K_Sasha
Active member
- Joined
- Aug 16, 2020
- Messages
- 40
- Reaction score
- 46
This thread will document how Lagslayer works, along with all the other plot related limits on DiamondFire.
CPU Usage
Plots can use up to 40% to 80% of the node's CPU, depending on the amount of players on the plot. Each player after the first player that joins the plot adds an additional 6% to the plot's allowed CPU usage (40 + (players - 1) * 6). This means that a plot's maximum allowed CPU usage is reached at 8 players.
To help with lag spikes halting plots, a plot can use 130% of the allowed CPU usage (allowedUsage * 1.3) for 1 second every 4th second (if a plot exceeds 130% of the allowed CPU usage more than once within a span of 4 seconds, it is halted).
The first time a plot is halted, it is halted for 5 seconds. Every consecutive time the plot is halted, it is halted for an additional 2.5 seconds (halts * 2.5 + 2.5). The maximum halt time is reached at 11 halts, with a halt time of 30 seconds. The plot halt length is reset when all players leave the plot.
CPU usage is checked every time an event finishes executing, a wait is run, or a potentially CPU intensive action is run. CPU intensive actions are actions that have the potential to use significant amounts of CPU in the right circumstances and, if chained, cause a substantial lag spike. These actions include block setting actions, many list manipulation actions, and several others. However, unless you want to design your plot in such a way that accounts for any place where a plot halt can occur, this information won't be of very much use to you.
Entities
DiamondFire limits how many entities can be present on a plot, and immediately removes any that surpass the limit. Different types of entities have different limits, they are shown in this table:
(the General category includes any entity that is not part of another category)
Events
DiamondFire limits how many events can exist on a plot at a given time. Note that by "events" I mean events and processes. This limit is currently set to 5,000.
DiamondFire also limits how many events can be nested inside each other with no waits. Events are nested when an event triggers another event through some action such as damaging a player. This limit is currently set to 30. Note that if you hit this limit, your game almost certainly has a bug. This is not a limit that any normal game should ever hit and is only present to stop the server from freezing.
Variables
DiamondFire limits the amount of game and save variables that can exist on a plot to 500,000 (combined, does not include local variables). DiamondFire also limits the amount of local variables that can exist on any given event to 50,000. A list variable can contain a maximum of 10,000 values, this includes any values in nested lists. Values inside a list do not count towards the variable count.
The following information is currently inaccurate due to a variable saving bug.
CPU Usage
Plots can use up to 40% to 80% of the node's CPU, depending on the amount of players on the plot. Each player after the first player that joins the plot adds an additional 6% to the plot's allowed CPU usage (40 + (players - 1) * 6). This means that a plot's maximum allowed CPU usage is reached at 8 players.
To help with lag spikes halting plots, a plot can use 130% of the allowed CPU usage (allowedUsage * 1.3) for 1 second every 4th second (if a plot exceeds 130% of the allowed CPU usage more than once within a span of 4 seconds, it is halted).
The first time a plot is halted, it is halted for 5 seconds. Every consecutive time the plot is halted, it is halted for an additional 2.5 seconds (halts * 2.5 + 2.5). The maximum halt time is reached at 11 halts, with a halt time of 30 seconds. The plot halt length is reset when all players leave the plot.
CPU usage is checked every time an event finishes executing, a wait is run, or a potentially CPU intensive action is run. CPU intensive actions are actions that have the potential to use significant amounts of CPU in the right circumstances and, if chained, cause a substantial lag spike. These actions include block setting actions, many list manipulation actions, and several others. However, unless you want to design your plot in such a way that accounts for any place where a plot halt can occur, this information won't be of very much use to you.
Entities
DiamondFire limits how many entities can be present on a plot, and immediately removes any that surpass the limit. Different types of entities have different limits, they are shown in this table:
(the General category includes any entity that is not part of another category)
Events
DiamondFire limits how many events can exist on a plot at a given time. Note that by "events" I mean events and processes. This limit is currently set to 5,000.
DiamondFire also limits how many events can be nested inside each other with no waits. Events are nested when an event triggers another event through some action such as damaging a player. This limit is currently set to 30. Note that if you hit this limit, your game almost certainly has a bug. This is not a limit that any normal game should ever hit and is only present to stop the server from freezing.
Variables
DiamondFire limits the amount of game and save variables that can exist on a plot to 500,000 (combined, does not include local variables). DiamondFire also limits the amount of local variables that can exist on any given event to 50,000. A list variable can contain a maximum of 10,000 values, this includes any values in nested lists. Values inside a list do not count towards the variable count.
The following information is currently inaccurate due to a variable saving bug.
Apart from limiting the amount of variables that can be on a plot, DiamondFire also limits the amount of memory saved variables can use. To prevent severe lag spikes from occurring, DiamondFire limits the uncompressed size of saved variables (in case it isn't clear, variable data compressed before it is sent to the database) to 10 MB. DiamondFire also limits the compressed size of saved variables to somewhere between 5 and 7 MB, although this limit is poorly defined because it exists due to the SQL packet size threshold, we do not define it ourselves. The compression ratio of variables (uncompressed data to compressed data, or in other words, how much the data is compressed) is usually somewhere between 3 and 5, although it is highly dependent on the types of variables stored. This table gives some information about the saved variables of some popular plots:
1000 kB = 1 MB
Sampled from the top ten plots with the largest compressed sizes, 200 Levels of Parkour has the largest compressed size of any plot. Data taken on September 30th.
| Plot | Compressed Size | Uncompressed Size | Compression Ratio | Variable Count |
| 200 Levels of Parkour (2139) | 3593 kB | 10546 kB | 2.93 | 689,951 |
| Infinite Dungeons II (41996) | 1355 kB | 5923 kB | 4.36 | 1,752,245 |
| Lawn Mowing Simulator (10626) | 981 kB | 10193 kB | 10.38 | 194,887 |
| Gemstone Parkour (43140) | 739 kB | 6615 kB | 8.94 | 1,642,674 |
| Death Run (37888) | 511 kB | 1883 kB | 3.67 | 438,400 |
1000 kB = 1 MB
Sampled from the top ten plots with the largest compressed sizes, 200 Levels of Parkour has the largest compressed size of any plot. Data taken on September 30th.
Last edited:
