Ilandria

Oh awesome, thanks for that link. I'll do a bit more reading on it then keep that in mind and develop appropriately!

Yah they do die, but the problem isn't that they're not dying or anything - like I said it works fine and looks exactly how I want it to. The issues I'm facing are just that although each particle is tiny (data-wise), having hundreds of them generated (which happens if you place a lot of the blocks that emit them) adds up memory allocations pretty quick, which the Java GC then has to clean up (which is not good for performance). One solution to that problem is pre-allocating stuff (object pooling, etc.) then just re-using expired/the oldest one(s). I'm just having an issue where I don't know how to do that within the Minecraft engine/Forge API. I think the solution may be for me to do a 100% completely custom rendering solution (which I'd be fine with doing) instead of hooking into the MC/Forge particle system, but I'm unsure how to do that within this environment and am either hoping for references or an alternate solution to the problem. It also doesn't help that Java isn't my strongest suit, I'm learning the quirks of the language as I go. C++ and C# are where I know the ins and outs. Thank you for the reply though!

Hey, I'm working on adding custom particles to some of my blocks, and I've gotten it working using a few different methods. However, all of them run into issues related to garbage collection/memory inefficiencies. Currently what I'm doing is the following: I create an object pool of particles on load (with the intent of not spamming GC memory) and trigger the effects from that pool. If it runs out of available particles it just loops and overwrites the first one: In ClientProxy.java: @SubscribeEvent public static void onPostTextureStitch(TextureStitchEvent.Post a_event) { GlitterParticle[] particles = new GlitterParticle[500]; for (int i = 0; i < particles.length; i++) { particles[i] = new GlitterParticle(); } s_glitterEmitter = new Emitter(particles); } In Emitter.java: @SideOnly(Side.CLIENT) public class Emitter<T extends SimpleParticle> { private SimpleParticle[] m_particles = null; private int m_nextIndex = 0; public Emitter(SimpleParticle[] a_particles) { m_particles = a_particles; } public void emit(World a_world, double a_x, double a_y, double a_z, Color a_colour) { SimpleParticle particle = m_particles[m_nextIndex++ % m_particles.length]; particle.emit(a_world, a_x, a_y, a_z, a_colour); Minecraft.getMinecraft().effectRenderer.addEffect(particle); } } emit() in SimpleParticle: public void emit(World a_world, double a_x, double a_y, double a_z, Color a_colour) { world = a_world; particleAge = 0; isExpired = false; posX = a_x; posY = a_y; posZ = a_z; prevPosX = posX; prevPosY = posY; prevPosZ = posZ; particleRed = a_colour.getRed() / 255.0f; particleGreen = a_colour.getGreen() / 255.0f; particleBlue = a_colour.getBlue() / 255.0f; } Aaaand... How it's being used in randomDisplayTick on my blocks: if(a_world.isAirBlock(new BlockPos(x, y, z))) { ClientProxy.s_glitterEmitter.emit(a_world, x, y, z, colour); } I figured if I made my own pool of particles and added them to the effect renderer on emission, it wouldn't make copies of particles and thus get around spamming tons of GC memory, and if I tried to add a duplicate particle it simply wouldn't add it to the renderer until the previous reference to it was "finished" and removed. I was sad when I looked into ParticleManager and found that no such precautions are built-in. My knowledge on Java's GC and value vs reference types definitely could be stronger, I'm mostly drawing from my experience with C# for this. This is a concern for me since lots of the blocks and items in my mod emit particles and I'd like to make sure I'm doing things efficiently without allocating literal hundreds of megs of GC memory every few seconds just for particles that could easily be pre-allocated and pooled during load. If there's no built-in MC/Forge way of doing this, would anyone be able to suggest how I can do my own fully-custom rendering within the MC/Forge environment so I can be memory-efficient? Thank you!

{ "type": "charutils2:glitterdustfromcomponents", "ingredients": [ { "type":"forge:ore_dict", "ore":"dustRedstone" }, { "item":"minecraft:gunpowder" }, { "type":"forge:ore_dict", "ore":"dustGlowstone" }, { "type":"forge:ore_dict", "ore":"dye" } ], "result": { "item": "charutils2:glitterdust", "data": 0, "count": 4 } } You can use the forge ore dictionary like that ^. "plankWood" would likely be what you're looking for.

Thank you for the resource link, that'll be super helpful!

Hey! About 4 years ago (in 1.6.x) I had developed a mod, then I got too busy at school to update it, and now that I have the time I've decided to revive it! Forge has changed a ton since then and I'm not well-versed on the structure of the various json objects now used to define things. In particular, my mod has a lot of "16 colour variants" of blocks and items, and it would be nice (if possible) to have just one recipe file for all of them. Here's what one of the variants currently looks like: { "type": "minecraft:crafting_shapeless", "ingredients": [ { "type":"forge:ore_dict", "ore":"dustRedstone" }, { "item":"minecraft:gunpowder" }, { "type":"forge:ore_dict", "ore":"dustGlowstone" }, { "type":"forge:ore_dict", "ore":"dyeWhite" } ], "result": { "item": "charutils2:glitterdust", "data": 0, "count": 4 } } Instead of copy-pasting that file 16 times for many different kinds of items, blocks, and interactions, is there any way I can do something like this? { "type": "minecraft:crafting_shapeless", "ingredients": [ { "type":"forge:ore_dict", "ore":"dustRedstone" }, { "item":"minecraft:gunpowder" }, { "type":"forge:ore_dict", "ore":"dustGlowstone" }, { "type":"forge:ore_dict", "ore":"dye" <- This is now any dye colour. } ], "result": { "item": "charutils2:glitterdust", "data": "X", <- Whatever the metadata/damage/etc. of the dye used was. "count": 4 } } Thank you!