Mudlet 3.0.0-delta (preview #4)

Post Reply
User avatar
Belgarath
Posts: 232
Joined: Fri Jul 26, 2013 7:19 am
Discord: macjabeth#7149

Re: Mudlet 3.0.0-delta (preview #4)

Post by Belgarath »

Vadi wrote:Just starting Mudlet and clicking on the search bar doesn't seem to cause a crash. Could you help find a case to replicate this?
The times it's happened is usually when it's 'blackened' out and when I've left Mudlet open for a long time and there's a lot of backlog. I'll be clicking there through the day to see if it happens again. Have been checking it on a few different profiles (on startup) and it hasn't crashed yet.

Edit: Been keeping mudlet open for days and haven't been able to reproduce the crash search.
Vadi wrote:Has anyone been giving the new Variables view a go?
Yes, I think it's smexy. 8-)

User avatar
Belgarath
Posts: 232
Joined: Fri Jul 26, 2013 7:19 am
Discord: macjabeth#7149

Re: Mudlet 3.0.0-delta (preview #4)

Post by Belgarath »

It happened again. Not sure what caused it. All the buttons down there were blackened out, I was clicking blindly to try and enable the timestamps button and it crashed...

User avatar
Vadi
Posts: 5035
Joined: Sat Mar 14, 2009 3:13 pm

Re: Mudlet 3.0.0-delta (preview #4)

Post by Vadi »

So does it only happen when the buttons are blackened out?

User avatar
Belgarath
Posts: 232
Joined: Fri Jul 26, 2013 7:19 am
Discord: macjabeth#7149

Re: Mudlet 3.0.0-delta (preview #4)

Post by Belgarath »

I believe so. It's when clicking randomly on the black spots and hoping I hit the right button. It doesn't happen every time I click down there, and I've been unable to find the source of it...

Slayd
Posts: 102
Joined: Mon Jul 25, 2011 4:57 am

Re: Mudlet 3.0.0-delta (preview #4)

Post by Slayd »

I would like to globally change the background color of swamp rooms so that it's different than forest rooms.

Is this possible to do globally?

Will it stick with new mudlet-mapper updates?

Changing the mapper colors in profile preferences won't work for me as I believe swamps and forests are using the same color. At least it doesn't appear so.

I looked at getCustomEnvColorTable(). Are the keys the EnvID? The keys there appear to be in the range 257-272. When I tried getRoomEnv() on a forest roomID, it returned a value of 4. What is the mapping from 4 to 257...272?

If 257-272 map to terrain types for the mapper, is there documentation that explains the mapping? If I knew that I could try the setCustomEnvColor to see if that works, if that is the global solution.

User avatar
SlySven
Posts: 1019
Joined: Mon Mar 04, 2013 3:40 pm
Location: Deepest Wiltshire, UK
Discord: SlySven#2703

Re: Mudlet 3.0.0-delta (preview #4)

Post by SlySven »

There is a slight difficulty in changing the background colour for individual rooms - how much of the background do they take up? It might be possible to draw a coloured rectangle behind each room as it is drawn, but that could only sensibly occupy half the distance out from the room to an adjacent room that was a unit distance away, and even then the map drawing code would have to make two passes through the rooms to draw the backgrounds before anything else. It could be doable but it would slow things down...! :geek:

To store the information I think we would have to revise the map file format - which would instantly become incompatible with any previous Mudlet version - we have done that from time to time and I, personally would like to include a "down-grade" option so that temporarily a user could save their map in the previous former with the loss of the new data so that the use could share maps with more cautious persons who have not (yet) adopted a new, possibly development version.

The map colours (environments) are a bit confusing at present, as I understand it:
  • the colours 1-16 are sort of system reserved and seem to be a lookup table type thing, set in a XML format map sent from an IRE MUD where they might be remapped to any other colour (but there has never been code to do that), but if they could be set to "1" to "16" respectively (which they are NOT and can not be currently by the user) they would map to the 16 colours set in the "mapper colours" on the "profile preferences" or to any custom colour above 16.
  • the colours 17-256 can be set via the lua setCustomEnvColor() command which requires an alpha value which is not reported by the corresponding getCustomEnvColorTable().
  • the colours 257-272 are mapped (at least initially) to the same as the 16 colours in the "mapper colours" on the "profile preferences" but can be overwritten by the lua command.
  • the colours above 257 can also be set via lua command or by using the define colour option to the 2D Mapper's colour command - the latter automatically assigns a new colour/env Id which currently will be after the last colour defined in the range 257-272 so will start at 273 but does not allow the entry of an alpha value and it doesn't tell you when you are defining the colour what that ID will be!
There is not currently IIRC a way to remove colours from the customEnv table or, other than by inspection of the data returned from the lua getCustomEnvColorTable() which though doesn't include the alpha value so two entries could appear to be the same but the code does not tell you/your script.

You can set the colour of any room with the 2D mapper UI though the code does not currently indicate the colour used for the selected room(s) or via lua command { setRoomEnv(roomId, envId) } and you can find the current value {with getRoomEnv(roomId) which returns the envId to look up in the getCustomEnvColorTable() returned data}...

If a colour is specified for a room and that value does not exist it will be painted either the dark or light red on the mapper colour dialog - without diving into the code I can't recall which is used...

Hope that helps a little!

User avatar
Gilmo
Posts: 25
Joined: Fri Feb 11, 2011 11:43 am

Re: Mudlet 3.0.0-delta (preview #4)

Post by Gilmo »

I was thinking I could really use a way to track mouse positions. Is there any way I don't know of, or would it be impossible to add such feature?

User avatar
SlySven
Posts: 1019
Joined: Mon Mar 04, 2013 3:40 pm
Location: Deepest Wiltshire, UK
Discord: SlySven#2703

Re: Mudlet 3.0.0-delta (preview #4)

Post by SlySven »

Within a particular window or globally? It might be possible to tell the profile that owned a particular screen where a mouse click occurred within it - I'm not making any promises on that... but globally, out side of that window, I think not.

User avatar
Gilmo
Posts: 25
Joined: Fri Feb 11, 2011 11:43 am

Re: Mudlet 3.0.0-delta (preview #4)

Post by Gilmo »

I'm not sure what you mean with 'tell the profile that owned a particular screen' .

What I think of is something that can give me the x,y coordinates of the current mouse position in the user window.
so one could do, let's say:
Code: [show] | [select all] lua
local mouseX, mouseY = getMousePosition()
myVeryCoolImageLabel:move(mouseX, mouseY)
to move an image around the window.

User avatar
SlySven
Posts: 1019
Joined: Mon Mar 04, 2013 3:40 pm
Location: Deepest Wiltshire, UK
Discord: SlySven#2703

Re: Mudlet 3.0.0-delta (preview #4)

Post by SlySven »

At present the Mudlet application tracks mouse movement as part of a click for moving rooms and for <CTRL>-mouse Map panning only, would sysMouseClickEvent, sysMouseDoubleClickEvent, sysMouseMoveEvent and sysMouseReleaseEvent with arguments of buttons involved and the position probably confined to ONLY points within the window be sufficient for what you want?

It is not likely we could provide the mouse position outside of the window or when a button is NOT involved as that would require "Grabbing" the mouse which is not a good idea, as per:
in the Qt Documentation it was wrote:void QWidget::grabMouse()
Grabs the mouse input.

This widget receives all mouse events until releaseMouse() is called; other widgets get no mouse events at all. Keyboard events are not affected. Use grabKeyboard() if you want to grab that.

Warning: Bugs in mouse-grabbing applications very often lock the terminal. Use this function with extreme caution, and consider using the -nograb command line option while debugging.

It is almost never necessary to grab the mouse when using Qt, as Qt grabs and releases it sensibly. In particular, Qt grabs the mouse when a mouse button is pressed and keeps it until the last button is released.

Note: Only visible widgets can grab mouse input. If isVisible() returns false for a widget, that widget cannot call grabMouse().

Note: On Windows, grabMouse() only works when the mouse is inside a window owned by the process. On OS X, grabMouse() only works when the mouse is inside the frame of that widget.

Post Reply