Mudlet / Mudlet

⚔️ A cross-platform, open source, and super fast MUD client with scripting in Lua
https://mudlet.org
GNU General Public License v2.0
731 stars 264 forks source link

Feature request: Make the map room color pallete be always visible #2155

Closed diamond-lizard closed 5 years ago

diamond-lizard commented 5 years ago

Brief summary of issue / Description of requested feature:

I'd like to request that the color palette that's used for changing the color of rooms on the map be always visible.

Steps to reproduce the issue / Reasons for adding feature:

I change colors of rooms on the map all the time, potentially hundreds or thousands of times per day.

Having to right click on the room I want to color, move the mouse to the "color" menu item, and click on it are actions that add up to a lot of extra clicking and mouse movement over time.

Error output / Expected result of feature

Having the color palette always be visible would allow me to at least just click on the color I want, without needing to bring up the color palette window and save a lot of time.

Extra information, such as Mudlet version, operating system and ideas for how to solve / implement:

Mudlet 3.15.0

vadi2 commented 5 years ago

You can also select multiple rooms at once and then apply the colour.

diamond-lizard commented 5 years ago

I do color multiple rooms at once, when I'm walking through a bunch of rooms that are conceptually related somehow. But much more often I'm mapping and coloring one room at a time, as I explore.

SlySven commented 5 years ago

It sounds like something that would be better handled by a user script that is placed on the 2D mapper context menu.

BTW I am considering added better support for named environments, with a default room colour (unless overridden by an explicit room colour override) and a default room weight (unless overridden by an explicit {non-zero} room weight setting). I think this would help you (and also allow us to better use the information about environments provided in the IRE Muds' XML map files) - what is proving tricky is working out how to handle the EnvId to ColorId mapping that we currently do hidden away from the end user such that they think the Environment is the Colour when in fact there is a mapping that they cannot see or edit.

diamond-lizard commented 5 years ago

It sounds like something that would be better handled by a user script that is placed on the 2D mapper context menu.

If the colors are behind a context menu that means for every room I want to color I'll have to right-click to open the context menu first before I can color it. For every 1000 rooms I color this way, that's 1000 extra clicks compared to what I'd need if the color palette was always visible and didn't require any extra clicks to color a room.

BTW I am considering added better support for named environments, with a default room colour (unless overridden by an explicit room colour override) and a default room weight (unless overridden by an explicit {non-zero} room weight setting). I think this would help you (and also allow us to better use the information about environments provided in the IRE Muds' XML map files) - what is proving tricky is working out how to handle the EnvId to ColorId mapping that we currently do hidden away from the end user such that they think the Environment is the Colour when in fact there is a mapping that they cannot see or edit.

I'm not exactly sure what you mean by environment, but if it's something like an area or group of rooms, then I could see such features being useful for users who tend to assign default colors to rooms based on what area or group they're in.

Unfortunately, such a feature would not be very useful for me because I don't color my rooms based on the area they're in but rather on the room type or room contents. For example, if it's a shop I'll color it purple. If there's a portal in the room it'll be white, if an important NPC is there it'll be green, etc.

I set these room colors as I explore as I move from room to room, and as there's really no predicting what will be in any given room, a default color for the room won't usually be very useful for me.

I have on occasion been in gigantic wildernesses, where the majority of rooms were very similar to one another, and in that case I could see some default color being useful.. but then maybe it'll be just easier to be able to put Mudlet in a mode where the next room that's created is the same color as the previous room. That way, I could see myself moving along a road and coloring every "room" on the road gray, for instance. Or when I'm in grass fields or forest to color those green.

SlySven commented 5 years ago

I will need to check but it might just be simplest if we have a lua command to return the current selection of rooms (if any) so that you could select one or more rooms and then use an alias on the command input line to assign the colour (or environment) to that selection with a short command or even a key-binding...

... and then calling updateMap() if needed to immediately show the changes.

SlySven commented 5 years ago

:bulb: Right, @vadi2 how about a lua getMapSelection() that will return - if it is one or more rooms that are currently highlighted by the mouse selection:

{
    "rooms",
    {
       <selected roomnumber 1>,
       <selected roomnumber 2>,
...
       <selected roomnumber n>
    }
}   

:information_source: Putting an indication of what is selected is to cover ourselves if we extend this part of the API to handle other than just rooms (like a selected custom exit line or one or more map labels).

vadi2 commented 5 years ago

I agree - that would be great

SlySven commented 5 years ago

^^ Okay then, check that referred to PR. ^^

vadi2 commented 5 years ago

I think the original request could be implemented as a script in combination with the new selection function. Well, almost - we also need an event for when rooms are selected!

SlySven commented 5 years ago

Might be a bit more complicated than that - it will need to be whenever the selection changes...!

However, give that it is a user driven process it is less coding to just ask the user to cobble together a key-binding or alias or button to carry out the action - and a row of buttons with suitable code to apply a suitable colour/environment to the currently selected rooms would be pretty much fulfil what the OP wanted IMVHO without me having to come up with a workable UI for a non-modal ancillary toolbar. :relieved:

vadi2 commented 5 years ago

I agree.

SlySven commented 5 years ago

Right, if you build the current development (or wait for 3.17.0 to be released) you will be able to create a docked set of buttons (and since #2173 has gone in they can be on a menu) with a simple script to set the currently selected rooms - as returned in the rooms part of the table returned from the new function getMapSelection() you should be able to hard-code them to assign a different colour for each button (using setRoomEnviroment(roomId, colourId) I think) to the selected rooms - and to give the buttons a colour reflecting their effect - you can do that manually via the Qt Style Sheet box above the script entry widget in the Editor - or it is possible that there is a function to set the style of buttons/menus/toolbars, I just can't remember right now whether it exists and what it is called and I do not have the code open in an IDE right now...