Then how does this mod do it, with just server sided?
Because
Jetting and firing use a trigger function, so we can easily tell if the trigger is enabled or not
If you really want me to explain though, since you're insistent.
Fire, Crouch, Jump, and Jet are part of the engine and the server has a callback function for these, called ::onTrigger. This ::onTrigger function has 4 args. The first one is the datablock. The second one is the object. The third one is the trigger being activated (0 = 'left click', 2 = jump, 3 = crouch, 4 = jet).
The fourth one is the on/off state.. This is what allows me to check whether they're being turned on or off.
However, for the rest of the functions, they're only called the instant the thing happens, and not when the thing stops happening. They only have one state, and that's being called.
For example, the plant brick key. It's entirely scripted. It calls commandToServer('plantBrick'); What this does on the server side is calls ServerCmdPlantBrick with one arg, being the client object.
There is no on/off state here.Your relays are going to catch nothing. They're on a 33 ms schedule at best and even per frame wouldn't help you. The best I can do is set it on when the function is called, then set it off when the function is complete. But guess what? It's still going to always be in an off state. Here's what happens.
Your relay loop calls. The state is off for plantbrick.
The plantbrick function is called, the state is set to on, the function goes through it's normal behaviour, and before anything else in the game at all can even happen because torque does one thing at a time, the state is set to off.
Your relay loop calls. The state is off for plantbrick.
If the client is still holding the plantbrick key, the function is called again, because it's being called on a client-sided loop, there is nothing that can be done.
So, why not add an input for like.. the events that it can activate? So.
playerActionBind <list> <cd> <Events> (The "Events" can be input like 1, 2, 3, 4, etc. or 1 4 (Both only activate events 1-4
I'll think about this.
Could you add a bind for e/painting?
I would love to, but there's some complications in this.
E has three possible things it can do. Equip a paintcan, switch paintcan column, or activate stuff.
I'd be, somewhat okay with adding the activate stuff functionality. But as it goes for paintcans, this is going to be rapidly called as you scroll through paints. It will also probably be rapidly calling usetool and unusetool, unless the paint cans are using another class.
So next update, I'll probably add EActivate, and maybe the event ranges.
