Your code worked fine in my tests. There might be something else blocking execution of the function. Maybe one of the PATCH_IF conditions doesn't match?
My test script: [spoiler]COPY_EXISTING_REGEXP ~.+\.itm~ ~override~
READ_BYTE 0x26 min_str
READ_BYTE 0x31 prof
// Add this block to read original speed factor from first available launcher ability
READ_LONG 0x64 ofsAbil
READ_SHORT 0x68 numAbil
SET cur_speed = "-1"
FOR (idx = 0; idx < numAbil; ++idx) BEGIN
PATCH_IF ((cur_speed < 0) && (BYTE_AT (ofsAbil + idx * 0x38) = 4)) BEGIN
READ_BYTE (ofsAbil + idx * 0x38 + 0x12) cur_speed
END
END
PATCH_IF ((cur_speed >= 0) && (prof = 104) && (min_str = 6)) BEGIN // longbow
LPF ALTER_ITEM_HEADER
INT_VAR
header_type = 4
speed = cur_speed + 2
END
END
BUT_ONLY
[/spoiler]
About identifying weapon types, you could take equipped appearance into account. It should work for at least some of the weapon types.
One possible way is to find the "unidentified name" of the base composite long bow, and compare it against the unidentified name of other bows....
Yeah, you're right: I must rely on general name (i.e., the unidentified name) if I wanna get the best results... @argent77 However, I don't understand how to use READ_STRREF: after putting READ_STRREF 0x08 gen_name, both gen_name = Longbow and gen_name = 6860 are not the correct way to read the unidentified name.....
READ_STRREF will get you the string, I think. Which means you need to put it inside delimiters and use STRING_EQUAL to compare it.
The problem is that if I write something like READ_STRREF 0x08 Longbow followed by %Longbow% STRING_EQUAL %Longbow%, then WeiDU is not able to distinguish Longbows from Composite Longbows (probably because "Longbow" is also contained into "Composite Longbow".....) -> For the time being I'm using the following code:
As you said, this should work fine provided that items are not already identified (as far as I know, only Kylee's Dagger is not using "Dagger" as general name.....)
READ_STRREF will get you the string, I think. Which means you need to put it inside delimiters and use STRING_EQUAL to compare it.
The problem is that if I write something like READ_STRREF 0x08 Longbow followed by %Longbow% STRING_EQUAL %Longbow%, then WeiDU is not able to distinguish Longbows from Composite Longbows (probably because "Longbow" is also contained into "Composite Longbow".....)
STRING_EQUAL_CASE (and STRING_EQUAL) will compare only whole strings, so comparing ""Composite Longbow"" with "Longbow" will never return true. However, your code example isn't quite correct.
The syntax is ~%Longbow%~ STRING_EQUAL_CASE ~Longbow~ Note tilde and percent signs. Both are required to correctly evaluate string variables. The second operand of STRING_EQUAL_CASE is a literal string (hence no percent signs).
I've seen incorrect usage of the percent sign in many scripts. Most of the time WeiDU will handle it correctly, as percent, double quote and tilde signs are all valid string delimiters, which are allowed to wrap variable names in (i.e. %Longbow% is equivalent to "Longbow" and ~Longbow~.) Btw, numeric variables can be used either with or without quotes, e.g. myNumber >= 1234 is equivalent to "myNumber" >= 1234.
STRING_EQUAL_CASE (and STRING_EQUAL) will compare only whole strings, so comparing ""Composite Longbow"" with "Longbow" will never return true. However, your code example isn't quite correct.
The syntax is ~%Longbow%~ STRING_EQUAL_CASE ~Longbow~
Is the following piece of code equally "powerful"?
Both READ_LONG and READ_STRREF have their own strengths and weaknesses.
Using READ_LONG is less work, since you just have to check a single numeric value. This method works fine even across different game languages. However, you're out of luck if items are use different strrefs for the same string.
READ_STRREF is more flexible, since you can check for the string itself or even different string variations (it helps to know a bit about regular expressions). But it requires some extra work if you want to support more than one game language.
Please look up the READ_STRREF syntax in the WeiDU documentation. It uses basically the same syntax as READ_LONG, except that it returns a string in place of a number. READ_STRREF 0x08 item_name
// Either compare static strings...
PATCH_IF (~%item_name%~ STRING_EQUAL_CASE ~Longbow~) BEGIN
PATCH_IF (~%item_name%~ STRING_EQUAL_CASE ~Long Bow~) BEGIN
PATCH_IF (~%item_name%~ STRING_EQUAL_CASE ~Long-Bow~) BEGIN
// ...or use a regular expression that covers all three examples from above
PATCH_IF (~%item_name%~ STRING_MATCHES_REGEXP ~Long[ -]*bow~ = 0) BEGIN
Comments
LPF ALTER_ITEM_HEADER INT_VAR header_type=4 speed=10Moreover, can I feed "speed" an expression (say speed = speed + 2)?
PATCH_IF (prof = 104) && (minimum_strength = 6) BEGIN // longbow -> speed:9 LPF ALTER_ITEM_HEADER INT_VAR header_type=4 speed=9 END ENDPATCH_IF (prof = 104) && (minimum_strength = 6) BEGIN // longbow -> speed:9 LPF ALTER_ITEM_HEADER INT_VAR header_type=4 speed=9 END ENDMoreover, do you know a smart way to distinguish flails from morningstars, longbows from composite bows and ninjatos from wakizashis?My test script:
[spoiler]
COPY_EXISTING_REGEXP ~.+\.itm~ ~override~ READ_BYTE 0x26 min_str READ_BYTE 0x31 prof // Add this block to read original speed factor from first available launcher ability READ_LONG 0x64 ofsAbil READ_SHORT 0x68 numAbil SET cur_speed = "-1" FOR (idx = 0; idx < numAbil; ++idx) BEGIN PATCH_IF ((cur_speed < 0) && (BYTE_AT (ofsAbil + idx * 0x38) = 4)) BEGIN READ_BYTE (ofsAbil + idx * 0x38 + 0x12) cur_speed END END PATCH_IF ((cur_speed >= 0) && (prof = 104) && (min_str = 6)) BEGIN // longbow LPF ALTER_ITEM_HEADER INT_VAR header_type = 4 speed = cur_speed + 2 END END BUT_ONLY[/spoiler]About identifying weapon types, you could take equipped appearance into account. It should work for at least some of the weapon types.
@argent77 However, I don't understand how to use READ_STRREF: after putting
READ_STRREF 0x08 gen_name, bothgen_name = Longbowandgen_name = 6860are not the correct way to read the unidentified name.....The syntax is
~%Longbow%~ STRING_EQUAL_CASE ~Longbow~Note tilde and percent signs. Both are required to correctly evaluate string variables. The second operand of STRING_EQUAL_CASE is a literal string (hence no percent signs).
I've seen incorrect usage of the percent sign in many scripts. Most of the time WeiDU will handle it correctly, as percent, double quote and tilde signs are all valid string delimiters, which are allowed to wrap variable names in (i.e. %Longbow% is equivalent to "Longbow" and ~Longbow~.) Btw, numeric variables can be used either with or without quotes, e.g. myNumber >= 1234 is equivalent to "myNumber" >= 1234.
Using READ_LONG is less work, since you just have to check a single numeric value. This method works fine even across different game languages. However, you're out of luck if items are use different strrefs for the same string.
READ_STRREF is more flexible, since you can check for the string itself or even different string variations (it helps to know a bit about regular expressions). But it requires some extra work if you want to support more than one game language.
READ_STRREF 0x08 item_name // Either compare static strings... PATCH_IF (~%item_name%~ STRING_EQUAL_CASE ~Longbow~) BEGIN PATCH_IF (~%item_name%~ STRING_EQUAL_CASE ~Long Bow~) BEGIN PATCH_IF (~%item_name%~ STRING_EQUAL_CASE ~Long-Bow~) BEGIN // ...or use a regular expression that covers all three examples from above PATCH_IF (~%item_name%~ STRING_MATCHES_REGEXP ~Long[ -]*bow~ = 0) BEGINFor example, how can I set the Value of an opcode? The following code isn't good
I believe %-1% works as well.
LPF ADD_ITEM_EQEFFECT INT_VAR opcode = 305 target = 1 timing = 2 parameter1 = %-1% // parameter1 is value? END