Print

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

[voliol]

I don't know the answer to the second one, but there's a lot of modding knowledge floating around the community which is poorly or not written down at all. Asking first in one of the modding threads is always better because it 1. offloads Toady, 2. probably gets you a quicker answer, and 3. brings up the topic in case it is under-researched, and the subsequent !science! can either solve the issue and advance modding, or home in on a less broad question which is quicker for Toady to read through and answer.

Fair enough, this makes sense; I should probably edit that question out then?

Yeah, I would say so.

[Su]

hi toady! bit of an unusual question today - we've been watching/reading this talk [from the 2020 virtual Roguelike Celebration] on using hash functions instead of using rand() to randomly decide things, so that rng calls won't be affected by earlier calls. it's very interesting.

does dwarf fortress do anything like this already, or have you considered the technique? we recall there being something in one of the update posts a while back that sounded you were suffering from this problem.

[Mobbstar]

hi toady! bit of an unusual question today - we've been watching/reading this talk [from the 2020 virtual Roguelike Celebration] on using hash functions instead of using rand() to randomly decide things, so that rng calls won't be affected by earlier calls. it's very interesting.

does dwarf fortress do anything like this already, or have you considered the technique? we recall there being something in one of the update posts a while back that sounded you were suffering from this problem.

May I enlighten you to srand(), the function that takes an uint to do exactly this?  It sets a "seed" for rand() and thereby it will always generate the same sequence of random numbers.

Advanced world parameters already do this!  There's a seed for geography, one for history, etc.  To my knowledge, there are no seeds used in Fortress or Adventurer mode.

[Su]

hi toady! bit of an unusual question today - we've been watching/reading this talk [from the 2020 virtual Roguelike Celebration] on using hash functions instead of using rand() to randomly decide things, so that rng calls won't be affected by earlier calls. it's very interesting.

does dwarf fortress do anything like this already, or have you considered the technique? we recall there being something in one of the update posts a while back that sounded you were suffering from this problem.

May I enlighten you to srand(), the function that takes an uint to do exactly this?  It sets a "seed" for rand() and thereby it will always generate the same sequence of random numbers.

Advanced world parameters already do this!  There's a seed for geography, one for history, etc.  To my knowledge, there are no seeds used in Fortress or Adventurer mode.

we believe you may have misunderstood - if a call to rand() is placed before another call to rand(), the sequence will be shifted along.

consider the following scenario: a call to the rng to determine, say, the qualities of a religion, and then a call to determine the outcome of a battle. if a new call is inserted between these two, say to implement a new worldgen feature, the sequence will be shifted along - meaning that the outcome of the battle could be completely changed, even if the new feature had nothing to do with the military and happened halfway across the world. hashing avoids this problem.

unless you mean calling srand every single time you make a call to rand() - but at that point you've basically reinvented the hash function.

[DwarfStar]

The way the world gen thing works, there are multiple random-states for different purposes. So you can at least leave the other ones unaffected if you only add a call to one of them.

srand, though, is a particularly bad way to explain that concept since it only has a single static/global state. But you could do it if your compiler speaks C++11.

https://en.cppreference.com/w/cpp/numeric/random

In DF I’d wager they have their own random classes since they’ve been dealing with this issue before those functions. Those could be converted over to the new standard ones, but there’s little benefit to changing.

[lethosor]

The simple switch up to SDL2 makes the most sense first.

This is something that could potentially be good for pack/mod/utility maintainers to plan for (including myself), and I haven't been able to turn up another recent reference to this change, so I thought I would ask here just to clarify for those of us who it would affect:

Are you planning to upgrade DF to SDL 2 (or has it happened already)?

[Mr Crabman]

What changes if any do you have planned for the likes of combat report logs, and the "block of text describing this creature's current injuries"? For the Steam release that is.

For the dragon/constrained randomizer, do you have any idea at this stage how descriptions would work? Currently descriptions for most creatures are manually entered into the raws, and for procgen creatures follow a hardcoded format for certain bodily traits and abilities.

But if dragon variations are to be exposed to the raws, presumably just 1 description couldn't cover all possible dragons without being extremely vague, but hardcoded means of generating descriptions seem a bit tricky to pull off in terms of how to neatly describe important features without describing too much, and in a bland manner (ie being too "anatomical/clinical" or repetitive, and lacking in flavor like many of the manual descriptions currently have), especially if the constrained randomizing functionality isn't tied to dragons/is expanded to other creatures.

To an extent this also applies to other procgen stuff planned to be exposed to/manipulable in the raws at a later point in some way, and because of how after myth and magic, a lot more creatures in a world may potentially be randomly generated.

EDIT: Same sort of question also goes for prefstrings.

Also, why is it that only integers seem to be used in the raws for everything? I don't think any numbers use decimal points as far as I can tell.

[PatrikLundell]

The roots of DF are old, and might be old enough that floating point calculations came on separate boards that weren't included in all computers (in particular luggable ones). In addition to that, even with an FPU, floating point calculations were still considerably slower than integer math.
Add to that the mess caused by CPUs using different number of bits for calculations with the resulting non reproducible results across different architectures and you need a compelling reason to abandon the relative stability of integer math.

It doesn't exactly help that high level assembly language (a.k.a. C(++)) doesn't specify the size of its "standard" units, so you either have to roll your own or have the result differ on different architectures.

[Mr Crabman]

What's the purpose of using GO_TO_START in creature variants? For example:

Code: [Select]

[CREATURE:GIANT_TOAD]
[COPY_TAGS_FROM:TOAD]
[APPLY_CREATURE_VARIATION:GIANT]
[CV_REMOVE_TAG:CHANGE_BODY_SIZE_PERC]
[APPLY_CURRENT_CREATURE_VARIATION]
[GO_TO_END]
[SELECT_CASTE:ALL]
[CHANGE_BODY_SIZE_PERC:100700]
[GO_TO_START]
[NAME:giant toad:giant toads:giant toad]
[CASTE_NAME:giant toad:giant toads:giant toad]
[DESCRIPTION:A huge monster in the shape of a toad.]
[POPULATION_NUMBER:10:20]
[CLUSTER_NUMBER:1:1]
[CREATURE_TILE:'T']
[COLOR:2:0:0]
[PET_EXOTIC]
[PETVALUE:500]
[MOUNT_EXOTIC]
[GO_TO_END]
[PREFSTRING:beauty]
[APPLY_CREATURE_VARIATION:STANDARD_WALK_CRAWL_GAITS:3512:2634:1756:878:4900:6900] 10 kph
[APPLY_CREATURE_VARIATION:STANDARD_CRAWLING_GAITS:9000:8900:8825:8775:9500:9900] 1 kph
[APPLY_CREATURE_VARIATION:STANDARD_SWIMMING_GAITS:9000:8900:8825:8775:9500:9900] 1 kph
Here you SELECT_CASTE:ALL, and then add one token, and then go back to the stat to add a bunch more tokens, and back to the end again.

But why is this? To my knowledge, the very start of the object is treated as the ALL caste already, so it doesn't seem like it makes a functional difference whether these tokens are at the start of the object, or at the end inside SELECT_CASTE:ALL, and it doesn't seem to serve a clear stylistic purpose either; my only guess is that maybe you look at the end resulting raw object after these commands have been processed, and so you get to see those tokens actually look at the top like with all "normal" creatures.

[Toady One]

Are dwarves from other civs meant to join player fortresses? They just show up there and quietly declare themselves members of a different nation? Are they alliance visa, or war refugees?

FantasticDorf: http://www.bay12forums.com/smf/index.php?topic=169696.msg8301122#msg8301122
Nilsolm: http://www.bay12forums.com/smf/index.php?topic=169696.msg8301131#msg8301131

So it looks like it pulls historical migrants from the player's civ only, unless they are vampires.  But these herbalist etc. migrants that are showing - were they not members of the player's dwarf civ?  Were they ever members?  It's hard to see how they get on the list it's pulling from if not, but if it's happening it's happening.  The intended behavior is to not even have dwarf migrants from other dwarf civs (although like others they'd be allowed as tavern visitors and then get in through petition.)

The game does however allow children of pets, if they were born intelligent, to be assigned labors, rooms, squads, noble positions etc, and includes them under the cirizens tab. I know because I've used unintelligent pets in a rare caste to give birth to a frequent caste of intelligent children to pump up my citizen count artificially. Is it possible to enable these things on all pets that are intelligent? The game seems to already recognize them if they're born into your fort, but not tamed on site or bought from a caravan. Gremlins and trolls brought on embark (by civs that allow them) and pets that gain intelligence through a syndrome automatically self-assign labors they're skilled in and hauling/cleaning/construction labors, but the UI elements to assign labors yourself never appear unless they're born into the fort and intelligent from birth, making them a citizen that carries the (TAME) flag around their whole life. So from personal experience it looks like a UI element not getting turned on/off rather than additional issues.

Also, I've never seen gremlins do their mischievous thing once tamed. Whether brought on embark, bought from a caravan, or caught and tamed on-site, they either do their default labors, or hang out in meeting halls. I suspect that something is broken there.

FantasticDorf: http://www.bay12forums.com/smf/index.php?topic=169696.msg8301863#msg8301863
Eric Blank (op): http://www.bay12forums.com/smf/index.php?topic=169696.msg8301886#msg8301886
FantasticDorf: http://www.bay12forums.com/smf/index.php?topic=169696.msg8302004#msg8302004

It's not an easy change sadly - there are a lot of places where the game checks for pet status, or intelligence, and it just sort of assumes those things are exclusive.  It'd be a big project I think to disentangle that.  The number of bugs and oddities would still be high even if the interface were opened up.  It's also not clear what it means to have an intelligent pet ethics-wise here, since dwarves don't do slaves, and the game especially wouldn't understand the syndrome since it uses the creature-type check too often when making certain decisions, especially in older code.  Ideally when the syndrome hits, they'd be changed into a friend relationship or something.  In relationships that are supposed to be deceptive as with the gremlin's intended behavior, another wrinkle is added.

On the topic, if animals as mounts and companions  were to expect more scope for fortress mode and w.g as a whole (ei army arc dedicated cavalry), would the current distinction of non-histfig animals logic end up being changed eventually to create historical and non-historical populations?

EI - The named horses and animals are found in the stables but all the strays still linger around with a more even distribution on w.g of how animals are represented / dwarves bonding with their mounts or giant ridable housecats choose who can ride on their backs.

It seems that way - it already happens when there are slayer-animals, and they are historical when they are pets in fort mode.  I think it'll just naturally follow whatever features we add.

There is by any chance add a FORCE dig option (explanation dig even if there is damp location) for our tiny dwarfs? sometimes I want to dig through an aquifer location without having to remake the tile to dig again.

Bumber: http://www.bay12forums.com/smf/index.php?topic=169696.msg8302058#msg8302058

This one is reasonably high up on our list of things that need to be handled in some way.  It's probably even more annoying now that most of the aquifers can be managed without advanced techniques.

In the "s" Squads screen, using "p" to select individual dwarves for squads #11 and higher never works, while it does work for squads #1-10. Is this on the radar to fix?

Whatever the military/squad menus end up turning into, I think this will stop being an issue just by virtue of the scope of the updates.

Will the new multi-z-layer display be toggleable?  Can we turn it off and see just one z-level at a time?
I can picture myself turning it off briefly as a way to confirm what I'm seeing, especially with ramps/slopes (fairly often until getting the hang of the new graphics).

clinodev: http://www.bay12forums.com/smf/index.php?topic=169696.msg8303490#msg8303490
Uthimienure (op): http://www.bay12forums.com/smf/index.php?topic=169696.msg8303689#msg8303689

Yeah, clinodev (and Meph) answered it here - we're going to have some settings/toggles at some point, and in-game rather than over in d_init or wherever we'd normally hide it.

is that old development page accurate in that while it's probably incomplete and not in the planned order, everything on it is still planned to be done eventually, or would some features have been scrapped?

Some of it is surely outdated now, and some are no longer priorities which can be reached in the time we have left.  But the myth/magic stuff is more ambitious in some ways now I think, and should do a lot of it justice in a general sense, and then on into the society stuff after that.

1.When are we going to actually see festivals during gameplay?
2.Sorry if this is too much of a suggestion, but it's kind of a bummer how colosseums and skulls on pedestals do nothing but give your people trauma (especially when playing a modded race like goblins). Are there any plans to change that in the near future, maybe taking certain traits like cruelty into account?
3.Are we going to see Adventure mode ai improvements before the big wait? It's pretty silly how I can murder innocent villagers one by one and all they do is cry and spit on me.
4.I remember you mentioned adoption being added in the near future. Is this going to allow gay/asexual figures to get heirs?
5.Dungeon Masters don't do much right now. What exactly are they planned to do once the villain update is over?
6.Are we going to see more flexible magic system? IE systems that let you create your own spells?

FantasticDorf: http://www.bay12forums.com/smf/index.php?topic=169696.msg8304002#msg8304002

1. I think FantasticDorf covered this well enough.  I never have dates for anything anyway, and it isn't slotted in the shorter term timeline.
2. No plans in the near future!  But it is unsatisfying I agree.
3. I don't know what specifically will be addressed, but the adventure investigation/villains/army stuff comes before the big wait, so some things will change!
4. The immediate concern was babies crawling into lava, so that would mean that in fort mode yeah, your monarch could potential adopt and then pass their position on, in situations like that where it wasn't supported before.  But I'm not sure if it would happen in worldgen at first, since it's harder to keep track of all the orphans there and get them sorted without potential FPS trouble, but if it happens it'll cover everybody.
5. They have the espionage token, so theoretically they'd be enabling and be responsible for the player's shenanigans. As with the manager, it might not be much beyond that, though when we get into the situation of imperfect knowledge, which we've already got with the fort heist situation, suddenly what the dungeon master knows and doesn't know might be more important.  But there's trouble here on the player interface side - if the dungeon master dies, it might be a bit much to delete all of the things you know (driving the player to like, pen and paper.)  So, I think it'll take some feeling out as we go.
6. One of the main points of the myth/magic releases was to get at procedural magic systems, and these sorts of things are on the table.  We all know the spell maker from the elder scrolls, and there's also systems like Spellcraft where you can change up amounts of reagents to get variable levels either in prep or on the fly, and perhaps most ambitiously, systems from literature/myth where effects/powers are more freeform like "I can create and control water and do whatever with it" - those will be some of the harder things to capture, and create interfaces for, and mechanics for, etc., but we're hoping to not just be bound by the idea of discrete "spells" in the usual way, that sometimes it would function differently.

What if players will have some limited access to legends right during their fortress/adventure runs that will only allow viewing events that are known to the player? This would really bring joy of discovery and some order to the information you know (especially useful in adventure mode)?

PatrikLundell: http://www.bay12forums.com/smf/index.php?topic=169696.msg8304031#msg8304031
LordL (op): http://www.bay12forums.com/smf/index.php?topic=169696.msg8304431#msg8304431
PatrikLundell: http://www.bay12forums.com/smf/index.php?topic=169696.msg8304439#msg8304439

The knowledge issue is tricky, as said in the replies, but there's probably some reasonable level that can be shown even in fort mode without spoiling things, just to make use of all the added intricacy worldgen provides.  We've been thinking about this again lately since it's a whole thing sitting there that isn't really used.  When I do the new legends hyper-links type interface stuff we'll see if something happens in fort mode.  Adventure mode is a whole other critter and we haven't done enough work there to say, but it's reasonably that you should know what everybody knows about the bigger issues.

I don't understand how "...but the jobs will be done by anybody available, starting with the most talented." can work unless most of the work force is unassigned to any "real" job. In the current system dorfs select posted jobs as they become available for new jobs, unless unoccupied when the job is posted. Without changes to that logic, the talented dorfs will almost always get the next job in a workshop taken by somebody else, unless the current "finished job. Wander away for 10 or so steps before taking a new one" behavior is changed so dorfs now either kick the unskilled out, or grab the next job immediately. Any comments on how this will work?

On the positive potential side, does need satisfaction factor into the job selection process, such that those who desperately want to craft something get a higher priority than the usual riffraff?

Without using masters and details, we've found that it does still sort of function - a cluster of dwarves that are already good at the job, from the varied migrant pool, tend to work on them, and get better at them.  There is a bit of delay in the job postings that gives the better dwarves a chance to appear - I haven't seen this 10-steps wander behavior screw things up, and it's confusing that they wouldn't be up for the next application since they are also free the next time applications are processed.  If that's a known bug, it hasn't impacted the general skill breakdowns much, but I'd still probably wanna take a look at it.

At the same time, assigning workshop masters is really easy and is what we intend for jobs you want done well.

What is the biggest embark size that you expect to be stable by the 1.0.0 release? Do you think it might be greater than the current maximum possible of 16x16?

PatrikLundell: http://www.bay12forums.com/smf/index.php?topic=169696.msg8305013#msg8305013

Of course, it currently gives you a warning for 16x16 and that's not guaranteed to be stable.  Even ones smaller than that give you the warning.  Part of the idea of the map rewrite is to handle altitudes a little better, and that'll allow us to do the multi-camera battlefield thing, so you can watch a battle in some other part of the map while your fortress is going, even on a large battlefield (because it doesn't load the 100+ z layers below generally.  There are a lot of wrinkles there though, and it remains to be seen how fast it'll actually be, and which sizes then are allowed by default.  We're not precisely aiming for larger and larger forts though.

there are goals other than "immortality" that are valid for secrets. Given that they currently do nothing, unlike the Immortality goal, are there any plans to make these functional after/during the Myth and Magic "arc", or are they sort of placeholders for something bigger? Or maybe placeholders for a a kind of "primitive" magic system?

I don't want to build any unrealistic expectations for myself but the hype train is real.

FantasticDorf: http://www.bay12forums.com/smf/index.php?topic=169696.msg8305040#msg8305040

When you say "after/during" the Myth and Magic stuff, during that arc we're hoping for way more than "primitive" magic systems - we're going for full procedural robust magic systems.  The "goal" system will hopefully be more integrated with regular personality stuff during this.

What's the reason for having APPLY_CURRENT_CREATURE_VARIATION? I don't see why the likes of CV_REMOVE_TAG, when defined directly in a creature, couldn't just be applied immediately, and then the same for any subsequent CV_ tokens like CV_ADD_TAG and CV_CONVERT_TAG.

For example, penguin men start out like this:

Code: [Select]

[CREATURE:PENGUIN MAN]
[COPY_TAGS_FROM:BIRD_PENGUIN]
[APPLY_CREATURE_VARIATION:ANIMAL_PERSON]
[GO_TO_TAG:BODY]
[CV_REMOVE_TAG:BODY]
[CV_ADD_TAG:BODY:HUMANOID_NECK:2EYES:2LUNGS:HEART:GUTS:ORGANS:GIZZARD:HUMANOID_JOINTS:THROAT:NECK:SPINE:BRAIN:SKULL:4FINGERS:4TOES:BEAK:TONGUE:RIBCAGE]
[APPLY_CURRENT_CREATURE_VARIATION]

Why couldn't [CV_REMOVE_TAG:BODY] and the [CV_ADD_TAG:BODY:...] just be applied immediately one after the other automatically? As far as I can tell, [APPLY_CREATURE_VARIATION:ANIMAL_PERSON] is applied instantly, it's just the manual "inside the creature definition" creature variation tokens that need APPLY_CURRENT_CREATURE_VARIATION.

Also, why does CV_ADD_TAG need to exist anyway? If BODY has already been removed, surely it could just be re-added directly as [BODY:...], and the same for every other possible tag that could be added?

voliol: http://www.bay12forums.com/smf/index.php?topic=169696.msg8306138#msg8306138

I'd have to refer to the modders as to if this is useful or if it's redundant.  It has probably been around a decade or more since I added it, and I haven't looked at it since, so I just don't remember and it would take long time to get myself back up to speed as to how the 'cursor position' works and all that.  Certainly I didn't do things in the most efficient way; if there was a reason at the time things were that way that no longer applies, I don't recall, but that's also possible.

1. Are there any plans for larger cities than currently exist? Something like huge metropoli akin to Rome or Constantinople for example, taking up multiple world tiles.
2. Moving fortresses/fortress parts have been mentioned, but are there any plans to eventually add mechanisms for things like airships in addition to sea vessels and the like?
3. I've heard that there are plans for ruined civilizations and such. Are there plans for modders to be able to make ruins of their own, with custom loot/squatters/monsters?

voliol: http://www.bay12forums.com/smf/index.php?topic=169696.msg8306521#msg8306521

1. We've considered it - there'd need to be a little sewing and a little rethinking, but even the current system before the bigger map rewrite could be made to support it.  Not that we'll see it before then!  And once we get there, we're hoping to have world-sized or even infinite city-planes and that sort of thing, though the larger problem there becomes managing inhabitants (which is something we already do poorly enough, since histfigs are the limiting resource.)

2. It'll all be the same once stuff can move, pretty much.  I haven't thought about airships specifically, though.  But flying fortresses are likely.

3. Hmm, I'm not sure what this is referring to precisely.  The plans I can think of currently for ruins are just to add more mechanisms for live civilizations to become not so live.  And that would all be up to the sim - and of course modded civs could also die in whichever ways make sense for them.

Feels odd, but the topic for the addition of a hospital occupation has put me and probably a few other people in a wierd spot, because it makes anything said flex the thin veil of suggestionhood if its all very prematurely formed at this stage. Ill stick my neck out, assuming we don't see a steam-post before the end of the month.

    1) Ill quickly say that anecdotally i've set up small taverns to ensure visitation inside hospitals by friends and loved ones, and keeping the alcohol tap flowing for the benefit of longer term residents. Since this would be awkward to overlap with two occupation zones, will there be any degree of revision change of the hospital's "rules" if nessescary to discriminate between public and private hospitals?

    2) Is there a expected "flow", prioritizing fortress mode outwards into adventure and worldgen in mind or will each area for medicine affected by this occupation zone and permancy change be respectfully stalled to their appropriate arcs after the big wait?

Though i wonder how many visitors would willingly let your dwarves do surgery on them if they had heard about your inhouse hospital. Its not like they can pay you for your trouble, so im not sure what a player could even possibly get out of it besides their imparted gratitude and that character lives to survive another day. A good deed in high places makes all the difference i suppose.

1) So you're saying before you did this with overlapping hospital and meeting areas?  We haven't really changed how that part works, so you could still do it that way.  You can also put your hospital beds in a meeting area, which makes for a very lively and probably unsanitary hospital, ha ha.  But really it seems the key here, which we don't have time for now, is to just to proper visitation - the whole make-hospitals-a-location thing has made us want to make DF into a hospital sim, but it's probably a good time to not do that.

2) There's a lot crammed in between now and the big wait, and the steam release is only going to cram more in there.  But there is now an anticipation of wg/adv hospitals as well.  I'm not sure when it'll happen.  Not the biggest priority of course, but the game is now out of parity on that location more than the previous ones (not that guildhalls/guilds got much attention.)

If hospitals are now a location, does that mean that we will see hospitals in different parts of the world both in adventure mode and in world gen? Or will we have to wait until later for that?

The infrastructure is all there now, but it'll have to wait!  We're pretty much trying to point straight toward the release now, and there's a lot left to do.

My biggest concern with the new labour system is that it addresses the opposite of my own concerns. The new labour system allows you to easily prevent e.g. non-stonecrafters from doing stonecrafting jobs; I don't mind if low-skill stonecrafters do stonecrafting, but what I really want is for miners to only mine and not do any other jobs.

With the new labour system, is there an easier way to prevent e.g. miners from doing non-mining jobs, than from making every work detail selected-dwarfs-only, and then assigning every dwarf that isn't a miner to every not-mining work detail?

You can set your miners and other work detail people to specialize just like you can with the workshop masters.  Then your miners will only mine and not haul or do any other jobs.  So currently it's just one click per miner, and they are all arranged nicely at the top of the work detail when they are selected now.  You can make specialized haulers the same way, and it also works for doctors and other location occupations you might want to keep on duty.

You can also use custom work details to turn off specific labors entirely, by making e.g. a "stone hauling" work detail and then setting it to "nobody does this", if you want stone to remain in place after you mine without having to fiddle much.

How does CV_CONVERT_TAG work with target selection? That is, take this example:

Code: [Select]

[CV_CONVERT_TAG]
[CVCT_MASTER:BODY]
[CVCT_TARGET:BASIC_2PARTBODY:BASIC_HEAD_NECK]
[CVCT_REPLACEMENT:HUMANOID_NECK:3FINGERS]

In actuality `BASIC_2PARTBODY:BASIC_HEAD_NECK` are the very first 2 arguments in BODY everywhere this pair is used, and they are beside each other, but in principle, do they have to be directly beside each other to be detected and replaced? Like, would this be detected here?:

Code: [Select]

[BODY:BASIC_2PARTBODY:FRONT_BODY_FLIPPERS:BASIC_HEAD_NECK]

Or does it need to be immediately consecutive?

voliol: http://www.bay12forums.com/smf/index.php?topic=169696.msg8307894#msg8307894
Mr_Crabman (op): http://www.bay12forums.com/smf/index.php?topic=169696.msg8307923#msg8307923

hi toady! bit of an unusual question today - we've been watching/reading this talk [from the 2020 virtual Roguelike Celebration] on using hash functions instead of using rand() to randomly decide things, so that rng calls won't be affected by earlier calls. it's very interesting.

does dwarf fortress do anything like this already, or have you considered the technique? we recall there being something in one of the update posts a while back that sounded you were suffering from this problem.

Mobbstar: http://www.bay12forums.com/smf/index.php?topic=169696.msg8308505#msg8308505
Su: http://www.bay12forums.com/smf/index.php?topic=169696.msg8308602#msg8308602
DwarfStar: http://www.bay12forums.com/smf/index.php?topic=169696.msg8308609#msg8308609

I'm not sure which update post you were talking about, but it is a common problem!  I was at that Roguelike talk (well, virtually) and almost immediately tried out the SplitMix stuff.  And it's fast and fun!  I haven't used the more advanced place-keeping/skipping/parallel abilities of it, but I've used it for our procedural furniture variations and some map variation stuff, and it works really well where our regular twister would be way slower to seed and where I was having trouble seeding more simple RNGs without glaring artifacts popping up.  We do use multiple seeds etc. in worldgen with the twister, and put the seeds on a stack sometimes to keep things consistent, and that makes debugging messy sometimes when there are bugs in worldgen consistency.  I haven't revisited any of that yet, but there are doubtless lots of places where switching to the new one'll make it cleaner and less prone to errors.

Are you planning to upgrade DF to SDL 2 (or has it happened already)?

I haven't done it yet, and things are working well enough so far that it hasn't seemed pressing.  It's something I'd like to try, because it might speed things up or give me more powers, but if it throws a month-long wrench into the process, right now it doesn't look like I should do that, and I should leave it for a time when I'm not under time pressure (whatever that means, but this is not it.)  As more testing happens on more setups, when we are closer to the finish line, that might change.

What changes if any do you have planned for the likes of combat report logs, and the "block of text describing this creature's current injuries"? For the Steam release that is.

For the dragon/constrained randomizer, do you have any idea at this stage how descriptions would work? Currently descriptions for most creatures are manually entered into the raws, and for procgen creatures follow a hardcoded format for certain bodily traits and abilities.

But if dragon variations are to be exposed to the raws, presumably just 1 description couldn't cover all possible dragons without being extremely vague, but hardcoded means of generating descriptions seem a bit tricky to pull off in terms of how to neatly describe important features without describing too much, and in a bland manner (ie being too "anatomical/clinical" or repetitive, and lacking in flavor like many of the manual descriptions currently have), especially if the constrained randomizing functionality isn't tied to dragons/is expanded to other creatures.

To an extent this also applies to other procgen stuff planned to be exposed to/manipulable in the raws at a later point in some way, and because of how after myth and magic, a lot more creatures in a world may potentially be randomly generated.

EDIT: Same sort of question also goes for prefstrings.

Also, why is it that only integers seem to be used in the raws for everything? I don't think any numbers use decimal points as far as I can tell.

PatrikLundell: http://www.bay12forums.com/smf/index.php?topic=169696.msg8309829#msg8309829

I'm not sure combat reports are going to change.  They need to be integrated with the announcement icons that roll up the left side, and we left some space for that.

Procedural text is always difficult, especially getting it to sound varied and natural while still being accurate.  There are various tools and so forth, and other projects people have done (e.g. tracery/markov stuff/GPT# etc.) and I'm not sure which direction we'll end up going.  It's not an easy problem and our initial descriptions will be lacking I'm sure.

Yeah, as PatrikLundell mentioned, there are e.g. general speed concerns - I got to prefer fixed-point math when doing triangle u/v coords before e.g. directx existed, on some ancient pre-armok projects, and lean even more that way now.  On top of speed trouble, doing file i/o with floating points is also a pain compared to integers.  I just try to never use them outside of some necessary local calculations that have no chance of ever being serialized, mainly when I can't escape using e.g. sin/cos or I need a real sqrt and the square won't suffice (e.g. for distance comparisons, comparing dx*dx+dy*dy is faster than also taking sqrt and comparing after.)  Raws aren't binary serialization, and I can understand for appearances sake why doing e.g. densities as g/cm^3 would be preferable.  But generally I just push up to mg or cc or whatever is close enough to get rid of the '.', so it matches the internal data structures and so I don't have to parse the '.'.  And it's good for the raws to visually match the data - here in FotF, we just had that issue with the /10 volume conversion causing some confusion, and it would probably be better to just use those unusual units out in the raws as well rather than converting silently.

What's the purpose of using GO_TO_START in creature variants? For example:

Code: [Select]

[CREATURE:GIANT_TOAD]
[COPY_TAGS_FROM:TOAD]
[APPLY_CREATURE_VARIATION:GIANT]
[CV_REMOVE_TAG:CHANGE_BODY_SIZE_PERC]
[APPLY_CURRENT_CREATURE_VARIATION]
[GO_TO_END]
[SELECT_CASTE:ALL]
[CHANGE_BODY_SIZE_PERC:100700]
[GO_TO_START]
[NAME:giant toad:giant toads:giant toad]
[CASTE_NAME:giant toad:giant toads:giant toad]
[DESCRIPTION:A huge monster in the shape of a toad.]
[POPULATION_NUMBER:10:20]
[CLUSTER_NUMBER:1:1]
[CREATURE_TILE:'T']
[COLOR:2:0:0]
[PET_EXOTIC]
[PETVALUE:500]
[MOUNT_EXOTIC]
[GO_TO_END]
[PREFSTRING:beauty]
[APPLY_CREATURE_VARIATION:STANDARD_WALK_CRAWL_GAITS:3512:2634:1756:878:4900:6900] 10 kph
[APPLY_CREATURE_VARIATION:STANDARD_CRAWLING_GAITS:9000:8900:8825:8775:9500:9900] 1 kph
[APPLY_CREATURE_VARIATION:STANDARD_SWIMMING_GAITS:9000:8900:8825:8775:9500:9900] 1 kph

Here you SELECT_CASTE:ALL, and then add one token, and then go back to the stat to add a bunch more tokens, and back to the end again.

But why is this? To my knowledge, the very start of the object is treated as the ALL caste already, so it doesn't seem like it makes a functional difference whether these tokens are at the start of the object, or at the end inside SELECT_CASTE:ALL, and it doesn't seem to serve a clear stylistic purpose either; my only guess is that maybe you look at the end resulting raw object after these commands have been processed, and so you get to see those tokens actually look at the top like with all "normal" creatures.

It was mostly an aesthetic thing, probably.  The name etc. tags are at the top, so I put them at the top.  It's also probably good to keep positions as consistent as possible for any future alterations as well, though I probably haven't done an excellent job of that and the need hasn't yet come up after many years.

[clinodev]

Thanks as always for the replies!

I'm sure I speak for many when I say I'm looking forward to the community conversation moving forward from concern about labor assignment to terror about the military system!

[Toady One]

Ah, and missed the part of Mr_Crabman's question about the injury text (I just read it as a combat report question, and those aren't going to change much.)  That paragraph in v-p-z or wherever is outmoded and will be replaced by the health tab on the unit sheet, and likely in the creature list.  I'm not sure which direction it'll go yet - we need the text descriptions of wounds some place, both because they are excellent atmosphere and for the practical reasons, but we also need a quick health overview, which might be sortable in the creatures list and be by hoverable icon, the same way you can sort stress there now.

[Immortal-D]

Have you ever considered changing the lycanthrope 'Wereass' to 'Weredonkey'?  I know it's technically correct, but thinking ahead to the Steam release, might be best to just nip that in the bud, as it were.

[clinodev]

Have you ever considered changing the lycanthrope 'Wereass' to 'Weredonkey'?  I know it's technically correct, but thinking ahead to the Steam release, might be best to just nip that in the bud, as it were.

Even worse, "asses" only exist as procedural elements, for were creatures and forgotten beasts. "Wild Donkey" has become acceptable in English for Equus africanus asinus. From private correspondence I know it's an historical accident that domestic donkeys have no wild version in the game, possibly over confussion about whether "wild donkey" was acceptable, and I'm assured it's not an intentional joke.

This is a personal pet peeve of mine, as it happens. I've removed countless "Ha ha wereass! Get it? A! S! S! Like a butt!" posts on the subreddit.

[Silverwing235]

Have you ever considered changing the lycanthrope 'Wereass' to 'Weredonkey'?  I know it's technically correct, but thinking ahead to the Steam release, might be best to just nip that in the bud, as it were.

A side note to this, but it appears demons/forgotten beasts made of vomit can also come about - definitely a bit overly 'gross-out humor' for the tone, IMO?