Schrodinger's Steve
Create a new flat world.
Build 2 Nether portals close to each other, Portal A and Portal B.
Make sure A is activated and B is deactivated.
Create a mechanism to toggle the portals, such that when a button is pressed, after sufficient delay to allow a person to use the previously activated portal before it is turned off, the portal that is currently on will turn off, and the portal which had been off will turn on.
If you hit the button and run through the portal in single player, when you attempt to return from the nether, you will come out at the location of the portal you originally used, even though it is no longer active. In my original test case, this placed me inside of a wall which I had to destroy to be able to move.
If however, you have multiple players, as long as one player remains in the overworld in proximity to the nether portals, when you come back to the overworld you will instead come out the portal which is currently active, which is the desired behavior which is not seen when playing single player.
This must be because in single player, when the only player is in the nether, overworld processes cease to execute, and thus the mechanism for swapping the portals does not actually happen until you go back to the overworld.
Solution would be to let certain types of processes continue instead of suspending them when the world changes.
If needed I can supply test world, video, images, etc.
Linked Issues
relates to5
MCPE-17304Pistons, droppers, dispensers, observers, & redstone lamps become stuck in an on or off-state & act like solid/opaque blocks until world-reloadFixedMCPE-13608Redstone components update when world is reloadedFixedMCPE-14508Nether portals duplicating one another nearbyFixedMCPE-17584nether issues with portals duplicating/moving/not workingCannot ReproduceMCPE-18722Observer misses events when the player is coming out of netherCannot ReproduceAttachments1
Created Issue:
Schrodinger's Steve
Create a new flat world.
Build 2 Nether portals close to each other, Portal A and Portal B.
Make sure A is activated and B is deactivated.
Create a mechanism to toggle the portals, such that when a button is pressed, after sufficient delay to allow a person to use the previously activated portal before it is turned off, the portal that is currently on will turn off, and the portal which had been off will turn on.If you hit the button and run through the portal in single player, when you attempt to return from the nether, you will come out at the location of the portal you originally used, even though it is no longer active.
If however, you have multiple players, as long as one player remains in the overworld in proximity to the nether portals, when you come back to the overworld you will instead come out the portal which is currently active, which is the desired behavior which is not seen when playing single player.
This must be because in single player, when the only player is in the nether overworld processes cease to execute, and thus the mechanism for swapping the portals does not actually happen until you go back to the overworld.
Solution would be to let certain types of processes continue instead of suspending them when the world changes.
If needed I can supply test world, video, images, etc.
Create a new flat world.
Build 2 Nether portals close to each other, Portal A and Portal B.
Make sure A is activated and B is deactivated.
Create a mechanism to toggle the portals, such that when a button is pressed, after sufficient delay to allow a person to use the previously activated portal before it is turned off, the portal that is currently on will turn off, and the portal which had been off will turn on.If you hit the button and run through the portal in single player, when you attempt to return from the nether, you will come out at the location of the portal you originally used, even though it is no longer active. In my original test case, this placed me inside of a wall which I had to destroy to be able to move.
If however, you have multiple players, as long as one player remains in the overworld in proximity to the nether portals, when you come back to the overworld you will instead come out the portal which is currently active, which is the desired behavior which is not seen when playing single player.
This must be because in single player, when the only player is in the nether overworld processes cease to execute, and thus the mechanism for swapping the portals does not actually happen until you go back to the overworld.
Solution would be to let certain types of processes continue instead of suspending them when the world changes.
If needed I can supply test world, video, images, etc.
Create a new flat world.
Build 2 Nether portals close to each other, Portal A and Portal B.
Make sure A is activated and B is deactivated.
Create a mechanism to toggle the portals, such that when a button is pressed, after sufficient delay to allow a person to use the previously activated portal before it is turned off, the portal that is currently on will turn off, and the portal which had been off will turn on.If you hit the button and run through the portal in single player, when you attempt to return from the nether, you will come out at the location of the portal you originally used, even though it is no longer active. In my original test case, this placed me inside of a wall which I had to destroy to be able to move.
If however, you have multiple players, as long as one player remains in the overworld in proximity to the nether portals, when you come back to the overworld you will instead come out the portal which is currently active, which is the desired behavior which is not seen when playing single player.
This must be because in single player, when the only player is in the nether, overworld processes cease to execute, and thus the mechanism for swapping the portals does not actually happen until you go back to the overworld.
Solution would be to let certain types of processes continue instead of suspending them when the world changes.
If needed I can supply test world, video, images, etc.
relates to
![[Mojang] Mega_Spud (Jay Wells)](../../../data/avatars/users/92696.png){kind=small}
relates to
relates to
relates to
Tested moving observer to nether, which causes the same faulty behavior as in single player mode. So if a tree falls in the forest, but no one is there to hear it, it doesn't make a sound until they come back.
Affects 0.17.0.2
Affects 1.0.0.0
Here's a test world
Interesting notes on test world...
Failure behavior almost always results in something having a bugged state. So far I've managed to bug pressure plates, water bucket dropper state, and Redstone flip flop / portal selection parity. What gets bugged depends on the exact timing between activating the pressure plate and entering the nether portal. Bugged states are persistent. When the pressure plates bug, they get stuck in an activated state and can no longer detect pressure afterwards. Exiting the game and reentering does not fix them. They must be destroyed and replaced to work again. When the water bugs, activating the circuit again or using the empty bucket to pick the water up manually both result in the water going away but the bucket remaining empty.
Some ideas on fixing this...
Have each chunk that's loaded into memory have an in memory variable called lng_chunk_activity_count. When processes occur within the chunk during a tick, increase this number. When you would normally unload a chunk, check this number over a window of ticks and don't unload the chunk until the number stops increasing.
Another possibility would be to create a virtual player called observer. Have observer not show on the player list or generate any chat log activity. Place observer in chunks temporarily to keep them active, such as in the case of a someone using a nether portal.
Affects 1.0.0.1
Affects 1.0.0.2
Affects 1.0.0.7
How do I get this confirmed?
Affects 1.0.0.16
Jason Welbourne, since you are the ticket creator, you have the ability to edit the list of affected versions yourself. Also, an issue is "confirmed" when a moderator/dev tests the bug and is able to confirm that it is indeed happening.
Thanks, anything I can do to speed that along?
The reason you come out of the nether portal that has been disabled is because it wasn't disabled when you first came through it. You see, when you enter the portal, the redstone mechanism to disable the portal doesn't activate until you return, as the chunks containing the mechanism are unloaded. As you return, you return through the same portal through which you came, and it is disabled moments later (during the loading screen when travelling between dimensions). So the portal WAS activated when you returned through it, but was disabled pretty much immediately after you returned due to the redstone mechanism not being able to finish its job before you entered the Nether in the first place. (Hopefully I explained all that properly.) This chunk-unloading-redstone behavior is works as intended, so I'm closing this issue.
Please, I'm begging you, change this back. I have several reasons I feel this is not works as intended behavior. Your assessment of what happens is not accurate. The portal doesn't deactivate after you come back. The Redstone doesn't finish running. Instead it gets stuck in a bugged state which requires destroying components and replacing them in order to restore them to working order. Also, it works as intended when a second player is connected to the same game and standing close to the Redstone. Shouldn't Redstone behavior be consistent between single player and multi player? Marking this as works as intended when it is broken and inconsistent after the bug has sat here unconfirmed for months is a slap in the face.
I looked into this, and you're partially right and wrong.
Just as SuperGeniusZeb said it is correct, intended and designed for you to come back to the same portal you walked into. This is because when you changed dimension the chunk stopped ticking. When you go back the machine will continue ticking and thus disable the portal.
However, the bug that you mentioned in the previous comment did interest me so I tested this (thanks for the attached map!). Some redstone components (in this case it seems to be affecting the pressure plates) isn't serialized correctly. When you get back to the chunk the pressure plates might be locked in a "pressed" state. You have to rebuild them to get it working again. I'm working on a fix for this right now.
Even though the pressure plates and various other things are broken, the bug that you describe in the bug description is actually working as intended.
Other Redstone components becoming 'locked ' is described at
MCPE-17304, I've added a link to this ticket.The blocks that should get fixed by my fix are: Pressure plate, tripwire, redstone lamp, detector rail and buttons.
It's also possible to bug the dispenser state causing water to become stuck that later will cease to exist if you try to pick it up with a bucket manually, but can never be picked up by the dispenser + empty bucket until it is cleared.
Regarding the works as intended, there is still the matter of this device operating completely different with two players than it does with 1. I don't dispute that unloaded chunks shouldn't tick. I dispute the necessity of unloading a chunk that has active Redstone circuitry ticking. Just keep the chunk in memory a few more ticks until it goes idle, and then release it. That would make the behavior consistent between single player and multi player and allow me to finish building a safe room.
Yes, I noticed that. My fix could also fix that issue with dispensers and droppers. I didn't do extensive testing on those to see that this was the actual problem in your machine, but they did have the same problems as pressure plates.
That is indeed a problem depending on what you want to do, but it's not a bug. We have for a very long time discussed how we want redstone to work in regards of unloaded chunks, but so far we haven't come to a conclusion. Having all redstone machines keep chunks loaded could result in performance degradation. In your scenario there are many things one needs to choose: How many chunks should be kept loaded? For how long? Should only redstone tick or should everything else as well (fire spreading, water flowing, mobs running around attacking, etc)? Some might use a portal as a "safe room" from when shit hits the fan, if we keep ticking their chunks it might ruin their worlds... Maybe that's a bit far fetched, but it could happen.
The Redstone tick issue impacts a variety of machines that people may want to build. There's people building circuits so complex they can't even fit in the 8 closest chunks they are standing in. If detecting idle adds too much overhead to a main loop then create a special block that can force a chuck to stay open if it is powered or some sort of mechanism that can transfer control of this process to the user. I'm my case I only need a few ticks, but other people might like to build circuits that they can power on and off sections of as needed, for arbitrary lengths of time. Right now, that requires walking around.
All I want is a room that can't be broken into. I've stretched the limits of my creativity getting this far. Now all that stands between me and my goal is a dozen ticks or so.
Yes, we know this.
You could make the off-switch in the nether instead of in the overworld.