Mudlet features and API requests

[Vadi]

A function to register event handlers with.

I find that this is necessary now more than ever, now that Geyser, which is shipped with Mudlet, relies on a Mudlet event that is by default not registered - hence Geyser's auto-repositioning does not work on new profiles unless the event handler is added manually.

[tsuujin]

A function to register event handlers with.

I find that this is necessary now more than ever, now that Geyser, which is shipped with Mudlet, relies on a Mudlet event that is by default not registered - hence Geyser's auto-repositioning does not work on new profiles unless the event handler is added manually.

I really wish that the way events are handled would be rethought in general. Requiring a script to be named for a function to handle events is cumbersome, and having no accessors even more so.

how about just using accessors in general, that define a function as their value?

Code: [show] | [select all] lua

tempEventHandler("whatever name you want",{"table","of","events"},
    function(event,arg) doSomething() end)

That way you could still pass the associated function the event and argument list, they could be called on the fly by other scripts, and you could reference them by any name you choose.

[Vadi]

I think it's good for newbies though, the whole graphical aspect of managing the handlers does make it easier.

I like your proposed function though, it does make sense.

[tsuujin]

You could always add a event handler tab, which would be a grid view of "name | event list | function declaration"

[Vadi]

Hm... no, I think the current interface is fine in that sense and should be kept. It could use improvements like a larger size of the event handlers list, but in general, I see it being more useful to keep it compact (one tab one two) performing these two functions. But tempEventHandler is absolutely necessary as well.

[tsuujin]

the problem is that the way it currently works, the anonymous function isn't really going to work because it calls functions based on the name of the script (which, again, i think is needless).

[Vadi]

Well, if you're defining anonymous functions, then chances are you'd want to use the API function as it is then... no? What I see to solve the dislike of the script name being relevant non-organizationally here would be then to create another field in there where you can put in the function name you'd like to be called. But I personally have had success with creating sub-scripts with my functions and event handlers, and it's easy to glance at too.

(now if the function name was parsed properly for tables, that'd be great. I think I could patch that sometime soon as I got it working for GMCP decoding.)

[Vadi]

Need a function to read the contents of the input line.

[Omit]

Need a function to read the contents of the input line.

Isn't the 'line' varible there for all the triggers? (I have used it... is complete copy of the line triggered on with formatting)

If this is not what you mean, what 'input line' are you looking for?

[Vadi]

Where you do all your commands? Some people want to read from it before it's sent as a command to the game.