Post reply

Warning: this topic has not been posted in for at least 120 days.
Unless you're sure you want to reply, please consider starting a new topic.
Name:
Email:
Subject:
Message icon:

Verification:
Type the letters shown in the picture
Listen to the letters / Request another image

Type the letters shown in the picture:
What color is grass?:
What is the seventh word in this sentence?:
What is five minus two (use the full word)?:

shortcuts: hit alt+s to submit/post or alt+p to preview


Topic Summary

Posted by: Wisp
« on: November 08, 2010, 03:25:57 AM »

but SET $array(a %b% c)=d failed the last time I've tried it.
You need to quote (or wavy-line) %b%. You can index an array with e.g. $array(a b) (if you don't need variable substitution etc).
Posted by: the bigg
« on: November 07, 2010, 07:04:04 PM »

Yes, I'm ashamed of how variables and strings are handled in WeiDU. No, I can't fix those oddities - Refinements (and, most likely, other mods too) was hand-crafted by a more naive myself to make sure that it essentially depends on every little exception in the string handling code.
Posted by: GeN1e
« on: November 07, 2010, 06:49:39 PM »

Last I checked, there were some statements that require both %% and quotes around variables, like STRING_EQUAL. Otherwise, it reads the variable as a string equalling the variable name, rather than the contents of the variable. But yeah, you don't need them in most cases, like the syntax above.
If you the string to be evaluated, then yes, ~%%~ should be used.

Arrays must take either ~%%~ or "%%" for indexes to be evaluated, and ~~ or "" otherwise.
SET $array("a""%b%"~%c%~)=d will work, but SET $array(a %b% c)=d failed the last time I've tried it.
Posted by: Mike1072
« on: November 07, 2010, 06:26:46 PM »

Last I checked, there were some statements that require both %% and quotes around variables, like STRING_EQUAL.
STRING_EQUAL works on strings.  ~%var%~ is a string containing only the contents of the variable named var.

I thought strings required ~~. Is this also a thing of the past?
~ ~ or " " or ~~~~~ ~~~~~ or the confusing % %.  A string can be declared without using quotes, but such a string can't contain spaces or certain special characters, can't substitute variables, and can't be empty.
Posted by: Echon
« on: November 07, 2010, 04:19:33 PM »

I thought strings required ~~. Is this also a thing of the past?
Posted by: Miloch
« on: November 07, 2010, 04:06:38 PM »

Last I checked, there were some statements that require both %% and quotes around variables, like STRING_EQUAL. Otherwise, it reads the variable as a string equalling the variable name, rather than the contents of the variable. But yeah, you don't need them in most cases, like the syntax above.
Posted by: Mike1072
« on: November 07, 2010, 04:00:42 PM »

The resulting ugliness and extra typing involved with having unnecessary %s and "s around integers should be discouraged.

Use quotes around strings, not around variables.
Posted by: GeN1e
« on: November 07, 2010, 03:10:11 PM »

if an item is found, "%#items%" is set to zero, but the loop continues because the value is never read
:facepalm: I've been such a moron to not take a notice of PATCH_PRINTing even after the match...
Posted by: the bigg
« on: November 07, 2010, 03:09:47 PM »

They became not needed before my time, actually. It's a matter of habit whether you use them or not.

Using them is also nice because you're sure that your tp2 isn't invalidated if one of your variables become a keyword in the tp2 synthax (although you could simply write in lower-case in that case).
Posted by: Echon
« on: November 07, 2010, 03:05:53 PM »

Should I omit "" for integers and %% when reading variables? I am not sure if they were required when I started this FotD update but they were widely used. They seem to have become obsolete since then, however.
Posted by: the bigg
« on: November 07, 2010, 02:59:25 PM »

Here goes.

When you write SET "var" = 5 (or READ_LONG offset "var"), "%var%" (quotes excluded) is associated with 5. When WeiDU tries to convert "%var%" to an integer, it looks up the association for "%%var%%"; since none is found, then it looks up the association for "%var%".

READ_LONG associates "%#items%" with the number of items.
WHILE ("%#items%" > 0) operates on the value of "%#items%" ("%%#items%%" is not found)
SET "%#items%" -= 1 reads "%#items%" ("%%#items%%" is not found) and stores the result in "%%#items%%"
from now on, WHILE will read "%%#items%%"
Finally, the macro does its job and sets "%%#items%%" to 0 because it scanned all items (if an item is found, "%#items%" is set to zero, but the loop continues because the value is never read).

Next time the macro is launched,
READ_LONG will set "%#items%" to the number of items
However, WHILE will read "%%#items%%", which is still zero from before, meaning that the loop is not executed and the macro results in a do_nothing().
Posted by: Echon
« on: November 07, 2010, 02:35:14 PM »

Sure.
Posted by: the bigg
« on: November 07, 2010, 02:12:19 PM »

Quote
DEFINE_PATCH_MACRO ~DELETE_PURCHASED_ITEM~ BEGIN
  READ_LONG 0x30 "#items"
  WHILE ("%#items%" > 0) BEGIN
   READ_LONG (LONG_AT 0x2c + ("4" * ("%#items%" - "1"))) "purchaseditem"
   PATCH_IF ("%purchaseditem%" = "%item_to_delete%") THEN BEGIN
     DELETE_BYTES (LONG_AT 0x2c + ("4" * ("%#items%" - "1"))) "4"
     WRITE_LONG 0x30 (THIS - "1")
     PATCH_IF (LONG_AT 0x34 > LONG_AT 0x2c) THEN BEGIN WRITE_LONG 0x34 (THIS - "4") END
     PATCH_IF (LONG_AT 0x4c > LONG_AT 0x2c) THEN BEGIN WRITE_LONG 0x4c (THIS - "4") END
     PATCH_IF (LONG_AT 0x70 > LONG_AT 0x2c) THEN BEGIN WRITE_LONG 0x70 (THIS - "4") END
     SET "#items" = "0"
   END
   SET "%#items%" -= "1"
  END
  SET "purchaseditem" = "0"
  SET "item_to_delete" = "0"
END
The red %% confuses WeiDU. Removing them makes the macro work correctly.

Do you want the in-depth explanation?
Posted by: Echon
« on: November 07, 2010, 02:08:56 PM »

I do not know what it is that fails. To test it I use the macro four times in a row and the code installs without any problems. Only one purchased item has been removed from the STO, though.
Posted by: GeN1e
« on: November 07, 2010, 01:49:01 PM »

Change from MACRO to FUNCTION worked. Is there any particular reason why WHILE wouldn't launch for the second time, despite the condition being true?