XML talk:BINA/OBJC/TRGV
Failing string comparison
There is also a bug with DOOR textures. XML:BINA/OBJC/DOOR#tags
We could try to capitalize everything, maybe that helps. --paradox-01 (talk) 12:12, 14 May 2020 (CEST)
Can someone describe the bug in more detail so I can take a look? --geyser (talk) 14:39, 14 May 2020 (CEST)
- Oh, OK, silly me, I should have read the TRGV page to learn about the string comparison bug. However, I don't understand how the TRGV string comparison is related to DOOR textures (DOOR textures are a permanent level setting, nothing to do with BSL - right?) --geyser (talk) 16:20, 14 May 2020 (CEST)
This is what s10k wrote: https://wiki.oni2.net/w/index.php?title=XML%3ABINA%2FOBJC%2FTRGV&type=revision&diff=26530&oldid=26524
Basically "String" eq "String" returns false when one expression is delivered by TV and one expression delivered from a 'native' BSL variable.
Maybe the comparison fails because at some side (left or right) the string is made toUpper. We have seen a similar bug when the engine reads texture names.
So the idea is that "STRING" eq "STRING" might work, just maybe. --paradox-01 (talk) 16:25, 14 May 2020 (CEST)
The analogy to Doors would be that "String(fromCJBO)" eq "String(fromTextureFileName)" fails because of the bugged comparison. (The code for comparison might be used at both locations - BSL and Door.) --paradox-01 (talk) 16:26, 14 May 2020 (CEST)
To check the toUpper hypothesis, you don't need to change the game data, just test against "CHAR_0". Another thing to do (which I did) is set testVar = ai_name (similar to what is done with my_save_point = save_point in many of Bungie's scripts). I then print testVar (it displays as char_0, both with dmsg and at the dev console, i.e., with no uppercase) and finally check testVar eq "char_0" instead of testVar eq "char_0" (it fails). I also quick-changed char_0 to KONOKO in Konoko's CHAR. And it still fails the same way: both strings display the same value KONOKO, but testVar eq "KONOKO" (or testVar eq KONOKO) evaluates to false (same as for "char_0" before the hack). However, testVar eq testVar, ai_name eq ai_name and testVar eq ai_name all evaluate to true. So I really think it's a non-printable char in the character name as sent from the runtime event (end-of-line most likely). -- geyser (talk) 19:41, 14 May 2020 (CEST)
Is there a way / "geyser hack" to count the signs a la length(string)? :D