Syncing Player Initiative to Combat Tracker

[sciencephile]

I'm sorry to have to ask as I am quite stubborn and have figured out everything else in the development of the Dark Heresy ruleset. The one area that is giving me trouble that I cannot figure out is when it comes to the combat tracker. Specifically the functionality that allows a character in the 3.5e ruleset to roll initiative and the initiative text box in the combat tracker automatically stores the result of the initiative roll.

Does anyone have any documentation on this process or can steer me in the right direction?

I've tried to look at the 3.5e ruleset to see how this is done but all I see is a template within a template, within a template and I'm afraid that the actual implementation was lost on me.

Also, as a side question to this I am wondering why in the 3.5e ruleset, most all of the rollable fields are <rollable />, thus being able to be dragged/double-clicked, yet the spot/listen/search abilities are using a small button to do the rolling instead. Was this strictly to conserve space or is there a technical reason for the difference? I ask that because I had used the buttons for my ruleset, instead of the <rollable /> and was wondering if I should do <rollable /> instead.

For what it's worth, I am developing the ruleset for Fantasy Grounds 3.0 using the 3.0 versions of CoreRPG and 3.5e as guides.

Thanks,

Danny

[Trenloe]

EDIT: Clarified some OOB actions.

This is handled by the OOB_MSGTYPE_APPLYINIT OOB functionality within the 3.5e ruleset. The OOB functionality is coded in the CoreRPG ruleset.

Look in the \scripts\manager_action_init.lua file - the handleApplyInit function updates the .initresult field of the combat tracker node in question using:

DB.setValue(msgOOB.sSourceCTNode .. ".initresult", "number", nTotal);


This is triggered through the ActionsManager.registerResultHandler("init",onResolve); and OOBManager.registerOOBMsgHandler(OOB_MSGTYPE_APPLY INIT, handleApplyInit); handlers that are registered in the onInit function within this lua file.
This means that when a result with an action type of "init" is found (rRoll.sType = "init") it will run the "onResolve" function (registerResultHandler("init",onResolve)).
The onResolve function basically delivers the roll message to the chat window and calls the notifyApplyInit function.
The notifyApplyInit function uses the OOB functionality to deliver an OOB message to the GM - this type is OOB_MSGTYPE_APPLYINIT which runs the handleApplyInit function on the GM side (registerOOBMsgHandler(OOB_MSGTYPE_APPLYINIT, handleApplyInit)).
The handleApplyInit function (running on the GM side through the OOB functionality) sets the DB .initresult entry in the CT node (as discussed above).

[Trenloe]

FYI - the OOB functionality (I believe it stands for Out Of Bounds) is required as the players cannot modify the CT directly - the GM owns the DB nodes so the GM has to modify them. OOB allows the player side of FG to initiate an operation that is passed to the GM side of FG to process - as the GM side is processing the operation it has access to make changes in the CT.

[sciencephile]

Great, thanks Trenloe. I hated to ask as it causes folks to stop what they are doing and I am usually quite good at finding the solution, but this one did not have a direct correlation that I could tell (i.e., no link in the character sheet initiative to link to CT or vice versa by having the same name, etc.). Seems to be more of a passive link in that the link is handled in the lua file mentioned, which I didn't get.

Thank you for the nudge in the right direction.

Danny