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.Vadi wrote:A function to register event handlers with.
Mudlet features and API requests
Re: Mudlet API requests
Re: Mudlet API requests
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.Vadi wrote: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.Vadi wrote:A function to register event handlers with.
how about just using accessors in general, that define a function as their value?
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.
Re: Mudlet API requests
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.
I like your proposed function though, it does make sense.
Re: Mudlet API requests
You could always add a event handler tab, which would be a grid view of "name | event list | function declaration"
Re: Mudlet API requests
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.
Re: Mudlet API requests
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).
Re: Mudlet API requests
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.)
(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.)
Re: Mudlet API requests
Need a function to read the contents of the input line.
Re: Mudlet API requests
Isn't the 'line' varible there for all the triggers? (I have used it... is complete copy of the line triggered on with formatting)Vadi wrote:Need a function to read the contents of the input line.
If this is not what you mean, what 'input line' are you looking for?
Re: Mudlet API requests
Where you do all your commands? Some people want to read from it before it's sent as a command to the game.