Adrian Brightmoore
14 issues
Key
Summary
Status
Reporter
Assignee
Created
MC-5975![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
![[Mojang] Searge (Michael Stoyke)](../../../data/assets/gravatar/searge.png){kind=small}
MCPE-139618Vanilla BP JSON has inline comments, breaking json parsers and workflows
Works As Intended
Changed Description:
Attached schematic is a small ridiculous machine, but it exhibits a return of the double-state piston (extended and retracted) which halts the piston firing and has to be manually cleared by the player destroying the extended head.
<img src="https://dl.dropbox.com/u/54682869/Minecraft/Screenshots/2013-01-04_20.21.32.png"/>
Changed Description:
Attached schematic is a small ridiculous machine, but it exhibits a return of the double-state piston (extended and retracted) which halts the piston firing and has to be manually cleared by the player destroying the extended head.
<img src="https://dl.dropbox.com/u/54682869/Minecraft/Screenshots/2013-01-04_20.21.32.png"/>
Added Attachments:
Removed Attachments:
PistonDoubleHead1.schematic
Added Attachments:
Added Attachments:
Added Affects Versions: 1.18.2 Hotfix
@Adrian Brightmoore: Please append your description to MC-8471
Screen shot of the behaviour in-game
There is a new "TileID" tag. It is TAG_Int. It will carry the block ID for all blocks.
"Tile" is still available if TileID is not set, and the 0xFF masked value (lower byte) of TileID is copied into Tile (for backward compatibility)
A worked example is here, and on the original PMC page I linked in when reporting the issue:
https://dl.dropbox.com/u/54682869/Minecraft/Filters/Framination_v8s2.py
Here is an MCEdit view of the area where the crash occurred.
Reproduction steps in 1.15.0.8 RTX Beta:
This problem does not appear to be present in 1.16.057
Check the resource pack to see if there's a notification that your hardware is incompatible.
I have replicated the fault using G-Force Factory from the Marketplace by running TWO coaster copy operations at the same time as shown in this video here:
https://youtu.be/MZK-It8NeI4
I am reliably able to reproduce this in my game FLY SPY when I force creative and teleport the player around the gameplay area. The result is that the chunks around the player are not drawn. This may be related to complex chunk composition (number and type of blocks) AND when the system is under load (Win10 with disk recording of the play session on using the Windows game bar).
(NOTE the game doesn't attempt to teleport the player normally, this is troubleshooting/attempt to reproduce).
Please see this short video showing the problem being reproduced: https://twitter.com/abrightmoore/status/1204124424510664704?s=20
I am reliably able to reproduce this in my game FLY SPY when I force creative and teleport the player around the gameplay area. The result is that the chunks around the player are not drawn. This may be related to complex chunk composition (number and type of blocks) AND when the system is under load (Win10 with disk recording of the play session on using the Windows game bar).
(NOTE the game doesn't attempt to teleport the player normally, this is troubleshooting/attempt to reproduce).
Please see this short video showing the problem being reproduced: https://twitter.com/abrightmoore/status/1204124424510664704?s=20
May be duplicate with
MCPE-68842Duplicate
MCM-1015Bedrock 1.7.30 Retail still exhibits this problem and I don't believe this issue is either prioritised nor actioned so you're probably safe to leave it open rather than treat it as stale.
Confirmed still present with 1.18.2 Bedrock
Chunk block entities:
BlockEntity[universal_minecraft:command_block, -12, 65, 9]{NBTFile("":{utags: {isMovable: 1b, auto: 0b, Command: "", conditionMet: 0b, CustomName: "\"\"", ExecuteOnFirstTick: 0b, LPCommandMode: 0, LPCondionalMode: 0b, LPRedstoneMode: 0b, LastExecution: 0L, LastOutput: "", LastOutputParams: [], powered: 0b, SuccessCount: 0, TickDelay: 0, TrackOutput: 1b, Version: 17, UpdateLastExecution: 1b)}}}
{{}}
BlockEntity[universal_minecraft:command_block, -11, 65, 9]{NBTFile("":{utags: {isMovable: 1b, auto: 0b, Command: "", conditionMet: 0b, CustomName: "\"\"", ExecuteOnFirstTick: 0b, LPCommandMode: 0, LPCondionalMode: 0b, LPRedstoneMode: 0b, LastExecution: 0L, LastOutput: "", LastOutputParams: [], powered: 0b, SuccessCount: 0, TickDelay: 0, TrackOutput: 1b, Version: 17, UpdateLastExecution: 1b)}}}
{{}}
BlockEntity[universal_minecraft:command_block, -10, 65, 9]{NBTFile("":{utags: {isMovable: 1b, auto: 0b, Command: "", conditionMet: 0b, CustomName: "\"\"", ExecuteOnFirstTick: 1b, LPCommandMode: 0, LPCondionalMode: 0b, LPRedstoneMode: 0b, LastExecution: 0L, LastOutput: "", LastOutputParams: [], powered: 0b, SuccessCount: 0, TickDelay: 0, TrackOutput: 1b, Version: 17, UpdateLastExecution: 1b)}}}
I raised this as these are the reference implementations for content creators and so it may not be readily apparent what the impacts on that community are ahead of them relying on the Mojang RP.
For instance it busted some code on a project I'm working on forcing a workaround.
(Responding to Dhranios' comment)
I have a 1.19.51 world with the new "execute as" syntax in use when using the interactive commands via chat.
The same commands do not work when they are used in an mcfunction file, with a parsing error thrown as shown below
[Commands][warning]-Error on line 1: command failed to parse with error 'Syntax error: Unexpected "@e": at "xecute as >>@e<<[type=twf:"'
The problem is not resolved with enabling "upcoming creator features" inside the world.
If you are experiencing this behaviour, make sure your Behavior Pack manifest.json entry is set correctly to align with the new execute syntax:
"min_engine_version": [1, 19, 50]
Yes it's still an issue. You can see it on enchanted apple with a simple GitHub search on the current/latest BP at any time.
https://github.com/Mojang/bedrock-samples/search?q=%2F%2F+damage+resistance&type=
This idea that closing stale tickets is acceptable is ridiculous when the reported issue hasn't been looked at.