The documentation says that LISOI outputs the given number in case it does not find the requested entry.
The following code:
LOOKUP_IDS_SYMBOL_OF_INT test ~ea~ 3
PATCH_PRINT ~%test%~
LOOKUP_IDS_SYMBOL_OF_INT test ~missile~ 3
PATCH_PRINT ~%test%~
LOOKUP_IDS_SYMBOL_OF_INT test ~projectl~ 3
PATCH_PRINT ~%test%~Outputs
FAMILIAR
3
ARROWFLM
which means it has not found the 3rd entry in MISSILE.IDS, even though my MISSILE.IDS does contain:
3 Arrow Exploding
Could the problem arise from the presence of spaces in the entry? The code actually also fails to retrieve the first entry, which is not "anomalous".
The reason why I'm using that command is that projectl.ids and missile.ids are biased by one entry, and opcodes (such as 83) use the latter while extended headers use the former (or perhaps vice versa).
I'm using v231
PS: besides, I've noticed that trying to re-align the two files (for instance by adding a row to projectl.ids) results in ADD_PROJECTILE skipping a row on the other one and keeping the two values biased by one.
I find this confusing, because it means that the variable returned by AP is only correct for some uses; could nothing be done to either directly fix this anomaly (but it could break backwards compatibility) or at least see if the bias has been fixed by other mods and, if that's the case, not reintroducing it?
Another option could be a tp2 flag (which, only in case AP is called, aligns the ids files to a common value if present and to values differing by one if absent); installing mods with and without the flag could result in some extra "unknown" projectile entries but would allow new mods to work on "aligned" projectl and missile ids filesNevermind; perhaps, since the two files are always shifted by one, keeping them like that is better; otherwise, it would be too confusing having to treat vanilla and custom projectiles differently. Besides, the bias could even be hardcoded.
But I suggest that this vanilla game anomaly should be pointed out in the Weidu Documentation. For instance:
LOOKUP_IDS_SYMBOL_OF_INT variable idsFile value
The symbolic constant associated with value in idsFile (which may contain user variables) is stored in variable. If that doesn’t work, value is stored in variable. Example:
LOOKUP_IDS_SYMBOL_OF_INT foo ~spell~ 1101
SPRINT myfile "SPELL"
LOOKUP_IDS_SYMBOL_OF_INT bar ~%myfile%~ (0x44c + 1)
LOOKUP_IDS_SYMBOL_OF_INT baz ~spell~ 77777
Both foo and bar are CLERIC_BLESS while baz is 777777.
Add to description something like:
Due to an anomaly in the original game, projectiles are stored in two different files (missile.ids and projectl.ids), and their index in the latter is lower by one then the one in the former. Moreover, missile.ids does not always contain the file name of the .pro, but sometimes contains a description.
Extended headers use missile.ids to code the projectile type, whereas opcodes dealing with .pro files use projectile.ids. For this reason, when reading an extended header, you must use LOOKUP_IDS_SYMBOL_OF_INT somevar projectl (%value%-1).
Or just add a specific tutorial covering ADD_PROJECTILE, IDS_SYMBOL_OF_INT and IDS_OF_SYMBOL.
Other caveats:
ADD_PROJECTILE ~name.pro~ sets %pro% to the
MISSILE ID of the newly created projectile. So, if you want to assign a newly created pro to an opcode (EG 83, immunity from specific projectile), you must use (WRITE or INT_VAR or whatever you're using), for that purpose, (%name% - 1).
Finally, if you want to change projectile to an extended header (using an already existing one), you must use (IDS_OF_SYMBOL (projectl ~name~) + 1), in order to write the correct reference to MISSILE.ids.
I believe these are all the cases in which you have to add or subtract 1; in all other cases, the value read from ids files/provided by ADD_PROJECTILE shouldn't be modified.
Topic: LOOKUP_IDS_SYMBOL_OF_INT fails on MISSILE.ids and other projectile quirks (Read 1565 times)
