PenUltima Online

^ Would be great.

It'd be nice if you could use xml, php, etc. rather than just html. Make it more secure(as stated above). Be able to use images(if you try to show an image with your webserver it fails to load it) also be able to transfer files, zip, rar, etc. Don't know if you guys have been doing that lately with 95 and 96 or have future plans for this stuff but... lol this idea will probably get smacked down like the rest.

While we're at it, why not add a POP3, IMAP and SMTP engines, a DNS daemon, and a news server, too? It'd also be nice for POL to be able to expose SOAP web services, and maybe it can also implement a relational database, while we're at it. Oh, and don't forget that with all of this, it should probably implement LDAP, be able to serve as an SSL Certificate Authority, and finally, it should include IRC and Jabber services, as well.

Head shot

So what you're saying Marilla, is that my "SUGGESTION" is completely irrational? lol.

I wouldn't call it irrational, but imagine the (already limited) development resources, being pointed to extending the webserver, which I think we all considered as not being the main point of POL's existance.

Wouldn't it be much better concentrating on ironing out any bugs and making the whole scripter's experience better?


I think it would.

I understand and totally agree to that. It's just a feature suggestion. I didn't say get it done first thing. It'll be really nice if in the future of POL if we'd be able to use stuff like this.

www.cfg is a grovy start.

At the risk of starting something here, I have to ask; Why re-create Apache, when Apache already exists? Why bloat POL with lots of junk that duplicates functionality already available out there by other means? In the 'future', the POL devs with have other UO features to add to POL - they still won't have time to 'reinvent the wheel' inside of POL.

And for the record, the reason I'm replying to these posts is because I would very much not like the POL devs to spend time and effort on this stuff, and fill POL up with extra junk that's not needed. In fact, if you asked me, I'd suggest they REMOVE the web server completely... but I know I'd get out-voted on that one, so I won't bother trying

(and yes, I know it can simply be disabled; that was mostly a joke)

Marilla I for once would agree with you on something.

I have never used the webserver for anything myself. Heck I have just starting looking into any interface of Apache or PHP into my scripts for some other things I want to do. I have heard about the webserver and refuse to use it.

Hate to res a semi-dead thread here, but why don't people use aux scripts and just interface their website with that?

It wouldn't be difficult to write a perl script that communicates to the POL server and set it on a cron job. The perl script could retrive any information that the aux script has access to (more or less everything on the server). The perl script could store this information in a database which is then accessed by your PHP scripts.

You could even create a web-based POL-authenticated administration portal. Just have username/password forms on your PHP script, send the forms to your perl script, which then sends the information to the aux script which returns if the login is valid or not. Then you could easily implement commands like broadcast, and it wouldn't be impossible to have highly graphical and interactive representation of the world using an big image of the world and some javascript, or even ajax.

The only time you should request a feature is it could generally help make the UO emulation better or add some functionality that is virtually impossible to do using scripts (that is to say, it's very ugly/incredibly slow if you use scripts).

The core is called the CORE because it does very little. When you take into consideration the amount of functionality you can hook and control yourself with scripts, the core does almost nothing but open up some ports, run scripts and lower-level stuff. This is the beauty of POL.

I'm not saying don't request features that would be cool ever, just request them once POL is at version 1.

I don't know anything about php, perl, js, etc. I only know eScript.. And I wasn't asking for these features to be done tomorrow, maybe in the future of pol, like you said, version 1. just as long as it's considered, it'd be nice.

I remember back about 6 years ago when I GMed for DW on Myth....He had a webpage the GMs could go to in order to check things like system load, reset "something" that seemed to help performance when the load was high, and to check on the number of mobiles. It would even give you the X, Y of large groups of mobiles.

This was a huge help since the admin was often unavailable for large chunks of time. Like one night, a town guard went to hacking on a slime that just kept splitting. There were over 2000 slimes in the area of a half-screen.

Another time, a town guard (probably the same troublemaker) trying in vain to get into a graveyard and slay a lich. The lich, wasn't messing around....he had called a huge army of undead, all crammed into a tiny graveyard and jostling next to each other.

I have no idea how he created that page, but it really came in useful for us. I wish I knew enough to re-create something like that for my folks.

Oh, and I realize this might not even be the appropriate place for this post, but I like the idea of a little more web support.

I was just trying to suggest using aux scripts, not trying to sound mean. The "don't request silly features" wasn't intended for you.

I'll tell you what though, if I knew php and stuff I'd use aux scripts. But I don't, .

This will help you learn Unreal

http://forums.polserver.com/viewtopic.php?t=86

Yup; there are lots and lots of really cool things that can be done through AUX and WWW scripts in POL; Anything you could script in the game could get an interface to -any other program at all- via one or both of these.

Whether being accessed through something simple like PHP or ASP, or a full-fledged C, C++ or .NET program, you can really do anything at all through them.


You could - with nothing at all but eScript - write a set of WWW pages that do exactly what the pages you described do. Though I never recommend providing direct access to WWW scripts to clients (I use them only to provide XML output to other systems), you CAN do it... in fact, that's what they were designed for. You can even link in images and such all you want.

For example, I've seen - entirely in eScript through the WWW scripts - a system that displayed a map, and used CSS (again: INSIDE the eScript WWW page) to put a mark on the map for where a player was located... and the map image was served from within POL's www. Again: I don't recommend this.. but there's no reason the WWW POL script could not simply link to the image hosted on a 'real' web server, but still be entirely scripted in eScript.

I just would not want to have POL taking up the task of loading an image into memory and having to stream it to a client, is all. No sense putting more load on it than needed, when web hosting is 'a dime a dozen'.


Let's just imagine this, as a simple example of a possibly useful WWW script:

(Note: I'm typing as I'm thinking, so it's very likely there will be syntax or function name errors here)



Note how the URL is 'built' to point to killmobile.ecl, and pass the serial of the monster. killmobile.ecl would then take the QueryParam("serial") and use that to get a ref to the monster, and kill it.

Of course, this example does nothing to validate that the person loading these pages actually should be allowed to kill a mobile. It also does not list nearly enough information to know if you really want to kill that mobile or not. But I have a similar system which is used to reset the graphics of mobiles whose graphic numbers have been set to an invalid value which crashes the 2d client; So if a GM messes up and sets something to an improper graphic ID, they can simply go to the page, and it tells them there last location (because the web site has their account login info, and passes it appropriately), or lets them enter a custom location. The script lists the mobiles in the area and shows the graphic IDs, and lets them choose one. The script that handles the link takes the serial, and gets a ref to the mobile, then resets the graphic on that mobile to 1 (ogre), which is 'safe', so they can log in without crashing.

So, just a wild idea of maybe one way a WWW script could be used to pass any information you like, and can be used to let the viewer actually take ACTION that has effect in the game. If you were really crazy, you could even design a playable 'web client' for the game through WWW scripts - though obviously, performance would be totally unacceptable.. .but ALL the information and capabilities are there.