5E - StealthTracker

[MrDDT]

I was testing the new SR Carrier ext in the paid section and found that when this ext is loaded the two do not work together. It took some time for me to narrow it down since it did not throw an error nor warning. It just fails silently. I will be passing this along to SR in his thread as well.

Can you tell us what is failing? I'm using ST and Carrier and not getting any issues. No Error (like you said) and both working.

[JustinFreitas]

Yeah I'm calling original code in all places. If this helps these are what I override (saves are what is stored - original code - and called as all overrides should do where possible)...

-- Store original CombatManager.onDrop function so we can restore it on close
local saveCMonDrop = nil;
-- Store original TokenManager.linkToken function so we can restore it on close
local savelinkToken = nil;
-- Store original TokenManager.updateTooltip function so we can restore it on close
local saveupdateTooltip = nil;
-- Store original TokenManager.updateVisibilityHelper function so we can restore it on close
local saveupdateVisibilityHelper = nil;

I have a CT drop handler I think. Lemme look.

[JustinFreitas]

I have a CT drop handler I think. Lemme look.

Drop handlers get put into a table so they all work (I looked in CoreRPG/manager_combat.lua)... prolly not that then.

[SilentRuin]

Drop handlers get put into a table so they all work (I looked in CoreRPG/manager_combat.lua)... prolly not that then.

As per PM there is no conflict according to MrDDT. Unless new info comes up I'd not worry about it. If your using custom drop then there will be no conflict anyway (as mine wraps around that whole process which gets done before my stuff). Though if anything returns "true" on the process then as the rules state nothing else will process after. I trust nobody is truncating the drop on my CT name drag by stating nothing else should execute if they are not messing with that.

Typical onDrop return mean the following (which I respect and don't execute my stuff if it happens - meaning this will not be my unique CT name field drag/drop anyway):

This function should return true if it handled the event and the processing of the event should be stopped. A value of false indicates that the default framework functionality for the this particular control should not be executed, but the processing should continue for the element below this control, if any. A return value of nil (or the absence of a return statement) indicates that the framework should continue handling the event normally.

[JustinFreitas]

I'll need to switch to an onDrop override then. Fun times.

[SilentRuin]

I'll need to switch to an onDrop override then. Fun times.

? if your stuff works - it works. No need to change it if it works.

Point being - if someone processes something and don't want anyone else to process it (rare) then they will return true and truncate all other processing. I only return the original onDrop calls return code and only process my stuff if it was not true (nil or false) meaning nobody did anything with my CT name drag/drop I'm after. But things are nebulous at best and you just need to do what you need to do. I just try not to mess anyone else over so never return a true in my onDrop unless I really want it to stop processing what I just processed.

[SilentRuin]

MrMDDT verified its a bug in the on drop processing of the CT name field dropped onto another CT field. As I stated, even the custom on drops you use in ruleset code loop (onDropEvent) will terminate all further custom drops if one of them returns true - and I (over all of that processing) also respect that return code coming out of the onDrop cycle of those things to not process if its true. My bet is your returning a return code when you should not be. See my previous cut/paste of onDrop return codes from FGU documentation above.

[MrDDT]

As SR posted, I see the issue, when you try to make a group, it has the "error" (no msg) where it wont make a carrier group.
So if you trying to make it happen and don't understand what SR is saying (I don't get that coding side).

With carrier group, you drag the CT onto another CT and make a carrier group. This is where ST and Carrier are in conflict, with both EXTs loaded, it will not make a carrier group. Without ST, Carrier works fine.

[JustinFreitas]

I pushed a fix (3.6.3) up to the store. Can you check it out again sometime today? The problem stems from me having to work around an FGC bug where the drop handler fires twice. Doesn't happen on FGU, so I had to put in a weird hack to prevent it in FGC instead of returning true. I tested on both and it fires once on both with these changes.

[nephranka]

I will not be able to test it to this evening. Thank you for taking a look and trying to fix it.