Is this fixed with the latest version of betweenlands?
CyberdyneCC/Thermos#461

Any feedback on this?

I guess this will take long, I'm gonna regenerate the nether through mcedit and will see..
By the way, what worry me about mostly is the music-menu problem :/
I know it seems silly, but it's kinda important when you have custom music for a modpack x_x
Also, not sayng.. but I'd probably posted that here before the Betweenland team was on the decision to dump support for 1.7.10 :c

Also, not sayng.. but I'd probably posted that here before the Betweenland team was on the decision to dump support for 1.7.10 :c

That was actually quite a while ago. If somebody has the time and motivation to keep the 1.7 branch updated then we'd be fine with that, but it's too much work as it is right now.

anyway, I'm not sure is it wise let this issue behind.. I'm sure it will be the same for 1.10 and people who want add custom music will have problems.. the fact is that you doesn't even need liteloader to reproduce.. when you disable main menu from betweenland in the config the vanilla musics start to play from nowhere D:
could this be fixed just by impede vanilla musics to play in the menu? forcing them somehow to mute.. idk :l

That's why I left this issue open. If it's still a problem in 1.10 we'll certainly fix it there.

I did a quick profiling, and there's clearly bad things going on in the events handling:

For the record, there's no players in the betweenlands when this profiling was done with Opis.

I don't see anything wrong there, unless I'm reading it incorrectly. Could you point out where and what's supposed to be bad with those results?
Edit: As a side note, when I used Opis is seemed really quite buggy and I couldn't make sense of the results. Why don't just use "/forge tps" to check the TPS as an indicator for lag? If the mod causes so much lag it should definitely affect the TPS a lot.

Over 250 sampled ticks, the mod is using in average 2% of CPU time just for the event handling.
For example, the ChunkDataHandler by itself, uses 0.42 ms of CPU time every ticks.

In comparison, on the same sampling time, Botania slowest event is at 0.05 ms, which is 10 times faster.

Here's a view on another event using a Java profiler:

This was sampled over 9mn with ~12 players online on a dedicated server with lots of free RAM, etc.

You can see the thebetweenlands.entities.properties.EntityPropertiesHandler.onEntityUpdate calls are taking 3.19% of CPU time just by themselves.
Here's a more detailled view for just that event:

Looks like the call to NBTTagCompound.equals() is the culprit here. You might want to consider using another way to check updates instead of brute force comparaison of a complex structure.

At least 2 other event leads to the same conclusion here:

and here:

I've see some random lag spikes too, but they're harder to catch on this profiler. I would advise to start fixing the above issue for a start.

From what I see in the code, there's lot of use of threads synchronization. I hope it's not used in network events handling, as this would cause lots of lag by itself.

Over 250 sampled ticks, the mod is using in average 2% of CPU time just for the event handling.
For example, the ChunkDataHandler by itself, uses 0.42 ms of CPU time every ticks.

Hmm, that's interesting. It's only supposed to be called when a chunk is saved or loaded and I don't suppose that is being done every tick. I'll have a look at that at some point.

Looks like the call to NBTTagCompound.equals() is the culprit here. You might want to consider using another way to check updates instead of brute force comparaison of a complex structure.

Yes, that's true. I'm aware of the fact that comparing NBT tags is not the most efficient way, but I hadn't noticed any performance problems which is why I left it there. We haven't tested the mod in MP extensively yet, and only with 3 or 4 players at most.

A lot of the code is being rewritten as we update the mod to 1.10 and I hope that most of those issues are going to be fixed during the rewrite.
Thanks for the info, I'll keep those points in mind.

A lot of chunks are loaded and saved every ticks in SMP. Players don't remain static, especially in an exploration mod like this one.

@TheCyberBrick Ehm... to be honest I was reffering to this issue.. #324
it should also be easy to fix.. I.. guess? :/

1. Does this only happen if the BL is installed? Please remove it and test again.
2. Does this also happen with modded vanilla (not spigot)?
3. There are 411818 loaded entities and 830822 tile entities in the nether, surely something is wrong there...
4. The reported method from that logger (not sure what or how spigot does it) reports ItemEquipmentHandler.tickEquipment as the culprit. However, I don't really see what could be wrong there except that it iterates over all entities which could be related to the crazy entity count perhaps. If spigot simply dumps the thread stack trace then that wouldn't really be helpful.

Well, I should still try without BL, it could require a week or maybe two to figure out if this does happen again since the server normally doesn't shut down.. tryng with vanilla forge server would be even worse and would require even a month to reproduce.. the hard thing is exactly this.. is hard to reproduce because it's not well clear what exactly cause all the mess.
By the way what is weird is that the Nether was explored for only 7-8 chuncks, and nothing was done around there.. (only 2 players explored the nether actually for those 7-8 chunks).
Regarding the logger... err... I'm almost a total noob at java ^_^''
I didn't even really got what you was tryng to say D:

How was it fixed?

Both the chunk data and entity data handlers have been rewritten since the 1.10 version and the 1.12 version. The entity syncing doesn't constantly compare the NBT anymore and I've just pushed a commit that moves chunk data/local storage saving to the file IO thread. Loading the data isn't in a seperate thread because I haven't found a way to hook async chunk loading (yet)

Doesn't this mean that it is not fixed for 1.7.10 but only for 1.10+?
In this case it's incorrect to close the issue...

We can't work on all of those 3 major versions, and it'll probably stay that way unless somebody volunteers to update them. The current version is v3.3.3 (or dev build 1.12-725 with the saving IO thread) and there it should be fixed. If it isn't please feel free to open a new issue with new profiling results. I've done some profiling myself and I couldn't find anything significant