OniGalore - User contributions [en]

XML talk:BINA/OBJC/TRGV

2020-05-17T18:54:31Z

Loser: Added link to the article about BSL string comparison.

==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. --[[User:Paradox-01|paradox-01]] ([[User talk:Paradox-01|talk]]) 12:12, 14 May 2020 (CEST)

Can someone describe the bug in more detail so I can take a look? --[[User:Geyser|geyser]] ([[User talk: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?) --[[User:Geyser|geyser]] ([[User talk: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. --[[User:Paradox-01|paradox-01]] ([[User talk: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.) --[[User:Paradox-01|paradox-01]] ([[User talk: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). -- [[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 --'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. --[[User:Geyser|geyser]] ([[User talk: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'''. --[[User:Geyser|geyser]] ([[User talk: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. 
--[[User:Loser|Loser]] ([[User talk:Loser|talk]]) 20:54, 17 May 2020 (CEST)

BSL:String comparison

2020-05-17T18:49:08Z

Loser: Let's trample some hopes...

==Summary of this page==
Even though the topic is a bit convoluted, the general information is that [[BSL]] does '''not''' reliably support string comparison. 
It is strongly advised to '''not''' rely on string comparison in BSL scripts.

==Topic==
As a lot of BSL scripters already know, BSL seemingly allows string comparison, meaning it looks like BSL should be capable of processing syntax similar to the following one: 
<pre>
func void some_ai_died(string ai_name){
if (ai_name eq "A_t48") {
dmsg("A_t48 died!");
}
else {
dmsg("Some other AI died!");
}
}
</pre>

However, string comparison appears to be a bit unreliable - sometimes it looks like it works, sometimes it does not. 
But why? The following research is an attempt to find the answer.

==Test setup==
A test was set in the 1st savepoint of the EnvWarehouse level.

The test comprized of: 
# A test subject ("A_t48" ai2 character) and its slightly modified death function t48_dead(string ai_name).
# A global BSL string variable "BOB_string".
# A lot of wasted time while searching for all those damned addresses ^_^.

The test was set as follows:
# There is a global BSL variable "BOB_string". Init value of the variable is a BSL string literal "A_t48". The variable can be set via custom BSL functions to represent one of these BSL string literals: "A_t40", "A_t41", "A_t42"
# There is a BSL function ''t48_dead(string ai_name)''. The function is called by engine when the ai2 character "A_t48" dies.
# Inside the BSL function t48_dead(), there is an immediate comparison of '''ai_name''' and '''BOB_string'''.
# After cca 5 seconds, BOB_string is set to be the same as ai_name and another comparison attempt is made.

==Test results==
Please see the enclosed series of figures.
Figures show a relevant selection of Oni application runtime memory data.

# Data regarding global BSL variable '''BOB_string'''. 
#: [[Image:BSL-strcmp-01 gbStrVar-Ptr.png|256px]] [[Image:BSL-strcmp-02 gbStrVar-PointedMemory.png|256px]]
# Data regarding local BSL variable '''ai_name'''. (relevant only during the execution of the t48_dead() BSL fnc)
#: [[Image:BSL-strcmp-03 ainame-Ptr.png|256px]] [[Image:BSL-strcmp-04 ainame-PointedMemory.png|256px]]
# State of runtime memory data at the moment when BSL string 'comparison' got evaluated for the first time (evaluated 'false') and for the second time (evaluated 'true').
#: [[Image:BSL-strcmp-05 comparison-false.png|256px]] [[Image:BSL-strcmp 06 comparison-true.png|256px]]

==Conclusion==
# BSL string data seems to be stored as a C-style string. No additional special characters, simply a stream of bytes till the first 0x00 byte (string terminator).
# If there are several various independent strings which by chance represent a same text (e.g. "A_t48"), then engine keeps separate instances of these strings (no string grouping or any similar techniques).
# For BSL strings, the 'string' BSL datatype does not seem to be a string itself, but it more probably represents a '''pointer''' to the given C-style string.
# When BSL string 'comparison' is attempted, it in fact most probably means that the values of pointers themselves are compared (meaning the addresses are compared), not strings themselves.
# Engine allocates local BSL variables and parameters of BSL functions "on demand" and utilizes a memory area which is not exclusive for BSL strings, but is generally used for various purposes. This point effectively means that address of a local BSL string (think ai_name) can differ based on what happened in the game prior to the string allocation request.

[[Category:BSL docs]]

File:BSL-strcmp 06 comparison-true.png

2020-05-17T17:39:10Z

Loser: Documentation of the Oni engine approach to perceived BSL 'comparison' of C-style strings. Category:Modding diagrams