08 Apr, 2011, Twisol wrote in the 21st comment:
Votes: 0
Holy cow! I just optimized my renderer a bit (by buffering style runs in a document fragment and inserting them into the output all at once), and my rendering speed for a 37x25 ANSI-dense wilderness map dropped from 120ms to 14ms! Rendering 8bit's on-login ASCII art banner (which has become my informal benchmark) is also way faster.
09 Apr, 2011, Scandum wrote in the 22nd comment:
Votes: 0
Twisol said:
Testing confirms that those cases work as described, but I do have a question. What should happen given \eTesting 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.[/quote]
It should indeed be bright red. I'm kind of starting to wonder if it's worth the trouble to promote the 90 and 100 codes. From a client perspective it can't hurt, from a server perspective it's too much of a gamble. Hopefully xterm 256 colors will cover it all, once the detection issues are taken care off.

[quote=[url=/topic-3362-55038#p55038]Twisol[/url]]
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. [/quote]
I think it's \e[38;5;1m ?

[quote=[url=/topic-3362-55038#p55038]Twisol[/url]]
I'm going to have to have, I don't know, an @xterm flag… Alright, changed. Feels like a hack, but it works.[/quote]
I think I'm doing the same with tt++'s html logger, it's a lil messy but I doubt there's a cleaner way.
09 Apr, 2011, Twisol wrote in the 23rd comment:
Votes: 0
Scandum said:
I think it's \eI think it's \e[38;5;1m ?[/quote]
Er, right.
12 Apr, 2011, Twisol wrote in the 24th comment:
Votes: 0
Alrighty. I'm getting ready to put Aspect up on a Linode, and I need MUDs that are willing to act as scapegoats. :devil: If multiplaying is illegal on your MUD, you probably don't want to allow Aspect at this time, as it'll make it really hard to tell if someone's multiplaying.

Also, if anyone knows what the host/port is for a test MUD (like what DecafMUD shows as option 6), that would be fantastic. I know one was mentioned on MudStandards, but the forums are long gone and I can't find any archives.

EDIT: Just to clarify, this isn't going to happen within 24 hours. More like by Sunday.
12 Apr, 2011, Cratylus wrote in the 25th comment:
Votes: 0
Twisol said:
Alrighty. I'm getting ready to put Aspect up on a Linode, and I need MUDs that are willing to act as scapegoats


dead-souls.net 6666

It's pre-alpha, so it doesn't really have players, but maybe seeing your dingus in action for my mud
will finally help me understand what you've been flapping on and on about.

-Crat
http://lpmuds.net
12 Apr, 2011, Vigud wrote in the 26th comment:
Votes: 0
I'm wondering… Do you really need Aspen to act as a proxy? With DecafMUD, it is possible to connect directly (through a Flash socket). If you can't provide such feature, I don't see how I would want my players play through Aspen if the data gets proxied by a machine somewhere outside my country (which is not the US, sadly).
12 Apr, 2011, KaVir wrote in the 27th comment:
Votes: 0
Twisol said:
Alrighty. I'm getting ready to put Aspect up on a Linode, and I need MUDs that are willing to act as scapegoats. :devil: If multiplaying is illegal on your MUD, you probably don't want to allow Aspect at this time, as it'll make it really hard to tell if someone's multiplaying.

Feel free to test it on godwars2.org 3000

There are no rules, the mud supports XTerm 256 colour (which can be enabled through TTYPE, MSDP or the in-game 'colour' command). You can use the 'whois' command on yourself to view which protocols your client has negotiated, the screen size from NAWS, and the reported name of your client.

Type 'home' when you connect to go to your private plane, so you don't get spammed by other players. There's no hunger or thirst messages, no idling out, etc. Use "config" to switch off any other channels that are spamming you.
12 Apr, 2011, sankoachaea wrote in the 28th comment:
Votes: 0
KaVir said:
There are no rules, the mud supports XTerm 256 colour (which can be enabled through TTYPE, MSDP or the in-game 'colour' command). You can use the 'whois' command on yourself to view which protocols your client has negotiated, the screen size from NAWS, and the reported name of your client.

Type 'home' when you connect to go to your private plane, so you don't get spammed by other players. There's no hunger or thirst messages, no idling out, etc. Use "config" to switch off any other channels that are spamming you.

This made me want to start playing again! I love the 'whois' option.
12 Apr, 2011, Kayle wrote in the 29th comment:
Votes: 0
Just because I'm curious, you can use Sith Wars as a test bed as well. We're don't really have a lot of players, so aside from some of the staff greeting you when you log in you shouldn't have any other spam to worry about.
The connection info is on the website, I can't remember it off hand because I've only been awake for 3 minutes or so…
12 Apr, 2011, Twisol wrote in the 30th comment:
Votes: 0
Vigud said:
(through a Flash socket)

There are features I want to implement in Aspect that aren't possible with a direct connection. Plus, I'm not willing to make Flash a requirement of Aspect; my whole goal is to use no Flash, Java, Silverlight, etc., or only for those things that the browser platform still sucks at.

Also, I have tentative ideas for sharding Aspect such that I could put something live at the Linode center in London, and use DNS resolution to determine which server you should connect to for lowest latency. Of course, I have other priorities right now.


Thanks to everyone who offered their MUD. :smile:
12 Apr, 2011, Twisol wrote in the 31st comment:
Votes: 0
Kayle said:
The connection info is on the website, I can't remember it off hand because I've only been awake for 3 minutes or so…

If you mean the website in your signature, it seems to be down.
13 Apr, 2011, Kayle wrote in the 32nd comment:
Votes: 0
Hmm. Not down, wrong address. Should be fixed now.
17 Apr, 2011, Twisol wrote in the 33rd comment:
Votes: 0
It's looking like my hoped-for release today isn't going to happen - I've had a pretty packed week. I'd like to aim for sometime within the next week. Here's a list of things I want to accomplish before going live:

* Fix the output area (re)sizing. It's locked to the size of my browser viewport right now, and I use a rather high resolution. You probably wouldn't be too happy with me if I released before this was fixed.
* Build a dialog (or something) for selecting a MUD. Right now the MUD to use is hard-coded into the JS…

On the bright side, I have support in for the IBM/OEM charset. This plus xterm-256 color support means Aspect effectively complies with FANSI. It's been tested with 8bit-MUSH, so I know it works.

MXP support is on the long-term list, and MCCP likewise. And I seriously need to work on alias/trigger support.
23 Jun, 2011, Twisol wrote in the 34th comment:
Votes: 0
I got my two bullet points above done, after a long delay. I had to stop working on Aspect for a little while, then I moved my client-side code from MooTools to jQuery + Backbone.js. The output area is now sized to take up all remaining space in the client area, and if the input bar resizes (e.g. you type a lot and it grows a new row), the output window shrinks accordingly. I'm using the built-in prompt() function to ask the user which MUD to connect to. It's not the prettiest thing, but it's an excellent rope bridge.

I also spent a lot of time optimizing the render process. The biggest issue is that getting an element's scrollHeight (the size in pixels of the area you can scroll through) takes forever to calculate right after you add a lot of text. So I'm rendering in chunks, updating the scrollHeight much more quickly, and if it takes too long to render all of the chunks I schedule another run with setTimeout(). The result is a very responsive render which, while taking longer overall than DecafMUD for large amounts of data, looks and feels fast.

I have Aspect up on Heroku, but for the moment it isn't running. I'm going to clean a few things up over the next day or so, and start it up in open alpha. Only the MUDs that have offered to let Aspect connect will be available, and anyone can add or remove their MUD at any time by asking me. I'll also be running a MUD client test server from home occasionally, but if it doesn't connect that means I don't have it up.


I want to work on improving my Node.js binding to Anachronism after this, so I can start getting MCCP and the like implemented. Not sure when aliases/triggers will be added, but it will probably be extremely simple text replacement until I have a good plan for scripting.

I'm also not sure how to update Aspect without kicking everyone off. Maybe I should add a broadcast message I can send from Aspect that'll pop up an alert?
23 Jun, 2011, Runter wrote in the 35th comment:
Votes: 0
Quote
'm also not sure how to update Aspect without kicking everyone off. Maybe I should add a broadcast message I can send from Aspect that'll pop up an alert?


If it's that much of an issue there's always using a separate deployment and just updating it once a week or so once you're ready to push it over.
20.0/35