Some suggestions...

[Psycho-A]

Hi! I'm Wesp's Unofficial Patch tester/helper/co-worker and translator (he might told you about me)...

I looked at your addon and found it quite interesting. First of all, it's good that you're trying to make it language-independent, by using an external ini file.

I also have some suggestions for the addon improvement.

1. Currently, your addon supports only the ANSI 1252 (or 1250?) code page, which stands for basic Latin characters and diacritics only. This means that Cyrillic, East Asian, and other letter layouts don't work. I tried your addon with custom Cyrillic fonts (Russian), where additional pages of characters were added, but they didn't work, displaying some garbage instead of letters. Is it possible to add support for custom layouts and forcing ANSI encodings through your ini file? I've attached an archive with custom Cyrillic fonts (custom chars range is 0xC0...0xFF) - maybe this will help you figure it out. The same thing happens for Unicode UTF-16 too (which is used by gameui_english.txt and inside of .lip files) - I couldn't force to display custom letters in the game interfaces.

2. I saw that your WidescreenUI plugin is compiled with Windows XP support. Is it possible to do the same here? It would be great to keep the native historical game compatibility :)

3. You may have noticed that the windows of the main menu interfaces have a larger font size than inside the game (in the upper subtitles, etc.). This is due to an engine bug related to the parsing of the resource/trackerscheme.res file. This file contains groups of font sizes for each resolution, and you can see entries like "Default_1280", "Dlg_Malk_1024", etc. The number at the end goes to the screen pixel width. The font size in the game is selected based on the calculation of the screen height at a ratio of 4:3 (for example, the section "_1024" will be used if the screen height is "768" pixels). BUT in the main menu, fonts are calculated by the screen WIDTH, not by height. Therefore, a bug on not 4:3 screens, which causes the next section to be taken in size. For example, if our monitor resolution is 1366x768, then the menu font sizes will be taken from the "_1280" sections, not "*_768". And because of this, they turn out much larger than in the game. Is it possible to fix it? This bug is especially noticeable if you run the game with a small widescreen resolution (for example, add -sw -w 1280 -h 720 to the launch parameters of the exe file). Some languages have longer words (than English), and this bug have words cutting, as well as cutting fonts themselves in some resolutions. This forces the use of smaller fonts inside the game, which makes them difficult to read at high wide resolutions.

fonts_cyrillic.zip

[LaZar00]

Hi Psycho-A, yes, Wesp told me you will contact to me. It's a pleasure meet you. Ok, let's see.

1. I had not tought about adding other non-latin languages to localization_addon module. Mainly because the own game is not prepared for that, unless you do something like you translator module to adjust the new unicode chars. Basically, for latin languages (or italian/french/german/spanish), you don't need unicode, you can do everything with ansi/char. In fact, I deleted all the unicode keywords in .lip files and changed them to char. Said this, I'm not sure if you are able to code that, but I have not idea on how I could program the module to accept UTF-8 Cyrillic characters. I never done anything like that, only worked with ansi/ascii chars for retro vintage game translations, only in spanish. I should look at it and how to make it possible with UTF8 Cyrillic without breaking anything as it is now.

But in any case, I thought that your translator module was enough for you, wasn't it? It has embedded the words, and they are in ANSI (but not understandable). That is what you want? Put the words externally in Cyrillic, and that the module do the conversion?

2. Mmm... I changed the flags in Visual Studio to accept also Windows XP. I though it would work. It is not working for you in Windows XP? 3. So, it seems this is the real issue with words cutting, like in dialogues and in subtitles (top left part of the screen). I think you translator module fixes some things about this, because the names of disciplines are wrong displayed with chars over 0x80 (non ascii standard). I can look at this, but I can not promise anything, because probably we will need to follow a bit the code to know where it puts this info. Maybe Niko can help more than me researching this info and then do something in widescreenUI module.

I will try to look at localization module for add Cyrillic. Give me some time, because I'm also testing my spanish translation and would like to finish this second run. Regards, David. <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Libre de virus.www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> El mar, 27 may 2025 a las 10:00, Psycho-A ***@***.***>) escribió:

…

*Psycho-A* created an issue (LaZar00/localization_addon#1) <#1> Hi! I'm Wesp's Unofficial Patch tester/helper/co-worker and translator (he might told you about me)... I looked at your addon and found it quite interesting. First of all, it's good that you're trying to make it language-independent, by using an external ini file. I also have some suggestions for the addon improvement. 1. Currently, your addon supports only the ANSI 1252 (or 1250?) code page, which stands for basic Latin characters and diacritics only. This means that Cyrillic, East Asian, and other letter layouts don't work. I tried your addon with custom Cyrillic fonts (Russian), where additional pages of characters were added, but they didn't work, displaying some garbage instead of letters. Is it possible to add support for custom layouts and forcing ANSI encodings through your ini file? I've attached an archive with custom Cyrillic fonts (custom chars range is 0xC0...0xFF) - maybe this will help you figure it out. The same thing happens for Unicode UTF-16 too (which is used by gameui_english.txt and inside of .lip files) - I couldn't force to display custom letters in the game interfaces. 2. I saw that your WidescreenUI plugin is compiled with Windows XP support. Is it possible to do the same here? It would be great to keep the native historical game compatibility :) 3. You may have noticed that the windows of the main menu interfaces have a larger font size than inside the game (in the upper subtitles, etc.). This is due to a bug in the engine related to the parsing of the resource/trackerscheme.res file. It contains font sizes for each resolution, and you can see entries like "Default_1280", "Dlg_Malk_1024", etc. The number at the end goes to the screen pixel width. The font size in the game is selected based on the calculation of the screen height at a ratio of 4:3 (for example, the section "*_1024" will be used if the screen height is "768" pixels). BUT in the main menu, fonts are calculated by the screen WIDTH, not by height. Therefore, a bug on not 4:3 screens, which causes the next section to be taken in size. For example, if our monitor resolution is 1366x768, then the menu font sizes will be taken from the "*_1280" sections, not "*_768". And because of this, they turn out much larger than in the game. Is it possible to fix it? This bug is especially noticeable if you run the game with a small widescreen resolution (for example, add -sw -w 1280 -h 720 to the launch parameters of the exe file). Some languages have longer words (than English), and this bug have words cutting, as well as cutting fonts themselves in some resolutions. This forces the use of smaller fonts inside the game, which makes them difficult to read at high wide resolutions. fonts_cyrillic.zip <https://github.com/user-attachments/files/20452049/fonts_cyrillic.zip> — Reply to this email directly, view it on GitHub <#1>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK7UOL3W6UZ6JPLELDKFDC33AQLQVAVCNFSM6AAAAAB57IUDG2VHI2DSMVQWIX3LMV43ASLTON2WKOZTGA4TGMBRGA4DQNA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[LaZar00]

About the third point, I'm not really sure the game does what you explained. When I look this part at client.dll:

It seems to select specifically the Font he wants to use depending on the width. But it seems to choose correctly the font (more or less). So, if we have here 1024x768, he will get the Font_1024, if we have 800x600, he well get the Font_800, if we have 1280x???, he will get Font_1280.

What is true, is that if we have 1920x1080 or 1366x768, he will select Default Font (not 1280 or 1600) because that specific width is not added in that part of the code and goes to the Default Font (it is at some few more lines at the bottom, not seen at the image). And this must be wrong.

Are you referring to this?

[LaZar00]

Ok, after talking with Niko, that part seems to not affect the main menu or other texts, only Signs texts. So, that must be discarded.

[Psycho-A]

Thanks for your attention!

As for my own plugin - just liked an idea to use one plugin for most known languages :) Besides, the code of my "translate_helper" is closed (it was written by other man who vanished long times ago) and I can't add any improvements there.

As for Windows XP question - no, it doesn't work, because it imports some native WinNT 6.1+ libraries (api-ms-*, vcruntime140 etc), while your WidescreenUI plugin not (it required them before too, but you've been recompiled it in April, and it doesn't for now - maybe the required code is included into plugin itself).

About the Cyrillic fonts...

The game doesn't use UTF-8, it uses plain ANSI chars and wide UTF-16 chars for its texts. ANSI uses regional chars mappings. It means that single 0xC0...0xFF bytes are used in latin-based countries for various special symbols (diacritic, umlauts), while in Cyrillic countries this range is used for letters "А-Я" and "а-я". The mapping method is regulated by forcing the codepage in the text parsers. For Latin-speaking countries, this is usually ANSI-1252, for Cyrillic ones - ANSI-1251. The fonts I sent you take this into account, but your plugin does not. My suggestion was that by forcing the codepage in the ini file settings, so it would be possible to change these ranges inside of fonts. As for Unicode (UTF-16) - it's still being forcibly used in "gameui_english.txt" file (all game main menu texts), and this needs to be taken into account too.

Regarding the resolution-based font scaling...

No, the scaling methods in the game menu, and in the gameplay internals, are different in practice. If you set the screen resolution to 1280x768, you can see that the fonts in the menu are much larger than inside the game itself. And if you try to change the font size in the "Font_1280" section, the font in the menu will change, but NOT in the game. Because there, for some reason, it is taken from the "Font_1024" section. But if you set the screen resolution to 1024x768, then the font sizes will be equal, both in the game and in the menu. Therefore, my version is that, inside the game, the engine considers the font size by height, not by width. Thus, the height of 768 is always means "Font_1024" section (1024/1.333, the standard 4:3 monitor ratio), regardless of the width of the screen resolution (even if it is 1920). While the menu is the other way around, it doesn't matter what the height of the screen is, because it takes font dimensions by width. Therefore, on wide or ultra-wide screens with low height resolutions, the fonts in the menu look huge and get cropped.

And no, the game doesn't seems to use default font sizes, if actual screen width is not equal standard values (1280, 1600 etc.). I was doing practice tests, and it looks like the engine takes values from the nearest smaller standard value. That is, in the screen resolution range of 1280...1599 (for example, 1366x768), the game menu always takes values from the Font_1280 section, and font sizes are the same during all these tests. And if the resolution is higher than 1600, then the value from Fonts_1600 will be taken. The situation is similar for in-game interfaces, but the nearest values are taken by height (as told above).

[Psycho-A]

P.S. Re-tested font issues again, and seems like all it's true. I set 1680x1050 screen res (non-standard for both dimensions), set "Copperplate" (or "vamp_small") "default" section font size to smallest (11), and there's no any place where it's been used. The game menu still takes size from Copperplate_1600, and gameplay fonts (subtitiles, buttons) used size from Copperplate_1280 (because closest standard height of 1050 is 960 or 1024 which, again, corresponds to 1280 width in 4:3 aspect).

So, this is exactly the thing that needs to be fixed, if it's possible (but it's rather already more related to "WidescreenUI" plugin by its type). Although I prefer the font size selection based exactly on screen height (as inside the game), because it is better for wide screens, where the height can be much less than the width, and with a large width, the texts will not fit vertically due to the large font, which was chosen by horizontal screen width. So the "fix" would be just to make the game menu do the same...

[LaZar00]

Ok, let's go step by step.

1.) I compiled again, changing minor things in Visual Studio, the module localization_addon. I attach it. Please, test it in Windows XP and let me know if it works now. You will have to rename it from .dll to .vtm.

localization_addon.zip

2.) About translator_helper module.

This is the module that makes the conversion from Cyrillic to ANSI chars, that's right. In some place it decreases 0x350 to the Cyrillic chars (0x400-0x4FF) to convert it to byte char and assign one ANSI char. This is the part that I have not been to reverse engineer of the module, and without it, I'm not able to do anything in localization_addon. That's why I asked to Wesp (now to you) the sources.

I added some of the things (the more basic, like do some unsigned int compare to accept chars over 0x80) it changes to vguimaterialsurface.dll, but the code that enables this ANSI<->Cyrillic conversion has been impossible for me to decipher. If I had that code, I could implement it in localization_addon, and we could try something more with the external texts.

I can "implement" (and this is only an assumption), the possibility in localization_addon module, to read the texts (in Cyrillic) in the .ini file, and then do the conversion into ANSI like does translator_helper module, but you WILL ALWAYS need translator_helper module because of the conversion it does directly in the .dll for other texts. And as that module has also some of the texts localized into russian (byte encoded), I'm not sure if you would get any benefit from localization_addon module.

Apart of it, depending on which module has the priority (I think in this case would be translator_helper for being the last one on read by the system), that priority will set from which module the texts will be chosen. Remember that the module overwrites the addresses to point the own texts of the module.

Besides of all this, I don't know why you mention "gameui_english.txt". I have not touched anything of it in my modules. But maybe translator_helper does something, and it is in the portion of code that I have not been able to decipher. Who knows...

3.) The font-scaling issue

Yesterday, I looked at the code trying to find where it must set the fonts, for main menu at least, of the game, but I had not success. There are other modules to look at, like GameUI, but it is a bit difficult to see something related to this. The only place I see something interesting was in the screenshot I uploaded, but it seems that addresses correspond to the Signs font texts.

The only thing that I can say right now, is that for modding my spanish version, that I decided to focus the best result with a resolution of 1920x1080, I had to modify Font_1280 sections to take effect. I can assure you that I have not touched Font_1600 sections for this. I have even modified some of the fonts fixing some wrong special chars over 0x80.

I'm not sure that I can solve this aspect ratio thing. Maybe with more help, but this is being a bit difficult.

[Psycho-A]

Hello again!

I tested your recompiled build, and now it works fine under Windows XP, many thanks!

About Cyrillic support... I've read your notes, and if it's so complex, I just suggest you to drop the worries about that. My "translator_helper" plugin initially works fine side by side with your one, as well as the Cyrillic fonts in .ini, so I can use it just to improve some minor things. Although I noticed some hardcoded Spanish words due to making savegames (quick and manual) in the save list menu, so if you find it, better to move them into .ini file too...

The same about font-scaling. Just forget it in that case :) I already tweaked it for myself via DLL, to make the alternate fonts copies with other sizes layout specially for menus. The only thing I can say - it's definitely inside of gameui.dll file. There's font calls from game client dlls, and there's separated calls from gameui.dll, and seems like specially for game menus. Looks like Torika did their own code for the game, while gameui.dll uses the common rules for Source Engine/GoldScr from Valve's legacy.

[LaZar00]

Thanks a lot for the report on the module working with WinXP. I updated github.

Theorically, as both modules must access the same memory addresses they should work, but I'm not sure which one has priority. I understand that you can use ANSI chars among 0xC0 and 0xFF and you will be able to use Cyrillic font. Supposedly this is not understandable in the .ini, but I understand that you have some method to check the correct spelling.

I have nothing hardcoded. In case of Autosave or Quicksave translated words, they are in the .ini also for translation:

The only reason they appear in english, is because this keywords are not found or they are not enabled in the .ini.
Remember that this words/lines (Autosave or Quick Save) are written in the save file once you save a game (or the game creates an autosave). You should change also this texts to your Cyrillic versions.

Yeah, the use of a lot of different .dlls is a bit of a mess when you try to change something. If I have time, I will try to check some more things. Wesp told me about a bug there is with Histories also, and I have not luck either trying to find something.

Regards.

PD: Wesp has asked to me if it would be possible for you (or someone you know) to create the .PHY file for the model of the rat (for rat.mdl). He says this model has a bug when the ragdolls despawn flag is enabled.

PD2: In case you need, I updated localization_addon, with the point 'm', adding the 'quit' word we use in the .ini for KEYPADS. If not, you get stuck.