Member Discussions

I am interested in adding web-integration into the MUD I help run. Currently I am using Clandestines' Webwho.c code to output who's online to a web page. I would like to do more web-related outputs, such as help files and skills/spells. Does anyone know of code to do this that would work with a GW base? I am running a Fallen Empires 2/Battle of the Immortals GW base.

Trelin

look at the webwho parser.. i think it triggers off a "/webwho" type argument.
You can make other arguments that are passed, and have them send relavant input: "/areas" might show the arealist, "/finger" might send finger info on the next part of the arg, helps can be dome similarly (though helps are a bad idea, they usually don't change too much, so more economical to just make a command to generate a set of pages for the helps), but stuff like that would work.
Of course, I don't really see much of a point for a webwho that works off teh webserver, most muds would do better just updating a html file every few minutes, but it depends on how often the page is requested, how up to date you want it, and how many people are usually on, etc...

Come on, creating web pages from the mud is easy. You know HTML right? Just have the mud output html code into the file (if you have a public_html dir, if not, you'll have to make the game upload it, too, but that code exists as well), and you have a webpage!

Ok, first off, head out and get a book on MySQL, or find a tutorial on the net. Then you probably want to learn some PHP. This will give you a better style of web integrations. Its a shame I don't know more, because this is also something I'd love to learn... maybe I will and post a link to the tutorial I used. Anyways, thats enough from me :)

Davion

Yes that is what one would do. We took the same kind of webwho online code, and turned it into an integreated websever. Shows your helpfiles, skills, spells, groups, and has a section where you can login and read notes and see whos online, (according to your characters ablity.)

Also for the administration we have some olc things in the logged in section cause some things a little easyer to edit using a browser then the mud.

If you would like to look at it feel free to take a glace:
http://www.rotf.net:5001/

That will take you to the webserver section.

Heh, mine's still not quite pulled together :P
I've got the current finger section at en3.servegame.com/finger - but you need to know the name you are looking for atm (if you want to check it out, you can try DaShiVa - but I don't remember how much finger info I've set :P) Then there's en3.servegame.com:6666/areas kinda self explanitory... but I'm mostly working on the SQL side of things atm, and the new site layout, while trying to finish the code, so it won't be finished for a while yet.. I expect I'll remove the actual webserver and use the MySQL for everything, easier to work with, and more efficient, in the long run.

Check this out: http://ice.cold.org:1180

This is the Genesis/ColdC server running ColdCore. It integrates a webserver into the game. You can view rooms and descriptions, all the muds objects, note boards, and help files.


(Comment added by Tyche on Wed Feb 25 16:37:38 2004)

Oh yeah you can even view the code:

For example, this is the routine that is processing your HTTP request:
http://ice.cold.org:1180/bin/method?target=%24http_connection.parse()

> Yes that is what one would do. We took the same kind of
> webwho online code, and turned it into an integreated
> websever.

I wouldn't recommend turning your mud into a webserver. Not only do you suddenly have to deal with all of the webserver issues that have been solved before (e.g. http parsing, headers and output buffering, authentication), but they have severe limitations.

What happens when you want to integrate your web stuff with the rest of your site? Answer is, you can't. You have to embed some of your site presentation into the data that's being returned, so when you go to update your site you have to also update your mud. For example, if I wanted to display how many new notes a guy that logged into my site had, I'd have to make an iframe completely separated from the site, and I wouldn't really have the data ready for in-line display if I wanted to change things.

It's just the wrong tool for the job. What you really want is an RPC mechanism (I use XML-RPC). The benefit of this method is that I can not only use the data I receive in any format on the web page, but I can also use the RPC interface in scripts that present the data in other ways. I've got a script that displays the list of logged-in users when I log into my terminal, for example. And I could write an external (non-web) NPC editor at the drop of a hat because I didn't waste my time parsing HTTP POST variables and formatting GET requests to implement the save/load methods =).

Yui Unifex

The best way I can think of you doing it is writing your own intergrated webserver using the same kind of socket code the plain sockets use. That way, you can build a very expandable system and you don't have to pump out webpages every so often. You can just generate them using plaintext.

All you need is the socket code and a very basic understanding of how an HTTP connection works. Its quite simple if you're up for some reading. just google it for awhile.

The best way you can think of is writing your own webserver? You're high, aren't you? :)

.

I really really wish I was. But its eaiser without drugs.

I mean best because you can expand on it in any way you want, where as writing to an HTML file limits how current your information is. And a webserver isn't that hard if you know some socket code. I'm not talking about a full RFC compliant server. just complex enough to be able to push various content types like images, pages, and maybe the occasional executable or whatnot.

But yes, some data would be easier to just pump out to a plain html file. others would be nice to pipe straight from the active world. idk. call me high if you want. your opinion.

The catch I ran into with my webserver (based on the webwho code... and yes I know it's more than a little limited initially, but mine's evolved to parse the query strings and do some stuff the right way now...) was the limitation of not being able to see oddbod ports from behind a firewall.

I've since "solved" the issue by using what amounts to a port bouncer CGI... it's not very exciting, but it does the job and is easy enough to modify that (now that it's working) I'm tying it into the rest of the site with some PHP, a little bit of getting the mud to do displays for me and a fair amount of form juggling.

I've chosen my approaches from being too lazy to make the mud communicate with an SQL server or the website to play nice with one.

By and large it works... there are limits of course, but it does what I want it to do and I've managed to make myself relatively happy with it.

Looking at the code is an interesting feature... but one I can't say I'll do myself... I thought ftp, backups, warmboots and unpacking tar files was quite dangerous enough.

As always, your mileage may vary.

Dsarky and the One Thousand Monkeys

There is one catch with using RPC...

You are limited to using components which have been installed on the system.

For myself, being that I have had to be a BYO implementor on pretty much every host that I've ever been on (to a greater or lesser extent) it's proven reasonable to follow the in-built web-server approach.

While I would simply LOVE to use an RPC implementation, I'm not sure I want to run the risk that if I move servers, have to code and compile on an unfamiliar box, (you'd be surprised how often this happens to me) or rig up something to house stuff temporarily, that my web services won't work. This being the case, I'm prepared to limit my desire to use what is frankly the best, most front-end customizable option for ease of portability.

After all, with creative use of style sheets and a front end template (in the form of the port bouncing cgi script mentioned in my other post to this thread) encapsulating a small amount of html printed straight from the server, I'm not losing a lot of the variability for my trouble.

My 2c,

Dsarky and the One Thousand Monkeys

> There is one catch with using RPC...
>
> You are limited to using components which have been
> installed on the system.

With the implementation of RPC that I use (XML-RPC), the server end is compiled directly into the mud (it is no library), and the web client piece is a php file that is included. There are no external dependencies for this functionality, although I would actually prefer if they were external libraries.

I would not pay for an account on a server where the admin refused to install a specific component or library that I needed to function. That's just sub-standard service.

> After all, with creative use of style sheets and a front
> end template (in the form of the port bouncing cgi script
> mentioned in my other post to this thread) encapsulating a
> small amount of html printed straight from the server, I'm
> not losing a lot of the variability for my trouble.

Unfortunately my shell does not parse HTML, so the who list output I mentioned earlier wouldn't display very nicely on it. And I couldn't integrate that list or any functionality into applications (such as external builders) that didn't parse HTML either. But since you've got an extremely simple setup, I suppose your solution works for you, and that's what matters.

Yui Unifex

It's easy to avoid using a port using mod_proxy in Apache. I run my commercial site such a way: the url foo.bar.com is written in apache to localhost:4000, where a Python application server is listening. From the outside, it looks just like a subdomain.

In your VirtualHost you have just:

         RewriteRule /(.*)               http://localhost:4000/$1 [P]

You might need to use a little patch to Apache to get the original IP address transferred, too (if you care).

There is negligable speed cost to this (good enough for million daily requests for me).

Which is all well and good so long as you have control over the web server...

Unfortunately I don't have that luxury... and I felt like seeing if I could write a bouncer to do it :}

I should probably look at the XML-RPC offerings again... I guess I just didn't spot the server you've got in place, which is not entirely surprising :}

While I have no doubt that any server I signed up for would be happy enough to install stuff, I'm just all about the instant gratification thing... Well... I guess it's as much for the nerd factor of proving I could make it all work as anything. But now you've got me wondering how much fun it'd be to get RPC working for me... :}

And I guess it hadn't occurred to me to try to connect the same concept to external builders, etc. Now I'm never going to sleep tonight thinking about the possibilities :}

I need more hours in the day...

Dsarky and the One Thousand Monkeys

You could check if your host is running php or perl. If so.. have fun!!