5E - Friend Zone

[MeAndUnique]

I find this extension very useful and love the ease of controlling NPC's for companions. However, I also find it very difficult to use for things like Beast Master pets and sidekicks. Trying to grasp modifying stat blocks based on how beast master works when leveling, as well as sidekicks (Tasha's ruling). For the last two, it seems easier to just create PC's for those to better manage them. Is there a better way to use FZ for the two situations, or maybe creating the PC's for those situations and add them to FZ? Thanks

Regarding the Sidekicks: they are indeed already structured as PC classes in the module. Since players can select and run multiple PCs fully already in the base ruleset there really isn't anything for Friend Zone to do.

For the Beast Master: everything should work via drag and drop if starting with one of the Template creatures from The Tasha's Cauldron of Everything module. However, since regular CR 1/4 creatures weren't built with the intent of being used as scalable companions the creature would require editing to make the various fields automate, largely through the addition of a "+PB". For example placing "+PB" in front of the "(natural armor)" text. The most complicated is probably the hit points field, for which you want to replace the text value with "(see notes)" and then add the following text on a new line on the "Other" tab: "Hit Points: Hit points are 4 times the Ranger Level."

[meadegendar]

Ok, thanks for the response. That should be easy enough to figure out next time when our ranger finds another pet (his previous died in a cave-in during our last session).

[MeAndUnique]

Just released version 1.2.0 with vehicle support as well as some general fixes for parsing cohort powers depending on their commander's abilities. Additionally, support has been added for version tracking with Power Up moving forward.

[GEONE]

I am getting an error with the new version when adding an NPC to the combat tracker



Edit: It seems to be a conflict with another extension that is using the legacy addNPC(). Would you be able to add a nil check to CombatManager.getCustomAddNPC before calling onNPCPostAddOriginal() for maximum compatibility?

[MeAndUnique]

I am getting an error with the new version when adding an NPC to the combat tracker



Edit: It seems to be a conflict with another extension that is using the legacy addNPC(). Would you be able to add a nil check before calling onNPCPostAddOriginal() for maximum compatibility?

I'd certainly be willing to discuss with the author of the other extension if you know which extensions is conflicting and see if there is a solution. In general though, if onNPCPostAddOriginal is nil it means that another extension has been actively deleting built-in ruleset functionality, and that is not something that I will be able to blindly account for in a generic manner. So while I may be able to suppress the error with a nil check, I cannot actually recover from the situation. So things would still almost certainly be in a broken/unpredictable state and I am of a very strong opinion that silent failures are much worse than reported ones.

[GEONE]

I'd certainly be willing to discuss with the author of the other extension if you know which extensions is conflicting and see if there is a solution. In general though, if onNPCPostAddOriginal is nil it means that another extension has been actively deleting built-in ruleset functionality, and that is not something that I will be able to blindly account for in a generic manner. So while I may be able to suppress the error with a nil check, I cannot actually recover from the situation. So things would still almost certainly be in a broken/unpredictable state and I am of a very strong opinion that silent failures are much worse than reported ones.

If an extension overrides or extends the legacy CombatManager2.addNPC() function using CombatManager.setCustomAddNPC(), then CombatRecordManager.getRecordTypePostAddCallback(" npc") will return the base 5e version of the function.
There is a switch of sorts in CombatRecordManager.addNPC() that ensures if there is a legacy override, then it will not use the standard handling. This is not removing built-in functionality, this is how it worked prior to the 2022-07 update and any extension older than that date that modifies the 5e combat manager's npc add handling will cause getRecordTypePostAddCallback("npc") to return the unmodified function, which is not good for legacy compatibility.

The best thing to do here would be to check if CombatManager.getCustomAddNPC() is not nil and use that, and if it is nil then use getRecordTypePostAddCallback("npc")/onNPCPostAddOriginal instead. This is how CombatRecordManager.addNPC() handles this exact predicament

[MeAndUnique]

If an extension overrides or extends the legacy CombatManager2.addNPC() function using CombatManager.setCustomAddNPC(), then CombatRecordManager.getRecordTypePostAddCallback(" npc") will return nil.
There is a switch of sorts in CombatRecordManager.addNPC() that ensures if there is a legacy override, then it will not use the standard handling. This is not removing built-in functionality, this is how it worked prior to the 2022-07 update and any extension older than that date that modifies the 5e combat manager's npc add handling will cause getRecordTypePostAddCallback("npc") to either return nil or the unmodified function, both of which are not good for legacy compatibility.

The best thing to do here would be to check if CombatManager.getCustomAddNPC() is not nil and use that, and if it is nil then use getRecordTypePostAddCallback("npc")/onNPCPostAddOriginal instead. This is how CombatRecordManager.addNPC() handles this exact predicament

In CoreRPG there are exactly 5 uses of CombatRecordManager's _tRecordTypePostAddCallbacks, none of which clear entries. In 5E, CombatManager2's onInit() calls setRecordTypePostAddCallback(). This basically means that unless an extension is either setting the callback to nil or deleting the code that manages the callbacks there is no way for getRecordTypePostAddCallback() to return nil.

On the legacy compatibility front, the expected behavior would be that Friend Zone would not have its logic invoked in the first place if another extension is causing the legacy code paths to be invoked. And to be honest, the legacy extension is running on borrowed time as is; the old flow is being officially deprecated and so will eventually no longer be functional.

[GEONE]

In CoreRPG there are exactly 5 uses of CombatRecordManager's _tRecordTypePostAddCallbacks, none of which clear entries. In 5E, CombatManager2's onInit() calls setRecordTypePostAddCallback(). This basically means that unless an extension is either setting the callback to nil or deleting the code that manages the callbacks there is no way for getRecordTypePostAddCallback() to return nil.

On the legacy compatibility front, the expected behavior would be that Friend Zone would not have its logic invoked in the first place if another extension is causing the legacy code paths to be invoked. And to be honest, the legacy extension is running on borrowed time as is; the old flow is being officially deprecated and so will eventually no longer be functional.

You're correct that getRecordTypePostAddCallback() should not return nil, but it does return only other functions which have been registered using the new handling, which means this extension will override the behaviour to npc adding that any other extension may make using the legacy handling. Surely it is worth it to add a small check to make it more compatible with older extensions? Yes legacy extensions will eventually be so deprecated that they cease to function, but I do not believe that means we should refuse to support them, especially when in this case it would be a very minor change to keep compatibility.

I don't see why FZ's logic wouldn't be invoked in the first place if the legacy setCustomAddNPC is used? The only use FZ has of onNPCPostAddOriginal is in its own onNPCPostAdd function, which is where this issue is arising, and where an if-else can be added to use getCustomAddNPC instead if it exists.

[MeAndUnique]

In 5E, CombatManager2's onInit() calls setRecordTypePostAddCallback().

This is the essential piece. Everything else comes back to this ground truth.

Every extension built for 5E should be able to safely depend on the callback existing because it is unconditionally provided by the ruleset itself. If the callback does not exists, it invariably means that there has been a fundamental alteration to the entire system for adding combatants in 5E.

I am happy to work with the developer to identify specific solutions for specific situations. However, I am not willing to silence the error that is rightfully signaling that there is significant misalignment.

[GEONE]

This is the essential piece. Everything else comes back to this ground truth.

Every extension built for 5E should be able to safely depend on the callback existing because it is unconditionally provided by the ruleset itself. If the callback does not exists, it invariably means that there has been a fundamental alteration to the entire system for adding combatants in 5E.

I am happy to work with the developer to identify specific solutions for specific situations. However, I am not willing to silence the error that is rightfully signaling that there is significant misalignment.

I think there may be a miscommunication. There is not an error that is being silenced. The FriendZone extension is using the newer callback. If an old extension modifies the npc adding behaviour using the built-in setCustomAddNPC() function, then FriendZone will completely bypass this modification. This can be fixed by having FriendZone check to see if an extension has overridden the npc adding behaviour using setCustomAddNPC() and use that instead of the new callback.