Print

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

[NW_Kohaku]

Well, I'm trying to work on it, and make the fluid system as efficient as possible by removing the need for iterative per-tile calculations...

Thing is, I think that if I use bodies of fluids, inflows and outflows, as well as swells and depressions, I can make static and flowing bodies generally work fairly efficiently.

The problem is, the way I'm coming up with how to model a swell is basically to have what the water level would be without the swell, and then create a height, and then something that looks like a normal curve that has an ever-larger standard deviation to map out how the fluid is flowing to make a level plane again... which is probably not the easiest way to handle things, but I am having trouble finding much better ways to handle fluid distribution models that do not rely upon iterative per-tile methods of calculation...

As for rivers, the key piece of information is the rate of flow of water.  If a river will have the same amount of water flowing through it at any given point, then the breadth of the area that it travels through determines how quickly the water travels - so a three tile wide, two tile deep river that suddenly gets funneled into a one tile wide, one tile deep channel/pipe (without ability to overflow) will have to run six times as fast to keep the water flowing.  In that sense, the calculation for making rivers run fast is fairly easy.

The only major difficulty is in programming a way for the computer to recognize the direction the river is flowing, and the general amount of area it has to flow through, and recognize changes in the area that the water can flow through.  Still, if you have an ability to track the direction that the water is flowing, you simply have to trace out both other directional axis to see how large the area a river has to flow through... with the real problem is in non-cardinal direction flows, like the way that brooks in the game already have somewhat winding paths.

[Andeerz]

<3's for this thread.  I am in full support of this suggestion, NW_Kohaku!  If it was in eternal suggestions, I'd vote for it.

[NW_Kohaku]

It is on Eternal Suggestion Voting.  The link seemed to have been broken, though, as they changed the number in the link after I posted it.  (It apparently used to link to #vote248 in the OP)

http://www.bay12forums.com/smf/eternal_voting.php#vote258

[NRN_R_Sumo1]

I do fully support it, and if there was a way to disable default workshops from being made in DF, as well as default reactions, I'd probably be trying to make this entire system just from modding.. although it wouldnt be near as classy as having it be the default DF.

Elephants really should be used to make several dozen capes.

[tfaal]

If you want to get rid of the current workshops, you can just remove their kebindings. I think that a full conversion mod of that sort would run into other problems, though.

[keda]

I really like this idea, but I have a vague feeling that it would have to involve iterative per tile computations, at least for each tile that is in a state of pressure imbalance. I'm also thinking about the behaviour of fluid in a realistic cave-in. Solids rock does not have viscosity but could nonetheless experience friction. When moving rock comes into contact with fluids, it should exert pressure that equals the force required to decelerate the rock, which, if the rock has a very large mass or high velocity would be a lot. The result would be a big splash of fluid flying out in all directions, even up Z level just to move the fluid under such high pressure. The rock itself would experience massive internal stress and perhaps decompose into rubble. Regarding pressure, I think the location of each tile or perhaps rather each border between tiles, that by some event has triggered it to become into a state of pressure imbalance could be put into a priority queue, associated with the direction and magnitude of the pressure, as well as the velocity of the flow, which is to be accelerated by the pressure (and decelerated by the viscosity) The higher the velocity, the more often the fluid has to be moved across the border, and so a smaller time interval is to be added onto the current tick count pushing the element back into the queue, until pressure balance is achieved again, which the viscosity will achieve, as well as the even spreading as a side effect.

[keda]

Btw, I'm thinking that a large parts of a constantly flowing river (the parts that are not in bends or bottlenecks) would actually be in a state of balance, i.e. that influx would equal outflux which means no acceleration, yet water flows through the tile. I'm not sure if this should be represented somehow, like it is now, as water flows very unevenly now. Slow moving water might not have to but fast moving water would experience turbulence.

[NW_Kohaku]

Btw, I'm thinking that a large parts of a constantly flowing river (the parts that are not in bends or bottlenecks) would actually be in a state of balance, i.e. that influx would equal outflux which means no acceleration, yet water flows through the tile. I'm not sure if this should be represented somehow, like it is now, as water flows very unevenly now. Slow moving water might not have to but fast moving water would experience turbulence.

Yes, actually, this is how I plan to make most water calculations become based upon bodies, and not iterative per-tile calculations.

Most water in a "stable state" of either sitting in a lake or flowing in a continuous loop, or at least flowing in a stream with a steady rate of flow should be computable as a single body.

I am also sure I can come up with some way to fudge pressure differences in a single body of water into something simpler, which is why I was talking about "swells" and "depressions", which would basically make differences in water pressures into a few addendum tags on a body of water that create temporary (or, if it were a waterfall pouring water down into a lake from above on one end, and a sink draining water on the other end of the lake, it could be a permanent stable-state swell and depression pair) flux in the water levels without having to guage the water on an individual level.

The problem is not in the "lakes" or the "rivers", but in the "spills", the times when water is spreading outward over formerly dry land, and looking for the lowest point.  This is the part that I was really trying to minimize the calculations on, but may have to just give up and eventually make it essentially iterative, but with an overall body push towards a certain direction.

Unfortunately, I have a few projects I'm juggling in this suggestion forum right now, though, and I'm a little preoccupied with the Improved Farming (and Class Warfare, and DFize and Procedural Forts), so I have put this problem off for a bit...

[Soralin]

Yeah, and things like pools of water merging, like channeling into the bottom of a couple of lakes, and have them flow into some central chamber, or even just a small line of contact together.  Or if you dug a channel between a river and a lake.

Or a body of water splitting apart, like if you have a lake with a ridge down the middle just below the water surface, and put a drain on the bottom of one side of the lake, eventually the water level will go down to the point where you now have two separate lakes rather than one.

Or if you have some chamber of water, with a door in the side of a cliff, and open and close it quickly, leading to a quantity of water which is falling in mid-air without any connection to any other source of water.

You'd still have to keep track of each tile too where the water was, since you'd need to know it's borders, and everything else that it acts on, or that acts on it, is on the scale of tiles.

It looks like it could work well for steady-state things, but I don't know how well you could get it to handle changing situations.  I mean, for example, a good worst case scenario:  How well would this system handle digging a multiple tile wide channel into the side of a stream that is at a high elevation, wider than the flow of the stream can fill completely, and having the water flow down the nearby bumpy chaotic cliffside, falling in paths that would cause it to split, and re-merge, and overflow(leading to more splitting and merging), etc. as it goes down?

[keda]

The way I see it, most spills will happen slowly, and the only fps threats would be when massive objects, rocks of fluid are dropped into one causing tsunamies. An even spread over a large area will however experience little pressure and thus even if a large number of these are on the priority queue the time interval at which they are pushed back into it is going to be very large for almost all of them. In addition, all flow is directed, so no more bubbles going back and forth pathing for holes to drop into which I think most of the current cpu issue is. In essence it isn't exactly an iterating through each tile solution, it is only going to check on a tile when it is actually going to accelerate/decelerate water.

[NW_Kohaku]

It's actually less of a problem than you might think if a few special cases are resource-hogs.  After all, right now, ALL water motion is fairly resource-dependent, even the relatively stable-state stuff like a brook or the contents of murky pools that have slightly evaporated so that they aren't all a bunch of 7/7s.

Replacing this with something that makes most stable states resource-efficient with having a few rare events like having a rockslide into a lake still take up plenty of resources would mean that 98% of the time, you're seeing an FPS improvement.

[VoidPointer]

Don't have time to read the entire thread right now (just read most of it), but a quick note on cave-ins: If we assume that non-structural objects (e.g. platinum bars) don't count, we don't have to continually recheck structural integrity. Only necessary when the map changes (e.g. mining, construction). This reduces the FPS hit.

[NW_Kohaku]

Well, I was thinking that something like, say, a 15 ton adult cave dragon or a few 5 ton adult elephants could put quite a strain on the floorboards.

Actually, I've been thinking about the way that stockpiles currently work, with bins and barrels largely being the only way to put more than one object in the same tile, even though most items, even large pieces of furniture, only take up 30 or so liters of volume.

We could, instead, have shelving.  Shelving could hold more furniture and even multiple bins in the same tile, but restrict movement.  Theoretically, if it goes by the same way containers currently work, you could put 10 bins with 10 items into a single tile, significantly reducing the giant layer-wide warehouse sprawls we currently get.  Even with all that you can put into a bin, such shelves would still be nowhere near filling entire tiles. 

Or we could make shelving actually capable of filling whole tiles... if the shelving itself took up a massive 1,000 liters, we could still fit 26,000 liters of materials into a single tile.  That's hundreds if not thousands of items.

[Sunken]

This is on the earlier topic of volume/mass of solid items, but...

Although an exact representation of volumes and masses makes the most sense and is most realistic (and probably won't be too hard to code), there's some validity to the viewpoint that all those numbers may look extremely ugly and off-putting. Make a granite ring, be left with a 149.997 kilogram rock? Sure, the weight might be hidden and only visible when explicitly examined - but in other cases, it may be desirable to determine the amount left in, say, a gold bar at a glance.

What I'm saying is we might need a cosmetic system of understandable quantities, preferably integral, even for bulk things. It is so much easier to wrap your head around things like 130 bushels of wheat, 40 carats worth of emeralds, 10 ounces of gold, than 3472.3 kg, 0.007496 kg, 0.2835 kg (or whatever). Plus it sounds more fantasy-like.

The units would be determined by the good, as well as the amount (after all, "240 kg of gold" is preferable to "8466 ounces"). The internal representation could still remain the same. The advantages to that are obvious. The disadvantage might be that if the amount is rounded up, the player might think he has enough gold for something when in fact he doesn't quite. Always rounding down is one solution, switching to a smaller unit if the number gets too small.

So, a one-tile wall might require "1 cubic meter of granite" whilst a granite earring might require "1 ounce of granite" which should satisfy those who like neat numbers.

Edit: I'm all for the SI system ordinarily, it's just that for a game I agree that integers are far more tractable and comfortable, plus the time period is one where units were very much adapted to what they measured.

[NW_Kohaku]

Well, SI units would at least put everything in a single format, so you could know that 500 liters of wheat was just as big as 500 liters of stone. 

Still, it wouldn't be a bad idea to have seperate units for different types of objects, provided this was still represented in terms of SI somewhere, so that you could see whether 10 bushels of wheat was larger than a barrel constructed to contain 30 liters of material.

Likewise, even if it was represented in "bushels" it would still be measuring "3427.6 kg" of material, it would just be with a different name.  Currently, the game just truncates all fractions.  So we have a 17 "Gamma" bar of copper, which is invisibly 2 liters of copper.

One of the other things about the original suggestion of making everything in these units is that it would treat stacks, differently, though.  You don't have just a single "stone" of 70 liters, you have 70 liters of stone, and if you take 5 liters off of it, and then dump it in a stockpile with another 70 liters of the same kind of stone, it becomes 135 liters of that type of stone.  (The game doesn't necessarily have to care whether it is contiguous stone or not.)

That means that either volume or mass would replace what we have for stacks currently with regards to most raw materials.  (You'd still count things like bolts, earrings, and coins as discrete objects.)  Hence, you would be able to tell at a glance how much gold you have leftover, in liter form.  (Or ounces or whatever if you throw some kind of conversion into it.)