Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exit portal at -33.5 surrounded by rock #5

Open
Fixer-007 opened this issue Dec 21, 2017 · 3 comments
Open

Exit portal at -33.5 surrounded by rock #5

Fixer-007 opened this issue Dec 21, 2017 · 3 comments

Comments

@Fixer-007
Copy link

Fixer-007 commented Dec 21, 2017

If you create portal in nether and walk into it, new portal is created at -33.5 in rock, trapping you inside (Carpathian mapgen). Managed to do it twice, so it is problem a potential problem. Engine 0.5.0
Note, above it is ocean.

default
default

@paramat
Copy link
Contributor

paramat commented Jun 29, 2019

This is expected and intentional. Not a bug.

The normal realm portal has a particular X, Z, it searches downwards for a suitable Y.
It can't be placed in mid-air, and for performance the test for a suitable placement position cannot move downwards in 1 node steps, instead it moves downwards in 16 node steps, so it will almost always be placed buried in solid nodes.
The portal cannot be placed in any volume that contains non-natural nodes (is_ground_content = false) to not grief player builds. This makes it even more likely the portal will be a little way underground.

The portal is placed with air nodes around it to create a space so it isn't embedded in stone.
It is expected that the player has a pickaxe to dig their way out, this is highly likely if they have built a portal and are exploring the nether. The player will not be trapped.

Note that MC also often places portals embedded in stone.

The code could be altered to first try to find a surface position, but if this surface position is unsuitable due to being near player builds, the portal will still move downwards into the ground, so this is unavoidable.

Any search for a suitable resting-on-surface or resting-on-cave-surface position will be somewhat complex, to avoid placement on a tiny floating island or narrow spike etc. which would be impractical or deadly to the player.
A portal room embedded underground is the safest and the most accessible for the player.

So i decided to start the placement position search at y = -16 as that, or a little below, is the most likely suitable position: Ground is almost always present there, it's below any lakes or seas, below most player builds.
Also, the search for non-natural nodes doesn't actually guarantee avoiding player builds, as a player build can be composed of only natural nodes (is_ground_content = true). So even more good reason to start the search a little way underground where player builds are more unlikely. Y = -16 seemed a reasonable compromise between safety and distance from surface.

Each placement position search has to search a volume of nodes for non-natural nodes, this is not lightweight, and many searches may happen if there a lot of underground player builds present. So the code has been written to avoid intensive procedures.

@Treer
Copy link
Collaborator

Treer commented Jun 30, 2019

thanks for this explanation

@CasimirKaPazi
Copy link

When you have a mapgen that generates many high mountains then the portals will be underground almost always. You then have to dig your way up some several hundred nodes. Sometimes they generate underwater - where it could just be moved 16 nodes up to the surface. This is extremely annoying.

This also isn't intended behavior. We don't intend to have portals surrounded by stone. What we want is to protect player builds, the other aspect is a side effect of picking a specific solution.

It could least not default to -16 when no place could be found, but some place close under the surface. I.e. search from 0 upwards until there is a surface, check for player buildings and when there are, move a few nodes down.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants