Bertilsson

Ouch! That explains it. Valve switched their security certificate provider from "Verisign" to "DigiCert". When you go "offline mode", Steam says it is copying your "credentials" from the server to your local drive. When you launch the Steam Client in "offline mode", apparently it checks your locally cached credentials for a valid security certificate to compare against the certificate in the game executable. In the case of the "downgrade", it has the old certificate, so it fails the check and the Client refuses to launch the (to it) "pirate" game. I think that officially makes the "downgrade" a "dead horse". You would have to hack P4 to use the "DigiCert" certificate, and that would constitute "piracy". Someone might ask Steam about it, but really doubt they would have any interest in that request, as they would have to purchase certificates from both providers to accommodate a few mod users. Simpler by far to tell them to just buy "EW". -Dubious- If it was possible to leave the P7 certificate part of the file untouched and only convert the rest of the file from P7 to P4, then it would not constitute piracy. It would just be a partial downgrade of the exe, which would not be usable in offline mode. Since P6 can be downgraded to P4, it seems that the integrity of the exe is not verified when playing in online mode and that the certificate is not depending on the integrity of the file is pretty much proven by the possibility to mod the exe in general, so I guess it could work. But it is however a theory that I am not planning to explore (especially not at the risk of Steam banning me because I appear to be experimenting with naughty things), so you are absolutely 100% correct in the assumption that the mod is now officially dead. I have hidden it to make sure no-one waste time on trying to use it. I also think you deserve special credit for tirelessly helping people over the years. That is truly an amazing effort. Thank you!

Yes, no one expects it! :P From a quick file compare in HxD I can see that there are some differences in the first 250 bytes. After that the files are identical up until around 75%. After that point all bytes are different (or more likely offset) so something was obviously modified there. Jumping to the end of the file I also noticed that P7 has unique references to DigiCert and P6 has unique references to VeriSign.

I've tested pretty much every thing I can think of without any success. Fresh install of P7 starts without any issues. If I replace XComGame.exe with P6 backup the game won't start. As long as I can't get past that trying to downgrade further seems pointless. I have tried both Dubious DirectX advice and lots of compatibility settings as well as getting rid of the XComLauncher, removing EW DLC. When trying out different compatibilty settings the only effect I was able to get was to have the Steam bootstraper service go nuts and constantly restarting itself until I killed Steam. One thing I have not tested (and is not very eager to do) is to install steam in the exact same directory structure as I had 2013 (today I have Steam\ as a root folder on C:\, in the past I had it inside another folder). I guess it is not impossible that hard coding file location inside the .exe is part of steams copy protection even if I do not think that is the case.

Thanks. Maybe... After a little digging around I found a backup of the patch 6 version I used to create the downgrade mod (missing the EW folder). When comparing that folder with the latest version I can see that only XComGame.exe has been changed outside EW folder. If I install the latest version and use the downgrade mod to make it patch 4 version and manually replace XComGame.exe it should in theory work, but instead what happens is that I end up in the launcher and when selecting the to play EU it starts as a background process and nothing happens. Most likely the problem is in \common\XCom-Enemy-Unknown\XEW\Binaries\Win32\XCOMLauncher.exe which was never included in the downgrade mod. With some luck it would be enough to replace also that file with an older version and if it works it would be very simple to make the mod working again. But I don't think I have any backup of it to test the theory :(

Sometimes the most unlikely things happens :smile: Unfortunately, I'm unable to start XCom EU after manually downgrading to patch 4. I just end up with a background process called "XCOM: Enemy Unknown (32 bits)" running and nothing more happens :sad: When comparing my backup of XComGame.exe (patch 6) with newly installed XComGame.exe I can see that file size has increase ~500 bytes, so something has definitely changed after the downgrade patch was originally created. I will probably do some more attempts and keep an eye on this thread to see if Drakous79 has better luck getting an old version running, otherwise I think it is probably well overdue to retire the mod. Edit: Fixed incorrect quote.

You misunderstod the reply. It is random for each soldier at which rank the AWC perk should trigger. If a soldier has already reached the randomly selected rank before you build the AWC then that soldier will never get the bonus perk. The following lines in XComGameData.ini allow you to limit the random rank XComHeadquarters_MinAWCTalentRank=2XComHeadquarters_MaxAWCTalentRank=7 If you for example change it like this:XComHeadquarters_MinAWCTalentRank=4XComHeadquarters_MaxAWCTalentRank=4 Then all soldiers will receive the AWC perk when they are promoted to Lieutenant, provided that you were able to build AWC before any soldier was promoted to Lieutenant.

No need to apologize, that was exactly the type of feedback that I requested. Making it more structured would make things easier for myself but the main focus is not to make it simple for myself but for the user. However there is actually more structure than meets the eye in my example, I just didn't do a very good job of explaining it. The structure is really as simple as this: Seach critera : Target data (replace) The search criteria is one or more wild card search words (separated with '&') which will be used to identify which line to edit. Target data is the complete replacement line you want to enter. If search critera is not unique, such as some difficulty level settings, then you can add (#) to indicate that you are interested in the second, third, ... matching line for that search critera. This far we have a very simple to use notation, Find this : Write this In order to be more user friendly it allows the following special case where search criteria is omitted and only target is provided: Steam_Vent=3 This is intended to make it child easy to use for simple edits and should increase the readability of the mini file. The next special case is that you don't want to enter the full target line if you only want to edit something small on that line, ie iWill=10 or whatever inside a long array. So you are allowed to enter target data as one or more array objects separated by ',' the same way as the original ini file does it, instead of complete target line. This allows much better readability and modder friendliness, but more importantly, doesn't unintentionally overwrite other parameters in that line. A mod that increase mobility for armors can now co-exist with a mod that increase will for the very same armors. (Internally the tool will check if the beginning of the target data matches the beginning of the targeted line and assume it to be partial edits otherwise. Then it is only a simple matter of chopping up the contents of the target data and the contents of the array and match/replace it in the same way as Steam_Vent=3, but separated by , instead of line breaks). So far, we have now covered all possible replace existing row, use cases that I can think of. The only thing missing is ability to ADD stuff and delete stuff. The ability to delete stuff has been ignored since I cannot think of one single use case where that would be necessary. The ability to add stuff, almost went down the trashcan for the very same reason, except I can think of a few isolated scenarios, which probably all have in common that they are part of long war or are at least extremely rare to find outside that mod. First of all, if a new line is to be added, then it needs to be clarified in which [sECTION] of the ini file should it be added? If you want to add something completely new like Backup_Steam_Vent=3 I could allow it to be as simple as: [sECTION] : Backup_Steam_Vent=3 Ok, so Backup_Steam_Vent does not exist, this must mean that user wants to add that to this section... But does the user mean the beginning of [sECTION] or the end of [sECTION]? Does it even matter? Technically it shouldn't matter in most cases except for difficulty settings and similar where it actually does matter and in those cases neither is sufficient. And what happens if user accidentally enters Stean_Vent=3, will this be a bug in the mod where original value is not updated and Stean_Vent is added? So now suddenly we have the following issues, it must be clear that user, really wants to implement the very rare exception of adding stuff and it must be clear exactly where it should be added and on top of this it must be repeatable, so that a new version of the mod will not accidentally add unwanted extra lines every time the mod is installed. AddBefore and AddAfter commands where indeed considered for this but they both risk failing on repeatability if used multiple times with same search critera. So bascially what I would need is AddBeforeAfterOnlyIF, commands and now we are guaranteed to make it so complex that the learning curve will make it unlikely that anyone, including myself, would ever attempt to use it... and we still haven't approached the possibility to add new parameters inside existing arrays. Based on this I decided that I wanted to only allow adding new rows and ignore the ability to add parameters to existing objects, at least to begin with. What I figured would be least complicated would be to expand the (#) match indicator to (x/y) which would only be relevant in the rare situation that someone wants to add something and once learned how to use it would be very simple to use again. As to multi mod conflicts. Yes, if two mods both want to expand the same "Matrix" or "vertical array" or one of them expands it to mess up the order for the other then this is pretty much already an unresolvable scenario and one of the mods simply needs to be adapted to be compatible with the other one. As to number of objects/parameters inside a single line array, as long as the tool only allows replacing existing ones, there really is no risk of messing up the number of parameters.

I'm planning to make a new tool for .INI patching The tool would be a simple vbscript with optional arguments for sourcefolder and targetfolder. (default should be current directory and ..\My Games\XCOM - Enemy Within\XComGame\Config\) Source files are identified by the extension .mini and target file is identified by the name of the .mini file. Example: XComGameCore.mini will target XComGameCore.ini XComGame.mini will target XComGame.ini So basically all that is needed to patch .ini files would be to run the script from a folder with one or more .mini files. The .mini files are not complete .ini files, but instead they only contain instructions what should be changed. For smaller mods this is good because it can be used by multiple mods without conflict (as long as they are modifying different values). For larger mods it should make life a lot easier if a new patch is released since it will still be compatible unless the new patch targets something which is part of the mod. So far I think all is good, but I still haven't decided on the exact notation inside the .mini files and which features should be available. So, right now I'm thinking about the following features and notation, but I am still very open to suggestions: ;Changing unique one-liners like UPLINK_CAPACITY= from 1 to 2 UPLINK_CAPACITY=2 ;Find the kevlar armor and replace it with a complete new line Armors= & kevlar : Armors=( ABILITIES[0]=0, ABILITIES[1]=0, ABILITIES[2]=0, ABILITIES[3]=0, Properties[0]=0, Properties[1]=0, Properties[2]=0, Properties[3]=0, strName="", iType=eItem_ArmorKevlar, iHPBonus=3, iDefenseBonus=0, iFlightFuel=0, iWillBonus=0, iLargeItems=1, iSmallItems=2, iMobilityBonus=3 ); Tac Armor ;The script will search (non-case sensitive) for a line with *Armors=* and *kevlar* and replace with whatever is found after : ;Find the kevlar armor and replace only a few selected parameters Armors= & kevlar : iWillBonus=100, iMobilityBonus=50 ;The script automatically discovers that this cannot be a complete line replacemet and instead updates the individual parameters, if more than 1 they must be separated by comma. ;Modifying the third SAT_HELP_DEFECT line (3) SAT_HELP_DEFECT=0.7 ;Adding a new Armor on the third Armors= line (3/22) Armors=( : Armors=( ABILITIES[0]=0, ABILITIES[1]=0, ... ;3 indicates that the new line should become the third to match the search critera, 22 indicates that it should only be added if the current number of matching lines is <=22. If it is 23 then the line has obviously already been added and the third line will be replaced instead of added. This is to secure that the mod can be applied again and again without issue. ;Adding a new unique line to the end of [XComGame.XGTacticalGameCore] [XComGame.XGTacticalGameCore] (1/1) Something_completely_new=123 Any feature missing? Any suggestion how the notation could be improved?

I was only away for a minute or so to see if anyone would notice that I was missing :wink:

I would if I could... But unfortunately the only backup I have from EW Patch1 contains several modified .upk files which not even god knows what failed modding experiments I may have subjected them to. While I'm sure it is possible to find someone who have original backups of those files, the method used to roll back Enemy Unknown to P4 has not proven to be very user friendly or guaranteed to work for everyone, so in all honesty it doesn't really seem worth it only for using toolboks. If there is a specific mod from toolboks you are missing then I recommend making a mod request for that specific mod instead.

That is sort of an issue by itself when it comes to releasing an update of a mod. I don't think it would be very popular to ask players to verify steam cache between installing beta 1 and beta 2 of a mod... Or to make it mandatory to install beta 2 addon and beta 3 addon (in that order) before installing beta 4 addon when going from beta 1 to beta 4. Not to mention the effort involved in actually maintaining such version chains.

How about breaking them down into two separate commands then? CreateObject If the object does not exist: Create the object. If the object exist and is of correct type: Great! No action needed. If the object exist but is of incorrect type: Something is wrong, throw error to alert user that he/she may accidentally be up to no good. SetType If object is not of requested type: Change type If object is already of requested type: Great! No action needed. The upside to not see target already achieved as a problem is repeat-ability. I can change an unrelated detail and run the same script again and again.

I think the key to this may be found while figuring out a good way to handle WGhost's latest discoveries. Instead of renaming an object, create a new object with proper name and use that object instead. Edit: Something like this might work: NEWOBJECT=XGFacility_Barracks.PickAClass.NewVarName;Type After that this new object can be referenced in the same was as any other object. Edit 2: Or even better: MAKEOBJECT=XGFacility_Barracks.PickAClass.NewVarName;Type If the object does not already exist: Create the object. If the object is of different type: Change type

If the entire squad has no enemy contact (cannot see and is not seen by enemy) at beginning of player turn, then all boring stuff would be instant. MEC Repair servos max out instantly. Adaptive bone marrow max out instantly. Primary and secondary weapons are instantly reloaded. A side effect from this is that it will likely result in increased chance to collect the second meld container, since time will not be spent healing / reloading between enemy contacts. I'm OK with that. I will most likely attempt to implement this myself sooner or later so this request is mostly a reminder to myself.

Whenever player press R on keyboard the current soldier should attempt to reload and hunker down in the same turn. If soldier is not in cover he/she would only attempt to reload If soldier has full ammo he/she would only attempt to hunker down If soldier has full ammo and is not in cover then nothing should happen If soldier is hunkering down due to panic no automatic reload should happen Narratively this would be equal to non-panicking soldiers having brains enough to reload weapons instead of using their hands to cover eyes and ears like a 3-year old when they are actively taking cover. Optionally there should be a chance to fail reload during hunker down if shot upon. Optionally automatic reload should only happen if soldier didn't move (reload and hunker down each requiring 1 action point). I will most likely attempt to implement this myself sooner or later so this request is mostly a reminder to myself.