Ok, that sounds good.
For the first half of the problem, I've just created this ticket that I intend to implement very soon:
http://trac.cafu.de/ticket/123
About the second half, if I understand your problem correctly, you want an augmented version of the human players
GuiHUD
, right?
Well, I have a "solution" for you, but it's downright ugly, more a work-around than a solution, and I'm somewhat ashamed of it:
1. In the HumanPlayer entity code, you learn the data that is relevant for you from the ScriptTracker entity. (Btw., with the new DoSerialize() and DoDeserialize() code it would even be possible to store the data in the HumanPlayer entity directly, in each of them, bypassing the ScriptTracker entity. Just a thought.)
2. Then, still in the HumanPlayer entity code, you would update your augmented version of the
GuiHUD
analogously as the existing sample code does:
GuiHUD->GetScriptState().Call(...);
3. The only problem is that you cannot easily react on events that occur in the
GuiHUD
in the HumanPlayer code: with things as they are, we have no callback from the
GuiHUD
into the HumanPlayer.
And this is where things get ugly: You could implement a polling mechanism. For example, as long as
Code: Select all
std::string result;
GuiHUD->GetScriptState().Call("GetSomeChoice", ">S", &result); // S, not s
yields
result == ""
(checked each frame), the player made no choice, otherwise, a choice was clicked.
Well, as I said, neither can I see if that actually helps your problem (did I understand it right?), nor is this a particularly elegant solution.
Better solutions would register callback functions to the GuiHUD script state, and/or bind the HumanPlayer instance to it (hey I like this one!), but for that I needed more time than I have tonight, and more thorough understanding of your problem, and possibly some sample code.
Hope this helps anyway!