-
Notifications
You must be signed in to change notification settings - Fork 63
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
Cannot place MineCarts outside vanilla worldheight #495
Comments
Im wondering, can you place rails below y=-65? Do minecarts continue driving down the rails beyond this point or do they derail / error ? |
Rails can be placed below Jdk21.0.2_13.2024.03.02.-.12.37.19.05.mp4 |
Weird, this killing logic is set to be < worldBorderKillDistance (config.yml) which is set to 64 by default. This happens when the minecart is 64 blocks outside the world border (or height limits). This would mean it thinks the height limit is at y=0. If you edit config.yml worldBorderKillDistance and set it to something high like 1000, does the minecart still get killed? |
Changing this setting does indeed fix both issues of placing minecarts and riding them 👍 |
Id call it more a workaround than a fix, but good to know. That means this function is wrong. Which is just a Bukkit method (World getMinHeight()). It might be a bug in the server itself? |
Can you share this datapack? Maybe its a configuration in the pack that is wrong, causing bukkit to misreport the minimum build height |
Shared in the original post
|
You can also try restarting the server, as it does cache the world border information. Idk if you did? |
worldHeightRange: -256..256 |
Restarting returns the same result. Been an issue for a few weeks |
Can you also print WorldUtil.getBlockBorder(world)? When printing it shows the min/max bounds of the total space, where the y coordinate is interesting. Im thinking maybe the min y changes after the world initializes, but that a cached version remains in memory. |
{min={-29999984, 0, -29999984}, max={29999985, 256, 29999985}} |
so worldBorderKillDistance: 64 works purely because it happens to just cover this, which returns old pre 1.18 worldheight change to -64 |
Just in case, do you see any errors at startup? This could be explained by the region handler failing to initialize, as y=0 is a default. It might help to print the value of |
https://mclo.gs/ITCmpHn log seems to not contain any errors no |
And the instance type? |
new RegionHandlerSelector().getHandler(getWorld()); returns com.bergerkiller.bukkit.common.internal.logic.RegionHandler_Vanilla_1_17@7f960c3f |
new RegionHandlerSelector().getHandler(getWorld()).getMinHeight(getWorld()); so im guessing it caches the worldborder before it makes RegionInstance use 1.17 impl? thus no override applied |
I found the problem. Thanks for testing btw! Its doing RegionHandler.INSTANCE.getMinHeight(world), which is calling it on the selector not the actual implementation. There is no getMiNheight and geTMaxHeight impl in the selector, so they stay the default 0. |
https://ci.mg-dev.eu/job/BKCommonLib/1680/ that should do it |
can confirm it is fixed. thanks for the help 👍 |
Info
Please provide the following information:
Train_Carts: v1.20.4-v1 (build: 1518)
BKCommonLib: v1.20.4-v3 (build: 1673)
Server: git-Paper-430 (MC: 1.20.4)
Bug
Description
When a server has a datapack that extends the worldheight past the vanilla range, minecarts cannot be placed outside of the vanilla range.
For example a server extends the worldheight from 255->-64 to 255->-256
Any placement from -65 and below is cancelled
Expected behaviour
Place like normal
Actual behaviour
It is cancelled
Steps to reproduce
Add a datapack that extends the worldheight above or below the vanilla range.
Try and place a minecart
Additional Information
Video clip:
Video.uten.navn.mp4
Datapack example:
deeper_world.zip
The text was updated successfully, but these errors were encountered: