Print

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

[Fleeting Frames]

This is pretty....Large idea, but honestly I have no idea if it would decrease the computational cost (PS: note that entity in DF refers to civilizations).

One problem with multiple liquids is their interaction, though this "multiple things existing in same space" problem is already present in how tossing things into fluids doesn't do more than give mist Chemical reactions are pretty complex, and this is why we have, say, molten cinnabar and molten chalk exist as objects, possibly in same magma pool, and not reacting or pushing magma out of it. To define an interaction for each of N fluids with each other, you'd need N! definitions, after all.

Bit of critique, though:

The ideas of miniscule and shared volume seems like it interacts weirdly with splitting up a murky pool to drying point and shared volume. Miniscule by itself means that N tile murky pool split into 7N+1 tile murky pool would totally dry out the moment water spread out fully, while 7N would instantly dry at the slightest evaporation but would last for a while, while 7N-1 would last for twice as long on average....You get the idea.

Though DF drying is not how actual drying works, so can lay it there.

[Qyubey]

This is pretty....Large idea, but honestly I have no idea if it would decrease the computational cost (PS: note that entity in DF refers to civilizations).

One problem with multiple liquids is their interaction, though this "multiple things existing in same space" problem is already present in how tossing things into fluids doesn't do more than give mist Chemical reactions are pretty complex, and this is why we have, say, molten cinnabar and molten chalk exist as objects, possibly in same magma pool, and not reacting or pushing magma out of it. To define an interaction for each of N fluids with each other, you'd need N! definitions, after all.

Bit of critique, though:

The ideas of miniscule and shared volume seems like it interacts weirdly with splitting up a murky pool to drying point and shared volume. Miniscule by itself means that N tile murky pool split into 7N+1 tile murky pool would totally dry out the moment water spread out fully, while 7N would instantly dry at the slightest evaporation but would last for a while, while 7N-1 would last for twice as long on average....You get the idea.

Though DF drying is not how actual drying works, so can lay it there.

Oh okay, didn't really know what to call it. Mobs maybe? Creatures? You could use the same system as those, but just give it a Null tile to exist in so it can't be interacted with. Instead it just operates through functions relating to various tile IDs that it 'owns'. I don't think it would use up too many resources doing checks, but pathfinding might be an issue. However even then you wouldn't be dealing with the hundreds or thousands of individual tiles like you do now. It'd deal with one Body each that knows which tiles it should fill with its combined volume. I'd probably avoid doing it every frame as well.

Hence why I'm against liquids actually having any interactions beyond affecting the Volume value of a tile, with higher density fluids taking priority for adjusting it. I feel like that's simple enough to work.

Yeah, I eventually decided that method of dealing with miniscule values wouldn't be feasible - basically for the reasons you've listed. Still don't really have a fix there, beyond bumping the units for volume far beyond the 7 we currently have.

[90908]

I envy your motivation.

[Fleeting Frames]

No interactions, and higher density having priority could result in free-flowing magma compressing water pools into smaller full volumes, perhaps? An interesting way to create fishing areas. Nonetheless, I picked magma and water here for a reason.

[Qyubey]

I envy your motivation.

Thanks

No interactions, and higher density having priority could result in free-flowing magma compressing water pools into smaller full volumes, perhaps? An interesting way to create fishing areas. Nonetheless, I picked magma and water here for a reason.

Yeah, I see your point actually. Still, if we're just talking Water/Magma the interactions aren't super complex. Just make it so that any tile containing the two of them will delete all of its tile volume, unown the tile from all bodies, and create both a chunk of obsidian in the space and spawn steam above it.

So long as it doesn't create a new fluid body, you might be able to do this with other mixtures as well - like magma and oil producing an fire that deletes the oil, but leaves the magma.

[Fleeting Frames]

Just water/magma, yeah, but if you want to define N new fluids, you'll need to write (N+2)! -2 interactions. And since just about anything in the game has liquid form, you'll likely want to define some rules instead, lest you die of old age first.

But then you have liquid rock + water = rock wall VS salt + water = salty water....And then checking for all this.

I'd suggest changing the magma to cool down into obsidian on its own, with water acting as just heatsink - but this probably would have massive FPS impact for each liquid body. (non-residual magma pumpstacks tend to lose -1 FPS per level of pumpstack)

[Qyubey]

Just water/magma, yeah, but if you want to define N new fluids, you'll need to write (N+2)! -2 interactions. And since just about anything in the game has liquid form, you'll likely want to define some rules instead, lest you die of old age first.

But then you have liquid rock + water = rock wall VS salt + water = salty water....And then checking for all this.

I'd suggest changing the magma to cool down into obsidian on its own, with water acting as just heatsink - but this probably would have massive FPS impact for each liquid body. (non-residual magma pumpstacks tend to lose -1 FPS per level of pumpstack)

I'm saying that, by default, liquids will have null interactions. You actually have to ADD effects if you want them to occur. Two liquids touching each other will have null reaction with each other unless there is a rule designating it. I suppose that still does mean you have to run a check of "Liquid A=X, I know X interacts with Y, is Liquid B=Y?" and so forth, so it isn't perfect. May need to workshop it.

Woah, I am NOT going that advanced. Water sitting next to a block of salt would not become salty in this system; there's no check for that. Not realistic, I know, but far easier. Rocks currently don't interact with adjacent rocks, after all. I just want a good flow system.

Fufu~ You'll enjoy my next post I was writing... (although I don't really understand what you mean by non-residual magma pumpstacks)

[Qyubey]

This had made me think of something else regarding heat and pressure. Magma should logically produce heat that dissipates to other tiles, and heat in turn should affect pressure. You could probably use the same system that moves Pressure around to dissipate heat (in fact that'd probably work better).

Although if you wanted to, you certainly could extrapolate a system out that causes magma to revert to volcanic rock if it dips below a certain temperature. Meaning that if you dumped a tile of magma out in the open air, it'd dissipate all its heat and cool down to rock. Wouldn't actually be all that hard, I don't think - not if we're already running heat dissipation calculations for each tile. That'd require giving every tile on the map a temperature level, including rocks and open air so it can convex heat. That'd probably be a separate check entirely, but I doubt it'd be that intensive since it's just arithmetic - the CPU load would be dependent on how often the temperature cycle runs.

...So lets do that!

"Thermal conductivity (K) is a measure of the rate at which heat is conducted through a material."

"For a plate of thermal conductivity k, area A and thickness L, the conductance calculated is kA/L, measured in W·K−1 (equivalent to: W/°C)."

"Every body has its own capacity to conduct heat.  To determine how much it is we use this term. Thermal conductivity (λλ or k) is the capacity of the body to conduct or transmit heat.
Thermal Conductivity Formula

Where,
k is thermal conductivity in W/m K,
Q is amount of heat transfer through the material in J/S or W,
A is the area of the body in m2m2,
ΔTΔT is difference in temperature in K."

"The law of heat conduction, also known as Fourier's law, states that the time rate of heat transfer through a material is proportional to the negative gradient in the temperature and to the area, at right angles to that gradient, through which the heat flows. We can state this law in two equivalent forms: the integral form, in which we look at the amount of energy flowing into or out of a body as a whole, and the differential form, in which we look at the flow rates or fluxes of energy locally."

etc etc

Luckily since we're dealing with an abstraction we don't have to worry about these real laws - we just get to play with the end numbers. Each material should have a value for thermal conductivity, and whatever occupies a tile gives its value to the tile for conductive purposes. If two or more liquids ever share the same tile, it'll use the value of the least conductive.

Lucky for us, people have already found out some values for thermal conductivity:
http://physics.info/conduction/
https://en.wikipedia.org/wiki/List_of_thermal_conductivities

Lets grab a few that we want:
Air, Sea Level [0.025]
Water, Liquid [0.561]
Water, Ice [2.8]
Water, Vapor [0.016]

Based on these, Heat will flow pretty rapidly through water, but not through air, which should REALLY help with stopping magma from just solidifying instantly. Speaking of which, Magma is a little harder to parse, since real world magma's conductivity is affected by its content and depth. But we can just take a stab at it:
http://onlinelibrary.wiley.com/doi/10.1029/94JB01018/abstract

0.31? Okay, that makes it better than air but worse than water - perfekt. It means magma will take a long time to cool against air, but will cool rapidly against water.

However, one problem:
Granite [1.73]

I had anticipated stone to conduct very poorly but it actually seems like it does it well. It's not a huge problem; heat moving out from the magma still moves at a 0.31 rate.

Now, I'll run some tests to get this to work, but I'll need to modify how I distribute heat values. Might take a while; I'd just been using averages to calculate it right now, but now I'll have to calculate Heat Flux so I can multiply it by our thermal conductivity as a modifier. It'll be cool if that works.

Temperature puns~

EDIT: MUCH HARDER THAN EXPECTED. Shiiit...

[Fleeting Frames]

 Non-residual magma pumpstack: design where every z-level(alternating empty space and floor) is
######
#+%% .#
######

#= wall

Since magma is placed and removed each step, it gives empirically around -1 FPS per z-level of it.

Residual means that instead of pumping to 1 floor tiles it pumps to 3, so that some magma will remain behind and not force temperature calculations for magma's removal, normalizing the temperature and making it skip the heat calculation. But if magma is always cooling, I'd think that might no longer matter.

What's worse, there would always be heat flowing upwards from magma sea and volcanoes - dissipating off the map edge could work, but it'd leave weird situations where center of embark is hotter than edges.


I don't think heat affects pressure much with solids and liquids, since they don't expand/compress much with it. What it does affect is evaporation; air humidity isn't tracked right now.

Note that many specific heats are already in the raws, such as iron's 450.

For heat transfer, it probably should be most conductive - after all, current follows the most efficient path.

But if you have to check each individual tile for fluid sharing, it comes back to every-tile check. Ugh.

At which point might as well do local approximiation and either model everything in 1 tile as single heatsink, or give heat to everything in single tile at once. (It'd have the cool effect where dropping magma onto large enough pile of metal could have the metal cool down the magma to solidify it rather melt itself.)

In any case, don't see why heat flow has to be linked to fluids, rather than handled like fluids. Well, it is kinda same problem as whether handling new gaps for fluid bodies to flow into is efficient, expect whole map is an ocean.

[Qyubey]

Non-residual magma pumpstack: design where every z-level(alternating empty space and floor) is
######
#+%% .#
######

#= wall

Since magma is placed and removed each step, it gives empirically around -1 FPS per z-level of it.

Residual means that instead of pumping to 1 floor tiles it pumps to 3, so that some magma will remain behind and not force temperature calculations for magma's removal, normalizing the temperature and making it skip the heat calculation. But if magma is always cooling, I'd think that might no longer matter.

What's worse, there would always be heat flowing upwards from magma sea and volcanoes - dissipating off the map edge could work, but it'd leave weird situations where center of embark is hotter than edges.


I don't think heat affects pressure much with solids and liquids, since they don't expand/compress much with it. What it does affect is evaporation; air humidity isn't tracked right now.

Note that many specific heats are already in the raws, such as iron's 450.

For heat transfer, it probably should be most conductive - after all, current follows the most efficient path.

But if you have to check each individual tile for fluid sharing, it comes back to every-tile check. Ugh.

At which point might as well do local approximiation and either model everything in 1 tile as single heatsink, or give heat to everything in single tile at once. (It'd have the cool effect where dropping magma onto large enough pile of metal could have the metal cool down the magma to solidify it rather melt itself.)

In any case, don't see why heat flow has to be linked to fluids, rather than handled like fluids. Well, it is kinda same problem as whether handling new gaps for fluid bodies to flow into is efficient, expect whole map is an ocean.

...Much like the rest of the world, I hadn't actually considered the issue of global warming. Well, map-wide warming.

Again, I don't intend to track air either. Steam, maybe, so long as it's kept in a pressurized state (disappears/forms water without sufficient pressure, so it would delete itself if it escaped), but not really worrying about that right now.

Units to change; I'm just checking formulas and systems right now.

Yes, more conductive might be better.

If you want to measure Temp or Pressure adequately, doing an every-tile check is unfortunately unavoidable. I do have some ideas on how to alleviate the drain though.

I had only planned to consider temperature to convex between tiles - not creatures or objects. Those things can still be affected by heat, but they don't alter how it spreads. So if a ton of heat transferred into a tile containing a dorf, the dorf wouldn't affect how it spreads to the next tile, but it would change its temperature to match that of the heated tile. It could happen either instantly (spontaneous melting/freezing), or over a period of time (objects/creatures will adjust their temperature to match their tile at a certain rate, like 10 degrees a second). I like the latter since it allows you to escape danger, but it might be harder to program.

True, heat should probably be its own system.

[Qyubey]

I tried to find out a way to factor in heat transfer with different rates depending on material - which led me around in a few mad circles. At one point, I literally just recreated how water currently spreads, so that was weird. In any case, I think I have a good idea for how to do it now:

Every tile has a Temperature value. Each tile undergoes a temperature check at a certain time, then loops after a certain amount of frames.

Temperature Check

Spoiler (click to show/hide)

1. Function selects a tile, going from minX to maxX, then from minY to maxY, then from minZ to maxZ.
2. The tile is checked to see if IDLE_TEMP in the tile is TRUE. If so, it ignores it.
3. The tile gathers the collective average of it and all the tiles surrounding it.

• If the initial tile's temperature matches that of its surroundings (to a set significance), then nothing occurs, and a it sets IDLE-TEMP to TRUE.
• If it is unequal to any of the collective tiles around it, the function continues.

4. It calculates the required ΔT (change in temp) for each tile in order to obtain the average..

• If the average is below the individual tile's temp, the formula for ΔT is [ ΔT = 1 * iT + xT]
• If the average is below the individual tile's temp, the formula for ΔT is [ ΔT = -1 * iT + xT]

   Where iT is the initial Temp of the tile, and xT is the mean Temp for the collective tiles

5. It modifies the temp of each tile a a fixed rate set by the contents of the tile (water/stone/air/etc).

   What I mean here is; if the rate is set to 5 and it requires a ΔT of 6, it'll be limited to changing by +5/-5 degrees, but if it were ΔT of 4, it'd change by +4/-4 degrees.
   The formula here is one of a few,

• if ΔT is positive and above/equal to the rate, the formula is [ fT = iT - r * 1 ]
• if ΔT is negative and above/equal to the rate, the formula is [ fT = iT - r * -1 ]
• if ΔT is below the rate, the formula is [ fT = iT - ΔT ]

   
   where fT is final temperature for the individual tile, and r is for the rate.

6. After altering temperature values, the function sets IDLE_TEMP in each tile to FALSE.
7. Function moves onto the next tile.

Okay, that should about cover it. This creates a loop that checks every single tile for temperature variations and equalizes them, according to the rate of the source tile. If it ever encounters static temperatures, it flags the tiles and skips over them on the next loop - thus saving CPU cycles.



Because the function works in conjunction with its surroundings, it should have the ability to equalize temperature with respect to all 26 possible adjacent tiles.

As for how to deal with the problem of source heat tiles creating a rising tide of heat, it could either sort itself out by letting miniscule amounts of heat transfer, until it believes that two different temperature tiles are equal due to the significance.

Spoiler (click to show/hide)

If a tile transfers 0.001 degrees of heat, and the significance is only set to examine differences of 0.01, then it wouldn't run.

Dunno how well that'd work, but it'd keep heat from rising through layers of rock, whilst still possibly allowing subterranean levels to heat up thanks to magma. It might also solve eventual magma cooling since heat stabilizes at a certain point - creating a small, static zone of 'heat saturation' that surrounds magma and the like.

[Fleeting Frames]

Isn't that just a more calculation-intensive variant of how it currently works (no flow rate, temp doesn't really spread more than 2 tiles away)?

It's a mess, given ability to disable....But if you assume magma layer/semi-molten rock and instead calculate head towards the surface, that could greatly simplify things, allowing one to check only where there isn't static stone layer and otherwise applying to whole z-levels at once - heat flows up, expect where blocked by air, thus making cavern openness affect underground temperature.

With seasons passing, applying a counter-Z gradient from the surface would seem like natural, of course, but that seems to run naturally into player-created holes in ground causing issues (and constant temperature recalculations, instead of doing it once at embark and then ignoring till something changes.)

Though here, metal veins would act kinda like aquifer idea you had for containing more water or something. Ugh, don't see a way around individual tiles there.

[Qyubey]

Isn't that just a more calculation-intensive variant of how it currently works (no flow rate, temp doesn't really spread more than 2 tiles away)?

It's a mess....But if you assume magma layer and instead calculate head towards the surface, that could greatly simplify things.

No idea, I'd have to research it some more.

Edited to talk about magma at the end there.

Heat aquifers? Haha, yeah, that would technically work.

EDIT: The way I see it, it'd run a number of loops at the start, until temperatures near magma seas and pockets stabilize. Although if magma was close enough to an underground cavern, it might run for a bit longer as it penetrates into underground air. After that, it really only calculates temperature changes that the player and other creatures create (dragonfire, dumping magma, etc). The heat system would be important if steam power is to work though.\

From the wiki:

Temperature transfer in DF is fairly simple - most temperature values have a whole part (in "degrees Urist") and a fraction part (which ranges from 0 to the material's SPEC_HEAT minus 1). Once per tick, the game calculates the relevant temperature difference (e.g. between the item itself and the tile in which it is located) and adds that to the fraction part, then adjusts the whole part until the fraction part is within range. For example, a piece of Lignite (which has SPEC_HEAT 409) at temperature 10015.0 (room temperature underground) exposed to Magma (temperature 12000) will heat up by 1985 fraction units, which will increase its temperature to 10019.349. In order to reach its ignition point of 11440, it would need to be in the magma for a total of 517 ticks, over 5 seconds at 100 fps.

That's pretty much what I described in terms of object and creature heat transfer, so that's all good. I still don't know how tile temperature transfer works though.

[Qyubey]

Did some more reading on the wiki and some experimentation ingame with the current water system.

Seems that it uses an averaging system for tiles of 2/7 and above, between that tile and anything around it that is either open space or contains a liquid. I'm guessing what happens is any tile containing water more than 1/7 will seek to flow, so it will grab a random tile around it and find the average of the two (so, 1/7 for both). Curiously, due to the fact that it decides this randomly, you can get situations where a 7/7 tile flows into the same tile twice:

Spoiler (click to show/hide)

Might be a bit difficult to explain, but I've created two instances of 7/7 water here. The top one spread out into that 3x3 area adjacent to the NW wall. However, what proves that it randomly chooses a tile is the fact that it managed to place a 1/7 puddle outside of that 3x3 area. Which means it must have transferred 2 units of water South of its original tile, then transferred one of those units to the tile SW of that. Marked the path with a red arrow. Each frame, it must just grab a random adjacent tile and average them; the flow seems too fast to be transferring liquid one unit at a time.

The other time I've managed to pause before it completely spread out. My cursor is north of the origin spot, marked with a yellow dot, so you can see that two units have definitely been transferred north. After I unpaused it, the water averaged itself with the tile to the NW, also jumping out of the original 3x3 possible area.

Magma seems to follow the same rules, but does so at a far slower rate. Even within my small test of making two 7/7 blocks of magma, I noticed the inefficiency. A block of 2/7 magma to the north of the mass, which bordered 3 open spaces, actually transferred it to an empty space SOUTH of the puddle - meaning it must have averaged itself back south instead of logically flowing north into the open space.

Testing in a 4x4 space with 27 units of water (7,7,7,6) definitely shows that the 6/7 block and one of the 7/7s attempt to average each other. When entirely filled with 7/7, no motion seems to occur but it's impossible to tell, after all, it could still be attempting to average itself. However, I'm guessing 1/7 and 7/7 water can both act as static and ignore loops, or at least I hope so. But since the system needs an alarm to tell 7/7 water when it should stop being static, it's likely that it still constantly checks the spaces around it, even when static.

Going to do some testing in Fortress/Adventure mode regarding other things. Will report.

[Qyubey]

Upon examination, the fact that water in this game uses averaging between two random tiles makes the flowing water make SOOOO much more sense! It's why pools take forever to drain; they literally can't flow faster than 3 or 4 units per tick into an open square, then the square after that has to half again, and again. The speed of water calculations only masks the fact that the flow rate is abysmally slow; you can really see how slow it moves when you stretch it out over a lot of tiles - or even comes to a near-complete stop. Given that it seems to consider open air and a 1/7 tile of water as equally promising, you can very quickly see a 'blobbing' effect to water in the game.


So aside from good ol' water, there's a few sets of special circumstances that affect water in the game:

• Brooks, flowing water which can be walked over.
• Murky water, which arises from a 'Murky pool' ground tile.
• Salt water, from oceans, seems to have a similar concept.

Turns out brooks are more of a workaround; a 'Brook' is actually a special floor tile that you can walk over, but still allows liquid to pass, like a floodgate. When testing Brooks, I found that the water inside was regular water, not special in any way. Channels containing it we impassable by dwarves, unlike the brook; they had to walk onto the 'Brook' tiles to get to an area I sectioned off via channeling. Not much to say here, since Brooks are more of a cheat way of making water streams you can walk across. The water is ordinary.

Murky and Salt water are far more interesting.


Murky status for water persists, even when it flows onto regular tiles again. If drained, any water that arises to fill the pool is also murky. Seems to imply water-containing tiles can inherit properties from other tiles, and spread them as they flow. All the better for a liquid body system~

'Murky' is considered a contaminant, and can be removed with a screw pump (this process is probably just deleting the murky water and spawning regular water at the end of the pump).

When regular water from the brook attempted to average between Murky and regular water, it left both tiles as regular, deleting the contaminant. However, dumping fresh water from a bucket into stagnant water does not produce this effect, it remains stagnant. Speaking of buckets; Buckets maintain their contamination status when they are dumped. Stagnant water stays stagnant, fresh water stays fresh.

When fresh water is dumped into a hole, then allowed to mix with murky water, all of the water turns fresh - effectively purifying it. It likely does this to avoid polluting an entire river.

At this point I'd like to note that if Fluid Bodies were used, you could measure contamination levels within an entire body and avoid this problem. If fresh and contaminated water mix, it averages the contamination across the bodies, so when they separate they would then have half and half contamination. Same for salt levels, speaking of which...


Time to hit the beach... for SCIENCE!

...

...Huh. Salt water is... strange. For one, when exposed to fresh water, salt water and fresh/murky water will refuse to overwrite the other. They actually WILL still share though! Seriously; although each tile remains static in whether it is 'Water' or 'Salt Water', they do appear to exchange units of liquid - effectively meaning that if you create a small hole next to the ocean, dump fresh water in there, then connect it to the open sea, you will have an infinite supply of purified water. No need for a screw pump.



Who the fuck needs Desalination plants!? Not dwarves, that's for damn sure. My guys were kicking back on the beach, drinking salt water filtered through nothing but a few drops of stagnant water

Which also seemed to spontaneously de-contaminate itself for some reason...



I also dealt with Aquifers at the beach. It seems like they fill adjacent tiles with the same system; open tiles fill with 3/4 units of fluid, so the aquifer rock is treated as a 7/7 tile that cannot be depleted. I connected an Aquifer-flooded tunnel up to salt water (pouring down the stairs) and interestingly enough, once the salt water touched regular water, it refused to 'claim' any more tiles as salt water. They were all signified as regular water.

I performed a repeat test to be sure, this time letting the salt water flow in before I triggered the aquifer. I'm sure Urist appreciated the gravity of his contribution to the field of dwarven water physics whilst he mined out an aquifer in an already-flooding room. The previous result seemed to be a fluke; salt water could claim tiles just as easily as regular water, it's just random to see if they 'jump' on a tile first. Also produced the same result: salt water and fresh water can exchange units, but cannot overwrite one another. Curious. My next thought would be to drain out regular and salt water tiles to see if they retained those values when fluids were removed - although that would take a lot of time and I feel like the answer is 'No'.


This is literally what it looks like.


So... on closer inspection, water physics are even more fucked than I had anticipated. Some of this stuff might even be worth adding to the wiki, regarding how the liquids interact. I'd really love to see how salt and murky water interact with lava, but that's an elaborate thing to set up so I'll leave it be.

Now, to figure out if Fluid Bodies could solve these problems...