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 ai_name 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, none that I know of, 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)

One way to check would be to deliberately initialize a string variable with an end-of-line, and use it to check against the character name received from the TRGV event. Daodan DLL's sprintf would be the simplest way to create a string variable that includes an end-of-line. Or, if sprintf doesn't support \n for some reason, it should be possible to hex-edit a custom name for an AISA character, and then retrieve its name into a string variable using d_name. Then again, I guess it would be easy enough to implement strlen. --geyser (talk) 00:38, 15 May 2020 (CEST)

Hi guys, I saw this page and got interested in the topic.
I tried to run some tests and did some runtime memory probing.
See BSL:String comparison for results.
--Loser (talk) 20:54, 17 May 2020 (CEST)

It doesn't resolve the current situation but it is a help nonetheless and kills some headache about bsl scripting.... If someone really needed to he can use your work as foundation. Thanks you Loser for looking into this. --paradox-01 (talk) 08:59, 18 May 2020 (CEST)