Combat Tracker: where would code that initializes NPC fields go?

[peterb]

Yet another CT question.

A bit of background. I’m in the process of writing an extension, to the Basic Roleplaying ruleset, adding support for “strike ranks” (SR). So far, I have modified the PC sheet and the NPC sheet. Both now handles and updates SR as per the rules. Now I’m working on making entries on the CT handle and update SR as required. Linking PC sheets was easy, I just modified the function linkPCFields() in ct/ct_entry.lua. Getting NPC records to work has been more troublesome.

NPC records are copied to the CT, as I understand it, and my problem is where to put the code that initializes and updates the variables used to set up SR. Currently, the code is in ct/ct_entry.lua. But it seems like the NPC node isn’t 100% copied, DB nodes that exists in the NPC node are not available in the CT node until the ruleset is reloaded.

I’ve tried to add an onDrop function, but it didn’t have any effect, as far as I can tell.

What kind of code and where would I put it to make sure that a given node is created and populated or copied from the NPC node?

[Moon Wizard]

One thing to remember is that records are not copied "as a whole unit at one time". When copying a record, first the record entry is created, then each field is copied independently which can trigger database events. My guess is that your code is firing as soon as the top-level node is created, before all the data is copied over.

I'm not sure how your strike ranks are calculated. The approach would probably be different whether it's a user-entered single field or a field calculated from multiple other user-editable fields; and whether it's a record top-level field (immediate child) vs. per sub-record field (nested child list).

Regards,
JPG

[peterb]

One thing to remember is that records are not copied "as a whole unit at one time". When copying a record, first the record entry is created, then each field is copied independently which can trigger database events. My guess is that your code is firing as soon as the top-level node is created, before all the data is copied over.

OK. That would explain why the node that contains the already calculated current strike rank is not existing when I try to access it in a function called from ct/ct_entry.lua's onInit(). How do you control the copying? How do I make sure the fields I need get copied at the very start?

I'm not sure how your strike ranks are calculated. The approach would probably be different whether it's a user-entered single field or a field calculated from multiple other user-editable fields; and whether it's a record top-level field (immediate child) vs. per sub-record field (nested child list).

Well, the strike rank of a weapon attack is automatically calculated based on the actors DEX, SIZ and the reach of the weapon. The NPC record already has the current SR calculated as a sub-record field (windowlist.window.field). I'm trying to copy the active weapons SR value to the strikerank field. The strikerank field is already present in the ruleset, so I thought it was best to continue using it.

Strike rank handling is a bit complex. The value depends on the weapon the actor is using, so an active weapon must be selected (I'm using a custom made "radio-button"), and then the SR of that weapon must be calculated. The calculation must be updated if DEX or (very rarely though) SIZ changes. SR must also, of course, be recalculated if another weapon is selected.

There are no user-editable fields directly involved. Indirectly the fields for DEX and SIZ are involved.

I can post the layered ruleset I use (I have a few modifications to BRP that I use. So, there are four layers involved CoreRP, BRP, my layered ruleset and an extension.) and the extension that implements strike ranks on top of it, if anyone is interested

[Moon Wizard]

You cannot control the copying behavior nor the networking behavior. You have to assume that records can be partially complete, and trigger updates based on the incoming adding/changing of nodes.

It sounds like you'll need to capture the DEX/SIZE changes for NPCs, as well as the active weapon setting and the SR value of weapon records as well. Then, add them all up to apply as the strike rank any time one of those fields changes.

Regards,
JPG

[peterb]

You cannot control the copying behavior nor the networking behavior. You have to assume that records can be partially complete, and trigger updates based on the incoming adding/changing of nodes.

OK. Thanks for the clarification.

It sounds like you'll need to capture the DEX/SIZE changes for NPCs, as well as the active weapon setting and the SR value of weapon records as well. Then, add them all up to apply as the strike rank any time one of those fields changes.

Allright, I have such code elsewhere, I'll implement it in the ct code as well. Thanks for the pointer.