Is it? It looks like a constant that gets referenced locally. If that constant is in the string table or its own separate table I do not know. What I do know was the desyncs in the past were reported around setting special effect model path locally and did exactly what you showed above.It's a global that gets set locally...?
I definitely forgot the string table was a thing. You mean because it's doing something like this internally, the lookup of TRIGSTR_002 vs TRIGSTR_001 causes some sort of local state change and desyncs?constant that gets referenced locally
globals
constant string TRIGSTR_001 = "This text displays for all players"
constant string TRIGSTR_002 = "This text only shows up for the Triggering Player, whomever that was"
//Or maybe they aren't even put into a globals block anywhere but are accessed some other way
string udg_StringVar
endglobals
//later
set udg_StringVar = TRIGSTR_001 //does it point to this location in memory but not take its value, or is udg_StringVar actually set here?
set udg_YourPlayerVariable = GetTriggerPlayer()
if GetLocalPlayer() == udg_YourPlayerVariable then
set udg_StringVar = TRIGSTR_002 //same question here
endif
call MultiboardFuncWhatever(udg_StringVar)
Trigger strings in GUI are resolved from an external file. However they will resolve to a string already loaded in the table if they were loaded before. I believe the desync was caused by the JASS string tables getting out of sync but people were not very clear. It is pretty much one of those cases one has to manually test and see if it breaks.I'm not sure how setting a variable on map init gets around this; ultimately you end up back in the same situation referencing different TRIGSTR_s, don't you?