_______________________________________________________________
Please note that information shared in this blog is not final and may
change at any time!
_______________________________________________________________
Please note that information shared in this blog is not final and may
change at any time!
_______________________________________________________________
Hi all! Today we're going to talk about a big update coming to DiamondFire that we're currently working on. We'll be looking at what's planned and what you should be aware of regarding this update.
Background
Currently, your plot is stored on a single world on a node. If a server gets full because too many people are playing or building on, say, Node 1 plots, there is really nothing we can do because all the plots are stuck on the node they were created on. As DiamondFire continues to grow, we want to eliminate this restriction and allow your plot to be loaded onto any server. This will allow us to scale plots and overall make it much easier to expand without needing to create new "nodes".For example, if there are lots of popular plots on a single node we can distribute those plots onto different nodes to help improve server performance. This new system will also allow us to add some really cool features to make your development experience even better.
That is why we are looking into separating your plots... you could perhaps even say we are giving each plot its own world!
World Plots
Instead of each node having a world of plots, each plot will live in its own plot-sized world:
We're hoping to make the empty chunks customizable (for example grass or ocean, not just void), but no promises.
Code will be edited in its own world separate from the build:
This also allows us to have players play on separate copies of a plot. While we will have the option to keep any block changes made in play mode, we are hoping to also allow those changes to be ignored. The second option would prevent issues such as when plots don't shut down correctly or a set region action accidentally overwrites an important build. Eventually, we could even allow multiple simultaneous instances of the same game, meaning many games could scale up to hold hundreds of players.
Advantages
This crazy change will bring lots of advantages for the future. While you won't see all the benefits immediately when world plots are released, we are hoping to build these as soon as we can!Plot Distribution
Because plots will not be stored on a single node, we can distribute plots live according to how many plots and players are on the current server. If there's not enough room on the current nodes, we could even create new nodes on the fly!Infrastructure-wise, this is one of the most complex parts of world plot development, so we'll likely be spending a lot of time on it.
Plot Backups
Because each plot is stored separately, we could create backups for each individual plot. We could even have separate backups for the build and the code! We are unsure of how exactly this will work yet, but we are hoping to provide a way to backup and restore plots. This way you will have peace of mind knowing that if something goes wrong, you can restore it to a previous save.Smarter LagSlayer
Because each world is ticked individually, we can make LagSlayer able to directly measure how long your plot world is taking to tick.For example, the more complex entities you have the more server CPU you take up. Plot entity limits exist to ensure that you stay within a safe limit without lowering the server's TPS. This solution is imperfect, and separating your plot's world will allow us to measure how much CPU your entities are using directly. This way you can have as many entities as you want, but if they are expensive entities we can try to stop ticking them or delete them when needed.
Redstone lag machines would also be able to be "slain", as we would be able to measure how long your plot world is taking to tick redstone and be able to stop it based on that.
This smarter LagSlayer would eliminate a lot of the sources of lag that can be created just by using default Minecraft mechanics, which would ensure server stability.
Removal of Legacy Code
Currently, we have over 115 legacy actions. These actions sit in our codebase and slow down our development process.With world plots, we will be able to directly edit your code without loading any Minecraft world. We are hoping to have code that would automatically be able to convert templates and your plot which would replace these legacy actions with newer ones. This would allow us to ensure that we can move on from old features that boggle us down whilst maintaining compatibility for those plots.
Plot Archiving
We may be able to "archive" old plots. This means they will no longer be automatically cleared, but will be stored for a longer period (in an "archived" state) should you decide to return to the server after a long absence.Larger-ish plots
We will most likely be expanding plots to the nearest chunk border.
This is a basic, 51x51. Rounding it to the nearest chunk border would cause your plot now to be 64x64.
We can also expand codespace size. Not to mention you already have double the size because they'll start at y = 0 instead of y=50!
What should I watch out for?
Because world plots are such a drastic change, there are a couple of things that we would like people to watch out for.Barrel Databases
Oh boy, the thing that people keep doing despite us telling them NOT to. Because we will be able to properly measure and limit your plot these types of plots will suffer. It is recommended that if using a system like this you try to move away as soon as possible, as any possible breakages caused by this will not be supported (we have been telling you not to use these anyways).Note: By "barrel database", we're referring to the practice of saving data on items in barrels or other kinds of containers, effectively using a huge amount of blocks filled with items as storage.
Ender Chests
Currently each node has its own set of player ender chest inventories. Under world plots this won't work, but we will likely add an alternative such as some "personal vault" that you can access on all plots. Unfortunately this is more difficult to implement than it sounds; in the meantime, we recommend you back it up in your toolbars."Dead" Code
Lines of code that do not have any line starters (so it does not start with a process, function, player event/entity event) are not detected by the code system.When plots are converted we read your line starters and paste them into the world plot. However, when these line starters do not exist that line of code will not be read. So any code that is like this will most likely be deleted, so it is recommended you just stick a blank function at the beginning of it or just leave it to die.
When are world plots coming?
It should be noted that we are volunteers, we are not paid, we do this all in our free time, and this is quite possibly the largest update in DiamondFire history.We know Minecraft 1.17 recently came out, and we are uncertain when this update will be released to y'all yet because of all the changes that it requires. World plots in themselves change how lots of things work before, and as a result, any updates we make before world plots are released basically have to be built twice. As such, don't expect a lot in terms of updates before world plots are ready.
Please be patient with us as we work on this update. Complaining will only slow us down. We have no set release date (for either node beta or the main nodes), but we will update you on the progress as the summer continues.
We're super excited for this update, and we hope you are too!
- The DiamondFire Dev Team
Last edited by a moderator:
