My expiring of effect call is now failing in TEST - works in LIVE

[SilentRuin]

I'm looking at this right now - but not seeing anything obvious in why this would be working any differently than in LIVE. I get a stack dump of...



[6/23/2022 12:09:13 PM] [ERROR] Handler error: [string "scripts/manager_combat.lua"]:97: attempt to index local 'nodeEffectList' (a userdata value)
stack traceback:
[string "scripts/manager_combat.lua"]:97: in function <[string "scripts/manager_combat.lua"]:95>
(tail call): ?
[C]: in function 'delete'
[string "scripts/manager_effect.lua"]:785: in function 'expireEffect'
[string "scripts/manager_polymorphism.lua"]:1645: in function 'fHandler'
[string "scripts/manager_oob.lua"]:30: in function <[string "scripts/manager_oob.lua"]:22>
[C]: in function 'deliverOOBMessage'
[string "scripts/manager_polymorphism.lua"]:1619: in function 'NotifyStopConcentration'
[string "polymorphism_stop_concentration_button"]:13: in function <[string "polymorphism_stop_concentration_button"]:7>


Where somehow the ruleset code is losing the nodeEffectList - or something has changed in expireEffect that I'm just not seeing. Any help or ideas appreciated.

[SilentRuin]

In fact, no matter where in my code I trigger an expireEffect it fails in the same way.

[Moon Wizard]

Try adding Debug statements at the top of each function in the chain to see what the parameters are.

If you provide a very specific example campaign and extension where everything is set up so I can see it with a few simple steps; I should be able to help.

Regards,
JPG

[Moon Wizard]

I just checked with the latest beta Test code in the CoreRPG ruleset in the TokenManager; and the calls seems to be coming through correctly for me using CombatManager.setCustomDeleteCombatantEffectHandle r.

Regards,
JPG

[SilentRuin]

I just checked with the latest beta Test code in the CoreRPG ruleset in the TokenManager; and the calls seems to be coming through correctly for me using CombatManager.setCustomDeleteCombatantEffectHandle r.

Regards,
JPG

Might it have something to do with this function I override? I'll get on the Debug.console stuff now.

-- in order to prevent crash from conflicts where effect list is not longer in existence
saveonDeleteCombatantEffectEvent = CombatManager.onDeleteCombatantEffectEvent;
CombatManager.onDeleteCombatantEffectEvent = onDeleteCombatantEffectEvent;

[SilentRuin]

I can see it come in this routine...



-- prevent conflict crash
function onDeleteCombatantEffectEvent(nodeEffectList)
if type(nodeEffectList) ~= "databasenode" then
return false;
end
return saveonDeleteCombatantEffectEvent(nodeEffectList);
end



And when I print out the nodeEffectList I get

databasenode = { combattracker.list.id-00019.effects }

Which is correct. The only purpose for this function was there were times the node with that list would have been removed and I check that the entry is still a database entry to prevent it from doing... well... what it's doing right now.

But not understanding how it looks good going into my save call and then drops dead as if its not good. Ideally I'd prefer the FGU code to validate the node effect is still around but this was my solution - which works in live - but fails in TEST.

[SilentRuin]

I just validated that removing my above override causes the same exact error. Which was the sole purpose of the override in the first place - to prevent an expired effect request from triggering after something else removed the node it was part of. I really don't understand how my check is not preventing this. Actually not really understanding what is going on at all. My debug console log shows it calling my override - and with valid nodeffect list - but then seems to not really have it by time it reaches the FGU version. Or something else is calling the FGU version and completely skipping my safety check.

Any chance this safety check can move into the FGU code? Either way - I'm stumped what is going on.

[SilentRuin]

To be clear - polymorphism uses the effect's removal to trigger a transformation (CT node will be removed and replaced) - which can end up in this error where by the time the system gets around to doing the delete - the node is gone and the effect list is user data. I prevent this error (an expired event is generic - not just my poly one) when this situation happens by checking the nodeEffectList is still in the DB. Works in LIVE as I said - fails in TEST.

[SilentRuin]

Also not sure there is a way to do a simple example. The only way I know to get this to happen is to have an expired effect trigger the removal of the node it is part of. You'd have to have polymorphism and run it. But I think what I've explained already should be pretty clear...

My safety check for ALL onDeleteCombatantEffectEvent calls is not happening in ALL calls. Not sure why.

[SilentRuin]

[Removed likely useless info]

Pretty much lost on what is causing this. Putting a print in LIVE to see if that safety was ever triggered and the print never showed up. Does not error in LIVE - but it for sure does not print that it skipped processing on the type(database) check.

Beginning to wonder how you can ever get this code to not try to process a nodeEffectList where the node is gone.

[Moon Wizard]

As I mentioned above, I'd need an example all set up in a campaign with the current extension that can be walked to the error in a few clicks, before I can provide any real feedback.

JPG

[SilentRuin]

As I mentioned above, I'd need an example all set up in a campaign with the current extension that can be walked to the error in a few clicks, before I can provide any real feedback.

JPG

Sent to you in discord with directions. Should be simple to duplicate. If you need to recreate the polymorph just hit Druid action tabs ACTIVE button - the kobold is already targeted. It will polymorph to the active setting (baboon) and then if stop concentration button is not showing flip back and forth between any tab and back to actions. Double click on stop concentration and Error will occur when trying to expire (delete) the effect that no longer exists.

[SilentRuin]

@Moon Wizard

Was that enough?

[superteddy57]

@Moon Wizard

Was that enough?

It may take some time to go over what you provided and go through testing scenarios. Moon will reach out when further information is needed or a solution is found.

[SilentRuin]

It may take some time to go over what you provided and go through testing scenarios. Moon will reach out when further information is needed or a solution is found.

Cool - just wanted to make sure you guys got it as I dropped it all in his discord.

[Moon Wizard]

Finally got a chance to dig into this today.

It's because your extension assumes it is the last one to register an effect delete handler (or assumes it is the only one), which is not an assumption you can ever make, since initialization order is never guaranteed (since Lua table ordering is never guaranteed).

Your current handler as implemented actually deletes the current CT node which the effect is on; which makes the nodeEffectList invalid (since it was deleted with the CT node you deleted). Thus, any subsequent effect deletion handler calls now throw an error.

In fact, there are many places in the CoreRPG code where the CT node is continued to be referenced after an effect is expired/deleted. I'm surprised you haven't run into more issues before; except that the references are minimal.

I would suggest changing the data within the same CT node if at all possible to preserve the integrity of any code executing after yours; or come up with another mechanism to do what you want.

Regards,
JPG

[Moon Wizard]

Since you're already overriding CombatManager.onDeleteCombatantEffectEvent, you might be able to get away with not registering the function at all, and calling it explicitly in your override after the standard processing. This may get you back "to where you were before". However, the issues I mentioned still remain in terms of deleting a CT node mid code stream when the expectation is that only the effect node when away; and I would expect that you would encounter future issues as the code evolves because of that.

Regards,
JPG

[SilentRuin]

Since you're already overriding CombatManager.onDeleteCombatantEffectEvent, you might be able to get away with not registering the function at all, and calling it explicitly in your override after the standard processing. This may get you back "to where you were before". However, the issues I mentioned still remain in terms of deleting a CT node mid code stream when the expectation is that only the effect node when away; and I would expect that you would encounter future issues as the code evolves because of that.

Regards,
JPG

Yes that's what I described to you was happening - though I was not aware it could have been happening (race condition) in other places - I only overrode the one you mention above as that was the only one I had to guard against a bad address to get it to work. I'll take a look at working around this issue of having the removal of a concentration effect triggering the change of nodes. This is vital to how polymorphism works as when damage is done and something loses concentration for these its automatically going to work. In fact, everything still works just fine - its just that error gets printed out (and likely if anything else is going on after it that will not be happening).

Is there any chance at all you can guard against the non database reference argument like I do in your code? I mean this is something that can legally happen - and like guarding against nil in similar situations I would thing doing this guard would be something worthwhile and would certainly solve my problem with the new TEST version. All it would need would be the below code added like I originally did correct?



function onDeleteCombatantEffectEvent(nodeEffectList)
if type(nodeEffectList) ~= "databasenode" then
return false;
end
.... Do your normal stuff ....
end


Also not sure what you mean by registering it - as you can see in the extension code I gave you it just overrides the function - does not do anything with the registration.

[SilentRuin]

I'm actually wondering if the CombatManager.setCustomDeleteCombatantEffectHandle r(onEffectsChildDeleted); call that triggers the whole node thing can somehow be done so that it does not occur until the effect is actually deleted and done processing (I'm still confused on how I can be triggered by a child delete and the child still being processed in places).

[SilentRuin]

Well looking at the latest drop in TEST I thought - wow you guys wrote some safeties in. Then I realized a bunch of other stuff changed breaking things all in a different way (sigh)

[SilentRuin]

I will verify that your safety checks work and Polymorphism no longer has any issues when having damage failed concentration save expiring the concentration effect and triggering the polymorph change of nodes. So thanks for that. I'll have to recheck all my extensions individually as addNPC is now giving some nil call errors in things like Death Indicators. I could tell lots of things got shifted around so will have to sort through and figure out how to get things back to working.

Are there any other major extension breaking changes to TEST coming up before july 12?

[Moon Wizard]

Regarding post #17 and #18, I'm talking about removing CombatManager.setCustomDeleteCombatantEffectHandle r call in your code, then updating the replacement function to look like this:



function onDeleteCombatantEffectEvent(nodeEffectList)
.... Do your normal stuff ....
.... Call your polymorphism specific code that you used to register with setCustomDeleteCombatantEffectHandler ....
end


Regards,
JPG

[Moon Wizard]

Regarding post #21, we're working on streamlining the process for registering new record types for combat, in order to support vehicles in combat for 5E. (i.e. upcoming Spelljammer release).

For the addNPC, there are now hooks to get/set the record type handlers, as well as postAdd record type handlers. (See 5E ruleset for CombatRecordManager.setRecordTypePostAddCallback).

The next step for adding 5E vehicle combat support is updating the CT UI to support vehicles; as well as updating all actor/roll functions to correctly handle vehicles as actors/combatants. I'm not sure if any of those changes will be in test yet, but I'm leaning towards after this Test release doing an immediate second cycle to finalize for Spelljammer (which releases in mid-August).

Regards,
JPG

[SilentRuin]

Regarding post #17 and #18, I'm talking about removing CombatManager.setCustomDeleteCombatantEffectHandle r call in your code, then updating the replacement function to look like this:



function onDeleteCombatantEffectEvent(nodeEffectList)
.... Do your normal stuff ....
.... Call your polymorphism specific code that you used to register with setCustomDeleteCombatantEffectHandler ....
end


Regards,
JPG

No need your guards in those areas fixed all the problems. Now I'm hunting why all my NPC action lines are blank in the NPC change to Ape - and why on change back 1/2 are blank in the original NPC it was polymorphing from. I'm assuming this last load of changes has shifted all sorts of things around messing up the overrides involving those areas - which means a number of my extensions will need to be rettested (and likely have this same issue). I'm guessing someone shifted the npc record xml or lua stuff around rendering any overrides bugged.

[Moon Wizard]

The overrides are continuing to work in the layered rulesets (because I specifically tested for layered rulesets which have not been updated); so not sure why yours wouldn't work.

Can you provide another specific campaign example? Or will the previous example show the issue?

Regards,
JPG

[SilentRuin]

The overrides are continuing to work in the layered rulesets (because I specifically tested for layered rulesets which have not been updated); so not sure why yours wouldn't work.

Can you provide another specific campaign example? Or will the previous example show the issue?

Regards,
JPG

The sample will work fine - when the kobold is turned into a Baboon just hit CT (sword) to bring up the actions list - they will all be blank. Transform the baboon back to its original kobold entry and you will see all or some blank (in my usual campaign I have more complex NPCs with spells and things and not all the action lines were blank).

53330

[SilentRuin]

Note - a lot of functions got deprecated and shifted around when I did a diff on latest code drop in TEST - so this may all be tied to stuff I just have to adjust too. For sure I've seen error in another extension with addNPC being nil which was not there last release.

[SilentRuin]

How is line 347 getting a stack overflow after this last TEST release? I fixed one of my new issues caused by CombatManager2.addNPC being removed - but this one I'm not understanding. The function should still be there and working as it did previously.



header:
Line 24: local saveaddNPC = nil;
onInit() stuff:
Line 151: saveaddNPC = CombatManager.addNPC;
Line 214: CombatManager.addNPC = saveaddNPC;

Functionality:
Line 347: local nodeNewCTEntry = saveaddNPC(sClass, nodeNPC, sName);


This one also:

local nodeCT = CombatManager.addNPC(sClass, nodeNPC, sName);

Something is broken in this.

[Postedit - did not find it - error occurs in new way this is working in TEST - but its a stack overflow where a print shows it calling it for the same operation over and over till it gets the stack overflow]

[Moon Wizard]

Actually, it does get returned if you're overriding the old CombatManager.addNPC:



function addNPC(sClass, nodeNPC, sName)
local tCustom = { sRecordType = "npc", nodeRecord = nodeNPC, sClass = sClass, sName = sName };
CombatRecordManager.addNPC(tCustom);
return tCustom.nodeCT;
end


JPG

[SilentRuin]

[QUOTE=Moon Wizard;654296]Actually, it does get returned if you're overriding the old CombatManager.addNPC:

[Postedit - did not find it - error occurs in new way this is working in TEST - but its a stack overflow where a print shows it calling it for the same operation over and over till it gets the stack overflow]

[SilentRuin]

Apologies, when Death Indicators was found to no longer be able to call CombatManager2.addNPC and it got replaced with CombatManager.addNPC - then for some reason its override of onHostAddNPC [CombatManager.setCustomAddNPC(onHostAddNPC);] started to infinite loop at this area of its code.



---------------------------------------------------------------------------------------
-- Called on the server to add a NPC to the combat tracker
---------------------------------------------------------------------------------------

function onHostAddNPC(sClass, nodeNPC, sName)

-- Validate the nodeNPC parameter

if not nodeNPC then
Debug.console("NpcTokenManager.onHostAddNPC: Invalid nodeNPC parameter");
return nil;
end

-- Add the NPC to the combat tracker

local nodeCT = CombatManager.addNPC(sClass, nodeNPC, sName);

if not nodeCT then
Debug.console("NpcTokenManager.onHostAddNPC: Invalid combat tracker node");
return nil;
end

-- Retrieve the configured NPC token

local sToken = getConfiguredNpcToken(nodeCT);

if not sToken or sToken == "" then
Debug.console("NpcTokenManager.onHostAddNPC: Invalid NPC token")
return nil;
end

if not Interface.isToken(sToken) then
Debug.console("NpcTokenManager.onHostAddNPC: Interface.isToken(" .. sToken .. ") = false")
return nil;
end

-- Update the combat tracker node with the correct token and return

--Debug.console("manager_npc_token:onHostAddNPC; update CT token");
--Debug.console(sToken);
DB.setValue(nodeCT, "token", "token", sToken);

return nodeCT;

end


My guess is that being forced to replace the original call to CombatManager2.addNPC with CombatManager.addNPC is what is causing this infinite loop.

As I have no idea what the intent of this area of the code is, not having written it, I will have to delve into why CombatMnager2.addNPC was removed and what I can do to make this work now that it has.

Thanks to MeAndUnique for pointing out my idiocy on "not returning the node" in an indirect manner ;)

[SilentRuin]

Ok I can see that CombatManager2.addNPC while removed has similar but not the same coding in CombatManager2.onNPCPostAdd. I am officially confused. What can I use to replace the original CombatManager2.addNPC behavior without suffering a callback infinite loop? They (addNPC vs onNPCPostAdd) differ in setting size and other things it appears.

[SilentRuin]

Now equipped effects no longer works when dropping NPC into CT and applying effects. I'll have to find out what changed there too. Is there something that tells us the reasons things are changing and how? The single sentence in updates gives no clue as to what will be broken.

[SilentRuin]

Appears equipped effects is not processing the call

local swClass, swRecord = DB.getValue(nodeCT, "link", "", "");

for my npc as it used to - coming up both blank.

[SilentRuin]

I think I see a recurring theme in some of my many issues that cropped up with the last release of TEST. I have overrides for CombatManager.addNPC - which are done as part of stuff I use to insure I get a hook in to all things that get added into the CT. But now doing a printstack - to see how I'm reaching some of the calls I'm getting - I see that those calls while calling addNPC are now calling them out of the new manager combat record. So even though it "appears" all my stuff is working in terms of overrides - they will now never be called.

the new "function CombatRecordManager.addNPC(tCustom)"

vs

the old "function CombatManager.addNPC(sClass, nodeNPC, sName)"

is very misleading. While you can call the old one still - overriding it will get you nothing - because nothing in the handlers/callbacks ever calls it anymore.

I have changed all my old references and overrides to CombatManager.addNPC to CombatRecordManager.addNPC - this way I'm sure my overrides are being implemented across the board always no matter who's custom stuff is in play.

[SilentRuin]

These are the current open issues I'm waiting on an explanation from SW in TEST...

CT blank NPC action lines after nodes recreated - works in LIVE fails in TEST (https://www.fantasygrounds.com/forums/showthread.php?74189-My-expiring-of-effect-call-is-now-failing-in-TEST-works-in-LIVE&p=654286&viewfull=1#post654286)

CombatManager2.addNPC is no longer present and calling the CombatManager.addNPC in the callback causes infinite loop now (https://www.fantasygrounds.com/forums/showthread.php?74189-My-expiring-of-effect-call-is-now-failing-in-TEST-works-in-LIVE&p=654341&viewfull=1#post654341)

[Moon Wizard]

Do not override the CombatRecordManager.addNPC. There are now very specific calls you can make to override the existing behavior without monkeying around with the internals of the CoreRPG scripts (which will cause future breakage).

Specifically,
to override the overall NPC add behavior, you can use CombatRecordManager.setRecordTypeCallback("npc", fn)
to just append to the default NPC add behavior, you can use CombatRecordManager.setRecordTypePostAddCallback("npc", fn)

Regards,
JPG

[SilentRuin]

Do not override the CombatRecordManager.addNPC. There are now very specific calls you can make to override the existing behavior without monkeying around with the internals of the CoreRPG scripts (which will cause future breakage).

Specifically,
to override the overall NPC add behavior, you can use CombatRecordManager.setRecordTypeCallback("npc", fn)
to just append to the default NPC add behavior, you can use CombatRecordManager.setRecordTypePostAddCallback("npc", fn)

Regards,
JPG

For what I'm doing the setRecordTypePostAddCallback will cause multiple errors and blank CT lines when I try to use it - and the setRecordTypeCallback looks to be designed that only the last person to define it will get to have that the behavior - meaning two extensions can't both override it as currently can be done when overriding COmbatRecordManager.addNPC. Or am I reading that wrong? I live in a many extension environment.

[SilentRuin]

I also found out why those CT lines are blank after the polymorphism. Because this call stack is no longer happening when I trigger the node change.

From LIVE I get this for my override of parseNPCPower...

stack traceback:
[string "scripts/manager_equipped_effects.lua"]:439: in function 'parseNPCPower'
[string "scripts/manager_combat2.lua"]:316: in function 'parseNPCPower'
[string "scripts/manager_combat2.lua"]:206: in function 'addNPC'
[string "scripts/manager_npc_token.lua"]:55: in function <[string "scripts/manager_npc_token.lua"]:44>
(tail call): ?
[string "scripts/manager_equipped_effects.lua"]:347: in function 'addNPC'
[string "scripts/manager_campaigndata.lua"]:107: in function <[string "scripts/manager_campaigndata.lua"]:87>
(tail call): ?

For TEST I get nothing. Hence blank CT lines.

All my issues seem to come back to manger_combat2.lua removal of addNPC - what is going on there? Why would I not get something similar triggered in the new overrides?

[SilentRuin]

My problem is I need parseNPCpower called when a node is changed in the CT. Which works in LIVE but does not in TEST.

In TEST the stack is this.

Dropped NPC onto CT:

stack traceback:
[string "scripts/manager_equipped_effects.lua"]:439: in function 'parseNPCPower'
[string "scripts/manager_combat2.lua"]:281: in function 'parseNPCPower'
[string "scripts/manager_combat2.lua"]:204: in function <[string "scripts/manager_combat2.lua"]:107>
(tail call): ?
(tail call): ?
[string "scripts/manager_combat_record.lua"]:36: in function 'onRecordTypeEvent'
[string "scripts/manager_combat_drop.lua"]:124: in function 'handleLinkDropEvent'
[string "scripts/manager_combat_drop.lua"]:78: in function <[string "scripts/manager_combat_drop.lua"]:70>
(tail call): ?
(tail call): ?


Polymorph changing the nodes:

parseNPCPower never called - no stack.


In LIVE the stacks are both present as I would expect:

Dropped NPC onto CT:

stack traceback:
[string "scripts/manager_equipped_effects.lua"]:439: in function 'parseNPCPower'
[string "scripts/manager_combat2.lua"]:316: in function 'parseNPCPower'
[string "scripts/manager_combat2.lua"]:206: in function 'addNPC'
[string "scripts/manager_npc_token.lua"]:55: in function <[string "scripts/manager_npc_token.lua"]:44>
(tail call): ?
[string "scripts/manager_equipped_effects.lua"]:347: in function 'addNPC'
[string "scripts/manager_campaigndata.lua"]:107: in function <[string "scripts/manager_campaigndata.lua"]:87>
(tail call): ?

Polymorph changing the nodes:

stack traceback:
[string "scripts/manager_equipped_effects.lua"]:439: in function 'parseNPCPower'
[string "scripts/manager_combat2.lua"]:316: in function 'parseNPCPower'
[string "scripts/manager_combat2.lua"]:221: in function 'addNPC'
[string "scripts/manager_npc_token.lua"]:55: in function <[string "scripts/manager_npc_token.lua"]:44>
(tail call): ?
[string "scripts/manager_equipped_effects.lua"]:347: in function 'addNPC'
[string "scripts/manager_polymorphism.lua"]:2223: in function 'savePolymorphActivated'
[string "scripts/manager_AssistantGM.lua"]:82: in function 'PolymorphActivated'
[string "scripts/manager_polymorphism.lua"]:363: in function 'fResult'
[string "scripts/manager_actions.lua"]:622: in function 'resolveAction'
[string "scripts/manager_actions.lua"]:595: in function 'handleResolution'
[string "scripts/manager_actions.lua"]:570: in function <[string "scripts/manager_actions.lua"]:563>

[SilentRuin]

I should note that even with the sample campaign I gave you - where I don't override parseNPCpower - you could easily put a printstack in your ruleset version and see that when I do the polymorph it never gets called - hence blank. Using equipped effects I can do my own printstack as in that one I do override pareseNPCpower. But in both cases, the behavior no longer triggers pareseNPCpower in your new way of doing things triggered by the drop only.

[SilentRuin]

I did more digging it looks like addNPC in LIVE used to call parseNPCPower directly and addNPC in TEST no longer does. Nor does it trigger it when addNPC is called directly. Not all CT node addition occurs due to a drop. Some are due to direct calls to addNPC.

[Moon Wizard]

In the core ruleset, there are no direct calls to addNPC.

If you need to call something analogous to addNPC, then you would you would call need to make a call like this with the new code:



local tCustom = { sClass = "npc", sRecord = [sourcepath] };
CombatRecordManager.onRecordTypeEvent("npc", tCustom);


Regards,
JPG

[SilentRuin]

In the core ruleset, there are no direct calls to addNPC.

If you need to call something analogous to addNPC, then you would you would call need to make a call like this with the new code:



local tCustom = { sClass = "npc", sRecord = [sourcepath] };
CombatRecordManager.onRecordTypeEvent("npc", tCustom);


Regards,
JPG

That Solved it - much appreciated. Just need to figure out the infinite loop as my only "known" problem left.

Replace any addNPC calls with the above and all my CT action lines are there.

[SilentRuin]

Infinite loop solved, per Moon Wizard suggestion, replaced CombatManager.setCustomAddNPC(onHostAddNPC) call with the following:

In onDesktopInit...


savedOldFn = CombatRecordManager.getRecordTypePostAddCallback("npc");
CombatRecordManager.setRecordTypePostAddCallback("npc", onNPCPostAdd);


With function...


function onNPCPostAdd(tCustom)
if savedOldFn then
savedOldFn(tCustom); -- assume if something there they call CombatManager2.onNPCPostAdd
else
CombatManager2.onNPCPostAdd(tCustom);
end
local nodeCT = tCustom.nodeCT;

... My Stuff ...

[Moon Wizard]

There was a bug in CombatRecordManager.getRecordTypePostAddCallback that I just fixed in the beta Test channel.

You shouldn't need the CombatManager2.onNPCPostAdd(tCustom); backup call any more.



function onNPCPostAdd(tCustom)
if savedOldFn then
savedOldFn(tCustom);
end
local nodeCT = tCustom.nodeCT;

... My Stuff ...


Regards,
JPG

[SilentRuin]

There was a bug in CombatRecordManager.getRecordTypePostAddCallback that I just fixed in the beta Test channel.

You shouldn't need the CombatManager2.onNPCPostAdd(tCustom); backup call any more.



function onNPCPostAdd(tCustom)
if savedOldFn then
savedOldFn(tCustom);
end
local nodeCT = tCustom.nodeCT;

... My Stuff ...


Regards,
JPG

I assume if it ever did come back null in this check I'd still have to call the CombatManager2.onNPCPostAdd - though I understand you've fixed it so it should not.

[SilentRuin]

As this is my grab bag thread of things I've had to fix in my extensions for TEST - I figured I'd mention this one. Make sure you replace addNPC calls etc. with CombatRecordManager.onRecordTypeEvent - or you will pay for it in subtle ways.