//=====================================================// Input, a script to capture key and mouse input//// This script will catch and store player input// from the keyboard and mouse in a struct array.// Keys and buttons are records as bool states,// while mouse clicks and movement are kept as// int and fixed values for the UI and World// respectively.//// To get the state of the X key, you would use:// playerInput[p].key.state[c_keyX]// To get the point of the cursor, you could:// Point(playerInput[p].mouse.x,playerInput[p].mouse.y)//// The user may configure the DETECT bool// constants to set which triggers will be// created on initialization of the script.//=====================================================// CONFIGURABLE CONSTANTSconstboolDETECT_KEYDOWN=true;constboolDETECT_KEYUP=true;constboolDETECT_BUTTONDOWN=true;constboolDETECT_BUTTONUP=true;constboolDETECT_MOVEMENT=true;constintINPUT_BUTTONS=6;constintINPUT_KEYS=99;constintINPUT_MAX_PLAYERS=c_maxPlayers;// STRUCTSstructButton{bool[INPUT_BUTTONS]state;};structKey{bool[INPUT_KEYS]state;};structMouse{intuix;intuiy;fixedx;fixedy;fixedz;};structInput{Keykey;Buttonbutton;Mousemouse;};// GLOBALSInput[INPUT_MAX_PLAYERS]playerInput;// FUNCTIONSboolInput_KeyOn(booltestConds,boolrunActions){playerInput[EventPlayer()].key.state[EventKeyPressed()]=true;returntrue;}boolInput_KeyOff(booltestConds,boolrunActions){playerInput[EventPlayer()].key.state[EventKeyPressed()]=false;returntrue;}boolInput_ButtonOn(booltestConds,boolrunActions){intp=EventPlayer();playerInput[p].button.state[EventMouseClickedButton()]=true;playerInput[p].mouse.uix=EventMouseClickedPosXUI();playerInput[p].mouse.uiy=EventMouseClickedPosYUI();playerInput[p].mouse.x=EventMouseClickedPosXWorld();playerInput[p].mouse.y=EventMouseClickedPosYWorld();playerInput[p].mouse.z=EventMouseClickedPosZWorld();returntrue;}boolInput_ButtonOff(booltestConds,boolrunActions){intp=EventPlayer();playerInput[p].button.state[EventMouseClickedButton()]=false;playerInput[p].mouse.uix=EventMouseClickedPosXUI();playerInput[p].mouse.uiy=EventMouseClickedPosYUI();playerInput[p].mouse.x=EventMouseClickedPosXWorld();playerInput[p].mouse.y=EventMouseClickedPosYWorld();playerInput[p].mouse.z=EventMouseClickedPosZWorld();returntrue;}boolInput_Movement(booltestConds,boolrunActions){intp=EventPlayer();playerInput[p].mouse.uix=EventMouseMovedPosXUI();playerInput[p].mouse.uiy=EventMouseMovedPosYUI();playerInput[p].mouse.x=EventMouseMovedPosXWorld();playerInput[p].mouse.y=EventMouseMovedPosYWorld();playerInput[p].mouse.z=EventMouseMovedPosZWorld();returntrue;}voidInput_Init(){if(DETECT_KEYDOWN){TriggerAddEventKeyPressed(TriggerCreate("Input_KeyOn"),c_playerAny,c_keyNone,true,0,0,0);}if(DETECT_KEYUP){TriggerAddEventKeyPressed(TriggerCreate("Input_KeyOff"),c_playerAny,c_keyNone,false,0,0,0);}if(DETECT_BUTTONDOWN){TriggerAddEventMouseClicked(TriggerCreate("Input_ButtonOn"),c_playerAny,c_mouseButtonNone,true);}if(DETECT_BUTTONUP){TriggerAddEventMouseClicked(TriggerCreate("Input_ButtonOff"),c_playerAny,c_mouseButtonNone,false);}if(DETECT_MOVEMENT){TriggerAddEventMouseMoved(TriggerCreate("Input_Movement"),c_playerAny);}}
In my experience, even disabled triggers to detect player key, button, and movement input generate network traffic. This is why using as few triggers as possible is preferable, as it is the only thing approximating a throttle we have on this issue.
Since the engine cannot perform simultaneous parallel processing of its threads, using multiple triggers when they will just fire in sequence anyway is needless overhead.
My script is intended to capture all player input from keys, mouse buttons, and mouse movement, without any specific implementation. Call me a romantic, but I have a soft spot for modularity. I'd like people to be able to do whatever they want with it, stopping just long enough to configure the constants that regulate the creation triggers, in case they don't need to detect key up or mouse movement.
So it's not an improvement, per se, but rather a script with some similar features but a different and more general purpose, which may also happen to be more conservative toward net traffic.
The only (minor) issue one may have with my script is the overhead cost of the variable memory which, assuming a 32-bit bool implementation, roughly exceeds 6 kb.
While I have a few issues with Jademus' script (consts, man, consts! 6, 16, 99, magic numbers make me sad), I'm inclined to agree with him in regards to the disabled triggers part.
My attempts at using constants to define array sizes have been met with syntax errors in the past. Also, they are not magic, so much as they should correspond to the highest constant ints for the relevant input types; keys go up to c_keyF12 = 98, for example. I have no other option there. It becomes the user's responsibility to modify them according to its needs.
EDIT: I tried using constants again and was pleasantly surprised. Script updated.
Thanks Motive. =D
My script almost certainly generates less network traffic, a total of 5 input catching triggers versus 14n where n is the number of active players, but it would be positively unscientific for one to be averse to testing such things. Be certain to implement each system in separate maps when conducting the tests, since toggling between the two in the same map via the disabling of triggers is not effective at throttling the network traffic generated by the input detection triggers, in my experience.
Also, your demonstrable wealth of platitudes has awed and humbled me.
Event's will probably be queued and sent in packages from one player to another.
Then they'll arrive at the other player who can then use them like the events have been generated on his local pc.
Thus it'll probably not matter very much in terms of net traffic.
Two triggers which both use the same trigger event don't necessarily cause a game to transfere the same event twice.
Only now do i realize i can use constants to declare array sizes.. it doesnt work if its not a constant right? Are there any cases in which this does not work?
Neat! I'll attach a map with the GUI version of this script.
Any improvement compare to my 2 month old script? Which activate and deactivate itself for certain interval for every action and every active player?
In my experience, even disabled triggers to detect player key, button, and movement input generate network traffic. This is why using as few triggers as possible is preferable, as it is the only thing approximating a throttle we have on this issue.
Since the engine cannot perform simultaneous parallel processing of its threads, using multiple triggers when they will just fire in sequence anyway is needless overhead.
My script is intended to capture all player input from keys, mouse buttons, and mouse movement, without any specific implementation. Call me a romantic, but I have a soft spot for modularity. I'd like people to be able to do whatever they want with it, stopping just long enough to configure the constants that regulate the creation triggers, in case they don't need to detect key up or mouse movement.
So it's not an improvement, per se, but rather a script with some similar features but a different and more general purpose, which may also happen to be more conservative toward net traffic.
The only (minor) issue one may have with my script is the overhead cost of the variable memory which, assuming a 32-bit bool implementation, roughly exceeds 6 kb.
@JademusSreg: Go
While I have a few issues with Jademus' script (consts, man, consts! 6, 16, 99, magic numbers make me sad), I'm inclined to agree with him in regards to the disabled triggers part.
My attempts at using constants to define array sizes have been met with syntax errors in the past. Also, they are not magic, so much as they should correspond to the highest constant ints for the relevant input types; keys go up to c_keyF12 = 98, for example. I have no other option there. It becomes the user's responsibility to modify them according to its needs.
EDIT: I tried using constants again and was pleasantly surprised. Script updated. Thanks Motive. =D
Yea, Jademus' script is much cleaner than yours, avo :)
Though a const int for the player number would be appreciated:
Yes. =)
I don't know, if yours faster or not. But most other author use your logic, and their maps are not very fast.
I think, my system generate less traffic, but it is hard to proof.
We need a test with a lot of player. 2 system but same map.
My script almost certainly generates less network traffic, a total of 5 input catching triggers versus 14n where n is the number of active players, but it would be positively unscientific for one to be averse to testing such things. Be certain to implement each system in separate maps when conducting the tests, since toggling between the two in the same map via the disabling of triggers is not effective at throttling the network traffic generated by the input detection triggers, in my experience.
Also, your demonstrable wealth of platitudes has awed and humbled me.
Event's will probably be queued and sent in packages from one player to another.
Then they'll arrive at the other player who can then use them like the events have been generated on his local pc.
Thus it'll probably not matter very much in terms of net traffic.
Two triggers which both use the same trigger event don't necessarily cause a game to transfere the same event twice.
See my awesome drawing skills for what I mean:
http://simplest-image-hosting.net/png-0-unbenannt63
@avogatro: Go
I like your creed there. Filled with truth :)
@s3rius: Go
Only now do i realize i can use constants to declare array sizes.. it doesnt work if its not a constant right? Are there any cases in which this does not work?
@FuzzYD: Go
I guess it only does not work if you declare the constant after the array. But that's normal.
Generally this always works. It needs to be a constant though, yes.
Trivial update; MAX_PLAYERS updated to INPUT_MAX_PLAYERS = c_maxPlayers to avoid namespace conflicts.