Matt S
- jocopa3
- jocopa3
- America/Vancouver
- Yes
- No
MCPE-6650
When I play a world
andgo to the home screen without firstclosing the world, the game still runs in the background. If I leave the app running in the background without closing it for too long, my battery is drained quickly, and my phonewilleasily overheat, eventhoughthe appis in the background.I am using a Galaxy S5.
When I play a world, then go to the home screen without first leaving the world, the game still runs in the background. If I leave the app running in the background without closing it for too long, my battery is drained quickly, and my phone can easily overheat, even if I'm in another app or turn off the screen.
I am using a Galaxy S5 on Android 4.4.2.
When I play a world, then go to the home screen without first leaving the world, the game still runs in the background. If I leave the app running in the background without closing it for too long, my battery is drained quickly, and my phone can easily overheat, even if I'm in another app or turn off the screen. I can also hear game sounds even when the screen is off.
I am using a Galaxy S5 on Android 4.4.2.
After the 0.13.0 update, MCPE displays a green screen after the splash logo. I can still interact with menu options despite the green screen. If I manage to load up a world, the world loads and works fine, but all 2D UI isn't rendered (ex: sign text, hotbar, crosshair, etc).
This only happens on one of my PC's, and 0.13.0 works fine on all my other computers. The affected PC is using 2 Nvidia GTX 980's, and the Nvidia driver is version 358.91. The issue does not appear to go away after updating drivers.
This issue
sis different from MCPE-10402, since this happens immediately after the splash screen and not upon loading a world. This issue also appeared only after the 0.13.0 update, and didn't exist in 0.12.x
Redstone torchesturn offwhen the block they are attached to has a change in signal for 1.5 ticks (except for short-circuits). In PE however, torches toggle when the block they're attached to has a change of signal of only 1 tick. The video demonstrates two examples of this in both PE (MCW10) and PC.In PC, redstone torches change state when the block they are attached to has a change in signal for 1.5 ticks (except for short-circuits). In PE however, torches toggle when the block they're attached to has a change of signal of only 1 tick. The video demonstrates two examples of this in both PE (MCW10) and PC.
In PC, redstone torches change state when the block they are attached to has a change in signal for 1.5 ticks (except for short-circuit
s). In PE however, torchestoggle when the block they're attached to has achange of signalof only 1 tick. The video demonstrates two examples of this in both PE (MCW10) and PC.In PC, redstone torches change state when the block they are attached to has a change in signal for 1.5 ticks (except for when that change in state is caused by the redstone torch itself, i.e. a short-circuit). In PE however, torches change state when the block they're attached to has a signal change of only 1 tick. The video demonstrates two examples of this in both PE (MCW10) and PC.
In PC, redstone torches change state when the block they are attached to has a change in signal
for 1.5ticks(except for when that change in state is caused by the redstone torch itself, i.e. a short-circuit). In PE however, torches change state when the block they're attached to has a signal change ofonly1 tick. The video demonstrates two examples of this in both PE (MCW10) and PC.In PC, redstone torches change state when the block they are attached to has a change in signal longer than 1 tick (except for when that change in state is caused by the redstone torch itself, i.e. a short-circuit). In PE however, torches can change state when the block they're attached to has a signal change of 1 tick. The video demonstrates two examples of this in both PE (MCW10) and PC.
https://www.youtube.com/watch?v=8vNeAsOgeyk
To fix: torches should ignore any change in signal to their attachment block that is exactly 1 game tick or shorter (50ms or shorter), and only change state when the change in signal is longer than 1 tick. That way, a pulse that is 1.5 ticks or 2 ticks will affect a the torch, but a pulse that is exactly 1 tick or shorter won't, which is how redstone torches in the PC edition work.
Edit: updated info, since redstone torches in the PC edition ignore any pulse that is 1 game tick or shorter and respond to any pulse longer than 1 tick, not just 1.5 ticks.
If a piece of redstone dust is being powered directly by some sort of power source (torches, levers, blocks, etc.), it cannot power any other blocks even if it leads directly in to them.
In attachment PEa, a line of redstone is being powered by a block placed next to the left redstone dust. The left torch doesn't turn off, despite there being redstone leading directly into the block it's attached to; however, the other torch on the right does turn off. In attachment PCa is the same circuit in PC, notice how both torches turn off.
In the attachment PEb, the same circuit is being powered by a redstone torch from above. Once again, the torch on the left where the redstone is being powered doesn't turn off, where the torch on the right does. Attachment PCb shows the same circuit in PC for reference.
In attachment PEc1 and PEc2 is a common half-adder design. The three torches on the top should be turned off since the redstone dust next to them is powered; however, the torches are still on. PCc1 and PCc2 show the same half-adder design, but the three redstone torches on the top are off.
An redstone torch that's turned off will block a redstone signal from traveling up blocks. In attachment PE1, the redstone on top of the iron block is turned off
, whereas in PC1,the redstone on top the iron blockison.An redstone torch that's turned off will block a redstone signal from traveling up blocks. In attachment PE1, the redstone on top of the iron block is turned off. For reference, in attachment PC1 is the same circuit in the PC version, with the redstone on top the iron block being on.
Matt S did your screen resolution and/or refresh rate change when you got the new monitor? Others, perhaps try changing the screen resolution and/or refresh rate to see what happens. Just guessing, but as you can see, there haven't been many ideas, so I thought I'd try.
Matt S is right. This is "Works As Intended".
Thank you Matt S for your confirmation. Changed the confirmation status to "Confirmed".
Water and leaf animations in shaders packs are now frozen. Galaxy s7
Edit by PHO:
Steps to reproduce:
- Install SEUS PE "Ultra" or "1.1 Test".
- Look at water, leaves, grass, or vines.
What I expect to happen:
Those things are rendered with waving animation. Actually on ≦ 1.0.9 the animation was working correctly.
What actually happens:
They don't wave at all, completely still. uniform highp float TIME in renderchunk.fragment seems not to be updated along the time.
See also the comment from Matt S below.
I can confirm this happens on my Galaxy S5. It occurs when you enter a world and do not leave the world before leaving the app.
@AMAN4700 No, this does not work as it does in PC (if this is intended, it's a pretty awful change). Here is the same circuit in PC, with a daylight sensor set to detect darkness on top; notice the lamps are ON not off: http://i.imgur.com/1P1DU5G.png
Here is that same exact circuit again in PE. It's night time, the daylight sensor is set to detect darkness, and yet the lamps don't turn on: http://i.imgur.com/rr73zCZ.png
This is a bug, and these screenshots confirm it.
They're all the result of the same glitch, so
MCPE-11871thus duplicatesMCPE-11353.This is exactly what's going on. Those really compact and impossible clocks where two torches are on the same block only work because the 1-tick pulse created by one torch is short enough to change the state of the other torch.
So this is what was going on... I wrote about an issue with my GTX 980's (
MCPE-11910) but I couldn't find a crash log from the event viewer. Sadly I can't disable my 980's to play Minecraft because my CPU doesn't have on-board graphics, so I'm stuck with playing on a laptop instead...This works as intended. There's a limit on the FOV to prevent it from going too high and causing graphical glitches. The FOV is capped at 110, and the highest you can set the FOV in the settings is 110.
The daylight sensor measures daylight; when inverted, it measures the lack of daylight. What you describe is how the daylight sensor is supposed to work. The inverted daylight sensor will still give off a redstone signal during the morning and afternoon.
Examples:
Inverted daylight sensor during the morning: http://i.imgur.com/XJx1UtT.jpg
Daylight sensor during the morning: http://i.imgur.com/CFJU1x2.jpg
This only happens if you place the lever while facing in a certain direction. If you turn 90 degrees in either direction then try to place the lever, it works just fine. Still a bug.
I had a very similar bug for quite some time (
MCPE-11910), but the game would still launch instead of crashing and was still "playable" to some very limited extent. After the logo, the screen would go green, and all 2D UI would fail to render. However, after buying a new monitor, it somehow fixed itself. I tried everything to fix the issue beforehand, from changing video settings in Nvidia Control panel to using only one monitor at a time, but I couldn't find a fix. I don't know why using a new monitor suddenly fixed the issue when driver updates and video settings didn't.It looks like the texture was overwritten with other memory, or Minecraft is reading the texture from the wrong section of memory. This sort of thing tends to be a bug with a driver since it happened when switching from one OpenGL context to another. If you can't reproduce it again, then it's likely just a driver bug, but if you can reproduce it again, then it may be a bug with MCPE.
What Samsung device to you have?
I agree with PHO. I clearly demonstrated in the YouTube video that there is a difference in how redstone torches work in PC and Pocket Edition, yet this issue is marked as "Works As Intended." If the intention is to get redstone working the same in PE as it does in PC, then this is certainly not working as intended, and is still a bug.
The problem somehow went away after using a new monitor. I still do not know what the actual cause behind the issue was, or what exactly fixed it. It seems related to MCPE because this issue happened immediately after updating to 0.13.0 and launching game, where just prior to updating the game still worked fine.
This bug still exists in 0.14.0, and it still does not work as intended.
A quick note for future reference: enderpearls are in the 0.14.0 beta, but you cannot get them in game. They have an item class:
And they also have a thrown entity class with a working teleport feature:
From the game binary, it looks as though enderpearls are implemented and do work; however they don't associate them with an item ID so there is no way to obtain it in-game, not even with an inventory editor.
While I don't know much about how the game is doing input handling, my guess is the input queue is still holding some input events that a are prematurely freed or released. Many games and applications would check for this situation to prevent exactly this kind of error from occurring, or limit the size of the input queue to reduce overall load.
Can confirm.
For comparison, here is the same setup in the PC version: http://i.imgur.com/xcq00JJ.png
And here is the setup again in Minecraft Win10: http://i.imgur.com/XnDmflw.png
Does clicking stop/freeze the game even when using an external mouse?
Also, if it ever crashes the game again, it might be useful to post the crash report. You can find the crash report by doing the following:
Here is an example screenshot of what a Minecraft crash log might look like in Event Viewer: http://i.imgur.com/4QyAvf0.png
From the crash log, it looks like the error was an UnhandledException that occurred somewhere in the OptionsItem::render function. The error happens at or before the call to destroy string. Not sure why it happens, but hopefully that info is useful to staff.
One last thing worth mentioning:
The reason for this is because of floating-point precision. This can be remedied by using high precision floats in the fragment shader for certain variables, though this fix doesn't work for older devices that don't support highp floats in fragment shaders.
Here is an example screenshot after applying this fix: http://i.imgur.com/lUcEyro.png
Oddly enough, this also fixes the crash when viewing end portals/gateways in non-fancy mode.
This is a duplicate of
MCPE-11418. The developers have stated before that they have no intention of fixing issues that occur when teleporting past a certain distance. Under normal playing conditions, there is no way this would be a valid issue for the vast majority of players; it's highly unrealistic to expect players to reach 4 million blocks from the origin in normal play without explicitly teleporting to those locations. On top of that, there is no easy or practical way to fix the issue; it's a limitation of the both the platform the game runs on and the game engine itself.Attached a crash log containing the main stack trace. Device is a rooted Samsung Galaxy S5 on Android 4.4.2. The error stems from line 178 of the MainActivity.java file in the onCreate method; the exception is:
This same issue still occurs with the 1.0.5.3 beta build. Reinstalling the app doesn't fix the issue, nor does clearing cache or data.
Added a second crashlog from 1.0.5.3 with unrelated processes filtered out. Should contain a bit more information about the crash than the first log.
This issue seems to be fixed in 1.0.5.13.
This seems to be fixed in 1.0.5. I'm not sure which build fixed it.
It seems the game no longer updates the TIME uniform; its value is always 0. Consequently, any shaders which rely on that uniform for animation appear "frozen".
The dx, dy, and dz target selectors are not currently supported. As-of 1.0.5 and 1.1, the supported target selectors are: