Mudlet 3.0.0-delta (preview #4)
Re: Mudlet 3.0.0-delta (preview #4)
Have a look at http://wiki.mudlet.org/w/Manual:UI_Functions#getBgColor and http://wiki.mudlet.org/w/Manual:UI_Functions#getFgColor, which have always been there.
Re: Mudlet 3.0.0-delta (preview #4)
Ah, yes, but I am receiving the colour as text from gmcp.Comms in the following format
[0;37;41m(Khairt's Barrel): You say, """."[0;37m
and I was hoping I could convert those numbers from ANSI to text in a script without having to add triggers to my client, but I guess I will have to if that is not possible.
[0;37;41m(Khairt's Barrel): You say, """."[0;37m
and I was hoping I could convert those numbers from ANSI to text in a script without having to add triggers to my client, but I guess I will have to if that is not possible.
Re: Mudlet 3.0.0-delta (preview #4)
Mudlet 3.0 is pretty great. My only complaint is that cecho() seems to have been quietly changed, such that this:
cecho("<:white><red>text")
is no longer valid. I used to be able to set the background color of the cecho without having to set a fg color in the same tags, but it seems that's not the case anymore. Any chance of this being changed back? Kinda broke one of my functions.
cecho("<:white><red>text")
is no longer valid. I used to be able to set the background color of the cecho without having to set a fg color in the same tags, but it seems that's not the case anymore. Any chance of this being changed back? Kinda broke one of my functions.
Re: Mudlet 3.0.0-delta (preview #4)
There'll be an ansi2rgb function available to handle this.mishgul wrote:Ah, yes, but I am receiving the colour as text from gmcp.Comms in the following format
[0;37;41m(Khairt's Barrel): You say, """."[0;37m
and I was hoping I could convert those numbers from ANSI to text in a script without having to add triggers to my client, but I guess I will have to if that is not possible.
Re: Mudlet 3.0.0-delta (preview #4)
What did you want it to do? You don't set a foreground at first, but then you set it to red after.Erant wrote:Mudlet 3.0 is pretty great. My only complaint is that cecho() seems to have been quietly changed, such that this:
cecho("<:white><red>text")
is no longer valid. I used to be able to set the background color of the cecho without having to set a fg color in the same tags, but it seems that's not the case anymore. Any chance of this being changed back? Kinda broke one of my functions.
Re: Mudlet 3.0.0-delta (preview #4)
I have a function that I occasionally only give a background color, or only a foreground color. Don't feel like digging it up right now but it's basically:
banner(text, fg, bg)
And I would do:
cecho("<:" .. bg .. "><" .. fg .. " >" .. text)
As of 3.0, the first tag is broken. I suppose I could hack something else together, but this functionality was handy.
banner(text, fg, bg)
And I would do:
cecho("<:" .. bg .. "><" .. fg .. " >" .. text)
As of 3.0, the first tag is broken. I suppose I could hack something else together, but this functionality was handy.
- SlySven
- Posts: 1023
- Joined: Mon Mar 04, 2013 3:40 pm
- Location: Deepest Wiltshire, UK
- Discord: SlySven#2703
Re: Mudlet 3.0.0-delta (preview #4)
Improving the user interface for 256 colours is on my to-do pile - I had some stuff including an overhauled FG/BG colour selector for the trigger editor to put out at some stage but then got a bit worried about how Mudlet handles incoming colour settings - up to now we have matched the colours that are in the output from the MUD server on the basis of the effective RGB values that are used - however with 256 colours the situation is a bit more confusing because some of the 256 colours are, or could be, duplicates as the 256 colour range includes:
0-15: two 8 colour ranges one "bright" and one "dim/normal"
16-232: 6R-levels x 6G-levels x 6B-levels for a total of 6x36 = 216 colours coded as 16 + 36 * R + 6 * G + B where R,G & B are values 0-5 and are converted to a colour by multiplication each component by currently 42 (but I think should be 51)
233-255: 24x Grey Scale values, converted from 0-23 by multiplication by currently 10 (but I think should be 11.1 or so)
In this manner though this means that colour 0, 16 and 233 are all black for example, so which colour code do we report back to the user 0 or 16 or 233? And if we change the scaling factors as I think we should, 15, 232 and 255 are all a bright white but the latter two will be different from the first one. Alternately perhaps we will just have to return the RGB values but with the slight inaccuracies of the colour encoding (each RGB component as a value 0-255) how much fuzziness in detecting colours are we to allow - say we treat a colour with RGB values of 128,0,0 as dark red is 127,1,1 also the red that ANSI 16-colour "1" represents or not - after all look at all the fuss that that blue and black or, to me as well as a bunch of others, white and gold, dress caused - and that was down to the rendering of the colours being on the edge of what two different people perceive as different colours...
Yes, we ought to support the user getting colour information, just that we need to work out what to report to them!
0-15: two 8 colour ranges one "bright" and one "dim/normal"
16-232: 6R-levels x 6G-levels x 6B-levels for a total of 6x36 = 216 colours coded as 16 + 36 * R + 6 * G + B where R,G & B are values 0-5 and are converted to a colour by multiplication each component by currently 42 (but I think should be 51)
233-255: 24x Grey Scale values, converted from 0-23 by multiplication by currently 10 (but I think should be 11.1 or so)
In this manner though this means that colour 0, 16 and 233 are all black for example, so which colour code do we report back to the user 0 or 16 or 233? And if we change the scaling factors as I think we should, 15, 232 and 255 are all a bright white but the latter two will be different from the first one. Alternately perhaps we will just have to return the RGB values but with the slight inaccuracies of the colour encoding (each RGB component as a value 0-255) how much fuzziness in detecting colours are we to allow - say we treat a colour with RGB values of 128,0,0 as dark red is 127,1,1 also the red that ANSI 16-colour "1" represents or not - after all look at all the fuss that that blue and black or, to me as well as a bunch of others, white and gold, dress caused - and that was down to the rendering of the colours being on the edge of what two different people perceive as different colours...
Yes, we ought to support the user getting colour information, just that we need to work out what to report to them!
Re: Mudlet 3.0.0-delta (preview #4)
I had a look, but the first tag isn't broken. Just specifying <:background> still works: cecho("<:red>hi <blue><:red>hi <:yellow>hi")Erant wrote:I have a function that I occasionally only give a background color, or only a foreground color. Don't feel like digging it up right now but it's basically:
banner(text, fg, bg)
And I would do:
cecho("<:" .. bg .. "><" .. fg .. " >" .. text)
As of 3.0, the first tag is broken. I suppose I could hack something else together, but this functionality was handy.
Re: Mudlet 3.0.0-delta (preview #4)
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?Belgarath wrote:I'm having the same problem as https://bugs.launchpad.net/mudlet/+bug/1413435 in OSX. I've been using Delta for the last few weeks and apart from having to maximise/resize it when I open different profiles, that one mapper bug, and Mudlet crashing when I click on the search bar to look up something in the backlog, it is working very smoothly and efficiently.
Re: Mudlet 3.0.0-delta (preview #4)
Has anyone been giving the new Variables view a go?