I have a bit of a strange situation that I can reproduce 100% in situ, but so far I have not managed to make a minimal test case.
This is what happens...
The player makes a miniwindow in the world script space with a movewindow drag handler on it. The player then drags the window around for a while over top of their GMCP mapper miniwindow which of course lives in its own plugin. If new room GMCP data arrives (like if they set a timer to send the "look" command) causing the mapper to refresh its display, the miniwindow they're dragging suddenly AND TEMPORARILY forgets that its mouse handler functions exist and this error message pops up saying:
https://i.imgur.com/Cz0503w.png
After clicking "Ok" to dismiss the error message, the miniwindow that was being dragged stays stuck to the mouse cursor, following it around until the mouse is clicked again. After that, the miniwindow's dragmove handler resumes working normally until the next time.
The problem goes away if I comment out this WindowAddHotspot call inside the mapper https://github.com/fiendish/aardwolfclientpackage/blob/c6441b3c36e58ca79ef2029292e8012d86a4e9f7/MUSHclient/lua/aardmapper.lua#L919-L924
I've ruled out my Lua DLL by making some necessary modifications to be able to load the Aardwolf mapper plugin without LuaJIT and dropping in the classic one, so that's not the problem.
I think the problem also doesn't occur if the dragged miniwindow is larger than the mapper miniwindow, so it may be some global optimization gone bad using the hotspot corner coordinates when adding hotspots to miniwindows?
Anyway, there appears to be _something_ about that WindowAddHotspot call that is transiently botching an entirely unrelated script's miniwindow's ability to remember its dragmove function.
This is what happens...
The player makes a miniwindow in the world script space with a movewindow drag handler on it. The player then drags the window around for a while over top of their GMCP mapper miniwindow which of course lives in its own plugin. If new room GMCP data arrives (like if they set a timer to send the "look" command) causing the mapper to refresh its display, the miniwindow they're dragging suddenly AND TEMPORARILY forgets that its mouse handler functions exist and this error message pops up saying:
Quote:
Cannot find the function 'mw_testwindow_movewindow_info.dragmove' - item 'dragmove' is nil
Cannot find the function 'mw_testwindow_movewindow_info.dragmove' - item 'dragmove' is nil
https://i.imgur.com/Cz0503w.png
After clicking "Ok" to dismiss the error message, the miniwindow that was being dragged stays stuck to the mouse cursor, following it around until the mouse is clicked again. After that, the miniwindow's dragmove handler resumes working normally until the next time.
The problem goes away if I comment out this WindowAddHotspot call inside the mapper https://github.com/fiendish/aardwolfclientpackage/blob/c6441b3c36e58ca79ef2029292e8012d86a4e9f7/MUSHclient/lua/aardmapper.lua#L919-L924
I've ruled out my Lua DLL by making some necessary modifications to be able to load the Aardwolf mapper plugin without LuaJIT and dropping in the classic one, so that's not the problem.
I think the problem also doesn't occur if the dragged miniwindow is larger than the mapper miniwindow, so it may be some global optimization gone bad using the hotspot corner coordinates when adding hotspots to miniwindows?
Anyway, there appears to be _something_ about that WindowAddHotspot call that is transiently botching an entirely unrelated script's miniwindow's ability to remember its dragmove function.