edemircinexusmods Posted October 9, 2022 Share Posted October 9, 2022 (edited) If you want help with understanding how to merge scripts 100% yourself and never rely on script merger other than it creating the paths for you after a file's first merge, just private message me. We can do a screenshare over discord and in less than one hour I can show you how to do this and gain the confidence to make code changes yourself and be in control of merging to ensure accuracy and less headache. You will need to understand 100% manual merging is sometimes tedius and sometimes requires you to use your brain. You will also need to commit time needed to make the manual merges. --------------------Understanding why script merger is just a tool and not an authority, a validator, an accurate means of merging, reliable, etc, why we have a problem with mods, why the modding community as a whole is very difficult to work with, etc.-------------------- I have been following sinitar's witcher 3 modding guide. I have never played the game and wanted my first experience to be everything it could possibly be with today's mods. I am a developer by trade so troubleshooting code related issues takes almost no effort. I know many of you want to vomit when looking at code, and I understand that. However, there are three huge issues with modding games that use script files: 1. There is no source of truth other than vanilla: In source control systems, every commit yields the 'official' code base. For you developers out there, lets just forget branches for now. In modding, there is zero source of truth and zero latest. The real source of truth is vanilla. Merged scripts are never a source of truth because there is no single goal to achieve by everyone modding files, and, because they are [if ever] rarely reviewed for accuracy by an authority. Script merger cannot help you here. It does its best to merge code but in reality, there is no concrete way of doing this accurately. Even if it says 'zero conflicts remain' that means nothing. It just means it 'merged' the code and it thinks there are no issues. YOU still have to review the code. Many times script merger will NOT merge correctly because only a human can interpret what the merge should consist of. It can easily screw stuff up because again, it does not use the source of truth (vanilla) to get alterations to merge. The cyclic merge files created from one mod to another are NOT source of truth, period. Lets say a particular script is modified by 5 mods. Assuming you merge all 5 mods together (click the file's root checkbox),what script merger does is take the first two, and merges their stuff together to make a merge file (assuming this script has never been merged before). Then for the other three that remain, it compares the merged file to the next mod, makes changes, and so on. A far more accurate but more complex way of doing this is to compare a mod file to the vanilla file to see what is different, then take those changes and merge them into the merge file. In other words, using this example, it would take the first mod and compare that to vanilla, get the changes, and create a merge file. Then go to the next mod, compare it to vanilla, get the changes, and attempt to merge them into the merge. Where it goes wrong is it doesn't get the changes each mod has from vanilla, it only 'checks' if the files are different from vanilla. 2. There are no standards. In development, there are standards for anything and everything. When you look at the Unreal Engine documentation, it mentions strict coding standards and principles Epic Games follows. It expects exactly the same from any contributor to the engine. Epic will simply refuse to accept any outside contribution if the code is not following their standards. Because the modding community is more of a 'every man for themself' approach, standards do not exist and therefore you have this wild wild west collection of mods that do a few things: a: contain only the code needed for that mod and that mod alone to function. This means all of the other code in the file is VANILLA. When you have two mods that modify the same file (almost certain), and you overwrite one with another, then the one used last will be the one used in the game because the other's changes are now back to VANILLA. This is what script merger attempts to solve. However, for some moderately complex merges, it fails to do this correctly despite saying zero conflicts remain. b: contain code to 'patch' other mods. This creates the problem of 'did the modder take all of the code from the other mod and put it in here', or 'did the modder only fix the areas they both touch', or 'is the modder's patch being updated to contain the latest stuff from the other mod it attempts to patch? Since there is this wild wild west approach of no standards, no governance, no authority, things break, don't work, and are sometimes difficult to figure out the issue. c: contain crap code. When you create an IF statement, NEVER should you just write a line of code to execute without curly braces to indicate an encapsulated block, EVER! CD Projekt Red even leaves out the curly braces. This is just pure laziness to save 2 extra lines, and is completely unacceptable. It leads to not only confusion of Script Merger, but also humans. What was the intent? Did they intend to include these other two statements to execute from the IF and forgot the curly braces??? 3. When the developer/publishers of the game put out an update, this sometimes breaks mods. This does happen because sometimes it is inevitable. Sometimes it is because some modders are just plain sloppy with their code. If you are a modder, and you create your own pointer/reference types, you should ALWAYS check if they are null in your custom routines, and have code written for those blocks to use vanilla to either inform the user something is not working (instead of the game just crashing or doing weird crap) or at the very least keep the game running. Most mods causing games to crash are the result of inexperienced developers making assumptions, period. There is no arguing that statement. If you check for null and have code in place to run vanilla if null, your game will simply not crash because you are not making any assumptions. This is literally what the Unreal Engine code does, and what their documentation tells you to do because that is the right way to develop. Edited October 9, 2022 by edemircinexusmods Link to comment Share on other sites More sharing options...
Recommended Posts