Bay 12 Games Forum

Quote

I play over SSH (via a modified version of PuTTY) and I have a custom script and executable that locks the DF account to the game using Screen.  That way I can always resume the game, wherever I am, as long as I have Internet access.

Personally, I want to do this to my own console once I get it up and running, but still limit its access to the internet.  Just so I can play anywhere in the house.  I love novel things like being able to do that.

But why disable access to the internet? Shouldn't it be enough to block access from the internet? As long as you don't install any services, nothing will be listening for incoming connections. Even if you set up an SSH server (which I'd offer as an optional feature to users) it can be configured in such a way that it only accepts connections from certain IP-addresses (I know that this isn't secure - but in addition one has to have login credentials - what in the case of your project probably means private-/public key authentication). If that's not enough, you can still set up a software firewall using nftables (or iptables if you prefer), the package filtering function of the Linux kernel. The reason I'd suggest to stay connected to the internet is the possibility to access the Wiki. There are several text based browsers, and it might not be the worst idea to have one of them running on another terminal.

Quote

What linux distro will this be based on? (and all other highly techy questions)

I will need to get back in touch with Urist McProgrammer on his progress.  We've mostly been discussing the features needed, and his status on implementing them.  We are close to the prototype stage 1 (hardware only), and oddly, I haven't asked him about which distro he is using yet, lol.

If I may suggest: Use something minimalistic. Although I've never user used it, Arch would come to my mind. It's rolling release, so no reason to bother with distribution lifetime. Also, it uses systemd. Many might see this as a downside, and it might indeed be from a technical standpoint, but from a user's standpoint it's extremely convenient, as managing services (as in: making the system boot into dwarf fortress and shut down when dwarf fortress exits) has never been easier - except maybe with the much less flexible BSD-style Init.

Quote

Linux is happy to boot off cheap USB drives, once it's booted you can run from ram

The original idea was to do exactly this.  People would update their system by just updating their portable USB stick and everything would be easy.  But that doesn't really feel much like a console
In reality, the reason we are not opting to do this is that hard drive access has a generally minimal impact on the gaming experience, and it is WAY cheaper to buy a decent little SSD than lots and lots of RAM for those big, long historically significant worlds.

Don't forget that dwarf fortress is just 32bit. This means, that it'll anyhow be limited by the address range. On a 32bit Linux system, dwarf fortress won't get more than about 3 GB of RAM, while on a 64bit Linux system it should get just short of 4 GB maximum (source). This means that you'll probably want a 64bit Linux kernel. This will waste some HDD space for the additional 32bit libraries required by dwarf fortress, and use a bit more RAM than a 32bit Linux system, but the additional 1 GB might make a difference on large worlds. A further consequence of this is, that you'll probably want to have 8 GB of RAM available, as dual channel mode is kind of a must for dwarf fortress, meaning you'll either want to mount 2x2GB, what will require swapping if df gets close to using all possible 4 GB of RAM (or without swap, it'll crash), or 2x4GB. While this means you'd have easily enough free RAM for a small ramdisk containing the root filesystem, I don't see much use for it in your particular case, as all storage access to the root filesystem will happen during boot (if the system is configured in that way at least), at which point a ramdisk would have to be loaded from permanent storage as well... One might argue that the ramdisk images are typically compressed and therefore might require less storage I/O, but compression is also available at the filesystem level, for instance with btrfs.
Long story short, I don't think a ramdisk is a good idea in that use case, even when using a slow storage medium.

Anyhow, I'd like to bring up something else: The KMS terminal. What is the reason you don't want to use PRINT_MODE:TEXT?
And, semi-related: Why doesn't dwarf fortress allow to draw to the KMS terminal framebuffer? Other SDL based applications (openttd, dosbox, ur-quan masters,...) can output graphics without an X11 server just fine.

Nope, and there is no tower nearby, so I'm really hoping that there is some way to craft at least trade goods out of them...

I'm playing with [GRAPHICS:NO]...
If I would manage to get fast scrolling (SHIFT+Direction) working with it, I think I'd even play with [PRINT_MODE:TEXT]... As it is now, this is reserved for playing over SSH...

Yesterday my fort was attacked by a werebear. It was a horribly one-sided, but nonetheless epic battle, and the result was a beautiful leg-, tail-, gut.-, and headless night creature corpse.
Now the strange thing is: I have a sentients stockpile right next to a deep, deep hole where bodies are being disposed off if they get too many. I also have a stockpile for animal corpses and body parts, which mainly serves as input for the butcher's shops. And last, but not least, I have a stockpile for usable, non-edible refuse, meaning hair, bone, skulls and horn. Now from those three stockpiles, the dwarfs decided that a rotting, miasma-spilling shapeshifted treehugger corpse is best placed in the stockpile for bones. I'm now wondering if anyone has seen similar behavior, and if there's a way to prevent dwarfs from doing this.

(For me the solution is obvious: As I have a deep, deep hole to dispose of bodies nobody needs any more, I'll have this one dumped there as well, but I'd still prefer not to have anything causing miasma or thoughts of horror in my bone supply pile...)

Ma graveyards tend to be rather simple. Typically they are 20x20 squares big, and contain a regular pattern of coffins, slabs and empty squares between them. As I usually have a fort die to fps-death instead of *fun*, the 20x20 areas are more than big enough. In my last fort I had the brilliant idea to have the hospital (10x10 squares) built inside the graveyard. That means a short hauling distance for dwarfs that the medics couldn't save, and given that several forgotten beasts with necrosis causing syndromes showed up, this short hauling distance paid off in the end, as only one of the many dwarfs that suffered from said syndromes was saved, the rest bled to death.

But do I feel sorry for the graveyard design? Definitely not. I mean, real life graveyards aren't so different. Nobles get their crypts next to their offices anyhow, just to remind them what will happen if they demand something too difficult to produce...

The axedwarf that was injured when I sent the army after raven corpses attacking migrants has died. Obviously the doctors didn't get thread early enough to suture all his wounds, so he kept on loosing blood...

Also, one of the glassmakers decided to demand silk cloth for a strange mood, so now I'm rushing to find the caverns just to gather a single web and have it spun as fast as possible. With a little bit of luck, the caravan from the mountainhome will arrive be for he goes crazy, but as there are undead ravens around, I'm not sure if the traders will make it to my depot. I'm currently considering sending out the soldiers to deal with the ravens, but they are still lacking parts of their armor, so that attacking the birds will probably cause casualties...

On the bright side, while digging down towards the caverns cassiterite was found, meaning that my soldiers will soon be able to upgrade their equipment from copper to bronze.

Maybe your parent civilization is (nearly) dead?