Gommeh
Veteran Member
dammit ryan and rylie
Posts: 2,744
| Likes: 778
|
Post by Gommeh on Aug 1, 2020 0:10:37 GMT
Vouch, this could be a huge help when there are no admins on.
|
|
|
|
Post by DragonSlayer2189 on Aug 1, 2020 0:12:04 GMT
I object, we have had discussions about this many times before, and while its a great idea, theres one major flaw, if someone turns on the inspector and starts using it a lot, it will make it so that admins cant use it because it will display the "database is busy" error, allowing for ops to easily prevent admins from doing their job with no concrete way of finding out who is doing it.
unless there is a solution to this problem my vote will remain an object
|
|
XenVoltz
Veteran Member
Posts: 2,461
| Likes: 1,488
|
Post by XenVoltz on Aug 1, 2020 0:12:50 GMT
Vouch. I’m pretty sure OPs we’re suppose to get logstick at some point, but I don’t think that ever happened.
|
|
Daniels
Veteran Member
Posts: 349
| Likes: 197
|
Post by Daniels on Aug 1, 2020 0:16:27 GMT
I object, we have had discussions about this many times before, and while its a great idea, theres one major flaw, if someone turns on the inspector and starts using it a lot, it will make it so that admins cant use it because it will display the "database is busy" error, allowing for ops to easily prevent admins from doing their job with no concrete way of finding out who is doing it. unless there is a solution to this problem my vote will remain an object Punish the people who are intervening with administrative duties. Ban them for 24 hours or so. And anyway, it isn't completely life changing as you can easily just ban the culprit which would take 2 minutes or so and carry on. |
|
elmon
Veteran Member
Asst. Server Liaison
fionn sucks
Posts: 1,476
| Likes: 1,842
|
Post by elmon on Aug 1, 2020 0:23:28 GMT
I object, we have had discussions about this many times before, and while its a great idea, theres one major flaw, if someone turns on the inspector and starts using it a lot, it will make it so that admins cant use it because it will display the "database is busy" error, allowing for ops to easily prevent admins from doing their job with no concrete way of finding out who is doing it. unless there is a solution to this problem my vote will remain an object That's ridiculous inspect is literally busy for a fraction of a second |
|
|
|
Post by ???TheHour on Aug 1, 2020 7:43:30 GMT
I object, we have had discussions about this many times before, and while its a great idea, theres one major flaw, if someone turns on the inspector and starts using it a lot, it will make it so that admins cant use it because it will display the "database is busy" error, allowing for ops to easily prevent admins from doing their job with no concrete way of finding out who is doing it. unless there is a solution to this problem my vote will remain an object Isn't that just an issue with how TF actually has the db setup |
|
Jay
Veteran Member
TFM is a mess.
Posts: 2,756
| Likes: 199
|
Post by Jay on Aug 1, 2020 9:07:36 GMT
If seth integrated permission nodes into the TFM rank class, vouch for /co i on ops.
If not, obviously can't be a thing.
|
|
|
|
Post by operatethedope on Aug 1, 2020 10:46:43 GMT
vouch
|
|
|
|
Post by Captainclimber on Aug 1, 2020 10:58:15 GMT
Vouch
|
|
fleshy_
Full Member
goodbye proboards
Posts: 282
|
Post by fleshy_ on Aug 1, 2020 12:06:55 GMT
vouch
|
|
burger
Registered
fionn is overated
Posts: 0
| Likes: 446
|
Post by burger on Aug 1, 2020 13:08:52 GMT
I object, we have had discussions about this many times before, and while its a great idea, theres one major flaw, if someone turns on the inspector and starts using it a lot, it will make it so that admins cant use it because it will display the "database is busy" error, allowing for ops to easily prevent admins from doing their job with no concrete way of finding out who is doing it. unless there is a solution to this problem my vote will remain an object Punish the people who are intervening with administrative duties. Ban them for 24 hours or so. And anyway, it isn't completely life changing as you can easily just ban the culprit which would take 2 minutes or so and carry on. Please explain how we would do that, core protect is a toggle command. Once you run co I it toggles on core inspect. When a player breaks blocks with co I on the system figures out who edited what blocks. Spam clicking would force co inspect to keep loading up edit data about certain blocks causing the plugin to slow down. |
|
elmon
Veteran Member
Asst. Server Liaison
fionn sucks
Posts: 1,476
| Likes: 1,842
|
Post by elmon on Aug 1, 2020 13:31:19 GMT
Punish the people who are intervening with administrative duties. Ban them for 24 hours or so. And anyway, it isn't completely life changing as you can easily just ban the culprit which would take 2 minutes or so and carry on. Please explain how we would do that, core protect is a toggle command. Once you run co I it toggles on core inspect. When a player breaks blocks with co I on the system figures out who edited what blocks. Spam clicking would force co inspect to keep loading up edit data about certain blocks causing the plugin to slow down. there's probably a way to integrate turning off the inspect permission using a TFM toggle command like /disableinspect or something |
|
Daniels
Veteran Member
Posts: 349
| Likes: 197
|
Post by Daniels on Aug 1, 2020 15:15:49 GMT
Punish the people who are intervening with administrative duties. Ban them for 24 hours or so. And anyway, it isn't completely life changing as you can easily just ban the culprit which would take 2 minutes or so and carry on. Please explain how we would do that, core protect is a toggle command. Once you run co I it toggles on core inspect. When a player breaks blocks with co I on the system figures out who edited what blocks. Spam clicking would force co inspect to keep loading up edit data about certain blocks causing the plugin to slow down. That's ridiculous inspect is literally busy for a fraction of a second You could also possibly integrate a system where it shows who has /co i currently on, and exclude the admins. I am 100% sure that not every single person on the server is going to have /co i on at the same time. |
|
grntbg
Full Member
Omnis anima potestatibus sublimioribus subdita sit.
Posts: 295
|
Post by grntbg on Aug 1, 2020 18:51:43 GMT
I object, we have had discussions about this many times before, and while its a great idea, theres one major flaw, if someone turns on the inspector and starts using it a lot, it will make it so that admins cant use it because it will display the "database is busy" error, allowing for ops to easily prevent admins from doing their job with no concrete way of finding out who is doing it. unless there is a solution to this problem my vote will remain an object This isn't how SQL works, and is a non-issue. If the server is avoiding SQLite for database management (as it should be) then multiple reads should not hinder the database's operation. |
|
grntbg
Full Member
Omnis anima potestatibus sublimioribus subdita sit.
Posts: 295
|
Post by grntbg on Aug 1, 2020 18:59:05 GMT
Punish the people who are intervening with administrative duties. Ban them for 24 hours or so. And anyway, it isn't completely life changing as you can easily just ban the culprit which would take 2 minutes or so and carry on. Please explain how we would do that, core protect is a toggle command. Once you run co I it toggles on core inspect. When a player breaks blocks with co I on the system figures out who edited what blocks. Spam clicking would force co inspect to keep loading up edit data about certain blocks causing the plugin to slow down. CoreProtect and the MySQL/MariaDB DMBS do not "load up edit data" in the way you are describing. Information is stored in files either unitarily (think of flat files) or split between tables (possibly between each field of data required by the plugin to display logs) rather than being read like an upload/download. The plugin doesn't slow down because of read requests, and the response period at which you receive logdata wouldn't be significantly halted by one player. This is all predicated on my assumption that the server isn't using SQLite, as there's already been an (approved) suggestion on the subject for some years now. |
|
[/spolier]
