tracktwo / ppdefmodifier

9 stars 2 forks source link

Possible language support? #7

Closed jvarnes closed 4 years ago

jvarnes commented 4 years ago

I don't know very much about programming so forgive my ignorance, but wondering if it could be within the scope of PPDef to change the following files:

I2Languages I2Languages_CharNames I2Languages_GeoEvents I2Languages_GeoHavens I2Languages_Images I2Languages__Research

They don't have have guids, but they do have very specific m_Name strings (which are exactly their names i.e string m_Name = "I2Languages")

These files contain all the text in the game and it would be a godsend to be able to update them as Phoenix Point does a generally terrible job at explaining some things... for example Research could tell you what would be unlocked and abilities could specify AP/WP costs before you unlock them, etc. etc.

Also some tool tips are "hardcoded" with values for example Healer always says it gives +2 Willpower and +50% Healing (BTW does Healer actually give additional WP because I couldn't find that value, but I digress :P )

In my brain I'm envisioning something along the lines of:

{ "m_name": "I2Languages", "field": "Terms[686].Languages[0]", "value": "Soldier has increased Willpower and medical devices they use heal more damage.", "comment": " 50% bonus healing and +2 Willpower ", "comment": " Taken from ---> i2Languages " },

and/or

{ "guid": "I2Languages_Research", "field": "Terms[270].Languages[0]", "value": "We have managed to connect to some of the remaining weather satellites. We should use these to assess the extent of the new mist outbreak. UNLOCKS: The Phoenix Archives Research Project, Haven Recruitment Protocols Research Project and Global Mist Monitoring System on GeoScape", "comment": " We have managed to connect to some of the remaining weather satellites. We should use these to assess the extent of the new mist outbreak. ", "comment": " Taken from ---> i2Languages " },

( i.e guid would take m_Names or be hardcoded for these files... a subpar solution, but workable??)

Again I have no idea if this is possible or the complexity, but it and / or adding pptr support would open up PPDef massively in what it could change in Phoenix Point without requiring additional DLLs and complex coding...

Thanks for consideration and thoughts!

tracktwo commented 4 years ago

Thanks for the suggestion, I didn't realize the localization strings were also stored as defs. This is a good suggestion, I'll see what I can do. I need to look into the code a bit to see how I can get references to these things without a guid. Having the name is useful, but AFAICT there is no way to look up a def by name, just by guid. I may need to special-case the localization entries.

jvarnes commented 4 years ago

Thanks I appreciate anything you can do. :)

(Unfortunate that the Geo setup files mentioned in the other issue do not have a specific m_name like that or some other unique identifier... )

Worst case if you simply cannot hook the language files would you consider taking a look at maybe something like changing the localizationkeys (DisplayName1 , DisplayName2 , Deescription , Category, etc.). I'm thinking maybe something like:

"guid": "affb0b00-e649-f211-9f12-3b89d7b52c0c", "field": "DisplayName1.LocalizationKey", "value": KEY_TECHNICIAN_FIELD_MEDIC_NAME, "comment": " Default Value is KEY_HELPFUL_PERSONALTRACK_NAME (HEALER)", "comment": " Changed to KEY_TECHNICIAN_FIELD_MEDIC_NAME (FIELD MEDIC)", "comment": " Taken from --->E_ViewElement [Helpful_AbilityDef] "

"guid": "affb0b00-e649-f211-9f12-3b89d7b52c0c", "field": "Description.LocalizationKey", "value": KEY_EXPERT_HEALER_DESCRIPTION, "comment": " Default Value is KEY_HELPFUL_PERSONALTRACK_DESC (50% bonus healing and +2 Willpower)", "comment": " Changed to KEY_TECHNICIAN_FIELD_MEDIC_NAME (Restore +50% additional Hit Points when healing)", "comment": " Taken from ---> E_ViewElement [Helpful_AbilityDef] "

Not a very good solution, but it would allow some shuffling around of names, descriptions, etc.

Anyway good luck! I really appreciate the hard work you have put into creating this!


EDIT:

Hmmm in retrospect I guess I am asking for string support (which would come anyways if you can hook the language files) seeing as I just discovered BackersSoldierDbDef and BackersHavenDbDef which both have guids as well as a few other things that would be nice to change the string values on...

tracktwo commented 4 years ago

Good news: adding just string support is enough to get localization mods working too.

I don't know a whole lot about the inner workings of Unity defs, but the reason why the objects such as 'I2Languages' don't have a guid is because they aren't full defs in their own right. They show up in asset studio as similar things, but they aren't defs. That unfortunately means the def repository can't find them directly, because it only holds defs. The good news is that all of these I2Language* objects are linked from a single def: LanguageSourcesDef, and you can reach the individual language objects containing the text from that.

If you look at LanguageSourcesDef in something like asset studio it contains an array LanguageSources containing 6 references to other objects. These are exactly the I2Language entries. It's hard to tell which entry maps to which one just in AssetStudio, since it doesn't seem to show or support searching by path ID. You can search by path ID in UABE, so using that you can determine that the 0th element of the list (path ID 218615) is I2Languages. Then you can index into that with a normal guid mod. For example, the "NEW GAME" text on the main menu is in term 18 of I2Languages, so you can change it with a mod like this:

{
        "guid": "48cc3f00-fc67-cca4-ea6f-9cc0c0377f4c",
        "field": "LanguageSources[0].mSource.mTerms[18].Languages[0]",
        "value": "NEWER GAME",
        "comment": "meow"
}

(Sort of, that won't work until I update PPDefModifier to support string values)

Unfortunately these have a lot of magic indices in them: LanguageSources[0] is "I2Languages" that has a lot of the game text. mTerms[18] is the "NEW GAME" entry. Languages[0] is English.

(Other languages are 1 - Bulgarian? That's a guess based on where Snapshot is based, but it looks like the text is a lot more incomplete so maybe it's just for their internal builds and not a supported language. 2 - Chinese, 3 - French, 4 - German, 5 - Italian, 6 - Polish, 7 - Russian, 8 - Spanish, 9 - Dunno/unused? There are entries but each seems to be one of the other languages)

I should be able to get a new version up sometime tomorrow with string support to enable this.

tracktwo commented 4 years ago

Fixed in v 1.4.

jvarnes commented 4 years ago

WOW! First of all you are amazing dude! Legendary find on being able to hook the other file. Nice job :D

Secondly a few notes I've noticed in playing with this for an hour or two:

1) Just as an FYI to anyone perusing this thread in the future - the Research terms/descriptions are stored in LanguageSources[4] not [5] (apparently they flip flopped the last two so I'm guessing LanguageSources[5] is actually I2Languages_Images (which is kind of a useless file at this time anyways... or so it appears)

2) Languages look like they might be defined at the bottom of I2Languages and align with your estimates of what is what:

List`1 mLanguages int size = 10 [0] LanguageData data String Name = "English" String Code = "en" [1] LanguageData data String Name = "Bulgarian" String Code = "bg" [2] LanguageData data String Name = "Chinese (Simplified)" String Code = "zh-CN" [3] LanguageData data String Name = "French" String Code = "fr" [4] LanguageData data String Name = "German" String Code = "de" [5] LanguageData data String Name = "Italian" String Code = "it" [6] LanguageData data String Name = "Polish" String Code = "pl" [7] LanguageData data String Name = "Russian" String Code = "ru" [8] LanguageData data String Name = "Spanish" String Code = "es" [9] LanguageData data String Name = "UI_Tester" String Code = ""

I'm guess UI_Tester is for internal testing...

3) Sorry to be dense, but should string support extend to other random bits as well?

I tried this without success, but I probably have it bassackwards like in my other thread:

{
    "guid": "4ff1ceb8-4e30-9194-d8e6-0dcfd68c2e03",
    "field": "Soldiers[657].Name",
    "value": "steve",
"comment": "Benjamin Ghost Ghastly ",
"comment": "taken from --->  BackersSoldierDbDef "
}

Not super important as most things are properly localized in the main 5 language files. (Personally though I would love to update the backers and swap out some names and nicknames)

4) Did you sneak in a fix LOL? I was using Jake's little hack of removing the Festering Skies image on the new game screen to tell if anything borked during load, but now it seems PPDef ignores invalid entries which is great ;)

tracktwo commented 4 years ago

If I had to hazard a guess, the UI_Tester language probably holds the language with the longest number of characters for each entry, and is used to make sure the text doesn't overflow the UI elements in the game.

Another interesting find is that the game can populate the translations from a google spreadsheet. This is disabled in the shipped defs (the sheet URIs are all there, but the keys needed to access them are not included). It looks to be part of their internal workflow to fetch the translations from a central source. In theory could be useful for fan-translations to unsupported languages.

for (3) it should work. Are you testing this with an existing save where the soldier already exists? I wouldn't expect modifying the def to change the name of an existing soldier, since those can be customized. I would expect this kind of change to only take effect when soldiers are newly generated. If you can force-spawn a particular backer soldier (maybe through console?) and it isn't respecting the def change then there might be a bug, though.

(4) I did make a small fix to error-handling so that if one particular def fails to apply it will bail on it and log the failure but it should keep trying others.

jvarnes commented 4 years ago

I was indeed testing this with already generated soldiers so your point is very valid ;)

I do think though there may be a maths issue with something as all of the higher end terms I try to change in an index do not in fact change :/

An easy to test example is hero difficulty:

{ "guid": "48cc3f00-fc67-cca4-ea6f-9cc0c0377f4c", "field": "LanguageSources[0].mSource.mTerms[1570].Languages[0]", "value": "COMMANDER", "comment": " HERO ", "comment": " Taken from ---> i2Languages " }

Other ones that I tried included the Cypher pistol name and description and the Tooltip for "Aircraft under Phoenix Point control"... however any string with an index under 100 that I tried DID change so I could mess around with most tooltips and the research stuff for atmospheric analysis, etc.

Is this a 255 limit on lists or something (integers?) ? I only half know what I'm talking about and just tossing ideas out...

tracktwo commented 4 years ago

HERO is index 1574 in my version of the files, and works when I change it (1570 is "SOUND FX"). What are you using to dump the list of strings?

jvarnes commented 4 years ago

Oh wow. I wonder if the indexing changed the last hotfix patch? I dumped them using Asset Studio, but the file date is 3/20 and I think the hot patch came out the day after...

Yeah I just redumped the language file and get the same index as you.

Oof that's going to suck if it gets reindexed all the time :(

I'll check the others as well (like my soldier name), but I'll bet that's the problem I had...

tracktwo commented 4 years ago

Yeah if they add new entries anywhere except at the end of the list it'll break these kind of mods every time they change things in a patch. That's unfortunately par for the course with the game being updated regularly and no official mod support meaning they aren't taking particular care to maintain backward compatibility.

Previous patches have broken other people's ppdefmodifier files when certain things were reworked in a different way or just outright removed. I expect that will continue, especially on big patches that accompany the DLCs. DLC patches were a major headache that often broke a lot of stuff when I worked on Long War 2.

jvarnes commented 4 years ago

Yep I just compared the two dumps and they added a few things for Blood and Titanium DLC and that threw the index off by a few numbers.

LOL oh well that's bound to happen each time new DLC drops then.

Headaches I've shared in other games as well. Part of the reason I gave up on Far Cry mods as I grew tired of having to redo things everytime Ubi updated the games.

Thanks for the pointers!