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

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

Status
Not open for further replies.
_______________________________________________________________
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 by a moderator:

EvilsSouls

Forum adept
Overlord
Joined
Apr 16, 2021
Messages
208
Reaction score
18
YESSSSSSS!

(btw, i wanted to ask. If you have a say for example a basic plot and you have a block that would get removed in the next version. Than as you said, it would get maby replaced with a other option with a new block or a template. And because "template" is sounding like more than 1 Block of code, what would happen if the line doesn't have space, would it make the template over the code border, would it make a function that gets called? I say this in every thing i say, but many things i say don't make any sence. So i am sorry if this doesn't make sence.)
 
D

Deleted member 26

Guest
YESSSSSSS!

(btw, i wanted to ask. If you have a say for example a basic plot and you have a block that would get removed in the next version. Than as you said, it would get maby replaced with a other option with a new block or a template. And because "template" is sounding like more than 1 Block of code, what would happen if the line doesn't have space, would it make the template over the code border, would it make a function that gets called? I say this in every thing i say, but many things i say don't make any sence. So i am sorry if this doesn't make sence.)
Glad you asked! It took a while but I think the idea I’m thinking of is basically when your plot is updated you’ll get a menu where it asks you to replace lines of code. They will appear as templates and basically say “please place down these lines, they are too large”. The bonus is with world plots we can have it so your plot will still totally work even if it doesn’t fit in your codespace.
 

EvilsSouls

Forum adept
Overlord
Joined
Apr 16, 2021
Messages
208
Reaction score
18
Ahh okay, so it would be a thing where the player has to place the template? But yea except that i find it amazing and a overall plus with the world plots.
 
R

redaipo

Guest
_______________________________________________________________
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:
View attachment 825
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:
View attachment 824

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


View attachment 823
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
Among Us (y)
 

General_Mudkip

Retired Moderator
Overlord
Joined
Sep 6, 2020
Messages
362
Reaction score
95
Will be interesting to see how this affects moderation. Will chats still be server/node-wide or will it be only limited to plots?
 

superbaconbro

Forum adept
Overlord
Joined
Jul 14, 2021
Messages
161
Reaction score
23
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!
flawed mathematics lol
256-50 is 206
adding 50 would be, well 256
256/206 = not 2, it's 1.242718....
you get 24% more code space not including the expanded codespace
yes im bored
 

TechStreet

Active member
Overlord
Joined
Sep 9, 2020
Messages
58
Reaction score
34
_______________________________________________________________
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:
View attachment 825
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:
View attachment 824

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


View attachment 823
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
My opinions: https://blog-website.techstreetdev.repl.co/blog?id=1
 

lemonhead2000

New member
Joined
Jun 16, 2021
Messages
4
Reaction score
1
flawed mathematics lol
256-50 is 206
adding 50 would be, well 256
256/206 = not 2, it's 1.242718....
you get 24% more code space not including the expanded codespace

We know that 1.17 allows negative height by y coordinates (-64).
The distance between the compact floors of the code is 4.
The maximum code height at the moment is 250 (because 250 + 4 and the code block with the chest = 256)
|-64| : 4 + 250/4 = 16 + 62 = 78; (round to floor)
now its 40 compact floors;
If 40 this 100% and 78 - x%
so x = 78*100/40 = 195%
195 - 100 = 95%

95% ~ double size
 

PettatoGaming

Active member
Overlord
Joined
Sep 6, 2020
Messages
45
Reaction score
12
I like the idea of world plots but why exactly do we need to separate the worlds between Build and dev? cant it be like a personal world with our plots in? so you don't have to stick at the loading screen every time we switch between /code and /dev?
 

Refrizor

Retired Administrator
Retired Admin
Joined
Aug 16, 2020
Messages
513
Reaction score
361
I like the idea of world plots but why exactly do we need to separate the worlds between Build and dev? cant it be like a personal world with our plots in? so you don't have to stick at the loading screen every time we switch between /code and /dev?
Hi! I asked the developers for you, and they mentioned that it's a lot of work to merge them into one because dev and build use totally different formats. Connecting them would cost us a lot in terms of performance, and the plot’s code is stored as ‘code’ whereas the build is more like a region. This means they are loaded quite differently
 

PettatoGaming

Active member
Overlord
Joined
Sep 6, 2020
Messages
45
Reaction score
12
Hi! I asked the developers for you, and they mentioned that it's a lot of work to merge them into one because dev and build use totally different formats. Connecting them would cost us a lot in terms of performance, and the plot’s code is stored as ‘code’ whereas the build is more like a region. This means they are loaded quite differently
I still don't understand fully, from what I'm seeing from this they essentially creating multiple worlds per player including separate worlds for code and dev. so essentially, you're creating more issues by having to create worlds. I can imagine thousands and thousands of worlds filling up the server storage.
I don't want to ruin peoples Excitement here but I am concerned that too many worlds can affect server's performance.
 

General_Mudkip

Retired Moderator
Overlord
Joined
Sep 6, 2020
Messages
362
Reaction score
95
I still don't understand fully, from what I'm seeing from this they essentially creating multiple worlds per player including separate worlds for code and dev. so essentially, you're creating more issues by having to create worlds. I can imagine thousands and thousands of worlds filling up the server storage.
I don't want to ruin peoples Excitement here but I am concerned that too many worlds can affect server's performance.
As mentioned in the blog, the developers have given a lot of thought into this. Development of concepts similar to this (private nodes) have been going on for about a year now so they've had plenty of time to think about the best way of implementing this. It's a very large move, and the developers wouldn't make such a huge change just for the sake of change.
 

dumploid

Retired Developer Management
Retired Admin
Joined
Nov 2, 2020
Messages
61
Reaction score
11
I still don't understand fully, from what I'm seeing from this they essentially creating multiple worlds per player including separate worlds for code and dev. so essentially, you're creating more issues by having to create worlds. I can imagine thousands and thousands of worlds filling up the server storage.
I don't want to ruin peoples Excitement here but I am concerned that too many worlds can affect server's performance.
World plots actually will allow for better storage of information compared to Minecraft's normal type of storage. With world plots, we are able to store code and build areas separately, and as such, are able to tailor the way they are stored to be a lot more specific. Another bonus is that with basic plots on the main nodes, you often are loading several other plots around your player, while with world plots, you only need to load the current plot.
 

PettatoGaming

Active member
Overlord
Joined
Sep 6, 2020
Messages
45
Reaction score
12
As mentioned in the blog, the developers have given a lot of thought into this. Development of concepts similar to this (private nodes) have been going on for about a year now so they've had plenty of time to think about the best way of implementing this. It's a very large move, and the developers wouldn't make such a huge change just for the sake of change.
I'll just follow along anyways cus, I don't hate the plan of what the server is going to become, just a few worries that some may have towards something that may just be successful anyways, and I wish the best of luck to them.

Here's to the future of DF 🍺
 

PettatoGaming

Active member
Overlord
Joined
Sep 6, 2020
Messages
45
Reaction score
12
World plots actually will allow for better storage of information compared to Minecraft's normal type of storage. With world plots, we are able to store code and build areas separately, and as such, are able to tailor the way they are stored to be a lot more specific. Another bonus is that with basic plots on the main nodes, you often are loading several other plots around your player, while with world plots, you only need to load the current plot.
Yeah I got that, it was just that the fact having multiple worlds in a server creates a lot of files and may fill up the server storage, especially with the player base we got on df now after Youtubers Showcasing the server
 
Status
Not open for further replies.
Top Bottom