Posted on October 31, 2021
Mudlet 4.14 Preview
Mudlet 4.14 is on the horizon, and I thought I might do a brief preview of a few of the features I’m looking forward to in the next release of Mudlet.
Dark theme
There has been an excellent dark theme package available on the Mudlet forums for a couple years now; however, a dark mode for Mudlet remains a frequently requested feature. I’m happy to report that this version marks the first one with an included dark theme. It’s using the Dark Fusion theme, if I remember correctly. Have some preview pics!
On the left above is the ‘light’ mode most Mudlet users are presented upon first install, followed by a picture highlighting where the option is in the preferences dialog, and finally a picture which shows a similar picture to the first, but in dark mode. The editor theme in the left picture is the default ‘Mudlet’ theme, on the right is ‘Monokai Midnight’ which is the one I usually use.
Named tempTimers and not-so-anonymous event handlers
Mudlet 4.14 will ship with a new internal IDManager which will manage the work of killing and recreating temp timers and event handlers for you, rather than forcing you to capture return IDs and handle it yourself. One of the more frequent issues I hear from people while sitting in the help channel is that they’ve got multiple tempTimers stacking up for the same thing, or their old anonymous event handlers aren’t cleaned up and fires four times for each raiseEvent call. Or in more practical terms
-- before 4.14
-- tempTimer
myTable = myTable or {}
if myTable.timerID then
killTimer(myTable.timerID)
myTable.timerID = nil
end
myTable.timerID = tempTimer(4, function() doSuperCoolThingInFourSeconds() end)
-- anonymous event handler
if myTable.vitalsID then
killAnonymousEventHandler(myTable.vitalsID)
myTable.vitalsID = nil
end
myTable.vitalsID = registerAnonymousEventHandler("gmcp.Char.Vitals", "myTable.handleVitals")
-- after 4.14
-- tempTimer
registerNamedTimer("Demonnic", "super cool thing", 4, function() doSuperCoolThingInFourSeconds() end)
-- event handler
registerNamedEventHandler("Demonnic", "vitals", "gmcp.Char.Vitals", "myTable.handleVitals")
-- for those who prefer to work with Lua 'objects'
myTable.idmgr = myTable.idmgr or getNewIDManager()
myTable.idmgr:registerTimer("super cool thing", 4, function() doSuperCoolThingInFourSeconds() end)
myTable.idmgr:registerEvent("vitals", "gmcp.Char.Vitals", "myTable.handleVitals")
The first parameter identifies what ‘name’ to file the handlers under, so that you can keep the timer/handler names themselves simpler without colliding with the names used by others. The second parameter is the name of the timer or event itself. These are both picked by you, and I would recommend using your own handle or character name for the first one if it’s just scripts you’re writing for yourself, or your package name for scripts you’re writing to give to others. In the latter case this helps to keep all of a particular package’s events and timer’s logically bundled together in the same manager. This is similar to the API for managing GMCP modules. No matter how many times you call registerNamedTimer or registerNamedEventHandler with the same names it will replace and restart them rather than allowing them to stack. These two functions on their own would cut way down on my own boiler plate code, but there are also stopNamed*, resumeNamed*, deleteNamed*, and getAllNamed* functions which should make working with tempTimers and named event handlers even easier and more convenient.
More error/debug message options
One of the things which Lua is not so great at in my opinion is error handling. Its error and assert functions do not print nearly enough stack trace information, and options for printing error messages without halting execution were nonexistent. Mudlet added debugc which allows for non-error messages to be printed to the error console, but it was not much different than a normal echo to a hidden miniconsole for debugging, and in my experience goes largely unused by most. I aim to replace all of these with printError and printDebug.
-- prints calm green debug message.
printDebug("This is a debug message, will only show in the error console in the script editor")
-- prints calm green debug message, with stacktrace
printDebug("This is a debug message, will only show in the error console in the script editor", true)
-- prints big red error. Does -not- halt execution
printError("This is an error and shows up anywhere using error() would")
-- prints big red error, including stack trace. Does not halt execution
printError("This is an error and shows up anywhere using error() would", true)
-- prints big red error, including stack trace, and halts execution
printError("This is an error and shows up anywhere using error() would", true, true)
Adjustable wait time for non-GA/EOR games
One common complaint with Mudlet on games which cannot be configured to send the telnet GA (Go Ahead) or EOR (End of Record) signals with their prompt is that it can feel a bit sluggish. This is because by default there is a 300ms wait to make sure the game has sent everything it needs to send and there aren’t more packets waiting to come in which may contain part of the line. Without a delay of some sort you can wind up with line breaks in unanticipated places and triggers which won’t fire consistently, and that’s no good either. 300ms can feel like a looooong time sometimes though, and if you have a fast connection with low latency it’s unlikely you need to wait that long. And starting with 4.14 Mudlet will allow you to adjust this wait time to suit your specific situation.
And more…
This post has only highlighted a few of the things coming up in Mudlet 4.14 that I’m personally excited for. There have been a lot of other tweaks and improvements made since 4.13 dropped; from minor bugs to new features there will be lots to explore and enjoy in the next version of Mudlet and I hope you’re all as excited as I am about the upcoming release.
Happy MU*ing,
demonnic