CombatManager.setCustomDrop - event is executed twice

I am trying to create a custom on drop event on the Combat Tracker.
The idea is that i can drag special tokens into the combat tracker actor, and add stuff to it (damage, etca)

So I am having an issue, and then to be safe, I checked this and it happens with CORERPG code also


Here is what i did:

- Clean CORERPG code

After that, I edited manager_combat2.lua, and did this:

Quote:

---

function onInit()
CombatManager.setCustomSort(CombatManager.sortfunc Standard);
CombatManager.setCustomCombatReset(resetInit);
CombatManager.setCustomDrop(onDropEvent);
end

function onDropEvent(rSource, rTarget, draginfo)
local sDragType = draginfo.getType();
Debug.chat("onDropEvent");
Debug.chat("rSource",rSource);
Debug.chat("rTarget",rTarget);
Debug.chat("draginfo",draginfo);
end

---

So, testing, I added a PC, and dragged a dice on it

The function is being called twice (check attached image)

Attachment 38201

I have no idea why this is happening, any ideas?

I'm not sure why it would be called twice; though you could use a Debug.printstack to review where it's being called from. One scenario is if there is an error; event scripts will be called twice by default.

JPG

Quote:

---

Originally Posted by Moon Wizard

I'm not sure why it would be called twice; though you could use a Debug.printstack to review where it's being called from. One scenario is if there is an error; event scripts will be called twice by default.

JPG

---

Thanks for the tip Moon Wizard.
I could not really find out the issue, printstack didnt show much, but it is quite weird behaviour. I ended up creating a workaround, a counter to avoid the second ondrop.
It only happens when on the ondrop in the combat tracker.

So, with the workaround, it is working now... i may investigate further and try to find what happens.
It happens in corerpg, but i did test savageworlds and it doesnt happen there, but its combat tracker code has been changed a lot, so, i dont know

Quote:

---

Originally Posted by Moon Wizard

I'm not sure why it would be called twice; though you could use a Debug.printstack to review where it's being called from. One scenario is if there is an error; event scripts will be called twice by default.

JPG

---

Hey Moon Wizard, not sure if you are going to read this, but i found another interesting thing.

I did the same test on FGU, and CORE fgu does not have the same issue.

I believe it could be a bug on corerpg, since i did test on a clean code, but of course i am not the best on coding for FG...

I'm not seeing the double call when I drop a dice on the CT. Do you have an extension or ruleset that I could use to recreate?

Regards,
JPG

Quote:

---

Originally Posted by Moon Wizard

I'm not seeing the double call when I drop a dice on the CT. Do you have an extension or ruleset that I could use to recreate?

Regards,
JPG

---

Here. This is just CoreRPG.pak unzipped, and I added the lines i described above, to scripts/manager_combat2.lua

(FGClassic)

https://drive.google.com/file/d/1lNY...ew?usp=sharing

There's an interesting behavior in the current script system where some events are called twice if they aren't handled (i.e. return true/false), but an event function is defined. I've never tracked it down, because it's usually not that hard to avoid. It seems like that is what is happening here.

I should probably change the CombatManager.onDropEvent to return true always; but I don't want to change it at this point, since I don't know what the repercussions might be.

For now, you can add a "return true" to the end of your custom onDropEvent function to stop it.

Regards,
JPG

Quote:

---

Originally Posted by Moon Wizard

There's an interesting behavior in the current script system where some events are called twice if they aren't handled (i.e. return true/false), but an event function is defined. I've never tracked it down, because it's usually not that hard to avoid. It seems like that is what is happening here.

I should probably change the CombatManager.onDropEvent to return true always; but I don't want to change it at this point, since I don't know what the repercussions might be.

For now, you can add a "return true" to the end of your custom onDropEvent function to stop it.

Regards,
JPG

---

Thanks a lot Moon Wizard! I wouldve never found this out alone!