Print

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

[PatrikLundell]

:
I made those relationship checks 10x as fast by just introducing a little caching, turning the checks from O(logn) to amortized O(1)--multithreading is an O(1) speedup, so improvements in algorithms will win just about 100% of the time, and this is a great example of that

Expressing strong support for Putnam here: When looking to make things faster, first try to improve/replace the algorithms, then retry to improve the algorithms, then again try to improve the algorithms. After that you may start to look for optimizations (and while doing that, keep an eye open for algorithm improvements).
It's also the case that an algorithm that was good once upon a time may become less suited to its ever expanding set of tasks as years go by, so a need to replace an algorithm isn't automatically a sign of a bad design.

[A_Curious_Cat]

This may have been asked before but currently, Legendsviewer doesn't work with the steam version as some of the data required can't be exported. Are there plans to bring back the required exporting options?

Lime-Green your text if you want The Toad to see it!

[Toady One]

Are there any plans to put something in the highlighted box when you're selecting things for trade in classic graphics? A colored 'x' or something -- as far as I can see it just kind of highlights itself a slightly lighter gray which can be a bit tricky to see at a glance

Are there plans to re-implement an option for varied tiles in classic graphics? When I played before I would always immediately turned varied tiles off for easier readability

SeeSchloss: http://www.bay12forums.com/smf/index.php?topic=169696.msg8482466#msg8482466

Yeah, some of the choices are subpar for sure.  You can edit them in the txt files but it'd be good to get the defaults improved.

Huh, only the loading part in the d_init txt needs to be added back.  The rest looks like it is still there.  I'm all for it.

What is the timeline for fixing the [CONDITION_NOT_DYED] and [CONDITION_DYED:COLOR] tags?
I really want to make a mod which adds new dyes and accurately displays clothing colors instead of having profession colors. It would be cool if there was tags to detect if a body part is missing, or if a weapon is in multigrasp, or if a particular item is hauled instead of only a tag for number of items hauled. Currently I think artifact weapons and armor don't display on your dwarves in vanilla. I fixed this in my mod by removing the the [CONDITION_CRAFTED_ARTIFACT] tag and layer grouping some stuff. Unfortunately the game doesn't properly detect the material of a crafted artifact so it can only display a generic artifact instead of a specific one of a particular material. Last I checked the creatures_graphics layered file also looks for black bronze equipment instead of bismuth bronze. That would be an easy graphics fix since it only requires the replace command.

Eric Blank: http://www.bay12forums.com/smf/index.php?topic=169696.msg8482767#msg8482767

Yeah, we were planning to have that work at release, but didn't get an option in for the display in fort mode.  Eric Blank's right that'll it'll probably come up with the adv stuff.  That should also make the fort mode option possible.

1- About myth&magic update, myth generator will create random people and creatures but how will you make their designs in game if they are completely random? I remember I saw something like ''lizard with exposed brain'' this could be easy since we have lizard design but how will you do every random creatures' design?

2- I don't know if random quests are possible but If it's not, will we see more complicated (or detailed) quests in adventure mode near future? Like maybe this example not that complicated but, you see a poor village and ask what happened, they say bandits often raid here but they don't know where they come so ask you if you spend some time here wait for bandits and offer you a house (you can reject and pay for it) and you wait some time and realize they don't come here so ask villagers about their predictions where bandits are etc.

3- Will our adventurer and others do their jobs (miner, farmer), earn money etc. before big wait?

4-I remember I saw one of the aims of new steam version adventure mode was adding new things for our adventurer and making the mode more enjoyable. So, will we see villain update too with adventure mode release or will we wait a bit longer for it?

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

1. PatrikLundell covered this.  Forgotten beasts already have various groupings and pathways along these lines, and we'd like to both expand those systems and get them out into editable files to the extent possible.

2. Making the world more dynamic has been an ongoing project, and the villain stuff we delayed just before the premium work is the next step in improving both adv and fort mode in this way.  It hasn't come together as quickly as a normal RPG, but it has changed a lot and will continue to do so.

3. I doubt it.  Making that work properly requires a whole economy which doesn't exist.

4. It's not clear, but either way those are the two things we're working on next for adventure mode (UI update -> villains stuff -> army stuff, in some form.)

Is the rate at which items in a refuse stockpile decay related to the item’s size?  I.e. do larger items take longer to decay?

Looks like it just advances it one stage per season.

1. Have you considered consulting UX professional at any point? Caves of Qud has their entire UI re-conceptualised by an artist and they are implementing that step by step. Adventurer, being very interface-heavy, could benefit from this probably?

2. What are the plans ahead art-wise? Some animations perhaps?

3. Most games have audial feedback on UI interaction(think click sound on buttons). Would it be realistic to implement that in DF?

4. Have you ever played Gnomoria/Ingnomia?

1. We were, but our original plan fell through.  Not sure what's going to happen now.

2. We're going to focus on what we need for adventure mode, mostly.  That'll mean the missing travel stuff and missing town bits, and UI elements as the come up.  We're experimenting with some other bits but I don't want to mention it yet if it doesn't work out.

3. Yeah!  We have a few audio engineers working now.  The initial focus is adv mode, but we've discussed this as well.

4. Nope.

With the multi-threaded improvements to the line-of-sight code going live, is there any plans to look into threading other parts of the code? Pathing relationship checks during watching performances and stone temp come to mind for me.

PatrikLundell: http://www.bay12forums.com/smf/index.php?topic=169696.msg8484626#msg8484626
lethosor: http://www.bay12forums.com/smf/index.php?topic=169696.msg8484702#msg8484702
oninoshiko (op): http://www.bay12forums.com/smf/index.php?topic=169696.msg8485404#msg8485404
Putnam: http://www.bay12forums.com/smf/index.php?topic=169696.msg8486050#msg8486050
PatrikLundell: http://www.bay12forums.com/smf/index.php?topic=169696.msg8486109#msg8486109

1. As I recall from the myth demos, deities and primordial forces are given spheres by looking at what objects with obvious spheres (like the sky, elemental planes, certain creatures, divine law, etc.) they created during mythgen. So if a deity created the ocean, they might become associated with OCEAN or maybe WATER. However, some spheres would seem required for a more cohesive myth narrative. Like the TRICKERY of a trickster god, or a deity of LAW not running around wrecking things. Especially if mythgen doesn't cease completely at the point where historygen starts (or the player is able to enter the world), but continues to run in parallel to history (albeit slow). At what point would these sphere-connections be put into place? At the end of (normal?) mythgen where historygen starts? When something with an obvious sphere connection is created?

2. Many cultures have considered mundane animals to have magical properties, such as scarabs or black cats. Can we expect any of this with mythgen, or will it rather be the separate fantastic beasts, like the unicorn, who are granted powers?

3. Any thoughs on sacred animals/plants and mythgen?

dikbutdagrate: http://www.bay12forums.com/smf/index.php?topic=169696.msg8484922#msg8484922

1. Yeah, we've been working with associations that come from actions, and that can still work.  It's also not a problem at all to just have some asserted associations which will then become clear as actions happen.  It's not preferable since it feels more forced, but it can be fine I think.  But yeah, generally connections would be placed the first time something related to them happens so that the character etc. acts consistently from that point forward, or beforehand.  And there's no reason why it can't happen historically as well, if the critter isn't immutable in some fundamental way, though it would usually be a big deal.

2. We've thought about it vaguely a bit, like how to place a whole e.g. alchemy system on top the existing mundane-or-not raws procedurally.  There are plenty of existing tags (colors, large predator, etc.) that the game can use, but there'd still be more structure needed to stop it from feeling really mushy and random, but some of it should feel kinda random/historical/etc./etc.  Seems feasible though, with any target object.

3. Cultural links generally are sort of wanting to happen and also a bit worrisome without the additional frameworks from the entity rewrite, so we'll see what we get.  Obviously we're needing various magical/religious subgroups and beliefs etc. so I guess we'll see how far we can push without breaking things.

As multithreading appeared to be quite possible and implementable instead of being "too hard", may be another long wanted feature is also not so impossible? I mean multiplayer. There are a lot of turn based games with simultaneous MP like Crusader Kings or Rimworld which is basically DF for casuals, it has a mod that adds pretty decent multiplayer experience without issues.

lethosor: http://www.bay12forums.com/smf/index.php?topic=169696.msg8484595#msg8484595

Multiplayer was never impossible.  I just don't have the skills for it, and it's not my kind of game so I don't want to design and maintain it.  A mod would make more sense -- if a mod springs up or something else comes up, and it doesn't take much support from my end, that's cool.

Given that we are about to switch to sdl2 and at the same time sdl2 is going into maintenance mode, are there any wishlist items that you want to see from sdl3? And on the same line of questions, can we move to sdl3 more quickly once it is released?

lethosor: http://www.bay12forums.com/smf/index.php?topic=169696.msg8484985#msg8484985
Putnam: http://www.bay12forums.com/smf/index.php?topic=169696.msg8486050#msg8486050

Ha ha, I don't even know what sdl2 is capable of.  I'm sure we're not using most of it.  So I can't make a wishlist for 3.  We'll probably be on 3 before 10 years pass or however long it was, but unless it makes the base game a lot faster I'm not sure there's a reason to push for it rapidly.

Are there any scripts or features in DFHack that you think would be good candidates to integrate into DF itself, should time allow?

I'm not familiar enough with them.  We've done similar things enough times that I assume there are several though.

With all the changes to UI, has it made it technically easier to translate Dwarf Fortress to other languages? Are we likely to see localisation of Dwarf Fortress, perhaps by KitFox or another third party? Is it technically feasible to abstract the interface to the point where fans could do the translations themselves? If not yet, is it possible or likely, perhaps something Putnam could take the lead on?

A_Curious_Cat: http://www.bay12forums.com/smf/index.php?topic=169696.msg8484968#msg8484968

I don't think it's any easier, aside maybe for extra glyphs being slightly more reachable maybe.  There's still all the procedural text sitting in the way.  We've vaguely started to some people about some things, but the constructed elements are a high hurdle.  I'm not sure how well partial translations are received, and we have to be careful about that.

With the Linux port compiling now, will we get an aarch64 build for Linux, or just aarch64 for macOS and x86_64 for Linux?

I don't know what's possible at this point with the process we're planning to use.

Is there a roadmap being followed?
or
What would be the best way to keep track of the development of Dwarf Fortress?

Shonai_Dweller: http://www.bay12forums.com/smf/index.php?topic=169696.msg8485812#msg8485812
Egan_BW: http://www.bay12forums.com/smf/index.php?topic=169696.msg8485826#msg8485826

The Premium stuff delayed the stuff on the dev page linked in the reply, but that's still the plan.  We aren't through updating the game though, still need to do adv mode, finish legends mode, ports, keyboard stuff, etc., so it's not clear when we'll be back to the dev page.

This may have been asked before but currently, Legendsviewer doesn't work with the steam version as some of the data required can't be exported. Are there plans to bring back the required exporting options?

We're planning to bring back everything that was in the pre-Steam version, yeah.

[A_Curious_Cat]

Thanks for the replies, Toady!

[mikekchar]

:
I made those relationship checks 10x as fast by just introducing a little caching, turning the checks from O(logn) to amortized O(1)--multithreading is an O(1) speedup, so improvements in algorithms will win just about 100% of the time, and this is a great example of that

Expressing strong support for Putnam here: When looking to make things faster, first try to improve/replace the algorithms, then retry to improve the algorithms, then again try to improve the algorithms. After that you may start to look for optimizations (and while doing that, keep an eye open for algorithm improvements).
It's also the case that an algorithm that was good once upon a time may become less suited to its ever expanding set of tasks as years go by, so a need to replace an algorithm isn't automatically a sign of a bad design.

Another way to think about this:

Saying that the game is slow because it is single threaded is similar to saying that I'm not rich because I'm only working 1 job.  Working 2 jobs doesn't guarantee that I will double my salary.  It's often easier to negotiate 1 high salary rather than 2.  Worse, even if I did double my salary, it wouldn't be enough to make me rich.  Finally, the nail in the coffin is that by working 2 jobs, I put each at risk because coordinating 2 full time jobs during the day is actually very difficult.  The way to get rich is by concentrating on getting rich, not by concentrating on how many jobs you are working.

While I'm here, I want to put in a brief pug for SDL3.  I think Putnam was earlier expressing some support for SDL3 sooner rather than later and I think that's the right idea (apologies if I'm putting words in your mouth Putnam).  It doesn't have to give you a lot of value.  The reason for doing it as early as possible is that there will be less changes made earlier in the development stream.  The earlier to upgrade, the easier it is to do.  When working on a long term project, understanding long term efficiencies is *very* important.    Those little cleanup chores can easily suck up most of your time if you let them.

It's a bit like doing your dishes.  If you clean as you cook, each thing takes only about 5 seconds to clean.  If you leave it until after you eat your meal, it will take 1-2 minutes.  If you leave it until the end of the week, all your meals take 2-3 times as long to cook because you are constantly fighting for counter/sink space.  And then you have an extra 2 hours of really horrible cleaning of the kitchen.  I once saw an interview with the wife of a Michelin star chef.  She said her husband's food was OK, but for every day meals, she liked hers better.  However, she said that he did everything in a third of the time because he kept the kitchen immaculate.  This is also true of programming.

[Putnam]

Are there any scripts or features in DFHack that you think would be good candidates to integrate into DF itself, should time allow?

Right, I'm a bit more qualified to answer this: I personally love the planning mode a lot and consider it maybe the single biggest usability boost DFHack provides, but it's a bit of an undertaking and DFHack's version works, as of right now, which is obviously a cop-out.

The main thing I use from DFHack is the Lua console and gm-editor and such for debugging purposes, plus writing my own scripts for that stuff, which has helped a good deal--turns out unit allocation is a bit spotty right now, so there's a notable performance gain from reloading after every save, which is a bit annoying. That didn't show up in initial testing, but now I can see it pretty clearly. It's good stuff.

[voliol]

Thanks for the answers!

[Vanzetti]

People have noted that waves breaking on the shore, and the foam they spread around, currently look a lot less impressive in Graphics mode than in ASCII mode. Is there a plan to remedy this?

[Nihilich]

1) When you say that you plan for everything from the old version to be on steam, does that mean you plan to add the old intro movies back to the game? They're iconic and I love how they set the mood.

2) What is the nature of the code-sharing deal you worked out with the DF hack team? Are you taking precautions against potential copyright issues?

[Silverwing235]

People have noted that waves breaking on the shore, and the foam they spread around, currently look a lot less impressive in Graphics mode than in ASCII mode. Is there a plan to remedy this?

Not just their look - you were probably unaware that they don't actually function as waves, either?

[Vanzetti]

People have noted that waves breaking on the shore, and the foam they spread around, currently look a lot less impressive in Graphics mode than in ASCII mode. Is there a plan to remedy this?

Not just their look - you were probably unaware that they don't actually function as waves, either?

I'm talking only about the aesthetics in this case.

[clinodev]

2) What is the nature of the code-sharing deal you worked out with the DF hack team? Are you taking precautions against potential copyright issues?

I think the short answer here is that there's no code-sharing deal with the DFHack team.

For about a year now there's been a very small testing group that get an early release to bug test, and then what will be the public beta a couple days early. More recently, members of the DFHack team are in that testing group, so they can prepare for releases, and Tarn and Putnam are pretty accessible in that chat for specific issues that come up.

Nevertheless, they're almost entirely only getting a few days early access to public releases. I think it's underestimated in the community just how very good the core DFHack team is at putting things together from the same releases everyone else gets. Early access lets them release very close to the public release time.

Any access to actual code appears to be limited to occasional small snippets, but it having Putnam available (who's historically been active in DFHack) to explain this or that has probably helped a lot.

I'm not part of the DFHack team but I'm in testing, so it's possible I've messed up some small detail, but that's how it works in general.

[mikekchar]

I may very well be wrong, but I *think* the DFHack team has access to 1 header file that allows them to understand the memory layout of the game a little bit easier.  Or at least that's what I squirreled away in my brain from an offhand comment from Putnam on Reddit months and months ago.  So... take that with a massive grain of salt.  I could easily have gotten the wrong end of the stick.

[Nihilich]

2) What is the nature of the code-sharing deal you worked out with the DF hack team? Are you taking precautions against potential copyright issues?

I think the short answer here is that there's no code-sharing deal with the DFHack team.

For about a year now there's been a very small testing group that get an early release to bug test, and then what will be the public beta a couple days early. More recently, members of the DFHack team are in that testing group, so they can prepare for releases, and Tarn and Putnam are pretty accessible in that chat for specific issues that come up.

Nevertheless, they're almost entirely only getting a few days early access to public releases. I think it's underestimated in the community just how very good the core DFHack team is at putting things together from the same releases everyone else gets. Early access lets them release very close to the public release time.

Any access to actual code appears to be limited to occasional small snippets, but it having Putnam available (who's historically been active in DFHack) to explain this or that has probably helped a lot.

I'm not part of the DFHack team but I'm in testing, so it's possible I've messed up some small detail, but that's how it works in general.

Thanks for the reply, & i'm glad to hear that, though I was most worried about code flowing the other way - ever since that whole unfortunate meph thing ://

[lethosor]

Thanks for the reply, & i'm glad to hear that, though I was most worried about code flowing the other way - ever since that whole unfortunate meph thing ://

What "code flowing the other way" are you referring to? The DFHack code is less useful to DF than DF code is to DFHack, because we (DFHack) have historically used different names for the majority of things in DF. We are used to translating the names as needed if we ever get code snippets, but Bay12 is not so much. That said, our code is zlib-licensed, so it would be pretty hard for DF to create copyright issues by using any of our code.

If you're referring to PRs going into libgraphics, I'm not sure what the exact concerns are there, but PRs have not been made exclusively by DFHack contributors.