How does the idea of grouping different versions of a single mod inside the same folder sound for helping with this issue? And under the same "slot" in the ingame list, with a list of which versions you have alongside the description stuff (maybe a dropdown menu where the version number is displayed). This would at least somewhat neaten the mod folder and ingame modloader (so the garbage buildup would just be about disc space rather than clutter), unless this is how it already works?
Could the current/old versions be enabled through some out-of-the-way config option somewhere, maybe even requiring editing a text file instead of just toggling something in the menu? At least the Object Testing Arena, because it's quite handy for... Object testing. Trying to update mods for the new graphics functionality (or trying to make new mods entirely) for the Premium version would go somewhat slower and more painfully if there is no way to instantly test things on the Premium version, and if the concern is exposing unwitting new players to an unpolished and difficult to use menu, requiring out-of-the-way configuration to access it would solve this.
Can 2 different files in different mods use the same header? By "header", I mean the first line in the raw file, which apparently, unlike the actual filename, determines the raw loading order; for example:
creature_other
[OBJECT:CREATURE]
[CREATURE:FOXSQUIRREL]
Here `creature_other` is the header, and `creature_ocean.txt` has the header `creature_ocean`.
So the question is basically: will 2 different, simultaneously loaded mods be able to use a file that is named `creature_other.txt` and have `creature_other` as its header (and each mod would have different contents in each file), or would this cause one of the files to be ignored or overridden?
Having to be careful about naming the mod identifier itself, and about naming object identifiers (assuming you don't want to overwrite the vanilla [CREATURE:DWARF]) makes sense, but the filenames and headers would be rather convenient to have "isolated" within each mod so that one can just use readable filenames/headers without worrying if someone else has used them.
The disk space issue was the main issue I was thinking of, but it doesn't nest them currently, just shows the version numbers.
The modes don't function now, and I'm not going to try to cludge them in since it'll take extra time to make the parallel systems work. In arena mode's case that's probably the same amount of time as just doing the necessary arena mode menus.
I'm pretty sure the filenames can overlap between mods, and the header line there too (which should probably just be removed.)
Zach says you're good at guitar now, and you said you've been practicing for years... any chance we can get a secret (patron only? 
) bonus track for the release of the steam version of something in the same style by you? As much as you disparage your improvisation from way back when it has a mood to it and I think people would love something in a similar style and I hope it would be a pretty low effort project for you.
It doesn't feel low effort, ha ha. Doing an actual track for the OST sitting by the other tracks would require more time/focus than I can justify.
You've said before there's going to be multiple "passes" of magic update, and the first one isn't going to have all the stuff you have planned, but will lay out the framework for it to be possible. Where do these "extra passes" fit into the timeline? Are they just multiple different releases one after the other (and being released in pieces/passes so that the big wait isn't quite as big), or would they be separated by other update arcs like starting scenarios or economy or boats?
Dunno! Even though it's still a huge release, we're going to try to do the smallest release we can that still has large stuff we need (like the map rewrite.) That'll take long enough and change enough that we'll have to see where it goes from there.
Is there any technical constraint or conceptual reasoning behind beverages not changing in qualiy the same way meals' quality depends on cooking skills? I just noticed how brewers don't get to make masterwork distilations, and I wondered if alcohol quality was ever considered before as a feature.
It has come up but I don't recall what the reason was at the time. That they are used in cooking? That they are more numerous and easily divisible, so it could be a data control thing? I can't think of any strong reason though.
Is the new palette swap system going to be used for all items and constructions (walls, floors etc) so that the colors are accurate? I heard before that constructions weren't going to be recolored because it wouldn't look great, but with the new recoloring system that answer might have changed.
There were some early technical difficulties with floors, due to edging, but that's kinda-sorta handled, and constructions don't necessarily need or want edging if you want to do, say, mosaic floor patterns that look clean. We haven't drawn these constructions yet.
Will there be any changes to how "evil" artefacts get handled? For example the reason why necromancer apocalypses are so common is because after a slab is made, if the new necromancer either doesn't do much with it before perishing (persumably if they dont want to conquer the world/write books forever) and it gets dumped in a random hamlet/town it inevitably leads to the death of all nearby civilization because any random civilized mortal person who wants to become a necromancer can become one just by reading it with no delay. I doubt that anyone other than goblins/maybe weirder human civs would keep a dark slab like that around, especially if they know the potential consequences. Will this ever be changed? If it were would this apply say to artefacts made in fell moods/from goblin's doing murdering. It seems odd that fell mood artefact creators seem to go unpunished by their civilizations as well. Is this intentional?
Yeah, I imagine it'll be changed at some point, though not before the magic stuff generally most likely. It is a bit odd that readers are so enthusiastic.
I remember it was an intentional decision for the fell mood dwarves, and I think that was a combination of it being early in development (so we couldn't easily manage whatever we might want to do to them), and of them being feared/respected because of the artifact though we didn't think too much about it.
currently, all overground crops can be planted year-round. will this be changed before the Big Wait?
It isn't a focus of any of the arcs at least. I agree it's weird and not ideal for the game.
As I understand it, engraved floors will now show an image of the thing engraved. How does this work for the more abstract subjects, such as the shapes? Does it show only the first noun if, for example, the description is complex (for instance, "a Dwarf slaying numberless goblins. The dwarf is laughing," would render as a dwarf?) If the image is of a specific historical figure, how does the game 'dress' the image- is it based on what they're currently wearing, or is it based on their occupation? If so, does the game remember their occupation after death? Are generic dwarfs naked?
How does the material blend with the colour palette in engraved images? What I'm thinking of is, if a particular material has a primary colour of black and secondary of green, and another material, primary of black and secondary of green, could you make an attractive chequerboard pattern of circles with the right material?
Do you have any plans for constructed engravings?
Putnam:
http://www.bay12forums.com/smf/index.php?topic=169696.msg8364173#msg8364173The engraved floors don't show anything because they haven't been drawn yet, and we'll have to see what happens. It might be too much to redraw all the large creatures to fit in a 32x32 etc. The image selection will work as Putnam describes. Doing entire scenes is too much to attempt, though at some future date some of the most common scenes (multiple dwarves etc.) might be attempted.
I imagine the colors will work the same way they'll work with the palettized floors, once we've drawn those if that's the way we go. That is, one color - vanilla materials have one color as far as I remember so I'm not sure what you mean about primaries and secondaries. Do you mean the ASCII background/foreground colors? It uses the material colors/RGB from the raws now.
I remember we have notes for engraving constructions as being a possibility for this release. Haven't gotten there yet.
1.Are the starting 7 ever gonna have customizable personalities and traits?
2.It's pretty annoying how once you retire your fort, half your dwarves leave. Is there any planned fix for that?
1. It'd be reasonable, but I'm not sure when. We did that whole adventure mode personality setter and if I remember were vaguely thinking of moving it over, but that wouldn't be possible until it's updated itself.
2. I'm not sure what the context of this question is. A bug (there are various retirement bugs), or the migration? They all join the migrant pool like other historical figures, so you can see them in future forts, so that part is intended.
Are there any plans to have countries have borders? Kinda hard to draw world maps when all the countries are interlaced with each other.
The mess will likely continue, since things are supposed to be messy, though we have a few additional notions we didn't have originally (with the various holdings) that give it a bit more structure sometimes.
Author
Topic: Future of the Fortress (Read 3135684 times)