Sign up Calendar Latest Topics

  Author   Comment   Page 3 of 3      Prev   1   2   3

Posts: 3,007
Reply with quote  #31 
Originally Posted by Nighthawk

packet from the network link? dunno.
I know there must be a way, if it's displayed.... it must be coming from somewhere.
it's also being relayed to other computers, so it has to be stored somewhere.

I THINK it's possible to read it with Glitter. If I'm understanding the program correctly, it intercepts the packets travelling from server to client. So as you say, it HAS to be there in the packet protocol being relayed to the Helm. I'm just not sure how to get to it and translate it into a form which can be displayed on the console.

I'm assuming macros and third party apps are being used to move the cursor and click on buttons on the display that aren't mapped to keybinds, though (such as the command to unload tubes) so for the sake of this thought experiment I'm assuming we're making use of whatever is available to do what we want.

It would be way easier if we could just deal with keybinds and DMX, but since not everything is covered by that, we have to make some assumptions. At the very least, we can use some tricks to workaround the issue, like my suggestion that the heading can be tracked by the console, using its own calculations, instead of getting the heading from the server.

I'm really stoked about the idea of an audio-only Comms. [biggrin] I'm putting together a diagram right now.


Posts: 3,007
Reply with quote  #32 
Just to say it, if you have to you can implement your own client, which sends packets back to the server based on inputs to your headless console. Then you can interpret incoming packets however you want. There's no since reinventing the world, though, and if Glitter provides that functionality then so much the better.

Posts: 3,007
Reply with quote  #33 

Okay, I threw together a quick and dirty diagram which I think should be a good starting point for designing a Comms console. I'll note that there may be some messages I forgot, and I'm not sure what order message types are in, I think player ships are option 1, but for the discussion below I will assume bases are option 1 because it makes the examples easier:


From top to bottom, the selectors are used to control which target is contacted out of bases, friendly ships, and enemy ships. The square indicators above the knobs are a digital display showing which base, friendly ship or enemy ship is selected. This can be handled one of two ways, triggered when the selector changes:

1) The key sequence 1-1 (for bases, 1-2 for friendly and 1-3) is sent to the server. The menu should open to the list of available bases. If the client receives that list, then that list is stored and the selected base displayed based on the state of the selector knob.

2) The key sequence 1-1 (for bases, as above) and the number corresponding to the knob position is sent to the server, for instance 1-1-2 for whichever base is second closest. The menu should open to the base interaction list. If the client receives the name of the base that is currently selected, then it is stored and displayed.

Now, when a button is pressed, for instance Hail (base) the key sequence 1-1-2-1 will hail the base selected above. The received message is played back via a text to speech program. In addition, the message display to the lower right updates; the message number is incremented (this probably isn't part of the game, but is needed to help the Comms officer keep track of past message) and the Time and From indicators are updated with the applicable information from the packet.

The player ship selector to upper right is a special case. The Voice Channel On button basically activates the Push To Talk keybind on your TeamSpeak/Ventrilo. The selector doesn't really matter in this case, although the message could be preceded by a sound file that plays a hailing sound, and then says something like "Artemis to Intrepid" with the text to speech. It depends on how complicated you want to get. The keypad to the right I put there because I can't remember the player messages, and they're rarely used anyway. The keypad could double as a standard Comms interface, for that purpose you might need a switch to take it out of "player ship" mode (which issues the 1-4-2 style macro) and puts it back in standard one press one menu level mode.
As for the messages section at bottom right, again, it would depend on how the packet protocol from the server works. If, as I suspect, the server sends a message only once to the client, and the Comms client has to retain a list of all messages it displays on the screen in memory, then the console will have to retain that list too. OTOH, if an individual message can be fetched from the server or read from the screen, then the console can just scroll through the messages and read them as needed.

The up and down buttons basically scroll through the messages. Each message has a number, and the Time and From values read from the server. The age of a message may have to be updated in real time. The Comms officer scrolls through messages with the available info, and presses the Replay Message button when the desired one is selected. This will playback the message to the Comms officer's speaker or headset. I suppose a preview of the text could be shown, but I'm trying to keep digital displays to a minimum.

When a new message comes in without interaction from Comms, it is just played on the headset, and the message display updates.

The Red Alert button, of course, is self-explanatory. I also haven't included any DMX lights or anything like that, they could be added to this layout.

Note that it may be necessary to "refresh" the selectors from time to time by polling the server again. Targets are listed in order of distance, so it changes every time you open the menu. Presumably, this is why the server has to send a new list to the client every time the menu is opened. (If it does not, then we will have to store and update the distance information like the client does)

User McUser

Posts: 123
Reply with quote  #34 
Originally Posted by ryleyra

Okay, I threw together a quick and dirty diagram which I think should be a good starting point for designing a Comms console.

Wow nice, very streamlined!

Instead of Text To Speech (TTS), you could add a multiline segmented LCD to display messages. Or do both I guess, but TTS seems harder to do to me.

Does Artemis limit itself to a maximum of 10 each enemy and friendly ships? I honestly never thought about it before now, but you don't want more ships than you have dial positions...

Posts: 3,007
Reply with quote  #35 
I just found out that apparently Glitter is capable of a lot of this. There is already a proximity sensor, which could be part of Helm. And Ivan Sanchez is already working on most of the things for Comms I described above, including text to speech. So I'm looking forward to seeing what he comes up with. [biggrin] (He also suggested audio for Science, reading off scan info like Spock's Library Computer, which sounds neat)

The Comms menu is not limited to 10 options, but that's all that can be accessed through keypresses, so I think that's sufficient. Since the list is in order of proximity, it changes constantly, so you can access any ship, you just may need to fly closer to it than other ships.

I'll note the friendly ship menu and player menu also have more than 10 options. The extra menu options will probably have to be accessed by mapping a button press to a program that clicks on a spot on the screen. You could probably change the selector to a rotary dial that rolls around to the first ship after the last one, but that would have to use that kind of mouse click workaround. Glitter might be capable of sending a packet back to the server, bypassing keypresses.

The concept here is really to have completely audio Comms, like Uhura's station in Star Trek. It's more realistic, and would mesh more seamlessly with voice chat. While I can see computers in the future parsing speech and displaying a text version, for record keeping, messages coming in would not be text. Of course, Artemis can only simulate that, so we need to turn text into audio.

Note that there is a button for "Play an Audio Message" on the Comms console, for use in missions. It appears on the message itself. That button would not need to be on this console, because pressing the "Replay Message" button would just play the message, instead of using Text to Speech. [biggrin] More general Comms do need that button, unless you just use the touchscreen for that function.

One button that could be added is a "Audio to Bridge" toggle that would route the Comms' audio to the Mainscreen's speakers, so everyone can hear it. Mission audio files would automatically be played to the bridge. Maybe it does need to be a separate button. (One to play the text to speech and one to play the audio file)

Posts: 108
Reply with quote  #36 
at last! 6 consoles [smile]
even one for the capitain

I'm now going to start on a 7th addition to the collection, for certain missions using keypresses.
more to come...


Posts: 3,007
Reply with quote  #37 
That's pretty nice. Although the captain's should be sized for the arm of a chair. [biggrin] (The screen can be put on the other arm)

Posts: 108
Reply with quote  #38 
it's true, but I have to clear up a classroom after we've finished, Making a cool chair is fine but it wont fold up afterwards [smile]

Posts: 7
Reply with quote  #39 
Question on everyone's console ideas.

Instead of just left/right arrow to change frequencies, how can you select A, B, C, D, E and just hit one button to switch to each?

I've been working on an Arduino setup (I'm no programmer by any means) and I'm finding this task nearly impossible.

Same idea with weapons.  Shift + 1, 2, 3, 4 to load AND fire the tubes - Unless your using a mouse, there is no longer a way to unload the tubes. I think this used to be 7, 8, 9, and 0 previously.

I love the game, but would like to see EVERY button input correspond to a single key press, or combination that stands out from another.  Even your view screen needs the mouse control.  There would be so many options for consoles and buttons if we had everything mapped to individual keys.

Not sure how the programming works, but it would be interesting to see the option to map you own keyboard bindings.

I'm honestly trying to eliminate the keyboard entirely, and only use a trackball, if needed.

The pen is mightier than the sword.  Unless, of course, your opponent actually has one.
Previous Topic | Next Topic

Quick Navigation:

Easily create a Forum Website with Website Toolbox.