Search FAQ

Release notes for MUSHclient version 4.42


Version 4.42

Released on 15 Jul 2009

1. Fixed bug in the way TriggerStyleRuns was set up for send to script, after omit. Styles with inverted colours did not have the inverted colour correctly set up in textcolour and backcolour.


2. Added a new flag to WindowCreate (the bit set if you add in 8 to the flags parameter). This is the "ignore mouse" flag. If set, the miniwindow ignores mouse-down, mouse-over, and mouse-up events. Therefore it will also not display any hint you might put into hotspots, and hotspots in general will not be any use for such miniwindows.

The intention of this flag is to let you add floating visual elements above other windows (eg. warning messages, explosion effects) which do not limit the behaviour of the mouse for the window underneath.


3. Changed the way triggers match on colours so that if you specify (say) red on black, then if the colour is displayed as red on black (normal) or black on red (inverse) then it still matches. Of course, black on red (inverse) looks like red on black (normal) so the effect is you are matching on what you see.


4. Changed the way the current directory is handled.

In previous versions the current directory (that is, the default directory used in a file open if no full pathname is specified) would vary if you used the file browser dialog. For example, if you loaded a plugin (by browsing to find it), then the file browser would leave the current directory as the one the plugin was in.

I didn't want to change the file browser to not remember where you last browsed to, because that would be annoying if you wanted to load lots of plugins (say) from a non-standard location, and had to keep browsing to the same spot.

On the other hand, having the current directory change randomly can make plugins stop working.

The solution is now as follows:

a) When MUSHclient starts up, it remembers the startup directory (the current directory). This is stored internally (See GetInfo (68)).

b) The "file browsing" directory is initially set to be the startup directory.

c) When you use the file browser (there are about 36 places this happens), the current directory is set to be the file browsing directory - before the dialog appears. This way, file browsing remembers where you last browsed to.

d) After you have browsed for a file, MUSHclient remembers the now-current directory as the file browsing directory, for next time you browse a file.

e) After that, the current directory is reset back to the startup directory.

Note that the script function ChangeDir *does* change the current directory, as advertised.


5. Added new selector to GetInfo - 84 - returns the current file-browsing directory.


6. Improved the help file regarding the SQLite Lua interface, to add references to the prepared statement context callback functions.


7. Fixed bug where, when using MXP, if a <BR> was received from the MUD, although that started a new line, if the previous line was a note, the new line would be marked as a note, and thus triggers not processed for it.


8. Changed GetMappingString so that if the number of repeats for a particular direction exceeded 99, it was broken up into lots of 99 or less, to be consistent with EvaluateSpeedwalk.


9. Added Lua script function PlaySoundMemory which lets you play a sound already loaded into a memory buffer (a string).

local f = assert (io.open ("some_sound.wav", "rb"))
local sound_data = f:read ("*a") -- read all of it
f:close () -- close it

PlaySoundMemory (1, sound_data, false, 0, 0) -- play sound loaded into sound_data

The intention here was to allow a batch of sounds to be distributed in a single file (an SQLite database) and extracted (by a SELECT statement) as required, and played. This saves having to distribute hundreds of small sound files with a plugin.

The arguments to PlaySoundMemory are the same as for PlaySound except that the second argument is a string containing the sound data itself, not the file name of the sound data. The sound data still needs to be a .WAV file (loaded into memory).

For more details, see: http://www.gammon.com.au/forum/?id=9566


10. Added Lua script function WindowLoadImageMemory which lets you load an image from data already loaded into a memory buffer (a string).

local f = assert (io.open ("sword.png", "rb"))
local image_data = f:read ("*a") -- read all of it
f:close () -- close it

WindowLoadImageMemory (win, "im", image_data) -- load image from loaded string
WindowDrawImage (win, "im", 20, 20, 0, 0, 1) -- draw image into miniwindow

The intention here was to allow a batch of images to be distributed in a single file (an SQLite database) and extracted (by a SELECT statement) as required, and drawn. This saves having to distribute hundreds of small image files with a plugin.

The arguments to WindowLoadImageMemory are the same as for WindowLoadImage except that the third argument is a string containing the image data itself, not the file name of the image. The image data needs to be a .PNG file (loaded into memory). Note that .BMP files are not supported.

For more details, see: http://www.gammon.com.au/forum/?id=9567


11. Added new script function WindowDrawImageAlpha.

This lets you draw a loaded PNG image into a miniwindow respecting the alpha channel. The alpha channel is effectively a "mask" which indicates which pixels in the image are to be drawn, and which are not. Unlike WindowDrawImage however, the transparency is not just "on" or "off". The alpha channel lets you specify a degree of transparency (technically, a byte in the range 0 to 255) for each pixel. Thus it is possible to have soft edges around an image, where the alpha mask gradually transitions from opaque to transparent.

This lets images be placed on top of other images (eg. icons on top of a background) with soft edges, giving a more pleasing, natural look.

For more details, see: http://www.gammon.com.au/forum/?id=9568


12. Changed the way that selections work in the output and command windows, so that Ctrl+C to copy to the clipboard works in a more natural way:

* When you select text in the command window, any selected text in the output window is automatically deselected.

* When you select text in the output window, any selected text in the command window is automatically deselected.

This is like treating the whole world window as a single block of text, and normally you only have one selection.

Then, when you hit Ctrl+C (or Edit -> Copy) it copies whatever selection there is (in either window), if any.


13. Fixed problem where miniwindows with the "draw in absolute position" flag was set, would draw in a degraded way if the position code was in the range 0 to 3 (draw with stretch). Now, if the absolute position flag is set, the window is not stretched.


14. Fixed problem with GetWindowInfo where the selectors 10 to 15, and 17 and 18 might return random values, if they were not initialized. For example, 17 and 18, which is "where mouse was during a drag operation" could have had some large numbers in them, if no drag was ever done. Now, they are initialized to zeroes.


15. Changed the documentation for script callbacks - plugins, to use Lua as the example language rather than VBscript.


16. Removed check for if this is the first time you used MUSHclient from the Registry - this will have the side-effect that for every user of MUSHclient it will say "I notice that this is the first time you have used MUSHclient on this PC.". However it will then write the "not first time" flag to the SQLite database, and you won't see that message again.


17. Changed so as to not use the Registry for the most-recently-used file list (MRU list) nor the toolbar locations. To save making extensive changes to the source, these are now saved in a file called MUSHclient.INI in the same directory as the working directory when MUSHclient is invoked. A side-effect of this will be that your toolbars will be repositioned to the default places the first time you open this version of MUSHclient. Also your current MRU list will be lost.


18. Changed so as to not add the Registry key for "Gammon Software Solutions" - provided that it was able to open the SQLite preferences database file (mushclient_prefs.sqlite).

This is to maintain a minimal footprint in the Registry, particularly for people who want to use MUSHclient in a portable situation (like a USB disk).

The sequence at startup is now:

* Open a file MUSHclient.INI in the startup directory of MUSHclient.

* Look for the global preferences database (mushclient_prefs.sqlite) in the startup directory.

* If not found, look for the global preferences database (mushclient_prefs.sqlite) in the MUSHclient application directory.

* If not found in either place, create the preferences database in the startup directory AND then set the Registry to use the "Gammon Software Solutions\MUSHclient" key to try to locate existing global preferences (created by earlier versions of MUSHclient). Then copy those preferences from the Registry to the SQLite database.

Thus the net effect is that the "Gammon Software Solutions\MUSHclient" Registry key will not be created provided it finds the SQLite global preferences database.


19. Fixed bug where the script handlers for miniwindow events, namely MouseOver, CancelMouseOver, MouseDown, CancelMouseDown, MouseUp, MoveCallback and ReleaseCallback could not have periods in their names. This particularly affected Lua, as it made it impossible to put those handlers inside a containing table, for neatness.


20. Fixed bug where, in a miniwindow hotspot, if you had processing for a mouse-up event which displayed a dialog box (eg. the colour picker) the first mouse click was not processed as the "mouse capture" was not released before calling the mouse-up script event.


21. Added support for RH (right-hand) mouse-clicking in miniwindow hotspots. Now, a mouse-down or mouse-up callback has the "flags" parameter set as documented for hotspots ...

The flags parameter is a bit mask as follows:

0x01 - Shift key down
0x02 - Control key down
0x04 - Alt key down
0x10 - LH mouse
0x20 - RH mouse
0x40 - double-click

So, to test for a RH click you might say in Lua:

if bit.band (flags, 0x20) ~= 0 then
-- RH mouse clicked
end -- if

Note that a double-click event is recorded first as a single-click mouse-down (so the flags might be 0x10 or 0x20 if no keys were held down), followed by mouse-up, and then a double-click mouse-down (with the flags as 0x50 or 0x60 if no keys were held down), and then a mouse-up. So effectively, a double-click is really two single clicks in quick succession, where the second one has the double-click flag set, to indicate that this was close enough to the first one to be considered a double-click.

The mouse-up flags do not remember whether the mouse-down was started with a single or double-click - you need to remember that in the mouse-down event handler.


22. Added modules mw.lua and movewindow.lua to the official distribution (in the lua subdirectory).

View all MUSHclient release notes

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.