Mojira Archive
MCM-1534

Loading a structure in water creates ghost waterlogged blocks

Partner Rank:
2

Partner Team Reporting:
Everbloom Games

Verification builds:
1.18.30.20_rc3

Summary:
Loading a structure in water does not waterlog blocks. Instead, a ghost waterlogged block is created, with water that does not spread. On world reload, the water is gone.

Impact:
Creates ugly air bubbles whenever a structure is loaded in water that make our content look unprofessional. An upcoming map of ours relies heavily on loading structures both in and out of water, so we can't just save the structure waterlogged.

Repro Steps:

  1. Open the provided world.
  2. Run /function test/water
  3. Stand in the center of the block so you don't get pushed by the water
  4. Run /function test/wall
  5. Observe the surrounding blocks.

Observed Results:

You see a waterlogged wall block. HOWEVER, the water part of the block is a ghost block - the wall isn't actually waterlogged.

Because of this, the flowing water surrounding it quickly disappears. If you reopen the world, the water is gone.

Expected Results:

I expect the wall to load waterlogged, without disturbing the water, because there is no air in the structure file anywhere. This is a complicated bug though and people might be relying on different behaviors, so my proposal is below the Notes part of the bug report.

Regression Build:

This has always been the case

Screenshots/Videos attached:

 

YouTube

 

Notes:

The attached world has some extra functions for loading structures:
/function test/wall_waterlogged creates a waterlogged wall.
/function test/wall_airlogged loads a structure with air in its second layer (via NBT editing)

Expected behavior(s)?

I can definitely see arguments for both waterlogging and not waterlogging the structure on load.

I think, from the player's perspective, it makes more sense for it NOT to waterlog - you saved the structure without water, it should load without water.

HOWEVER, if you look at it from the perspective of the structure file format, it's a different story.
(Pictured: the NBT of a non-waterlogged cobblestone wall saved into a structure, which is loaded via function test/wall in the attached world)


Inside the block_indices tag, there are two lists, one for each "layer" of the world. The first is usually the block layer, and the second is usually the liquid layer.
For example, a waterlogged wall would have a wall on the first layer and water on the second.

The only exception to this rule is when the liquid is alone on the first layer. If there is no liquid-logged block at that position, the liquid will be at the first layer instead of the second.

 

The Real Bug

-1 means "keep whatever is already there at the destination". This is what a structure void represents when saving a structure.
Currently, all structures saved will have a -1 in the second layer, so long as it wasn't a liquid-logged block.

This means "keep the liquid layer in the destination intact". In fact, the game does this correctly. If you load a waterloggable structure into an already-waterlogged block (not just water), it will keep the water at the destination. If you somehow load an airlogged structure (created via nbt editing) into a waterlogged block, it correctly removes the water!

 

The real bug is that the game does not transfer liquids from the first layer to the second. Remember how water alone is stored on the first layer, not the second? Loading a structure with a waterlogged block SHOULD take into consideration that the liquid at the destination might be on the first layer instead of the second.

Alas, it does not. A simple water block will be replaced by a waterloggable block, because they occupy the same layer.

 

My proposed solution without breaking maps:

A versioned change, dependent on base_game_version or the BP manifest:

Structures loaded in this new version will be loaded, by correctly moving liquids at the destination from the first to the second layer if the structure has a -1 in its liquid layer, and a waterloggable block in the first.

Long-term, after the previous is done:

It would be nice if we had more control over the second layer in structures saved in-game. For example, an argument in the structure save command to explicitly set which block to save on the second layer. For example,
/structure save __ x y z x y z true disk true void
to save a structure with -1 on the second layer, or
/structure save __ x y z x y z true disk true flowing_water
to set a specific block on the second layer, such as water or air

Unresolved

Energyxxer

2022-04-20, 02:38 AM

2022-04-22, 12:37 AM

0

0

-

-