Larian Studios Forums Divinity - Original Sin Divinity Original Sin - Mods Publishing a Mod

Hm, I thought I had posted something before but ...

Anyway, there is no other way to rename Comback Kid but through English.txt (or French.txt, German.txt, or how ever the localizations are named).

Talents and abilities 'bypass' the 'translated string key system' and have the handles for their displayed strings stored directly inside the .exe.

English.txt is the ultimate file for all displayed strings. Only if a created object or a translated string key does NOT have a handle, it's value is displayed directly. So talent names are only changeable the way you already did, through modifying English.xml.

I know it sucks to not be able to pack this file into a Steam Workshop .pak and you have to provide it as an extra external resource but you already have this problem with Requirements.txt, because you must place it outside of the directories the editor considers for a .pak file.

Larian might do another patch for the EE eventually but I'm pretty sure they will not do any more changes for modders.
They will always point to D:OS2 and hopefully the modding situation and support there will be better.

I did not look at installation instructions of your mod yet, but if you install nothing more than English.xml and leave English.pak untouched, it could mean that it's read the same way as all other stat files (except Requirements.txt for some reason): first the unpacked version is read and then the .pak is read.
You'd have to test this but if it worked, you might be able to only provide a 'delta' as your English.xml and leave everything else out because it would be read after your file and only those handles that do not exist in your file take effect.
(Yes, you'd have to be careful with new handles to keep them unique across two files but I think it would be worth it and a delta file would be much smaller than the complete file.)

This would also make translations which I saw were already requested a lot easier.

The delta idea is interesting, and judging from experiences I had during development I think it will work as you suspect. I'll give it a shot later; it will definitely be an improvement if it works.

I just tested it--it works exactly as you thought. I wonder, this should work then for any user who is playing on any other language to just change the name of this "delta" english.xml to, say, russian.xml, right? It would only replace the strings that the mod modifies, so the majority of their game would still be in russian while the modified strings appear in english.

Should at least. I'm not even sure if it must necessarily be named English.xml or if it can be any name and must only be an XML with an appropriate header. At least it's not important at all how stat files are named because only the content is important. (Requirements.txt might be the only exception.)

I haven't looked at the other content of English.pak, but there might be some meta file which includes the current language and the engine then searches all XML file which have that language in some header tag.
This would give you the chance to put ALL language files into the Localization directory without other languages influencing the current selected language.

Although I'm no native english speaker I never played anything but english, so I have no experience how other language files look but there are tons of people who can tell you.
... or Abraxas knows since I know he's not native English either ;-)

I tried to test it with file names other than english.xml, but it didn't seem to recognize anything other than english.xml. English.pak only contains english.xml and "language.lsx" which looks like this:

Hm ... and does English.xml contain any header field with a language tag that has 'English' ?
If that was the case it could be the 'selector' for language files. But it could as well be the selector for the file names which are read.

No matter what it is, you'd need to find out how other languages are written.

I just looked into an english.xml (written with all small letters) and it is not even a valid XML by itself because it does not contain any headers.
So I'd guess if you wanted to provide translations, you will use files like french.xml, german.xml, etc. and you can put them all into a single package which is unpacked and only the file named after the current language is chosen among all files.

All requires testing though and you have to find out how different languages are named, because for example german might be named 'german.xml' but it might as well be 'deutsch.xml', french might be 'french.xml' but it could as well be 'francais.xml' and so on. (Just to be sure.)

The fact that it works to use deltas makes things easier for you.

You can provide all languages in a single package, make a copy of your english.xml to french.xml etc. and request the help of other people with translations.
For the beginning, users of localized versions at least have english displayed instead of nothing at all for your new stuff.
(Well, if you did the 'handle adding stuff' for your translated string keys etc., like the names of all the new spells, the new spell books, etc.)


You know that you can use <!-- --> comments in XML, so you might want to note the key from the translated string keys, or the original names - for the renamed talents - and maybe some description in comments above the lines. Makes translations easier I'd guess.


I just thought of one thing: the language file says value="English" and the file is named 'english.xml'. This is no problem ... on Windows, on a Linux (or OSX) file system, letter case DOES matter. So if the value from language.lsx is taken as the file name selector, you'd have to experiment I guess, Larian will not tell you if they simply take this value and attach '.xml' to it to get the file name or if they use something like "strtolower( $xmlValue ) + '.xml'".
This is only important for Mac and Linux because those have case sensitive file systems (I'm not a 100% sure about OSX but since its origin is some BSD, I suppose it inherited that.)

They should be English: 'german.xml' or 'french.xml' ('Scales' has a french localization).

Continuing some of the discussion on how to get my english.xml's modified strings to appear for other languages, Abraxas*, did you mention that renaming the "delta" english.xml to the correct language doesn't work? Because if that's the case then I think the only way to support other languages would be for me to provide a .xml file for each language with my english string replacements. But, why would this be the case? The english.xml is the same as other languages apart from the string contents, correct?

Indeed, using your english.xml and renaming it (in my case) to german.xml makes the game completely ignore the German.pak and switch to English, regarding the handled text in your english.xml (now german.xml) and taking all other English text that isn't translated in your english.xml/german.xml from the 'root' files. English is the language they developed the game in. If I understand everything right, they made the english.xml just for convenience (e. g. for translation into other languages).

Hm, wouldn't mean that the 'delta' idea does not work after all ?
The reason you did not notice it was that all strings you received from the roots and the translated string keys had no difference.

I'd say a bit more than convenience. It's a way for the 'language guys' to provide the final strings, maybe even in some Excel file. (Almost all grenades for example have different names from the ones in the translated string key files.)
Then have some script run over the provided data to build the different language XML files.

Yes, it seems so, sadly. The 'delta' file can only help to get the handles and the text for translation. But the work has to be done in the whole language xml files, if I didn't miss anything.

Was just an idea that it might work the same way as other systems do.

Worked for all crafting recipes in XC_Bags, which has only new recipes but the old ones still work. But of course, that's a different system.

EE is so big already that it would have been nice if they did not have to provide full XML files.

... if you guys have done some story scripting, you can at least remove the compiler's log file, which is usually more than 40MB already.
You can remove all files except 'story.div.osb' and 'story.div.osi' from Data\Mods\<MOD>\Story, they are not required. Leave all files under ..\Story\RawFiles though.
You might be able to remove even more files, but I myself did not dare to do that, I only looked, which files Main.pak had kept and removed the rest ...
Remove the files before repacking the mod in the editor.

How can I provide even translated versions for people then? One would assume that the string contents are not considered so, even if I had only German text and it was called german.xml, it would still switch to the English language. My latest update shipped with only the modified strings in english.xml but, since it seems to work for English installations, this should be okay to save some space if nothing else.

Good call on removing those Files, FrauBlake, it will save a lot of space. Are those files also unnecessary to edit the mod? I want people to be able to make modifications if they choose to.

Yes, the files are unnecessary. I did this a couple of times already, removing those files except the compiled ones, the two mentioned above, before packing the mod for publishing.

You can unpack XC_Bags and take a look but you probably have Main.pak unpacked already, so look there. The Story directory of Main contains only the two mentioned files and several subdirectories. Don't change anything in the subdirectories, only delete the unnecessary files from the Story directory.
Removing the log file should most significantly reduce the mod's size, because the file is 40MB. The log file is for developers not players.

The log file is the reason why Baardvark's 6 man mod on Steam is almost as big as XC_Bags although it contains hardly anything more than the story code change, and some minor stat changes that are negligible in size.

All you need for mod editing are the definitions, which are in Story\RawFiles and the source code files which are in Story\RawFiles\Goals.
You don't even need the compiled code for editing, only for testing inside the editor. (And of course in the published mod, if you made changes ;-)
And more strictly speaking, you don't even need the definitions for editing, only for compiling ;-)

You can remove ALL files and definitions, leave the source files and still start the editor without problems. You'll have to create the definitions again though before you compile the code.

You would have to provide a complete german.xml, it seems. Otherwise one would get German text for your changes and English text for all other strings.


Definitely good to know!