Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - alexchandel

Pages: [1] 2
1
DF General Discussion / Re: Lazy Mac Pack (v0.47.05)
« on: July 29, 2021, 11:21:07 pm »
PSA:

If you want flawless native fullscreen and/or retina display support, use Mifki's SDL.framework build. It still works. I uploaded it here. (Note: Intel macs only.)

2
DF General Discussion / Re: Lazy Mac Pack (v0.44.05)
« on: July 01, 2019, 12:35:48 am »
ANNOUNCEMENT:

I've compiled an updated version of the Lazy Mac Pack, v0.44.12 dfhack.  Get it here: https://github.com/alexchandel/starter-pack/releases/tag/v0.44.12-r02-mac-beta

3
DF General Discussion / Re: Lazy Mac Pack (v0.44.05)
« on: June 29, 2019, 09:09:04 pm »
Yes:

xattr -rc FOLDER

That will nuke the com.apple.quarantine attr on every file of that folder (and in every subfolder).  Just type "xattr -rc   " in the Terminal, then drag the folder into it.

4
DF General Discussion / Re: Lazy Mac Pack (v0.44.05)
« on: January 08, 2019, 09:33:26 am »
Quote from: falcn on January 06, 2019, 07:43:24 pm
While jecowa is out, I made this.

It's not a replacement for Lazy Mac Pack, it doesn't have a launcher, it doesn't have options, and it comes preconfigured.
Let's call it MacPack 0.44.12-p0.

Why not include the launcher?  The binary is compatible with all newer versions, and was designed to provide a unified interface to Dwarf Fortress until Toady bothers.  You should just need to tweak the json file and update the Baselines and Defaults.

Also your Retina modification should be unnecessary.  Use Mifki's SDL build instead (http://www.bay12games.com/dwarves/mantisbt/view.php?id=9762), it fixes everything on the jecowa's dfhack pack.

5
DF Suggestions / Key binding for muting sound
« on: January 07, 2019, 11:32:23 pm »
A keybinding option for turning sound on/off.  Currently this can only be done from the init file.  There isn't even a keybinding option to raise or lower volume.

6
Utilities and 3rd Party Applications / Re: SoundSense: a sound engine for dwarf fortress.
« on: January 06, 2019, 05:49:06 am »
SoundSense should be rewritten in Python/Tkinter (like the PyLNP launcher is).

FYI macOS users, there's NO NEED to install Java if you have any apps that distribute Java, like Minecraft or Mathematica.  Just drop a symlink to that app's "java" executable in your "/usr/local/bin" folder using a command like:

Code: [Select]
ln -s /Applications/Mathematica.app/Contents/SystemFiles/Java/MacOSX-x86-64/bin/java /usr/local/bin
Then edit soundSense.sh and add one line, PATH="/usr/local/bin:$PATH", AFTER the first line, so the first three lines are as below, and SoundSense will magically work. No system Java necessary!

Code: [Select]
#!/bin/sh
PATH="/usr/local/bin:$PATH"
dir=${0%/*}

7
DF General Discussion / Re: Lazy Mac Pack (v0.44.05)
« on: January 06, 2019, 05:21:29 am »
jecowa, any updates?  All the DFHack and TWBT bugs have been fixed upstream.

8
DF General Discussion / Re: Lazy Mac Pack (v0.44.05)
« on: August 08, 2018, 05:38:27 pm »
Quote from: jecowa on April 02, 2018, 02:05:18 pm
The pack without DFHack is on Dwarf Fortress v0.44.09 now. I didn't test it much, though.

updated Taffer to 5.1.2. It includes the long-anticipated Damascus tilesheet which has really cool walls.

A bunch of less popular graphics packs were removed to simplify the options. Let me know if you miss any.

The 32-bit lite pack is in the legacy section now. Snow Leopard, Lion, and Mountain Lion users who need Dwarf Therapist will want to get the 32-bit lite version from the legacy spoiler.

Barebones pack is replaced with a 64-bit lite pack that includes Clément's 64-bit Dwarf Therapist.

Any news for 0.44.12? The TWBT was supposedly fixed in DFHack 0.44.10-r2. You can upgrade the DFHack bundle now.

9
DF Dwarf Mode Discussion / Re: Running DF interface without the game loop (for multiplayer)
« on: March 06, 2018, 05:13:31 pm »
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?

10
DF Dwarf Mode Discussion / Re: Running DF interface without the game loop (for multiplayer)
« on: March 05, 2018, 03:41:00 pm »
Quote from: Bumber on March 05, 2018, 02:57:41 pm
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.

11
DF Dwarf Mode Discussion / Running DF interface without the game loop (for multiplayer)
« on: March 05, 2018, 01:24:13 pm »
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.

12
DF General Discussion / Re: Lazy Mac Pack (v0.44.05)
« on: February 20, 2018, 05:25:40 pm »
Quote from: jecowa on February 19, 2018, 11:57:24 pm
Oh, thanks for pointing that out. I had only read the last line and didn't notice the first two. That's convenient having it support both and somehow it does it with only half a megabyte.

IIRC the official releases already use Mifki's builds of both SDL_Image and SDL_TTF in 32-bit Dwarf Fortress. Once this gets added, the complete set of SDL libraries will be his builds.

Edit: It causes crashes when exiting full-screen mode in every OS I've tested so far (Snow Leopard, Lion, and Mountain Lion) in both the 32-bit and 64-bit versions of Dwarf Fortress. Same results on Retina Display (tested in Mountain Lion) and in DFHack (tested in Lion).

I haven't tested on those, but Dwarf Fortress crashes when entering fullscreen (via the green button) in Yosemite, El Capitan, Sierra, and High Sierra in any print mode except 2D, and 2D is unplayably slow on those OS versions (due to bug 10052). Mifki's SDL fixes the crash. Someone should tell him the build behaves differently in 10.9 and earlier OS's.

Quote from: falcn on February 19, 2018, 11:03:22 pm
Quote from: alexchandel on February 19, 2018, 08:22:58 pm
If you replace DF's SDL framework with Mifki's SDL build (linked from http://www.bay12games.com/dwarves/mantisbt/view.php?id=9762), then macOS's native fullscreen works, and can be toggled by the usual green button.

It might be a good idea to bundle Mifki's SDL build into the Lazy Mac Pack by default, as that'll save untold noobs untold hours of trouble by fixing the fullscreen crash.

That SDL allows DF to work nicely with OS X window manager, but it is not using retina resolution in fullscreen mode, unlike bundled SDL.

Are you sure? Which OS version? When I zoom out on High Sierra (and before on Sierra) with Mifki's SDL, I have Retina precision. Confirmed with the Color Meter.

13
DF General Discussion / Re: Lazy Mac Pack (v0.44.05)
« on: February 19, 2018, 08:22:58 pm »
If you replace DF's SDL framework with Mifki's SDL build (linked from http://www.bay12games.com/dwarves/mantisbt/view.php?id=9762), then macOS's native fullscreen works, and can be toggled by the usual green button.

It might be a good idea to bundle Mifki's SDL build into the Lazy Mac Pack by default, as that'll save untold noobs untold hours of trouble by fixing the fullscreen crash.

14
DF General Discussion / Re: Lazy Mac Pack (v0.44.05)
« on: February 05, 2018, 02:46:16 pm »
New DFHack release!

DFHack 0.44.05-r1: https://github.com/DFHack/dfhack/releases

15
DF Dwarf Mode Discussion / Re: Simultaneous multiplayer is feasible
« on: December 18, 2017, 09:11:19 pm »
Quote from: stingpie on December 17, 2017, 02:18:08 pm
The way I would interpret this working, is the two players agree to an fps range, and if one of the computers exits that range, the other will dedicate some resources. It would certainly take a very fast connection, but that's the only way I feel a processing power difference could be solved. they would have to control different fortresses with some sort of fps magic to slow down ticks on one computer, if the other one was paused. If all else fails, there would be a counter for the ticks in a (virtual) day, and force one of the players to wait that long, at the end of a day.

I'm imagining more of a client-server model, where only one process runs the fortress-evolution & world-evolution. Other players have a thin client that connects to the main DF process/computer (over a network, via the DFHack plugin RemoteFortressReader), shows a screen of tiles, & sends modification requests back to the main DF process whenever the other player does something (e.g. designates an area, renames a burrow, adds a task).

Pausing would have to be coordinated, as I mentioned here:

Quote from: alexchandel on December 18, 2017, 08:46:58 pm
…

Quote from: Starver on December 17, 2017, 12:27:37 pm
It's always been the problem that play tends towards being asynchronous with game-time varying wildly from play-time. Not a problem with a solo game (complaints about depressed FPS aside, which I don't consider game-breaking anyway so long as it does still tick, however slowly) but two players meshing together is a practical problem that no mere 'recoding' can handle. It's, as said, a change in game-play, with either micromanagement allowed to throttle the freer player, or 'plot progression' potentially happening full-throttle whilst things (that need to be 'menued' in-depth) continue unhandled.
…

See I'm thinking 'plot progression' could happen full-throttle, unless explicitly paused by either player (e.g. bind pause to the backtick/"`" key on every screen). One could still attempt to 'menu' things as deeply as possible real-time, explicitly pausing when it wasn't possible.

It's worth hacking this feature into the current (single player) game, to see how it plays. From a technical point, the only potentially problematic question is "what does the current menu code do when a menu should've changed?" As long as the answer isn't any variation of "the game crashes" or "the game gets corrupted," it's fine.

But since there's only 1 fortress (and thus no additional game computations happening), this type of simultaneous multiplayer wouldn't even hit FPS that much.

Pages: [1] 2