16 Dec, 2014, SlySven wrote in the 1st comment:
Votes: 0
We are just adding in support for strike-through {ANSI Code "?We are just adding in support for strike-through {ANSI Code "?[9m" = on and "?[29m" = off} to Mudlet and there is a bit of a debate as to whether we should also include support for over-line, inverse and {god-forbid} blink. I realize that this is a bit chicken-and-egg between Server and Clients but does any MUD servers use them, or is it like nipples on blokes - [i]purely decorative and not much use in the scheme of things?[/i] :wink:
16 Dec, 2014, Kaz wrote in the 2nd comment:
Votes: 0
I have used the reverse video attribute before because clients do not have a detectable background colour and it gives a better user experience than white-on-blue becoming blue-on-white instead of black-on-white all of a sudden, for example.

But I don't have a particularly large audience, so I'm probably not representative. I'd say do it anyway, though. The more features you put in the client, the better potential for servers. The development effort shouldn't be *that* large, right?
16 Dec, 2014, roguewombat wrote in the 3rd comment:
Votes: 0
Holy crap! I didn't realize Mudlet was maintained by people in here. Its behavior (at least on OS X) has been… interesting for me. Often when I start typing, the window just resizes at random, making it hard to (well, play) see what I'm typing / resize the window appropriately. That unique to me? If not, I'd fix that before adding blink. ^_^

That said, inverse would be cool. I don't really care about blink or over-line, but I don't see why not. :D
16 Dec, 2014, plamzi wrote in the 4th comment:
Votes: 0
In my journeys I have come across exactly one MUD that used blink in their splash / MOTD screen. That's probably the only place I would even consider using it, and even that's probably going to annoy some people. I have never seen strike-through used, unsurprisingly.

I second roguewombat in that it seems like there are bigger fish to fry. If we focus on features rather than bugfixes, do you guys already support custom and bitmap fonts, MXP frames, MXP image tags, 256-color backgrounds? The MXP dropdowns could use some love as well. If you already have an embeddable browser, allowing a plugin to open a browser frame, e. g. to the help files, could also be very useful.
16 Dec, 2014, alteraeon wrote in the 5th comment:
Votes: 0
Alter Aeon disallows the use of all those tags, and has filtered them out since 1996. There are no plans to change that.
16 Dec, 2014, Ssolvarain wrote in the 6th comment:
Votes: 0
I think underline is about as extreme as I get.
17 Dec, 2014, KaVir wrote in the 7th comment:
Votes: 0
God Wars II supports inverse and underline (but not blink). They're not officially used anywhere, but players can include them in their prompt if they wish (using ^i and ^u respectively).

I could see someone using inverse for ASCII maps and energy bars (as it would give them twice as many background colours). However that seems pretty obsolete if you're using a client like Mudlet that supports xterm 256 colours.
17 Dec, 2014, SlySven wrote in the 8th comment:
Votes: 0
roguewombat said:
Holy crap! I didn't realize Mudlet was maintained by people in here. Its behavior (at least on OS X) has been… interesting for me…
The main issue we have is that we don't have as much access to/developers with current Mac Hardware as we would like - I believe one guy has a hackintosh but that about sums it up as I understand it. Of course, if a Mac user were to join our team of Mudlet Makers I'm sure they'd be welcome. :biggrin:
17 Dec, 2014, roguewombat wrote in the 9th comment:
Votes: 0
Oooh, nice! Might be a fun opportunity to practice the ol' C++. That said, I've never actually developed for OS X, but I know where to find ya now if I get the chance to play with it. :D
17 Dec, 2014, SlySven wrote in the 10th comment:
Votes: 0
Well I can't take much of the Kudos/blame - I suppose I'd better finger the member here called "Vadi" as he's our current project lead as Heiko, the "name on the box" is, currently not able to be particularly active on Mudlet ATM. Any potential coders ought to be aware that we use Git source code version control and the current development repository is hosted on Github as only Heiko had access to the old repository on SourceForge… :sad: Developer chat takes place on Gitter though there is more than the single channel I linked to here. Bug-tracking is done on Launchpad and of course a lot of user interaction takes place on the forums. Hope those links are of use and not a problem to mention here.
18 Dec, 2014, roguewombat wrote in the 11th comment:
Votes: 0
Great, thanks. I use Git / GitHub for all my daily work, so not an issue at all. :smile:
18 Dec, 2014, SlySven wrote in the 12th comment:
Votes: 0
Great, one niggle though - can you release your own code under GPLv2+ without getting complications from your Contract of Employment with those who pay you to code for them during the day? In some jurisdictions, the legislative environment and small print in their Employment Terms does cause grief for some coders doing things in their own time in the privacy of their own homes! :cry:
18 Dec, 2014, Hades_Kane wrote in the 13th comment:
Votes: 0
I've used blink in the past.

I've come to my senses.

Strike through I could see some uses for.

Overline might could be useful with ASCII art.

Overall, though, if it's not too much additional work, I'd support it all. When you have more features than "the other guy" then you have a competitive advantage for sure.
19 Dec, 2014, koqlb wrote in the 14th comment:
Votes: 0
I use underline, blink (VERY SPARINGLY), and inverse on my MUD. Of course, I have a command for players so they can
convert blink into underlined (since some people hate it). *shrug* I think the extra support is a good thing
to have. At least that way, you can say you have a wider range of support. As far as overline and strike_through…
I don't know. Players want to be able to read what's there, and personally, I don't find any use for strike through, or overline.
But I do agree with this previous post #13. Support it all, and then you have more features. :)
20 Dec, 2014, SlySven wrote in the 15th comment:
Votes: 0
Well, personally I'd like to include as many of those extras as can easily be coded. One thought on strike-through is that it might be a way to indicate something that isn't in-use or has run out without using colour which takes up the same on-screen space as the normal text; or, if anyone has ever written out boolean expressions by hand, putting a bar over a term is the textual way of indicating it's logical inversion (c.f. 'C' coders putting a '!' before the term).

OTOH: Another coder has pointed out a rather thorough rejoinder to adding too many bells and w....
20 Dec, 2014, quixadhal wrote in the 16th comment:
Votes: 0
Adding support for the full ANSI and/or VT100 set of control codes, as well as TELOPT negotiation for line or character mode, would allow mudlet to (at least potentially) be used for other things like roguelike games, and shell prompts. Just saying. :)
20 Dec, 2014, SlySven wrote in the 17th comment:
Votes: 0
Fair enuff - but Mudlet isn't a VT100 terminal (it has colour for instance!), handling an attached serial printer could be a bit tricky and there could be copyright issues in reproducing the character ROMs exactly! It's all about choosing the right subset of features that it is productive to include. Indeed, IIRC even the ANSI specification does hint that not all features will be implemented in all instances. :evil:
21 Dec, 2014, quixadhal wrote in the 18th comment:
Votes: 0
$ reply -c –pedantic post.c
reply: fatal error: poster missed point
potentially helpful suggestions terminated.
21 Dec, 2014, SlySven wrote in the 19th comment:
Votes: 0
# ifconfig eth0 inet promisc
# cat broadminded_mode.txt
"Right, now set up to accept anything going around the
network as input. Interested in hearing a range of
responses to detect a consensus whilst also trying
monitor for bogus packets. I can't promise to act on
information received but it does help to evaluate what
bottlenecks and issues others might be having both
with the Client I'm working on and other related
22 Dec, 2014, Hades_Kane wrote in the 20th comment:
Votes: 0
SlySven said:
OTOH: Another coder has pointed out a rather thorough rejoinder to adding too many bells and w....

Considering this is a "bell and whistle" that is completely and utterly invisible to the player/user unless a MUD in question has made use of it, I don't think that could really apply. This is more about providing support for bells and whistles that the users of your software may have need of based on the MUDs they choose to play, and whether something has too many, in this regard, would be dependent on the MUD they are connected, not your software. I see a distinct difference between "support" and what constitutes a bell/whistle.

MUDers are a finicky bunch, and I've seen people swear off clients for pretty insignificant things… I've never heard of anyone deciding not to use a client because it supports something the others don't… it's usually the opposite.

My 2 cents anyhow. I'm happy with the client I use anyhow, so it doesn't really affect me :)