Wasn't there a DF multiplayer mod at some point? Or did that only work with having two people in the same embark? (I'm pretty sure I heard of adventurers visiting player-run fortresses, though...maybe that was speculation of the future.)
In any case, it's almost certainly broken for 0.40.xx.
dfterm is either an ssh/telnet middleware solution that allows multiple remote user to pass around the control of the terminal and watch what is happening using a shared single user POV, which has some neat features like an integrated chat function and the like-- (dfterm and dfterm2) or a dfhack plugin that allows many remote users to do the above,, but via a handy web portal interface instead. (dfterm3)
it does not allow multiple players to have simultaneous user activities on the same active region. DF simply does not have the innards for this, and while it might theoretically be possible to hack something like this in usinga very ambicious dfhack binary patch, it would be very dangerous and quite likely to corrupt the world save because the individually running processes spawned to accomplish something like that would be prone to developing race conditions that require reconciliation, and multiple sites in the world save would be active at the same time, meaning normal fortress mode loading would be out of the question. the game would consider the save corrupted because of the dirty data from multiple simultaneously active sites. additionally, the computer on which such a multi user patch, (which again, does not exist), is running would have to retain some form of memory and cache coherency between the disparate fortress and adv mode threads running, since fortresses would all be trying to pull from the same historic figure pool for migrants, and you would want to prevent duplication of those figures, and also because adv mode players would need to have the whole active memory space copied quickly and efficiently into thier own process should they want to explore and actively managed player fortress, etc.
a nightmare of keeping things orderly, shared, etc on an already memory bound program. you would need more memory in that daemon server than is currently found in even massive database servers, with as many cores as you have users, and need a memory pipeline technology to clone massive swaths of memory in real time without a big performance hit. in short, modern computing hardware is just not up to that atm.
the thread you are referring to was a wishlist type thread-- i remember participating in it. it sure would be nice if DF was written to be a daemonized play server running a single world simulation with multiple forts all running as individual worker threads, but that just is not how it is. DF is simply not geared for being coaxed into a multiuser setting. even with that kind of memory and process model, you are going to need a computer from an alien spaceship to run it.
apples to oranges.
in this case, about the best that can be done is a "round robin" reclaim/retire cycle, where player 1 manages fortress 1 for one year, then retires-- player 2 manages fortress 2 for one year, then retires, etc... until all players have had thier "turn", then player 1 reclaims thier fortress and plays a year then retires, player 2 does the same etc.. etc.. etc..
that would introduce quite a bit of uncertainty, because of the new active world code. the elapsed time between overseer interactions would be years=nPlayers+1, and members of fortresses not in active play would be historical figures from which the currently active fort's migrant waves would be selected. that means the participating players would need to follow an ethics code of conduct concerning migrants that prominently features a no-kill rule. the fortresses that each player manages would constantly be changing in the time they are not at the wheel, meaning they wont be the same as they left them when they pick back up.
it would be a very interesting community succession game, but not the same as actually concurrent fortresses in the same active world.
Author
Topic: Save question (Read 1080 times)