Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[alexchandel]

What would it take to run DF in dwarf-mode without actually running the game loop? In other words, to populate the memory structures in df::global (for example, using data from RemoteFortressReader) and to allow in-game menus to operate, but not to spin the game-logic loop (i.e. no pathfinding, no combat simulation, no time progression whatsoever), nor to let the in-game menus write to df::global (ideally), rather capturing the user's requested changes (e.g. enabling a labor on a dwarf) and sending them elsewhere (for example, over RemoteFortressReader).

Is DFHack currently capable of this?

• Is DFHack capable of preventing the game-logic loop from running, and populating/updating df::global with data from RemoteFortressReader between frames?
• What about intercepting user actions from the UI (e.g. a designation, adding a new task for a workshop) and sending them over RemoteFortressReader? Can DFHack at least copy user actions and send them over RemoteFortressReader (with the local result later overwritten by an update, as described above)?

Note that blocking the game-logic loop isn't exactly equivalent to pausing (although presumably it would happen via the same code), because whether the "*PAUSED*" label is displayed on the UI would depend on what is populated into df::global. Even if it isn't displayed (if RemoteFortressReader is reading from a remote game that is unpaused), the local game-logic must not run.

Note also that since game data is coming from elsewhere (RemoteFortressReader), there are no local save files. So DFHack needs a way to get the program from the main menu to a state where it's running dwarf-mode on data whose initial state was supplied by DFHack.

This builds off another thread about simultaneous multiplayer and a Dwarf Fortress network client.

Edit: presumably dwarf-mode's core loop will still run, but the portion that runs when a normal game is *unpaused* should be suppressed. This amounts to DFHack keeping the game "paused" regardless of whether it says it's paused or not.

[Bumber]

What exactly is the point? If the game loop isn't being run, why populate and hack df:global in the first place? Sounds like a lot of trouble compared to building a custom UI client from scratch.

[alexchandel]

What exactly is the point? If the game loop isn't being run, why populate and hack df:global in the first place? Sounds like a lot of trouble compared to building a custom UI client from scratch.

The point is to run DF as a network client. Building a custom UI client from scratch would probably require rewriting code for the GUI, rewriting code for graphics packs, rewriting code for all the menus, rewriting code for interacting with df data structures, reinventing SoundSense... sounds comparatively hard when a UI already exists, if that UI can be repurposed.

What seems necessary to achieve this is to:

• Somehow move the process to a state where it's running the dwarf-mode game loop with data we supplied. Given dfhack's "load-save" command,
   some of the requisite code may already exist. (Worst-case scenario: we download the entire region folder from a remote fortress and load that.)
• Inhibit the time-progression code in dwarf-mode game loop, even when it's unpaused.
• Periodically poll a remote fortress with RemoteFortressReader, and update the game state in df::global.
• Send changes the user orders (designations, labor assignments, workshop tasks, etc) over RemoteFortressReader.
• ?
• Profit

Edit: that said, if anyone has a custom UI client already, or plans for one, go for it.

[gchristopher]

Wait a minute... You're saying you want to run the df executable, and the functionality you want out of it is to... just use the GUI/user interface part of it? (By somehow turning everything else off.)

[alexchandel]

The df executable does more than you credit it with. It knows how to parse the map's data & display it, it renders the myriad dwarf-mode menus, it deals with units/buildings/items, it can parse tilesets and graphics packs (meaning custom graphics packs would work natively), and it's already compatible with TWBT, SoundSense, StoneSense, Dwarf Monitor, Dwarf Manipulator, and other UI mods.

Think about how much you can do when the game is paused, from ordering raids on another civilization, to reorganizing labors, to trading with merchants, to changing stockpiles/zones/designations. All of that would have to be rewritten. That's not impossible, but the DF dev community doesn't exactly have a surplus of free labor willing to recode the entire UI (and update their recoded UI with every DF release) (that I'm aware of).

If the df executable can be repurposed, or tweaked slightly so it can be repurposed, shouldn't it be?

[Bumber]

The point is to run DF as a network client. Building a custom UI client from scratch would probably require rewriting code for the GUI, rewriting code for graphics packs, rewriting code for all the menus, rewriting code for interacting with df data structures, reinventing SoundSense... sounds comparatively hard when a UI already exists, if that UI can be repurposed.

My gut instinct is that you're going to get hit with a clown car of issues if you try to let DF handle things. For example, DF defines stockpiles by the order they're created in. Player 1 creates a food stockpile<#98>. Meanwhile, Player 2 creates a wood stockpile<#98>. The clients submit their df::global, and now you've got a huge problem regarding stockpile 98. Same for selecting building materials, queuing up jobs, etc.

So maybe you decide to send updates to all players' globals each time someone changes something. The update must first go out to the server, then from the server to the other clients. This might take several seconds. Now everyone's work is constantly invalidated by other players. Whenever one player's update is received by the server, any change not containing that update must be discarded. You can't verify that your proposed changes weren't affected, because you've decided to let DF handle df::global.

So maybe you decide that the players should just take turns. Well, that's just Web Fortress.

SoundSense uses the gamelog.txt, which isn't going to get written without the game loop, so the server's going to have to send that in any case. Graphics packs should be relatively easy.
The UI mods obviously won't be compatible as-is, but they're hacking in entirely new menus anyways, which is on par with creating a custom client. Instead, we have the possibility of designing a good UI from scratch.

Edit: that said, if anyone has a custom UI client already, or plans for one, go for it.

We've got pieces floating around. DT does labors, obviously. Armok Vision handles graphics packs, and I'm pretty sure it does digging designations. Warmist's multiplayer thing gives each client their own little viewport.