[MCPE-18570] Schrodinger's Steve Created: 19/Nov/16 Updated: 17/Jan/17 Resolved: 13/Jan/17 |
|
| Status: | Resolved |
| Project: | Minecraft (Bedrock codebase) |
| Component/s: | None |
| Affects Version/s: | 0.17.0.2, 0.16.2, 1.0.0.0, 1.0.0.1, 1.0.0.2, 1.0.0.7, 1.0.0 |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Jason Welbourne | ||
| Resolution: | Works As Intended | Votes: | 1 |
| Labels: | world-loading | ||
| Attachments: |
|
||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||
| Confirmation Status: | Unconfirmed | ||||||||||||||||||||||||
| Platform: | Phone - Android - LG Nexus 5 | ||||||||||||||||||||||||
| Description |
|
Create a new flat world. 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. |
| Comments |
| Comment by [Mojang] Tomas Alaeus [ 17/Jan/17 ] |
Yes, we know this.
You could make the off-switch in the nether instead of in the overworld. |
| Comment by Jason Welbourne [ 16/Jan/17 ] |
|
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. |
| Comment by [Mojang] Tomas Alaeus [ 16/Jan/17 ] |
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. |
| Comment by Jason Welbourne [ 13/Jan/17 ] |
|
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. |
| Comment by [Mojang] Tomas Alaeus [ 13/Jan/17 ] |
|
The blocks that should get fixed by my fix are: Pressure plate, tripwire, redstone lamp, detector rail and buttons. |
| Comment by [Mojang] Mega_Spud (Jay Wells) [ 13/Jan/17 ] |
|
Other Redstone components becoming 'locked ' is described at |
| Comment by [Mojang] Tomas Alaeus [ 13/Jan/17 ] |
|
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. |
| Comment by Jason Welbourne [ 13/Jan/17 ] |
|
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. |
| Comment by Zeb [ 13/Jan/17 ] |
|
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. |
| Comment by Jason Welbourne [ 29/Dec/16 ] |
|
Thanks, anything I can do to speed that along? |
| Comment by Zeb [ 20/Dec/16 ] |
|
TheOrganicGypsy, 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. |
| Comment by Jason Welbourne [ 19/Dec/16 ] |
|
Affects 1.0.0.16 |
| Comment by Jason Welbourne [ 12/Dec/16 ] |
|
How do I get this confirmed? |
| Comment by Jason Welbourne [ 12/Dec/16 ] |
|
Affects 1.0.0.7 |
| Comment by Jason Welbourne [ 10/Dec/16 ] |
|
Affects 1.0.0.2 |
| Comment by Jason Welbourne [ 08/Dec/16 ] |
|
Affects 1.0.0.1 |
| Comment by Jason Welbourne [ 06/Dec/16 ] |
|
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. |
| Comment by Jason Welbourne [ 06/Dec/16 ] |
|
Interesting notes on test world... |
| Comment by Jason Welbourne [ 06/Dec/16 ] |
|
Here's a test world |
| Comment by Jason Welbourne [ 02/Dec/16 ] |
|
Affects 1.0.0.0 |
| Comment by Jason Welbourne [ 30/Nov/16 ] |
|
Affects 0.17.0.2 |
| Comment by Jason Welbourne [ 20/Nov/16 ] |
|
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. |