View Single Post
Old 04-15-2008, 02:45 PM   #9
shadowfyr
Senior Member
 
Join Date: Oct 2002
Posts: 310
shadowfyr will become famous soon enough
Re: Are MUDs the clog dancing of online gaming?

You nailed most of the things that have bugged me right on the head. Some of those are fixable now, in "some" clients. Some are fixable in the future, with "some" clients. Frankly, I keep hoping, now that Mushclient is source available, someone with way better understanding of script integration and event handling will look it over and figure out how to get those things to work, ironically, the way they do in IE. We badly need basic controls support, and some way to use the COM system via scripting to plugin in external objects, so we don't have the limitations we do now. At the moment, their are only two ways to take, I don't know, lets say IE itself, and patch it to Mushclient:

1. Create a shell application that has UDP support, and creates the IE instance itself, handles the "page finished loading" event, then links via UDP to Mushclient, so that your script can receive noticed that data came in and respond to the "event".

2. Create a shell applicaiton that uses the Mushclient .tlb structure to get callbacks to the client, and creates the IE instance itself, handles the "page finished loading" event, then calls, using data passed "from" the script, CallPlugin(some_hex_number,data), then have that plugin try to figure out what the hell to do with the data, which is *not* able to contain more than like 255 characters, even if the data you need to send it does.

The *correct* way to do this would be something like:

But, this just isn't possible at the moment. If it was, then it would make using external applications unbelievably easy, make designing them easy, make using controls as easy as downloading the dlls for something like the VB runtimes, etc. The only thing the client itself would need to supply is the handlers for the objects, tiny bit of code, but a pain in the ass to manage, and a basic window that supports control container features. Everything else could be done via the script system.

You can't imagine both how fracking hard it is to either find how to manage the above though with a scripting system, or how much even more insane it is to try to do it with MFC getting in the damn way.

A lot of stuff it would be nice to see are just plain trade offs. Mushclient doesn't currently support 1) blinking, 2) text positioning, 3) inline graphics, 4) more than one font at a time, 5) a mapper. Why? Because the first four make writing the custom windowing code even *more* complicated. The last one the author didn't even have the first idea where to start making one. He figured an external for that might be better, and I tend to agree, since as things stand with scripting, some stuff, like path finding, would lock up the client while it ran, and synchronization of the script to the triggers, etc. without having the client suspend while they ran... isn't too feasible. And external, with proper integration is better for that.

Anyway. Point is, clients tend to be hit or miss when universal, since there is always "some" features that are not as practical as one would like them to be, which never make their way into the client. And, invariably, the ones that do have them, are missing other things. Ones like Batmud, which is mentioned, have a leg up only due to the fact that they don't even try to be universal, so don't have to make apologies for not supporting some feature the mud itself doesn't supply.

Some, like the one I use and mentioned, are so damn close that my teeth itch, but none of those of us that use it have the slightest fracking clue how to fix the problems, including the guy that wrote it, who frankly has no intention of fixing some of the things I consider flaws himself (not when he had to release the source to keep it alive, since no one would fracking pay him for using it).
shadowfyr is offline   Reply With Quote