Flying and floating blocks

A flying steam powered ship would need all these blocks. If some textures simply float on top of water that would be cool. With out getting into really heavy physics. Though if Red wanted to give water a displacement calculation vs the surface area and weight of said objects that would like wise be cool after all you can make a boat out of concrete provided you hit the right ratio of weight and surface area.

I mentioned this in my suggestions awhile ago. I thought about the blue print function that the game already has in place. You could use two or three or only one blue prints if wanted it animated but if not you could use only one blue print. Of course this once he gets blue prints to rotate 90,180,270

1. Create a structure (aircraft/automobile/train/boat) we will assume ours is a BOAT
2. Add a special CHAIR or STEERING WHEEL in BOAT ... This CHAIR will be the control station of your BOAT
3. Highlight everything of that BOAT
4. Create (aircraft/automobile/train/boat) BLUE PRINT of BOAT which limits it to floating on water.
5. The BOAT is now like any other blocks it just sits there until you sit in special CHAIR on that BOAT.
6. Sit in CHAIR --> BOAT becomes an ENTITY on back end just like a new body you float BOAT on the ocean.
7. When you want to park it into current position you stand up.
8. As you stand up from CHAIR the BOAT is PASTED like a blue print on-top of the water position if not in protected area.
9. Of course it has some difficulty since if your at a half angle it have to turn you 90,180,270, 0 degrees or whatever works.
10. Or instead of doing step 8,9. it could remain an entity for all time BOAT would be drive-able but I don't know about the memory requirement for that,

Some memory issues may occur if its an entity, so you have to limit the (aircraft/automobile/train/boat) BLUE PRINT SIZE along with how many each user could have at one time.

I might be wrong, but I have the impression that discriminating the inside from the outside of any reasonably shaped boat/ship moving around (to keep it free from water) is going to be quite heavy computationally (and detecting leaks is going to be very heavy!).

As a reference, currently the code does not stops light flow (which is comparable) even within orthogonally placed walls/planks.

Quote from Miwarre

I might be wrong, but I have the impression that discriminating the inside from the outside of any reasonably shaped boat/ship moving around (to keep it free from water) is going to be quite heavy computationally (and detecting leaks is going to be very heavy!).

As a reference, currently the code does not stops light flow (which is comparable) even within orthogonally placed walls/planks.

Could be accomplished using particles but that would mean all water was particles and most computers would scream at you before they just shut down. Though if you made water produce a small number of particles when items touch it to check for leaks then say that if a particle gets through it causes the object to sink........ Depending on how you streamline the code it might only drop the fps on larger builds thus a possible work around.

Quote from Miwarre

I might be wrong, but I have the impression that discriminating the inside from the outside of any reasonably shaped boat/ship moving around (to keep it free from water) is going to be quite heavy computationally (and detecting leaks is going to be very heavy!).

As a reference, currently the code does not stops light flow (which is comparable) even within orthogonally placed walls/planks.

First of all my suggestion is not any different from your character falling through the floor when you walk on drawbridge as it moves.

1. This reference to "current code as an argument such as light flow" This is not an argument.
2. You don't actually have to calculate (LEAKS) or (particles) as if real world physics applies to any game, in fact there is always some physics ignored in all games.

To counter the (leaks critics), I want to say the problem doesn't exist you simply check upon blueprint boat creation (what is in air) & (what isn't above the water) every brick below the water is marked as below water brick and everything above is marked as above water.

The simplest answer to critics you never have to calculate waterflow while driving your boat the water calculation was already done before you ever moved the boat. This is not a real boat no hole or damage can appear while driving it. I don't know why people always think the most complicated problems require complicated solutions, Miwarre admitted he was unsure I must give him stars for that.

Of course my boat example I gave is more difficult than doing what other examples I proposed included (train, car, airplane) but essential I was giving an summarized example.

Perhaps I should of started with a car example: Since it's so much easier for you non-programmers to understand. You do same steps as above but simply keep it on the surface of land not allowing it to go below the surface it becomes an entity no different than your avatar except it has controls and shape that is unique to your car.

The only reason water is more difficult for some to grasp because you have three surfaces rather than just two on land you have (land/air) when you go to boat you have (air/water/land) your blueprint boat will be floating on a plane of water which has to be aware of things below surface & above when the water below turns into land to stop the boat from going onto shore. But you never have to compute any leaks on anything except when the blueprint was computed, your obviously thinking real world rather than virtual world. I am simply going to be moving 3d entity (boat) across a plane (water surface). No different than any other 3D game. All you need to do is compute where was the water level when you created the blueprint above or below surface of water (keep bricks above) and (below surface). Hence only compute one PLANE of water keeping in on (x,y) or in his game (z) ever for model. The only real time calculations you have to do would be check the direction it is moving if there is land in that direction to stop movement of your blueprint.

CPU not that much?
Why? I see some of you are assuming it's huge CPU, it's almost no difference than you rotating around as individual custom avatar your spinning the visual references around back to user, the only reference as to a problem I could foresee was memory, I was only referring to if you made the object so big let's say size of max blueprint you have to keep that in memory or send that object to nearby clients on the server. The exterior shape as you moved it for everyone on the server who is riding inside it or it smashing into things. Of course if those were relatively small blue prints there would be no problem doing that in-fact anyone who's played grand theft auto can see you can ride on cars. You make the player who sits in the chair the entity (ship,car,train, plane) It be easier if everyone of course in the ship/train/car while moving would have to be in one of the seats then you wouldn't have to worry about entities inside of entities which we can see from blueprints not keeping items in chests doesn't have hierarchy recursion.

If the programmer allowed passengers to move around you have to keep track of two things at once the passengers inside your ship relative to the motion of the entity they are riding in which I think will have to be done anyways. For example your driving Grand Theft auto and your standing on the hood then run to back of car. Requires that you calculate the current motion of avatar and the entity the avatar is standing on relative to the world.

Or if they don't go that customized creation route for (boats,cars,trains) it's fine I wouldn't mind static predefined sail boats, cars, trains either but that's going to change any of the checks in entities movements the problems are still there.

For the moment being, I am not concerned with a number of points you quote ('riding' the boat, boat hitting underwater rocks and so on); they need to be solved of course, but I concentrate in distinguishing between the inside and the outside of the boat to make it empty of water. Let me see if I understand you correctly (and putting aside leaks, they are not the most important point; we may even assume boats never leak, no matter their design):

IIUC, you say: when placing the boat, any point which is above an underwater piece of the boat is 'inside' the boat and is therefore clear of water. This is a nice approach (which does not take into account rudders, propellers or bulbs, but these are possibly secondary details). The biggest shortcoming I see is that this assumes the boat is never going to tilt, but it is always displacing 'flat' on the water, so that the boat model Y axis is always pointing straight up and never slanted.

Even under those assumptions, one can imagine that a reasonably shaped boat is not going to be made of cubic blocks, but of planks, arranged in either a horizontal sequence of 'ribs' or a vertical sequence of 'bands' (and possibly both); each rib or band will be made by several planks each with a different 3D orientation and each plank, in principle, can be partially below and partially above the floating line. If this is not considered quite accurately, it is possible to end up with portions of 'world chunks' filled with water inside the boat and/or void of water outside the boat. So, it seems to me even this approach turns out not so simple and quick. Am I overlooking something?

Miwarre, Your not missing the complexity of water or the difficulty involved especially if you treated a video game as actual water rather than treating water as blocks.

I don't really know if this discussion will go anywhere because of the complexity involved in it and Red might just not do custom vehicles or boats in first place but I assure you if you create a mask for the boat from the original blue print it's just a floating 3d object inside the world doesn't mater what outside that blue print you keep the mask inside the boat.

If you put mice into a pickle jar I created an in verses out. A mask as it was a world onto itself.

It wouldn't matter if my blueprint is cubic, but first I switch all the water & air to special blocks. Erase any water blocks from that mask, I will just call these erase blocks ALPHA blocks which are allowed to fill up with water or land sort of the way air blocks do for blueprints now. I will create new type of block FIX air blocks.

Put simply there is already masks in the game where blocks and terrain appear to be separate medium. Since land verses block is already defined differently I presume water will be too. The presumption is based on devs own statement of I will make water blocks and swim animations for our avatars. But if I was developer I do flying and driving first vehicles since it's easiest then tackle water.

I choosing to switch this entire technical discussion from boats to land vehicles for simplification.
I hope you believe that custom vehicles could be done with air blocks verses non-air blocks already?

Because that's clearly already done at a basic level it's only that we don't have blueprints moving in smooth animations, you can see this with your blueprint as you move it or with the drawbridge as you ride it going down. However blueprints I realize is also in an unfinished state even for Alpha because no degree of rotation is found not even 90,180,270. So that's a work in progress.

I assume you pasted blue prints before. As you paste them what happens Air blocks are clearly ignored pasted over the top is your blue print blocks and in the cases you have blocks there the air blocks are filled in with your blueprint. In the case of (boats/trains/vehicles) Air blocks will have to be kept to keep it free as it travels in water. Because right now there is a mask, I am assuming between voxel land and blocks already in the game and they are not the same thing. This why voxel land doesn't get put into blueprints it's ignored / masked out of blueprints.

Voxel Farm and Landmarkthegame worked more than 3 years attempting to create voxel dynamic water, neither really succeeded. Voxels do not follow the same rules as pixels do. With 24 points of contact on each voxel the points of contact with other objects can present some wonderful effects or some major disasters.