Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Jan Milants]

I have run into this problem more then once...
Many events are only send after the core has done its work. In the case of expiring nicknames for example it means that by the time the event is send, no data in the nick still exists. If the module stores data in the ModuleData for example it means the module can't do anything anymore either.

Another example is the identify event: the event is send in the middle of the core code. So before the core has finished setting stuff like vhosts, but after setting some other things lke +r.

I think it would be very useful to have that kind of events send in different stages and it doesn't require a lot of changes either. For example sending an event before the nickname is dropped and after or before and after the nickname is identified, maybe even with a third event before the channel modes on the user are being set.

[Edited on 17-8-2007 by Viper]

[Pieter Bootsma]

The whole event system will be re-done for 1.9, and the core should be using them itself as well. I hadn't thought of the multiple stages yet, but i'll note it down.

[Jan Milants]

as an extension to this, it would be very useful if modules could create their own events. This way different modules could more easily interact without having to duplicate all the logic.

[Pieter Bootsma]

Originally posted by Viper
as an extension to this, it would be very useful if modules could create their own events. This way different modules could more easily interact without having to duplicate all the logic.

That too is in the planning

[katsklaw]

although such modules would have to insure that their dependencies are present, perhaps via findmodule()