[GAME] Space Nerds In Space

1234689

Comments

  • That's a pretty expensive setup for a bridge Sim! But it's totally worth it
  • I have added a *completely untested* DMX lighting library to the my codebase. Before you get too excited (as if), know that this code is not linked into any executable at this time.

    I wrote it without having access to any DMX hardware, based only on a few things I read on the internet. This means my DMX code almost certainly doesn't work. So why am I telling you this? Because there are some people around here who do know a thing or two about DMX and how to drive such devices from linux, and I'd like to get some input about my code if possible.

    Setting the baud rate of the serial port to 250000 is unusual enough to require some black magic, and I think I figured out how to do it, but, as I mentioned, I've not tried it out yet. Also, I am unsure about sending BREAK and the "mark after break" that the DMX protocol specifies. I took a stab at it, but I doubt I got it completely right.

    If you'd like to take a look at the code, it is here:

    https://github.com/smcameron/space-nerds-in-space/commit/06b35a69e5e145e054607a0a136eb557b62ea743

  • You could check if with my code:
    https://github.com/daid/EmptyEpsilon/blob/master/src/hardware/serialDriver.cpp
    https://github.com/daid/EmptyEpsilon/blob/master/src/hardware/devices/dmx512SerialDevice.cpp
    This is known to work with the DMX hardware out there.


    Took a quick look at your code, "tcsendbreak" with any other parameter then 0 gives undefined behavior. Some drivers might not add a break at all with low values, other gives very long breaks. Some drivers do nothing with tcsendbreak, ever. (Arduino is one of these)
    So I tried changing the baudrate to a low value and send a single 0x00 byte instead. However, this shows another bug, where some drivers introduce a small glitch on the line when changing baudrates.

    Instead, on linux, you could use the TIOCSBRK and TIOCCBRK ioctl calls instead, and time the pulse yourself. This has the same "problem" as tcsendbreak, that it some drivers do nothing. But it does give you better control of the timing.



    I do have some Arduino code that ignores the lack of the break, and uses a timeout to detect the start of the message. That can allow you to test some of the code. But as I mentioned, the break part doesn't work with the Arduino serial drivers.
  • Thanks. Looks like my baudrate setting code is correct, or pretty close.

    The man page for tcsendbreak says this in the notes:

    The effect of a nonzero duration with tcsendbreak() varies. SunOS specifies a break of duration * N seconds, where N is at least 0.25, and not more than 0.5. Linux, AIX, DU, Tru64 send a break of duration milliseconds. FreeBSD and NetBSD and HP-UX and MacOS ignore the value of duration. Under Solaris and UnixWare, tcsendbreak() with nonzero duration behaves like tcdrain().
    I suppose it may depend on the particular driver though, so "linux" might not be the right level of granularity for the question of what tcsendbreak does with the duration value.

    For the Mark after Break, after looking at this diagram, http://naidepot.blogspot.com/2014/05/uc-based-dmx-transmitter.html

    I think I can do the tcsendbreak() with a 0 duration followed by writing 0xff for the "mark after break" then there will be two stop bits from the driver (becoming part of the mark after break) then write 0x00 (NULL START byte) then the 512 bytes of dmx data... and I *think* that should work, maybe... if I am lucky.

    I added a test program...

    scameron@sirius ~/github/space-nerds-in-space $ make test_snis_dmx
    CHECKING for struct termios2... not OK. We will define it ourself.
    COMPILE snis_dmx.c
    scameron@sirius ~/github/space-nerds-in-space $ ./test_snis_dmx /dev/null
    snis_dmx.c:236: NOTICE!!! This snis_dmx library is COMPLETELY UNTESTED as
    snis_dmx.c:238: I currently do not have any hardware I can test with.
    snis_dmx.c:240: Do not be surprised if it utterly fails to do what you want.
    snis_dmx: ioctl TCGETS2 failed: Inappropriate ioctl for device
    Failed to start DMX thread on device '/dev/null', Inappropriate ioctl for device
    Instead of /dev/null, I should give it the serial device for some DMX hardware chain, but I don't have any hardware.

    If someone does have some dmx hardware and could try it out, that would be helpful.

    It will attempt to turn on all 512 devices at full brightness for 1 second, then off for 1 second, then on for 1 second, etc. 20 times (or hit ctrl-C while the lights are off to stop it early.) I have never tried it myself though, so fair warning.
  • From the wreckage of a derelict ship, some disturbing footage was recovered....

    https://www.youtube.com/watch?v=woMkFN47U-Q
  • Just a little update about what's been happening in Space Nerds over the last few weeks.

    https://www.youtube.com/watch?v=Jzj4CSFYD6s&feature=youtu.be
  • The audio mix on that last video wasn't very good. Here's a better version:
    https://youtu.be/tWeQyX2jDWY
  • I've bought the domain spacenerdsinspace.com and rented a droplet on digitalocean and put the majority of the SNIS assets like images, audio files, and stl model files on it, so now it is no longer required to have OpenSCAD nor build the stl files. Now "make" no longer builds the OpenSCAD models. Instead, you can just download them (and a lot of other stuff -- extra solarsystems, mostly) with "make update-assets". However, if for whatever reason you want to build the models yourself, you can of course still do it via "make models."
  • edited April 2018
    I've been thinking about comms, and comms power, which currently doesn't do anything and I had an idea. What if there is a high gain antenna which can be aimed. You can receive signals regardless, but in order to transmit successfully, you have to aim the high gain antenna at what you want to communicate with by entering a "bearing" and "mark" (once) and then the antenna will move to maintain the requested bearing and mark. Suppose also that it is mounted on the top of the ship, and so has a limited range of motion, so now Comms has to coordinate with Science (to get the bearing and mark to the target) and with Nav in a manner similar to weapons -- if he wants to transmit, the ship must at least be oriented such that the antenna is capable of pointing in the right direction. Also, comms could be blocked by planets or nebula between the antenna and target.

    Maybe the antenna doesn't maintain bearing an mark so swiftly if deprived of power?

    Maybe if the antenna is more than say 45 degrees off target, receiving starts dropping/garbling some small fraction of characters? Well, maybe that's too annoying.

    Hmm, I think I will try implementing it and see how it is.

    Edit: Hmm, for close targets, there might be wild swings in the required aiming, say, if you fly past a starbase, but, for close targets, the aim probably shouldn't matter -- that is, comms should only be affected by the aim if the target is beyond some distance -- for close targets, the aim should not matter. However, usually what little communication you need to do involves a nearby starbase (e.g. requesting docking permission). So that means most of the time, the aim will be irrelevant. However, it could still be relevant for mission scripts that might require comms with distant entities.

    I've also thought about doing some kind of comms with NPC ships (currently un-hail-able.) But, seems very hard to come up with something that doesn't seem fake. I'd need to implement some passable natural language processing and it just seems nearly unworkable.


  • edited April 2018
    I think the comms directional antennae makes sense and sounds pretty cool. I'm not sure how much more complex it would be to program (and to play, for that matter) but the high gain antennae might have varying designs on a per-ship basis that yields different benefits:
    1. Type/Class/Desc.
    2. Range-of-motion (from bow/0-degrees)
    3. Max Gain factor (or maybe not "factor" per se, but a logarithmic scale that, in the end, translates to simple map grid units worth of range)
    4. Power Conversion Efficiency (or maybe thats overkill with a max gain?)
    5. Subspace Attenuation Factor (kind of a warp-factor for transmissions; subspace transmissions permit FTL communications with very remote objects. The higher the attenuation, the higher the delay in transmission. Pushing more power to the antennae can help overcome this, though)
    6. Frequency Range
    Thus the famous Enterprise has:
    Type/Class/Desc.: The Deflector Dish (which, if I recall correctly, was multi-purpose including subspace radio)
    Range-of-Motion: 5 deg. (fixed, you MUST point the ship pretty much at the direction, the 5 deg is some kind of field focus thing or perhaps a minute threaded mounting adjustment.)
    Max Gain Factor: 7 (nice and high)
    Power Conversion Efficiency: .8 (pretty good)
    Subspace Attentuation Factor: .45 (very low)

    Thus, not very convenient, definitely has to get nav to point the ship, but really high-powered and high-quality and capable of pretty much normal conversation with HQ, even when you are waaaay out in deep space.

    But the famous Falcon has:
    Type/Class/Desc.: Roof-mounted Comm Dish
    Range-of-Motion: 360 deg. (pretty flexible, just have to have target relative elevation between 0-180 degrees, auto-aim away, computer )
    Max Gain Factor: 4.1 (pretty good, but nothing like a giant flagship)
    Power Conversion Efficiency: .7 (pretty good)
    Subspace Attentuation Factor: .7 (okay, almost always will have delays in comms with distant targets unless you are devoting a LOT of engineering resources to this)

    Frequency range attribute maybe yields some limited resistance to attenuation through things like asteroid fields and nebulae.

    In addition to reducing delay through subspace, the Subspace Attenuation Factor, if high enough, may permit a transmission to skip over/around/past black holes.


    A few other thoughts:
    Maybe if the antenna is more than say 45 degrees off target, receiving starts dropping/garbling some small fraction of characters? Well, maybe that's too annoying.
    If you decide it is not too annoying: one very specific scenario or capability this enables: a faint and garbled transmission from an unknown location could be discovered by players through sweeps for direction finding. Kind of like playing warmer/colder game with an automated distress beacon or something.

    This more complex antennae thing also maybe opens up possibilities for upgrading the antennae on a ship.

    Inter-solarsystem/server comms only possible with antennae with favorable stats and tons of power coursing through the high-gain antenna.
  • edited April 2018
    None of the changes described below are yet committed.

    I have implemented what I think is the hardest part of the high-gain antenna feature. You can aim the antenna with a "/antenna heading mark" command on comms (e.g. "/antenna 270 30" to set the antenna to bearing 270 mark 30), and the antenna will try to do this, but can point straight ahead or ptich up to plus-or-minus 90 degrees up and down or yaw up to 90 degrees left/right thus covering a hemisphere centered on the front of the ship. It cannot point towards the back of the ship.

    On the Nav screen I have added two directional indicators (similar to the current science and weapons indicators) which show which direction the high gain antenna is currently aimed, and the desired direction of the antenna. If the desired direction is more or less towards the front of the ship, then these two indicators overlap and indicate the same thing. Otherwise the current antenna direction is as close as it can get to the desired direction (it will be in the ship-relative y-z plane), but does not match it.

    I have not yet implemented any consequences to comms.

    The way comms works, you transmit on a channel, and anybody tuned into that channel can receive messages transmitted on that channel. There is no notion of "intended recipient" or a "connection". This means to transmit, the code needs to loop through each possible recipient, check which channel they are monitoring, and if it's a match attempt to deliver the message. Hailing is accomplished by switching hailer and hailee to the same randomly selected channel. The new part of this would be say, constructing a vector from transmitter to candidate recipient, dotting that with the current antenna direction and only allowing the transmission to go through intact if the dot product was greater than some threshold, otherwise "attenuate" the message in some way (e.g. drop it, scramble it to some degree, etc.) Because there is no notion of "intended recipient" there can be no warning if a transmission does not succeed due to antenna mis-alignment. Of course there can be a warning if the antenna cannot reach the desired direction (e.g. the desired direction is more or less towards the rear of the ship), but if the heading and mark are entered incorrectly, so that the desired and actual direction of the antenna match, but your intended recipient is in the opposite direction, you cannot be warned that your message wouldn't be delivered.

    I have also not implemented any checks for interfering nebula, black holes, or planets or other space junk between transmitter and receiver.

    I also imagine that for close communications (e.g. hailing a starbase for docking) the antenna aim would not matter. If that is the case, when would it matter? When you are communicating with e.g. distant starbases -- and when would you do that? I am wondering if the combination of infrequent applicability of the antenna aiming combined with the necessary lack of feedback when some intended recipient is out of the antenna's aim might lead to unpleasant confusion on the few occasions when it matters. I like the "idea of the idea", but I'm not sure I like the idea itself.

    As for having different ships with different antenna configurations -- right now, only the wombat is playable, and this is currently pretty baked into the client code in the rendering for the nav, weapons, and main screens. It could be changed, but it's not a priority and I'm not sure it's worth it.

    As for ship upgrades, I have resisted this for a few reasons. This is meant to be a multiplayer game. The nature of it, requiring people to be in the same room with a load of computers means that in most cases, this will be a transient gathering... people might play it for an hour, a half hour, and then somebody is likely to have to leave for whatever random reason. If there are persistent upgrades, who do these belong to? (answer: whoever owns the computer the server happened to be running on). If people care about these upgrade (i.e. went through some slog to get them) then they're going to be disappointed if they get clobbered (thus now some stability requirements are imposed on the data storing this stuff.) If you have multi-crew, then upgrades tilt the playing field. So I'm not super keen on upgrades.

    As for inter-solar system comms, there is no infrastructure for that to happen at present, all comms is currently mediated within a snis_server process, and there is no snis_server to snis_server comms bridging of any kind, and I am not too keen on setting out to re-invent IRC -- re-inventing unix "write(1)" command is about as far as I'm willing to go, I think.


  • edited April 2018
    Another perspective altogether -- though still within the presumption that the only meaning of power level to comms is transmitter antenna energy--

    Diminish the general importance and frequency of managing power supply to comms. Make "full" power not that costly, so it rarely is called upon to sacrifice for other systems. Pretty much only when we need "every drop"for some desperate measure. Maybe also when you want to "go dark/stealthy" so you don't throw off detectable emissions. Other wise engineer will probably just leave it at nearly full.

    Then, all comms work all the time, everywhere, mostly. If comms is receiving too little power, it's transmissions are slightly garbled for everyone just don't bother checking anything other than transmit power (and possibly antenna module damage, if damcon-able module ever created). It makes some trade-offs and quantizes experience a bit perhaps. But players imaginations might full in the gaps while the back end remains suitably simple.
  • I've just pushed the antenna aiming code. By default, it is disabled. To enable it, type in "enable_antenna" on the demon screen. To disable it, type "disable_antenna" on the demon screen. Those are just lua scripts that call a C funtion to set a global variable on the server. The clients will display comms arrows on the nav screen if the antenna aiming is enabled, and comms may fail to work (e.g. unable to hail a starbase) if there is a planet, nebula, black hole between transmitter and receiver, or if the distance is too great, or if comms power is too low.

    From a user perspective, comms not working due to these types of things is not super-distinguishable from comms not working because the program has a bug. That's not ideal, and I fear I've written a lot of code which has the net effect of making things seem buggy, even if they aren't. Which is why it's disabled by default. Also possible I've introduced actual bugs that I am unaware of.
  • smcameron said:

    From a user perspective, comms not working due to these types of things is not super-distinguishable from comms not working because the program has a bug. That's not ideal, and I fear I've written a lot of code which has the net effect of making things seem buggy, even if they aren't. Which is why it's disabled by default. Also possible I've introduced actual bugs that I am unaware of.

    Artemis has that issue with enemy cloaking systems. Maybe some indication that the comm system itself is working, but that the signal is too weak and needs to be aimed?
  • Tangent on the "bug or intended limitation, and hard to distinguish" issue: on Science LRS, it is sometimes difficult to select a distant target, even if the name appears. I think that sometimes it is a distance limitation, sometimes nearby objects obstruct receiving the click, or something like that. But I can't tell when I click and get no feedback. I find myself thinking that some kind of feedback, even if its kind of not completely conclusive.

    In the Science case: maybe a click that is recognized but on an object that is too far results in the client interface making a brief show of "trying really hard" (some kind of message or small sound effect or geometric "seeking"/"processing" kind of thing) followed by a failure sound effect. If no response at all, I will more strongly suspect the click didn't register or something is in the way.

    I see the dilemma in any kind of similar positive feedback in comms. The uncertainty is part of what you are trying to simulate. On the other hand, an entertaining moment in a mission scenario: player ship is tasked with establishing a repeater network in a celestial-object dense region of space to permit comms with deep-space research station. After placing the first repeater buoy/station, a "chatty" operator on the deepspace station just lights up the channel while your ship proceeds to place the backup-route repeater in an alternate location. Half way there, the chatty operator's signals are just cut off mid-sentence. Research station not responding; hmm.. what happened?!


  • jrwarwick said:


    In the Science case: maybe a click that is recognized but on an object that is too far results in the client interface making a brief show of "trying really hard" (some kind of message or small sound effect or geometric "seeking"/"processing" kind of thing) followed by a failure sound effect. If no response at all, I will more strongly suspect the click didn't register or something is in the way.

    This commit may help with that specific case.
  • edited June 2018
    Quite some time ago, I added the capability for speech recognition (using pocketsphinx) and some rudimentary Zork-like natural language processing to Space Nerds In Space. However, like a dancing bear, the speech recognition is remarkable mostly in that works at all, not because it works so well. Especially, background noise is a big problem, but also accents, talking too fast, and mumbling slightly will make it not work so well.

    The speech recognition is done in a separate process and the text which it produces is fed into the game via a fifo that snis_client monitors. This means the speech recognition can be replaced relatively easily (assuming the existence of an alternative). It occurred to me that if I had an android app which could do speech recognition (should be easy enough, right?) and then forward the recognized text to an arbitrary TCP socket, then I make some little program to forward this text from this TCP socket to the fifo. In fact, I don't even need to make something, I can just use netcat for that. However, I don't really know anything about writing android apps, and it's been almost 20 years since I even tried Java. If I were to do it, there's considerable static friction before I can get moving.

    I mentioned this idea to Max Redmond, a member of my local hackerspace (these days, that's HackRVA) and hey presto, now we have an android app that does exactly what I imagined.

    It's here:

    Source code: https://github.com/Athulus/SpaceNerdsCommunicator
    Releases: https://github.com/Athulus/SpaceNerdsCommunicator/releases

    To use this with SNIS, find out the IP address of one of the machines running snis_client, then
    run this in a terminal:

    netcat -lvk -p 8080 > /tmp/snis-natural-language-fifo

    Then run the app on your android device, set the IP address, and then you can hit the microphone button and talk. Android will do the speech recognition (and do a much better job of it than pocketsphinx does) and the text will get forwarded to netcat and then into snis_client, and finally to snis_server, where it will be processed. It does not have the "Computer" hot word though.

    It occurs to me now that unlike the fifo, the socket is a 2-way communications channel, so it might be worthwhile to set up a special socket for getting the NL text into snis_client and use that instead of or in addition to a fifo so that responses could be sent back to the android device as text (and then maybe text-to-speech). Then you could operate the ship from a phone remotely and at least get the responses from the computer instead of operating completely blind. Not that it would be super useful to try to play the game remotely via voice control without any visible output.

    Perhaps a role-play mission where you're stranded on a planet, and you have to bring the unmanned ship into orbit around your planet using voice alone. i.e. "Set a course for planet X", "full speed ahead", "how far to planet X" (repeat until the reported number is small enough), "standard orbit", "beam me up scotty". Well, it's not much of a mission, I suppose.
  • Android is most likely using googles speech to text engine, which uses their servers for the processing. You can also use this in google-chrome with javascript: https://developer.mozilla.org/en-US/docs/Web/API/Web_Speech_API
    As far as I understood, this isn't available in chromium.

    It's much better then other options. But it still has a lot of problems if you are not a native English speaker.
  • Here's a picture of Space Nerds In Space, built and running on Windows 10 using the linux subsystem here at HackRVA by member Will O'Donavan. Not that it looks any different than it does on linux:

    image

    Surprisingly straightforward to make it work. Same instructions as for linux just worked.
  • Nice! Figured it would work. I just don't have WSL installed on my Win10 boxes.
  • edited July 2018
    Played a SNIS session for a few hours at HackRVA in Richmond, Virginia tonight. Went pretty well, and was a lot of fun. The game seemed to be very stable. We did find a couple minor issues though [1], [2]. I tried to take some video, although unfortunately I think the video isn't very good for various reasons (loud fan noise, for a start). Still need more scenarios, though the crew was rookie enough that they were mostly unable to complete the scenarios we did try. Even so, people seemed to have a blast.
  • Here's my latest dev update video for 2018-07-27: https://www.youtube.com/watch?v=60oUfXtFlI4
  • Ran a session with 6 clients at HackRVA in Richmond, Virginia tonight. Not a single crash over a period of more than 3 hours, and no restarts of any servers, and no unintentional restarts of any clients. I impressed my own self with how rock solid this thing seemed to be.

    Weak points: 1) Not enough missions scripts. 2) Somebody mentioned some tearing in the graphics (oh well... doubt I can do much about that). 3) For some wirelessly connected clients, lobby auto-detection didn't seem to work (but typing in the IP address manually worked fine.)

    Well, as "rock solid" as it seemed to be, I did have to fix two (1, 2) serious bugs (segfault or hang) a scant few hours before the event, so maybe I was just lucky.
  • And while I took a camera to the event, I so preoccupied with running things that I completely forgot to even take a single picture. Oh well.
  • Six Years of Space Nerds In Space:

    https://youtu.be/RAboPRjI4Vg
  • In case anyone might be interested, there are some live bootable x86-64 Arch Linux ISO images with Space Nerds In Space pre-built now. I don't think they contain all of the art assets, but enough to be playable. I haven't tried these myself. You can put these on a USB flash drive then boot up your e.g. Windows laptop from the flash drive and

    https://smcameron.github.io/space-nerds-in-space/#ISOIMAGES
Sign In or Register to comment.