GZDoom v3.8.0 and Strife: Localization strings missing!

[ShockwaveS08]

I noticed a major bug regarding GZDoom v3.8.0 Vintage and Strife: When talking to anyone in the game, signs of missing localization strings show up instead of normal dialogue.

How to reproduce: Just talk to any interactable NPC, and the issue will persist, 100% of the time.

My guess as to why this is hapening is because of the way v3.8.0/v4.0.0+ handle their localization strings. Rolling back to v3.7.2 Vintage fixed the issue immediately.

[Graf Zahl]

To clarify: If the new localization content is not being used, all replacement logic for script-based text and label synthesizing needs to be removed for both ACS and conversations.

[drfrag]

I've investigated it and the problem appeared since "- exported all texts from Strife's dialogues to the string table." and then after "Only replace Strife dialogue content if the default strings from zd_extra.pk3 are present. If not, use the dialogue file's content directly." they still don't work.

I don't see why it doesn't work, the strings are there in '\wadsrc_extra\static\language.enu'. Besides the Level abstraction it's the same code as in master.
I've missed something but i don't know what's going on. There was still no csv spreadsheet at that time.

[Graf Zahl]

You have to remove all code in there that tries to check the string table, unless you add all relevant content to language.enu. If the texts are present, there must be a label mismatch

[drfrag]

No, these two are for those in the screenshot:

Code: Select all

TXT_RPLY0_SCRIPT02_d69736_SUREW = "Sure, why not.";
TXT_RPLY1_SCRIPT02_d69736_NOTHA = "No thanks.";

Besides if they were not present in theory the dialogue file would be used instead.
Edit:
This one works:

Code: Select all

TXT_DLG_SCRIPT02_d69736_INASM = "In a small world, word travels fast. I hear you just removed some obstacles from your path. Nice work. Are you interested in some more lucrative projects?";

[drfrag]

The labels are indeed different but where do they come from?
Changing 'TXT_RPLY0_SCRIPT02_d69736_SUREW' to 'TXT_RPLY0_SCRIPT02_D69736_SUREW' works.
But at the hospital the game asks for the first one here and the language file contains the second.

Code: Select all

TXT_RPLY1_SCRIPT02_d21224_MEDKI
TXT_RPLY1_SCRIPT02_d21224_MEDIC
TXT_RPLY2_SCRIPT02_d21224_HEALI
TXT_RPLY2_SCRIPT02_d21224_FIELD

Then in ParseReplies:

Code: Select all

		if (name)
		{
			FStringf label("$TXT_RPLY%d_%s_d%d_%s", j, name, pos, TokenFromString(rsp->Reply).GetChars());
			reply->Reply = GStrings.exists(label.GetChars() + 1)? label : FString(rsp->Reply);

			reply->Reply = label; <- does this even make sense?
		}
		else
		{
			reply->Reply = rsp->Reply;
		}

Edit: and deleting that line fixed it, but why does it work in master?

[drfrag]

and deleting that line fixed it, but why does it work in master?

Hey, it's fixed.
I don't know why but "hey if it works it works" (tm).
IMEO someone should go ahead and remove that line from master as well.

[Rachael]

IMEO someone should go ahead and remove that line from master as well.

I don't think it's a good idea to go carelessly deleting the line unless we know what it is for. There could be unintended consequences for doing that, and I'm not too interested in being the reason why some mysterious bug pops up later on.

[drfrag]

Of course i'm no expert . But when there's a conditional assignment and right after it an unconditional one looks like something is wrong.

[_mental_]

This line seems to erroneous indeed. This works in master because FStringTable::exists returns true for these labels. So, two assignments do the same thing twice.

[Rachael]

Ah, I didn't look that closely.

[drfrag]

I.R. very clever.
But now seriously i don't see why it returns false, those strings are in the language file. It should return true right? Seems i missed something.
Edit: it works anyway, i've changed that "No thanks." for something much more offensive and gets replaced so this can be closed now.

[Graf Zahl]

That line should be removed, it's clearly wrong.

[Rachael]

_mental_ has taken care of it.