Anti-Griefing Update! 8/15/16

Discussion in 'Empire Updates' started by Aikar, Aug 14, 2016.

Thread Status:
Not open for further replies.
Page 15 of 16
  1. How is the senior staff service coming along? I haven't heard anything back about it and I'm getting close to being able to have people out to help with some things. Just wanna make sure its not in vain and that the griefers leave with broken hearts instead of breaking my base lol.
    Gawadrolt, Sep 1, 2016
    #281
  2. I have at least not heared anything about the SS after i did send in 3 protection requests (1 outpost)
    RichRayM, Sep 1, 2016
    #282
  3. Remember that just because the system lets them remove the block, doesn't mean they are free to anytime they want.
    The goal of the system isn't perfect permissions, but to restrict griefers from breaking it, by narrowing the list of who's allowed to break it down to unlikely griefers.

    If you do a group project, there should be some form of communication in game or on forums about this, so if for some rare reason one of those people do come and 'grief', you can still get staff involved.

    The issue with locking to a single owner is that you may accidentally place a block you didn't mean to, and then be unable to remove it yourself. (or say you only intended to put some blocks down temporarily, then come back later after groups disbanded and now you cant get them back)

    It's important for players to not stress out over who's on the permission list. Griefing rules still apply. It's merely to limit it to the 0.0001% chance of it happening.

    EMC has a lot of complex stuff, and Id rather us keep it simple where we can.
    Aikar, Sep 1, 2016
    #283
    Lordess_Spartan, ANubIsWe3, ThaKloned and 3 others like this.
  4. Finally getting these updates out!

    • Group Build mode has been changed to a toggle. When in Build Mode, everyone in the group will be placed on the list of who can break the block, but the placer is still the "Owner". Only the Owners friendslist is checked for trust relationships. So the list goes to "Placer + Trust Relationships + People in group at time"
    • Trying to break a block that another protected block depends on (such as the block under a rail), if that block is unprotected, then it will check the dependent blocks. If the block under happens to be protected, and the user has permission, then they will be able to break it regardless of dependent blocks (otherwise, someone could slap a button on your diamond block and prevent you from retrieving it)
    • Limits for SS doing protection commands has been raised so they can protect your outposts easier!
    Aikar, Sep 17, 2016
    #284
    crazyminerpete, ANubIsWe3, 607 and 1 other person like this.
  5. Assuming I understood correctly, but doesn't this make the blockbreak feature somewhat redundant? If I understand correctly then the people in the group can only break the block for as long as they are in the group. Which is basically the same behavior as group blockbreak.

    Or does the access for the people in the group sustain after they left the group?

    UPDATE / edit: I should try things out before commenting :rolleyes:

    I got confused with your "People in group at time" comment. "People in group at time of placing block" covers it a bit better I think, but the comment in-game covers this completely.
    ShelLuser, Sep 17, 2016
    #285
    BlitzAttack, We3_MPO and Vortixin like this.
  6. Rail track and semi-secret passages problem

    I have several rail tracks that are obviously known to many more people than I was aware of.
    Some of the stations have "secret passages" where one has to break few blocks to get through.

    Now I'm in the situation that I can not go through my own "secret passage", because the blocks now belong to someone else.

    Also, I can not revert some changes on the railway track, because they were made by some people I don't know at all. Even with a common block - netherrack.

    What to do?

    My impression that this anti-grief system might soon lead to a big mess in places used by several or even many people.
    M4ster_M1ner, Sep 17, 2016
    #286
    Lordess_Spartan, ANubIsWe3, ShelLuser and 1 other person like this.
  7. We (Regen outpost) had the same problem but we resorted to using a redstone powered door: after placing a redstone torch a door opens and the torch drops again.

    The only other options you have is to use common blocks for the door. So cobble or dirt. Or get everyone to use /noprotectmode before placing those blocks. This command completely turns off block protection.

    Ask staff (a moderator) for help. They can overrule that protection and help out. That way you can replace those with blocks you actually own.

    I've needed help a few times myself during a Frontier restoration session and it's my experience that the staff will do everything they can to help you out. Just try to work with them.

    So: find a moderator, explain the situation, go back to that location and then they can teleport to you and try to help you resolve the problem.

    I'm very mixed about that. I tend to agree with you, but on the other end I also don't think it's illogical to assume that once you are playing with others then you're bound to befriend some of those players as well. And that creates options to share ownership on blocks.

    For example, I'm part of an outpost and I've befriended several players there, including the leader / founder of the outpost. So basically he can overrule anything I do within the outpost and I think that's a good thing. So as long as you have one central figure and all the involved players befriend him then you got some kind of a failsave in place.

    To be honest I think it's a bit too early to tell if this will create a mess or not. Sure, sometimes you may need to adapt to the new thing (like with that redstone door) but you'll get many other securities back in return.
    ShelLuser, Sep 17, 2016
    #287
    ANubIsWe3 and 607 like this.
  8. With this new update, there is now a bug where protected sticky pistons can no longer retract my protected blocks. Even when my blocks aren't protected, (noprotectmode) the piston still wont retract the block? And when the piston is placed in noprotectmode, then it wont extend the unprotected block??? (Also everything works fine in town with no issue)
    This basically means all piston doors and redstone mechanisms are broken in the frontier currently... :(
    Zrugite, Sep 17, 2016
    #288
    ANubIsWe3, M4ster_M1ner, tuq1 and 2 others like this.
  9. It's usually best to PM both Aikar & Chickeneer (just use the link) when you found a bug and report it to them directly. This way they're bound to notice.

    On that subject: if you ever come across a bug which could be abused then always PM them and never share it in public. That's to prevent cheating. It doesn't apply here, but I wanted to mention it just in case.
    ShelLuser, Sep 17, 2016
    #289
    607, ANubIsWe3 and Zrugite like this.
  10. I believe that this bug should be made public, because if you use the redstone, then it will break, and most likely you will have to rebuild a part of it... or even all of it... So telling all people to not use sticky piston related contraptions in the meantime, will save a lot of time for people...
    Tuqueque, Sep 17, 2016
    #290
    jkjkjk182, ESSELEM, 607 and 2 others like this.
  11. It can work well only for very simple circumstances, but life is never simple.
    It is wise to keep things natural, to follow natural logic.
    Natural is that, who is the owner of a block, in 99% situations depends on where the block is placed and not on who placed it.

    The source of all of this problems and hassle is that we are trying to work around, to patch and to bend right a system that is built on a wrong foundation.
    M4ster_M1ner, Sep 17, 2016
    #291
    607 and ShelLuser like this.
  12. talk to me ingame next time, I had a few idea's but you logged off when i got on...
    finch_rocks_1, Sep 17, 2016
    #292
  13. will fix the pistons soon as we can -- but on the passages, soon we will also make it so if you break a block, then replace it, it will restore the previous ownership information if replaced in a period of time, to accommodate these secret door setups.
    Aikar, Sep 17, 2016
    #293
    finch_rocks_1, TomvanWijnen, 607 and 3 others like this.
  14. ive noticed that piston interaction even with friends blocks are glitchy, ive had to rebuilt my wither farm that cadgamer101 helped with because of it.
    bitemenow15, Sep 18, 2016
    #294
  15. If you use group build mode while building it together, itll behave better now.

    code looks like this

    final List<UUID> pistonOwners = AntiGrief.getPlacers(event.getBlock());
    boolean isFrontier = Worlds.isFrontier(event.getBlock().getWorld());
    for (Block block : event.getBlocks()) {
    if (isFrontier) {
    final List<UUID> blockPlacers = AntiGrief.getPlacers(block);
     if (!blockPlacers.isEmpty() && !Util.hasIntersection(blockPlacers, pistonOwners)) {
    event.setCancelled(true);
    return;
    }
    }

    which btw after last night piston issues should be fixed
    Aikar, Sep 18, 2016
    #295
    BlitzAttack, ShelLuser and ForeverMaster like this.
  16. Looks like Chinese to me, do you give classes Aikar? :p (Apologies to any chinese actually reading this, just making a joke)
    PetezzaDawg, Sep 18, 2016
    #296
    Vortixin likes this.
  17. Does event.getBlocks() return exactly the list of blocks that will be moved?

    Yesterday, a sticky piston would push a block, but wouldn't pull it back.
    Please check that as well.

    What about owner of the block which powers the piston ... etc - doesn't that get too complicated?
    M4ster_M1ner, Sep 18, 2016
    #297
  18. Just wanted to say thanks to Aikar and the Dev team for fixing the piston bug. My machines are now working their wonders again!!

    Y'all ROCK!
    Coorisnar, Sep 18, 2016
    #298
    Vortixin and ShelLuser like this.
  19. The bug was that I accidently had blockPlacers.isEmpty || !hasIntersection, which didn't match the logic before this update of blockPlacer != null && blockPlacer == pistonPlacer
    So its functionally the same now as before sats update.

    Checking power block is too much. If you dont want pistons pushing your blocks, dont put a piston in place that could push your blocks for someone to ignite.
    Aikar, Sep 19, 2016
    #299
    ANubIsWe3 and ShelLuser like this.
  20. This is lame.
    bonzd67, May 1, 2020
    #300
    jacob5089, SoulPunisher, bitemenow15 and 2 others like this.
Page 15 of 16
Thread Status:
Not open for further replies.