jo
Assigned
Reported
Comments
Ugh, been too long out of a shop... 'verify' is usually for fixes. :/
Sadly, 1.9-pre4 is still affected by summoned falling sand creating invisible blocks.
I agree: f3+a would be expected to act as a workaround for ghost blocks as well as ghost chunk errors.
Why it helps one and not the other... perhaps the ghost blocks are weirder than expected?
But - still not revealing ghost blocks as of 1.9pre4.
confirmed for 1.9 pre 4.
I do not suspect lag, as the block stays gone to the client, cannot be struck, and F3+A does not help, strangely.
Attempting to place a block/torch/etc... in the location will cause the block to appear, as described.
Dying, warping, teleporting away will also recover the block.
Still seeing it as of 1.9 pre 2, I get it using a fast shovel, beating up a mix of dirt and sand or gravel on a low-ping or local vanilla server, survival, no commands are needed.
Important:
As far as whether the proposed removal of those two offsets restores original pre-1.8 behaviour, I no longer have an opinion, as I didn't realize the distance of the offset had been limited to one due to having missed a few remarks in the history. My bad - though I blame unfamiliarity with jira. 😛
Less helpful to the bug, but still relevant:
– I very much doubt the very original behaviour was 'expected'...
I'm sorry I didn't spend more lines explaining this so it was more obvious - I was referring to releases prior to 1.8, though I'm not clear when the timer kicked in fully. We certainly used to get teleported back if we dawdled in the portal. 'Expected' is in quotes because it is very hard to pin down any sort of objective notion of what different players will find intuitive.
– That block isn't cleared except in the last-resort case where the game couldn't find any valid location to place a portal. Nor would it be the case for built portals
two things:
1) If the portal generation code is not creating portals safely enough given the intent to have the nether be dangeous - then that is presumably unexpected behaviour, given dinnerbone's comments and changes as above. If the new intended behaviour is to place players in front of the portal, then the issue is now with the portal generation code not finding reasonable places to generate, clear enough space, or build additional floor.
2) I don't think built portals matter much - if the behaviour of portals is known to teleport players +/-1 block in the direction the portal is facing, then players will build portals such that this is good. Bringing portals from previous versions forward really happens, but - outside of portals in front of walls now being verbotten, reasonably built portals should not be dropping people through the floor now.
Finally:
I support stopping teleporting players into the portal square, as it frees up portal mechanics to allow other shapes and sizes of portal, ideally supporting teleporting into borderless portals, portals with target destinations in their extra info etc... or even other fancier portal dynamic patterns (different moduli, worlds, near portal finding, etc...
I'm going to be shooting for seed + replication script from here on in. Thanks for your patience.
Sorry to clutter this further, but - I very much doubt the very original behaviour was 'expected' - as after travelling through a portal, one would in short order be teleported back as one had been ported into a portal square. Also my apologies if it seems a hair out of the flow, but I accidentally failed to post this the other night, and tried to restore it to the current context.
Expected behaviour from portals in other games is that they port one to a destination upon entry (and typically must be re-entered in order to trigger that), or - they port one to a destination very near to another portal, rather than in it.
The current issue, which I do agree is quite serious, is not fixed by merely unrolling the last change; the last change was very likely an attempt to produce expected behaviour.
The previous code mostly worked as the player needed to be quite 'into' the portal tile to trigger it, and the portal generation would clear the volume in directly in front of the portal, produce a little lip if needed, etc... the current code does not create enough of a lip, nor clear enough volume, on portal generation to account for the new player location chosen, and it makes no attempt to deal with grandfathered tight-fitting portals from old worlds.
unrolling the change might be a quick fix - but part of the delay might well be a significant rewrite of the portal code, other nearby issues which aren't public, etc... and how that got scheduled with all the other important work is not my place to guess.
Still - if it isn't dependent on much else - my guess is that there is a safe place to port the player to: namingly the centre of the block directly in front of the portal block chosen, as that will be both cleared and floored by current portalgen, if needed, and also puts the player out of the portal itself. This location was likely the intent of the last change, but it was overshot by some amount. Also - as is clear from gzurti's attachments, the last change was larger and would drop the player well away from the portal in some edge cases.
In short, we don't know the extent of the previous changes, nor the full set of issues they were attempting to resolve.
Suppose this is related to the falling damage issue. My impression was that it used to be that with a just-generated portal - they would port the player to the nearest portal block within certain constraint. But this is hairy - from below this might be a block at ground level, and from above this would be a block with the player's head in the obsidian, or alternately, it might be a block at head level, but from the other side a block with the player's feet in the rock. combined with falling damage for simply porting so the player's head touched the top of the portal - fixup was needed already. add in the 'last portal used won't resend hack' and it's getting ugly. If an attempt was made to clean up the behaviour such that portals could be created that did not require the same obsidian shell, then it would start getting weird fast.
However it seems clear given the tests we have at hand, that the two expression change to the code suggested by removing the addition of those values from the player position, is not sufficient to fix all the cases where players are currently ported to odd and lethal locations. Also presumably it is not sufficient to fix whatever issue that addition fixed (say, the falling damage?).
Torabi beat me to the punch with the reminder I agree with so strongly: the best way for us to help from here, without knowing the full suite of tests and constraints the portals need to adhere to, is to identify apparent odd behaviour and try to help replicate it by finding seeds, short descriptions, and screenshots that make it easy for the devs to confirm unexpected behaviour and test potential fixes.
peace and lucks, dfj.
Verified for 1.11.2.
Reminder: getting stuck in the block and suffocating is no fun, the block is not minable as it's not present on the client... it can be cleared by trying to place a new block in that location, mind - or by logging in and out. f3+a does not re-download the block, as again - it is not known to the client.