PepprmintButler

There is no ini mod for class allocation. Afaik nobody was able to mod it through the upks either. On a side note, I'm baffled by your complaint. I believe snipers are possibly the most powerful class, to the point of being frankly OP at the colonel level. And I'm certainly not alone in this opinion. Sure, they are weak at the squaddie level, but that's supposed to balance out their immense power in late game. Equipping a scope should give you enough hit chance for the leveling phase.

Nice work bokauk ! (^^)d

You will need to go into the upks to look for the second wave settings (which afaik have not been found yet), but I doubt it would be of much use since you cannot add code yet.It might be possible to switch mobility for xp for example but that sounds tricky. Can't say much more until the relevant scripts are found.

No, there's no simple mod to get the Psi research from a Sectoid (nothing in the ini for that anyway. It probably can be done through UPK surgery). I honestly don't see why you would want that though.

This has been discussed extensively in the forums before but I don't think a mod has been released to correct just that one thing. Doing a proper search in the forum would have let you to these instructions for how to modify things in the exe-embedded ini : (but then again that's not very clearly arranged so I can understand how it's not that easy to find) - Get a tool called Resource Hacker (freeware, google for it) and install it - Make a backup copy of your game exe (steam/steamapps/common/xcom-enemy-unknown/binaries/win32/xcomgame.exe) - Open that exe with Resource Hacker - From the left panel, navigate to RCData/1020/1033 - There you have the contents of an ini file in plain text. There are lots of things you can modify in there. (see below for the specifics in your case) - After making your modfications, press Comple Script (button over the text area) - File/Save your exe (keep the name as the original xcomgame.exe) - Start Steam in OFFLINE MODE (or your mod will not work) - Launch game from Steam, you're done. Regarding the soldier health bug, the problem is that new recruits have their health defined by the Easy difficulty modifier, regardless of the difficulty you are actually in. The line you will be looking for in the data is : BalanceMods_Easy=(eType=eChar_Soldier, iDamage=0, iCritHit=0,iAim=0,iDefense=0,iHP=1, iMobility=0,iWill=0) The base HP for a soldier is 5, making it 6 with this iHP=1 modifier. What you can do is set the iHP on this line at the same value that the equivalent line for the difficulty you are in. Be careful, the balance modifier for Classic is described in the file by BalanceMods_Hard and for Impossible it's BalanceMods_Classic, which is counterintuitive. The value for Classic and Impossible both is -1 (4HP) (...I think. My exe may be modded so I'm not completely sure). So if you set the iHP value to -1 instead of 1 in the line above, new recruits in your games at all difficulties will have 4HP. If you play Classic or Imp, then this is the correct value, problem solved. The value's not correct anymore for normal or easy, but you should'nt be playing that anyway ^^ BTW, the change applies to new all soldiers recruited after making the mod, even in games that were started before the modification (... I'm pretty sure it does, at least...) Also, it's highly likely that this bug will be fixed by Firaxis themselves in the next patch, whenever that may be (my money is on the end of this month)

This is brilliant, thanks. Will try some commands as soon as I find time to.

Nice find daimond007, that saves us a good bit of work ! Did anyone find where the 100 value for starting items that are not infinite is located ? I'm thinking this could complement nicely the "all items are sellable" mod tjat was workef on earlier, but I'd rather turn that 100 down to 10 or something.

Oh, right, good one. Vehicles/aircraft stuff for cat 3 makes much more sense. Item 124 is avalanche missiles then. Backpack items (medkit, etc) are actually category 1 if I get this right. Also yeah, there's no 4, didn't even notice.

First off, many of the constants in XComGame.XGTacticalGameCoreNativeBase are known to be related to nothing, most notably BASE_NUM_ROCKETS = 1. It's probably sloppy coding on the part of the devs. The item list in BuildItems might be somewhere as m_arrBuildItem, along with a description of the BuildItem() function itself, but I did not find it. I suspect it's native therefore hardcoded into the exe. Still it is possible to guess what's what from the argument values. Here is my guess for categories : Category 1 = weapons Category 2 = armors Category 3 = secondary items Category 4 = UFO items Category 5 = alien bodies The arguments of BuildItem are probably BuildItem(ItemNumber, CosttobuildinCredits, CostsinElerium/Fragments/Alloys? (3), SomeOtherArgument). Note that some lines have 5 arguments and some 6. That final argument looks interesting but I have no clear idea of what it is yet. Looks like a reference into some other array. The first few lines have -1s on the supposed cost arguments, pointing to them being the ballistic weapons, which are free. They're also unlimited, which is consistent with InfiniteItems listing 2 3 4 5 and 6 ! (4 primary weapon types + pistol) Item 57, the first in the supposed armor category, is free and Infinite. I'd bet money on it being the Kevlar. (btw it's twice is the InfiniteItems list. It's sloppy, but it allows us to replace one of those with some other item without breaking anything else so it's a good thing for modding !) Item 85, also infinite, is most likely the grenade. I'm less sure about 124 (a backpack item ?) and 195 (not in the list!?). For the others, which may be useful to recognize it you want to add something to the infinite list, the credit cost to build is of course the biggest clue (2nd number). The armors in particular are easy to recognize, this should give you the exact composition of the BuildItem arguments (I didn't take the time to do it). Also, if you want to give costs to ballistic weapons (maybe in a mod where they are more powerful or whatever), you can replace their number in the InfiniteItem range with another or some number corresponding to nothing in particular and then give them costs in their BuildItem arguments.

Are we ? I was saying, we can change the default properties of XComDamageType_AreaBurn defaultproperties { bDamageUnits=false DamagedFFWaveform=ForceFeedbackWaveform0 KilledFFWaveform=ForceFeedbackWaveform1 } I did change that false into a true. If that's not it, what was it you were talking about ? (sorry if I'm being thick)

We can't change that. Actually we can. EliotVU showed me how and I did it ; it works (see my report a few posts up). The next thing is to find a way to give the damage a value because it does not seem to have one at the moment (instant kill). I also already made the changes to causessurroundingareadamage, it seems to have some effect, but I still need to do more testing to be clear on how it works. Thanks for the mod anyway, that's awesome, I hope more people can try it out and find out how it works because I don't have much time to do it myself these days.

This thread needs to be moved to Mod Requests.

I had the same error the first time I tried using XSHAPE, reinstalling Java manually (x64 from their website) worked for me.

I've been all over the upks looking for that code, no luck yet. Can't say I have combed averything, but I'm running out of ideas on likely places to find it. It's super frustrating. Also, good job on modding both panic friendly fire and the critical injury rate. :thumbsup: Will you share ? (I'm not planning to do anything with it personally, but I'm sure many would be eager to try those out)

That is awesome. Kudos. Sudden feature request : could you consider adding the "exotic" perks (those not appearing in any tree) to the list to facilitate testing of these ? That would save me mucho time, and maybe get more people to experiment with those. They're on the wiki : http://wiki.tesnexus.com/index.php/XCOM:EU_Perks

Yup, Torch does make damage now ! :dance: weee Problem is, it does a bit too much of it. Or more precisely it does no particular amount of damage, it just kills. There is no damage indicator, just a dying enemy. I guess the damage amount is not defined anywhere so this is what it comes down to by default. Also, since it is using the Shot animation & action, it actually only kills when a hit is rolled. Free aim does not give chance to hit % so difficult to say if it is actually the standard shot % but that seems likely. Also, Free aiming does in some instances result in the soldier firing somewhere silly (like the cover he is standing behind...). It looks like a LoS problem. On the "fire burns" front, it looks like the modifications I did to CausesSurroundingAreaDamage actually works. I had one of my guys, who was standing in fire in titan armor, go from 20-something HP to dead at an end of turn without anyone shooting at him. Again the damage amount not being defined anywhere seems to be the problem. Also the fact that he died from fire while wearing titan armor is kind of stupid (the armors ! They do nothing !) Anyway still ways to go but this is finally going somewhere. Thanks a bunch to y'all for the big help, feel free to continue to deliver :)

Whaddaya know, basic computer science does help ! I knew I was missing something :tongue: Thanks for the help. So yeah, simple as that, the two 01s in the second are the trues, 00 makes them falses. I guess 61 0B was more like an operator then ? Or prefix or something. I still don't got no computer skills to go with. Anyway I know I need to change a 00 into a 01 in the first file and I have a general feeling of where to look, so maybe I'll get somewhere this time.

OK, so thanks to sir EliotVU I did make some advances. Until I didn't. I must be really bad at this :confused: So the ellusive defaultproperties{} was in the separate file called default_XcomDamageType_yadahyadah. The bytecode to it is super short and short be easy pie, right ? So I was hoping to find a 27 which is "false" in a .function. There's none, meaning that the bytecode is different for these files which does not help, but hey there are so few things in there I'm bound to get to it at some point. So I change a few values around and understand the following : plaintext content ①bDamageUnits=②false ③DamagedFFWaveform=④ForceFeedbackWaveform0 KilledFFWaveform=ForceFeedbackWaveform1 hex content 61 4A 00 00 ①F3 07 00 00 00 00 00 00 ②61 0B 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ③1D 14 00 00 00 00 00 00 BE 55 00 00 00 00 00 00 04 00 00 00 00 00 00 00 84 BE 00 00 03 41 00 00 00 00 00 00 BE 55 00 00 00 00 00 00 04 00 00 00 00 00 00 00 85 BE 00 00 32 55 00 00 00 00 00 00 If I modify bytecode marked 1 the variable 1 is changed, same for 3, so 61 0B must be "false". Indeed if I edit eitheir of these bytes (randomly) false changes into something else, usually a 0 or 1 (I think I got a 2 once). If I change the first 2 bytes 61 4A I see no effect, so yeah, this must be it. Great, so now I just need to find the correct hex value for "true" and we're in business ! So I look around for a defaultproperty with "true" in it ; here is Default_particulesizebydistance_somethingsomething defaultproperties { MaxDistance=40.00 bUpdateModule=true bSupported3DDrawMode=true } 2 instances of true in there, should be fairly easy to point out 40 02 00 00 9C 52 00 00 00 00 00 00 1D 2E 00 00 00 00 00 00 04 00 00 00 00 00 00 00 00 00 20 42 D1 0D 00 00 00 00 00 00 61 0B 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 2A 0C 00 00 00 00 00 00 61 0B 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 32 55 00 00 00 00 00 00 Oh look two 61 0B s, that sure looks like my "true"s Wait what, 61 0B was the code for "false" ! But... But... Again, what is this sorcery !? :wallbash:

You, sir, are a gentleman and a scholar :) Do take a seat, have a drink. We'd be pleased to have you here. Let me take your coat. Be assured that any knowledge you humor us with will promptly be put towards the betterment of our humble community ! Also, insta-kudos. :thumbsup: (edit : if the Nexus lets me :sweat: ) Seriously, what a pleasure to have someone around here for pointers. We (well, I) have been running in circles for what seems like an eternity and a half. Then BAM !, magic happens. Thank you !

I too was under the impression that the sectopod ability did correct environment damage. Didn't test much, but basic rifles did not destroy much of anything iirc. Regarding aliens free aiming, I suspect the AI treats environment like shootable targets and does not make the difference with soldiers, therefore shooting at it randomly. Not sure aliens are attracted by the shot noises, they do patrol around and can bump into your squad even if you're not moving. Regarding the environmental damage values, they do make sense relatively to weapons but still could do with some rebalancing, seeing how plasma burns through anything. even aliens ship walls which should be much stronger than that.

How sweet that would be... I don't see it happening anytime soon though. We would need Firaxis to give us the (de)compiler, wouldn't we ? Is it even possible to reverse engineer one ?

You did give your non-heavies the Bullet Swarm perk right ? Modding this code would remove the impossibility for non-heavies to fire twice, not actually give them the ability to do it. I think your mod to the code is good and should do the trick.

Good points. Command abuse could be really bad (have just 2 guys with command on your team, an Assault gets 4 actions in one turn). In its current form it would need a pretty long cooldown at least. I dig your "On your feet, soldier!" idea, it sounds much less OP yet still useful.

Good idea there, I did not think of that. Did you try with eAbility_ShotDamageCover instead of destroyterrain ? It seems to be pretty much the same thing but it's worth a shot.

banjo, you're doing it right. That is a side effect of making any non-pistol weapon a pistol, not limited to arcthrower. If you put a shotgun (or anything else) as a sidearm, after switching you'll get a (cosmetically) superimposed "double-weapon" which does look pretty funny with some combinations. Because of that, I fear Perraine's theory does not hold because the primary weapons do play nice with all armors as switchable weapons on normal circumstances, yet still have this bug. The answer, as always, is hidden somewhere in the upks.