But can [moving the camera during worldgen] now be done unpaused? Sorry for asking, it's just that this sentence feels ambiguous.
Do you think it would be feasible to do [mod options] before the first release? Even just being able to enable and disable particular raw files (or multiple raw files) from being loaded/read based on labeled checkboxes (maybe also with a descriptive "this will enable X" blurb written by the mod author) being ticked or not would go a long way, basically offering equivalent power to what we have now, and it would solve the potential problem of the workshop (and DFFD probably) being filled with similar but slightly different versions of mods. Being able to enable or disable specific chunks of raw files (marked by special tokens at the start and end of the "chunk") would be even better, but presumably a bit harder to implement.
What's the limit for zooming out, and what's the cause of this limit? I worry if it might prevent larger screens from being able to see bigger sections of the embark (leading to them just having "bigger tile squares" instead, which isn't an ideal use of extra screen space).
[identical filenames:] What about the header at the top of the file (which can be different to the filename in principle, though usually it's the same), or was that implied in your response?
Ah, no, not currently. It would be simple, though I'm a bit worried it'll still lag if somebody is deep in a large world gen. It hasn't been noticeable in the 200s on a large, so maybe it'll be fine. Things tend to get even more intensive though as the number of events etc. goes up.
It's feasible, the first one anyway. I'm not sure how fiddly the chunk one would get, since not everything is set up to be parsed the same way as the creature ones (which offer some of that "do what you want with the raw text" functionality), if I recollect.
Zooming is out, currently, which perhaps ruins the images A_Curious_Cat was trying to make. I didn't know they were animated. This happened early on, since the zooming worked by making copies of the glyphs, and that just doesn't work fast enough now. If we ever get textured quads it'll be pretty easy to bring back since those scale naturally and the grids are all set up to scale, but if I remember we never attained a textured quad/triangle print that we could turn on by default. This is one of the things SDL 2 might give us, since it has more texture support, but I don't know and it's difficult to justify a possibly failed month trying at this point.
Are gremlins being trainable intentional, or a case of a pet token you forgot to remove? Given they're the only sapients you can train, and trained sapients are buggy at best, I was wondering whether it was an accident or something you actually intend to expand upon later.
PatrikLundell:
http://www.bay12forums.com/smf/index.php?topic=169696.msg8350582#msg8350582Yeah, this is all kind of half-assed, based on a very old joke/easter egg that gremlins could be 'tamed' after being caught in cage traps but then would still go pull levers, if this ever worked. It should probably all just be turned off at this point and revisited from something more like the villain/impersonation context vampires etc. use, and that wouldn't be a high priority thing.
How much can/has DF be/been multithreaded?
As CPUs grow wider and not fast, it seems like headroom for performance for Single Threaded applications has been reached.
DF seems to have a lot of opportunity for threadedness which has not been taken advantage of but this can be hard to perceive. Often threadable tasks are quick and efficient while the non-threadable tasks may be long and slow so the actions which were threaded are completed quickly and wait while the rest of the software completes.
Are there other milestones which stand in the way or things which need to be stabilized before threading is safe?
PatrikLundell:
http://www.bay12forums.com/smf/index.php?topic=169696.msg8350582#msg8350582Don't have much to add to what PatrikLundell said. The display code does run on a separate thread (thanks to the people that set that up, not me!), but expanded to other stuff has proved more difficult, despite the help people have provided with e.g. microthreading code examples etc.
Will the other main civilizations (especially humans) get hairstyles for the Steam release? It looks like only dwarven civs have defined hair styles in the raws it seems, and now that we have graphics, it could be weird or samey looking if everybody ends up with super long ungroomed hair unless they live with dwarves.
It was noticeable yeah, ha ha. There's a note for it, and hopefully that'll be done.
I noticed a while back that night trolls that abduct creatures always transform their new mate exactly 9 months after the kidnapping. Is this because of pregnancy time? Does this mean that giving birth to a night troll's child turns a creature into a night troll? Why does it work the same way for male abductees? If worldgen happens to end during the time between a kidnapping and the transformation, could I travel to the night creature's lair and peer into the data structures to see if the female is pregnant?
It looks like the conversion happens randomly during 2.5% of the weekly updates, and then a child is immediate the next week after conversion. There's no pregnancy.
Have you considered allowing players to designate an entire ore/gem vein from an exposed tile instead of using a selection rectangle with sub-settings? I was recently reminded that the former is not a vanilla function (DFHack), and seems like a good quality of life addition for Steam.
clinodev:
http://www.bay12forums.com/smf/index.php?topic=169696.msg8352654#msg8352654Salmuek:
http://www.bay12forums.com/smf/index.php?topic=169696.msg8352666#msg8352666I don't like the ability to distinguish invisible tiles, if Salmuek's correct that this is what you mean. The vanilla automine feature was meant to cut down on the amount of (at the time) keypresses required to follow a vein, but I understand that the vein might loop back around to ruin some other plan you'd made. I'm not sure how to fix this without omniscience or some fiddly blocking feature related to blueprints.
1. Why are embark tiles 48x48? It feels like a weird number, neither just an intuitive even number like 100, nor a power of 2 like 32 or 64.
2. Would custom/moddable biomes and dimensions be possible in the future at some point after the map rewrite and mythgen?
That is, for biomes this would ideally enable things like custom ranges of flora/fauna with different predominances.
And for dimensions, would allow stuff like their own set of biomes and geology/material composition and structural generation (probably borrowed from other parts of worldgen, like "this is a cavern-like dimension" or "this place is made of floating rocks in a void" or something; or maybe that would be per-biome or something) and their metaphysical/magical rules (to an extent anyway; leaving some flexibility for mythgen to play with the dimension to varying degrees would be good probably).
In both cases, I mean in advance of worldgen itself for worldgen to work with, not just editing a specific world map post-worldgen with the "map editor" that's been mentioned before.
PatrikLundell:
http://www.bay12forums.com/smf/index.php?topic=169696.msg8353052#msg83530521. Yeah, this is a weird ancient number - PatrikLundell may be right, but it's been so long I have no idea. I would have done 32 or 64 these days. There is a #define for it and I can just change it in that one place but... I think the number of bugs that would pop up would be extreme indeed, ha ha. I'm pretty sure even the map rewrite won't be enough to make the change, since it's just too dangerous.
2. Yeah, this is the idea (we've often talked about sphere-oriented regions, and it's kind of grown now into the map rewrite and the idea of editors and how myths will interact with it all to do various interesting stuff.) The editors should go beyond map editing, if that's in question. You should be able to work with more compact definitions that generates myths and worlds and regions, in addition to actually drawing stuff if you want. It remains to be seen how this will evolve though, since it's probably the largest project we've taken on and there is some desire to try to approach it in pieces - it's not clear how much it can be cut up.
How would mod updates work with the fact that saves don't keep raws anymore? One thing I see that worries me is that neither DFFD nor the Steam Workshop store old uploaded versions of mods (uploading a new version replaces the old one), so if all saves share mods (since they aren't stored inside the save folder anymore), that means updating a mod could irreversibly make all existing saves using it unplayable, and therefore as long as those saves exist, updating mods won't be safe/doable, so it won't be possible to use an updated version in a new save even though it could make use of it (if not for the other existing saves relying on the old version).
Old installed mods should stay around at least - it unzips them into their own folder, which doesn't conflict with other installed versions, and I don't think Steam erases those since it isn't linked to their database. So there's one buffer anyway, though it wouldn't help if you had to reinstall the game or use another computer. Of course keeping the old installed mods also leads to a garbage pileup issue, since mostly you'll just want newer (compatible) mods. Not sure what to do about that yet.
Ok, if I understand correctly, Adventure Mode isn't sure to ever be released in the steam version ? That would be too bad, it has crazy potential !
Mr Crabman:
http://www.bay12forums.com/smf/index.php?topic=169696.msg8354137#msg8354137iwantjelly (op):
http://www.bay12forums.com/smf/index.php?topic=169696.msg8354248#msg8354248voliol:
http://www.bay12forums.com/smf/index.php?topic=169696.msg8354252#msg8354252The roadmap post
http://www.bay12forums.com/smf/index.php?topic=174112.msg8354566#msg8354566 is where we are at currently.
How often are you designing/planning/discussing other future stuff during, or when taking pauses from, working on the Premium release? Compared to during a more ”feature-heavy” arc like the villains one. Is it more often as revamping menus is more samey? Or more seldom because of being busy or having planned out what can be already? Or about the same?
The Premium release is taking up basically all of our DF time now.
1. The number of sliders that can be put into the "main" generation screen is limited for obvious reasons of not being overwhelming; just some basic stuff, and all the masses of complex options get shoved into the advanced worldgen menu.
But for myth and magic (and maybe even future updates possibly, if you have plans that far ahead), what do you imagine these "top level, non-advanced" sliders for worlds would be? The most obvious ones (and which have been mentioned before) for myth&magic are a "mundane vs fantasy" slider, and a "randomness" slider separate to that maybe (though what a zero-fantasy world with high randomness would even mean?), but there also has been mention of things like world bleakness and such in the past, so I'm curious what you consider worthy of being a "basic" slider for the normal worldgen menu.
2. So you got a new batch of music from the composer apparently... What will it be for?
1. This dates back to the first Armok (where it obviously didn't go anywhere), but the idea is to allow people to make a fantasy setting of their choosing. Since the myth stuff has proven so promising, I'm not actually sure how we're going to narrow it down now ha ha. The old three slider idea seems like it doesn't capture everything, but it might not be too overwhelming to just have a few tabs concerning structure, progression/narrative, and atmosphere that you can kind of rabbit-hole down into if you choose to expand certain options. It'll become more clear I think as the raw/generator format settles - I'll more easily have power over some things than others, and it'll make sense to highlight those levers.
2. Legends, more seasonal stuff, caverns, battles... and there's more coming, ha ha. This has been going quite well.
1. What menus could not make it over to Classic semi-automatically? Due to what UI elements? The icon buttons?
2. It makes sense to me that Adventure and Legends mode get priority over Steam Workshop support. Is 4. on the roadmap just investigating Workshop, or for implementing it as well if it doesn’t take too long?
3. Have you figured a way to make future menus Classic/Premium-proof, having seen what broke this time? So that you won’t have to do double menus in the future?
1. Yeah, the icon buttons are the main problem, and every menu we've shown that uses them. Which is almost all of them in one way or another. The buttons are very compact, and if the ASCII+tooltips don't suffice, then we'll need bigger, textier buttons in those cases, which can cascade outward.
2. If it doesn't take too long, then yeah. It's nontrivial, I've been told, but hopefully straightforward - I've never done any internet code before, so if their library/etc. doesn't handle that part, it'll be much more difficult. Once I can get a subscribed mod zip on the disk, we should be in good shape.
3. Some thought and experience will go a long way, ha ha. I think double menus will probably be justified in some future cases, but the restrictions and requirements will be in mind, which should be most of it.
Does "haven't done anything with Adventure mode and Arena mode yet" mean these modes would be available with the old (0.47) interface? Or unavailable at all?
If they don't have graphics and mouse support, they won't be in the Premium release.
Will the weapons made by Ironhand keep the same style, or were the bases as well as the variations we’ve seen made by Meph? If they have changed, may we see them (for mod spriting purposes, as well as curiosity)?
Where does tutorialization go in the roadmap? With the tool-tips?
I am hopefully showing some of these in the dev log presently. They are a bit different, and the coloration method is new.
Yeah, when we do the tool-tips etc. we want to come out of it with that part complete.
What sort of features for Legends mode were you thinking of for point 5 in the roadmap? I assumed the hyperlinks, tabs and worldgen chronicle were going to be the end of it to be honest, at least until post-release.
The main thing we are missing from the ASCII version is the maps.
1. Are there any plans in the near future (post-Steam release) to implement a description tag for things like plants and items?
2. Even if the graphical version of the game is published with only fort mode available, will the classic version of the game exist on steam as a separate branch of the game you could chose to install?
What are the legalities of releasing the game on Steam without ASCII or Adventure mode? Considering the parity issues mentioned before, and that those parts would exist outside of the Steam version in 0.47.05, are there any risks of 0.47.05 downloads on the Bay 12 site leading to trouble? Or does that mean including a 0.47.05 download as well, somewhere in the Steam setup for Premium?
Mr Crabman:
http://www.bay12forums.com/smf/index.php?topic=169696.msg8355304#msg8355304 1. It has come up, but never really had a time to be slotted in. There's also tension with procedural stuff and details of how they are used and such. We're not generally going to be a Qudlike game in the sense of having well-written descriptions.
2/voliol. Steam has said they'd be satisfied with branches as I recollect.
1. How flexible is the versioning for mods? Like, is it just a string that you can put anything in, or does it want 3 numbers separated by dots, or an arbitrary number of dot separated numbers, or what?
2. Do you expect that there would be any kind of automatic version compatibility detection for mods (based on author-provided information of course), or would the nature of the version numbers make it just something the end user has to figure out? Like, if the author says that "3.0" is incompatible with "2.9" saves, would the syntax the author uses for that make it possible for the game to auto-detect that the mod shouldn't be updated to 3.0 for that save?
3. Will it be possible for graphics packs to define a greyscale texture and then have it be filled in with a true color? I ask because this old post by Meph: http://www.bay12forums.com/smf/index.php?topic=178199.msg8255811#msg8255811
Shows that hair colors for example, are bunched into groups, where each defined color has to point to its own specific sprite in a spritemap; so basically, would it be possible in principle to only have one sprite for a given hairstyle, and pull the color for the (greyscale) sprite directly from the defined set of colors? Or does each color always have to be its own sprite?
1+2. The displayed version can be anything. Rather than trying to parse various formats, there's also a simple integer version that isn't visible for the player. It'll be slightly annoying for authors to keep tabs on it separately perhaps, but I wasn't sure of another way to do it that didn't force a standardized version format, which I assumed people wouldn't be happy with. And the main benefit was that automatic version compatibility detection is just a simple check for bigger numbers, against whatever numbers the authors provide.
3. This has changed quite a bit. Rather than grayscale, for many items now, we've implemented palette swaps, so that each color can be selected more artistically. I'm not sure if hair colors will get the same treatment or remain as they are for now, since each implementation takes time, but ideally that would lead to the best looking hair since highlights could be done without being forced into a flat or overlay model as we had been doing previously with e.g. minerals and swords, which led to things looking a little dull or washed out.
Why does DF use its own special format for raw files instead of an existing format (and particularly, why was the decision made that the format should SCREAM EVERYTHING)?
Additional question along these lines, under what circumstances would you switch to a more traditional format for raw fies? You've mentioned before the idea of switching to a "proper scripting language" in a way that didn't sound like it was totally out of the question, just impractical.
PatrikLundell:
http://www.bay12forums.com/smf/index.php?topic=169696.msg8356159#msg8356159PatrikLundell is correct in that even though stuff like Python/Lua is from the 90s (as far as I can tell), I hadn't heard of it by the time I started the DF txt files, though it's hard to remember exactly... I think the first game I knew that used Lua was Civ 5, after DF was out and about for years, and as I recollect, this is really when I became aware of standard practices of game scripting languages, though I might be forgetting something. Civ 4 used Python I think, but I wasn't aware of that. Dunno about before that. I remember messing with Age of Empires (1) flat files but don't remember if they had a standard format. In any case, it wasn't on my radar as something really useful until it was too late.
It'd be a huge project to implement. The least problem is the amount of text files to be converted - much harder I expect is all the various code integration, with the added problem of my having zero experience at all here. I don't even know if Lua is the normal decision anymore or if other things have become more accepted.
Author
Topic: Future of the Fortress (Read 3135568 times)