missing required data class org.bukkit.Particle$DustOptions

[Malfrador]

Trying to spawn a Particle.DUST fails due to EffectLib not settings the data class.

EffectLib-Version: 10.10 Minecraft version: 1.21.7

Stacktrace: https://pastes.dev/vAY4MrIdt7 Using my fork here, but same issue happens on Paper.

Particle code:

      LineEffect lineEffect = new LineEffect(Spellbook.getInstance().getEffectManager());
      lineEffect.setLocation(caster.getLocation().add(0, -0.5, 0));
      lineEffect.setTarget(launcherTrait.getTargetLocation());
      lineEffect.particle = Particle.DUST;
      lineEffect.particleSize = 0.1f;
      lineEffect.color = Color.TEAL;
      lineEffect.duration = 20;
      lineEffect.start();

Looking at ParticleDisplay_Modern, it seems to set them only if the particle is REDSTONE. That particle is named DUST now, so the DustOptions will not be set. The Craftbukkit legacy hackery which renames REDSTONE to DUST does not seem to catch this case, and even if it did relying on it would be pretty bad.

Maybe in general checking Particle#getDataType would be better than hardcoding the ones that need data.

[NathanWolf]

I like the idea of using getDataType, I wasn't familiar with that method.

But I think something else may be wrong- as far as I know, colored particles are still working fine, and seem to be working in my own plugin that uses EffectLib.

It's important to note that the code you're looking at isn't comparing to the Bukkit Particle class, there is an internal set of constants in the ParticleDisplay class.

On startup, ParticleDisplay.REDSTONE is mapped to Particle.DUST in modern MC versions, and Particle.REDSTONE in older ones.

That works via ParticleUtil.getParticle, which is a named map to particle types. On startup, it tries each particle enum type in turn and uses the first one that works.

Is it possible that your fork defines both REDSTONE and DUST as valid Particle enums?

[NathanWolf]

I updated the class to use particle data type for most particles, including redstone.

You can try that out, it may fix your issue, though I still think there's something weird going on there.

https://jenkins.elmakers.com/job/EffectLib/275/com.elmakers.mine.bukkit$EffectLib/

[Malfrador]

Thanks, that build solved my issue perfectly.

Regarding the remapping: My plugin is a Paper plugin. Those do not run through the Commodore legacy compatibility stuff at all, so the REDSTONE -> DUST field rename isn't done there, as I recently learned. That explains that part at least.

My fork only changes some combat and damage mechanics, otherwise its just Paper. Just to be sure I printed the values of the Particle enum, no REDSTONE there.

Even the enum valueOf that ParticleUtil#getParticle is doing will run through Commodore/FieldRename though. So I kinda suspect it somehow relied on that doing its thing to work properly