mojira.dev

Test Pattern

More than one avatar was detected! There might be multiple accounts sharing this same name.

Assigned

No issues.

Reported

MCPE-226249 behavior pack manifest.json will not register to Minecraft if "settings" array is added Unconfirmed MCPE-182675 "minecraft:damage_sensor": {"cause":"magic","damage":false} ignores "oozing", "weaving", "wind_charged", "infested" Works As Intended MCPE-182653 New Coral Block definitions not a valid block type in add-on component "minecraft:inside_block_notifier" Awaiting Response MCPE-181244 Wind charge launches from feet Confirmed MCPE-179287 Skeleton not honoring seat rotation Awaiting Response MCPE-177948 Error message from crafter after moving with piston Cannot Reproduce MCPE-169561 Rapid double click loading items into small chest UI steals cursor focus to slot 1 Duplicate MCPE-169515 Sniffer Egg Item Shows incorrect scale/placement in item frames Fixed MCPE-168748 Allay has "open" inventory helper dialog Confirmed MCPE-168449 is_sneaking filter returns 0.0 (false) when player is sneaking & has item in main_hand Fixed MCPE-167099 Custom Blocks are missing a function to set transparent metadata so they can be waterlogged Awaiting Response MCPE-132673 Moss Blocks not appearing in chests of shipwreck Cannot Reproduce MCPE-126198 Shadow Pigs with Saddles in Boats Duplicate MCPE-126194 Riding Minecart - vision blocked Duplicate MCPE-57620 Crafting corruption Duplicate

Comments

night_vision

is still

nightVison

in loot tables but not listed. Likewise,

long_night_vision

is still

long_nightVision

This 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.

Ref: Minecraft Wiki Potion Metadata

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. 🙂

[media]

[media][media][media][media]

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

Twitter post @TestPattern360

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

still not fully implemented? Lets get on this one... I've tested every potion(drinkable, splash and lingering) as well as every suspicious_stew, ...they work (except for filters in the API noted below).

all of the following FLOWERS resolve to "poppy" (data 0)?

to recreate: copy one of the following 'replaceitem' commands and paste in chat, and then place any 1 tall flower in the players (@s) inventory slot 0. no matter what the flower is, any command listed below will erase it.

// poppy (correct)
"/replaceitem entity @s[hasitem=[{item=red_flower,data=0,quantity=1,location=slot.inventory,slot=0}]] slot.inventory 0 destroy air 1",
//blue orchid <--poppy
"/replaceitem entity @s[hasitem=[{item=red_flower,data=1,quantity=1,location=slot.inventory,slot=0}]] slot.inventory 0 destroy air 1",
// allium <-- poppy
"/replaceitem entity @s[hasitem=[{item=red_flower,data=2,quantity=1,location=slot.inventory,slot=0}]] slot.inventory 0 destroy air 1",
// azure_bluet aka houstonia <-- poppy
"/replaceitem entity @s[hasitem=[{item=red_flower,data=3,quantity=1,location=slot.inventory,slot=0}]] slot.inventory 0 destroy air 1",
// red tulip <-- poppy
"/replaceitem entity @s[hasitem=[{item=red_flower,data=4,quantity=1,location=slot.inventory,slot=0}]] slot.inventory 0 destroy air 1",
// orange tulip <-- poppy
"/replaceitem entity @s[hasitem=[{item=red_flower,data=5,quantity=1,location=slot.inventory,slot=0}]] slot.inventory 0 destroy air 1",
// white tulip <-- poppy
"/replaceitem entity @s[hasitem=[{item=red_flower,data=6,quantity=1,location=slot.inventory,slot=0}]] slot.inventory 0 destroy air 1",
// pink tulip <-- poppy
"/replaceitem entity @s[hasitem=[{item=red_flower,data=7,quantity=1,location=slot.inventory,slot=0}]] slot.inventory 0 destroy air 1",
// oxeye daisy aka oxeye <--poppy
"/replaceitem entity @s[hasitem=[{item=red_flower,data=8,quantity=1,location=slot.inventory,slot=0}]] slot.inventory 0 destroy air 1",
// cornflower <-- poppy
"/replaceitem entity @s[hasitem=[{item=red_flower,data=9,quantity=1,location=slot.inventory,slot=0}]] slot.inventory 0 destroy air 1",
// lily of the valley <-- poppy
"/replaceitem entity @s[hasitem=[{item=red_flower,data=10,quantity=1,location=slot.inventory,slot=0}]] slot.inventory 0 destroy air 1"
// poppy (correct I guess)
"/replaceitem entity @s[hasitem=[{item=red_flower,data=11,quantity=1,location=slot.inventory,slot=0}]] slot.inventory 0 destroy air 1",
"/replaceitem entity @s[hasitem=[{item=red_flower,data=12,quantity=1,location=slot.inventory,slot=0}]] slot.inventory 0 destroy air 1",
"/replaceitem entity @s[hasitem=[{item=red_flower,data=13,quantity=1,location=slot.inventory,slot=0}]] slot.inventory 0 destroy air 1",
"/replaceitem entity @s[hasitem=[{item=red_flower,data=14,quantity=1,location=slot.inventory,slot=0}]] slot.inventory 0 destroy air 1",
"/replaceitem entity @s[hasitem=[{item=red_flower,data=15,quantity=1,location=slot.inventory,slot=0}]] slot.inventory 0 destroy air 1"

inconsistencies: recipes - "red_flower" works in an ingredient array using "data"

{
  "format_version": "1.12",
  "minecraft:recipe_shapeless": {
    "description": {
    "identifier": "minecraft:blue_dye_from_cornflower"
    },

    
    "tags": [ "crafting_table" ],
    "group": "blue_dye",
    "ingredients": [
      {
        "item": "minecraft:red_flower",
        "data": 9
      }
    ],
    "result": {
      "item": "minecraft:dye",
      "data": 18
    }
  }
}

inconsistencies: "red_flower:<int> works in loot table array using "item" (wandering_trader_trades.json)

// start snippet
            {
              "max_uses": 12,
              "wants": [
                {
                  "item": "minecraft:emerald",
                  "quantity": 1
                }
              ],
              "gives": [
                {
                  "item": "minecraft:red_flower:0"
                }
              ]
            },
            {
              "max_uses": 8,
              "wants": [
                {
                  "item": "minecraft:emerald",
                  "quantity": 1
                }
              ],
              "gives": [
                {
                  "item": "minecraft:red_flower:1"
                }
              ]
            },
            {
              "max_uses": 12,
              "wants": [
                {
                  "item": "minecraft:emerald",
                  "quantity": 1
                }
              ],
              "gives": [
                {
                  "item": "minecraft:red_flower:2"
                }
              ]
            },
            {
              "max_uses": 12,
              "wants": [
                {
                  "item": "minecraft:emerald",
                  "quantity": 1
                }
              ],
              "gives": [
                {
                  "item": "minecraft:red_flower:3"
                }
              ]
            },
            {
              "max_uses": 12,
              "wants": [
                {
                  "item": "minecraft:emerald",
                  "quantity": 1
                }
              ],
              "gives": [
                {
                  "item": "minecraft:red_flower:4"
                }
              ]
            },
            {
              "max_uses": 12,
              "wants": [
                {
                  "item": "minecraft:emerald",
                  "quantity": 1
                }
              ],
              "gives": [
                {
                  "item": "minecraft:red_flower:5"
                }
              ]
            },
            {
              "max_uses": 12,
              "wants": [
                {
                  "item": "minecraft:emerald",
                  "quantity": 1
                }
              ],
              "gives": [
                {
                  "item": "minecraft:red_flower:6"
                }
              ]
            },
            {
              "max_uses": 12,
              "wants": [
                {
                  "item": "minecraft:emerald",
                  "quantity": 1
                }
              ],
              "gives": [
                {
                  "item": "minecraft:red_flower:7"
                }
              ]
            },
            {
              "max_uses": 12,
              "wants": [
                {
                  "item": "minecraft:emerald",
                  "quantity": 1
                }
              ],
              "gives": [
                {
                  "item": "minecraft:red_flower:8"
                }
              ]
            },
            {
              "max_uses": 12,
              "wants": [
                {
                  "item": "minecraft:emerald",
                  "quantity": 1
                }
              ],
              "gives": [
                {
                  "item": "minecraft:red_flower:9"
                }
              ]
            },
            {
              "max_uses": 7,
              "wants": [
                {
                  "item": "minecraft:emerald",
                  "quantity": 1
                }
              ],
              "gives": [
                {
                  "item": "minecraft:red_flower:10"
                }
              ]
            },

inconsistancies:

there is currently no way to use either a command (shown above) or a filter (shown below) in add-on entity to identify alt states of items, or at least it isn't in any documentation publicly available.

UPDATE 6/1/24: there is a filters only solution I found, based on that all minecraft namespace items do not need the 'minecraft:' namespace

// start snippet
"filters":{
	"any_of":[
		// WORKS!
		{"test": "has_equipment","domain": "inventory","value": "red_flower:1"},
                 // FAILS
                {"test": "has_equipment","domain": "inventory","value": "minecraft:red_flower:1"},
		// may work after flattening
		{"test": "has_equipment","domain": "inventory","value": "minecraft:blue_orchid"},
	]
},
"add": {
	"component_groups": [
		"phantom:fx_saturation_cg"
	]
}

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": true

or is it 

"test":"all_slots_empty",
"domain": "all",
"subject": "self",
"operator": "==",
"value": true

So the shortened code looks like

"test":"any_slot_empty",
"domain": "hand",
"value": true

and 

"test":"all_slots_empty",
"value": true

Did 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.

  1. Stacked or layered controls in the UI are not properly enumerated.

  2. global variable is overriding default local variable

  3. 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

  4. "$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.

Just ran some testing and all crouching interactions to the allay runtime have been removed by devs changing this:

// pre-1.19.80.24 Preview
      "minecraft:interact": {
        "interactions": [
          {
            "on_interact": {
              "filters": {
                "all_of": [
                  {
                    "test": "is_family",
                    "subject": "other",
                    "value": "player"
                  }
                ]
              }
            },
            "give_item": true,
            "take_item": true,
            "interact_text": "action.interact.allay"
          }
        ]
      },

to this:

// 1.19.80.24 Preview
"minecraft:interact": {
        "interactions": [
          {
            "on_interact": {
              "filters": {
                "all_of": [
                  {
                    "test": "is_family",
                    "subject": "other",
                    "value": "player"
                  },
                  {
                    "test": "is_sneaking",
                    "subject": "other",
                    "value": false
                  }
                ]
              }
            },
            "give_item": true,
            "take_item": true,
            "interact_text": "action.interact.allay"
          }
        ]
      },

So technically, I suppose, it's fixed? Just remove all `is_sneaking` interactions... is, well, an interesting tactic. I would have looked for a way to actually fix it, but I guess hiding it so no one can use that interaction on this runtime could be considered a repair. If the door doesn't work, just duct tape it shut. See? fixed. 🙂 Anyway, take care. Sincerely. It's a thankless job. I'll see you on discord.gg/Minecraft

Nice to see two of my favorite youtubers (FNT and GH) are on this... So If I had a guess, it's an incompatible default behavior combination, in the "minecraft: inventory" component on entities with inventories. MOJANG: Check to see if the flags have been set like this in your runtimes by mistake: 

"private": true,
"restrict_to_owner" : true

if this is the default setting in MOJANG's code, you'd block interactions because "open" overrides everything, but the inventory is private so nothing can be done by the owner. That's where I'd start to eliminate that component as one of the causes.

understood. but I don't have the bandwidth (time) to create use cases at this point. I've made a simpler example of the allay "open while sneaking" behavior and refiled it here -> MCPE-168748

Have a great day friend.

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