hiotewdew

No it doesn't. The second you run that on a DEDICATED SERVER it will crash. As I just explained, you need to use DistExecutor or packets.

Do not use Gradle 5.0, use 4.9

Your code is going to crash if you run it on a multiplayer server because it loads client classes regardless of if it runs or not. You need to use packets or DistExecutor

gradlew eclipse, F5 to refresh project

no no, instead of creating a custom particle type and particle data that you never use, instead just use BasicParticleType. This is as simple as deleting your particle type and data and replacing ObisidianParticleType::new with () -> new BasicParticleType(false)

Ah unfortunately all my Particle code is textured particles using the Sprite particle renderer. One thing I am a bit confused on is why you are registering particle data and have a custom Particle type class when you can simply use the default BasicParticleType

Does it not? I've used the double supplier trick in a lot of code and it's all worked just fine on dedicated servers.

DistExecutor is used for physical side, whether you are using a minecraft client or dedicated server (in this case, this is the relevant information as only physical clients do rendering) isRemote references the logical side, where true is the logical client. Logical client just means if it's not running the gameserver instance on that thread, so isRemote could return false on clients on the server thread. Also, isRemote checks do not properly avoid classloading, unlike DistExecutor which avoids them by utilizing the double supplier trick.

Not fully used Particle rendering on 1.15, only 1.14, but perhaps the issue is that your line has zero-depth? I believe you may need a small amount of depth for the line to actually render. Although, it looks like you may have that. Try ending the buffer? Also take a look at some vanilla particle renderers to see how those are done.

Dunno if you ever found a *real* fix - but my fix was disabling it in creative (the item has no use in creative, it's a bag that returns even after you die)

Yep.

Doesn't really matter - same bug happens with or without it. Had it originally, removed it, re-added, nothing.

I need to "register" my capability? How? Isn't already registered as an itemhandler capability, like builtin?

So I was doing some reading trying to figure out why my item with an itemhandler capability was losing all of its items when it changed slots in creative on the server- and someone on the MMD discord mentioned that the client handles inventory in creative. I found this: http://www.minecraftforge.net/forum/topic/27248-player-inventory-synchronization/ So apparently I'm doing something wrong with my cap provider/deserialization or something that is causing the client to not get the right items in the right spot. What I mean by "changing slots" is I will take the bag, move it from slot 1 on my hotbar to slot 2 and all the items will have disappeared. (It's a GUI, and definitely not desync, relogging fixes nothing). Otherwise works fine in survival on server and on the client (although I have noticed it a few times in creative on the client - possibly the effective server thread is responsible) Capability Provider: https://github.com/BuiltBrokenModding/SBM-DeadMansSatchel/blob/master/src/main/java/com/builtbroken/deadmanssatchel/item/SatchelCapabilityProvider.java Item: https://github.com/BuiltBrokenModding/SBM-DeadMansSatchel/blob/master/src/main/java/com/builtbroken/deadmanssatchel/item/ItemDeadMansSatchel.java Container: https://github.com/BuiltBrokenModding/SBM-DeadMansSatchel/blob/master/src/main/java/com/builtbroken/deadmanssatchel/item/ContainerSatchel.java Not sure if I should be using the NBT argument from initCapabilities somehow. Is there a way to force handling on the server for my container - even in creative?

How do I register using NBT values?