Fire key depends on specific crossbow pickup

#1 Here's what I would do...

I would map each of those keys to some kind of fire-filter function. That function then looks at the key pressed and the current crossbow. If the match is a success, I would then call that crossbow's onFire().

I don't see any reason why you need to go into the engine.

#2 Use a command to client, that will fire off a function on the client system to call the weapon key bind.

#3 Basically, when you push the fire button, the script sets a trigger variable, then the engine sees that the variable is set, and changes the state of the image, which is set in the script, which then tells the engine to execute the function onFire. You really dont want to mess with the C++ code in shapebaseimage if your only a beginner.. it is very hard to get a grasp of. Well, thats my view. I would stick with trying to do it in the scripts, like the other posts say.

#4 Great info. These posts fill in all the pieces except one. I think the answer will improve my understanding of Torque script more broadly than this particular question's scope.

In 'default.bind.cs' I can assign 4 different keys to fire the crossbow with this:
function l_fire(%val)
{
echo("L is pressed!!");
$mvTriggerCount0++;
}

..ETC....

So there I know what WAS pressed. And how to call Crossbow::onFire.

In 'function CrossbowImage::onFire(%this, %obj, %slot)'
I can check what is SUPPOSED TO BE pressed with:
%obj.client.player.thekey

..but neither script knows both pieces of information. Is there a way in 'function CrossbowImage::onFire' to find out what was just pressed?
My function in 'default.bind.cs' isn't passing anything on to 'onFire', so I'm not taking the key info with me to that function.

This for me is another case of being a bit stuck when I use functions that don't have '%this', and '%obj' passed in. Well, here it's a case of not passing them on.

Thank you

#5 The input event is purely client side. That means that unless you take special pains, the input event is not available on the server. Any input event can be used to manipulate the mvTriggerCount# variable. The # of triggers is determined by the MaxTriggersKeys defined in moveManager.h. By default, six triggers are available, so that # can be a single digit between 0-5.

The mvTriggerCount# script variables are created in gameConnectionMoves.cc in MoveManager::init and bound to mTriggerCount C++ array. GameConnection::getNextMove populates the Move object's trigger array using the current values in the mTriggerCount array. The Move is used in a controlled object's processTick(const Move *) method (after the Move being transmitted across the network if necessary).

It's up to processTick(Move(const Move *move) method to determine how the move->trigger[#} is interpreted. For instance, one common possibility is:

setImageTriggerState(0,move->trigger[0]);

Will set the trigger state for the image mounted on slot 0. If this represents a change in trigger state, a mounted image state transition will occur and the callback script of the new state will be invoked (this is where onFire is invoked, as a callback from within C++). The input event (e.g. a key) that was used to set mvTriggerCount0 is long gone.

It's a very flexible system where each stage is highly decoupled. For instance, input events can be bound to any script function, although unless they manipulate script variables tied to the contents of a Move or explicitly do a serverCmd, they do not affect the server. On the server side, the object executing the processTick is free to any interpretion of the contents of the Move received from the client (unfortunately, if that interpretation does not match your intended functionality, that does mean changing C++ code). This flexibility does make it more difficult to trace an execution path from source. The only advice I can give is in decoupled software it's often better to search for usages than to try to trace program flow -- for instance, searching for usages of mvTriggerCount would have lead to gameConnectionMoves.cc.

#6 Thanks. That's a can of worms that eventually had to be opened. It'll be a little while before I report back, but I'll post any useful/working code when I can.