It's not a matter of efficiency (or wasn't before) the issue was just the volume... I don't know how it'll react now we've moved to SQLite instead of a remote SQL Server, but I don't think this is really that valuable in the grand scheme of things myself.
It's not a matter of efficiency (or wasn't before) the issue was just the volume... I don't know how it'll react now we've moved to SQLite instead of a remote SQL Server, but I don't think this is really that valuable in the grand scheme of things myself.
Idk if you've ever used /ins, but it's incredibly watered down to the point where anything outside of blocks being removed or placed is useless for it, since everything is mushed under a 'interacted with" log. The /co i command is infinitely more useful than /ins.
It might work better with sqlite now, but you most likely won't know for sure unless you try it. If it ends up being an issue, as I said before, you can re-block it.
It's not a matter of efficiency (or wasn't before) the issue was just the volume... I don't know how it'll react now we've moved to SQLite instead of a remote SQL Server, but I don't think this is really that valuable in the grand scheme of things myself.
Idk if you've ever used /ins, but it's incredibly watered down to the point where anything outside of blocks being removed or placed is useless for it, since everything is mushed under a 'interacted with" log. The /co i command is infinitely more useful than /ins.
It might work better with sqlite now, but you most likely won't know for sure unless you try it. If it ends up being an issue, as I said before, you can re-block it.
Which is exactly what it is intended to do... And why the command exists.
Which is exactly what it is intended to do... And why the command exists.
Why, if I may ask?
Which is exactly what it is intended to do... And why the command exists.
Why, if I may ask?
To prevent abuse. It's how we rate limit things, but also because it was originally decided it was not a requirement for non-admins to have the command at all, this was designed as a way when IBR's were public for non-admins to gather / submit evidence, that is no longer the case.
since everything is mushed under a 'interacted with" log
That's because of a bug I've found in in how TFM displays the queries (in short: some API change went under the radar and TFM doesn't find a match for the interaction types so it picks the default generic one), hopefully it's fixed in the next release.
Bumping for further feedback.
Paldiu has said the bug with /ins not giving detailed info is being fixed (if not already done).
I'm wondering if EssentialsX's configurable command cooldown only works with its own ones? Can we test it on the dev server?
Paldiu Have you got a Jira ticket reference for the /ins bug.
I'm happy to un-block it given it's using SQLite but there could be a performance hit to the server rather than my DB, though again I have no means to test that because I don't fully understand how it got abused in the first place other than through hacked clients.
I'm happy to un-block it given it's using SQLite but there could be a performance hit to the server rather than my DB, though again I have no means to test that because I don't fully understand how it got abused in the first place other than through hacked clients.
People enabled the inspector and then spam clicked a bunch of blocks with an autoclicker to overload the DB. Idk if the packet spam filter has been tweaked since then to prevent that, but I do know that coreprotect has had improvements to their DB speed since then, so it shouldn't be a problem anymore.
I'm happy to un-block it given it's using SQLite but there could be a performance hit to the server rather than my DB, though again I have no means to test that because I don't fully understand how it got abused in the first place other than through hacked clients.
People enabled the inspector and then spam clicked a bunch of blocks with an autoclicker to overload the DB. Idk if the packet spam filter has been tweaked since then to prevent that, but I do know that coreprotect has had improvements to their DB speed since then, so it shouldn't be a problem anymore.
The issue wasn't CoreProtects efficiency, it was that people were using things like nukers, when you're getting hundreds of block requests per second it sorta fucked with the entire MySQL Env. It might be better on SQLite.
The issue wasn't CoreProtects efficiency, it was that people were using things like nukers, when you're getting hundreds of block requests per second it sorta fucked with the entire MySQL Env. It might be better on SQLite.
Right, my memory was kinda out of sync. Isn't there a packet limiter on the server now to prevent stuff like nukers from overloading stuff?
The issue wasn't CoreProtects efficiency, it was that people were using things like nukers, when you're getting hundreds of block requests per second it sorta fucked with the entire MySQL Env. It might be better on SQLite.
Right, my memory was kinda out of sync. Isn't there a packet limiter on the server now to prevent stuff like nukers from overloading stuff?
I think the nuke check stuff is just a block break event. Where core protect doesn't care about tfms nuke prevention the events never got cancelled. Again we can absolutely try unblocking stuff. I just haven't got the means personally to test if it'll shit the bed.
I think the nuke check stuff is just a block break event. Where core protect doesn't care about tfms nuke prevention the events never got cancelled. Again we can absolutely try unblocking stuff. I just haven't got the means personally to test if it'll shit the bed.
Oh, I'm not talking about the nuke check, I mean the packet flood check.
It's not a matter of efficiency (or wasn't before) the issue was just the volume... I don't know how it'll react now we've moved to SQLite instead of a remote SQL Server, but I don't think this is really that valuable in the grand scheme of things myself.
Idk if you've ever used /ins, but it's incredibly watered down to the point where anything outside of blocks being removed or placed is useless for it, since everything is mushed under a 'interacted with" log. The /co i command is infinitely more useful than /ins.
The next update to the TotalFreedomMod completely overhauls the Block Inspector and properly fixes the "interacted with" bug in the process.
