Bay 12 Games Forum

I know the army arc has plans for players to be able to send out attack parties, it only makes sense that the trading arc will include being able to send out trading parties.

We need production mandates from the Mountainhomes that ratchet up over time.

We need year round trading.

We need a company store/market and we need dwarves to use some kind of wage to buy stuff from it.

We need support for projects like Inns and Taverns that use up furniture.

We need lots of things to actually have a use, like mugs, instruments, and so on; so that they'll be handled and wear out or break.

We need trading to take the number of objects into account so spamming rock mugs or metal disks doesn't work anymore and forces the player to build a broader economy.

We need wild animals eating crops and herds, and bad weather conditions like frost, floods, and so on that reduce crop and herd production.

Ultimately, we really, really need a farming overhaul; to force players to choose between trying to farm (and protect) most or all of the arable land on their map, or trading for huge amounts of food to support the burgeoning population. The fact that one tiny plot can feed an entire fortress is the biggest economic issue in the entire game.

Probably less of the valuable metals would be good as well. Take gold, for instance:
"[Gold] ore grades in underground or hard rock mines are usually at least 3 mg/kg (3 ppm). Because ore grades of 30 mg/kg (30 ppm) are usually needed before gold is visible to the naked eye, in most gold mines the gold is invisible".
It would be a positive change (economically) if extracting gold from a unit of gold ore sometimes resulted in a nugget, and that it took quite a few nuggets to make a bar (say 10), and it took a couple bars to produce something small like a sword blade or the head of a war hammer.

But how would it know to attempt to combine? A simple swap would involve only two tiles, the 7/7 and the 1/7. That's simple. Checking that there are additional 1/7 tiles around so that the liquids could balance out at 4/7+3/7+2/7 would not be as trivial.

Probably should have gone into a bit more depth on that, I figured the best way is to only look at the tile directly away from the one encountered that contains a different type, and if it can't combine, just do the swap as normal. This would allow for non-full tiles to wander around for a time, which again would definitely look strange, but eventually they'd combine with the others of their kind.

And we can estimate how hard it is to code something. We don't know about the state of Toady's code, but we can estimate how hard it would be to code from scratch. Also, we know how water currently behaves. It's unlikely Toady coded it is a strange way, so we can guess at the current code pretty well too.

We have a vague idea, but there are two unknowns that make it difficult:
1. We don't know what data structures he's using and how he's using them, and just how much of the surrounding code is tied to the assumption that the liquid contents of a tile can be treated as a single number.
2. We haven't come up with the general purpose algorithm and analyzed the edge cases of the primary system everyone is in favor of.

In my opinion, this makes it more of a "gut feeling" than a real estimate, but gut feelings are valid too. I happen to agree with your assessment in this case, but one thing I wanted to make clear is that we are making assumptions, and we should be clear about what those assumptions are.

Re: layering
I agree that that's the right way to do it, but that does add it's own mixing challenges. For instance: if shallow water and oil mix then the two can just spread out independently. However, if you have two adjacent tiles with no air gap you would still want the oil to spread out.

The biggest challenge I can think of with multiple liquids per tile is making the exchange process take place when multiple liquids are present without hammering the CPU.
The most obvious approach is to search each element of the entire liquid storage structure of tile 1 against each element of tile 2, complete a reaction if reacting elements are found in that search, then if not and if there is sufficient difference, exchange this liquid for a different liquid or liquids which would have to somehow have been chosen along the way. (That last part would be quite tricky)

Another option that came to mind is to take all of the array elements from both and put them into a single structure that contains all possible types, compute reactions, and then split it back up and assign the results back to both tiles.

Given how pressure works in DF, it wouldn't be easy to make water push other liquids. So you may as well do it right and layer them.

The effect of pushing occurs as a natural outcome of the scenario I described. Nothing special has to occur other than the one look behind/attempt to combine step.

I'm not so sure that layering alleviates all the problems of pressure calculations in the presence of multiple liquids. You'd at least have to calculate the sum of the total depth stored in the new data structure prior to making every pressure calculation.

Its really hard to say just how painful each of these options would be without seeing the details of the code; and we know that isn't going to happen.

That said, I have to agree that the biggest issue with tile swapping is the one you mentioned a couple of posts ago, where depth doesn't match and tiles can't be combined; like a 1/7 oil tile moving around a reservoir full of 7/7 water. It would just look strange.

The more I think about option #4, "swap tiles when no reaction is defined", the more positives I see for it.

When tiles full of different liquids are on multiple z levels, the denser of the two could be swapped to the bottom (again as the default, when no reaction is defined).

It also allows reactions to continue to take place in the presence of inert substances.

Here's an example of Ammonia, Vinegar, and Water (and Foam representing ammonium acetate).

Quote from: harborpirate on November 21, 2011, 03:13:48 pm

Some possibilities:
1. The two fluids block each other from flowing as if they had run into a solid.
2. DF is updated to track multiple liquids in a given tile and the tile gets about half of each. (3 of one and 4 of the other).
3. Both tiles form a default compound, like "sludge" or somesuch.

And those would have to be coded in the RAWs as well.  Very very VERY (if any) few liquid interactions in the real world do 1 (form a vertical boundary).  Most will either mix (3ish*) or layer on top of each other based on density (2).  2, however, is very easy to code, as it can be implied based on the material definitions.  3is is harder, but possible as it depends on what type of material each is (a water-soluable liquid won't mix with a lipid-soluable liquid, even if both are the same density).

It's the acid/base, water/magma type reactions that are extremely difficult to code as every liquid likely interacts in some way to large numbers of every other liquid.  I.e. vinegar and ammonia would both (in large quantities) turn magma into obsidian.

The trickies reactions of all are the ones that involve three or more liquids.  I.e. one is a catalyst for a chemical reaction of the other two (I do not know of any that exist in pure liquid states).

*By which I mean two liquids mixing homogeonously into a "new" liquid.  I.e. water and milk.

Keep in mind that I'm only talking about the default reaction, when a reaction is not explicitly defined in the RAWs. The point is to support lots of liquids without having to define hundreds or thousands of interactions in the RAWs.

There is a fourth option for default reaction that I didn't think of until later:
Swap these two tiles.
If two liquid types with no defined reaction to each other interacted, you'd end up with a pool of "mixed" liquids, but each individual tile would only contain a single type. This would also make the interaction of 2 or more liquids a snap (it would just work automatically), and it would simulate pollution pretty well.

Example (Oil=o, Water=w)

I doubt #2 will be easy to code. The game is not set up to handle multiple liquids in a single tile - the game would likely need a new data structure and it could get ugly (especially in regards to performance) when more than just 2 liquids interact. Could be a real CPU hog.

As for #3, the "sludge option", my assumption was that if it was the default to create sludge, most things interacting with sludge would just form more sludge. So you don't have to worry about whether things without defined reactions mix, because they'll just turn into sludge. You could always define how some material reacts with sludge, which would apply no matter what previous interaction created the sludge in the first place. Not very realistic, but easy.

Let me give a little more detail about why I'm advocating the options that I am: I'd like to see other liquids get into the game soon. Pie-in-the-sky perfection takes forever. If we can get something interesting and useful that requires 80% less effort, I'd like to see Toady go for that.

To be honest I think the default of "swap tiles" would be the best default option. You could end up with lakes that were part oil, part water, part whatever; all without doing heavy modifications to the game. Meanwhile, modders could go crazy defining every possible interaction to satisfy the desire for more detail.

Its not quite as bad as an exponential problem to define reactions in the raws for two reasons:
1. If no reaction is defined then the two liquids just fail to mix (no reaction).
2. You could define a default reaction like for say magma where it just always has a certain interaction if one is not defined (in this case probably create stone type obsidian).

I also agree that interactions as a separate raws entry is a good idea, because it prevents duplication.