mirror of
https://github.com/mcMMO-Dev/mcMMO.git
synced 2024-11-22 21:26:46 +01:00
Slightly more readable changelog
This commit is contained in:
parent
72feacfdfe
commit
e90f8f5b82
@ -1,17 +1,23 @@
|
|||||||
Version 2.1.149
|
Version 2.1.149
|
||||||
Added new config file 'persistent_data.yml'
|
Added a new config file 'persistent_data.yml'
|
||||||
Almost all persistent mob data is now off by default and needs to be turned on in persistent_data.yml (new config file) for performance concerns
|
Almost all persistent mob data is now off by default and needs to be turned on in persistent_data.yml (new config file) for performance concerns
|
||||||
|
|
||||||
NOTES:
|
NOTES:
|
||||||
There are some performance issues with how Spigot/MC saves NBT when you start adding NBT to mobs, because of this I have decided that persistent data is opt-in.
|
There are some performance issues with how Spigot/MC saves NBT when you start adding NBT to mobs, because of this I have decided that the new persistent data from 2.1.148 is now opt-in.
|
||||||
Not every server will suffer from these issues, but there can be a significant cost if you turn the settings in persistent_data.yml on
|
|
||||||
I am therefor making many persistent options (the problematic ones involving mobs) opt-in so only those aware of the performance risk will be using the feature.
|
|
||||||
Persistent data on mobs is a new feature that was introduced in 2.1.148, it was not in mcMMO for the last 10 years and most of you probably didn't even know that it was missing
|
|
||||||
An example of persistent data would be, normally mcMMO would give 0 XP for a mob from a mob spawner, in the last 10 years if the server rebooted then those existing mobs would give XP again. But with the persistent data option turned on in persistentdata.yml they will be saved to disk, and mcMMO will not forget about them upon reboot.
|
|
||||||
|
|
||||||
For now it is not recommended to use persistent data without monitoring performance of ticks afterwards to make sure it was something your server could handle.
|
Not every server will suffer a TPS hit when using the persistent data options, but there is a significant IO cost which can affect TPS if you have them on
|
||||||
I have a solution in mind to make persistent data not so expensive, but writing the code for that will take some time. This will serve as an interim fix.
|
|
||||||
I am going to focus on Tridents & Crossbows instead of that alternative solution, so don't expect it anytime soon. Use persistent data only if you understand the potential performance cost risk.
|
I am therefor making many persistent options (the problematic ones involving mobs) opt-in so only those aware of the performance risk will be using the feature.
|
||||||
|
|
||||||
|
Persistent data on mobs was a new feature that was introduced in 2.1.148, it was not in mcMMO for the last 10 years and most of you probably didn't even know that it was missing
|
||||||
|
|
||||||
|
An example of persistent data would be, normally mcMMO would give 0 XP for a mob from a mob spawner, in the last 10 years if the server rebooted then those existing mobs would give XP again. But with the persistent data option turned on in persistentdata.yml they will be saved to disk, and mcMMO will not forget about them upon reboot.
|
||||||
|
|
||||||
|
For now it is not recommended to use persistent data without monitoring performance of ticks afterwards to make sure it was something your server could handle.
|
||||||
|
|
||||||
|
I have a solution in mind to make persistent data not so expensive, but writing the code for that will take some time. This will serve as an interim fix.
|
||||||
|
|
||||||
|
I am going to focus on Tridents & Crossbows instead of that alternative solution, so don't expect it anytime soon. Use persistent data only if you understand the potential performance cost risk.
|
||||||
|
|
||||||
Version 2.1.148
|
Version 2.1.148
|
||||||
Fixed a memory leak involving entity metadata
|
Fixed a memory leak involving entity metadata
|
||||||
|
Loading…
Reference in New Issue
Block a user