Doesn't protect AE2 cables, facades, terminals, etc, nor Malisis Doors

[ghost]

Would be nice to see support for these added, with AE2 cables being quite important (using GriefPrevention 9.1 with allowBuild() issue fixed).

Thanks for the releasing the plugin by the way, works quite well!

[thomas15v]

Akward, this worked good with 1.4.7-1.6.4. Are you sure your using the most recent version of forge-permittor?

[ghost]

Yes, although this is 1.7.10 with AE2 (a full rewrite I believe), so the packets or events the mod fires may be different.

[thomas15v]

Yeah, I know about AE2 and I plugin my mod on 1.7.10, and it was working with this modification: 25491c58858d4ab2298e97a6791ec12ea8468f3d. I am unsure why it doesn't work anymore now.

Could you enable debug mode and interact with the items and give me the output ?

[ghost]

How do I enable debug mode?

[thomas15v]

Its in the config.yml set other.debug to true.

But after reading #2 I am guessing something in griefprevention causing this issue.

[ghost]

Maybe. If you fix the GP issue, I can try the latest builds.

[thomas15v]

@Nentify the main problem is that I would like to make this plugin compatible with every minecraft version. It is sad the griefprevention changed his API. Because if I update now, it will break compatiblity with older versions of griefprevention. I test if 9.1 works on 1.4.7. if that it the case I can quickly update it. If it isn't it will take a bit longer, because I will need to write a reflect service to support every version.

[thomas15v]

And it isn't :(. Well it bukkit ended at 1.7.10. So 1.3.2 - 1.7.10 will be the target version of this plugin. I try to get it fixed :).

[ghost]

Could you not release 2 versions temporarily? It's only 1 line of code.

[thomas15v]

Hmm, I will skip the reflect service for now and fix it a bit dirtier that usally xD. Btw, I rather don't like to rush this,... .

[ghost]

That's fine - I've got another solution for AE2 cables for now. Keep me updated. ^^

[thomas15v]

Another solution? You have maded my curious :octocat:!

[ghost]

It's a custom solution by our developer, he created a mod which catches the AE2 events/listens to the event bus or what have you and ensures the user has build permissions in a claim using the plugin before allowing them to wrench AE2 cables. It has 2 components, a mod and a plugin component. @orthoplex64 will be able to explain more.

[thomas15v]

Should be fixed, but I don't close because I am kinda unsure. commit: 75bee20e8ae436ce322eca206a91e740d16a3356 download: http://ci.thomas15v.net/job/Forge-Permittor/38/

I have to note that people can add displays, on them. Because the block is a multiblock texture, bukkit doesn't give a BlockPlaceEvent.

[ghost]

[14:19:34 INFO]: [Forge_Permittor] [DEBUG] Requested ID: 4220
[14:19:34 INFO]: [Forge_Permittor] [DEBUG] thermalexpansion.item.tool.ItemWrench@10888882
[14:19:34 INFO]: [Forge_Permittor] [DEBUG] ItemType: Item
[14:19:34 INFO]: [Forge_Permittor] [DEBUG] Requested ID: 4220
[14:19:34 INFO]: [Forge_Permittor] [DEBUG] thermalexpansion.item.tool.ItemWrench@10888882
[14:19:34 INFO]: [Forge_Permittor] [DEBUG] true public java.lang.String me.ryanhamshire.GriefPrevention.Claim.allowBuild(org.bukkit.entity.Player,org.bukkit.Material)
[14:19:34 INFO]: [Forge_Permittor] [DEBUG] You don't have Haidify's permission to build here.  To override, use /IgnoreClaims.

For AE2 cables, plugin works on GP 9.1 now though.

[thomas15v]

That looks good :+1:, Please close the issue if you can't find no bugs anymore :wink:.

[orthoplex64]

@thomas15v I've been told that it's not an issue with the latest dev version of AE2, but when you place facades or some other components or use certain wrenches on AE blocks, AE doesn't fire PlayerInteractEvents for them. Apparently AE has its own Netty channel through which clients notify the server of such player interactions using FMLProxyPackets whose payloads are parsed by packet classes in appeng.core.sync.packets. My mod is configured to load after AE2, then add a handler to the front of AE2's channel's pipeline, where inbound messages are parsed as they would be by AE2's own network handler. PacketPartPlacement seems to be the only packet that is sent when players wrench or place AE blocks, so that is currently the only AE2 packet that my mod attempts to make a location out of. With a Player obtained by using Bukkit to look up the Bukkit player with the same name as the EntityPlayerMP that you can get as an attribute of the NetHandlerPlayServer from casting the Channel's NetworkRegistry.NET_HANDLER attr, and with the Location composed of the Player's World and the coordinates parsed out of the AE2 message, I pass those to a validation method of a "ClaimJudge" implementation that's supposed to be a static field in the main mod class. If that field is null, then it hasn't been set by the "activator" plugin that I had to make in combination with this mod (mods can't access plugins because plugins are loaded with a different ClassLoader, but plugins can access mods because the mods are already loaded by the time plugins are loaded, but the whole thing can't be a plugin because sometimes Forge complains that it can't figure out which mod is trying to do things). So I needed to also make a plugin that sets that static field to an implementation of ClaimJudge that performs proper checks with GriefPrevention and returns the result. If the result is that the player is griefing, fire readComplete() for the next ChannelHandler; otherwise fire a read().

[thomas15v]

Hmmm, but wouldn't it be easier to capture these packets and fire a bukkit event? This is what I understood: You have made a plugin and a mod. The mod waits until the plugin "activates" him. In case activated, the mod will send information from AE2 to the plugin. The plugin responses if it is allowed or not. In case not the mod denies the packet, and AE2 doesn't know anything.

What you do is exactly the same what bukkit would do if you would send him an event. To send bukkit events you have to use onPlayerInteractEvent. The way cauldron is made, it will fire the correct bukkit events. And that way you don't need to use that plugin, and logging plugins like coreprotect also know about it :wink:.

Also, and I know its a bit early to talk about that. Lets say you migrate to sponge, the same method will work for sponge as well.

[orthoplex64]

Actually, when "activating" the mod, the plugin simply instantiates an anonymous implementation of ClaimJudge and assigns to it a static claimJudge field in the mod's main class, and it's the implementation that checks with GriefPrevention. Every time the mod intercepts an AE2 packet, one of the first things it does is check if claimJudge is null. If it is, the mod hasn't been "activated" yet; if it isn't, go ahead and use it. No clumsy asynchronous "sending" of information required :)

But I agree; firing an event with Bukkit would make much more sense than manually emulating GriefPrevention's event handler. I thought about firing an event, but I couldn't find a way to get the result after everything's done. ...As I wrote that last sentence I realized that events might not even be handled asynchronously, so I might simply be able to access the event after the call that fires it. I will see about trying this later.

[thomas15v]

Tested on ftb infinity. Still bypass, so this is still an issue for me. So I reopen this. Sorry for the notification.