Seyko

Yes. It only makes sense with a good roleplay game. It's more of a topic for a mod. And then the mod should make any farm more demanding. So that you can't do everything at once. So that you do one thing, earn money, pay for the work of others. Damn.. I live in this mod!

Well, yes. It's obvious, but I didn't even think about it.

On the old laptop, FPS in DF was more stable than in Terraria. The video card was the weak point.

I've found a maximum of 60 gears in my singleplayer game. All from caves, and I'm not drawn to them at all. So it's a bit strange to me that gears are a common currency. Ok, I get it.

Since there are knowledgeable people here, wouldn't it be more productive to calculate water analytically and apply the finished calculations to the coordinates of the world? I don't know, I was a C student! What happens inside the blocks (about porosity) doesn't need to be drawn and loaded on the video card. And the water that comes to the surface would be described by an equation, for example, Navier-Stokes, and would be interpreted on the game space. As if you take a figure and apply it to millimeter paper. This requires knowledge of physics and numerical methods, which is difficult in itself. But would it be optimal for implementation in the game? I don't know if the Navier-Stokes equation is something that can be useful. But on the Internet they write that it is widely used to solve various problems. In essence, we need to know the direction and speed of movement. Direction is in which direction the cube transfers water. Speed is the amount that is transferred.

You can also wear coin pouches on your belt. And there will be a stealing mod. But I'm afraid that this will require a deeper role-playing game. You can do everything you need and even more on your own. And not die of hunger. Or on large servers, where players occupy large territories. With a shortage of resources, the market and economy can work. (Maybe I'm wrong, I've never played on a server)

This is not a requirement, but a nuance for the future. If a specialist takes up the idea, it will be clearer to him how to proceed. Even as it is stated now, if the modder wants a mod without AH, then there is no need to bother. If this is some kind of water wheel for interaction with AH, then you need to register the parameters for the mod blocks. Or simply. For a block without a parameter, the default value is selected. I have nothing against it, but I would like to have it in vanilla. I try to make an effort to somehow clearly describe how it could work. So that it would be easier for a developer or enthusiast modder. But this is not enough to achieve a result. Therefore, hope is on the developer. Especially if the idea received support from users.

How it works. 1. First, you need to make a cliche blank. No less than iron, or only steel. 2. Engrave the coin obverse. 3. Think of a name for the coin (currency). 4. Put a piece of metal or alloy. 5. Stamp with a hammer on the cliche. In the inventory, all coins look the same. But the name is different, depending on the currency. And it will stack by currency and material (gold VS-Coin, brass VS-Coin, etc.). When creating the first cliche of its kind in the world, you need to write down the name (currency). When creating a copy of the cliche, you just get a copy. The cliche has durability and wears out. You cannot edit the cliche, but you can look at the pattern, even on a broken one. Any cliche can be broken into pieces. If one player steals a cliche or its pattern, then he can also issue the same coins. Coins can be melted down at the price of a nugget. You can buy someone else's currency, melt it down and mint your own. Maybe when adding several cliches, you can mint several coins at once from a plate. I know about rusty gears. Let them remain for merchants. Alternatively, to be able to register your currency, you need to buy a "permission" from a merchant, or get it from the server admin.

I suggest adding coin minting to the game. Not just cutting metal into round pieces, but cutting out a unique cliche for minting, creating your own currency. Everyone will be able to make their own money, but will everyone be able to make it solvent? I think this is an interesting idea for roleplay.

@Katherine K Firstly, I am very pleased that someone is seriously interested in my point of view. Unfortunately, I will not be able to support your work. And with even greater regret, I will hardly be able to continue it. I believe that advanced hydrodynamics should be at the core of the vanilla version. At least as an option. It is obvious to everyone that this is a difficult task and I cannot imagine that enthusiasts will do such work, and then rewrite the code for each game update in years. I am trying to make some kind of model so that the developer in this topic will find not only terms of reference, but also examples of execution. I also think that rivers are a task of the terrain generator. And this is another reason why advanced hydrodynamics should be part of the vanilla version. Regarding static lakes in rivers. I had time to think, and everything I wrote in the topic title about VOLUME, POROSITY and MOISTURE is redundant. It is enough to leave VOLUME (or MASS) and ENERGY (for mechanisms). It is the ENERGY parameter as an increment of MASS that will make rivers dynamic. When I feel strong enough, I will rewrite the initial post. Is it just me who thinks that everything related to water in the game is incomplete?

While there is interest, it is worth discussing. Suddenly, while inventing the wheel, we will come up with a spaceship. Or vice versa.

I'm trying to remember C# to model the idea. There are results, but they are too childishly primitive to publish. If anyone is interested..

And if we go in the opposite direction, the direction of the water will flow in the opposite direction? Then the source block needs to store data about the direction. I think so too. There is no point in complicating things. And what is the purpose of the water flow block in the game? Just a guess, the flow was borrowed from another block game (I see that it is not customary to call it by name on the forum) only to solve the problem with the edge of the water. As a result, the flow is not optimized and is not intended for complex things. Because there were no plans for it. And in general, if you don't need realistic water (Welсome), then you don't need to come up with a transport system. It's enough to add "pipe" blocks that are connected into a structure. We build a line of "pipes" on a beautiful stand. At the beginning, a "funnel" block, at the end, a "spout". The end. When the state of any "pipe" block changes, the neighboring connected ones are checked. A chain reaction with loading chunks (no graphics, just math). The "funnel" is connected to the "spout" - ok. No - and there is no water. The cherry on the cake - remote loading of chunks!

Do we really need to monitor the aqueduct's condition along its entire length? It's like Schrödinger's cat. If a chunk isn't loaded (meaning there's no player there), then God knows what's going on there. It doesn't matter if it's somewhere at the source or in the middle. This can also be attributed to the game's lore. Maybe a temporal storm is happening in a distant chunk while we're away. Or maybe Seraphim himself is setting time in motion. When a chunk is unloaded from memory, the state is written - everything is ok. When loading into memory, the chunk is checked - everything is still ok?

New topic - I tried, but it's very long

At the time of opening the topic: The inclusion of "Advanced Hydrodynamics" (for now this is a working title, hereinafter AH) in the game is an option when creating a new world similar to the existing "cave-in" system. The player can try the new option, or play as before. So far there is an understanding of the need to add a new block - advanced water. For brevity and convenience, we will call it A-Water. A-Water has height options like charcoal when you dig it out piece by piece. A-Water contains 16 layers, each 10 liters (1 bucket). Vanilla blocks and A-Water get new parameters: VOLUME, HUMIDITY, POROSITY. Perhaps the new parameters should be stored in a separate data array (water map), which only exists if the AH option is enabled in the world. This may free you from having to rewrite the code for all existing blocks, including those from mods. But in this case, the mod must have an additional parameter grid for its blocks, or it will not support AH. Or it will work strangely. Perhaps storing some of the data in another place will have problems with write/read speed. This point requires an assessment by a competent specialist. It is also not entirely clear how much additional disk space all this will require. It seems to me not very much More details about the new parameters: VOLUME (V) - the amount of water that a block can hold. - For impermeable blocks (stone, clay) V = 0 - For air V = 1 (when air is filled with water, an A-Water block appears in place of the air) - For sand and gravel V = ... maybe 10 - For all types of soil V = 8 - For different building blocks, you need to think. For example, 4 or less. It does not matter now. The idea here is this: if the A-Water block contains 16 units of liquid, this is the maximum stacking. Earth and other materials capable of absorbing liquid thus fill the internal voids. Depending on how many voids there are in the material, it will be decided how much liquid it will contain. For all types of soil, V = 8 was chosen because it is half of 16. I can't explain it, but my intuition tells me that in the future this may be convenient, because the soil will be watered for agricultural crops. POROSITY (P) - it's probably more correct to call it a priority. This characteristic shows what place the material has in the queue for absorbing neighboring excess water. - For impermeable blocks (stone, clay) P = 0 - For air P = 1 - For sand and gravel P = ... maybe 6 - For all types of soil P = 9 - maximum - For different building blocks I haven't thought about it, we can decide later. - For water and A-Water P = 1. I think: if you bring a napkin to water spilled on a table, the napkin will pull the water towards itself. This is surface tension due to porosity. Therefore, for water and air, P is low. MOISTURE (M) - how much water is in the block at the moment. If the M of block has more than 75% of V, then P = 1. This way, the soil will not try to become wet mud (a figure of speech, this is the same earth), unsuitable for agriculture. Filling the block over 75% will only happen if the excess water has nowhere to go. Well, or maybe with the help of a watering can. The sources for groundwater and replenishing the world with fresh water will be rain, springs and melted snow. And possibly aquifers - permeable blocks located near the ocean or lake. Depending on the biome, blocks lose fluid at different rates. Blocks that are capable of collapsing fall if they contain 100% liquid by volume. Vanilla water blocks located at sea level or below infinitely fill adjacent voids, infinitely absorbing incoming water. Maybe not all blocks, but only those located in the ocean, lake biome. Thus, a channel for a sailboat can be created simply by digging it at sea level. But it was noted that this will provide a new way for griefing. Perhaps it is worth thinking about it better, or accepting a new threat. Rivers are basically a long hole with a spring at the beginning, so river generation is mostly landscape generation. The new parameters and rules of their interaction should lead to plausible water behavior. And as a result, having dug a hole, it will be filled with soil and rainwater. Or, having created a gutter from an impermeable material, you can direct the flow of water where it is needed. The downside is that now when choosing a construction site, you need to think through the landscape and the choice of material more carefully. I really hope that perhaps not in detail, but in general, the concept of advanced hydrodynamics will interest Tyron and the developers and we will get a unique, even more elaborate survival world! Hopefully soon! Water behavior algorithms are being considered. There are a lot of nuances and alternative thoughts. I'll try to write next time.

This topic is dedicated to the development of additional mechanics for the vanilla version of the game, introducing realistic water behavior with all that it entails: rivers, groundwater, wells, canals, aqueducts, cisterns, irrigation, water energy, and possibly erosion. Topic created as a branch [HUB] - Water mechanics overhaul: Farm irrigation, sail boat canals, pipes, aqueducts and natural occurring water sources

I am not against it. I support it. Very interesting. I tried to model the algorithm on paper. There are problems and new ideas. In general, there is something to discuss. One of the problems is the starting point of the algorithm. It would be good to get a developer's comment on the distribution of rain (coverage area) in coordinates, so that the epicenter of the rain would be the zero point for the algorithm.

Yes, unfortunately it's not as easy as they write in the wiki. And the information there seemed outdated and abandoned to me. I tried to implement the transfer of bodies of dead chickens in the hotbar cell for the backpack through assets. Well, I got a backpack in the form of a stuffed chicken that is not connected to the bodies in any way... Surreal. Definitely yes, if you have a lot of free time. The entry threshold into the game is high (there are memes about this on the Internet), the game mechanics are many. I have the impression that VS was initially largely inspired by DF. I tried to put together all my thoughts about the behavior of advanced water yesterday and ran into a lot of problems. I will work on it some more. For now, here are some changes: New additional block parameters. VOLUME (V) - the amount of water that a block can hold. For impermeable blocks (stone, clay) V = 0 For air V = 1 (when air is filled with water, an "advanced water" block appears in place of the air) For sand and gravel V = ... maybe 10 For all types of soil V = 8 For different building blocks, you need to think. For example, 4 or less. It does not matter now. For "advanced water" V = 16. Exactly 16, because this is the height of the block in pixels. I think by scooping up water with a bucket we take 1 pixel of the height of "advanced water". By the way, from here I got that the height of Seraphim is about 1 meter! If 1 block of water is 16 buckets of 10 liters, that's 160 liters. 160 liters = 0.16 m3 -> the side of the block is about 0.543 m. If Seraphim is 2 blocks high, that's a little over 1 meter! I'm probably delirious... But, take a ruler and measure the width and height of the door in your room. Divide the height by the width. Is that close to 2? In VS it's 2! The wolf takes up 2 blocks. A real wolf is about 1 meter long. I didn't go into it any further. POROSITY (P) - it's probably more correct to call it a priority. This characteristic shows what place the material has in the queue for absorbing neighboring excess water. For impermeable blocks (stone, clay) P = 0 For air P = 1 (if you bring a napkin to water spilled on a table, the napkin will pull the water towards itself. This is surface tension due to porosity. Therefore, for water, P is low) For sand and gravel P = ... maybe 6 For all types of soil P = 9 - maximum For different building blocks I haven't thought about it, you can decide later. For "advanced water" P = 1. MOISTURE (M) - how much water is in the block at the moment. If the M block has more than 75% V, then P = 1. This way, the soil will not try to become wet mud (a figure of speech, this is the same earth), unsuitable for agriculture. This will only happen if the excess water has nowhere to go. Speaking about the byte variable type, which stores 256 values, I just want to say that this is an economical data type, but even it holds a lot. You can use these 0-255 values in different ways. In fact, at that time I was thinking about writing all the block parameters in turn through a separator, but this is no longer a byte, it's a string. But maybe something similar will work in binary notation... First, it is more important to describe the water drainage algorithm. I stopped at this point and do not see a solution yet. So I came across the fact that everything is not so simple! Who would have thought! In general, this takes time.

I guess I'm not expressing myself very correctly. But in my previous post I actually suggest how to make "advanced hydrodynamics" (let's call it that for now) as an option when creating a world. Similar to the existing "cave-in" system. In general, I will think about describing all the thoughts consistently and clearly. So that everyone can read and have an idea. Here need to understand that the developers have spent a lot of effort to provide an accessible tool for modding (I haven't delved into it, there's a lot written about it all over the site), so to the request "I want a well" the developer can answer "make yourself a well". It's just a new structure like a cellar or a furnace. It's probably rude, but this thought doesn't leave me. Therefore, our wishes must be global and accessible, or intersect with the roadmap or vision of Tyron. Or if everyone unanimously says - we need it! Yes, I also see many topics related to water. I also want all this and faster! Maybe it's worth throwing a link to this one in other topics?

Not only olive, sunflower too! First grind on millstones, then press on a screw press. Make an alternative use of olive and sunflower oil in recipes for an oil lamp and oiled leather. In the future, oil is the basis for paints (we want to paint pixel by pixel with paint and a brush) and polishing paste (polishing jewelry, we are go!). Maybe a lubricant for shafts and gears.

Regarding rewriting the code. At first glance, it seems to me no: Of course, not everyone will be delighted with such serious changes. Therefore, as with the cave-ins system, advanced hydrodynamics should be an option. The existing system will be supplemented with mechanics and water dynamics, which I wrote about earlier. I will immediately move on to the question of data generation and storage: advanced hydrodynamics will not be stored in the standard world. If we enable this option, a three-dimensional data array is additionally created for the world. This array will store the new block parameters that I wrote about earlier. Perhaps multi-threading will allow this to work painlessly. Let the experts think about this. Regarding data storage. Variables of the byte type each occupy 1 byte, but store up to 256 values. For a world column of 8 chunks (32x32x32 with a height of 256 blocks), this is 262400 blocks of 1 byte each, which will be approximately equal to 256 KB. Not much for me. Air blocks will take up memory so that the engine understands that there is air there, and not a quantum hole. And water below sea level needs to be thought about... I understood @JYAR about layers of water like charcoal. Yes! This is the most logical! And I suppose this will be another water block, optional. About rivers. I like the theme of sources. If rivers are filled with ground and rainwater, then it will quickly run out. Here, a source as a constant influx of water will not allow it to dry up. In general, in this way, river generation comes down to generating a landscape and setting a source. And if the player does not enable the advanced hydrodynamics option, then the "river" (a strip in the ground) is filled with ordinary water. About evaporation, yes. The farmland blocks are already drying out. It is not clear how, maybe it is already ready. Well, the fact that water flows in and out of the "ocean", the "ocean" is abstractly constant. It is not replenished and does not dry up. I think this logic will help fill empty blocks and flow blocks underwater. Channels will not need to be filled, it will happen by itself, if not above sea level. But I did not think about griefing... I have never played on the server. On the other hand, griefing is an integral part of the game. After all, the game has padlocks and a system of strengthening blocks. Now we will need to think through the drainage system properly )

I remembered. Everything I'm trying to describe already works in Dwarf Fortress. My vision is not to add bits like a well, a river, etc. We need to completely rework the water mechanics so that all the missing aspects of the game become available automatically. As if from the general to the specific, and not vice versa. In the meantime, everything that is written on the forum related to water looks more like a topic for mods. Do I understand correctly that we write on this forum in the hope of being heard by Tyron and the development team? Then we should offer an idea that the developer will want to add to the game! By the way, how does it work? We, the users, should create a stir around the topic, then the team will start reviewing? Or do they look once a month? ...

Effigy burning rituals, altars and offerings

I see it differently. So that every conditional period of time the block is filled with water. And only in case of block overflow the excess water goes further. Thus a short rain can pass unnoticed, but a long storm will flood caves, lowlands, fields (there are interesting discussions on agriculture on the forum). What you are saying can really simplify the calculations. If at the beginning of a thunderstorm the VS engine already knows how much precipitation will fall within an hour, what the result should be and will simply draw water blocks of the required height. If I understood you correctly, I have to use a translator.