Getting your priorities straight: The plugin version

Maybe because the recommendations are just that, recommendations? The Bukkit Packages are sealed and are not recommended. That's a forced issue. They won't accept plugin's with bukkit in the package names as that is something they need/want enforced.

Let's also not mention the fact that it's not the job of Bukkit to teach the plugin developers how to be software engineers. I think the system will be self moderating anyways. I know for a fact it is. And by that, I mean if someone doesn't Generate a BLOCK_PLACE Event when they place a block, and another plugin is affected, the user's are going to notice and complain to the authors. They will either then work out what's wrong, or the users will end up stop using the plugins.

DispNameChanger actually had an issue with priorities and another plugin. I was contacted by users and another author in regards to the issues they were experiencing. Me and that author worked out which priority our plugins should be at, and now both of them play nice. Like I said, self moderating. My example is obviously the ideal for fixing the problems and that's not going to happen with everyone.

 

Dinnerbone

I think you messed something up, huh?

 

T3h Cr33p3r that would require, that bukkit maintains a list of PluginTypes. Also one plugin might do many things and thus would fall not into only one category.

About the sub-priorities: This would not change a thing as everyone would then just register its top prio as "super important". Its the same with the current system. Many "new" developers simply dont know what to register and overthink stuff. Meaning they think that this part is super important to handle first "its my plugin it has to get the event first".. something like that.

But often this is not the case and it can easily be fixed with MONITOR priority which can be used to check the outcome and if something is critical like "i added a database entry in another event and this dependend event got cancelled" then he has to remove the entry by checking MONITOR.

Conclusion: The developer has to think about their structure first, create a concept "what do i have to do on certain events" and react on that.

Setting everything to HIGHER (as many do) doesn't do it.

Edit: Plugin developers have to talk to each other and work together if there is a compatibility problem. This is a community project and not a one man show =)

 

I think the event system is fine as is for the time being. I don't know how much of the bukkit project will survive when the Minecraft API gets released, but I'm willing to bet that the new API will have an event system as well. For now the event system works. Are there some hiccups? You betcha, but most if not all of them are solved by the plugin authors working together to resolve those issues.

As it is, I'm more interested in the Bukkit Team pushing compatibility updates then trying to implement a new event system that would probably break all existing plugins.

Dinnerbone Care to chime in?

EDIT by Moderator: merged posts, please use the edit button instead of double posting.

 

Hello, I am making a plugin overriding respawn locations. What priority should I use? I guess LOW but I am not sure.

 

Well, here's the deal man. Do you want other plugins to override you? Do you need to do something before all other plugins?

If so then Low is fine. If you need to be the last one to touch a player, then you should probably go with highest. Otherwise Normal priority should be suitable for most use case scenarios.

 

You only need highest to override events. It should not be understood as run order. A plugin should also respect cancel states otherwise you should add that plugin to your incompatible list.

 

Anyone know if this applies to Async events as well? I'm looking to ensure the LOWEST priority in the async event gets executed before the NORMAL priority.

 

It applies to all events regardless of which thread fires them.

 

There is so much fuss in this thread about various issues. I think most of them are solvable... just think beyond the obvious.

Pointing out some things:

• You can in your code create and fire new events to see what other plugins think of your planed changes to the server state. (However great care must be taken to avoid creating event loops -> stackoverflow.)
• It is possible to create a plugin that would give the server admin / other plugins 100% control of the event execution order of all plugins - in fact I'm considering writing it eventually... once I have the necessary time or I myself has a big need for it I probably will do so. (Have a config for each event that shows the current order + allow server admins/other plugins to insert/suggest overrides to that order - will barely even affect server performance because it only needs to do additional processing when events are registered, which usually only happens on server load/reload, after that they will fire normally.)
• Even without such a plugin it's possible for plugin authors to manipulate event ordering within the same Priority for specific known plugins using a bit of extra effort and some smarts - if it's really needed. (Want to react before? Make other plugin an optional dependency. Want to react after? Check if the other plugin is already loaded, if yes proceed to register, if no register to the plugin load-event and register your event after the other plugin has been loaded, or all plugins has been loaded (i.e. the 'other' plugin wasn't installed on this server.))

 

No, you cannot, as other plugins may also actually change server state as a result of the event. There is no "modify only the event" - there is only "modify the event and the server" and "modify the server". For instance, many plugins fire BlockBreakEvents to see if they can break a block, but this may cause some plugins to unregister data for the block in question if they don't properly make sure the block was actually broken after the event.

Plugins can register and unregister event handlers at any time for any reason (as long as they are enabled) and once an event has started executing it cannot be stopped; not all events can be cancelled or even have a way to modify them.

 

I don't get your point... if you intend to break the block other plugins are *supposed* to react to it any way they please. Otherwise what is the point of calling the event? Is "other plugins are probably broken" (not actual quote) an argument against calling events?

In programming anything is possible... but I'm not sure how the possibility to modify and/or cancel events is related to what I said. The fact that plugins can register and unregister events at anytime is a lot more interesting, but simple to work around. Requires no reflection or anything hacky! Possible with pure Bukkit API. You're just stuck inside the box man
(Would of course increase performance cost since every time this happens the call order might need to be sorted again. But I don't think it will be all that expensive unless you have a plugin that registers/unregisters lots of events each tick...)

 

What if you don't intend to break the block? You responded to my example instead of my argument.

I never said you could not do what you wanted to do, I was merely offering a warning.

 

Well to be honest you didn't respond to my first post, so I'm the one staying on topic here and you're the one branching the conversation of in a new direction. (In my first post I said "fire new events to see what other plugins think of your planed changes", i.e. fire a block break event id you do intend to break the block.)
So your "No, you can't" statement doesn't apply to my original post, it only applies to the scenario you presented yourself. That's why I said "I don't get your point" - not because it's incorrect, but because you were arguing against a claim I never made.

tl;dr: (not actual exact quotes)

I said: "You can fire events when you intend to make a change on the server".

You replied: "No, you can't { = You can't fire events when you intend to make a change on the server } because if you don't intend to make a change on the server when you fire the event it could break stuff".

...see what I mean. A logical contradiction emerges in that sentence if you apply it to my original post. Hence it can't apply to my original post, hence I don't get it.

Ok. (That wasn't clear since your first part said "No you can't" I assumed that applied to the second part as well since it presented a list of technical obstacles.)

Edit: Since this has now turned into a discussion about misunderstandings, clarifications and argumentation logic I encourage ending or moving this part of the discussion to PM's unless you feel others could truly benefit from reading it. How to test if a block is breakable is a good question though - I don't think I have a good answer to that, but if you would be so kind and provide an example where this information is needed despite not having any desire to break it I would be grateful because nothing instantly comes to mind, and you have aroused my curiosity!

 

"You can in your code create and fire new events to see what other plugins think of your planed changes to the server state."
"You can fire events when you intend to make a change on the server"

These have two very different meanings. If you meant the latter, then be aware I was responding only to the former.

As for when to see if a block can be broken without actually breaking it, have you considered e.g. changing the block without actually breaking it? Many plugins that protect areas are only concerned with block break events.