• Hey! Register here to create your account, engage with the community, and talk about what is new!

Dev Blog: What's in store for the future?

_______________________________________________________________
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:
1625938786993.png
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:
1625938767018.png

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.
1625938710405.png
This is a basic, 51x51. Rounding it to the nearest chunk border would cause your plot now to be 64x64.


1625938735030.png
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:

Hammer86gn

Active member
Overlord
Joined
Sep 23, 2020
Messages
50
Very interesting this will def help with stopping lag with chests
 

wags678

Senior Moderator
Moderator
Joined
Sep 7, 2020
Messages
27
Absolutely amazing stuff. Keep up the great work!
 

shiverdog

Active member
Joined
Sep 8, 2020
Messages
73
1 complain = 1 more month of development :((
tired of all these greedy people adding more months for NO REASO
 

ninja70707

Support staff
Support
Joined
Sep 6, 2020
Messages
32
Nice, this looks super cool. I can't wait to get bigger codespaces for basic plots; it's so hard coding on them at the moment.

Although, this does seem like it would make getting locations on plots very difficult. It would also make it a little harder to quickly view the build. I hope there'll be a good solution to this. I also personally feel a glass platform in an empty void as the codespace to be a little unappealing; maybe we could get some sort of scenery around the codespace so that it doesn't feel so dull?
 

Oasher

New member
Joined
Sep 12, 2020
Messages
9
We're super excited for this update, and we hope you are too!
I'm very excited! just that, how will we easily get locations since the code and build will be separate? It's always be convenient that we could access the build and the code at the same time. Other than that, this update is really really great for players and the server!
 

Owen

Well-known member
Overlord
Joined
Sep 6, 2020
Messages
100
Build is accessed via punching and sneaking on a location item.
I'm very excited! just that, how will we easily get locations since the code and build will be separate? It's always be convenient that we could access the build and the code at the same time. Other than that, this update is really really great for players and the server!
 

Owen

Well-known member
Overlord
Joined
Sep 6, 2020
Messages
100
Nice, this looks super cool. I can't wait to get bigger codespaces for basic plots; it's so hard coding on them at the moment.

Although, this does seem like it would make getting locations on plots very difficult. It would also make it a little harder to quickly view the build. I hope there'll be a good solution to this. I also personally feel a glass platform in an empty void as the codespace to be a little unappealing; maybe we could get some sort of scenery around the codespace so that it doesn't feel so dull?
Top of the post.
 

stinkey

Support staff
Support
Joined
Sep 8, 2020
Messages
221

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.
this is great
(also see my signature)
 

SealedKiller

New member
Joined
Oct 3, 2020
Messages
4
Will there be bigger plot worlds than 64x64? It's kind of a waste if there aren't bigger worlds since you could have really big worlds with tons of space to work with.
 

fallow

Support staff
Support
Joined
Sep 12, 2020
Messages
15
Will there be bigger plot worlds than 64x64? It's kind of a waste if there aren't bigger worlds since you could have really big worlds with tons of space to work with.
Going off of this, it would also be awesome if the other end of the extreme was considered and super huge world plots (like 1024x1024) were created, but maybe at that point you'd have to factor in how loading chunks would effect the CPU.
 

sbot50

New member
Joined
Sep 6, 2020
Messages
8

World Plots​

Instead of each node having a world of plots, each plot will live in its own plot-sized world:
1625938786993.png

We're hoping to make the empty chunks customizable (for example grass or ocean, not just void), but no promises.
Yay! ik it's not final and stuff, but it would be so amazing. Also, world edit exists and there's already w/e for default players made with code, so its not necessary.


Code will be edited in its own world separate from the build:
1625938767018.png
This will help with people who lag from many chests, but I'm worried about if there's a loading time between found /dev and /play


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.
Btw ik it's not final, but if this becomes a thing, (talking about the last sentence) you should probably allow people to set a player limit.


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.
I hope this means lagslayers will be less of an a-hole about simple things.


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.
1. What about removed code blocks
2. Make sure this 100% works cause else a lot of plots will die

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.
Kinda forgot plots auto-clear lol, but still great.


Larger-ish plots​

We will most likely be expanding plots to the nearest chunk border.
1625938710405.png

This is a basic, 51x51. Rounding it to the nearest chunk border would cause your plot now to be 64x64.


1625938735030.png

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!
Idk if you guys know how much this will improve building stuff, thank you.


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.
Fun every plot that has multiple levels stored or uses a plot system for their players will die.


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.
Rip 2b2t sim.


"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.
Uhhhh what about code where stone has been removed, also why don't you just fully copy the codespace? But hey, who would do that... *cough*


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
1. Gj on not setting any deadlines
2. Should be a paid position imo
3. If it's coming with the 1.17 server changed (probs not) then make the codespace even lower plz :))))))
 

Daandar

Member
Overlord
Joined
Sep 10, 2020
Messages
21

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.

My plot has information about items stored in a DB (Each barrel contains items for damage, range, special particles, etc) so unless i store all that information in seperate variables as lists on plot startup i have to use a DB. from the first sentence i feel like its more a "You can have many more variables without any impact on your plot so just save information in SAVE variables" kinda deal but i wanted to make sure i don't have to convert my DB to 500+ Lists
 
Top Bottom