Wleklik, Patrik
- GameJunkiePat
- gamejunkiepat
- Europe/Stockholm
- Yes
- No
MC-136612
It is possible to shoot arrows and Tridents through nether portals.
Here goes your requested formallity:
what I expected:
Arrwors and Tridents get "stuck" in netherportals because they have a hitbox like every other block.What happend:
Arrows and tridents can pass throu nether portal blockssteps to recreate:
1. build a Netherportal
2. Grab a bow & arrow and/or a trident
3. hit F3
4. aim for the borders of the block (the black outline shown when aiming at a block)
5, make sure you can change the outlined block by only moving the mouse by one or two pixels.
6. shoot. You should observe that the arrow/trident passes through the portal, insted of getting "stuck" like it would when you aim for the middle of the block.
This bug includes Nether portals, Arrows and Tridents. It is possible to throw/shoot them through a nether portal by aiming at the block borders of the netherportalblocks.shoot tridents & arrwos through netherportals
to reproduce:
coppy"coppy" my setup as discribed below:I encounterd this bug while I wtied to make a datapack which sorts all players by distance to a given entity. I did this by creating 2 functions:
1. run.mcfunction
- scoreboard players set count distancecount 0
- execute as @a[sort=nearest] run function distancesort:sort
2. sort.mcfunction
- scoreboard players ass count distancecount 1
- scoreboard players operation @s distonacecount = count distancecount
to start I use this command:
- execute as @e[name=freeze] at @s run function distancesort:run
- "freeze" is the only armorstand in the map. And the only entity with that name.
explination:
with the start command I sett the postition of where the commands shall be executed to the position of the "freeze" armorstand.
Then the fakeplayers "count" distancesort is set to 0.
The execute then calls the "sort" function for every player in the wrld, because of the selector "@a[sort=nearest]" the player closest to the armorstand should call the function first.
When a player calls/runs the "sort" function, he increases "count" distancesort by 1. And then sets "count" distancesort to his own distancesort scoreboard.The problem:
when using the selector "@a[sort=nearest]" the player furthest away from the armorstand runs the function first.
And when using the selector "@a[sort=furthest]" the player nearest to the armorstand runs the function first.
Basicly the selector doese the opposite of what is says.2018-9-11_14.25.51 was taken with "@a[sort=nearest]"
2018-9-11_14.26.07 was taken with "@a[sort=furthest]"
the player with the rainbow-skin is "IrgendwasMitPat"
A minor bug, not gamebreaking in any way I know of.
It showcases the same effect. (My report also proves that the reversing also happens when calling functions)
Tanks for your time!
I have encounterd the same effect while trying to make a datapack which sorts the players by distance to a given entity.