Issue description:

Game crashes over a Flamethrower state, but I never have successfully loaded into the world I am connecting to, no one else is online, and the world is brand new - so no flamethrowers should exist

Steps to reproduce:

1. Load game
2. Connect to locally run forge server w/ same mods
3. Game Crashes after loading terrain screen appears

Version (make sure you are on the latest version before reporting):

Forge: 35.1 .37
Mekanism: Stage3-Mekanism-1.16.4-10.0.18.445
Other relevant version:
Stage3-MekanismAdditions-1.16.4-10.0.18.445
Stage3-MekanismGenerators-1.16.4-10.0.18.445
Stage3-MekanismTools-1.16.4-10.0.18.445

If a (crash)log is relevant for this issue, link it here: (It's almost always relevant)

https://pastebin.com/j6SXa38Q

If anyone finds this - this issue can be resolved by deleting the configs on the server side or client side (if in Single Player) - I don't know what it reset to work, but it seems to have worked.. for now

Edit: only worked for a little while

sorry, I just tested removing optifine, and sure enough like another issue here, it is caused by that.

added info: it seems to break again now, so the only option is to remove mekanism, optifine, or change this code that is causing the issue.

the problem occurrs here:

if (world.isRemote()) {
            boolean startSound;
            // If something changed and we're in a remote world, take appropriate action
            if (changed) {
                // If the player is the "local" player, we need to tell the server the state has changed
                if (isLocal) {
                    Mekanism.packetHandler.sendToServer(new PacketGearStateUpdate(GearType.FLAMETHROWER, uuid, isActive));
                }

                // Start a sound playing if the person is now using a flamethrower
                startSound = isActive;
            } else {
                //Start the sound if it isn't already active, and still isn't, but has a flame thrower
                // This allows us to catch and start playing the idle sound
                //TODO: Currently this only happens for the local player as "having" a flame thrower is not
                // synced from server to client. This is not that big a deal, though may be something we want
                // to look into eventually
                startSound = !isActive && hasFlameThrower;
                //Note: If they just continue to hold (but not use) a flame thrower it "will" continue having this
                // attempt to start the sound. This is not a major deal as the uuid gets checked before attempting
                // to retrieve the player or actually creating a new sound object.
            }
            if (startSound && MekanismConfig.client.enablePlayerSounds.get()) {
                SoundHandler.startSound(world, uuid, SoundType.FLAMETHROWER);
            }

I know this is an optifine related issue but I think that this can be addressed without having it be only in attempt to support optifine, if you guys disagree, feel free to reclose, but since there is a TODO: in the code that is causing the issue, there is likely a better solution that would improve the code without it being explicitly for helping support optifine. And, this problem only seems to occur when I try to connect to a server with this configuration, so it is definitely something to do with this remote world check.

What? That todo has nothing to do with the error, and just has to do with not starting the sound always when moving into range of a player if memory serves. The crash you are getting is due to the client not thinking a world exists or some other mod is firing a world load event for a null world. I need to look at this at some point given there is a very slight chance that the method causing the crash can somehow fire when no world exists, but I doubt it. Most likely it is due to optifine screwing up world loading or something.

Okay I actually stripped the logic and check from that code and optifine compatibility has returned when joining a world with a client w/ mek + optifine to a server w/ mekanism, so it does seem to have caused the error (and stripping the logic from the code does seem to fix it) (whether it was the sound or just the remoteworld check, I don't know) - I will test reconnecting a few more times to make sure but it seems to have worked

The code I changed to regain access to the world without removing optifine was the above, turned into this - hacky I know, but does seem to have solved the problem for now - I believe what stripping I did should only impact the playing of sounds when a player has a flamethrower, not sure, but I'm going to ban the flamethrower from being accessible in my world just to make sure it doesn't come up... lol

public void setFlamethrowerState(UUID uuid, boolean isActive, boolean isLocal) {
        setFlamethrowerState(uuid, isLocal);
    }

    public void setFlamethrowerState(UUID uuid, boolean isLocal) {
        boolean alreadyActive = false;
        boolean changed = false;
        boolean isActive = false;
        boolean hasFlameThrower = false;
    }

Also for more reference as to why we believe its optifine there was another issue about this problem here: #6888

report it to optifine - they are either interfering with or not firing the world load event, or somehow causing code to fire before the event has fired.

We can handle the NPE, but you'll likely end up with no sounds

Rather than removing logic from a class you should downgrade one forge version as specified in my last message.

I may just do that but unrelated, fastfurnace is on my modpack and Ive had no issues with it on 35.1.37, are you sure it requires it as well?

for anyone that stumbles across this, everything works on forge version 35.1.36 but not 35.1.37, mods like fastfurnace require 35.1.36 so people are updating to 35.1.37 and crashing.

I'm confused but I fixed it by modding the mod to not have a remoteworld check that crashes w/ optifine.. 🗡️