[GAME] Space Nerds In Space

1246789

Comments

  • Oh you maybe right. Let me check it tomorrow,
  • Star Wars has its Death Star, Star Trek has its Borg Cube, and Space Nerds In Space was clearly in need of a Big Honking Death Machine...

    https://www.youtube.com/watch?v=WUTmXUIMifQ
  • A giant space skyscraper as a ship. I see some potential for some interesting missions with that.
  • Inspired by the opening scene of the new Star Wars movie, I spent a half an hour or so playing around with the camera in SNIS, and this happened:

    https://www.youtube.com/watch?v=siPMjrEq8Rw
  • Are the flybys automatic?
  • The camera motion is automatic. For the ship's motion, I put the big giant ship in in a place that kind of lined up with the starbase and the rings, then starting at the starbase drove out past the big ship between the turrets, turned around, asked the computer to "set a course for the nearest starbase", then hit the gas and just let it go.
  • Experimenting with some different ways to control velocity. I don't think this will be in the game, but it looks cool.

    https://youtu.be/bvGfYSLtiNM
  • That could be used for a Cinematic mode for making videos or something.
  • FWIW, today I have added some pretty detailed instructions about how to run SNIS on a single system as well as with a multiplayer setup.

    https://smcameron.github.io/space-nerds-in-space/
  • A tutorial! Thank you for adding this! I successfully got the game to work this time :)

    The depth of this game compared to Artemis... is a little intimidating, as is the learning curve. but I feel confident we will figure it out as we blunder through the universe!
  • Hey, any idea of "Stack Smashing Detected" error means? I get it whenever my client computers try to connect to the server. This happens whether they are hosting their own game or connecting to my main computer.
  • Oh, sorry you bumped into that.

    It means there's some bug in some code somewhere. FWIW, I haven't hit this problem myself, and can't seem to duplicate it. Did it print out anything more than that? For example, something like this?

    *** buffer overflow detected ***: ./smash terminated
    ======= Backtrace: =========
    /lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7f9cb41257e5]
    /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7f9cb41c656c]
    /lib/x86_64-linux-gnu/libc.so.6(+0x116570)[0x7f9cb41c4570]
    /lib/x86_64-linux-gnu/libc.so.6(+0x1158c2)[0x7f9cb41c38c2]
    ./smash[0x400618]
    ./smash[0x4004ee]
    /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f9cb40ce830]
    ./smash[0x400529]
    ======= Memory map: ========
    00400000-00401000 r-xp 00000000 08:01 71567599 /home/scameron/github/snis-plain/space-nerds-in-space/smash
    00600000-00601000 r--p 00000000 08:01 71567599 /home/scameron/github/snis-plain/space-nerds-in-space/smash
    00601000-00602000 rw-p 00001000 08:01 71567599 /home/scameron/github/snis-plain/space-nerds-in-space/smash
    00f8e000-00faf000 rw-p 00000000 00:00 0 [heap]
    7f9cb3e98000-7f9cb3eae000 r-xp 00000000 08:01 19927513 /lib/x86_64-linux-gnu/libgcc_s.so.1
    7f9cb3eae000-7f9cb40ad000 ---p 00016000 08:01 19927513 /lib/x86_64-linux-gnu/libgcc_s.so.1
    7f9cb40ad000-7f9cb40ae000 rw-p 00015000 08:01 19927513 /lib/x86_64-linux-gnu/libgcc_s.so.1
    7f9cb40ae000-7f9cb426d000 r-xp 00000000 08:01 19927475 /lib/x86_64-linux-gnu/libc-2.23.so
    7f9cb426d000-7f9cb446d000 ---p 001bf000 08:01 19927475 /lib/x86_64-linux-gnu/libc-2.23.so
    7f9cb446d000-7f9cb4471000 r--p 001bf000 08:01 19927475 /lib/x86_64-linux-gnu/libc-2.23.so
    7f9cb4471000-7f9cb4473000 rw-p 001c3000 08:01 19927475 /lib/x86_64-linux-gnu/libc-2.23.so
    7f9cb4473000-7f9cb4477000 rw-p 00000000 00:00 0
    7f9cb4477000-7f9cb449d000 r-xp 00000000 08:01 19927447 /lib/x86_64-linux-gnu/ld-2.23.so
    7f9cb4671000-7f9cb4674000 rw-p 00000000 00:00 0
    7f9cb4699000-7f9cb469c000 rw-p 00000000 00:00 0
    7f9cb469c000-7f9cb469d000 r--p 00025000 08:01 19927447 /lib/x86_64-linux-gnu/ld-2.23.so
    7f9cb469d000-7f9cb469e000 rw-p 00026000 08:01 19927447 /lib/x86_64-linux-gnu/ld-2.23.so
    7f9cb469e000-7f9cb469f000 rw-p 00000000 00:00 0
    7ffde512e000-7ffde514f000 rw-p 00000000 00:00 0 [stack]
    7ffde51f2000-7ffde51f4000 r--p 00000000 00:00 0 [vvar]
    7ffde51f4000-7ffde51f6000 r-xp 00000000 00:00 0 [vdso]
    ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
    Aborted


    Assuming so, try the following:

    First:

    $ make mostly-clean
    $ make

    (just "make", not "make O=1" this will build everything without optimization.)

    $ ulimit -c unlimited

    This will let it produce a core dump when it crashes.


    Then try running again as you did previously. Presumably it will crash again, but hopefully it will also save a core file.

    Supposing it saves a core file (named "core", or "core.xxxx", where xxxx is some numbers.
    then run "file core", it should print out something like:

    $ file core
    core: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from './snis_client ...'

    (or it might be snis_server, or snis_multiverse, or something else that crashed, but snis_client is most likely the problem.)

    Then, try

    $ echo bt | gdb -c core ./snis_client

    and let me know what the output is (should be something along the lines of what's below).

    GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.04) 7.11.1
    Copyright (C) 2016 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law. Type "show copying"
    and "show warranty" for details.
    This GDB was configured as "x86_64-linux-gnu".
    Type "show configuration" for configuration details.
    For bug reporting instructions, please see:
    .
    Find the GDB manual and other documentation resources online at:
    .
    For help, type "help".
    Type "apropos word" to search for commands related to "word"...
    Reading symbols from ./smash...(no debugging symbols found)...done.
    [New LWP 5781]
    Core was generated by `./smash'.
    Program terminated with signal SIGABRT, Aborted.
    #0 0x00007f9e8d19e428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
    54 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
    (gdb) #0 0x00007f9e8d19e428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
    #1 0x00007f9e8d1a002a in __GI_abort () at abort.c:89
    #2 0x00007f9e8d1e07ea in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x7f9e8d2f78a2 "*** %s ***: %s terminated\n")
    at ../sysdeps/posix/libc_fatal.c:175
    #3 0x00007f9e8d28156c in __GI___fortify_fail (msg=, msg@entry=0x7f9e8d2f7833 "buffer overflow detected")
    at fortify_fail.c:37
    #4 0x00007f9e8d27f570 in __GI___chk_fail () at chk_fail.c:28
    #5 0x00007f9e8d27e8c2 in __strcpy_chk (dest=0x7ffe2e23b540 "", src=0x4006f8 "this is a very long string, isn't it.", destlen=20)
    at strcpy_chk.c:30
    #6 0x0000000000400618 in checkit ()
    #7 0x00000000004004ee in main ()
    (gdb) quit


  • edited March 2017
    A possibility occurs to me. Make sure that all versions of snis_client and snis_server are built from the same code. That is, if you have several machines, and you pull the code from git and build it on Tuesday, and later, on another machine, you pull the code from git and build it on a Wednesday, it's possible there are some differences which could manifest in this way you've described. Usually, they will manifest as a protocol error, but I could imagine it manifesting as stack smashing. In particular, this commit cut the precision of quaternions in half -- instead of 16 bytes, each quaternion now requires 8 bytes. If you had some old code expecting 16 byte quaternions and it got 8 bytes instead because it was talking to a snis_server with the new code (or vice versa) then I could imagine this resulting in stack smashing (though I haven't tried it.)

    So, TL;DR: make sure all clients and servers are running *the same* code, for example on all the machines, do:

    git pull
    make mostly-clean
    make O=1
    And I should do a better job of making the code aware by if not versioning, at least tagging the protocol in some way so these kinds of mismatches can be detected in a better way.
  • I thought about the versioning issue, but since the client would not connect to its own hosted game then I think that isn't the true problem. I was going to try to copy the built game from my main desktop to the clients and see if that works better, and otherwise try the different make options you posted above. With any luck, I'll be flying with multiple screens and then perhaps a full bridge soon!
  • On a hunch, I think I guessed what the problem is, duplicated it, and I think it's fixed now.
  • OK, here is the output when I run the game on the client computer using code pulled today. It was hosting its own ssgl, multiverse, and server. Again got the "stack smashing detected":
    artemis@artemis4 ~/space-nerds-in-space $ sudo file core
    core: ELF 32-bit LSB core file Intel 80386, version 1 (SYSV), too many program header sections (433)
    artemis@artemis4 ~/space-nerds-in-space $ sudo echo bt | gdb -c core ./snis_client
    GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
    Copyright (C) 2014 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law. Type "show copying"
    and "show warranty" for details.
    This GDB was configured as "i686-linux-gnu".
    Type "show configuration" for configuration details.
    For bug reporting instructions, please see:
    .
    Find the GDB manual and other documentation resources online at:
    .
    For help, type "help".
    Type "apropos word" to search for commands related to "word"...
    Reading symbols from ./snis_client...done.
    /home/artemis/space-nerds-in-space/core: Permission denied.
    (gdb) No stack.
    (gdb) quit
    artemis@artemis4 ~/space-nerds-in-space $
    I see "permission denied" but I always run the launcher with sudo--unless that doesn't always give enough privileges. That's going to be embarrassing if this is just a permissions issue!

  • btw, here is what I see when I make:
    artemis@artemis4 ~/space-nerds-in-space $ make 0=1
    ./gather_build_info > build_info.h
    snis_server.c: In function ‘put_client’:
    snis_server.c:466:3: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘int’ [-Wformat=]
    fprintf(stderr, "snis_server: calling remove_client %ld\n", client_index(c));
    ^
    snis_server.c:468:3: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘int’ [-Wformat=]
    fprintf(stderr, "snis_server: remove_client %ld returned\n", client_index(c));
    ^
    snis_server.c: In function ‘update_multiverse’:
    snis_server.c:16704:5: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 5 has type ‘int’ [-Wformat=]
    logprefix(), o->id, go_index(o), o->alive, __FILE__, __LINE__);
    ^
    COMPILE snis_server.c
    COMPILE snis_multiverse.c
    COMPILE snis_client.c
    cp snis_client.c snis_limited_client.c
    COMPILE snis_limited_client.c
    LINK snis_server
    LINK snis_client
    LINK snis_limited_client
    LINK snis_multiverse
  • OK, fixed the permissions and still get stack smashing. Here is the core dump:
    artemis@artemis4 ~/space-nerds-in-space $ sudo echo bt | gdb -c core ./snis_client
    GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
    Copyright (C) 2014 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law. Type "show copying"
    and "show warranty" for details.
    This GDB was configured as "i686-linux-gnu".
    Type "show configuration" for configuration details.
    For bug reporting instructions, please see:
    .
    Find the GDB manual and other documentation resources online at:
    .
    For help, type "help".
    Type "apropos word" to search for commands related to "word"...
    Reading symbols from ./snis_client...done.
    [New LWP 3635]
    [New LWP 3636]
    [New LWP 3603]
    [New LWP 3586]
    [New LWP 3608]
    [New LWP 3609]
    [New LWP 3593]
    [New LWP 3594]
    [New LWP 3610]
    [New LWP 3631]
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
    Core was generated by `./bin/snis_client --fullscreen'.
    Program terminated with signal SIGABRT, Aborted.
    #0 0xb7777cb0 in ?? ()
    (gdb) #0 0xb7777cb0 in ?? ()
    #1 0xb6c4b85b in __GI___fortify_fail (msg=,
    msg@entry=0xb6cb361b "stack smashing detected") at fortify_fail.c:37
    #2 0xb6c4b7ea in __stack_chk_fail () at stack_chk_fail.c:28
    #3 0x08096c2e in process_update_netstats () at snis_client.c:4761
    #4 0x0809913a in gameserver_reader (arg=0x0) at snis_client.c:5657
    ---Type to continue, or q to quit---#5 0xb6d0ef70 in start_thread (arg=0xa34dcb40) at pthread_create.c:312
    #6 0xb6c3bbee in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:129
    (gdb) quit
    (apologies for the triple post)
  • Hmm. That is weird. "No stack", well crap.

    I noticed you're on a 32-bit system... fwiw, all of my systems are 64-bit nowadays and for the past couple years. It's quite possible that some 64/32-bit uncleanness has creeped into the code.

  • My desktop that functions as the server for my bridge is 64 bit, and it runs SNIS fine. But my clients are a fleet of cheap old laptops and they are all 32 bit--oof if that is the problem, well, I suppose I have been considering upgrading at some point...
  • It *should* work on 32-bit systems -- I just haven't tried it, and so it's quite possible it doesn't. If that is the case, well it's a bug I should try to fix.

    Ah, I see you did get a stack trace! Great!

    #3 0x08096c2e in process_update_netstats () at snis_client.c:4761

    Interesting.

    I have filed a bug report here:
    https://github.com/smcameron/space-nerds-in-space/issues/98

    I may not be able to work on this for a week or so though due to completely unrelated circumstances, we'll see.
  • Ok, took a quick look, might be fixed by this commit. Give it a try and let me know how it goes.
  • Success! The client connects and can control the ship!

    I still get the "We expected an INT_LONG but the function only gave INT" when making which doesn't happen for the 64 bit desktop. But it ran anyways, so there's that.

    It's a tad slow on the poor rig (that's definitely my end not yours), but it does work. Well, other than the science screen which only shows a great blue background, and the turret screen is slow since it has to draw so much. But the less draw-heavy screens work admirably.

    But still, it connected and ran! Thanks for working with me.
  • Added a "Star Map" to the navigation screen.

    http://www.youtube.com/watch?v=fhu04_ymcM0
  • Haven't tried these myself, but there's some stuff by Hayden Hughes to build a bootable arch-linux based Space Nerds In Space usb image here: https://github.com/HUg0005/snis-live and some (again, untried by me) prebuilt images linked from the readme there.
  • A couple new features added recently:

    1. You can now set up to 10 waypoints on the Science station, either by typing in X, Y, Z coordinates directly, or by marking the ship's current position. The waypoints are selectable from the list of waypoints, or via the short range scanner or via the long range scanner. Once selected, the green arrow on the Navigation screen will point to the waypoint (just as it points towards anything that Science has selected.)

    2. Life support system. There's a new system on the damage control screen, life support. There are also power and coolant sliders on the Engineering screen for life support, and a gauge for oxygen, which is produced by the life support system (from e.g. electrolysis of water). If the life support system is damaged (or deprived of power), it will produce less oxygen. Oxygen is consumed at a fixed rate. If the rate of oxygen production is below the rate of consumption, the oxygen levels will slowly decrease. If they get too low, the crew will asphyxiate.

    A video demoing the new features: https://www.youtube.com/watch?v=5LmPP7OLtqM
  • Some minor progress on Space Nerds In Space. Improved UI sound effects (I think), most buttons make some kind of sound now. Added tooltips to all buttons and sliders. Now you can eject the warp core. I need to work on the warp core ejecting mechanic to make it a bit more meaningful, but the basics are there.

    http://www.youtube.com/watch?v=MImkMx3ZNWI

    The sci-fi UI sound effects were made with this thing:
    https://www.modulargrid.net/e/racks/synth/88651/2146 (Warning, this makes noise -- play with the 4 large knobs at the top left.)
  • Would you mind giving us a quick breakdown of the various factions in the game? I am having trouble remembering which of these jerks are most likely to shoot at me and which are generally friendly.

    Also, regarding funds:
    Refueling is expensive. What happens if we run out of funds?
    (I have tried to see what happens myself, but I tend to get murdered first. This one-man crew is poor performing, haha)

    Current money-making strategies include mining asteroids (done a bit of that) and ferrying passengers (not tried this yet but I see the option). I have yet to destroy anyone yet, so I don't know if you can loot the wreckage. Is there more?

    Any plans for purchasable upgrades to the ship?


    I am enjoying the CYOA aspect of the game; feels a bit like Escape Velocity.
  • Holy cow, somebody's actually playing this thing? Alright.

    So the factions are pretty shallow. There's a hostility matrix in share/snis/factions.txt which defines the factions and their territories and how they feel about each other, and that is about the limit of the depth of the factions, so this area needs some work.

    To sum up though:

    Zarkons: they hate everybody.
    Wallunni hate the Schaazbaut and the Vekkazi about 1/3 as much as the Zarkons hate anyone.
    Neutral don't hate anybody.

    One annoying thing is (and I consider this to be a bug), your ship is also assigned one of the factions randomly, but you don't even know which faction that is (good luck if you're a Zarkon, I guess.) I should fix that, either let you choose the faction (which is a property of your ship, actually) or at least let you find out what your own faction is.

    I should come up with some more distinguishing features and behaviors for the factions. E.g. maybe the ship-types would be per-faction, so you could tell what faction a ship was just by what it looks like (as is the case in every sci fi space movie ever, pretty much.) Oh, I almost forgot, you *can* tell which faction a ship is just by looking at the color of the exhaust plume it makes (you can also tell via science scanning it.)

    blue = neutral
    red = wallunni
    green = schaazbaut
    yellow = zarkon
    violet = vekkazi

    Tow trucks (Mantis ships) are always neutral.

    However, this information about which faction a ship belongs to is not terribly useful. I should make the different factions have different behaviors in such a way that knowing the faction is somehow actually useful. Open to suggestions for ideas about how to do that.

    When you get near a starbase that is in orbit around a high security area, the police ships will attack anybody that attacks anybody else in that zone (there's a voice announcement when entering or leaving a high security area, and the weapons radar shows "HIGH SECURITY AREA" when you're in a high security area. In general, you usually won't be attacked without provocation in a high security area (though once in a while it might happen, but nearly never.) If you attack another ship in such an area, the police will come after you.

    If you're around low security planets or in deep space, then there's no police protection, and you're much more likely to be attacked.

    Don't forget to turn the repair robot to "AUTO" mode if you're playing alone. That should help stop you from being killed so easily.

    If you run out of funds, nothing happens (your funds can go negative with no ill effect other than hurt pride.)

    You can collect fuel and oxygen from wrecked ships with the mining bot. When you kill another ship, it generally drops a cargo container that you can grab by running into it (tractor beam might be helpful there.) You can then sell the contents at a starbase.

    There are (inoperable) placeholders in the starbase interactions for buying new parts for your ship (that is to say, replacements for damaged parts.) I had not planned on having your ship be significantly upgradeable though. The reasoning behind this decision is as follows:

    1) This is meant to be a local multiplayer game, and is meant to allow multiple ships be player controlled (multiple crews.)
    2) It's nearly impossible to actually get such a group of people together to play such a game for a variety of reasons, not least of which is you need a lot of hardware, and a lot of laptops running linux.
    3) Given 1 and 2, if one crew had upgraded their ship, and the newbie crew just gets annihilated because of it, well, that's kind of missing the point, so in the interest of fairness, all the player ships should be the same, therefore no upgrading ships.
    4) (unrelated) if I lock some features behind achievements, likely nobody will ever see them at all (in case you didn't notice, *almost* nobody plays this game.)
  • Quick demo of new attitude indicator and yaw/pitch/roll rate indicator on the navigation screen:

    http://www.youtube.com/watch?v=eNOe1ghJmIg
Sign In or Register to comment.