Fixed loading single player worlds with mod enabled

[TreyRuffy]

Checks to make sure the server is a dedicated server before linking to mumble in order to fix unneeded strain and also fix the crash which occurs.

MixinPlayerManager.java:
MixinServerPlayerEntity.java:
• I added a check to fix crashes

ClientMumbleLinkMod.kt:
• I added a check to remove unneeded strain on the singleplayer world

[magneticflux-]

One requirement is to be able to use "Open to LAN" and have the mod work. Does this PR prevent that?

[TreyRuffy]

I think this will. What I could do is add an event for when you start a lan server, you will change a boolean to true and include that in the check. I won't be able to do it tonight but I can check tomorrow or the day after.

[TreyRuffy]

I believe I have fixed LAN servers with f371aaf

[magneticflux-]

I'm going to need evidence of the " unneeded strain" and the "crash which occurs" that you talked about in the main PR body. I've been using this mod on my own singleplayer world and haven't encountered a crash or been able to measure any strain.

[TreyRuffy]

I'm going to need evidence of the " unneeded strain" and the "crash which occurs" that you talked about in the main PR body. I've been using this mod on my own singleplayer world and haven't encountered a crash or been able to measure any strain.

I am not entirely sure if it caused by another mod or not, but this has fixed it. I can also measure the strain when opening the world and it uses more memory, unnecessarily as it is a singleplayer world.

[magneticflux-]

So I did some actual profiling on my own and these are the results:

The MinecraftClient.render() method is the only part used by this mod, as it hooks into the client tick, so we'll focus on that method:

As you can see above, the actual tick() component of the render method only takes up 22% of the time (approximately, it's sampled over a few minutes).
This mod only uses the tick() component, so we can "zoom" in further:

As you can see from the second image, ticking entities client-side takes up 65.8% of the time, ticking random block display ticks (things like flowing water splashes, sand dust falling, etc.) takes up 28%, and the remaining time is occupied by the mod at 2.5% of the time, and a raycast to find entities under the cursor at 1.2% of the time.

So that means this mod takes up 2.5% of all client ticking time and 2.5%*22%=0.55% of all client render time, right?

NOT SO FAST!

I actually couldn't get a single sample during the doMumbleTick method at first, so I added a call to println() at the start of the method that isn't normally there! How much time does that call take up then?

Well, well, well... It turns out all 6 samples ever recorded inside doMumbleTick were also inside of that println() call, which means that in over 12,000 samples, the sampler was never able to take a sample inside doMumbleTick that also wasn't in the println() call I added to make detection of the method easier.

From this, I can say with some degree of confidence that all the code in doMumbleTick takes less time than 1/6 of one println() call, which in itself takes less than 0.55% of the client render loop time.

If you have your own profiling that shows something significantly different, please share!

[TreyRuffy]

So I did some actual profiling on my own and these are the results:

The MinecraftClient.render() method is the only part used by this mod, as it hooks into the client tick, so we'll focus on that method:

As you can see above, the actual tick() component of the render method only takes up 22% of the time (approximately, it's sampled over a few minutes).
This mod only uses the tick() component, so we can "zoom" in further:

As you can see from the second image, ticking entities client-side takes up 65.8% of the time, ticking random block display ticks (things like flowing water splashes, sand dust falling, etc.) takes up 28%, and the remaining time is occupied by the mod at 2.5% of the time, and a raycast to find entities under the cursor at 1.2% of the time.

So that means this mod takes up 2.5% of all client ticking time and 2.5%*22%=0.55% of all client render time, right?

NOT SO FAST!

I actually couldn't get a single sample during the doMumbleTick method at first, so I added a call to println() at the start of the method that isn't normally there! How much time does that call take up then?

Well, well, well... It turns out all 6 samples ever recorded inside doMumbleTick were also inside of that println() call, which means that in over 12,000 samples, the sampler was never able to take a sample inside doMumbleTick that also wasn't in the println() call I added to make detection of the method easier.

From this, I can say with some degree of confidence that all the code in doMumbleTick takes less time than 1/6 of one println() call, which in itself takes less than 0.55% of the client render loop time.

If you have your own profiling that shows something significantly different, please share!

I'm very glad you have done that! It's much more reassuring to me to see this. The other problem does still exist where I crash. If you would like me to I can look into what mod(s) may be conflicting with this, but from the stacktrace, it is directly from the Mixins.

[magneticflux-]

I'd love any crash logs you have! Open an issue and post the relevant parts please! This PR can be to fix whatever incompatibility is causing the crashes.