PDA

View Full Version : A problem with the Client Tracker vs the Host Tracker...



Blackfoot
August 14th, 2014, 05:32
I'm making a change in the host tracker that I want to be reflected in the client tracker as well.
Basically it's a tick box for when the character 'aborts' their action. I want to tick the box on the host and display a field 'ABORTED' over the character's initiative numbers on the client. I thought I had it working but it doesn't actually update when clicked. How do I call one tracker from the other one? The functions are named the same thing in both tracker.. 'updateDisplay()'... I'm not sure how to refer to the 'client' when I'm the host. 'window' doesn't seem to work.

Trenloe
August 14th, 2014, 06:04
Simple way - have the control or action linked to a field in the relevant CT entry in the combat tracker section of the database. The GM udpates the database and controls linked to that field will be updated with it. Or, if you need to run code, do an onUpdate event handler that kicks off when the database field (or the control related to the field) is updated.

Or, a bit more complicated to code, deliver the command to kick off a script on the recipient client with OOB messaging: https://www.fantasygrounds.com/refdoc/Comm.xcp#deliverOOBMessage

Blackfoot
August 14th, 2014, 09:19
This is more or less what I'm trying to call... it's part of my updateDisplay() function in clientct_entry.lua ...
if abort.getValue() == 1 then
aborted.setVisible(true);
else
aborted.setVisible(false);
endI want this function to get called when I click the toggle in ct_host.xml
<buttonfield name="abort">
<anchored to="activeicon" position="righthigh" offset="325,0" width="12" height="20" />
<state icon="button_checkoff" tooltipres="ct_tooltip_abortoff" />
<state icon="button_checkon" tooltipres="ct_tooltip_aborton" />
<script>
function onValueChanged()
window.onAbortChanged();
window.updateDisplay();
end
</script>
</buttonfield>The two functions in 'onValueChanged()' are attempts to get this thing to work but aren't really getting anywhere.
Essentially all I want to do is the same thing that happens when I update the HP or some other value on the tracker.

Trenloe
August 14th, 2014, 15:02
HP and other values in the CT are tied to database values in the combat tracker portion of the campaign database - open up the campaign db.xml and see what data is stored there. When values in the database change, controls tied to these database entries change also - on all clients.

So, if the GM changes a value in the database and controls on the player side are tied to the same database entry it will change that too. See how the data is being stored in the database for your abort button, if it isn't being stored then you'll want to change your code to do that. Storing the value in he database also has the advantage of keeping data/control settings between sessions.

Blackfoot
August 14th, 2014, 15:28
I actually did check this. I put a Debug.chat(abort) into the updateDisplay() function and when it gets called, it displays a 1 when abort is set. Which is good... the only problem is that I want updateDisplay() to get called when abort is changed from 0 to 1... so that it changes the visibility on the clients. I need to figure out how to identify the client's tracker in order to call clienttracker.updateDisplay(); (or something like that).

Most of the battle with asking questions is explaining them so that people understand what you are actually asking.

Zeus
August 14th, 2014, 16:51
Blackfoot; rather than call the client's combattracker.updateDisplay() from the host, code the client combat tracker to call updateDisplay() when the source abort field's value changes. Remember that the database which underpins the client's CT window data is being kept in sync with the hosts CT window data, when you change the host DB, the database node changes get issued to all the clients as well.

Trenloe
August 14th, 2014, 18:59
Most of the battle with asking questions is explaining them so that people understand what you are actually asking.
Zeuss and I know exactly what you're trying to do - it's a common enough process: GM changes something, that something gets propagated to the players and runs some code there.

To re-iterate what I said in post #2 above (and subsequent posts) and what Zeuss has just said - the best way to do it is anchor controls in the GM and Player combat trackers on a specific database field (the control can be invisible on the player side if you don't want to show it). Then if the DB value changes on the GM side, all players who have the combat tracker open will get the change as well and you can tie your logic off the onUpdate() event for the control.

The GM cannot kick off scripts on the client side without using OOB messaging (this is what it is there for) - the GM cannot access clienttracker (if that is a window name in the PC side code) as that is not running on the GM PC.

Blackfoot
August 14th, 2014, 23:33
OK.. I think I might actually have this licked now. I didn't quite understand either of your explanations but I must have kinda gotten the gist. I added a script to the client .xml for the 'abort' that does an onValueChanged() function call. That did the trick.

Trenloe
August 15th, 2014, 04:46
The thing to remember is that code only runs on the one instance of FG - you can't attach to another instance of FG (be it a player attaching to the GM/another player or the GM attaching to a player) and tell it to run some code - hence why trying a command like clienttracker.updatedisplay from the GM wouldn't work. You need some way of kicking off code on all of the FG instances (GM or player) that are interested in acting on the change/code. The way to do that is changing a flag/value in the database that kicks off an onUpdate on all FG instances, or use OOB messaging to kick off a script on other FG instances (that is what OOB messaging is meant for - but it can be quite complex to grasp).

You've done it the best way in the end - update a field in the database and have onUpdate events triggered on the interested FG instances to run code.