Mudlet 3.0.0 beta is here – this is the second preview of the upcoming 3.0 release! In this version, we only focused on fixing new issues have have been introduced in 3.0 – such that 3.0 is no worse, only better, than 2.1 quality-wise. It is also, of course, better feature-wise :).
Please provide all feedback (don’t delay!) on our forums.
Documentation is still in progress of being updated for all new features.
Below is the summary of changes in preview #2. See preview #1 for a list of all the new things in 3.0!
Splash screen
The artificial delays in the splashscreen have been removed, making Mudlet startup much faster. Enjoy!
MSDP fixes
You can now toggle MSDP on/off in settings, like you can with GMCP. This is needed for MUDs which disable GMCP if they’re sending MSDP – which would break your GMCP scripts.
The sendMSDP() function has been fixed to work – you can now do sendMSDP(“LIST”, “REPORTABLE_VARIABLES”) for example.
Text cutoff in tabbed chat
Text has been getting cut off in miniconsoles, the most obvious effect of this being seen in tabbed chats like YATCO. This has now been fixed.
Windows installer
The Windows installer has been improved and is now signed, so it does not show the “unknown developer” dialog anymore – the developer is now verified and far less dodgy:
Miscellaneous
See changelog below for what else has made it in:
- added a openWebPage() Lua function which opens a URL (it was supposed to make it in the alpha)
- added a toggle for enabling MSDP in settings
- fixed a crash when browsing variables tab in the editor
- fixed option for turning off GMCP not working
- fixed sendMSDP() to actually work
- fixed text getting cut off in miniconsoles (and thus tabbed chats) on paste
- fixed the first letter of ‘What’ in IRE games at login showing up as
- fixed variables toggling their status when clicking away from them
- removed artificial delays from the splash screen
- room deletion has been massively sped up
- tabs have been reverted to show up as tabs again instead of spaces
Will 3.0 bring any improvement/functionality to Mudlet being able to display unicode output from MU*s?
This is a problem in any MU* that uses those characters, pretty much every non-English MU*, any MU* in which another player types them to you for so reason, and especially in fantasy MU*s that use the characters for accent/flavor purposes.
It also ruins a lot of text ‘art’ and framing for things like built in maps that MU*s tend to output.
3.0 won’t as we’re working only on fixing regressions that it has now and not adding any new features, but that is something we are working towards!
Yes, it is now a blueprint item (https://blueprints.launchpad.net/mudlet/+spec/unicode-support) so hopefully we will get it nailed for 4.0, as it is I am trying to ensure that things I touch become Utf-8 (the 8-bit transport encode scheme to convey Unicode information) compatible as I go, e.g. in the lua subsystem to C++ boundary so that users can send and receive Unicode information to the Mudlet application. The obvious issue there is the use of QString::toLatin1() which only handles ASCII instead of QString::toUtf8() when sending data from C++ to Lua to user (and not using QString::fromUtf8() the other way). More fundamental is the reassembly of a Unicode/utf-8 data stream from the bytes received from a MUD server – there is a section (the cTelnet class) that has to extract this from the Telnet protocol encapsulation and formatting instructions before it can be considered and treated as utf-8 Unicode data. Currently the data is treated byte by byte without regard to the fact that a byte may actually be part of up to four bytes that make up a valid unicode codepoint. Indeed some of those code points combine to make graphemes and those graphemes can be put together in more than one way – so the sequences must be “normalized” in order to give the user’s triggers a change of matching them even if they are not precisely as the user specified. So yes, I’d back Vadi up of this – we [i]are[/i] working towards this, but we are not there just yet… :geek:
Be advised that at this point the installed application is not likely to run on Windows XP. It seems that the sticking point is a function sprintf_s() that is used by the libyajl.dll that is included in the bundle – at a guess I’d estimate that it was built on a system later than that MS OS version and relies on items that are not present in XP. It turns out that the missing function is a “safe” sprintf() introduced in MSVC8 which has a different signature to sprintf() – indeed using the latter will apparently post a compile time warning to use the safe version. What a PITA *sigh*, whether it might be possible to substitute a copy of that library if built with a MinGW setup I do not know…