Space Nerds In Space

[smcameron]

Hunting NaNs

What are NaNs? A better question might be what aren't NaNs. NaN stands for "Not a Number", and NaNs are special floating point values that can occur when you attempt to do things like divide by zero or other "impossible" mathematical operations. Most typically in my experience, NaN generation due to dividing by zero happens when you attempt to normalize a vector with zero magnitude. Once NaNs are generated, they typically spread through any calculation in which they are used, corrupting all sorts of calculations and causing weird behavior for anything depending on those calculations (most typically, NPC ship movement.)

Since Space Nerds in Space seems to work pretty well for the most part, I sort of presumed that NaNs weren't really something I was bumping into much -- that my code was correct enough that I wasn't generally dividing by zero much if at all. And I suppose that must have been mostly true -- mostly true in that the game did work well enough, seemingly. But then I tried actually taking a look to see whether any NaNs were scurrying around down in there.

Oh my god... So many NaNs! So the way that you figure out whether you've got NaNs is to enable floating point exceptions to terminate your program and produce a core dump. The code to do so looks like this:

feenableexcept(FE_DIVBYZERO | FE_INVALID | FE_OVERFLOW);

Then you compile everything without optimization and run it, and see what blows up. Well things blew up *immediately*, leaving a core file for debugging. For a day or so, this cycle continued: Compile, run, explode, debug, fix. Many NaNs knew what it was to be roasted in the depths of the core that day, I can tell you!

After awhile, I slew enough NaN generating bugs that things no longer exploded immediately, but required several minutes of running before exploding. Now, I think I only have one NaN bug left (that I know of). And I have a fix for that one, I'm just not certain my fix is really right, so I want to think about it some more before I commit it (or some better fix).

In any case, if you're interested in the gory details, you can check out the bug report on github: https://github.com/smcameron/space-nerd ... issues/236

[smcameron]

I haven't tried this myself, but I have just received word from Dan Hunsaker that SNIS runs fine at 30 FPS on a Raspberry pi 4, including the weapons screen and even hybrid main/nav (probably the most demanding.) This is pretty cool news. May be some thermal issues, so you may want/need a good heatsink and/or fan setup (I'm not up to speed on Raspberry Pi 4 stuff, so I can't really be more specific.) The screen resolution was 720p (1280×720). Also this was running everything on the pi, (snis_server, snis_client, ssgl_server, snis_multiverse) not only snis_client. That being said, snis_client takes the lion's share of the resources, but still interesting to see the Raspberry Pi 4 performing decently as a general purpose computer, including graphics and network heavy apps.

At 1080p, (1920x1080), FPS drops into the 10 FPS range (not really acceptable), and at 720p there's the occasional drop into the 28 or 29 FPS at 720p (not ideal but acceptable) and this might not even happen if you only run snis_client, and not snis_server and ssgl_server and snis_multiverse on the RPI.

If anyone else can confirm these results that'd be cool.

[smcameron]

https://www.youtube.com/watch?v=wdy4ICZqc68

I finally got a Raspberry Pi 4B to try for myself. The summary is that the Raspberry Pi 4B with 4GB RAM is fine for the less intensive screens like NAVIGATION, ENGINEERING, DAMAGE CONTROL, SCIENCE, and COMMS, it's still not really good enough for the MAIN VIEW, WEAPONS or DEMON screens, despite a few optimistic reports I'd received from users. The video is long and boring, mostly taken up with installation, which went pretty smoothly for the most part. Then I try it out at first at the default resolution of 1080p and then at 720p to see if that makes performance good enough. The "easy" screens seem to be fine at either 1080p or 720p (maybe NAV drops to 28 FPS on 1080p sometimes), and the "hard" screens are terrible at 1080p and slightly less terrible at 720p. Oh well.

[smcameron]

Here's a video showing today's progress building physical consoles for Space Nerds in Space. Still early stages, but I have basic control of engineering more or less working. There's a repo for the hardware design and for the portion of code that runs on the arduino in https://github.com/smcameron/snis-consoles The code and plans there are still a bit hand-wavy and subject to change, but kind of working.

Within the space-nerds-in-space repo, there's a new program, snis_arduino, which reads commands from the arduino via usb-serial, and forwards these commands to snis_client to make it so. That is invoked like so:

{l Code}: {l Select All Code}

    snis_arduino /dev/ttyACM0


Assuming /dev/ttyACM0 is the serial port at which your arduino appears. You may have to add your user to the "dialout" group ("sudo adduser username dialout") before snis_arduino can successfully open /dev/ttyACM0. You can monitor snis_arduino's stderr if it doesn't seem to work.

Of course it's all still very much a work in progress, so I really don't expect anyone else to be trying this out at this point (or, realistically, ever, ha.)

[CapnRobberts]

Hello,

I am trying to understand how all the various components of Space Nerds work together, to get a better idea of the system as a whole.
Can anyone verify that my assumptions are correct or not?
https://www.beskararmorworks.com/SNIS_system_layout.pdf

I'm just looking to get a high level idea of what is going on before I dig deeper into it.

[smcameron]

CapnRobberts, yeah, that looks more or less accurate (by which I mean, I didn't notice anything wrong.)

Have you seen this: Hacking on Space Nerds in Space? It's a fairly detailed description of how all the stuff fits together (maybe you have seen it and you're just trying to condense it down to something more digestible).

Feel free to ask any questions. Some of the stuff (esp. multiverse stuff) is pretty hacky as it wasn't designed in from the beginning.

For most stuff, you'll only need to mess with snis_client or snis_server.

For Lua scripts, you won't need to touch any of the C code (unless you happen to need to do something which is currently not supported by the Lua API. If that happens, the first thing to do would be to ask me about it and see if I can update the Lua API or figure some way to do it with the existing API.)

[CapnRobberts]

I had not seen that, I will read it over, thank you.

When the multiverse server is set to autowrangle and starts up snis_server instances on its own, I do not see it use the -i option to specify an initial lua script. How do mission scripts work across servers/systems? Or how is a script preserved if an instance is shutdown then restarted? How would you have a mission script work that needed to go from one system to another? Is there data storage inside the bridge info on the multiverse server that will let lua scripts from one system write data that is readable by scripts in another system?

[smcameron]

IHow do mission scripts work across servers/systems? Or how is a script preserved if an instance is shutdown then restarted? How would you have a mission script work that needed to go from one system to another? Is there data storage inside the bridge info on the multiverse server that will let lua scripts from one system write data that is readable by scripts in another system?

Ha ha. They don't, they're not, you can't* and nope. Lua scripts run entirely within a snis_server instance, and one Lua script cannot communicate with another Lua script in a different snis_server instance, and if a snis_server instance is shut down, the states of any Lua scripts it is running are lost.

The idea of multiple solar systems arose initially to solve the problem of "I'm bored of seeing these same old planets."

The multiverse system and autowrangler silliness were both hacks tacked on later just because I could, and because they're kind of cool, despite the problems they bring. My original design only envisioned there being a single snis_server instance. In every "real" game I've played with other people, we have never even used the warp gates, and always stayed in the same solar system (not coincidentally because every Lua script that currently exists for SNIS is designed to work with a single solar system.)

Lua scripting itself brings some hard to solve problems. For instance, there's no way to checkpoint the game because even if you could check point all the non-Lua stuff (which should in theory be possible, but the infrastructure's not really there), there's no sane way to capture the state of any running Lua scripts, and of course that's related to why it doesn't play well with autowrangler.

I went back and forth in my mind for quite some time before adding the multiverse/auto-wrangler stuff, because it also brings a lot of potential problems. I think I talk about my rationale for including this hackery a little bit in this video, not that you need to watch that to get the gist of it.

* If you wanted to write a some scenario scripts that use multiple solar systems, you could do so but it would require the game master to invoke the lua scripts on each snis_server instance manually, and no information could be passed from one snis_server to another (except by the game master injecting it in some way manually), and if you backtracked and went back to a solarsystem you had previously left, you might notice its state had reverted or changed from what it was when you last left it esp. if the solarsystem got "autowrangled" in the meantime. You could kind of fake some things. For example, if you wanted the players to think a ship was chasing them across the galaxy, you could write a lua script that would spawn in the chasing ship at the warp gate where the players entered a solar system, but it would be up to the game master to trigger this script to add the chasing ship into the new snis_server (and also up to the game master to delete the chasing ship from the old snis_server instance.) This gets to be a little problematic, because the game master screen is actually tied to a player ship, and the player ship is only communicating with a single snis_server instance at any one time. So the game master might need to have multiple player ships under his sole control just for the purpose of triggering scripts in snis_server instances that the actual players are not currently in. This is I suppose an artifact again of the original design only having a single snis_server instance.

At this point I feel I should say that a lot of the "fun" to be found in this game (and other games of this type, like Artemis and Empty Epsilon) is to be found in the players themselves, not actually in the game code itself. There's a role-playing element to it, and if they players aren't that into it (which is fine) they're probably somewhat less likely to have a good time, and this role-playing nonsense can paper over some of the seams as well.

Another point to bring up is because it is so hard to get a group of people together to play, and because invariably after an hour or so, at least one person seems to have some place else they need to be, there's very little continuity between sessions. So the idea of having some long campaign over many sessions where one chain of events leads to another, and there's a long, involved story... just doesn't really seem to work. This genre of game seems to naturally be best served in small, bite-sized, self-contained chunks that are independent of one another.

[CapnRobberts]

Ha ha. They don't, they're not, you can't* and nope. Lua scripts run entirely within a snis_server instance, and one Lua script cannot communicate with another Lua script in a different snis_server instance, and if a snis_server instance is shut down, the states of any Lua scripts it is running are lost.

That makes sense, I wasn't sure if there was some key/value pair data stored with the solar system or bridge that a script could use for persistent data or not.

Another point to bring up is because it is so hard to get a group of people together to play, and because invariably after an hour or so, at least one person seems to have some place else they need to be, there's very little continuity between sessions. So the idea of having some long campaign over many sessions where one chain of events leads to another, and there's a long, involved story... just doesn't really seem to work. This genre of game seems to naturally be best served in small, bite-sized, self-contained chunks that are independent of one another.

This is probably why some people wish to play it over the internet

Thank you.

[CapnRobberts]

Question regarding Lua Scrips.
It looks like when you register events that events from only one lua script can be registered at a time.
I see that all scripts except initialize.lua call clear_all(), and that clears out all the event callbacks.
This makes sense because it looks like there is only ever one lua_state for the entire server.

Is that correct? are the events registered by initalize.lua cleared out when a mission script or something else is run? If not, how does the event know what script the named function goes with and how does it resolve conflicts?

[smcameron]

@CapnRobberts

It's been a long time since I wrote that code, so it's possible I might get some of the details slightly wrong, but, as I recall...

The callbacks (timers and events) are not tied to specific scripts per se.

There are three variables in snis_server.c that control the lua event and timer callbacks:

Link to code

* lua_timer
* event_callback
* callback_schedule

lua_timer is a linked list of registered timer callbacks, with each entry containing the name of the lua function to call, the time to call it, and a cookie to pass to it.

event_callback is a linked list in which each element contains the name of the event, the number of callbacks registered for that event, and an array of lua function names to call back when that event occurs. (So more than one lua function can be registered for a given event, up to MAXCALLBACKS, which happens to be 3, but it could be expanded arbitrarily if need be. See snis_event_callback.c)

callback_schedule is a list of callbacks to fire every frame. Each tick of the server clock (10Hz) the callback schedule is cleared. As events happen during the processing for the server tick callbacks and parameters are added into the callback_schedule. IIRC, the lua functions need to be called from the thread that set up the lua state (and there is only one lua state in snis_server), hence why the schedule. (See this re: lua and threads) Any threads may add things into the schedule, which is my code, not Lua code. Later, in the correct thread, at a particular point in processing a server tick, all the indicated lua functions in the schedule get called, then the schedule is cleared to get ready for the next server tick.

See the end of move_objects() function in snis_server.c where it calls:

* fire_lua_timers();
* fire_lua_callbacks();
* fire_lua_proximity_checks();
* send_queued_lua_comms_transmissions();

So if you run one lua script, and it creates some functions, and registers for timers or events to call those functions, then you run a second script, and that second script does not clear those things, they will still be in effect, and you can register multiple callbacks (up to 3) for an event, and I think all the timer registrations are independent, so an arbitrary number can fire on a given server tick.

See l_register_callback(), l_register_proximity_callback(), l_register_timer_callback(), l_comms_channel_listen(), ... I think those are the main things in snis_server.c where callbacks get registered.

There are calls to schedule_callbackX (where X is some small integer) that occur when any event is detected (e.g. player death). These add things into the callback schedule that get fired by move_objects() later in the server tick.

The timer callbacks are one-shot. That is, if you want to repeatedly get called back, each callback must re-register itself for the next callback.
I think the event callbacks are persistent until something calls clear_all() one way or another (though I see in some scripts it re-registers for the callback inside the callback, as if they were one-shots. Pretty sure they aren't one-shots, and there's no way to clear them other than clear_all(). There probably *should* be a way to clear an event callback registration, but currently I do not think that there is, other than clear_all().)

Hope that helps.

Edit: as for initialize.lua, there is currently nothing important in there (really I think I only made it while I was creating the callback system, so it was ok for testing -- printing things out when a few events happen). But if those get cleared out, it's no matter, because there's nothing in there anyway. It does not appear to get run each time after clear_all(). So basically, you can ignore initialize.lua, it doesn't do anything important and isn't really useful in its current form. It *might* be useful if it were called after clear_all(), but... if I haven't really needed it yet, it's doubtful. It appears to be an idea that I had while making the lua scripting system which never got very far.

Edit again: I created an issue to track these Lua API weirdnesses: https://github.com/smcameron/space-nerd ... issues/250

[CapnRobberts]

So if you have two scripts that have the same function name, the later loaded one will blow out previous functions of the same name since everything runs within the same lua state. I think I get it.
Thanks.

[smcameron]

Yes, I think you got it.

[smcameron]

Now you can set a per-client tweakable variable on the console, MAIN_VIEW_AZIMUTH_ANGLE, and with multiple main view clients, you can construct a widescreen view. About +75 or -75 degrees for the left and right views.

[MCMic]

That’s a nice idea!

I’m not sure I’ll have enough hardware for a multiple windows setup anytime soon though.

[MCMic]

Was looking into porthole windows, to add a small side window, then realized the door of a busted washing machine would probably be perfect to build that…

[smcameron]

That’s a nice idea!

I’m not sure I’ll have enough hardware for a multiple windows setup anytime soon though.

Me either. Well, I do have a couple Raspberry Pi 4's around, and a have a couple monitors for those ordered, so I suppose with my desktop unit and those 2, I could set up a 3 monitor system pretty soon (although the Raspberry Pis aren't really fast enough). And really to do it right, you need 3 projectors and 3 big screens and... a house to put it all in. So... Dammit. I can't even use my own software to full effect.

[smcameron]

Hmm, big TVs are getting pretty cheap, here's a 55 inch TV for $299.
https://www.amazon.com/TOSHIBA-50LF711U ... 002&sr=8-5

Get 3 of those, put one in a corner, and two on the walls on either side of it... Hmm.

No. I'm not doing that.

[CapnRobberts]

Would you really want to push 4k OpenGL through a Pi4?

[smcameron]

Would you really want to push 4k OpenGL through a Pi4?

Of course not. If you read upthread, you'll see that I tested the Raspberry Pi 4 with 4Gb and performance is really only acceptable on the simpler screens, and then only at 1080p. Even at 720p, the Raspberry Pi isn't really up to the task of the main screen or weapons screen.

But if I had the stuff lying around, and nothing else to try it with, why wouldn't I try it out just to get a sensation of sort of what it might be like (disregarding the poor expected performance.) Most of the fun I get out of this game is dinking around with stupid crap rather than actually playing it.

[smcameron]

I gave the weapons screen the same treatment as the main screen. Now you can set weapons_azimuth_angle via the demon screen. +/- 75 degrees seems to work alright for setting up a left and right view. It's not perfect, there's some near-plane clipping of the gun turret happening in the left and right screens. You can't really set up a two screen setup with the guns in the middle because the gauges only render if the azimuth angle is zero.

[MCMic]

On 2020-04-04, I will be animating a SNIS session in Lyon, France: https://pretalx.jdll.org/jdll2020/talk/ZPJD9R/

This will be part of the event https://jdll.org/

Most likely I will only be able to accept 6 players, I looked into having two crews playing together, but most likely I will be short on computers for this.
Maybe I will try it anyway if a few players have their own laptop, I need to see the room first to get an idea what it will be like.

[smcameron]

@MCMic, Sounds cool, I hope it goes well. I'll try not to break things before then. If you like, I could mention this on https://bridgesim.net, there are some French speaking people there, though I do not know if they are near Lyon. (But if you can only accept 6 people, perhaps you don't need any help rounding up a crew.)

I have a patch to move the solar system center to (0,0,0) which helps a little with the weapons jittering (but doesn't fix it completely). But it breaks the 2D demon screen a little bit, so I have another patch to remove the 2D demon screen altogether, and then working on more patches to make the 3D demon screen do everything that the 2D demon screen can do. One thing that the 2D demon screen is good at that the 3D demon screen is not very good at is manually creating a whole bunch of objects in a particular arrangement. I haven't figured out a way around that. This capability is nice for creating Lua scripts, you can just place a bunch of objects manually, then use the "enscript" command to save the layout to a Lua script, which you can then modify. Saves you from having to create an algorithm to place things. So I've been sitting on those patches while I try to get them into acceptable shape and make sure they don't break anything. Still not there yet.

I suppose I should hold off on committing those two big changes until after 2020/04/04.

And that probably goes for changes related to the weapons and damage system mentioned in this issue: https://github.com/smcameron/space-nerd ... issues/243 Or at least such changes should be hidden behind a tweakable variable.

(In case I do break things, you could always use an older commit if need be, however in that case, you run the risk that the extra assets might from spacenerdsinspace.com might not match up exactly right (not that they change that much, but they do change from time to time.))

[MCMic]

@MCMic, Sounds cool, I hope it goes well. I'll try not to break things before then. If you like, I could mention this on https://bridgesim.net, there are some French speaking people there, though I do not know if they are near Lyon. (But if you can only accept 6 people, perhaps you don't need any help rounding up a crew.)

That’s the hard part, I do need 6 people to show up, but if there are many more than this it’s not good either, so it’s hard to estimate if I should advertise it or not.

I have a patch to move the solar system center to (0,0,0) which helps a little with the weapons jittering (but doesn't fix it completely). But it breaks the 2D demon screen a little bit, so I have another patch to remove the 2D demon screen altogether, and then working on more patches to make the 3D demon screen do everything that the 2D demon screen can do. One thing that the 2D demon screen is good at that the 3D demon screen is not very good at is manually creating a whole bunch of objects in a particular arrangement. I haven't figured out a way around that. This capability is nice for creating Lua scripts, you can just place a bunch of objects manually, then use the "enscript" command to save the layout to a Lua script, which you can then modify. Saves you from having to create an algorithm to place things. So I've been sitting on those patches while I try to get them into acceptable shape and make sure they don't break anything. Still not there yet.

I never understood how to navigate the 3D demon screen :-/
But I do not really use the demon screen apart for debugging and starting scripts.

I suppose I should hold off on committing those two big changes until after 2020/04/04.

And that probably goes for changes related to the weapons and damage system mentioned in this issue: https://github.com/smcameron/space-nerd ... issues/243 Or at least such changes should be hidden behind a tweakable variable.

(In case I do break things, you could always use an older commit if need be, however in that case, you run the risk that the extra assets might from spacenerdsinspace.com might not match up exactly right (not that they change that much, but they do change from time to time.))

It’s not that big of a deal if I need to stay at an older commit.

I’m having a game session at my place at the end of march, so I will build live USB sticks for it and use the same ones for the event most likely.

[smcameron]

I have a patch to move the solar system center to (0,0,0) which helps a little with the weapons jittering (but doesn't fix it completely). But it breaks the 2D demon screen a little bit,

I fixed the problems with the patch that broke the 2D demon screen, and it seemed pretty solid, so I went ahead and committed it.

Not sure it's a great idea to invite people at a conference to touch your keyboards with this corona virus thing out there. I noticed the Artemis Armada 2020 convention got canceled, or at least postponed.