Seyko

I would start by disabling all mods on both sides if there are any.I'd start by disabling all mods on both sides, if any. The errors mention Packet_Server packet. Maybe it's missing?

I didn't want to blame anyone.

Thinking about Rimworld...

I don't think we'll see blood splatter in the vanilla version of the game. I remember a message from Tyron somewhere along the lines of "We won't be working on butchering because doesn't like cruelty." Else, it would be nice to get a blood trail from wounded game.

Maybe someone will be interested and continue the idea.

I just read on the internet that during the pyrolysis of wood in the oven, wood vinegar should form, which is used as a fertilizer. Sorry, this is off topic.

It's my pain that I can't burn charcoal in the coke oven. That stupid pit will haunt me for the rest of the game.

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.