Posts by videogamesm12

    @UnderTails#15273 Currently, the TotalFreedomMod has its custom worlds (flatlands, adminworld, and masterbuilder world) hard-coded. This suggestion is to change the world system to ditch this system of hard-coding worlds in favor of something that can be configured by anybody without having to recompile the plugin to do so.

    To make the TFM more attractive to server owners (not just our own), an idea I had would be to make the custom world system currently present in the plugin completely configurable. It would generate worlds and apply protection based on parameters defined in a configuration file.


    Here are some benefits to this idea:

    • This would allow server owners to add or remove as many worlds to their server as they wish without having to compile the plugin
    • Suggestions to add or remove worlds would not require developer input to implement, as it would only require a single configuration file to be changed

    Obviously, it would require some developer work to implement this, but I'd argue that it would be worth it in the long run.


    What do you think? Should this be implemented? Give your thoughts below.

    So, here's a rundown of why CoreProtect is acting weirdly in the form of a graph that I totally didn't just make in MSPaint in like 5 minutes:
    https://cdn.discordapp.com/attachments/769659654186860568/833310933170389012/unknown.png


    CoreProtect appears to be doing its job correctly, but the problem is the data that is coming into the plugin in the first place. We use BlocksHub to make AsyncWorldEdit's changes logged by CoreProtect. As BlocksHub seemingly mangles the NBT data but doesn't affect AsyncWorldEdit's session data (including NBT), it would explain why CoreProtect fucks up and why //undoing doesn't.


    The proper solution (for our current setup) would be fixing BlocksHub. Hopefully this clears up some confusion as for which plugin is causing the problem.

    @UnderTails#15010 What if the griefer leaves before we can undo it? When a player leaves, their session data (and thus the ability to undo their edits) goes away. This is permanent too.

    Quote

    @UnderTails#15007 well if the griefer doesn’t leave we should try it

    "Hey, griefer! Could you not leave for a few seconds so that we could roll back what you did? What do you mean no??"

    Quote

    @UnderTails#15007 its not a solution to the problem 100% of the time but it can really help out some people

    The solution causes more problems than the problem itself.

    Quote

    @UnderTails#14999 it’s been 8 months and i don’t think a single person believes it’s ever going to be fixed at this point

    We literally just did testing a few days ago and established a very possible lead (an outdated version of BlocksHub).

    Quote

    @UnderTails#14999 i think what we should do is get creative and think of different ways to fix griefs

    I think this is a risky way of doing it. //undoing won't do any good if the griefer leaves (and therefore wipes all of their session data) before we can //undo them. It also has a good chance of borking the CoreProtect record (which the cause for all sorts of problems already).

    @UnderTails#14995 A few things.

    • We've already isolated the potential cause for the CoreProtect issue (BlocksHub sucks) and someone is looking into fixing it.

    • The problem becomes a matter of record. //undoing something fucks with the record.

    • They can use //brush regardless of their freeze status.

    Quote

    @UnderTails#14988 what if we add /sudo, not for trolling but so if a griefer griefs something, and admin can freeze them, /sudo to make them //undo

    Years ago (before the days of CoreProtect), this was actually administrative protocol. You'd //undo and it would undo their edits a certain amount.


    Those days are over, and we already have /gcmd.


    Object.