Sign up Calendar Latest Topics
 
 
 


Reply
  Author   Comment  
eurobusker

Registered:
Posts: 108
Reply with quote  #1 
this a very ineresting command, if I'm right, this must give the opportunity for a client to input a number or letter and get the script to do something...
Has anyone got a simple example or snippet so I can understand its function and possible usage?
please?
Mike Substelny

Avatar / Picture

Administrator
Registered:
Posts: 2,180
Reply with quote  #2 
Two years ago I wrote a massive script that used if_client_key extensively, with dozens of different key controls on all of the consoles. Unfortunately it seldom worked properly due to bugs in the Artemis code. That is, I would program the script to poll Helm for keystrokes and it worked on my bridge. I might port my script to two other bridges and it worked there, too. Then I would port my script to a third bridge and suddenly it would be polling Science instead of Helm. This was very frustrating and I eventually gave up on that script. I believe that Thom determined the problem had to do with the different keyboard drivers used on mixed-computer bridges (e.g. where everyone brings their own laptop from different manufacturers with different operating systems). Thom said he will fix it someday but it was not a high priority.

The if_client_key function does work, but I recommend you do one of the following:

  • Do not use if_client_key extensively. Limit your script to no more than two or three keys on one console.
  • Or use if_client_key as much as you want. Once you get the script working on your bridge never share it with any other bridge because on some bridges it will malfunction.

__________________
"The Admiralty had demanded six ships; the economists offered four; and we finally compromised on eight."
- Winston Churchill
Mike Substelny

Avatar / Picture

Administrator
Registered:
Posts: 2,180
Reply with quote  #3 
Here is a code snippet from my old mission script. In this script the Helmsman could press H to hard dock with a special base called Delta Astre, which would give the player ship an upgrade:

 <!-- Prepare for Docking -->
<event name="Prepare to dock">
<if_variable name="Astre_near" comparator="!=" value="1"/>
<if_distance name1="Artemis" name2="Delta Astre" comparator="LESS" value ="100"/>
<start_getting_keypresses_from consoles="H"/>
<warning_popup_message message="H to Hard Dock" consoles="H"/>
<set_variable name="Astre_near" value="1"/>
</event>


<!-- Hard Docking -->
<event name="Hard Dock">
<if_client_key keyText="H"/>
<if_variable name="Astre_dock" comparator="!=" value="1"/>
<set_variable name="Astre_dock" value="1"/>
</event>

__________________
"The Admiralty had demanded six ships; the economists offered four; and we finally compromised on eight."
- Winston Churchill
Lorik Eolmin

Avatar / Picture

Registered:
Posts: 55
Reply with quote  #4 
Science Officer gathers data before jumping in another quadrant. I love using this command, I find it very immersive and easy to use to increase the feeling of teamworking.



Quote:
<event name_arme="Scientist gathers data" id_arme="eac86040-c140-4946-ae66-47ffcc843457" parent_id_arme="c9b837dc-768b-4382-9196-92409d2e2fb2">
  <if_distance name1="Artemis" name2="Jump Point DELTA" comparator="LESS_EQUAL" value="2000.0" />
  <if_variable name="chapter_1" comparator="EQUALS" value="17.0" />
  <warning_popup_message message="Key R: Gathering Jump Data" consoles="S" />
  <start_getting_keypresses_from consoles="S" />
  <set_variable name="chapter_1" value="18.0" />
</event>

<event name_arme="Science OK" id_arme="e2bcd487-8ef2-485e-af06-59a905fa4ba1" parent_id_arme="c9b837dc-768b-4382-9196-92409d2e2fb2">
  <if_variable name="chapter_1" comparator="EQUALS" value="18.0" />
  <if_client_key keyText="R" />
  <end_getting_keypresses_from consoles="S" />
  <set_variable name="chapter_1" value="19.0" />
  <play_sound_now filename="..\..\..\dat\testIUSound13.wav" />
  <warning_popup_message message=Gathering Jump Data" consoles="S" />
  <warning_popup_message message=Gathering Jump Data" consoles="M" />
</event>
ryleyra

Registered:
Posts: 2,888
Reply with quote  #5 
I make use of client key commands in my carrier script. It's really a lot more interactive and flexible than trying to use ship state to trigger events. I've found that it's best if only one console, or one console at a time, activates client key events. I have a key command set up to switch fighter control between Science and Comms, but only one can control the fighters at a given time.

Even so, client keys have some serious limitations:

1) All ships share the same client keys in multi-ship games. You cannot tell which ship sent the client key command, and when you start getting keypresses from a console, all instances of that console on all ships can use the key.

2) Similarly, you cannot tell which console, out of those selected with start getting keypresses, pressed the key. You could switch between consoles with start getting keypresses, and test for a given key only when that console is active, but that would delay the response time, as you could only listen to one console each cycle.

Mike's script apparently got around this problem by polling the proper console only when the conditions were right for the client key to work, which is another alternative. You could even have one console that is always active, and turn it off while listening to another console.

3) There is no UI interface for keypresses. That means they cannot be used with the Android and iOS versions of Artemis, or with custom Consoles that don't provide a keyboard.

4) You have to prompt the player to use the key. This is usually done with a warning popup, as in your example, although for greater player interaction you might give a list of the available keys to Comms, to be shared with the rest of the crew as needed.

A number of players, particularly those associated with the TSN Sandbox have reported problems getting client keys to work. This may be related to the firewall settings on the client, or it could be the keyboard drivers, as Mike suggested. Either way, client keys are so delicate that they are rarely used. I would suggest doing as I did, and provide an alternate interface which doesn't use client keys, and either turn the interface on and off via the GM screen, or provide two versions of the mission.

Oddly, GM keys do not seem to have as many problems. They seem quite robust and the various GM Sandboxes out there tend to use extremely complex menuing systems that can perform just about any function based an a sequence of keypresses.

I've also considered a form of communication back to the GM, or between player ships, where the Comms officer can "capture" a sequence of alphanumeric keys and dump them as text to a popup. (one character at a time, but maybe a way could be found around that) It would require a mission to implement, but could produce any message, not just the limited ones provided by the Comms menu. And the GM already has an interface to send a chat message to Comms.
Lorik Eolmin

Avatar / Picture

Registered:
Posts: 55
Reply with quote  #6 
Nice summary ryleyra, it clarifies a few questions I still had in mind while scripting.
Xavier Wise

Registered:
Posts: 1,042
Reply with quote  #7 
Originally, the TSN Sandbox used client keys. They were used to activate the fuel collection system, as well as interface with gateways. Sadly, they were so unreliable they were removed.

I think, if they were reliable, they would be immensly powerful for immersion and interactivity. I had loads of ideas for different client keys and how to set them up, but never pursued them as they never worked properly.

Mike, is there a way to convince Thom to crack on with fixing client keys as I reckon they would open a whole world of exciting scripting opportunities? That simple trigger of hitting one key could spark off a whole series of exciting events. In its simplest form, saying to your engineer 'Activate fuel collection system' is pretty awesome. And this could extend further to broadcasting messages, activating sensor sscans and analysis. The TSN RP Community would love it, I guarentee!

__________________
Fleet Captain Xavier Wise - TSN Sabre
Link to TSN RP Community website
ryleyra

Registered:
Posts: 2,888
Reply with quote  #8 
Honestly, I think fixing of client keys should involve more than just finding the keyboard driver bug and fixing it. I'd like to see all of the issues I listed addressed, possibly by a total redesign of the interface. I've made some suggestions and would be happy to discuss it further, but really what we are talking about is a means to create a customizable event interface between players, GM, and the mission.

In the meantime, I'm wondering if Glitter and/or ArtClientLib can be used as a go-between. The client and GM key packets are defined and identified in the packet protocol, and the mission could be programmed to respond to them, while an external interface could be designed to generate the packets based on ship number and console. So for instance the mission could respond to "a" as activate fuel scoop for ship 1, and "b" as activate fuel scoop for ship 2. (Using the mission's name for ships)

If I'm reading correctly, the external interface doesn't have to be told to listen for keypresses (so the mission script doesn't have to use start_getting_keypresses_from) it just sends the packet to the server and the server will respond. This should eliminate the problem with keyboard drivers or whatever since a keyboard will never be used. (And I'll note that even if the server has to be told to expect keypress packets from a console, according to the script docs both Mainscreen and Observer can be set with start_getting_keypresses, and maybe Data too. So you can still set the Glitter console to Observer if the console doesn't allow multiple connections)

I've also thought of using the built-in GM chat feature for communications between ships, but I believe that's already in work for Glitter.

Of course, if Thom thinks he can fix the bug without much trouble, so much the better. I like the idea of "automated" missions where the players are able to choose what missions to play or what options to take without having to rely on a GM for that. (And while you could use GM keys for that purpose, the players would have to start up that console, and resist the temptation to use it to cheat [biggrin])

BTW, I'm guessing the reason the clients don't just send keypresses to the server is to keep the network traffic down. The client can't know what keypress it is listening for, so it has to send ALL of them. (Except the ones it uses for its own interface, I guess)

Arrew

Avatar / Picture

Registered:
Posts: 2,737
Reply with quote  #9 
I have used this function a lot... But the biggest issue is sometimes it's unreliable and just doesn't work requiring a restart of Artemis before it does. Not sure why.

Here us a little snippet from a comms conversation;

<event name_arme="enemy message" id_arme="6c93f9e8-4244-4a08-9984-a160164e8661">
<if_timer_finished name="ATenemymessage" />
<if_variable name="warn2c" comparator="NOT" value="1.0" />
<start_getting_keypresses_from consoles="C" />
<set_variable name="warn2c" value="1.0" />
<incoming_comms_text from="TG01">The cargo is ours. You will back away from the transport and surrender it to us!^------------------------------^ (Comms Officer Reply Using The Numbers On Your Keyboard)^7. Under the TAK Treaty of 2191 this Sector is in USFP Territory. You will withdraw back to Torgoth space immediately. ^8. Cargo! They're children! And they're USFP citizens and under our protection.^9. Take it. The cargo is yours.</incoming_comms_text>
<set_timer name="LAG" seconds="2" />
</event>


<event name_arme="2C7" id_arme="b6dd22da-b4f3-426b-b569-f5c78df0dcf4">
<if_variable name="warn2c" comparator="EQUALS" value="1.0" />
<if_variable name="2Canswer" comparator="NOT" value="1.0" />
<if_client_key keyText="7" />
<if_timer_finished name="LAG" />
<set_variable name="2Canswer" value="1.0" />
<end_getting_keypresses_from consoles="C" />
<incoming_comms_text from="TG01">The cargo is ours!</incoming_comms_text>
<add_ai type="ATTACK" targetName="Ardent" value1="1.0" name="TG02" />
<add_ai type="ATTACK" targetName="Ardent" value1="1.0" name="TG01" />
</event>



<event name_arme="2C8" id_arme="a5d72a2a-94e6-4b19-aa83-ebb2e8a54b71">
<if_variable name="warn2c" comparator="EQUALS" value="1.0" />
<if_variable name="2Canswer" comparator="NOT" value="1.0" />
<if_client_key keyText="8" />
<if_timer_finished name="LAG" />
<set_variable name="2Canswer" value="1.0" />
<end_getting_keypresses_from consoles="C" />
<incoming_comms_text from="TG01">Your protection? Don't make me laugh.</incoming_comms_text>
<add_ai type="ATTACK" targetName="Ardent" value1="1.0" name="TG02" />
<add_ai type="ATTACK" targetName="Ardent" value1="1.0" name="TG01" />
</event>


<event name_arme="2C9" id_arme="34f9b0dd-8914-48a1-9474-614fa7945f2f">
<if_variable name="warn2c" comparator="EQUALS" value="1.0" />
<if_variable name="2Canswer" comparator="NOT" value="1.0" />
<if_client_key keyText="9" />
<if_timer_finished name="LAG" />
<set_variable name="2Canswer" value="1.0" />
<end_getting_keypresses_from consoles="C" />
<incoming_comms_text from="TG01">Excellent.</incoming_comms_text>
<big_message title="Mission Failed" subtitle1="" subtitle2="" />
<set_timer name="endgame" seconds="10" />
<add_ai type="ATTACK" targetName="Ardent" value1="1.0" name="TG02" />
<add_ai type="ATTACK" targetName="Ardent" value1="1.0" name="TG01" />
</event>




I like, using it in conjunction with comms because it makes it feel like you can actually communicate. But have also used it as everything from fighting off boarding aliens, spies and deploying sensor platforms and activating special weapons. It is super cool. Shame about its reliability.





locqust

Avatar / Picture

Registered:
Posts: 70
Reply with quote  #10 
Quote:
Originally Posted by ryleyra
Honestly, I think fixing of client keys should involve more than just finding the keyboard driver bug and fixing it. I'd like to see all of the issues I listed addressed, possibly by a total redesign of the interface. I've made some suggestions and would be happy to discuss it further, but really what we are talking about is a means to create a customizable event interface between players, GM, and the mission.

In the meantime, I'm wondering if Glitter and/or ArtClientLib can be used as a go-between. The client and GM key packets are defined and identified in the packet protocol, and the mission could be programmed to respond to them, while an external interface could be designed to generate the packets based on ship number and console. So for instance the mission could respond to "a" as activate fuel scoop for ship 1, and "b" as activate fuel scoop for ship 2. (Using the mission's name for ships)

If I'm reading correctly, the external interface doesn't have to be told to listen for keypresses (so the mission script doesn't have to use start_getting_keypresses_from) it just sends the packet to the server and the server will respond. This should eliminate the problem with keyboard drivers or whatever since a keyboard will never be used. (And I'll note that even if the server has to be told to expect keypress packets from a console, according to the script docs both Mainscreen and Observer can be set with start_getting_keypresses, and maybe Data too. So you can still set the Glitter console to Observer if the console doesn't allow multiple connections)

I've also thought of using the built-in GM chat feature for communications between ships, but I believe that's already in work for Glitter.

Of course, if Thom thinks he can fix the bug without much trouble, so much the better. I like the idea of "automated" missions where the players are able to choose what missions to play or what options to take without having to rely on a GM for that. (And while you could use GM keys for that purpose, the players would have to start up that console, and resist the temptation to use it to cheat [biggrin])

BTW, I'm guessing the reason the clients don't just send keypresses to the server is to keep the network traffic down. The client can't know what keypress it is listening for, so it has to send ALL of them. (Except the ones it uses for its own interface, I guess)



I started doing something like this with glitter. Instead of pressing a keyboard key you pressed a Web button which triggered a java script action and sent the keycode of the letter rather than the letter itself. Appears to get around the driver issue and was a tad more reliable. I do have to use different keycodes for the same action on different bridges. So 102 for launching shuttles on Artemis, Intrepid used 103. All sent through the observer console.
As you have 128 keycodes available to use in Artemis it expands it well beyond the 26 restriction of the actual letters. 

I do intend to rebuild it as a java app using artclientlib rather than glitter at some point but bit too busy at the moment.  
Karakawa

Registered:
Posts: 2
Reply with quote  #11 
Sorry to bring back an old thread, but I'm just getting into scripting, and I'm trying to get this function to work. Is Arrew's numbered comms method still the best way to do this, and we just have to live with the unreliability of it, or is there something better we can be doing? I currently have an option to press "y" to send an sos signal, and it hasn't worked yet in testing.
Karakawa

Registered:
Posts: 2
Reply with quote  #12 
Looks like asking for help was exactly what I needed to do! After two days of looking for this, I found the comms buttons 30 minutes after I posted this. Props to Thom, this is a great feature!
Mike Substelny

Avatar / Picture

Administrator
Registered:
Posts: 2,180
Reply with quote  #13 
The Comms buttons are much more reliable than the Client Keys. Unfortunately you can't have a Comms button for Science.
__________________
"The Admiralty had demanded six ships; the economists offered four; and we finally compromised on eight."
- Winston Churchill
Previous Topic | Next Topic
Print
Reply

Quick Navigation:

Easily create a Forum Website with Website Toolbox.