|
|
Post by deauth0r on Dec 26, 2019 22:34:10 GMT
i think it would be mostly useful since the most common way (that i've seen) to lag the server is to start a really huge world edit operation.
what this would do is alert the chat/admins currently online if a player begins a world edit operation that is over 50,000 blocks (alert limit can be changed if necessary).
this would most likely help the online admins quickly pinpoint who is causing lag and immediately ban them, as well as snitching telling everyone online who is lagging the server so they can create reports.
if you have any questions i am all ears.
|
|
StevenNL2000
Forum Admin 
Posts: 6,415
| Likes: 6,936
IGN: StevenNL2000
Timezone: UTC+01:00
Member is Staff. Need immediate assistance? Send a PM
|
Post by StevenNL2000 on Dec 26, 2019 23:16:57 GMT
I don't really like it for OPs because I've noticed that they can really misinterpret situations without admin tools. What I mean by that is that seeing a message for a large WorldEdit and the server lagging shortly after that doesn't mean they have anything to do with each other (but it is a great way to frame someone). Also, a screenshot of that message would not be enough evidence for a forum report even if they did cause the lag. For admins, it's essentially the same thing as totalfreedom.boards.net/thread/65572/schematic-load-idea. |
|
|
|
Post by Polaris Seltzeris on Dec 26, 2019 23:18:56 GMT
I think that instead of capping everything at a certain limit or relying on manual alerts it's possible to set up a simple blocker which blocks operations based on not only the size but also what is being done. For example, not all blocks are created equal, so you may want to cap one block at a certain reasonable limit and another block at a different limit. This also goes for the type of operation. Other than that, it would be useful to have a rate limit which doesn't completely cap limits but restricts what amount can be done in a certain reasonable time frame (ex. maybe you want a player to be able to make one million block changes, but automatically separate a huge operation like that into a few smaller operations, and have a fair amount of latency in between).
Given some time and development power, it shouldn't be hard to figure out a better system for this, it can be done.
|
|
super
Veteran Member
Among Us
Posts: 1,282
|
Post by super on Dec 26, 2019 23:38:55 GMT
I think that instead of capping everything at a certain limit or relying on manual alerts it's possible to set up a simple blocker which blocks operations based on not only the size but also what is being done. For example, not all blocks are created equal, so you may want to cap one block at a certain reasonable limit and another block at a different limit. This also goes for the type of operation. Other than that, it would be useful to have a rate limit which doesn't completely cap limits but restricts what amount can be done in a certain reasonable time frame (ex. maybe you want a player to be able to make one million block changes, but automatically separate a huge operation like that into a few smaller operations, and have a fair amount of latency in between). Given some time and development power, it shouldn't be hard to figure out a better system for this, it can be done. i agree with this. having different blocks have unique limits and restrictions (or just no restrictions) should be implemented. plus, it would be easy to put in. |
|
|
|
Post by Polaris Seltzeris on Dec 26, 2019 23:45:20 GMT
I think that instead of capping everything at a certain limit or relying on manual alerts it's possible to set up a simple blocker which blocks operations based on not only the size but also what is being done. For example, not all blocks are created equal, so you may want to cap one block at a certain reasonable limit and another block at a different limit. This also goes for the type of operation. Other than that, it would be useful to have a rate limit which doesn't completely cap limits but restricts what amount can be done in a certain reasonable time frame (ex. maybe you want a player to be able to make one million block changes, but automatically separate a huge operation like that into a few smaller operations, and have a fair amount of latency in between). Given some time and development power, it shouldn't be hard to figure out a better system for this, it can be done. i agree with this. having different blocks have unique limits and restrictions (or just no restrictions) should be implemented. plus, it would be easy to put in. You may also find that for a lot of blocks it would be better off not capping it at all but instead just splitting a huge operation into smaller ones with however much latency prevents it from shitting the server. |
|
StevenNL2000
Forum Admin
Posts: 6,415
| Likes: 6,936
IGN: StevenNL2000
Timezone: UTC+01:00
Member is Staff. Need immediate assistance? Send a PM
|
Post by StevenNL2000 on Dec 27, 2019 0:03:58 GMT
i agree with this. having different blocks have unique limits and restrictions (or just no restrictions) should be implemented. plus, it would be easy to put in. You may also find that for a lot of blocks it would be better off not capping it at all but instead just splitting a huge operation into smaller ones with however much latency prevents it from shitting the server. We already have that, that's the functionality of AsyncWorldEdit. |
|
|
|
Post by Polaris Seltzeris on Dec 27, 2019 0:16:39 GMT
You may also find that for a lot of blocks it would be better off not capping it at all but instead just splitting a huge operation into smaller ones with however much latency prevents it from shitting the server. We already have that, that's the functionality of AsyncWorldEdit. Except that doesn't completely solve the problem, which is the premise of this thread. |
|
?Robin
Club 4000 Member
caleb get off of tf
Posts: 8,027
| Likes: 8,604
|
Post by ?Robin on Dec 28, 2019 15:13:30 GMT
We already have that, that's the functionality of AsyncWorldEdit. Except that doesn't completely solve the problem, which is the premise of this thread. it's fastasyncworldedit that does what you primarily wanted, and that's already being attempted to be added once we release towards 1.15 |
|
|
|
Post by Polaris Seltzeris on Dec 28, 2019 18:52:35 GMT
Except that doesn't completely solve the problem, which is the premise of this thread. it's fastasyncworldedit that does what you primarily wanted, and that's already being attempted to be added once we release towards 1.15 So we're just buttfucked until 1.15? |
|
?Robin
Club 4000 Member
caleb get off of tf
Posts: 8,027
| Likes: 8,604
|
Post by ?Robin on Dec 29, 2019 1:42:13 GMT
it's fastasyncworldedit that does what you primarily wanted, and that's already being attempted to be added once we release towards 1.15 So we're just buttfucked until 1.15? so pretty much until next week? yes, we are my goddamn problem is that i can't get it to work with CoreProtect so i'm just deciding where to just ditch CoreProtect altogether and just use fawe's rollback system instead |
|
|
|
Post by deauth0r on Dec 29, 2019 1:46:18 GMT
So we're just buttfucked until 1.15? so pretty much until next week? yes, we are my goddamn problem is that i can't get it to work with CoreProtect so i'm just deciding where to just ditch CoreProtect altogether and just use fawe's rollback system instead by ditching coreprotect wouldn't you lose the ability to log blocks unless another system was implemented |
|
?Robin
Club 4000 Member
caleb get off of tf
Posts: 8,027
| Likes: 8,604
|
Post by ?Robin on Dec 29, 2019 2:18:43 GMT
so pretty much until next week? yes, we are my goddamn problem is that i can't get it to work with CoreProtect so i'm just deciding where to just ditch CoreProtect altogether and just use fawe's rollback system instead by ditching coreprotect wouldn't you lose the ability to log blocks unless another system was implemented "and just use fawe's rollback system instead" meaning that fawe has a logging system |
|
|
|
Post by deauth0r on Dec 29, 2019 2:48:23 GMT
by ditching coreprotect wouldn't you lose the ability to log blocks unless another system was implemented "and just use fawe's rollback system instead" meaning that fawe has a logging system ah yes excuse my retardation |
|
