Jason Welbourne
- TheOrganicGypsy
- theorganicgypsy
- America/Chicago
- Yes
- No
MCPE-3729
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" MCPE-13270. I've seen this several times but haven't reported because I couldn't find a reliable way to reproduce this. Upon reloading the world, activated comparators may either
- Continue to emit power as expected, or
- Become inactive for a very short time, probably even less than 1 redstone tick, and then activates again (
MCPE-13270), or - Look visually activated but not actually emit power until they receive a block update.
As far as I know, the third case, reported by this issue, has the lowest probability to happen. I've not tested Jason Welbourne's memory cell but will do later.
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.
I was going to say that I have never seen the other two scenarios, but I have a world that may demonstrate all 3 in a way that makes it easier to figure out the circumstances and mechanics of each. Is it ok to post a world zip?
The screenshots are kind of random but I was trying to locate each area that was misbehaving at startup. In this case, the isnt critical. The device starts out in a bugged state, but once it is properly used the first time, everything corrects and stays that way until the game is reloaded again later. There are, however, some builds that I have had to backburner because this issue is keeping me from implementing persistant analog memory short of converting everything to binary for persistence and back into the analog circuit on world load.
A tour of the different issues:
1) At the large displays, on world load, they are always blank, no matter what their state was prior to closing the world.
2) A few seconds after the game is loaded, a pulse comes down the input line turning most of the display on, almost entirely at 15 signal strength, but occasionally i see lines that are 12-14 and there are often lines that are unpowered.
3) The display retains these junk values until the button is pressed to send them correct values.
4) The junk value pulse originates from the circuit behind the control panel with all the item frames and the button
5) Those memory cells reset high on world load vs resetting off on world load like the display. I think this is because of the comparator chain that adds the two item cell values. On world load, the final comparator in that group of 5 is supposed to be outputting (15-Side input). I think comparators dont parse their side for the first ticks after load, so it outputs 15 initially, which sets all of the memory cells to that value, because they can be increased without a reset but not decreased. So they get 15 for atleast 2 ticks and get stuck there. (If it was just 1 tick, they would oscillate in a mixed state) When the button is pressed, they all are forecfully reset before being used to send data, so the issue doesn't propagate beyond the interval between startup and first use.
6) Regardless of what they are set to, the pulse shouldnt be emitted because the whole memory system is gated with another comparator so that all the values can be emitted simultaneously. The side signal should be 15 at startup, and at all times after except for 1 tick some fixed number of ticks after the button is pressed.
So I see comparators in subtraction mode ignoring their side input for some window after startup. It could be because the signal has not been constructed yet, or because they arent yet listening.
Comparators in either mode also seem to lose some ticks at startup, which is sufficient to destabalize a memory cell.
This issue still impacts 0.15.4 on android
I have built an empty flat world with a minimal test case for this issue. Will be happy to upload if it will help.
Also, fixing this issue should be pretty easy. The game is rendering the Redstone as if the state is stored properly, so the correct data is there somewhere. Just add a loop at the end of world load to look for these circuits and manually set their signal strength to the value that's being rendered. If it isn't being solved because that solution lacks the genericity to satisfy some sort of intellectual finesse, then yall are really just holding back features for the wrong reasons.
Effects 0.15.6
Some tentative testing on 0.15.90 build 1 seems to have this issue fully resolved. I was also unable to recreate the issue David mendenhall described.
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.
I've had this issue on several devices. After waiting for a while with no progress, I force closed minecraft, renamed my whole games folder, and then relaunched minecraft. Using a file explorer, you can watch as the minecraft process creates a new games folder and populates it. On some devices, it will eventually start. On others it has gone 10 minutes without ever starting.
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
Thanks, anything I can do to speed that along?
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.
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.
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.