Mudlet - Forum

Posted: **Fri May 08, 2009 8:55 am**

I have two bugs to report here. Firstly, event functions only appear to be run upon the first new line arriving from the mud after the event has been raised. This is demonstrated in the test script, though the test script was designed to test for a different behaviour.

Secondly, event handler functions do not fire in a determinable order. To show this, I created the following script:

Code: Select all

Alias pattern: ^rtevent$
Script:
echo( "Raising event: tevent" )
raiseEvent( "tevent" )

Script name: tevent1
Registered event handlers: tevent
Script:
function tevent1( tevent )
    echo( "Event 1 fired"  .. "\n")
end

Script name: tevent2
Registered event handlers: tevent
Script:
function tevent2( tevent )
    echo( "Event 2 fired"  .. "\n")
end

Script name: tevent3
Registered event handlers: tevent
Script:
function tevent3( tevent )
    echo( "Event 3 fired"  .. "\n")
end

Script name: tevent4
Registered event handlers: tevent
Script:
function tevent4( tevent )
    echo( "Event 4 fired"  .. "\n")
end

1. I turned on timestamps by clicking the "i" button in the bottom right corner of the mudlet window.
2. I entered "rtevent" at the command line, which raised the event "tevent".
3. I saw the text "Raising event: tevent" displayed in the main window as expected, with the matching timestamp of 18:13:00
4. I wait. Nothing happens for 12 seconds, until I send a blank line to the mud by pressing enter at the command line. At this point the following is displayed with a timestamp of 18:13:12
Raising event: teventEvent 4 fired
Event 2 fired
Event 3 fired
Event 1 fired

I underlined the part from the original echo - this is not new, only what follows. As you can see in the screenshots of this, the event handler functions are firing both far too late, and not in the order that they appear in the script editor.

Posted: **Fri May 08, 2009 9:28 am**

It's not actually a bug as it was designed to be this way, but I guess that what you expected is a more appropriate way of handling events. At the moment events are run after triggers have been run on the current data package recieved from the MUD. This means that they are not run after the alias unit.

I will change events to be run after every line that has been processed in the trigger engin + after every alias expansion. This is indeed a more appropriate solution.

About the order of events: According to the general paradigms of event driven programming, order does not figure anywhere. However, we can think about enforcing order in our case. I have to think about this for a while though as it would be entirely non standard.

However, you can determine the order in which the event handlers of a particular event are called by arranging them in a certain order in the same group folder.
This sequence is being obeyed. However, when working on the scripts you need to click on the parent folder (the group folder) and compile the folder -> save the folder. This will restore the correct order of the group in the event handler list. This is done automatically when the profile is loaded, but when working on handler scripts you recompile handlers and thus the order gets changed, but the workaround will work.

Posted: **Fri May 08, 2009 10:14 am**

I thought about the whole problem a bit and came to the conclusion to call the event handlers right away when the event is raised. This way you have even more flexibility and scripting becomes more transparent.

Posted: **Fri May 08, 2009 10:47 am**

Ah, I see. I was only calling it from an alias for a test scenario, though I suppose you might be right when you say that it may be useful to be able to do so. I would actually expect any scripts called before the event is raised, to be run to completion.

In the case of multiple triggers being fired on the same line, I can see reasons to want all triggers processed first, as well as situations where we might want the event called instantly. If they are called instantly, and we would prefer it to be otherwise, we can always make it a multi-line trigger, and 'trick' it into raising the event at the end.

For the order of operations, I just tried that now. I selected the group folder you see in the screenshot, and clicked "save". They still execute in the order of 2, 3, 4, and 1.

I know that I can simply have one event handler function, with all of the individual checks put into them. I went with this system instead because I figured that if someone else were using my scripts but needed to add/remove custom bits, it would be easier for them (or me) to have the scripts separated and graphically displayed. If they don't want to check for howling controls in the postQueue, but instead want to use a mentis whisper (because they play a vampire class and not a werewolf), it would be as easy as deleting that whole script object and replacing it with their own. Or if they prefer a different order, they could drag them around into the order they want.

Its not a big thing though. If lua events are not meant to work that way and there is no easy way to change that, then I'll just put everything in the one event handler. Its not actually difficult to rearrange scripts with cut/paste (especially with notebook++), so don't worry about it too much.

Posted: **Fri May 08, 2009 10:50 am**

I just read your PM now, hehe. After typing all -that- ^

Mudlet - Forum

2x bug: events only fire on new line and not in order

2x bug: events only fire on new line and not in order

Re: 2x bug: events only fire on new line and not in order

Re: 2x bug: events only fire on new line and not in order

Re: 2x bug: events only fire on new line and not in order

Re: 2x bug: events only fire on new line and not in order