Bay 12 Games Forum

Quote from: Octopusfluff

now that the game is out, i can see that there's some stuff in the vanilla definitions that would allow a degree of changes, but it requires me to change my question:
will we gain the ability to add mods to existing save files?

this has become a serious obstacle with mods that aim to improve accessibility by adjusting icons in the ui, or for my use case, replacing audio elements that are highly disruptive (like that horrific REEEE REEE REEEE bird noise in grasslands which is absolutely deleterious to some of us)

making a new save file every time we discover an experiential issue that someone solved with a mod is problematic.

Graphics stuff can already be adjusted w/out worries about saves I think?  I was doing it during development all the time anyway.

Sound just isn't that moddable yet, the format there isn't really complete.  It doesn't know how to use non-vanilla files, doesn't have a place to put them.  I wanted to get something in there so that saves could be a little bit compatible with more support later, by having any objects at all to work with.

understandable about the sound part. but my problem is that we have no mechanism for changing what mods are assigned to a world at present, so adding/removing graphics mods is currently impossible.

Quote from: Mr Crabman on November 02, 2022, 08:08:21 am

Quote from: BlueManedHawk on November 02, 2022, 07:33:39 am

Unfortunately, WINE (which proton depends upon) is a somewhat hefty piece of software, so it may still be out of reach for some people.

Hefty how? Many games run faster under Proton than they do in Windows even, and performance impacts are rarely significant in my experience.

What i meant was that WINE itself takes up a lot of storage space.

steam release for df is advertising storage requirements of about 500 megs.


a typical glorious eggroll release is a gig or so (within a couple hundred megs either way) extracted. official proton releases within the last couple years seem to be about a couple gigs or so (within a couple hundred megs), for reasons unclear to me (differently optimized builds? idk).


even still, that's not terribly massive for a system that's able to actually able to meaningfully play the premium edition. odds are pretty good anyone running linux using steam and not all-in on "native builds or gtfo" has some proton builds installed already.


if someone is running on a machine where a couple gigs of compatibility layer is that problematic, running the premium edition is quite probably not going to be a happy experience anyway.

Yeah, maybe "Square, Open Gaps, is best. It shows rectangular walls for people making a normal rectangular fort and it shows diagonal walls for people who are designing a diagonal fort.

Any weirdness on the border is because it's only showing half of those tiles in the examples.

... What I'm seeing is that Square, Open Gaps still shows jagged edges for diagonals; just look at the top left and bottom left.

Any algorithm that can somehow accomodate both square and rectangular build styles would be vastly more complicated than any seen here, and still have edge cases.

Look at how much work goes into things like the HQX algorithm; computer pattern recognition is hard shit.

Humor me, but, especially considering that the old versions weren't real time, what stopped this from being rendered in say cryengine?

Humor me, but what is it you think cryengine could possibly provide in terms of benefits?

I mean, to partially enumerate (and somewhat expand on therahedwig's notes on) why it's a bad idea:
a) it's kind of a mediocre engine for its category of product
b) even if it were a good example of a 3d engine for an indie project (it isn't. Among MANY other concerns, dwarf fortress and thus stonesense are crossplatform, and that isn't even the biggest issue), it's still a 3d engine, and stonesense was designed to be 2d
c) even if you were designing a 3d visualizer, your biggest obstacle for shininess of a project like this is not the graphics engine itself, but the quality of art assets (Just take a look at any of the extant 3d visualizers, and if you think they are insufficiently shiny, it's almost certainly not a pure software issue)

No I have not - Starter Pack still depends on an official DFHack release only because that's what it currently takes to get a release that is considered stable and works with the latest DF version. There is, based on the discussions so far, an opportunity to change that since both 11->12 and 12->13 only required a symbols.xml update, but due to the way DFHack is currently maintained this requires everything to be recompiled by the DFHack team to make the versions aligned and it to be considered stable, which is what is required for inclusion in the Starter Pack. What I want is to separate DF versioning from DFHack versioning from plugin versioning so that when DF makes non-breaking changes in an upgrade, the's no need for an unsupported "at your own risk" build in order to update.

There is an opportunity, yes. There is also an opportunity cost, which the team is not comfortable with at this time. That might change, particularly with a demonstration of implementation.

I described it already, but given your other posts it's not surprising that you'll ignore both that and the implications of a core change like this, given your above approach to replying to me. This isn't creating a new plugin - it would require DFHack and all the plugins to be updated to use a new system - that's not something that just gets done off on a branch and suddenly everyone becomes accepting of it.

I'm ignoring nothing. The implications of a change like that are significant, and someone has to actually do the work. A description is not sufficient. You're demanding someone else do it for you. This is not how to win friends and influence enemies.

Out of curiosity, why is stonesense done in the graphics engine that it has?

As opposed to...?

Is there a place which describes in detail how the overlay works, and what it does and does not do? By that I mean in one place, not spread out over a hundred page thread. If not, could you maybe summarize it here in a few sentences? I heard recently that people were able to hook Stonesense into the game so that it works like a true graphical interface, but it's been impossible  for me to track down detailed info on that, as most stuff here seems to exist over many pages in various threads.

That kind of documentation is generally reserved for legitimately complete features, rather than "oh hey, cool hack in progress".

As to 3D accel in VM: I'm running the newest of workstation (have a license for work) and VMWare tools are in fact installed.  I found a mention online about needing to set certain values, and I did so, and even confirmed in the VMX that the settings are there (enabling 3D accel and devoting some hardware memory to it).  However, still no dice.  Within the VM I try to install my GeForce drivers, and it simply aborts the installer, saying no suitable hardware was found.  So in truth, it might actually work... IF the device driver installer could find the device.  It's driving me a bit nuts.

You do NOT want to install geforce drivers within the VM; the vmware tools package provides the appropriate things to get the guest to make use of the host's hardware.

In general, outside of specific things like USB devices which have been mapped directly to the guest (and thus aren't "connected" to the host), you do not want to install drivers matching the host hardware. The whole point behind virtualization is that everything it thinks it sees is provided by the virtualization framework, rather than actually seeing the real hardware. And a lot of the time, the easiest way to do that is to present a generic set of 'devices' which don't necessarily match to any real-world hardware at all, nevermind matching the hardware sitting on your desk.

I want to mention again the degree to which 3d acceleration can work is mostly related to the _HOST_ OS. You haven't said if you're running windows, linux, mac, solaris ( ), you've only mentioned you're running XP in the guest. Is the host Windows? If so, XP, Vista, 7, 8, etc? Or is it something else?


As an aside on a previous user's comments, any 32-bit windows process which isn't Large Address Aware is limited to ~ 2 gigs, due to how win32 maps the address space. By default, DF isn't one of these, and as mentioned elsewhere, DF and dfhack are running in the same process space, so they have to share that 2 gigs.


Have you tried running some other lightweight 3d-rendering app, just to get another point of reference?