Open Wild1145 opened 8 years ago
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?
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."
@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
@OxLemonxO What if they're cracked?
@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.
@Commodore64x No, what we need is a better solution then doing that. People should be able to delete their own schematics.
@Commodore64x try to fix asyncworldedit for tfm and maybe stop making drama with leonard
@OxLemonxO 1 down 1 to go. I have made it so people cannot overwrite schems, not that people can't delete them. I will look into that now and @marcocorriero is that going to be added to TF?
@OxLemonxO that would require a major rewrite of the schem command to add a space where the plugin writes the name of the person who made the schem in the first place!
What is wrong with async worldedit?
@Commodore64x , is pulling some shitloads of errors
@Commodore64x ill post the jar download here, try to run into a tfm server .
https://www.dropbox.com/s/s7oenhocxh1yk75/AsyncWorldEdit.jar?dl=0
@Wild1145 I have implemented a fix for this which you can check out at my repo (https://github.com/Commodore64x/TF-WorldEdit) Also @marcocorriero I have fixed the asyncworldedit problems and it should work fine now.
@Commodore64x @marcocorriero A-SyncWorldEdit is not part of this discussion, that needs to be raised on the forums as a possible plugin addition.
In regards to your fix, its not so much as a fix but again a work around. All that does is block everyone and anyone from overwriting any schematics, even their own. All a bot would need to do is come on and spam //schematic save
@Wild1145 you realise how ridiculous that sounds??? With the ability to use every character in the alphabet, numbers and some special symbols there is almost an UNLIMITED amount of names that a schematic could use. A bot would have to be left on the server for YEARS to use up all the names. I believe to what you suggested my way is kinda less stressful and it works. Besides, that would happen anyway without my fix, a bot could still come on and spend years overwriting all the schems and creating new ones. You also forget that you have to select and area first, copy it, AND THEN save a schem. No offence @Wild1145 but the idea of a bot using up all the names is just stupid.
@Commodore64x You need to calm down. This repository is a place where civil discussion is to take place. If you cannot continue to discuss your ideas in an ordinary manner, please leave this repository.
Regarding your comments. There's no evidence/calculations backing your claims. How do you know it will take years? Do you need to exceed all the names, or just the ones under 8 characters for players to get annoyed. Does it even matter? These are all not addressed and you should consider these questions as well.
@Commodore64x Also, as I said yesterday when the last attacks happened we had multiple bots on at once. Yes it probably would take a single account far longer to do the damage than we would allow, especially given command throttling systems in place, however if i have 20 or even 30 bots join when its quiet, I could easily do it in a far far shorter time, and at the very least cause a great inconvenience to everyone.
Well then there is no solution for this problem. The only way to fix this is to stop spambots which I haven't heard any good suggestions of doing so.
@Commodore64x I suggested one that would work perfectly above...
@Wild1145 no offence but that was way too complicated and frankly stupid to go to that much trouble to do what you could do in the plugin.
@Commodore64x Look at my comment above.
Ok, I have thought a bit about this and have come up with a solution: Adding to @OxLemonxO's solution when a user does /schem save {name} the username of that user is appended onto the end. When someone wants to delete the schematic the plugin will check for staff then if the player is not staff check for the appended words in the schem name. If a player wants to overwrite the schem my solution will work fine, once again a check for admin will be in place though.
@Commodore64x That is a good idea. @StevenLawson already has a similar system in place for his own WorldEdit saves, this system can be easily expanded to every player on the server.
@Commodore64x Why not do the same thing for overwriting schematics instead of just blocking it?
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.