First two things I tried in TEST failed - I'm afraid to try more with extensions

I only tried two things in the new test environment - placed a cloudkill with new extension which does asset/NPC into map and immediately got an error (works in current)...

[11/22/2023 9:43:42 AM] [ERROR] Handler error: [string "GenericActionsLayer:..ric_actions_layer.lua"]:505: attempt to index local 'newTokenInstance' (a userdata value)

Code:

---

        -- Update token references
        CombatManager.replaceCombatantToken(tCustom.nodeCT, newTokenInstance);
        newTokenInstance.setActivable(false);

---

Then I tried to use another extension to equip a torch which puts a LIGHT into the CT entry for that guy. The torch effect is placed on CT and nothing happens. I can drag the torch button from effects also and nothing happens. Get out and back in session and the LIGHT torch effect is suddenly there.

I'm too afraid to try anything else. Might wait a week for things to settle down.

The first item sounds like the token is no longer valid by the time it reaches the call you are making to setActivable.
Also, setActivable and isActivable were stubbed out in FGU, and thus do not do anything. You can remove any of those calls (which are also going away in v4.4.7 as deprecated APIs from FGC are removed.

The second item is a new initialization ordering bug I need to work out, and push a fix for the next release soonish.

Regards,
JPG

Quote:

---

Originally Posted by Moon Wizard

The first item sounds like the token is no longer valid by the time it reaches the call you are making to setActivable

---

Granted and I've removed it - but this does not really address the problem that in TEST the call

CombatManager.replaceCombatantToken(tCustom.nodeCT , newTokenInstance);

which is pure you guys is returning a bad tokeninstance - which is the sole purpose of what its SUPPOSED to return.

Somebody has wrecked the pointer on your side before it comes out of there - in TEST only. I'd like that to go back to doing what it should be doing - replace the token and return a valid tokeninstance to it.

If something has "wrecked" (or deleted) the token instance, then you need to look for the extension that is doing that during the middle of a script cycle. The issue is that object is being deleted somewhere inside the various code updates. I can't guarantee that an object won't get deleted by extension code.

I have not seen this with the standard CoreRPG coding for token replacement (i.e. when new token asset dropped on CT entry token field). Therefore, I would need specific steps in a campaign without any extensions to track it down, and see if it's something that CoreRPG is doing.

Regards,
JPG

The only difference is LIVE works and TEST does not.

I wish to get an extension to do something new, and at times complex, could be done other than by trial and error. Choosing parts of FGU (5E/CoreRPG/Engine) that are stable enough to build on, and what triggers or timing to guard against in callbacks, is never clear.

So once again the ground I've build upon has shifted and a section of my sandcastle wall has collapsed allowing the moat to flood the inner keep.

I guess if you build a sandcastle (extension) on shifting sands (FGU - 5E/CoreRPG/Engine) you pretty much get what you get.

I'll try and figure out why

Code:

---

        -- Update token references
        CombatManager.replaceCombatantToken(tCustom.nodeCT, newTokenInstance);
        newTokenInstance.setActivable(false);

---

suddenly shifted under my feet somehow, blasting the tokeninstance it returns. The ground has shifted yet again.

This is insane but it works. No idea why - and not willing to spend a ton of time figuring it out as it works in LIVE and TEST written this way. Looking at live code I see no way it should not be doing the old vs new token instance comparison in the FGU code that its always done and returned the right one - but mine is not to reason why...

Just to try and keep the shifting sands from toppling my castle. Again.

Code:

---

-- Update token references
CombatManager.replaceCombatantToken(tCustom.nodeCT, newTokenInstance);
newTokenInstance = CombatManager.getTokenFromCT(tCustom.nodeCT);
newTokenInstance.setActive(false);

---

The Test channel fix for the initialization order blocking effect updates has been pushed.

Regards,
JPG

This appears to have fixed the effect issue - a torch is now a torch.

Never mind - my own fault ignore what was here.

Evidently its always been a problem. I did not know that adding a PC into the CT and readding all its original effects into the DB would not actually trigger them when the replace Map Token operation was triggered after all that. Though I admit the only effect that would behave like an immediate trigger that I can think of is a lighting effect - probably why I never noticed it.

So real question is - how do you trigger a lighting effect (or really any effect) that was part of a DB copy into the CT? The CT looks fine and works fine - just no light.

{Answer: I guess I'm responsible for calling "TokenManager.updateEffects(nodeNewCTEntry);" as none of the underlying FGU code that I call to replace the map token will do this for me (sigh)}

Updated comment above.