user-e1104
- jirauser509042
- JIRAUSER509042
- Europe/Stockholm
- No
- No
1 issues
Key
Summary
Status
Reporter
Assignee
Created
WEB-6998
MCPE-162107Deleted Comment:
I believe that this is still a valid issue and should be reopened. Small fireballs still cannot be summoned.
Added Attachments:
I believe I have pinpointed the problem. Please let me know if you agree or disagree with what I have written below:
Definitions
First, we must define the offending subcommands and affected subcommands.
Offending subcommands have been found as: /execute at <entity>, /execute positioned <coords>, and /execute positioned as <entity>.
Affected subcommands have been found as: /execute as <entity>, /execute at <entity>, and /execute positioned as <entity>.
This is an issue that occurs when an offending subcommand is immediately followed by an affected subcommand.
Examples
These examples were performed with an armour stand with the tag test in the world with a command block nearby to run the commands in these examples.
These commands should execute when the player is within three blocks of the tagged entity. Instead, they execute when the player is within three blocks of the command block.
This command should execute when the player is within three blocks of the position five blocks of the command block. Instead, it executes when the player is within three blocks of the command block itself.
Here, we added positioned ~ ~5 ~ as a decoy before setting the position to the entity that we want. Yet, the bug makes it so that @p[r=3] begins searching from ~ ~5 ~, which is not correct. It should be searching from the location of the tagged entity.
These commands execute in the expected manner, printing test if there is a player within three blocks of the tagged entity. They also execute correctly with unless. This shows that the if and unless subcommands are not affected by this bug.
execute at @e[tag=test] run tellraw @a {"rawtext":[{"selector":"@p[r=3]"}]} execute at @e[tag=test] run effect @p[r=3] jump_boost 10 0 trueThese commands execute in the expected manner, printing/effecting the player only if they are within three blocks of the tagged entity. This shows that target selectors in the run command are not affected by this bug.
This command executes in the expected manner, setting a block three blocks above the tagged entity. This shows that positioned <coords> is not an affected subcommand. If it were an affected subcommand, the stone may have been placed three blocks above the command block.
Examples of temporary workarounds to correct the unwanted behaviour
This unwanted behaviour can be corrected by inserting any subcommand in between the offending and affected subcommands.
Here are six of the nine commands from the first example, each with a different example of a remedy:
execute as @e[tag=test] at @s run execute as @p[r=3] run say test execute as @e[tag=test] at @s if entity @s at @p[r=3] run setblock ~ ~3 ~ stone execute as @e[tag=test] at @s at @s positioned as @p[r=3] run setblock ~ ~3 ~ stone execute as @e[tag=test] positioned as @s as @s as @p[r=3] run say test execute as @e[tag=test] positioned as @s positioned as @s at @p[r=3] run setblock ~ ~3 ~ stone execute as @e[tag=test] positioned as @s unless entity @e[tag=impossible] positioned as @p[r=3] run setblock ~ ~3 ~ stoneWe inserted a different subcommand in between the offending and affected subcommands, and no matter what separates them, it corrects the unwanted behaviour.
The simplest remedies are:
The latter two will only work if an @s entity has been defined with as beforehand, and run execute will always work. The common thing about these remedies is that when they do work, they will not change anything.
Also shown are less common remedies that are not recommended but will still work in some (not all) situations. These include:
Conclusions
This bug produces unexpected behaviour to certain combinations of subcommands within the new /execute command. Extensive testing was required to pinpoint the exact combinations that cause the unwanted behaviour. We also find that this bug is easily worked around while it is still present, in many ways. However, it is still behaviour that is illogical to the way /execute should be working, and it requires the insertion of redundant checks, the least intrusive being run execute, but which still takes resources, as it has to look up what /execute is again. The behaviour seen here is most likely unintended, and this problem should be corrected at the team's earliest convenience.
@Chris_KR To clarify, this is on the subject of the new syntax for the /execute command. In Bedrock version 1.19.10 and newer, the syntax of /execute has been changed to reflect that of Java Edition's.
Additional findings
Notice how to set a scoreholder with a non-alphanumeric character, quotation marks are required around the scoreholder's name:
scoreboard players set "#example" foo 1Therefore, logically, to retrieve this score value, quotation marks will need to surround the scoreholder's name in the JSON text.
Our current text is:
{"rawtext": [{"score": {"name": "#example", "objective": "foo"}}]}This means that when the JSON test looks up the score, it is looking up:
Notice something? No quotation marks!
The next logical step to find a solution would be to add an inner set of quotation marks around the scoreholder's name:
{"rawtext": [{"score": {"name": "\"#example\"", "objective": "foo"}}]}Notice the use of backslashes to insure the inner quotation marks are not interpreted as part of the JSON structure.
When this JSON text is printed, we no longer have an error message.
However, there is instead no output. No output is printed, even though a score is set.
It can be confirmed that putting inner quotation marks is correct because the same can be done for any other username, e.g. your own:
{"rawtext": [{"score": {"name": "\"ExpertCoder14\"", "objective": "foo"}}]}Conclusion
It appears that the JSON text resolution system is currently not prepared to handle usernames with non-alphanumeric characters, even when queried in the correct manner. However, such usernames are valid scoreholders within other aspects of the scoreboard system. Therefore, it is most likely unintended that the JSON text does not support these usernames, and this is a bug.
In addition, usernames like these are chosen frequently to be scoreholders because they contain characters that will never appear in a real Minecraft username. If a user with the same name as a fake scoreholder joins the game, this could have unintended effects if a command system detects them as a player. It would be appreciated by many if this could be fixed, which would increase the efficiency of development by allowing fake scoreholders to be printed directly.
It appears that there may be a potential fix in an upcoming release. Testing will need to occur to ensure that all subcommands have been fixed, and that none have been left behind.Edit: From testing, it appears that most if not all of the subcommands from the examples in my previous comment have been fixed. I tested several from the large list of nine commands, and each example from the single examples as well. The issue appears to be fixed at this point. Thank you to the team for fixing this problem.
Affects latest release (1.19.2) as of this time, and presumably all releases up until this point also.
Regrettably, I am experiencing what may be a similar issue pertaining to loading RTX packs.
For me, the pack I am using is the boilerplate pack that is provided by NVIDIA for developers creating RTX packs. This pack has been attached to this issue as nvidia-pbr-example_ec14.mcpack
for easy download and inspection.
I am also receiving similar readouts from Event Viewer:
I do not know where I can find any further details to the crashes I am experiencing. Please let me know if/how this error can be explored in further detail.