This archive is for modders ONLY. It contains a dirty version of Trolleybus' VanillaTradeFix. With diff files. Made from VTF from February 6 2022.
VanillaTradeFix contains a lot of fixes and also a lot of pretty but utterly unnecessary whitespace changes. DirtyVanillaTradeFix is a version of VanillaTradeFix that has all the whitespace changes stripped away, leaving only relevant, gameplay-affecting changes in the LTX files. If you ever wondered what exactly was so wrong with vanilla Anomaly that Trolleybus made a whole mod to fix it, well, now you can see for yourself - there are diff files in a separate subdirectory.
This archive is for modders only (for people who might want to introduce VTF changes into their own mods). If you don't know what "diff" is, you probably don't need it.
Original VanillaTradeFix is here: Moddb.com
The only change I did by myself was to insert [toolkits_h] and [artefacts_h] sections back into presets, for compatibility's sake, because I know that someone is going to disregard the description and will try to install it as a mod. Everything else was made by a script. Hopefully, the script didn't introduce any errors into the files. I certainly haven't tested them.
v1.0.1: fixed a small bug in the script that handled a change from "item = value" to "item" (without value). This affected a few files, resulting in things like "device_pda_2 1, 1" instead of "device_pda_2".
Honestly, modders shouldn't be distributing full blown trade .ltx files with their mods anyway. At best an injection script should be used, at worst they should be in DLTX format to avoid overwriting things.
Perhaps that's what the basis of this resource should be - DLTX files that add your changes forward, and which modders can then tack-on their own stuff to.
Just a thought..
It's not mine. Trolleybus is the author of the mod. I just reformatted it to make it obvious what he changed.
As for DLTX, I'm not sure. DLTX seems to work OK for sparse changes, but trade adjustments usually involve a lot of stuff.
Personally, I'm also concerned that DLTX makes mod conflicts unobvious, because ModOrganizer has no way to see that two differently-named DLTX files from two different mods actually change the same fields of the same section in the game. I only briefly looked through the code that applies DLTX changes in the engine, but my current understanding is that the last change wins. Meaning that if two DLTX mods change the same fields in the same section, you quietly get either one or the other, even if the result makes no sense.
If you really want to get behind DLTX, consider filing a feature request with ModOrganizer to make it scan DLTX files (they have distinctive names), collate all changes and to detect conflicts when two mods change the same fields.
Like I said, DLTX for trade files would be the lower level solution. Script-based injector would probably be the best available option, which some of the more recent weapon mods utilize (including BaS).
Also, it's a little more complex then just that with DLTX. Straight up overwrite of the same field by multiple files will throw up an error, so that becomes pretty obvious immediately. But there's plenty flexibility through syntax that DLTX utilizes. It's not perfect, granted. But it's miles better then having a user try to figure out changes between two files, even with things like "Compare" plugin in Notepad++, Winmerge or similar tools, and then merge them..
Might wannt to check DLTX docs, and also Demonized has a pretty great summary on his github for DLTX syntax changes in the latest modded EXEs: Github.com
Either way, thank you for fixing up and posting this resource!
Straight-up overriding the same field by multiple files does not throw up an error. I've just checked this by making two addons with differently-named DLTX files. One makes Sidorovich sell 10 packs of bolts, the other makes him sell 20 packs of bolts. Then I started a new game and looked at what he's selling.
It's worse than I imagined. It doesn't even depend on the order of the mods in ModOrganizer! The DLTX file with higher (as per string sorting algorithm) name wins (i.e. it's applied last and overwrites the changes made by earlier DLTX files).
There are no obvious errors in the log file. ModOrganizer, obviously, doesn't detect any conflicts either.
I don't see howscript-based injection would fix this.
So, again, one way to forestall the impending doom of invisible DLTX conflicts is to make MO (or maybe Modded EXE itself) police the DLTX files and report conflicting changes. I'm pretty sure I can whip up a script to do the most basic checks like that.
By the way, you can't do such change policing with script-based injection, because each injecting script operates independently (I assume; don't quote me on that) and can't know that it's conflicting with some other script.
The other way is to invent some new DLTX syntax where it's possible to specify not just the new value, but also the old one. Then DLTX would refuse to apply changes if the value being changed doesn't match the expected old value. That would be much less convenient, though. Not the creation of such files - that can be automated away. The inconvenience would come from the fact that every vanilla change will require updates in DLTX mods, and every trivial conflict will have to be solved to placate DLTX.
I will look into it later on. Might be really good thing.
I have no idea what this is, I've put it in my game along with other 426 mods
:) I hope it's nice
Please don't. Seriously.