older addons (pre-1.26.0) used
"register_to_creative_menu": true,(or false) without error. if left in the json block file for 1.26+ they will throw the version error. While not spelled out in any change log, many older developers just had this in their blocks and had left it there. it was removed in:
experimental
Holiday Creator Features
Versioned
Added events
Removed is_experimental
Removed register_to_creative_menu
…so its just an oversight on the dev side for long time developers, like me.
Someone really messed up… Ive lost 12 hours today trying to chase this one down… here is one fix… dont have // notations in any “minecraft:crafting_items_catalog“ or you’ll get “minecraft:minecraft” in front of the menu entries AND blocks listed… Then there is the forcing of js version from 2.4 to 2.6 which Ive never seen happen on an update before…
01:15:07[Scripting][verbose]-Plugin [Phantom Frames v0.15.7] - promoted [@minecraft/server] from [2.4.0] to [2.6.0] requested by [Phantom Frames v0.15.7 - 1.0.0].
01:15:07[Scripting][verbose]-Plugin [Phantom Frames v0.15.7] - promoted [@minecraft/server-bindings] from [2.4.0] to [2.6.0] requested by [@minecraft/server - 2.4.0].
not going to enter all my logs…
01:36:49[Scripting][verbose]-Plugin Discovered [Phantom Frames v0.15.7] PackId [eab735c8-7ff8-41ef-81c5-250b4228741f_0.15.7] ModuleId [1dd0c10a-3066-4170-a304-a80bb889a8d1]
01:36:50[Blocks][error]-block_definitions | C:/Users/seeit/AppData/Roaming/Minecraft Bedrock/Users/Shared/games/com.mojang/development_behavior_packs/Phantom_Frames_BP_DEV | blocks/utility/frame_placeholder.json | Unexpected version for the loaded data
01:36:50[Blocks][error]-block_definitions | C:/Users/seeit/AppData/Roaming/Minecraft Bedrock/Users/Shared/games/com.mojang/development_behavior_packs/Phantom_Frames_BP_DEV | blocks/utility/frame_particles.json | Unexpected version for the loaded data
01:36:50[Blocks][error]-block_definitions | C:/Users/seeit/AppData/Roaming/Minecraft Bedrock/Users/Shared/games/com.mojang/development_behavior_packs/Phantom_Frames_BP_DEV | blocks/utility/frame_break.json | Unexpected version for the loaded data
01:36:50[Blocks][error]-block_definitions | C:/Users/seeit/AppData/Roaming/Minecraft Bedrock/Users/Shared/games/com.mojang/development_behavior_packs/Phantom_Frames_BP_DEV | blocks/nature/dyed/dyed_9.json | Unexpected version for the loaded data
01:36:50[Blocks][error]-block_definitions | C:/Users/seeit/AppData/Roaming/Minecraft Bedrock/Users/Shared/games/com.mojang/development_behavior_packs/Phantom_Frames_BP_DEV | blocks/nature/dyed/dyed_8.json | Unexpected version for the loaded data
01:36:50[Blocks][error]-block_definitions | C:/Users/seeit/AppData/Roaming/Minecraft Bedrock/Users/Shared/games/com.mojang/development_behavior_packs/Phantom_Frames_BP_DEV | blocks/nature/dyed/dyed_7.json | Unexpected version for the loaded data
01:36:50[Blocks][error]-block_definitions | C:/Users/seeit/AppData/Roaming/Minecraft Bedrock/Users/Shared/games/com.mojang/development_behavior_packs/Phantom_Frames_BP_DEV | blocks/nature/dyed/dyed_6.json | Unexpected version for the loaded data
01:36:50[Blocks][error]-block_definitions | C:/Users/seeit/AppData/Roaming/Minecraft Bedrock/Users/Shared/games/com.mojang/development_behavior_packs/Phantom_Frames_BP_DEV | blocks/nature/dyed/dyed_5.json | Unexpected version for the loaded data
01:36:50[Blocks][error]-block_definitions | C:/Users/seeit/AppData/Roaming/Minecraft Bedrock/Users/Shared/games/com.mojang/development_behavior_packs/Phantom_Frames_BP_DEV | blocks/nature/dyed/dyed_4.json | Unexpected version for the loaded data… (500 more)
the frustrating things is everything works perfectly fine, but the logs can stop spamming.
night_visionis still
nightVisonin loot tables but not listed. Likewise,
long_night_visionis still
long_nightVisionThis camel case discrepancy issue effects potion, splash_potion and lingering_potion variants.
From my testing, all other potion id’s listed on the Minecraft Wiki are listed in the correct case format.
Note: the generation of the potion in a loot table uses a function
"function": "set_potion",
and an id
"id": "long_nightVision"
If you use the listed one "night_vision", you get a water bottle.
Thank you v-baselod, I cannot share an unreleased addon that is intended for a store release to the open public without an NDA. However I will share a prerelease example with GoldenHelmet here on Jira to confirm my discovery. I’m also very busy preparing for release, so I do not have the bandwidth to create example addons for Mojang. I'm just one person. 🙂
As a developer courtesy... I've got a technique posted on twitter to remove/hide the new 1.21 status effects from a 3rd party entity. Twitter Link @TestPattern360 Cheers!
1.21 released without repair to the wind charge projectile errors. Maybe the hotfix ? Golden Helmet nailed the issue with the projectile. That is the issue.
Thanks GH .I'm guessing Spell effect will need to be added to the entity to remove any of these status effects, so I suppose I'll use the entity sensor to trigger the component group removing the Spell effect. Even as a closed report, I'll update this so future devs with a similar assumption will have a solution.
Needs reopen - While beta 1.21 was addressed, the 1.21.0 stable release today still is using an item grip, not a tool grip like the stick and blaze rod.
here is side by side comparison of my 3rd party item frame entities which allow me to force the grip on any item or block
I'll send it to Golden Helmet (Mod) via private. If I expose the unreleased addon to the public domain, I lose my copyright. I assure you, this is a legitimate issue and its perplexing (but not game breaking).
Here is a snippet of the family types. Skeletons pull in just fine.
"minecraft:rideable":{
"controlling_seat":0,
"crouching_skip_interact":false,
"family_types":["mob", "player", "other", "monster", "hostile", "passive", "neutral", "inanimate"],
"interact_text": "action.interact.sit.mount",
"pull_in_entities":true,
"rider_can_interact":false,
"seat_count":1,
"seats":{
// head swivel
"lock_rider_rotation":45,
"max_rider_count":1,
"min_rider_count":0,
"position":[0,0.5,0],
"rotate_rider_by":270
}
}The snow golems "seat" has been rotated, he points in the correct direction
Nevermind: my UI interface had not considered the crafter when I wrote it. Please close - this is my issue - not yours - apologies
Note from todays(4/19/23) Beta:
Introduced new entity filters "all_slots_empty" and "any_slot_empty" to allow searching for empty item slots in a designated equipment location (MCPE-153909)
Without context the filter is??
"test":"any_slot_empty",
"domain": "hand",
"subject": "self",
"operator": "==",
"value": trueor is it
"test":"all_slots_empty",
"domain": "all",
"subject": "self",
"operator": "==",
"value": trueSo the shortened code looks like
"test":"any_slot_empty",
"domain": "hand",
"value": trueand
"test":"all_slots_empty",
"value": trueDid I get that correct?
Addendum:
To recreate:
1) Set down chest, barrel, enderchest or shulker box (small chest inventory UI)
2) using a controller, rapidly try to fill the small chest inventory from player inventory using double click method (individual items or item stacks does not matter)
Expected result:
Each item or stack in player inventory enters the target container inventory in sequence, while players cursor follows player's chosen selection in player inventory.
Current result:
upon moving item or stack into the 3rd or forth container slot, player cursor focus will jump to slot one in container inventory and player will mis-click, sending whatever is in container slot one back into player inventory. Highly frustrating and easily recreated.
Additional: this focus stealing also happens if trying to double click items from container back into player inventory - container slot 1 will steal focus after the 3rd or 4th group/item moved.
I have only observed this behavior using a controller. Release 1.19.73 does not exhibit this behavior.
Possible reasons for such behavior.
Stacked or layered controls in the UI are not properly enumerated.
global variable is overriding default local variable
Slots are named using the same convention in both player inventory and small_chest containers. (object cross-code) and depending on the tick, one object takes target priority when it should be silent
"$focus_override_left_binding_type", "$focus_override_left", "$focus_override_right_binding_type","$focus_override_right" are invoked somehow.
seeing how focus always jumps to container slot 1 in my experiments, I'd say it's enumeration + a binding error. Thanks for all your hard work dev teams.
Speed of moving item(s) into the inventory does not matter. Focus is stolen, in multiple container grid locations, and defaults cursor back to slot one in the target container. This behavior is also observed when using a mouse to transfer item(s) into any small chest container UI.
nah, Its not my bug. I'm just a reporter trying to help. If someone else wants to do all that effort to upload a video to a private youtube channel just to link it so mojang does not have to bear the storage cost for a 50mb file of the error in *their* product, go for it. I'm moving on. I'm a developer and have my own projects to work on, Just here as a courtesy
I have a 15 second (50mb) video if you want to increase the upload size over 10 MB
… that said, this MAY fix you issue… but for me, the issue is still there… but just making sure others are not repeating the troubleshooting im doing…