07 Apr, 2011, Twisol wrote in the 1st comment:
Votes: 0
Twisol said:
I just read the thread on ScapeFX you linked. Wow. :ghostface: I couldn't get over the chip on Hephos' shoulder. At any rate, I'd like to quote 'tommi' from this post, and provide my answers.

Quote
In business there are some standards you should always follow before you announce anything,

1. know your products strengths and weaknesses,
2. know your competitors products strengths and weaknesses,
3. know what the market wants and needs,
4. know who your customers are and the best way to reach them.


1. It's based in the cloud, so you can play from any computer using the same settings. It will have a plugin API, though I haven't decided between client JS or server Lua. MUD admins can create a default interface for their MUD. One weakness is its lack of a direct interface with the OS, making certain things impossible or undesirable. Another is that it's not open-source, though I will (and have) open-source components such as Anachronism, my Telnet library. (I'm aware of elanthis' libtelnet, but there were a couple things I wasn't happy with.)

2. As mentioned, other clients have the benefit of interfacing directly with the OS. They also use your own computer's CPU, whereas Aspect may need some load optimizations. However, most downloadable clients take a lot of effort to customize (i.e. MUSHclient), or can't be customized at all. Even if you can customize it, your users may get the generic client instead of the specialized one out of ignorance. There is only one Aspect.

3. This is an interesting one. I know that the MUD community is small, so Aspect should attract new players to the field. I also see a number of customized interfaces for MUDs, such as Nexus (IRE) and FMud, and KaVir's MUSHclient plugins, so Aspect should make that easier to do.

4. My primary customers are the MUD admins. I have a few admins I want to contact when the time comes, and of course I'm posting here to give Aspect some coverage. After that it's unclear, but I'm hoping to take advantage of word of mouth, and player pressure on a MUD to register with Aspect.


And yes, it is likely that I will charge at some point. God, nothing like the insane ScapeFX prices though. (EDIT: Wait, ScapeFX is free now?)



I figured it would probably be a good idea to spawn a new thread for Aspect. Also, COLORS ARE WORKING! Next I'm going to clean up some of the code and work on the interface, which is currently held together by duct tape and wishful thinking.
07 Apr, 2011, quixadhal wrote in the 2nd comment:
Votes: 0
Cool, now, do you support XTERM 256 color mode?

Note: nobody else but me probably cares, but… :)

A few more people might actually care about MXP, since a handful of muds use that.
07 Apr, 2011, KaVir wrote in the 3rd comment:
Votes: 0
My protocol snippet (which several muds are in the process of adding) also includes support for 256 colours.
07 Apr, 2011, Twisol wrote in the 4th comment:
Votes: 0
quixadhal said:
Cool, now, do you support XTERM 256 color mode?

Not yet! It's on the list, but it's not a huge priority. The ANSI sequence parser I wrote was made with xterm colors in mind, so it shouldn't be hard to implement.

quixadhal said:
A few more people might actually care about MXP, since a handful of muds use that.

That is also on the list, and it's also not a huge priority. I've also heard it's a pain to implement, but I do want to support it.
07 Apr, 2011, Twisol wrote in the 5th comment:
Votes: 0
Screenshot! (link)
07 Apr, 2011, quixadhal wrote in the 6th comment:
Votes: 0
One suggestion, from the way I implemented xterm256 in my LpMUD, if you do it abstractly, you can allow the user to switch display modes on the fly. That is, in my game, I can set my terminal type to xterm256 and see the full palette, or I can switch it to greyscale and it will downconvert tags to the 32 shades of grey that are in the xterm256 palette, or I can set to ANSI and it will downcode to the 16 regular ANSI colors.

So, if you recognize the incoming tags (MXP) or escape sequences (ANSI/xterm), instead of immediately setting the color, you could run it through another layer of filtering, which would let the end-user change colors as they wish. Besides cosmetic niceness, the ability to force greyscale or convert red/green to other values might help those who are colorblind.

This isn't pretty, but this is the code I used to generate the code my LP mud uses, and it's the part you would probably be interested in, as it does the color conversions.

Oh, here are some examples:

256:
ANSI:
GREY:
07 Apr, 2011, Twisol wrote in the 7th comment:
Votes: 0
.ansi .c01 { color: red; }
.xterm .c01 { color: red; }
.greyscale .c01 { color: grey; }


<div id="output" class="greyscale">
<span class="c01">Red! (Maybe.)</span>
</div>


+ javascript to change the class of the output div, and it should work pretty well.

EDIT: Y'know what? I'm going to work on this next.
07 Apr, 2011, Twisol wrote in the 8th comment:
Votes: 0
I just added support for a few silly ANSI codes, like italics and negative image. :lol: I also killed an impressive amount of perceived lag by buffering up events from a packet and sending them all at once, rather than sending each event individually as it was detected. Since my ANSI parser is server-side currently [but not for long], it was sending a lot of events for ANSI-heavy data like the map in the screenshot I posted. Now it's pretty much instant.

EDIT: I've switched my rendering process from using inline styles (e.g. style="color: #FFFFOO;") to classes (e.g. class="fg11"). So far this means I can change the class of my output <div> to turn colors on and off completely, but it also means I can add the xterm palette very easily. Also, I am mightily impressed with the speed with which Chrome can do the change-over.
08 Apr, 2011, Scandum wrote in the 9th comment:
Votes: 0
Twisol said:
Also, COLORS ARE WORKING!

Do you support \e
Do you support \e[22m as well as \e[90m to \e[97m and \e[100m to \e[107m?

[quote=[url=/topic-3362-54991#p54991]quixadhal[/url]]One suggestion, from the way I implemented xterm256 in my LpMUD, if you do it abstractly, you can allow the user to switch display modes on the fly. That is, in my game, I can set my terminal type to xterm256 and see the full palette, or I can switch it to greyscale and it will downconvert tags to the 32 shades of grey that are in the xterm256 palette, or I can set to ANSI and it will downcode to the 16 regular ANSI colors.
[/quote]
I wonder if someone could come up with a better down conversion algorithm (no offense meant), though it's not too much trouble to use a translation table with only 256 fields. One annoying issue is that there's no information about which clients support all available ANSI color codes.
08 Apr, 2011, Twisol wrote in the 10th comment:
Votes: 0
Scandum said:
Do you support \eDo you support \e[22m[/quote]
Yes.
[quote=[url=/topic-3362-55019#p55019]Scandum[/url]]as well as \e[90m to \e[97m and \e[100m to \e[107m?[/quote]
[url=http://www.ecma-international.org/public... specced[/url] (8.3.117), so no. What do they do?
08 Apr, 2011, quixadhal wrote in the 11th comment:
Votes: 0
Scandum said:
I wonder if someone could come up with a better down conversion algorithm (no offense meant), though it's not too much trouble to use a translation table with only 256 fields. One annoying issue is that there's no information about which clients support all available ANSI color codes.


None taken. :)

In fact, if someone has a better algorithm, I'd love to see it. The one I used seems to be accurate, but too expensive to use in real-time, hence the reason my script generates a bunch of mappings which get used at runtime.
08 Apr, 2011, Twisol wrote in the 12th comment:
Votes: 0
Out of the palettes you showed, Quix, I think I'm going to support the xterm-256 and greyscale palettes. There's no reason for me to support the xterm-to-ansi palette because, well, I'm going to support xterm-256. It makes sense for the MUD to change what it sends if the client doesn't support the full range, but it doesn't make sense for the client.

The nifty thing about this is that it makes player palette customizations a very real possibility.
08 Apr, 2011, chrisd wrote in the 13th comment:
Votes: 0
Twisol said:
Out of the palettes you showed, Quix, I think I'm going to support the xterm-256 and greyscale palettes. There's no reason for me to support the xterm-to-ansi palette because, well, I'm going to support xterm-256. It makes sense for the MUD to change what it sends if the client doesn't support the full range, but it doesn't make sense for the client.

The nifty thing about this is that it makes player palette customizations a very real possibility.


Some users may not like 256 colours. It's also a lot easier to customise 16 colours than 256.
08 Apr, 2011, Twisol wrote in the 14th comment:
Votes: 0
Twisol said:
Scandum said:
as well as \eas well as \e[90m to \e[97m and \e[100m to \e[107m?[/quote]
[url=http://www.ecma-international.org/public... specced[/url] (8.3.117), so no. What do they do?[/quote]
Okay, just did some research. It looks like \e[90m is basically exactly like \e[1;30m, and \e[100m lets you use the bright colors for the background too (since 1 only affects the foreground). I should be able to implement that no problem.

Alright, implemented. Five lines.

[quote=[url=/topic-3362-55023#p55023]chrisd[/url]]Some users may not like 256 colours. It's also a lot easier to customise 16 colours than 256.[/quote]
Point taken.
08 Apr, 2011, Twisol wrote in the 15th comment:
Votes: 0
Success! xterm-256 is now supported. I haven't added the ANSI-downcoded or greyscale palettes yet, but I'll get to it. About 15 lines were added, not including the generated CSS.

I also fixed a number of bugs in my renderer, mostly due to how Javascript treats 0, "", and null as equal. I found a MUD called "8Bit-MUSH" that heavily - and I mean heavily - uses ANSI, and that really helped flush out the bugs.
08 Apr, 2011, Scandum wrote in the 16th comment:
Votes: 0
Twisol said:
Okay, just did some research. It looks like \eOkay, just did some research. It looks like \e[90m is basically exactly like \e[1;30m, and \e[100m lets you use the bright colors for the background too (since 1 only affects the foreground). I should be able to implement that no problem.[/quote]
One thing to take into consideration is that if you print \e[91m\e[22mtest the color should still be bright red, while \e[0m\e[91m\e[31mtest should print test in dim red. They should behave a like 256 color code would, unaffected by the bold flag.

I'm not entirely sure about the origin of those codes, but xterm and several other terminal emulators support them.
08 Apr, 2011, KaVir wrote in the 17th comment:
Votes: 0
A slightly random observation related to this:

I started using Fixedsys Excelsior in MUSHclient after playing with UTF-8. Something I noticed was that bold ANSI colours would also use the bold character set, which is slightly wider than the regular one, and therefore messes up the formatting of tables and such. Unselecting the "bold" box in MUSHclient resulted in using the bold characters for everything, and they're not very pretty. XTerm 256 colours allowed me to display the bright colours without switching to the bold character set.

However this brought up another issue: Some of my players reconfigure their ANSI colours in the client. With the switch to XTerm 256 colour, they suddenly found themselves using the "proper" colours instead of those they'd configured.
08 Apr, 2011, Twisol wrote in the 18th comment:
Votes: 0
Scandum said:
Twisol said:
Okay, just did some research. It looks like \eOkay, just did some research. It looks like \e[90m is basically exactly like \e[1;30m, and \e[100m lets you use the bright colors for the background too (since 1 only affects the foreground). I should be able to implement that no problem.[/quote]
One thing to take into consideration is that if you print \e[91m\e[22mtest the color should still be bright red, while \e[0m\e[91m\e[31mtest should print test in dim red. They should behave a like 256 color code would, unaffected by the bold flag.[/quote]
Testing confirms that those cases work as described, but I do have a question. What should happen given \e[1;91;31m? My implementation would currently print text in dim red, but I suspect it should really be bright red. I can change this triially for the 90s codes, but xterm has a very unfortunate problem: \e[32;5;1m generates the exact same foreground color as \e[31m, yet the latter is affected by the bold flag while the former is not. This means I have to come up with a new flag or something… bleeech. What I have now:

[code]if @bright and fg? and fg < 8
fg += 8[/code]

I'm going to have to have, I don't know, an @xterm flag… Alright, changed. Feels like a hack, but it works.
08 Apr, 2011, Stendec wrote in the 19th comment:
Votes: 0
Twisol said:
I also fixed a number of bugs in my renderer, mostly due to how Javascript treats 0, "", and null as equal. I found a MUD called "8Bit-MUSH" that heavily - and I mean heavily - uses ANSI, and that really helped flush out the bugs.

You should be using the === and !== operators for equality checking, rather than == and != with JavaScript. Adding the extra = prevents casting, making the checks much faster and ensuring that 0, "", and null aren't treated as being equivalent values. DecafMUD pretty much never uses == and != because of that.
08 Apr, 2011, Twisol wrote in the 20th comment:
Votes: 0
Yeah, I'm using CoffeeScript which has is and isnt operators that map to Javascript's !== and ===. It's just one of those things that catches you up unless you've been using Javascript a long time.
0.0/35