I'm not entirely sure you understand the architecture of Aspect, Quix. Instead of chasing you around, would you kindly explain what you think it is so I can more easily correct you?

I think quixadhal looks at said proxies as they were meant to be installed by MUD owners (just like standalone DecafMUD) and I guess you want to set up your own proxy for many MUDs (just like the DecafMUD demo).

I'm curious. Why?

Virgud is correct. I am assuming a proxy will live on the server's side of the equation, because the usual reasons you want a proxy are either a lack of port forwarding into the network the MUD server lives on, or because you want to provide a client through your web server. In either case, your target MUD is well known.

I guess you could be trying to make a generic client that could live on some arbitrary web site and let you select from a list of MUD's to connect to, but I'm not sure many people would really want such a thing. If it works that way, the client can't easily be customized to work well with a particular MUD, other than by each individual user. Also, you now have to convince multiple MUD admins to alter their codebase to support whatever mechanism you use for the real IP transfer, or they have to accept that a (potentially) large chunk of their players will look like they're multiplaying.

I guess it would be useful on a site like TMC, as a way to quickly try a large number of different MUD's, but I'd expect once you found one you liked, you'd want to customize things, and I doubt TMC would want to store per-user, per-mud, custom settings for everyone.

1) Most hobby programmers are only used to dealing with classic string data, they'd have to switch their data handling in order to implement NEW-ENVIRON.

2) NEW-ENVIRON doesn't support nesting, making it limited as a data protocol. You could enhance NEW-ENVIRON with nesting support, fix the NULL byte issue, and get rid of some protocol bloat, but then you'd have re-invented MSDP.

Soooo, you want people to fully support TELNET, to handle the subnegotiations MSSP/MSDP require… but you think anyone who does support TELNET (which itself expects NUL bytes in several places), would find the NEW-ENVIRON feature too difficult to use?

I lol'd. Loud enough to wake the baby.

I think I need to disagree. Such a website with list of MUDs to play straight away from within the site could gain some popularity. I can easily imagine more than one website like that. Then inventing a protocol to transfer real IPs would be needed, at least for those who would wish to both let people play their MUDs from such proxies and to be able to ban individual addresses of people playing from behind them. The others could just ban proxies and not bother implementing the protocol/format or just ignore the whole matter. The protocol/format would be for those who would wish to use it.

Now we're on the same page. :wink:

Yes, it can be customized. My plan is to let MUD owners create mods that can be enabled by default for their MUD, thereby allowing them to customize the client. It's no different from, say, what KaVir did with MUSHclient, except you don't have to deal with distributing your changes (since it becomes the default interface).

The IP transfer is meant for MUDs that disallow multiplaying. If a MUD doesn't care, they don't need to implement anything. Plus, It's up to the MUD whether to register with Aspect at all; I'm not going to let players connect to an arbitrary host and port because that's basically an open proxy. I'm betting everything on getting a couple popular MUDs on board and making Aspect into an attractive option. If nobody particularly cares, I guess I'll just release it as a client-side proxy.


I'm going to stay in control of Aspect. If you want to embed Aspect into your web page that's fantastic, but the only place Aspect will run is on my server. Actually, that's kind of the whole point: I handle things so you don't have to. Client settings are stored remotely. Mods will be centralized and easy to find. MUDs can customize the interface and be assured that it will be the default for everyone, no matter where they're using Aspect from. And users can play multiple MUDs from the same page (which may not be important to some, but I do it fairly often. Like Achaea, Lusternia, and the Talon IMC)

wooo!

-Crat

I can see the benefits in organising it that way - but it does also raise some of the same ransom concerns that were discussed with ScapeFx.

If I spend several days/weeks/months developing custom mods for Aspect, what happens if you decide to pull the plug? Or introduce a licence fee I can't afford? Would all my effort be tied into the fate of the client, or would it be in the form of Lua scripts that I could at least partially reuse?

I vomit in disgust.

Thanks for raising this question, it's a very important one. :smile:

I'm writing Aspect because I care about MUDs, and I want to see them thrive. I can promise, right here and now, that if I decide that I can't keep running Aspect, I will release the full source code. Doing anything less would be counter to that motive. As it's a proxy, you could use it as a local client (assuming it runs on your platform) or you could host it on your own server. In the case of a MUD admin like yourself, you would probably run Aspect on a server so that your users are basically unaffected.

There are always certain risks inherent to using a platform. While Aspect is running, I can't promise I won't make dumb decisions. But I will try my best to avoid dumb decisions and put the interests of my users first. And if you have any concerns, I'm always open to criticism. (Just don't berate me. That doesn't get anyone anywhere. :thinking:)


EDIT: As a side-note, I almost have ANSI colors working. :surprised: Maybe I should find one of those horrid DBZ games to battle-test it.

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.



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?)

Twisol, were you the guy who was charging some time back for a Javascript client with a similar setup – you could play many muds from the same proxy which saved your settings? I can't remember the name of the service right now.

Nope. This is my first step into the field of MUD clients.

EDIT: Apart from, you know, contributing some things to MUSHclient. But you know what I mean.

Looks like it's a free with ads service.

After previously ducking out, Runter makes a brilliant return to the game with some quiet, safer positional play.

I meant that if someone's going to hack around from scratch they'll have an easier time as there aren't examples of how to deal with unterminated data in most codebases.

This is probably going off-topic, but I don't really see what's wrong with:

char buf[1024];
int length = recv(sock, buf, 1024, 0);

recv() directly returns the length of the buffer. If you throw that away, I don't know what to tell you.