Another thing that could be done is that Forge Mods would have the opportunity to “ask” Sponge whether an action is allowed or not if it is installed. Sponge would then fire an Event, if it gets cancelled, then Sponge would report that back to the Forge Mod. Doing this wouldn’t enforce grief protection, but it would be an improvement at least.
1 Like
Instead of unknown, give as much information as we can.
Couldn’t we pass the mod or class calling the method somehow?
Also in regards to protected spawns or regions I think we are thinking about this the wrong way.
How do gamemodes such as adventure work in vanilla? How does spawn protection work? What about the world border?
All of these seem like potential entry points for an API that mods would already understand if programmed correctly.
Implementing a “cancelable event for ALL changes” might deal with the problem called “griefing”… just to introduce a problem called “duping”. An example would be some mod’s mining machine: even if anti-griefing plugin had knowledge of that machine, could find out it’s owner, check against the break-allowance rules, and cancel the “setblocktoair” event to prevent damage to a private area - this would have nothing to do with spawning ‘loot’ by this machine. So instead of griefing on a private area this machine would be used for infinite ‘minig’ that area, which is effectively duping. Transactional way of handling things might help in some cases, i.e. if every block/tileenitty had a hidden ‘owner’ (not the fakeplayer, but the actual player who placed it) and any api invocations by the update method were reverted if any of them had got a cancelled event. This way no changes to an existing API are needed (as the owner could be assigned in the worldupdate cycle and mods would not even know it’s there) But even this might not be enough in lots of cases, and might even break things unless ALL of the mod’s behavior could be reverted, not only server api invocations, which is virtually impossible.
1 Like
If quarry dupes items, that’s the bug to report to the mod offer.
Just not blindly give the drop from block breaking would fix it.
That was just an example, and such things would work just fine without grief protection - they will break the block and spawn the loot. Not very funny for those whose assets would be ‘mined’ that way, but totally correct from the game mechanics point of view. But if there were some GP and the mod was absolutely ignorant of such a thing (and most, if not all of them are), then it would invoke setblocktoair (which would be cancelled, if possible and appropriate), then it would assume the block is broken (because it doesn’t realize that setblocktoair can be cancelled) and spawn the loot. And those mods developers would respond ‘blah! we develop for Forge, not bukkit/sponge/etc and on Forge there’s no such events to fire and check’ So we end up with either not working GP (because not ALL changes to the world have the appropriate event fired) or quarry/miner/bore/dril/… duping items (because they just don’t care of GP at work)
So, whats your solution?
You know, not only plugins may cancel events. Mods do it as well. Sponge will be WAY closer to the forge, than bukkit did, and sponge plugins in the beginning will technically be forge mods.
BTW I asked like 5 mod authors to fire block break event, because andi-grief plugins hadnt been logging what mods did. And guess what, they fixed it! It’s not hard to fix, and will make your mod have better compatability with others.
1 Like
Yes, many mod-authors are indeed very cooperative hen it comes to server compatibility, and sponge being a platform that is so close to forge, I think that the number of willing mod authors rise.