Proper Solution to Schematic Management

[Wild1145]

So, I've just been informed that a rather buggy work around has been created to stop spambots from being able to mass purge schematics, by blocking ops from being able to delete schematics, this is something that really is not good anyway, because the whole "TotalFreedom" part of the server, but thats not the big issue.

The big issue is that to "Work around" the work around that the bots have created by saving over schematics, an admin has suggested that //pos be blocked, this is a rather critical command in terms of WorldEdit, and will limit creativity rather heavily now. So we need to create a technical solution to allow people to actually use WorldEdit like its designed, and stop with these hack and slash work around that are actually really serving little to no purpose...

My suggestion would be for TFM to record every time someone runs //schematic save and store that in a SQLite Database along with the name of the schematic and the player, then when a player attempts to //schematic save it would check the database and if a match exists it would block the command. In terms of the delete command, this comes down to modifying WorldEdit to check the same database (Or editing this all into WorldEdit, either option does work really), but the more we put into TFM, the less we have to edit WorldEdit for every update.

I'd really appreciate any suggestions of those of you that are contributing to the project as we must find a better solution to this problem than just randomly blocking critical commands.

Or, rather than that complicated measure, we add in a piece of code that checks if a schem already exists and if it does throw up an error? I can't imagine that would be hard. Also, for the bots, maybe a playerjoinevent that detects if multiple users from the same ip join in a few seconds and ban them if that is the case?

[lemonsked]

Or why not just save the schematics as schematicname-playername.schem?
If the playername doesn't match when doing schem delete and schem save, say "That schematic is not yours."

[Wild1145]

@commodore64x While that sounds great, it doesnt work in reality, because it doesnt solve the solution of the schematic delete command.

@OxLemonxO That actually sounds like a simpler idea, the only drawback would the entity of it would need to be managed from WorldEdit, meaning more WorldEdit changes every update, however more updates would have to be done either way at the rate this is going.

@OxLemonxO i appreciate your idea , not bad

[xItsNickHD]

@OxLemonxO What if they're cracked?

[lemonsked]

@xItsNickHD It's still usernames- spambots cant login as random usernames and mass delete schematics.

Ok so half the problem is solved right? Deleting schems is blocked, but the problem is overiding them. What about in the tf fork of worldedit adding a if (schemname.exists) or something similar, I would imagine there would be a string that defines a schem name then you could go from there. As for schem del, is blocking it only a temporary fix? If it isn't then in the tf fork of worldedit maybe a check for admin around the whole code block would suffice?

I think this issue calls for better TFM to worldedit compatibility, while still being to run without each other. If Worldedit can access TFM classes then it would make it alot easier to check ranks, etc. This is probably way down the road but I am just pointing it out.

I have investigated this issue and found that a simple if (filename.exists() is all that is needed to stop this issue, I might make a PR later. The code will check if a file with that name already exists.

Here is the full code:
--REDACTED--
That is all that is needed to stop command overwrites.
Problem solved?
That is if I can successfully compile Worldedit...

All good, will make a PR now. It worksssssss.

[lemonsked]

@commodore64x No, what we need is a better solution then doing that. People should be able to delete their own schematics.