Help!

[Wounded_Lion]

I coded the following:

 

COPY_EXISTING ~AR0600.are~ ~override~
READ_SHORT 0x5a "numbertriggers"
READ_LONG 0x5c "triggersoffset"
FOR ( index = 0; index < "%numbertriggers%"; index = index + 1 ) BEGIN
 READ_ASCII ("%triggersoffset%" + ("%index%" * 0xc4)) "triggername"
 PATCH_IF "%triggername%" STRING_COMPARE ~Back to outside info~ THEN BEGIN
  WRITE_ASCII ("%triggersoffset%" + ("%index%" * 0xc4)) ~TRAN0700~
  WRITE_SHORT ("%triggersoffset%" + ("%index%" * 0xc4) + 0x20) 0x2 /* Type of Point = 2 = Travel Trigger */
  WRITE_ASCII ("%triggersoffset%" + ("%index%" * 0xc4) + 0x38) ~AR0700~ /* Destination Area = AR0700 */
  WRITE_ASCII ("%triggersoffset%" + ("%index%" * 0xc4) + 0x40) ~EXIT0607~ /* Entrance Name = EXIT0607 */
  READ_BYTE ("%triggersoffset%" + ("%index%" * 0xc4) + 0x60) "flags1"
  READ_BYTE ("%triggersoffset%" + ("%index%" * 0xc4) + 0x61) "flags2"
  WRITE_BYTE ("%triggersoffset%" + ("%index%" * 0xc4) + 0x60) ("%flags1%" BOR "0b00000100") /* 'Party required' Flag */
  WRITE_BYTE ("%triggersoffset%" + ("%index%" * 0xc4) + 0x61) ("%flags2%" BOR "0b00000010") /* 'Cannot be passed by NPC' Flag */
  SAY ("%triggersoffset%" + ("%index%" * 0xc4) + 0x64) @201 /* Info Point Text = @201 */
 END /* PATCH_IF */
END

 

It seems to work as it should except that:

 

PATCH_IF "%triggername%" STRING_COMPARE ~Back to outside info~ THEN BEGIN

 

always returns true. What gives? It should match only triggers with that name...

 

EDIT: To clarify, the check always returns true and patches all triggers in the area.

 

 

- D

[Grim Squeaker]

PATCH_IF "%triggername%" STRING_COMPARE ~Back to outside info~ THEN BEGIN

 

Okay this is a common situation that occurs because (and no offense intended) you didn't read the documentation.

 

STRING_COMPARE is like a standard compareTo() method that you see in various programming languages. It returns a number <0 if the first object is 'less than' (whatever that means) the second onject, 0 if they are equal and a number >0 if the first object is 'greater than' the second object. So to check if two strings are equal you do:

 

~%A%~ STRING_COMPARE ~%B%~ = 0

 

To check they aren't equal you do:

 

~%A%~ STRING_COMPARE ~%B%~ != 0

 

Now a lot of non-programmers found this confusing so the bigg coded up STRING_EQUAL, which works in the way you'd expect (it returns 1 i.e. true if the two strings are the same, 0 i.e. false otherwise).

 

So in your case you want:

 

PATCH_IF "%triggername%" STRING_EQUAL ~Back to outside info~ THEN BEGIN

[Wounded_Lion]

Thank you, Grim!

 

I did read the docs (v185 readme). I just didn't 'get it', I guess. Thanks for the pointer! You're pretty damn good at explaining things.

 

- D

[CamDawg]

STRING_COMPARE is like a standard compareTo() method that you see in various programming languages. It returns a number 0 if the first object is 'greater than' the second object.

I believe it's based on the actual ASCII values (or some sum thereof) of the characters in the strings. You can use greater than and less than string compares meaningfully--for example, I use them in a crude 'bubble sort' to put the HLA tables for Divine Remix in alphabetical order.

[Wounded_Lion]

Noooooooooooooooooooooooooooooo!

 

I tried:

 

PATCH_IF "%triggername%" STRING_EQUAL ~Back to outside info~ THEN BEGIN

 

and:

 

PATCH_IF "%triggername%" STRING_COMPARE ~Back to outside info~ = 0 THEN BEGIN

 

but neither version returns the appropriate match. Help?

 

EDIT: To clarify, the check returns false and does not patch any triggers in the area.

 

 

- D

[Grim Squeaker]

STRING_COMPARE is like a standard compareTo() method that you see in various programming languages. It returns a number <0 if the first object is 'less than' (whatever that means) the second onject, 0 if they are equal and a number >0 if the first object is 'greater than' the second object.

I believe it's based on the actual ASCII values (or some sum thereof) of the characters in the strings. You can use greater than and less than string compares meaningfully--for example, I use them in a crude 'bubble sort' to put the HLA tables for Divine Remix in alphabetical order.

 

Lexigraphical ordering, I believe.

 

Wounded Lion: Try getting it to PRINT (or PATCH_PRINT or something) the current "%triggername%". Then you can compare them manually just to check it's not some silly error.

[Wounded_Lion]

Okay. The issue causing this problem is that READ_ASCII defaults to 8 characters (or bytes).

 

So I tried:

 

READ_ASCII ("%triggersoffset%" + ("%index%" * 0xc4)) "triggername" 20

 

and:

 

WRITE_ASCII ("%triggersoffset%" + ("%index%" * 0xc4)) ~TRAN0700~ 20

 

but received a parsing error. According to the WeiDU readme, shouldn't I be able to specifiy the amount of characters/bytes to read and write? Why isn't it working?

 

EDIT: To clarify, the first code should read 20 characters/bytes. The second code should write the string plus as many null characters as needed to fill the specified 20 characters/bytes.

 

Also: This is a very useful feature (if it works) because it is supposed to automatically place null characters in any unused space (and thus can be used to overwrite long names with short names without any "use a text editor to embed null characters" stuff involved).

 

- D

[Grim Squeaker]

Ah, I assume the problem is that the offset doesn't contain the string, but a strref number for the string. What I think you want to do is read that number, then use:

 

READ_STRREF offset variable  [ ELSE string  ]

 

That way you can get at the string itself instead of just it's number.

 

Edit: No wait, maybe I'm reading the docs wrong. I think you just directly use READ_STRREF and the offset is the position in the current file that you want to grab the number from.

 

Edit #2: Yeah, that's right. GET_STRREF takes a number in the dialog.tlk as it's input. READ_STRREF use an offset in the current file.

[Wounded_Lion]

No, I don't think that the name of the trigger is a reference to a string. It seems to be an actual string. I'll check it again, but I'm almost certain of it.

 

The parsing error is a problem with the line immediately following the code in question. It almost seems as if WeiDU thinks that I didn't finish the READ and WRITE commands... but they seem complete to me...

 

EDIT: Is it possible that the extended versions of READ_ASCII and WRITE_ASCII cannot be used inside of a FOR loop? Some commands seem to behave in such a fashion... I had to use PATCH_PRINT for debugging because PRINT would not work inside of the FOR loop.

 

Help?

 

 

- D

[NiGHTMARE]

With READ_ASCII, the value at the end needs to go in brackets, i.e.

 

READ_ASCII ("%triggersoffset%" + ("%index%" * 0xc4)) "triggername" (20)

 

 

With WRITE_ASCII, the value needs to go after a #

 

WRITE_ASCII ("%triggersoffset%" + ("%index%" * 0xc4)) ~TRAN0700~ #20

[Wounded_Lion]

YES! YES! YES!

 

<offers up a sacrifice to the modding god NiGHTMARE>

 

Thank you! I appreciate your help. The WeiDU readme isn't clear on that bit of syntax.

 

EDIT: btw, it worked! lol.

 

 

- D