I would like to know this as well. A diff file is the only way I can think to apply the effects of several UI mods at once, but I also don't know anything about BG modding.
I want to create a mod that customize the UI. My idea was to have different diff files and apply the ones corresponding to the option the user choose. Is it possible with weidu (I don't know anything about modding BG) ?
Is there a better way to do it ?
Thanks
Diff files are just BG1/BG2/IWD specific archive files. The game unzips them as needed. What you need to do is have the individual GUI files need & have WeiDU install them. If you have several versions, then the easiest way to do that would be to use a .tpa file and a .tp2 file (the .tpa file does most of the work; the .tp2 file basically installs things based on what options the user picks), and then to have different GUI options in separate folders. So, for example, let's assume I had 2 GUI options: a purple GUI and a pink GUI. (Just go with it for the sake of the example please. ) I would set up the .tp2 file to ask, "Do you want to install purple GUI or pink GUI?". When the user selects their choice, then it would install the GUI files in /modfolder/purpleGUI or /modfolder/pinkGUI based on that choice. Basically, you separate out things based on the choices given to the user. Be careful though. If 2 (or more) options use the same file, then you need to append to that file. You don't want to be overwriting things.
Oh, I didn't know Diff files were a BG specific thing, I was thinking more like a git diff file used for patching. That would allow you to inject code directly into an existing file based on the differences. Using the example above, you could take the inventory screen form the pink GUI and the record screen from the purple GUI even though they both modify the same file (UI.menu in this case) if you set up your patch diff files correctly.
WeiDU has enough byte-level stuff that it can do literally anything to a file. Now, whether it can do it easily and/or be worth the effort is a more relevant question.
I don't think WeiDU knows the new file types yet, so the bigger problem is that it probably can't extract the UI files from the biffs until we get an update.
Couldn't existing version control software (e.g. git, hg, etc...) be used for this. It would essentially be a series of three way merges as long as every individua component was made off of the same base file.
For the git case you could have one branch of the repository have the original UI file and make a new branch off if this one for each optional component committed to them. To mix and match the user can merge the changes the want into master (as long as the don't conflict). One branch can also have any official UI changes in future patches so mods that make small changes aren't lost. The hard part is making a user friendly interface for this, git is not the easiest thing in the world to use.
Couldn't existing version control software (e.g. git, hg, etc...) be used for this. It would essentially be a series of three way merges as long as every individua component was made off of the same base file.
You're under the impression that BGEE would play nice with currently existing modern version control software...
The game (at its core) is 15 years old. Good luck.
The thing that I think should work is to be able to have the first component say 'Select this button based on this pattern (for example: contain an action with this value) and change the area values'. The other component will say 'Select this button based on this pattern and add this line to it'.
Couldn't existing version control software (e.g. git, hg, etc...) be used for this. It would essentially be a series of three way merges as long as every individua component was made off of the same base file.
You're under the impression that BGEE would play nice with currently existing modern version control software...
The game (at its core) is 15 years old. Good luck.
I just mean version control for the override folder, no need to touch any of the other game files (there are other tools for extracting the needed files). All UI mods have been reduced to placing files in the override folder now. So each branch would contain a "snapshot" of the override folder for that particular UI component.
Yeah, I was thinking things like merge conflicts would be handled by the mod manager wrapped around the patch system, e.g. don't allow conflicting mods to be selected/fail gracefully with a "this mod is not compatible with your current mods" message. I don't think it needs to be handled by the actual patch system itself.
Edit: The second case you mentioned would be solved by a there way merge.
lefreut
Member Posts: 1,462
Comments
So, for example, let's assume I had 2 GUI options: a purple GUI and a pink GUI. (Just go with it for the sake of the example please.
Basically, you separate out things based on the choices given to the user. Be careful though. If 2 (or more) options use the same file, then you need to append to that file. You don't want to be overwriting things.
Here's the WeiDU documentation: http://www.weidu.org/WeiDU/README-WeiDU.html
What you're looking for are subcomponents.
Here is a decent explanation of diff patch files: http://www.thegeekstuff.com/2014/12/patch-command-examples/
I don't think WeiDU knows the new file types yet, so the bigger problem is that it probably can't extract the UI files from the biffs until we get an update.
For the git case you could have one branch of the repository have the original UI file and make a new branch off if this one for each optional component committed to them. To mix and match the user can merge the changes the want into master (as long as the don't conflict). One branch can also have any official UI changes in future patches so mods that make small changes aren't lost. The hard part is making a user friendly interface for this, git is not the easiest thing in the world to use.
The game (at its core) is 15 years old. Good luck.
Edit: The second case you mentioned would be solved by a there way merge.