I wrote a solution in code on how to fix the problem to make it always haul meat and that change too made it into B18. The meat was only hauled if the animal had no butcherProducts. I wrote about the issue where butchers set to hauling would haul butcherProducts if any and drop the meat on the floor. I put in a change request for that, and that popped out in B18.Yeah they actually listen for feedback. Quote from: CannibarRechter on December 25, 2017, 07:54:09 PMBTW, it used to be that various graphics were first man wins. It might not really matter to the average patch writer, but technically it's a totally different solution with different pros and cons (more pros since ModCheck takes away all the cons ) I optimized the code to how it's actually patched, which makes ModCheck significantly faster than vanilla and this boost is only available because it patches each file individually on load. I had a bad experience assuming patching afterwards when I first wrote ModCheck and suddenly it would be possible to write a patch file, which was reported to take 10 minutes to load. However there are some cases where the difference matter. The end result is about the same, though isn't it? I can see some pathological cases they would be ensuring against in steps 5-6.In most cases the result will be the same. I see what you are saying here, and see the distinction. Quote from: CannibarRechter on December 25, 2017, 07:54:09 PMAh. Both of those require the mod creator to add PatchOperations to their xml files. The other is telling which file to patch, which avoids trying to apply the patch to all files with massive speed boosts to follow. ![]() One is an error to the user if the load order is wrong. ModCheck has two features related to what is mentioned here. I have seen a few, which adds some unneeded restrictions, but nothing bad will come from fulfilling all the demands in the description. What will require a specific load order is if a new item has a parent because that will cause an error unless the parent is loaded first.Ī general rule is to follow the instructions given with the mod. Changing the order could change minor stuff, like the order of buildings in the build menu, but nothing gamechanging. In most cases the mod order will not matter. The order will only matter if two patches replace the same tag, in which case it is the last one, which is used. In case of multiple patches in the same file, they are applied top to bottom. ![]() In a mod, the order is filenames alphabetically. If there are multiple patches, the order is the mod load order. It really is part of the xml loading code. What's interesting is that nothing takes place between loading the file and patching it, meaning the game can't tell the difference between a patched file or if the Def xml was written as it is post patching. I'm currently working on a stable solution for this problem.Īs seen in #6, patches are applied to each file when the file is loaded. However it's worse than that since loading multiple different versions of the same assembly file will result in an undefined behavior. Once all Def files have been loaded, Def cross references are resolvedĪssemblies (2&3) have a first one wins.For each Def xml file, load it into memory and then apply all patches.For each mod, loop all xml files in Defs.What happens when the loads are loaded is this: However while working on ModCheck I discovered this is not the case. Quote from: CannibarRechter on December 25, 2017, 08:59:25 AMpatches are processed after all defsI thought so too and it feels like it.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |