10
editsModding:Working with LSX files: Difference between revisions
Jump to navigation
Jump to search
Some minor errors & added stuff about AllowImprovement & MulticlassSpellSlots
(Created page with "I'll try to give people a head start here in working with lsx files overall, which are just xml files, and getting a head start with modifying Progressions.lsx overall. This gives you the power to modify & add classes, what they get on level up, and a good workflow overall. ==== Folder structure ==== There's already tutorials on here on how to setup the folder structure, overall it's very beneficial to package your mod as .pak instead of an archive which the user extrac...") |
(Some minor errors & added stuff about AllowImprovement & MulticlassSpellSlots) |
||
| Line 2: | Line 2: | ||
==== Folder structure ==== | ==== Folder structure ==== | ||
There's already tutorials on here on how to setup the folder structure, overall it's very beneficial to package your mod as .pak instead of an archive which the user extracts in to their data folder. BG3 uses an override system which I will get into more detail with later on, extracting everything in the data folder seems to somewhat circumvent this behavior since one seems to be forced to put stuff in some variation of Gustav, GustavDev, Shared . Be sure to really take a look at the folder structure because missing one little detail will make your mod not load & it's overall a tedious process to debug. | There's already tutorials on here on how to setup the folder structure, overall it's very beneficial to package your mod as .pak instead of an archive which the user extracts in to their data folder. BG3 uses an override system which I will get into more detail with later on, extracting everything in the data folder seems to somewhat circumvent this behavior since one seems to be forced to put stuff in some variation of Gustav, GustavDev, Shared, SharedDev. Be sure to really take a look at the folder structure because missing one little detail will make your mod not load & it's overall a tedious process to debug. | ||
==== Working with .lsx, or rather .xml files ==== | ==== Working with .lsx, or rather .xml files ==== | ||
| Line 8: | Line 8: | ||
==== How does BG3 load resources? ==== | ==== How does BG3 load resources? ==== | ||
As hinted on earlier it's very important to learn how resources are loaded and overridden. Imagine you extract the game .paks, you look through the folder structure, and inside Data/Public/Shared/Progressions/Progressions.lsx you find xml data for levels. You modify it to your hearts content, perhaps you remove stuff, add some stuff, and then you just let it sit there inside that folder hierarchy. What will happen is that it will completely replace that file as seen in the .pak file. Perhaps you noticed that there's only level 1-6 in this file, and you thought it smart to add levels 7-12. But the problem is that level 7-12 is another Progressions.lsx inside the | As hinted on earlier it's very important to learn how resources are loaded and overridden. Imagine you extract the game .paks, you look through the folder structure, and inside Data/Public/Shared/Progressions/Progressions.lsx you find xml data for levels. You modify it to your hearts content, perhaps you remove stuff, add some stuff, and then you just let it sit there inside that folder hierarchy. What will happen is that it will completely replace that file as seen in the .pak file. Perhaps you noticed that there's only level 1-6 in this file, and you thought it smart to add levels 7-12. But the problem is that level 7-12 is another Progressions.lsx inside the SharedDev subfolder structure, and that one is loaded after the one in Shared and just overwrote your 7-12. While this seems like a downer it should also give you a hint on how the system works. There's a load order, even inside the shipped .paks with the game, and you generally don't want to mess with that, because the patches are also playing ball with that load order. Generally, whenever you see Gustav/GustavDev/Shared/SharedDev in paths you should replace that with your mod name when you copy it over to your mod project. Generally you should only include sections of the files which you're actually changing, exclude everything else, and they will instead be filled by the game. This gives you the best chance that your mod is still working whenever a patch arrives, or if another mod is overriding stuff in the same file. | ||
So how are these files merged? It seems to be different depending on files, .txt files such as Data.txt merge based on the key of the key / value pair. .lsx which I'll focus on however are merged base on their UUID, so when you look over the xml whatever group has an UUID child is the granularity that you will be overriding on. | So how are these files merged? It seems to be different depending on files, .txt files such as Data.txt merge based on the key of the key / value pair. .lsx which I'll focus on however are merged base on their UUID, so when you look over the xml whatever group has an UUID child is the granularity that you will be overriding on. | ||
| Line 69: | Line 69: | ||
Lastly we have a child structure which is merely an array of subclasses, if you want to add a new sub class copy the structure & change the UUID value, the UUID maps to an entry inside ClassDescriptions.lsx. | Lastly we have a child structure which is merely an array of subclasses, if you want to add a new sub class copy the structure & change the UUID value, the UUID maps to an entry inside ClassDescriptions.lsx. | ||
In addition to the base classes you'd expect there's also MulticlassSpellSlots, this seems to just be a placeholder which kicks in when you multiclass with spell casters to make sure they get extra spell slots dependent on general character level instead. | |||
You might also run across an attribute with an id of AllowImprovement, adding this to a base class level & setting it to true makes sure that you get a feat for that level up. | |||