Jo

still happening, ruining bases and destroying villages. should've been patched by now

I've literally checked it again this evening and on the first page, the cave dweller mod picture comes up. Thanks for your comments, that's a very valid point. I think it needs much better monitoring and technology an to provide customers with better tools to customize their preferences, particularly as we are talking about huge technology companies. I’ll be notifying several Internet company organisations of this issue as well.

Try creating an entirely new instance of the server, a fresh install and fresh world to see if you can connect to that. What nations are people connecting from?

see above comments for work around? what platform is the 6th person connecting via,

remember to start your server after resetting, I forgot to

:c try creating a completely new server world just to check if that works? check the port address too, try different ones

continuing from above: if renting private server, make sure you download backups to your client side machines. Backups created on server hosting services will be deleted when server is reset. Use FTP to download backups of world files

workaround/fix - server needs a full reset. For some reason there is either an ID or update number issue which despite updating the server doesn't seem to align. Server owner needs to create backup of world, server.properties, world zip or whole server - anything of importance to you. Then reset entire server or delete server and reload. Then load back in backups of previous world and config files server.properties and whitelists etc. Backup is essential before reset.

same problem on console trying to connect to private bedrock server

unresolved, affecting both java and bedrock

I think this was just patched in the latest 1.17 snapshot

Both dosn't work!

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.

confirmed for 1.9pre3

It is a (less than useful) workaround for the some of the ghost blocks (MC-72248, MC-5694) and strange F3+A behaviour (MC-96142).

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.

Yes, my problem was MC-5694. 🙂

I then took the time to verify our issue here, MC-72248, for 1.9pre4, as 'thanks'. 😛

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.