Mission briefing missing text / incorrect formatting

[cyanea-bt]

Describe the issue

Edit: Leaving this post as is but take note that the issue was solved in the meantime and it is NOT related to localizations.

Found a bug that (I assume) only happens in some localized versions. Can only verify German (bugged) and French (not bugged). Upon starting any mission, the mission briefing header/title is missing text. The briefing body/text is also formatted differently when compared to the original executable.

Mission end screens/titles seem to work fine though.

Expected behaviour
No text should be missing. Formatting should (probably?) match reference from original executable.

Steps to reproduce
Always happens, no special setup needed. Game version is DRM-free re-release.
If you need logs to figure out the cause, just let me know how to produce them.

Additional information

• Level: Any (tested multiple tutorials and first campaign mission)
• Graphics fix: dgVoodoo2_82_5
• Using mods: None

---

German version (bugged):
original:

v0.0.0.7-hotfix1:

latest commit(2f6743c):

---

Mission end screen (mission 1):
original:

openlrr:

---

French version (no bugs):
original:

v0.0.0.7-hotfix1:

latest commit(2f6743c):

[cyanea-bt]

Edit: Read the next post, this one is most likely irrelevant.

---

Testing suggests that this issue is caused by Gods98::Font_GetStringWidth
Changing lines 288-292 in Objective.cpp from

const uint32 strWidth = Gods98::Font_GetStringWidth(legoGlobs.fontBriefingHi, title);
/// TODO: We could refactor this to cast strWidth to a float before diving by 2, that way two 0.5's can add up to 1.
Area2F newTitleArea = titleArea;
newTitleArea.x += (titleArea.width / 2.0f - static_cast<real32>(strWidth / 2));
newTitleArea.width = static_cast<real32>(strWidth);

To

const uint32 strWidth = Gods98::Font_GetStringWidth(legoGlobs.fontBriefingHi, title);
/// TODO: We could refactor this to cast strWidth to a float before diving by 2, that way two 0.5's can add up to 1.
Area2F newTitleArea = titleArea;
newTitleArea.x += (titleArea.width / 2.0f - static_cast<real32>(strWidth / 2));
newTitleArea.width = static_cast<real32>(strWidth + 0.1f);

will 'fix' the briefing title. Obviously more of a bandaid than a solution. Also briefing body/text formatting is still unsolved.

---

openlrr with modified newTitleArea.width:

[cyanea-bt]

Further testing suggests that the issue isn't inside Gods98::Font_GetStringWidth. Replacing calls to various functions inside Fonts.h/Fonts.cpp with calls to the original executable's functions did not resolve the issue.

Instead it seems like the issue stems from Gods98::TextWindow_Update. Replacing this function with a call to the original one fixes both the missing/cut-off title and the text/body formatting issues.

My branch for reference: cyanea-bt@c8df4ea

---

original lrr:

openlrr with original TextWindow_Update:

[cyanea-bt]

Alright, I figured it out.
Stepping through TextWindow_Update in VS Debugger I noticed that all the lines, where the line splits don't match with the reference from the original executable, have one thing in common. They get split up at the wrong word/letter because their currWidth is equal to windowSize.width and the corresponding if-statement checks for greater or equal:

if (currWidth >= window->windowSize.width) {
	// Check to see if the word is longer than the line
	if (wordWidth >= window->windowSize.width) {
		// If so, split the word onto the next line
		window->lineList[window->usedLines] = loop;
		lineWidthList[window->usedLines-1] = currWidth-charWidth;
		window->usedLines++;
		currWidth = charWidth;
		wordWidth = charWidth;
	} else {
		currWidth = wordWidth;
		window->usedLines++;
	}
}

e.g. the title area's windowSize.width is 201

Einsatzbesprechung

The German word for "mission briefing" also has a width of exactly 201.
So in the current implementation it gets split up at the last letter (the one that hits the limit), resulting in only a "g" being visible since the title only shows one line.

Another example, the main text area/body's windowSize.width is 390

Raider-Akademie. Da dies Dein erster

The third line's width is exactly 390. As such the word that hits the limit (the last word - "erster") gets shifted to the next line, which is wrong when compared to the reference and also messes up the line split of the next line.

---

Changing the condition to only split on greater than windowSize.width fixes this issue.

if (currWidth > window->windowSize.width) {
	// Check to see if the word is longer than the line
	if (wordWidth > window->windowSize.width) {
		// If so, split the word onto the next line
		window->lineList[window->usedLines] = loop;
		lineWidthList[window->usedLines-1] = currWidth-charWidth;
		window->usedLines++;
		currWidth = charWidth;
		wordWidth = charWidth;
	} else {
		currWidth = wordWidth;
		window->usedLines++;
	}
}

Title and body now look exactly like the reference:

[RingtailRaider]

This may be related to OpenLRR being built on the (second of three) original English EXE(s), so it currently doesn't include proper support for any possible modifications in different language releases (I assume the German version has this modification built in). Adding these is planned from what I remember, though this project has been on hiatus for a long time.

[cyanea-bt]

The executables for German/French/English (the versions I've tested) don't differ. I am positive that this issue was in fact just a small oversight in OpenLRR's codebase. If you take a look at my linked PR, you'll see that it was a pretty simple fix.

If you want to see for yourself, you can look at lego::front::TextWindow_Update and lego::front::TextWindow_UpdateOverlay in the LRR source dump. Either way - it simply didn't bother anyone until now since most people won't sit around and A/B test the line splits on some mission briefings.