TFS 0.X Raids misfiring

[Dries390]

Hello again everyone,

I wrote a script recently which uses the raids system (TFS 0.3.6 (8.60) V8.2) to spawn loot-filled chests in an area. Using the "raids timer" an event is initiated which spawns a chest in one of some pre-determined spaces if none has been spawned yet and skips spawning one if there -is- a chest already in one of the spaces. This system actually worked quite beautifully and I could probably do a tutorial if someone could help me fix the problem I ran in to. Seeing as it worked for one cave (Gallywain troll cave in this example) I decided to simply copy the entire script, making the neccesary changes, for it to also work in another area. The problem is now that, with both raids in the raids system, the first stops working. Chests no longer spawn in the first cave. The second cave works perfectly just as before with the chests spawning in one of five random locations. Additionally, firing up the first raid does produce a chest but in the second cave. It also contains loot specifically designated to the second area so I assume the scripts are interfering somehow. I've added a picture with the xml entries and .lua files and designated what I think the flow of the program should be (purple + orange arrows) and is going wrong (red arrow). I confirmed the first xml runs the second second .lua by adding doBroadCast statements to both.

I'd appreciate if anyone could try and help me solve this because I think it introduces a nice dynamic effect to hunting areas and such in what I thought was a not-too convoluted way.

Edit: I also add that all other raids, at least at the last time of testing, worked just as intended.

Edit2: One may notice I accidentally only have one position in the second .lua script. Re-adding the other locations, both raids place random chests in -one- location. This reduces the essential question to: Why do both xml files activate the same script?

 

[Dries390]

I have done some more extensive testing in the meantime and apparantly the bug cannot be located in my script itself. Using a larger amount of rudimentary scripts it would seem that for a given amount of raids involving scripts only the last one will ever be activated. As an example consider three "raids" which each spawn an item X,Y and Z. Activating the raids for X,Y and Z will only ever produce items Z. From this I can only conclude that either my understanding of the onRaid() function is severely lacking or there is some bug hidden in the sourcecode, any further sort of help would be nice on this issue.

 

[Dries390]

For those interested in the resolution, I have come up with an , at least approximate, answer. By switching over to a global events approach, and making a mistake I realized what the problem was. The mistake I made was (in global events) to use the same name for the function but not declaring it to be local. This lead to exactly the same mistake as in my first post as the program loads the .lua's sequentially, overwriting the same-named function such that all files point towards the same function. This is, as far as I know, an issue that cannot be resolved by onRaid() as the function seems to be intrinsically hard-coded, at least in older distributions, to be a global function. No matter how many different scripts you write, the "last" script to be loaded will always be the function onRaid() which is called when any raid activates. This probably explains why there is hardly any usage or information of onRaid() in the first place. If anyone is interested in my new, fixed script for random chests (Think rudimentary Timeless Isle in WoW) let me know.