mojira.dev
MC-89181

AreaEffectCloud does not work with some particles/crashes with others

When summoning an AreaEffectCloud, the following particles do not display:

  • blockcrack

  • blockdust

  • blockicon

    Particle

    /particle iconcrack_89 ~ ~1 ~ 1 1 1 0 50



    Summon AreaEffectCloud

    /summon AreaEffectCloud ~ ~1  {Radius:2.0f,Duration:2147483647,Particle:iconcrack_89}

Further explanation by @unknown:

What's happening is that the possible particle IDs (found in class 'cy') are checked exactly. "blockcrack_", "iconcrack_", and "blockdust_" are the exact IDs, meaning "blockcrack_1" is seen as an invalid ID since it doesn't match; it's not interpreting what the "1" means up to this point, thus the correct format for those types of particles is essentially irrelevant.

From the AreaEffectCloud entity class (ra.java), where it attempts to read NBT data (accessed via /summon):

if (compound.hasKey("Particle", 8)) {

    ParticleInput = compound.getString("Particle");

    for (ParticleTypes ParticleTypes : ParticleTypes.values()) {

        if (!ParticleTypes.getID().equals(ParticleInput)) continue;

        this.a(ParticleTypes);
        break;
    }
}

In summary: for each particle ID there is, check if the input from the "Particle" tag matches it exactly. If so, that will be the particle used. A small section from the list in ParticleTypes (cy.java):

A("barrier", 35, false),
B("iconcrack_", 36, false, 2),
C("blockcrack_", 37, false, 1),
D("blockdust_", 38, false, 1)

If the input was "barrier", then it matches perfectly. However, if the input is "blockcrack_1", then it doesn't since there's no corresponding particle ID. If the input is "blockcrack_", then it matches the ID from the list and is the chosen particle. The game will crash when doing so though, as mrpingouin1 pointed out.

So the problem comes from the AreaEffectCloud class matching particle IDs with the "Particle" tag, since the particle ID is checked as literally typed (it can't determine that "blockcrack_1" is the intended "blockcrack_" ID).

The /particle command differs from this because it checks on its own if the intended ID is one of the underscored IDs, which is why it can work there (as well as preventing the use of just "blockcrack_").

Attachments

Comments 10

Unless I've misunderstood him, I've used the intended method by Searge.
"Instead of _1_0 which was block id and metadata before, it now only takes one parameter. the new value in this case is _1 and this is calculated like this:
newId = blockId | (metaData << 12)"

It crash and "corrupt" your world when you use this command (see attached crash report):

/summon AreaEffectCloud ~ ~1  {Radius:2.0f,Duration:2147483647,Particle:iconcrack_}

What's happening is that the possible particle IDs (found in class 'cy') are checked exactly. "blockcrack_", "iconcrack_", and "blockdust_" are the exact IDs, meaning "blockcrack_1" is seen as an invalid ID since it doesn't match; it's not interpreting what the "1" means up to this point, thus the correct format for those types of particles is essentially irrelevant.

From the AreaEffectCloud entity class (ra.java), where it attempts to read NBT data (accessed via /summon):

if (compound.hasKey("Particle", 8)) {

    ParticleInput = compound.getString("Particle");

    for (ParticleTypes ParticleTypes : ParticleTypes.values()) {

        if (!ParticleTypes.getID().equals(ParticleInput)) continue;

        this.a(ParticleTypes);
        break;
    }
}

In summary: for each particle ID there is, check if the input from the "Particle" tag matches it exactly. If so, that will be the particle used. A small section from the list in ParticleTypes (cy.java):

A("barrier", 35, false),
B("iconcrack_", 36, false, 2),
C("blockcrack_", 37, false, 1),
D("blockdust_", 38, false, 1)

If the input was "barrier", then it matches perfectly. However, if the input is "blockcrack_1", then it doesn't since there's no corresponding particle ID. If the input is "blockcrack_", then it matches the ID from the list and is the chosen particle. The game will crash when doing so though, as mrpingouin1 pointed out.

So the problem comes from the AreaEffectCloud class matching particle IDs with the "Particle" tag, since the particle ID is checked as literally typed (it can't determine that "blockcrack_1" is the intended "blockcrack_" ID).

The /particle command differs from this because it checks on its own if the intended ID is one of the underscored IDs, which is why it can work there (as well as preventing the use of just "blockcrack_").

Is there a way to make those work with AreaEffectClouds?

Currently no, this bug would need to be fixed first.

Confirmed for 15w39b.

Confirmed for 15w40a.

Changed the particle command to:

/particle <name> <x> <y> <z> <xd> <yd> <zd> <speed> [count] [mode] [player] [params]

You cannot use iconcrack_XXX anymore, you give the XXX as param to the end of the command.

This entity summon will stop crashing, but it will not support the custom params for now.

@Grum Just for clarification, the [player] part of the /particle syntax was removed in favor of /execute; is that still the case (such that [params] is actually meant to be where [player] is)?

Yup, purged the player part. Not sure why that was still in the code!

Argh, we can't because it does the inverse. It normally sends to all and this would allow you to restrict it. Leaving it as it is 😃

qmagnet

Erik Broes

Community Consensus

Minecraft 15w38b, Minecraft 15w39b, Minecraft 15w40a

Minecraft 15w49a

Retrieved