XML talk:BINA/OBJC/TRGV: Difference between revisions
Paradox-01 (talk | contribs) mNo edit summary |
(there's no strlen() in Daodan AFAIK) |
||
| Line 20: | Line 20: | ||
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). -- [[User:Geyser|geyser]] ([[User talk:Geyser|talk]]) 19:41, 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). -- [[User:Geyser|geyser]] ([[User talk:Geyser|talk]]) 19:41, 14 May 2020 (CEST) | ||
Is there a way / "geyser hack" to count the signs a la length(string)? :D | Is there a way / "geyser hack" to count the signs a la length(string)? :D --'Dox | ||
You mean something to count the symbols/characters/bytes? Well, no, at least not from within Oni's game/console and scripts. Neo or the Daodan folks would be able to help, but I have never had the patience to look at Oni's ASM myself. I am pretty sure that the problem is a trailing end-of-line, though. --[[User:Geyser|geyser]] ([[User talk:Geyser|talk]]) 22:37, 14 May 2020 (CEST) | |||
Revision as of 20:37, 14 May 2020
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 --'Dox
You mean something to count the symbols/characters/bytes? Well, no, at least not from within Oni's game/console and scripts. Neo or the Daodan folks would be able to help, but I have never had the patience to look at Oni's ASM myself. I am pretty sure that the problem is a trailing end-of-line, though. --geyser (talk) 22:37, 14 May 2020 (CEST)