Cuberite Forum
ProtectionAreas (built-in) - Printable Version

+- Cuberite Forum (https://forum.cuberite.org)
+-- Forum: Plugins (https://forum.cuberite.org/forum-1.html)
+--- Forum: Plugin Releases (https://forum.cuberite.org/forum-2.html)
+--- Thread: ProtectionAreas (built-in) (/thread-1155.html)

Pages: 1 2 3 4 5 6 7


RE: ProtectionAreas (built-in) - Boo - 02-11-2015

maybe I can not wait this pluginBig Grin:D:D


RE: ProtectionAreas (built-in) - DarthCalvin - 04-06-2015

Greetings,

This is a very useful plug-in and I thank you for creating it. However, would it be possible to include protection from Mob damage in your protected area with this plug-in? I have managed to protect my spawn but am worried about mischievous types luring in a few creepers and exploding my grand temple...

Darth.


RE: ProtectionAreas (built-in) - xoft - 04-07-2015

This is not currently possible, the explosion API is missing. An approximation would be possible but it would not be 100% effective.


RE: ProtectionAreas (built-in) - DiamondToaster - 04-07-2015

Maybe use the OnExploding hook, create a new bounding box that represents that area, and return true if it is in the expanded box? (Expanded to make sure explosions don't happen inside or near the area)


RE: ProtectionAreas (built-in) - xoft - 04-07-2015

The problem is in MCS's implementation of explosions. It doesn't use the Vanilla's ray model, but instead a custom, inferior one. The hook then provides no means of actually determining what blocks are affected by the explosion, only an approximation via the relative ExplosionSize parameter.


RE: ProtectionAreas (built-in) - DiamondToaster - 04-07-2015

So, the implementation should be rewritten in order to use a predictable ray model? Then using Lua, you could get a table of blocks that are affected, iterate through that, then stop any individual blocks from moving under certain conditions using a hook? Or maybe a hook that goes like HOOK_BLOCK_DISPLACED that is triggered per block or something like that?


RE: ProtectionAreas (built-in) - xoft - 04-07-2015

I like the first variant more - a single hook call providing all the data. That would require a new class, though - array of block coords and blocktypes / metas, and bindings for that class, so that the hook could add or remove individual blocks being blown up.


RE: ProtectionAreas (built-in) - DiamondToaster - 04-07-2015

So, something like:
class cBlockToEntityData
{
    public:
        Vector3i Position;
        int GetBlockType(); // returns E_BLOCK type
        int GetMetaData(); // returns E_META data
        cBlockInfo GetBlockInfo(); // returns a cBlockInfo
        // Excuse my lack of knowledge of the internals of MCServer...
}

Then the Lua bindings would send table full of these:

function OnExploding(World, ExplosionSize, CanCauseFire, X, Y, Z, Source, SourceData, AffectedBlocks)
    -- AffectedBlocks is a table full of cBlockToEntityData
    for n, k in pairs(AffectedBlocks) do
        if k:GetBlockType() == E_BLOCK_DIRT then
            table.remove(AffectedBlocks, n)
        end
    end
    -- send the modified table to the server to be processed
end



RE: ProtectionAreas (built-in) - xoft - 04-07-2015

Rather than pushing the entire table to Lua and back, it'd be better to wrap the array into an object, cBlockArray:
function OnExploding(World, ExplosionSize, CanCauseFire, X, Y, Z, Source, SourceData, AffectedBlocks)
    assert(tolua.type(AffectedBlocks) == "cBlockArray")  -- It is an object with its own operations

    -- Example: do NOT explode dirt:
    for n = AffectedBlocks.GetCount() - 1, 0, -1 do  -- count from GetCount() - 1 down to 0
        if (AffectedBlock:GetBlockType(n) == E_BLOCK_DIRT) then  -- Get the n-th block's type
            AffectedBlocks.Remove(n)
        end
    end
    return false
end



RE: ProtectionAreas (built-in) - DiamondToaster - 04-07-2015

Ah, that's also a good idea. Saves a bit of overhead, especially when you decide to go crazy with WorldEdit and set off 100000+ TNT.