I'm assuming you're concerned about Slayn being non-existant? (At least visibly.)

That is one issue, though I haven't attempted to contact him over the possibility of adding the ability to use this Flash client. He has been very helpful as we have developed our game (going on 3 years there). The server is highly stable (as I am sure you could attest). The other users seem knowledgeable, and the problems related to any hosted games there are usually dealt with quickly by the users. I have had a better experience hosting with him then the paid hosts I have used in the past. I could not be more thankful to be hosted there.

If I did contact him about this I would recommend the option of only adding the ports of MUDs hosted there that requested the service. Not stating anything by this, just that I am naturally cautious when it comes to opening ports to outside code.

I do think that a MUD listing site offering the Flash client is a wonderful idea, and I certainly wish the OP the best (and I have followed this client from first reading a post about it). I would be even more supportive if the service also offered a simple "Flash is not enabled for this game.", or the chance for a game-specific Java telnet link, for the games that cannot (or wish to not) conform to the Flash requirements.

As Cratylus said, I don't mean to rain on your parade, but installing this client from the game server side was far from the simple process that the included instructions implied. I really do wish I could use this client you've written because it is very nice looking and offers a nice starter feature set to help attract newbies, but the install, particularily with the adobe socket policy thing, is more than a little prohibitive and not just because of the potential security risks of setting it to allow access to any port at all on your server but because of how difficult it seems to be to get it to play nice with shorewall. So, unless you can either find another way to do this without the socket policy (or with an easier means to the socket policy) or you decide to also list sites that are not flash enabled, as Mabus suggested, I suppose I'm going to have to withdraw my mud's listing submission because this python based socket policy script has me beat. :sad:

In the meantime, I guess I need to find another web based mud client to try to impliment for my new mud web site current under development because good old Microsoft has, in their infinite wisdom, made it much too challenging for newbie players to figure out how to re-enable telnet for their browsers. :sigh:

Take a look at TheBean, it will serve you well.

I think some of us might have been thinking that the OP's site might be something to replace MM, which it is unlikely to be, it will however become a specialist site like Mud Quest were certain games can gain some additional exposure. One of the real selling points of the OP's plan is that this one site can be marketed to all the flash games sites and has the potential to bring new players to text gaming, that is obviously who the target audience for this site will be, not the all ready established text gamer who has pre existing and well defined expectations. For those with a game that is not in development, this site could become a useful marketing tool. I agree that the bar is set pretty high and that the site has a limited scope, but ultimately i think the OP is on the right track and someone might like to copy his lead and do the same with a java client. Again more marketing possibilities. I don't think i can think of any one person who has truly leveraged all the marketing options available to us, it would be good to see a concerted push into some of these places to see if they result in a new influx of players.

I think The Fury did a good job of summing up my intentions with MudGamers. I actually put together the site on Sunday afternoon after thinking about it for a few days, so it was not a reaction to Mudrage closing nor designed to be a replacement. Sites like TMS and TMC certainly have a place, however I wanted to offer something different that was designed more to appeal to gamers not familiar with MUDs. MudGamers is modelled after successful web and Flash gaming sites rather than existing MUD sites. My plan is that once I have a decent variety of games listed I will begin to market the site to general Flash sites, web gaming, MMORPG, browser game sites etc.

I think Connor you are being a little unfair when you say the setup process is far more complicated than I imply - we've corresponded on this issue and your problem is that your firewall is blocking port 843. I am not familiar with Shorewall, but adding a rule for the socket policy server script should be no different from allowing any other kind of TCP service such as a web server, ftp, telnet etc.

I will have a look into offering a Java option alongside the Flash, however I'd really like to see if more games can enable Flash first as I have some neat things I can do with the Flash client that will definitely enhance the site. I understand that many MUDs may just want a listing with a link to their webpage or their own client, but I really want to integrate playing the games with the community aspect of the site, rather than simply act as a feeder site for individual MUDs. For example I will soon be adding a chat window to the client that will bring players on different games together.

Anyway, this is what an alpha production stage is for so I will be listening to the feedback and experimenting with new features.

It's pretty trivial to do. In about 20 minutes
I whipped this up: http://dead-souls.net/javaclient/mudbyte...

And about half that time was spent trying to figure
out the port number of Orrin's mud (which I never did get).

Someone putting in a little more time an effort could
really do the community a service with a site that does
this. Bringing in new folks who don't know how to enable
telnet on their Windows box seems like a pretty important
thing to try to do.

-Crat
http://lpmuds.net

PS If you use Internet Explorer, the colors in the client
may be screwy, and other stuff. Don't blame me. Discuss
it with your OS vendor.

It is nicer than the jta I've been using:

http://alcatraz.wolfpaw.net:8001/bean.ht...

I've not yet figured out how to get it to go to more
than just a local mud, though. Looks like I'll probably
have to edit the source and recompile the applet
with a getParameter("MudHost"). Needs jruby to
copile though, and I'm not sure I want to get into
learning both java and ruby enough to fix this.

Still, nice client. Thanks for the tip.

-Crat
http://lpmuds.net

Will do, thanks for the pointer! :smile:


It's Conner, and you're in alpha stage testing, how is it possible to be unfair with critiques at that stage? I'll spell it out a bit more clearly for you. Shorewall is one of the most popular firewall interfaces available for Linux, the folks at Adobe aren't interested in making things easy for the masses despite your personal hopes and this flash program seems to require a direct connection to the machine running it on port 843 which must also be the same machine running the mud it's to connect with. This can not be accomplished by a setup which has the firewall on a separate machine than the muds themselves which is rather likely to be a fairly common setup for hosted muds. After spending more than an entire day trying to make your client work without success, I finally gave up and tried the JTA client that Cratylus told me about and had it working from every browser I could find in Windows and Linux on our side of the LAN (yours only seemed to work from IE and Firefox, not from Opera, Safari, Chrome, or Konqueror even locally). I'm still waiting for someone to become available to test it from outside our firewall for me, but the fact that it doesn't require any ports to be open except the ones I already have opened anyway seems like that should pose no trouble for me. …correction, we just had a couple of successful connections via the JTA client from folks on IMC too while I was writing this.

(Btw, Cratylus, you'd commented that you could only vouch for version 2.5 rather than 2.6, I'll vouch for 2.6 now though it does seem to not want to do the button bar for me, but that could be my not getting the conf file for it done right too.)


If you do get a Java option going, I'll be delighted to be included in your listings, but either way, I think the idea behind what you're trying to do is well worthwhile and I wish you the very best in success. If you'd like me to do so, I can continue to try to help you alpha test by seeing if we can find a way to trick the socket policy into letting it go through but I'm not entirely certain that it can be done under my current setup (I had even tried moving the policy file and script to the firewall server to run from there and then I couldn't connect from the LAN either anymore. :shrug:) and I'm not willing to do it on my own just to prove that it can be done if it won't serve you any because in itself it won't really serve much purpose for me at this point. On the other hand, I did really like your client and I do think it's got great potential if you can find sites it will work on or can find a way to get around this bizarre socket policy restriction.

Orin, maybe also a portable flash one that people could put up on their mud's site? One that'd have a link back to MudGamer's etc.

Ps. I still need to contact Dale and see if he'll do the setup, not sure if he needs to do it on each host machine or not? I'd guess so right? Or maybe once for the domain?

Thanks for the info. I'll be continuing to test 2.6 this
week as well. The one thing I've found that I do not
like is that 2.6 does not like to connect to a mud on
a different server than the page that served it.

Trying to use 2.6 to do the stuff I did with 2.5 on the mudbytes.html
page in an earlier post fails :(

No biggie, though. Other than that it seems ok, but I'll
keep playing around. The_Bean is much more sophisticated,
and I'm in love with its input box and command history, but
it's way loaded with stuff that makes it hard to customize :(

One more note on the flash dealie, in my investigation,
it turns out that the flash app *first* checks for a
socket policy server on the destination port, and if
it doesn't find it, goes to 843. This means that if you
can code an Adobe monitor into your login process, you
might be able to avoid having to run a separate policy server.
I've heard from at least one person who claims to have done this
successfully for their mud.

Perhaps an "Adobe snippet" will eventually emerge for this.
Plenty of experienced people here with the capability, I'm sure.

-Crat
http://lpmuds.net

Why does the checking for a socket policy on the normal port not interfere with the MUD's processing of the input? Does it use some kind of negotiation that the MUD ignores?

I didn't get into that level of detail with him. He did,
however, indicate that it was a real pain to accomplish.

I'll ask him for more detail when I see him again.

-Crat

EDIT:

Or ask him yourself…

http://www.antikaria.com/FMud/FMud.html

Follow the bc-dev.net link in my sig and a version of the client is available for download, but you're still going to need a policy file for the latest versions of Flash player.



From theAdobe documentation


As it stands now it's certainly possible to do it this way, however it seems that Adobe really want to move towards master policy files for a domain being served from a central location. I haven't tested it under these circumstances, but I believe in the latest Beta release this behaviour has to be specifically allowed by a master policy file anyway, so it's a little redundant.

So from the MUD's perspective, it will be seeing a connection that immediately closes? It looks like the client is trying to make a connection that the MUD will not understand, and it'll presumably either close the connection itself or send something back that the client thinks is garbage, at which point it'll close the connection.

Forcing a master policy service seems like a rather draconian thing to do… the whole thing makes me pretty uneasy.

I don't think you can do this without port 843, unless I'm mis-reading something. From the Adobe docs linked by Orrin (emphasis mine):

File "./flashpolicyd.py", line 40
    with file(path, 'rb') as f:
            ^
SyntaxError: invalid syntax

I haven't even looked at the version of FMud i have on my website in ages, i seem to get this error tho when i try and start the socpolicy, any idea as t what might be happening?

You need Python 2.5.

If anyone wants to try some different methods for serving the policy file there are these scripts from Adobe.

When did that change because it used to work, that is the files that came with FMud v3, Ok i got the perl script to run, but still no connection, i am not sure whats changes as it all used to work well. Looking at the table of open ports on the corporate firewall that surrounds my vps port 843 is closed so that might be an issue, can i use another port?

I am pretty sure that the python scripts have always needed Python 2.5, I know it's something I've had people contact me about before.

You need port 843 open to run the policy file server. I'm a bit surprised that your VPS provider is blocking ports like that as that does seem contrary to what a VPS is supposed to be.

You've got my email so if you want to send me some more details on your provider and setup I will see if I can help you get things working again.

I ended up using the Perl version of the policy server. Works without a hitch.