dog
Full Member
Leaving this world is not as scary as it sounds.
Posts: 218
| Likes: 80
|
Post by dog on Aug 1, 2020 19:14:42 GMT
vouch
|
|
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 Aug 1, 2020 19:44:44 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. 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. There is a configuration issue that Seth hasn't fixed yet that is causing CoreProtect to fail to connect to the MySQL database that we have set up. Apparently CoreProtect automatically falls back to SQLite when that happens, so yes, we are currently using SQLite.
|
|
grntbg
Full Member
Omnis anima potestatibus sublimioribus subdita sit.
Posts: 295
|
Post by grntbg on Aug 2, 2020 6:28:03 GMT
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. 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. There is a configuration issue that Seth hasn't fixed yet that is causing CoreProtect to fail to connect to the MySQL database that we have set up. Apparently CoreProtect automatically falls back to SQLite when that happens, so yes, we are currently using SQLite. So it seems like the two posts I quoted justify their positions with a bug, and for that reason I don't see any valid technical explanation as to why giving block inspection to operators is a bad idea.
|
|
|
Post by Godfather on Aug 5, 2020 14:50:31 GMT
Bump, has a lot of vouches so.
|
|
|
Post by superryn on Aug 11, 2020 21:22:36 GMT
vouch
|
|
Alosion
Veteran Member
Posts: 589
| Likes: 237
|
Post by Alosion on Aug 11, 2020 21:53:11 GMT
Vouch
|
|
anthony
Member
Posts: 27
| Likes: 7
|
Post by anthony on Aug 12, 2020 23:49:10 GMT
vouch
this server is met with a lot of griefers and this would help on my player conduct reports
|
|
|
Post by iIFrozenFireIi on Aug 15, 2020 2:18:05 GMT
vouch
|
|
|
Post by Telesphoreo on Aug 15, 2020 3:36:55 GMT
The problem is that CoreProtect forcefully gives all players who are OP rights to run any and all commands. CoreProtect has this hard coded in, despite having the permissions properly setup in a way that TFM could set it up from the plugin.yml
|
|
lyicx
Full Member
Asst. Server Liaison
fuck raid and fuck babe ;)
Posts: 234
| Likes: 471
|
Post by lyicx on Aug 15, 2020 5:59:12 GMT
The problem is that CoreProtect forcefully gives all players who are OP rights to run any and all commands. CoreProtect has this hard coded in, despite having the permissions properly setup in a way that TFM could set it up from the plugin.yml wouldn't the only way to fix it would be to give people all the perms they'd have as op instead of giving them op? i assume this would be easier said then done, not an ideal fix and mean a lot of modification to TFM right?
|
|
|
Post by Telesphoreo on Aug 15, 2020 6:07:24 GMT
The problem is that CoreProtect forcefully gives all players who are OP rights to run any and all commands. CoreProtect has this hard coded in, despite having the permissions properly setup in a way that TFM could set it up from the plugin.yml wouldn't the only way to fix it would be to give people all the perms they'd have as op instead of giving them op? i assume this would be easier said then done, not an ideal fix and mean a lot of modification to TFM right? What you're referring to is "fake opping". Commodore had this idea years ago to use a permissions plugin to give players almost all permissions so we wouldn't have to modify anything. Although this goes against the core value of TF that everyone is OP. The only way to fix it is to remove the code in coreprotect. I theoretically could as I am a coreprotect dev, although the server had issues when I tried doing this before
|
|
lyicx
Full Member
Asst. Server Liaison
fuck raid and fuck babe ;)
Posts: 234
| Likes: 471
|
Post by lyicx on Aug 15, 2020 8:56:28 GMT
wouldn't the only way to fix it would be to give people all the perms they'd have as op instead of giving them op? i assume this would be easier said then done, not an ideal fix and mean a lot of modification to TFM right? What you're referring to is "fake opping". Commodore had this idea years ago to use a permissions plugin to give players almost all permissions so we wouldn't have to modify anything. Although this goes against the core value of TF that everyone is OP. The only way to fix it is to remove the code in coreprotect. I theoretically could as I am a coreprotect dev, although the server had issues when I tried doing this before yeah i didn't think that would sit right with tf. and yeah thats worth a shot, although i heard core protect is so messy
|
|