Implement gamemode switching between worlds (as part of the WorldBuilder) #1
Comments
|
If this is to have a creative world, and a survival world in the same server, wouldn't it make more sense to either remember the last used gametype per world, or going further and having the option to keep seperate userdata/inventory/falldamage/statistics per universe? I've used multiverses gametype enforcing before and both allowing users to have an override permission allowing them to bring creative from creative to survival, or not having the override permission and suddenly dying as they teleport to their last known flying position in a survival world (due to being in creative in the survival world before going to the creative world) seem annoying. |
|
We won't be keeping inventory/etc isolated per world. Remember we want to try and keep things mostly Vanilla gameplay. With that said, having gamemode in the builder does complicate things. Namely cause it does break vanilla gameplay doesn't it. @SpongePowered/developers thoughts? |
|
If I understand correctly from reading the spongedocs, in sponge a world is a collection of dimensions, unlike Bukkit which relocated the dimensions into their own worlds? So cross-dimension same world teleports is the "vanilla" behaviour and thus is why gamemode is preserved. When is the players gamemode set in vanilla (without command intervention)? Is it a once off thing that gets remembered and maintained? As far as I can see, the only difference a worlds gamemode makes, is what players who data is first generated gets assigned, changing the gamemode of the world (and not player) would just result in the player maintaining their original gamemode. Also in singleplayer when a player changes worlds, it then loads the playerdata associated with that world. So bringing true multi-world support into servers means that inventories and everything would be separate by default? players teleport across dimensions, but join and leave worlds. Don't make the same decisions that Bukkit did because it's what people are used to, just make it easy for people to restore that behaviour using the API. |
|
In Sponge, each world has its own dimension and are treated as true worlds. The only reason why world and DIM1/-1 seem "linked" is cause of their portal targets. As I mentioned above, we have to mostly keep vanilla functionality:
So its probably better that we don't interfere here. If a plugin wants to isolate gamemode per world, we should let them do so. |
|
Considering this is partially handled by data, during the event being thrown for someone transferring between worlds, this shouldn't be much of an issue from the implementation side. That being said, I do believe it should be handled as vanilla deems fit, and plugins interacting with the player (setting game mode in the event) will take priority for obvious reasons. |
|
Closing this as we follow what Vanilla does. Plugins can easily change the GameMode during events. I'll be removing it from the WorldBuilder. |
For some unknown reason, Minecraft is sleeping 10ms between every single chunk being saved to disk. Under high chunk load/unload activity (lots of movement / teleporting), this causes the chunk unload queue to build up in size. This has multiple impacts: 1) Performance of the unload queue itself - The save thread is pretty ineffecient for how it accesses it By letting the queue get larger, checking and popping work off the queue can get less performant. 2) Performance of chunk loading - As with #1, chunk loads also have to check this queue when loading chunk data so that it doesn't load stale data if new data is pending write to disk. 3) Memory Usage - The entire chunk has been serialized to NBT, and now sits in this queue. This leads to elevated memory usage, and then the objects used in the serialization sit around longer than needed resulting in promotion to Old Generation instead of dying young. To optimize this, we change the entire unload queue to be a proper queue.This improves the behavior of popping the first queued chunk off, instead of abusing iterators like Mojang was doing. This also improves reliability of chunk saving, as the previous hack job had a race condition that could fail to save some chunks. Then finally, Sleeping will by default be removed, but due to known issues with 1.9, a config option was added. But if sleeps are to remain enabled, we at least lower the sleep interval so it doesn't have as much negative impact.
For some unknown reason, Minecraft is sleeping 10ms between every single chunk being saved to disk. Under high chunk load/unload activity (lots of movement / teleporting), this causes the chunk unload queue to build up in size. This has multiple impacts: 1) Performance of the unload queue itself - The save thread is pretty ineffecient for how it accesses it By letting the queue get larger, checking and popping work off the queue can get less performant. 2) Performance of chunk loading - As with #1, chunk loads also have to check this queue when loading chunk data so that it doesn't load stale data if new data is pending write to disk. 3) Memory Usage - The entire chunk has been serialized to NBT, and now sits in this queue. This leads to elevated memory usage, and then the objects used in the serialization sit around longer than needed resulting in promotion to Old Generation instead of dying young. To optimize this, we change the entire unload queue to be a proper queue.This improves the behavior of popping the first queued chunk off, instead of abusing iterators like Mojang was doing. This also improves reliability of chunk saving, as the previous hack job had a race condition that could fail to save some chunks. Then finally, Sleeping will by default be removed, but due to known issues with 1.9, a config option was added. But if sleeps are to remain enabled, we at least lower the sleep interval so it doesn't have as much negative impact.
For some unknown reason, Minecraft is sleeping 10ms between every single chunk being saved to disk. Under high chunk load/unload activity (lots of movement / teleporting), this causes the chunk unload queue to build up in size. This has multiple impacts: 1) Performance of the unload queue itself - The save thread is pretty ineffecient for how it accesses it By letting the queue get larger, checking and popping work off the queue can get less performant. 2) Performance of chunk loading - As with #1, chunk loads also have to check this queue when loading chunk data so that it doesn't load stale data if new data is pending write to disk. 3) Memory Usage - The entire chunk has been serialized to NBT, and now sits in this queue. This leads to elevated memory usage, and then the objects used in the serialization sit around longer than needed resulting in promotion to Old Generation instead of dying young. To optimize this, we change the entire unload queue to be a proper queue.This improves the behavior of popping the first queued chunk off, instead of abusing iterators like Mojang was doing. This also improves reliability of chunk saving, as the previous hack job had a race condition that could fail to save some chunks. Then finally, Sleeping will by default be removed, but due to known issues with 1.9, a config option was added. But if sleeps are to remain enabled, we at least lower the sleep interval so it doesn't have as much negative impact.
For some unknown reason, Minecraft is sleeping 10ms between every single chunk being saved to disk. Under high chunk load/unload activity (lots of movement / teleporting), this causes the chunk unload queue to build up in size. This has multiple impacts: 1) Performance of the unload queue itself - The save thread is pretty ineffecient for how it accesses it By letting the queue get larger, checking and popping work off the queue can get less performant. 2) Performance of chunk loading - As with #1, chunk loads also have to check this queue when loading chunk data so that it doesn't load stale data if new data is pending write to disk. 3) Memory Usage - The entire chunk has been serialized to NBT, and now sits in this queue. This leads to elevated memory usage, and then the objects used in the serialization sit around longer than needed resulting in promotion to Old Generation instead of dying young. To optimize this, we change the entire unload queue to be a proper queue.This improves the behavior of popping the first queued chunk off, instead of abusing iterators like Mojang was doing. This also improves reliability of chunk saving, as the previous hack job had a race condition that could fail to save some chunks. Then finally, Sleeping will by default be removed, but due to known issues with 1.9, a config option was added. But if sleeps are to remain enabled, we at least lower the sleep interval so it doesn't have as much negative impact.
For some unknown reason, Minecraft is sleeping 10ms between every single chunk being saved to disk. Under high chunk load/unload activity (lots of movement / teleporting), this causes the chunk unload queue to build up in size. This has multiple impacts: 1) Performance of the unload queue itself - The save thread is pretty ineffecient for how it accesses it By letting the queue get larger, checking and popping work off the queue can get less performant. 2) Performance of chunk loading - As with #1, chunk loads also have to check this queue when loading chunk data so that it doesn't load stale data if new data is pending write to disk. 3) Memory Usage - The entire chunk has been serialized to NBT, and now sits in this queue. This leads to elevated memory usage, and then the objects used in the serialization sit around longer than needed resulting in promotion to Old Generation instead of dying young. To optimize this, we change the entire unload queue to be a proper queue.This improves the behavior of popping the first queued chunk off, instead of abusing iterators like Mojang was doing. This also improves reliability of chunk saving, as the previous hack job had a race condition that could fail to save some chunks. Then finally, Sleeping will by default be removed, but due to known issues with 1.9, a config option was added. But if sleeps are to remain enabled, we at least lower the sleep interval so it doesn't have as much negative impact.
* Fix : Keys.SKULL_TYPE * Change Stream to Loop, Introduce Test Plugin for Skulls.
(Hurrah to issue #1 on SpongeCommon!)
@bloodmc
When we pull over the world management impl to common, we need to implement switching gamemodes between worlds.
I think we considered making a permission in-which a player can override the gamemode switch. Something like
?
The text was updated successfully, but these errors were encountered: