Closed krzychu124 closed 2 years ago
Looks like TM:PE is setting wrong atlas when recalculates buttons. After next rebuild atlas is correct so must be a race condition or a bug in code that decides which atlas it should take
The menu rebuild is triggered by checkbox event handlers which call OptionsManager.RebuildMenu();
internal static void RebuildMenu() {
if (TMPELifecycle.Instance.Deserializing || ModUI.Instance == null) {
Log._Debug("OptionsManager.RebuildMenu() - Ignoring; Deserialising or ModUI.Instance is null");
return;
}
Log.Info("OptionsManager.RebuildMenu()");
ModUI.Instance.RebuildMenu();
// TM:PE main button also needs to be updated
if (ModUI.Instance.MainMenuButton != null) {
ModUI.Instance.MainMenuButton.UpdateButtonSkinAndTooltip();
}
RoadUI.Instance.ReloadTexturesWithTranslation();
TrafficLightTextures.Instance.ReloadTexturesWithTranslation();
TMPELifecycle.Instance.TranslationDatabase.ReloadTutorialTranslations();
TMPELifecycle.Instance.TranslationDatabase.ReloadGuideTranslations();
}
Note - the following should probably only ever be done when language changes?
RoadUI.Instance.ReloadTexturesWithTranslation();
TrafficLightTextures.Instance.ReloadTexturesWithTranslation();
TMPELifecycle.Instance.TranslationDatabase.ReloadTutorialTranslations();
TMPELifecycle.Instance.TranslationDatabase.ReloadGuideTranslations();
@kvakvs does that make sense?
Yeah that second part should be called when language changes - I don't see why it's now/was every time 🤷♂️ I'll check that code 😉
IIRC it was doing that originally so I just kind of left it.
Here's the original code before I stared changing stuff (it used to live in Options.cs
):
Yeah, I've checked original code. All good, but I'll test if it's really necessary. No need to waste time if not needed.
Anyways.... it's a race condition when it comes to issue with UI texture. I need to figure out a better solution
I think the original RebuildMenu()
(and thus my slightly tweaked version) was just a blunt "make sure everything gets updated".
The only 2 times I'm aware of that locales and textures should get updated:
OnAfterLoadData()
to ensure textures are updated post-deserialization (the textures should not be loaded prior to deserialisation IMO)So we could put the texture reload in to a method and only call it when required - vague mockup (needs improvement):
internal static void ReloadLocalisations(bool languageChanged = false) {
if (TMPELifecycle.Instance.Deserializing || ModUI.Instance == null) {
Log._Debug("OptionsManager.ReloadTextures() - Ignoring; Deserialising or ModUI.Instance is null");
return;
}
// relaod whenever language code or road theme changes
RoadUI.Instance.ReloadTexturesWithTranslation();
TrafficLightTextures.Instance.ReloadTexturesWithTranslation();
// only reload if language code changed
if (languageChanged) {
TMPELifecycle.Instance.TranslationDatabase.ReloadTutorialTranslations();
TMPELifecycle.Instance.TranslationDatabase.ReloadGuideTranslations();
}
}
I'm testing this one:
Ok, above code works good enough but there is a regression with regards to priority signs textures. I think we'll need new issue 😕 @aubergine10 @kvakvs I noticed that Chinese version of priority signs is never displayed despite we load textures when changing language. When we should display those modified version if we also have themes (but no Chinese one)?
I noticed that Chinese version of priority signs is never displayed despite we load textures when changing language. When we should display those modified version if we also have themes (but no Chinese one)?
I do not understand, there is no special handling of chinese signs in my theme code. But there is special handling of chinese TTL icons, where special versions of TTL icons for Chinese are loaded. Please make an issue with a screenshot.
Note also that there's two variants of Chinese - zh-cn
and zh-tw
IIRC? Simplified, and Traditional.
Locale is a combination of ISO language code (ZH for chinese) and country code where it is used (CN is for mainland China and TW for Taiwan, there's also SG for Singapore and HK for Hong Kong which we do not see in the game). Don't ask me how ZH means Chinese, probably some hieroglyph meaning China or Chinese transliterates to that and it became accepted by the ISO. Also this means most common Mandarin Chinese but there are a few more variations https://iso639-3.sil.org/code/zho
If lang is zh-cn
(for example) but the filename is just zh
would that cause issue? Maybe there's some code that trims anything from -
so zh-cn
becomes zh
?
Files are loaded correctly, we just don't use them anymore because of introduced themes. There is even [Obsolete] label above both fields holding refs to loaded textures. Everything was "working" before introducing Speed limit themes but now we just need either do an exception for the rule we have or better build a basic theme for Chinese.
I do not think we should localize the signs when a user playing Chinese C:S would switch to another theme. Can we merge these signs or reuse from the existing theme engine? What's exactly not working?
I already explained. Yield and Stop signs as localized Chinese version -> https://github.com/CitiesSkylinesMods/TMPE/pull/1081 I was pretty simple implementation -> when selected Chinese lang, swap signs. Now it does not work since we only have themes and there is no Chinese one. Part for localized Traffic Lights buttons from mentioned PR still works since we didn't touch that.
I don't mind adding Chinese signs or several themes for different lands speaking Chinese. What you think?
If we find textures why not. The more complete set of textures the better.
Describe the problem
See steps below. Investigating... (TM:PE workshop TEST also affected so probably a bug introduced in texture rebuild fix)
Steps to reproduce
Now the fun part
Now the weird part
Log files
Screenshots?
Notes or questions?
It looks like every second rebuild of menu, texture source or whatever is happening there fixes the problem 🤷♂️ Everything works, just textures are missing.