Bart Simpson
- Xorkent 2
- xorkent 2
- Europe/Stockholm
- Yes
- No
A component called "minecraft:damage_sensor" (according to bedrock.dev (Fig. 2), a trustworthy source for this sort of information) is supposed to have a sub-component called "damage_modifier." This sub-component allows us to directly add or subtract from the amount of damage an entity will take in a specific scenario. Unfortunately, it does not actually exist (Fig.
3, first error). This really sucks because while "damage_multiplier," another sub-component, does exist, it only changes the percentage of the damage taken, not the exact value. And speaking of the sub-component that does work, apparently it won't accept molang (Fig.3, second error). Molang is a key importance in addons that a component should always be compatible with, whenever possible. Fig.1is the code that doesn't work because of these two issues. It is for the defense and damage reduction systems to an addon that adds Terraria content into the game, and as far as I know, there isn't another way to achieve this system, so I'm basically stuck with this broken system until these two issues get fixed (if they even get looked into ._.). If it helps, I can split this post into two different reports, one focusing on each issue, so when you guys update the resolution status, you can differentiate between the two.A component called "minecraft:damage_sensor" (according to bedrock.dev (Fig. 2), a trustworthy source for this sort of information) is supposed to have a sub-component called "damage_modifier." This sub-component allows us to directly add or subtract from the amount of damage an entity will take in a specific scenario. Unfortunately, it does not actually exist (Fig. 1, first error). This really sucks because while "damage_multiplier," another sub-component, does exist, it only changes the percentage of the damage taken, not the exact value. And speaking of the sub-component that does work, apparently it won't accept molang (Fig. 1, second error). Molang is a key importance in addons that a component should always be compatible with, whenever possible. Fig. 3 is the code that doesn't work because of these two issues. It is for the defense and damage reduction systems to an addon that adds Terraria content into the game, and as far as I know, there isn't another way to achieve this system, so I'm basically stuck with this broken system until these two issues get fixed (if they even get looked into ._.). If it helps, I can split this post into two different reports, one focusing on each issue, so when you guys update the resolution status, you can differentiate between the two.
Issue: In the latest preview, the new BlockPermutation.resolve() method will throw the following error when using namespaced custom block properties:
{"(property)":(value)}*[Scripting][error]-Failed to resolve block "(block)" with properties
*. This is a huge disadvantage to Script API, as it means we cannot change the property values of our custom blocks. We also can't just change custom block property names to not include namespaces, because they're required for the block identifier.How to reproduce:
1. Make a new behavior pack if you don't already have one
2. Create a custom block with custom properties
3. Create a script that tries to edit the value of at least one of those properties
4. If you don't include the script file path in the manifest, make sure you have some way to run the script
5. Load a world with the behavior pack and/or place the block downThe files below are an example of me trying to create a custom fire block with as similar functionality to the vanilla block as possible. It's still incomplete in this file obviously, but because of this bug, I can't change which parts of the fire model are visible based on what adjacent block faces are solid (not without running several hundred execute commands per tick, and I don't need to explain why that's not a great option).


Ok, I’m sorry I put the report in the wrong place, but that has to be one of the dumbest fallacies ever! I’m sorry I put the report in the wrong place, but Mojang should still be DOING SOMETHING about it! This is a problem that MULTIPLE realms are having and it has been going on for almost a month! I can see you resolved the issue as invalid, but let me offer you some quick advice: Ignoring and shutting out a complaint that a massive audience is relying on to inform Mojang of a problem is not a very good idea. Take it from me.