[New release] The "Lockdown" update.

With the whole world on lockdown, it is time for an EE update.

This update contains a bunch of things. First off, things related to internet play, as what to do when locked in your home? Play EE on the internet.

  • You can enter your name, and this shows in the ship selection for reach selected station. So you can see who does what.
  • Build in voice chat. With [`] key to talk to your own ship, and [backspace] for the whole server.
  • A proxy server, for better distributing network load and hosting behind firewalls that do not work with port forwarding. (More on this later)

Next to this, the translation system is in place. This allows for a localized UI and scenarios. But nothing is translated yet. Language selection needs to be done with the options.ini file.

By my guess, enough can be translated to make the game playable for people that do not speak English. Note that any comms messages will be in the language choice of the server. So if you put your local client on a different language, you will still see English in relay.


There are also various other small improvements and additions. Know that this was an effort of multiple people, on code changes an testing effort.


About the proxy. It is a relatively simple application that sits between the server and multiple clients. So there is only one connection to the server and multiple clients connected to the proxy. The server only needs to send updates once and the proxy will send it to all clients. Putting the bandwidth requirements on the proxy side.

This allows for running a proxy on for example AWS, while still running your server locally and giving easy access to the GM console.

Documentation is up at https://github.com/daid/EmptyEpsilon/wiki/Proxy-Server but can always use some improvements.

Comments

  • Very cool.

  • edited March 23

    Many thanks for your work on this daid!

    I will help to update the wiki on the proxy server.

  • Nice! Integrated voice comms allowing separation of intra- and inter-ship communication is brilliant.

    The ability for the Relay officer to use voice communication with the relay officer of other ships would be a great extension of that feature.

    That proxy server is brilliant and will be super handy. I will always be running one of those on my computer so that my 4ish connections will not overload my computer's WiFi chip.

  • The proxy server was one of those things I always knew wasn't a lot of work (due to how EE's network code is designed) but never had a reason to do so. Until Kilted Klingon had a use case for reliability reasons on his ~100 clients event. Once I made it, I discovered there where other use-cases as well.

    The voice chat is easy to expand:

    This function figures out who the targets are of a voice transmission. Filtering on selected stations would be easy.

  • How does the voice chat work?

  • You hold [`] or [backspace] and you talk into your microphone.

    Or, on a technical level? It uses SFML to capture voice data, encode it with http://opus-codec.org/ and send it trough the network, where it gets decoded again and played back as audio.

  • Yeah, I meant on a technical level, sorry for being ambiguous. Thanks.

  • If you don't mind I have a couple more questions about the voice chat. Started looking at opus, looks pretty cool. But it doesn't support 44.1khz audio. I noticed you have a bunch of 44.1kHz audio files in EE. I didn't see anything in the playback code that would know the sampling rate was (or wasn't) 44.1kHz. Are you resampling the 48000Hz opus decode to 44.1kHz before playback, or maybe your audio library is somehow smart enough to know to do that, or are you just playing the 48000Hz audio at 44100Hz (or vice versa)?

  • SFML's audio streams can run at different sampling rates. So I just run the voice at 48000.

    But, I did notice there is a CUSTOM_MODES define in the opus code, which isn't documented. But in the code it says that it enabled other sampling rates.

    Also, recoding at 48000 and playing back at 44100 didn't even sound that bad, as I did that by mistake at first.

    The important classes are:

    https://github.com/daid/SeriousProton/blob/master/src/networkRecorder.cpp

    https://github.com/daid/SeriousProton/blob/master/src/networkAudioStream.cpp

  • Thanks. I also was wondering what would happen if you record at 44.1kHz, tell Opus on both the encode and decode phase that it's 48kHz, then play back at 44.1kHz. All the frequencies for e.g. high pass filtering and whatever other DSP magic it's doing would be off by 10% or so, but sounds like it's worth trying as a first attempt. Portaudio (what I'm using for audio) is a bit lower level, it's not clear to me if I can have multiple concurrent playback streams at different sampling rates with it, and the playback stream I have is 44.1kHz. I suppose for VOIP application a lower sampling rate, e.g. 16kHz could make sense.

  • Note that the opus documentation states that capturing at a lower sampling rate does not lower bandwidth requirements, just lowers quality. So there isn't a real reason to do so.

    And if 44100 capture with 48000 encoding gives bad sounding results, you could switch the encoder from OPUS_APPLICATION_VOIP to OPUS_APPLICATION_AUDIO, which should preserve all frequencies better at the result of more data.

  • Well, we played some EE today. I tested the proxy server and successfully had 6 clients running on my computer communicating to a proxy client on the same computer. I have had trouble running even 3 before--the bottle neck was defiantly in the network bandwidth.

  • Pushed a new release yesterday. This fixes the tutorial crashing. And adds the ability to select the main screen next to a station. As well as various other changes and fixes.

  • Thanks for getting this running; our college Sci Fi club is holding our usual spring convention entirely online, and we wouldn't have been able to run bridge sim without the proxy server update.

    For reference, I'm running the 2020-04-09 version (current as of this comment) with a cloud server (Ubuntu 18.04, headless) with the proxy=listen option, then connecting to it with the EE server from my (Windows 10 Pro, x64) desktop to be the GM screen, and then two other EE clients on my desktop to be able to see the viewscreen and player screens. (Almost all of our players are new and need some coaching :)

    I want to stress that I'm a big fan of EE for the last couple of years (after several years of Artemis before that; I have two ship licenses for Artemis, but haven't used it in ages), and have considerable respect for the dev(s) for making it work at all. However, in the spirit of making it better for everyone, following are some minor to moderate problems and suggestions we've encountered:

    A) There are a *lot* of errors complaining about OpenAL every time I run EE on my cloud server; probably because as a headless server in a data center rack it doesn't do sound. Can we get a "noserversound=true" or "serversound=false" option or something along those lines?

    B) The Linux version (.deb) doesn't support the common "--help" or "--version" options, which should generally give useful console output without trying to actually open X11, etc. Nor does there seem to be a man page entry created for it.

    C) This is the most annoying one: The GM screen can back out to the scenario selection page, but for whatever reason it resets everything to the default, rather than what was last used; and when one clicks the arrows next to "LAN" to change it to "INTERNET", it locks the client up completely (grayed-out screen, have to kill it from Windows). Once this has happened, I then have to basically start from scratch; re-start the headless EE proxy script (plus, see below for problems on that), then re-start my EE server from my desktop, and get all of my screens and the players to reconnect clients. Aside from fixing whatever bug causes the lock-up, having an option on the headless proxy server to keep it running when the "real" server exits would be nice ("persistent=true" or something?). In an even more ideal world, you could set some sort of timeout (e.g. "persistent=6h").

    D) The clients seem to be keeping some sort of network connection open, even after they're back to the main EE page. If I restart the EE proxy server after the above, it will give a "failed to bind to port XXXXX" error and fail, unless all of the clients have exited back out completely to Windows.

    E) Having an "Incoming Call" pop-up someplace other than Relay would be helpful (main screen, like the global push messages?). We are frequently running with small groups (2-4 players); and in general the Operations screen from the 4/3 player screen isn't nearly as functional as having that player have both Science and Relay selected; but it's problematic when a scenario sends a message and the player isn't on the correct screen to see it.

    F) Somewhat scenario related, but the audio messages are problematic when they go away on first click and don't put the corresponding text in the log. We had an issue where someone didn't know to click on them, and then clicked on several at once, making an unrecognizable jumble and then there didn't seem to be a way to get them back.

    G) Ships, especially fighters, keep getting stuck on (or even inside) the larger stations. Particularly problematic is the case where a NPC ship (freighter, etc.) is docked, and the fighter, in attempting to circle the station at 0 range, gets wedged between the freighter and the station. In general, ships want to close to literally touching range far too often (see also H on beams being too short).

    H) In general, we have found that new players are not good with "broadside" missile ships (side HVLIs are too hard to aim and too small a magazine to fire casually; side Homing don't curve /track well enough); also, most ships have beams that are too short-ranged, too weak, or both. (Normally, when I have run EE as a LAN game at cons in previous years, I had a custom (Enterprise E-inspired) ship and scenario(s) for them, but that's not really practical with remote play with strangers, where you really have to stick to stock.) After some flailing around, we've currently settled on the Crucible as the best starter ship for new crews out of what we've tried; the forward-oriented armament helps considerably in having people not get as frustrated as with the default Atlantis, which really isn't a beginner ship.

    I) The lack of an organized mod-loading or scenario-publishing infrastructure hurts a lot more when you're dealing with distributed players all over the world. I ran out of time to experiment, but does the scenario file have to exist on the player computers, or only the GM server? The ability to push out a custom ship from the server would be very helpful, although I realize that's probably a lot of work.

    J) Some sort of counter that can be used to give a score would be very helpful. Especially on something like Battlefield, where the player ship is not the only one in the quadrant. Solo kills and assists, total hull damage done, or something that can be used to give a quantitative / comparative "how did we do" value.

    K) Similarly, several scenarios end in "Defeat" with no explantion unless there is a GM and they are paying attention, if for example a required station somewhere far out of range gets destroyed. Some sort of explanation to the users as to what scenario criteria was violated would be nice, ideally with the ID. E.g. "Defeat! Condition "All allied stations must survive" failed; Station 'Armstrong' destroyed"

    Again, thanks for all the work so far; we've had a 4-hour session Thursday, a 3-hour session tonight (Fri.), and are expecting to do 2- and 4- hour sessions tomorrow (Sat.). Aside from the issues above, once things are up and the scenarios are running the experience has been very smooth; we even tried the Battlefield 30-v-30 with a skeleton crew and there were no performance problems (and they only died once).

  • edited April 25

    Further thoughts as I review my notes:

    L) I wasn't able to figure out how to delete a nebula I had accidentally placed on top of some important stuff on the GM screen. Aside from being able to specificaly do that (possibly including a better way to specify which of various nearby or overlapping things you are trying to operate on), the screen could really use an "Undo" button.

    M) The auto-generated asteroid field is way overkill; something between "place one" and "place hundreds filling the sector" would be useful.

    N) Some sort of allegiance / hostility information on the GM screen would be very handy. One of the sessions was fairly free-form "I plunk down problems and they go fix them", and I had to keep flipping back to the lua file to sort out who would come in as hostile to what.

    O) Planets are bizarre at so many levels, and hard to work with as a GM. The free-form "Empty Space" based session ended up with an Earth+Moon orbiting wildly in the middle of where we were, and it kept confusing and annoying everybody. "Why is Earth drifting harder than someone trying to smoke their tires around a sign in a bad TikTok gif?" was one of the quotes from Helm as they nearly got sideswiped again. There didn't really seem to be a way to manipulate it from the GM screen, nor any sort of clear display of where its path would sweep out.

    P) Several scenarios ("Delta Quadrant Patrol Duty" was one we played in particular) claim to use Reputation as a cost mechanic, charging for more missiles, replacement damage control crew members, information on economic conditions, etc. But there wasn't any obvious way to see either the current Rep, or what would / did earn you Rep, whether for players or the GM. Presumably there would also need to be a GM control to modify Rep, and/or a toggle to ignore the mechanic completely.

    Q) There are some related balance issues, in that beams don't cost Rep, only power (which in a pinch can be restored by yourself by lurking out of the way with the reactor up), putting beam-based ships at an economic advantage. (On the flip side, right now there aren't many effective ones in stock.) Also, nukes should probably cost a lot more compared to mundane ammunition (or be less effective, but that's less fun). A couple of years ago, one of the LAN games I ran decided to just nuke everything bigger than a fighter, and it wasn't as problematic as it should have been.

    R) Related bug: in the scenario "Delta Quadrant Patrol Duty", a few screens would come up with odd float values for Rep costs: "This ship will tell you its destination for 3.042557 Reputation" sort of thing.

    S) The player name entry field needs to be clamped to some reasonable length (and, probably, filtered against random Unicode, weird character sets, control characters, etc.). I had someone enter their name as basically "Nooooooooooooooooooooooooooooooooooooooooooooooo" and while things surprisingly didn't break too badly, it wasn't good.

    T) I thought it used to be possible to (re)name the player ship from the spawn-a-ship screen, but I'm not finding the option. Whether I'm remembering correctly or not, it would be handy. (Might also be a good idea to have a toggle on the scenario screen for ship rename ability: None / GM Only / Any Player.)

    Side note for others considering doing what we did: We ended up using a voice chat channel on the virtual-con's Discord for everything; while having built-in chat is a good idea, it doesn't function until people are already set up and in the game. With random new folks dropping in and out, needing help getting the client installed and configured, and trying to figure out who ends up with which bridge stations, it was just easier to use a persistent external voice chat room.

  • A) The OpenAL warnings are harmless, which is why i did not put effort in preventing them when running headless.

    B) Not going to put effort in man pages. Sorry.

    C) Never seen that happening for me. Maybe it is seeing multiple escape key presses instead of one. As a workaround you can exit the GM screen with the home key instead of escape.

    D) That is not the clients, but linux keeping a socket in "time wait" after it closed. It is possible to prevent, but sfml is not making that easy.

    E) Not sure how to handle that without changing the experiance if you run a normal setup.

    F) Report it to the scenario creator.

    G) This is more of an issue that for large stations, AI ships still try to hit the center. And their beam size is so shot that the will fly into the station then. Getting stuck inside is impossible.

    H) Git gud if you want the bigger ships. This is intentional.

    I) Scenario scripts only need to exist on the server by design. And scenarios can modify a lot of ship properties.

  • Adding my to cents two the discussion.

    J) Some sort of counter that can be used to give a score would be very helpful. 

    This can be done via scripting in a mission scenario (ShipTemplateBasedObject:onTakingDamage) But having a counter and display in the game engine itself would be conter intentional in my opinion. Usually the scenarios are not about individual achievements, but what the crew (or fleet) achieved together.

    L) I wasn't able to figure out how to delete a nebula

    You can use modifier keys on the GM screen. As far as I know it's only documented in a changelog. But use CTRL to only select ships and stations and ALT to only select things matching the faction selector in the top left. Nebulas, Asteroids etc are always "Independent". You can also combine the modifier keys to be very specific.

    L) "Undo" button

    This is close to impossible as scenarios would need to be aware of that possibility. An optional confirmation screen would be an option though.

    P) Several scenarios ("Delta Quadrant Patrol Duty" was one we played in particular) claim to use Reputation as a cost mechanic, charging for more missiles, replacement damage control crew members, information on economic conditions, etc. But there wasn't any obvious way to see either the current Rep,

    Reputation is shown on the Relay Screen (exclusively, AFAIK)

    P) or what would / did earn you Rep, whether for players or the GM.

    The base game gives you RP for enemy kills. But scenarios could change that.

    P) Presumably there would also need to be a GM control to modify Rep

    Its when you select the player. Then Tweak -> Player -> Reputation.


    Maybe you could think about doing some mission scripting to get the experience that you imagine for your group. Some of the things you mention are rather easy to change in mission scripts (like prices, the availability of missiles, keeping score, planet rotation, asteroid fields, etc). The "old" scenarios are usually not as fleshed-out as the newer ones - partially because the Lua API grew over the last years.

  • @Miuramir I have not visited this forum in a few months, hance the comparatively slow response. I recognize that I wrote the scenario mentioned in (F), where the audio playback is triggered by Relay via button, but I can't recall the specific scenario. Please identify.

    Regarding (J), as @xopn mentioned, it's up to the scenario writer whether to track and report progress (or score) for a crew or a team of player ships. Most scenarios don't have any progress details. One that has some is Borderline Fever.

    Similarly, for (K) it is up to the scenario write to provide a reason for victory or defeat. Usually, it's only visible on the main screen (if at all). It's possible to send a custom message to each of the 5 main consoles, but again, that would be up to the scenario writer.

    I'm also the author of Delta Quadrant Patrol Duty. In (P) you asked about the reputation cost for certain things. I made a conscious decision not to provide that information until the player ship docked with the station where that cargo could be purchased. In other scenarios, that information may be more readily available. For (R) where the reputation amount has a number of positions displayed after the decimal point, yes that's a scenario bug. I found most of those, but obviously not all of them. I intend to get back to this bug (and other bugs), but I haven't been able to lately. Anyone can fix these and contribute to the Empty Epsilon repository with a pull request (and some already have).

    Yes, different ships have different advantages as described in (Q). Generally, this is a good thing: diversity in a cooperative fleet gives a greater number of options to choose from to complete the mission. Also, a scenario can be run with different player ships to give a different experience. As @xopn mentioned, the game and the scenarios are designed to be cooperative, so it should not matter that one player ship has different advantages vs another.

    I'm glad you're enjoying Empty Epsilon. I'm glad you're enjoying the scenarios. I appreciate the feedback: it gives me the opportunity to adjust to make the experience even better

Sign In or Register to comment.