BuildCraft|Core

BuildCraft|Core

7M Downloads

Quarry: Reports its location as the currently mined block, not the actual quarry

Opened this issue · 10 comments

commented

Hi All,

I'm currently working on a Thermos (Cauldron) compatibility addon that will allow quarries to be used without risk of griefing.

This will primarily be for use on Hybrid servers, like Thermos or KCauldron.

At present BC is reporting the location of the FakePlayer as the location of the block being broken, not the quarry, which means it is impossible to do check to see if the quarry can break / place blocks there.

Can this possibly be adjusted? My plugin runs off the bukkit side of the hybrid server which relies on the FakePlayer reporting its location properly.

The location of the block is present in the block object in both forge and bukkit events, so having the fakeplayer location as that is pointless.

The End goal for Industrial miner grief protection will be;

  • If a player places a quarry in a location that is protected by factions, it assumes the player had (and the quarry shall have) build rights there.... so it will mine.
  • If a player places a quarry in unclaimed land, it will only let the quarry mine in unclaimed land as it cannot guarantee the player had rights to do so elsewhere.

Side note: If you could name the FakePlayer the same as the placing player, or have it as an attribute of the BuildCraft fakeplayer, that would us to support grief prevention for quarries 100%.

The end result for this will support Grief prevention, Towny, Factions, FactionsUUID, FactionsOne, Redprotect, Worldguard and many other plugins (I have the code for this ready).
Example is for factions.

Example of what I'm trying to do:


    @EventHandler(priority = EventPriority.HIGHEST, ignoreCancelled = false)
    public void onBreak(BlockBreakEvent event) {
        Player player = event.getPlayer();
        Block block = event.getBlock();
        Faction factionForPlayer = getFactionForChunk(player.getLocation().getChunk());
        Faction chunkFaction = getFactionForChunk(block.getChunk());

        if ((chunkFaction.getId().equals("none") || factionForPlayer == chunkFaction) && (event.getPlayer().getName().contains("[BuildCraft]") || event.getPlayer().getName().contains("[Mekanism]"))) {
            // This is where we allow denied break events.
            PerimeterPlugin.throwMessage("info", "Uncancelling a cancelled break event at: " + block.getLocation() + " for " + player.getName() + " at location: " + player.getLocation());
            event.setCancelled(false);
        }
    }
commented

@everyone Thank you all for this one! :) My players are so happy!
For anyone who sees this issue and runs Factions on their cauldron server - check out https://www.spigotmc.org/resources/perimeter.22469/ to make use of this properly.

commented

I've been informed that Forge requires a fake player to have a 0,0,0 position.
You'd have to have a unique fake player for each quarry upon further thought (to report different locations), which would be annoying for you guys.
Nevermind :)

commented

Who informed you of that? Fake players can be moved very easily, and I don't think forge requires anything about the player fired in the event.

On 30 Apr 2016, at 06:50, DraksterAU [email protected] wrote:

I've been informed that Forge requires a fake player to have a 0,0,0 position.
You'd have to have a unique fake player for each quarry upon further thought (to report different locations), which would be annoying for you guys.
Nevermind :)


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

commented

If that's the case ...

commented

I'll take that one up for 1.7.10. I want to release a 7.1.17, and this could actually be useful.

commented

Thank you!!! :)
Any idea when .17 will be available?

commented

Hi @AlexIIL Is there any chance you're updating to v7.1.17 for BC 1.7.10?
This change is something I'm hoping will be included in an official release, as Cauldron servers which benefit from this don't exist for 1.8 :)

commented

At the moment @asiekierka controls the 1.7.10 releases, so its basically waiting for him to release it.

Unless he wants me to also take control of 1.7.10 as well.

commented

I guess I could release it... Anything else you'd like to see done in 1.7 before release?

commented

I don't have anything specific for 1.7.10, no. Although the 1.8.9 branch has a few fixes that could be released at the same time.