Ryandor.com

I am considering using UO for an extremely eclectic project... I'm curious what people consider to be the strengths and weaknesses of the different server emulators.

I use POL, have for years, and will likely continue to use it. Here are a few outstanding reasons which other emulators (I am assuming the only particularly useful/feature-rich emulators out there are Sphere and RunUO) may or may not lack.

POL runs natively on Linux

Running POL in Linux in a limited user account prevents anyone from being able to comprimise system security.

POL has a scriptable language, eScript

Sphere does have scripts, however they seem to be more like configuration files than actual mini-programs. My experience with Sphere is only that of a player, so I might be incorrect.

POL has a large developer community

They've taken the Open Source road on everything except the server core, which is closed-source. This allows wider distribution of scripts for admins to customize, improve, and contribute back to the community.

POL has packet manipulation capabilities

Not sure if RunUO sports this feature, but this alone allows a developer to customize how client<->server packet events are handled.

UOX3 is one of the oldest emulators out there (UOX was the original UO emu), it is open source, written in C++, and has some very talented developers who actually listen to feedback. The down side is that it is not very popular, and thus lacks a proper development staff, and is fairly bug-filled.

_________________
Blog: http://www.sydius.org
Web: http://www.sydius.net

And of course there is Wolfpack, with a complete Python scripting, and totaly open source. It is far more up to date the UOX3, with less bugs.


The real choces if you want to modify server behavior, and want to run a shard soon, is (in my opinon of course):

Runuo
Wolfpack
Sphere (however, development of this is tied up in legal battles, not even sure if still actively developed)
Pol

Out of those (not counting sphere), Pol and Wolfpack run on linux (if that is important).

Runuo is by the far the most popular, and feature rich.


For stability with data configurations , there is Lonewolf (but does not have all the features of the others, but does run on linux and is open source).


There is UOX3, but it is far behind, and not really ready for shard running (again, my opinon). It is worked on as time perimits by only one main developer, with support on occassion from another handful.

POL is the only one I've personally worked with, and from my experience I can tell you that you should never push eScript as a plus. It is the worst language I've ever worked with, and I've written in PLM.

What's the difference between wolfpack and lonewolf?

Go to www.uox3.org and see his history section?

Wolfpack was a derivative of UOX (3, I believe), and Lonewolf was derived from Wolfpack. Wolfpack, I believe, has been completely rewritten since, though.

_________________
Blog: http://www.sydius.org
Web: http://www.sydius.net

A long time ago wolfpack was a branch of the UOX .7 release of there abouts.

However, yes, it has been totaly rewritten/designed since that time, so its heritage is only of interst for historical reasons.

Wolfpack has a scripting concept, using python.


Lonewolf was a branch of Wolfpack before it was redesigned. It has "closer" roots to UOX .7, in its structure. But it has undergone significant code modifications , with focus on stability. With that said, it has no "scripting" capability, other then simple triggers that can be used. It is easy for a user to tackle, as no coding is needed. If you want to go beyond that, the code is available.
Both LW and WP work on linux (if that is important).

Again, one has to develop one's own trade criteria, to determine what is a "strength" or not (for instance, if the code is available, I dont find scripting a strength or weakness. But for others that may not be the case. )

I think RunUO has one major advantage over script-based emus. Its "scripts" are written completely in a full programming language. Smaller advantages, I have never had stability problems, and the server takes up only a modest amount of resources.

The downside of RunUO, as I see it, is the binary format of the worldsaves. Sphere (to pick one at random) uses text files for the saves. This makes them significantly larger, and they take longer to save or load, but you can directly edit them without starting the server. Want to remove all daggers? Fine, easily done (although could be time consuming). The binary save format is possible to edit outside the server, but you would have to decode the file byte by byte, very impractical.

I've never worked with POL, and my time with UOX and its derivatives was long ago, so I'm not entirely comfortable commenting directly on them. What I can say is that RunUO works well "out of the box", is now completely open source, has an active dev community, and there's a decent possibility that the time spent learning the scripting language will be useful outside of your UO emu time.

And Hawkens, yes, you can over-ride packet handling in RunUO, you just (like always) need to know what you're doing.

It is true that UOX3 isn't as up to date as Wolfpack or Lonewolf when it comes to packet and/or feature-support, but UOX3's scripting-engine (spidermonkey javascript) allows for far more custom features than Lonewolf's trigger-system, and I think it is easier to understand and learn than Wolfpack's python-scripting. I have for instance scripted a fully functional static-housing script for UOX3, various resource-harvesting scripts, liquid-handling between various containers, and even started on an ingame version of my "WorldBuilder" GM-tool once (have never finished it for reasons not related to UOX3) - and I have very little coding-knowledge/skill.

Oh, and since all three of the above mentioned UO emus are "open source", that particular feature doesn't really become an argument either way, so scripting capability is more important when comparing these three (in my opinion).

Some of the features of UOX3's javascripting engine:

• Scripts can be reloaded on the fly, either all at once or specific ones by scriptID, no need to restart server for every small change you do.
• Magic is fully scriptable and can override some or all of the hardcoded magic spells.
• All available skills are fully scriptable, some have been moved out to Javascript already, more to come later.
• Combat would be scriptable if the implemented but at the moment non-working combat events were...er...working.
• Commands are scriptable - more than 100 commands are scripted and easy to modify by admins already - and new ones can easily be added without hassle (I've added worldbuilding commands myself, like the "repeat"-commands...'radd 0x#### and you get target cursor to add same item over and over and over again without entering a new command).
• You can run events on newly created characters and/or items, as well as on existing characters logging in - making popup menus (race-selection/character-creation, ingame news and other messages) easy.
• You can attach javascripts to objects through DFNs (textfiles listing variable-data for various items and npcs), by hex-ID, by item-type or through ingame-commands.
• You can assign custom tags to any character/item - these are persistant and will be saved along with everything else, and can be read again at a later time.
• (UOX3 Javascripting Documentation)

Other features of UOX3

• All UOX3 scriptfiles (javascript, DFNs, accounts, ini-files, etc) are reloadable on the fly.
• Extensive logging of everything from server errors, packets sent or received, commands used, spells cast, combat messages to actual ingame player chat.
• Most stuff in UOX3 is configurable, either through the ini-file or through various DFN files (for instance loot from corpse-carving, creature-sounds and animations, various settings such as timers, worldfile archiving, some combat/magic-rules, and more).
• Customizable races, allowing for allies, enemies, monsters opposing or assisting eachother, skill-bonuses/penalties, ++
• Regional spawning system where you can spawn a million NPCs (or items) without increasing worldsave times at all - since objects spawned regionally are not saved, but only kept in memory for as long as the server is running. Upon server restart, they're all respawned. Thus, the number of spawned NPCs your server can support is only limited by whatever amount of RAM your server has.
• Region-specific control of weather-effects, lighting, apperance (felucca,trammel, spring,felucca, winter) and ore-resources.
• Custom dictionary system allowing the display of server-and script-messages in multiple languages (We currently only have dictionaries for English, and to some extent - French and German, though any language with a country-code supported in the UO Client is possible to use).

I agree though, with punt, when he says that UOX3 is not really ready for public shard running at the moment, but there's not really that much stopping it from being just that - it's just that with the limited developer resources UOX3 has, taking care of the "show-stoppers" present is a lengthy process.

_________________
-= Ho Eyo He Hum =-

Its scripts ARE the language! How is the different then having the source of the emu on the other projects?
As for modest resources, clearly we come from different enviroments. NET by nature (and Java as well) take signficantly more resources. So it depends on what your expectations are for "server applications".
But no quesiton, Runuo is by far the most complete, and popular.

Have total control to me is vital if you dont have the source to the main engine (POL, and for a while, Runuo). HOwever, if you do, then having scripts to make it so a user doesn't need to be a full programmer is a godsend.

What made Runuo on of the more powerful "scripting", was it relatively well laid out class structue, so overriding was fairly easy. That would be true with say, C++ as well, if such a design was taken.

Anyway, to the original poster, one really has to build their own trade criteria, and their on weights on the criteria to make any type of evaluation. For it will vary widely form person to person.
Such as for me, scripting is very low (assuming I have source), but memory footprint is important (and portability, so I can pick the best deal for my server). But others will value scripting, and not care about those. So it really is up to one, and how much work one wants to invest (versus just running something straight out of the box).

One of the servers (I think it was wolfpack?) recently switched to a SQL backend. If the table layout is sensibly done, you could find all of the daggers with a query, and delete them all by altering the same query - probably a minute or two of work if you are familiar with the table layout and SQL.

Using UOX3, you could do it ingame, while the server is still running, using a small javascript. In fact, one already exists Example:

_________________
-= Ho Eyo He Hum =-

This is very easy to do in RunUO as well, in-game. My point was that it's very difficult to do outside of the game (for instance, if a particular item or creature is crashing the server).

As for my earlier comment on system resources, I've found that a fully spawned world in RunUO uses less resources than a fully spawned Sphere world, using worldfiles as similar as possible. Sphere tends to have a smaller overhead cost, so it would win hands-down in an empty or sparsely populated world, but the load grows much faster with more items and players.

Hey Xuri, how about UOX3 and linux playing nicely though? From what I've read, some people have a really hard time getting UOX3 to compile on linux. Any comment on that?

For some of the more rational (non-windows ) server guys, linux offers a lot more than windows.

It's not like you can build your own distro of windows, completely dedicated to running nothing but your UO shard... but with linux you can do just that. I think linux compatability should be a major player in every emu's development.

Linux typically runs cleaner and more secure (if the admin knows what he's doing), and given the fact that you can run the software in it's own memory space, it makes it harder for others to compromise the entire machine as opposed to just that running service.

I'm a slackware user myself. I've also dabbled in linuxfromscratch, and one of these solutions is what I'm looking to use. I won't consider M$ as an option.

_________________
Better Deader

Having UOX3 and Linux play nicely would be nice, yes. But when the only programmer around is a Windows programmer, what can you expect? It's not like the linux people are standing in a line to help out either, exactly. *shrug*

Btw, Fish compiled UOX3 successfully in Mac OS X 10.4 with GCC 4.0.0 as of the 24th of October (http://www.uox3.org/forum/viewtopic.php?t=642 )

_________________
-= Ho Eyo He Hum =-

Right on.

Well, if you need a linux volounteer I will be more than willing to help. Here's the issue though, I'm not the best C++ programmer.

I'm better at troubleshooting errors and making corrections than anything else. I may be able to port existing code to linux though...

If it's compiling ON Mac OSX with gcc that is a very good sign. Does the dev community make it a point to include configure files with the source? If not, this would be incredibly helpful because it would be able to auto generate a Makefile with the correct paths to required libraries and such.

While I havn't looked at the source for UOX3, I am looking to join one of the different emu server communities, and possibly dedicate a lot of time to them. Hopefully I can learn along the way and contribute my time to make advances for the emu.

At the moment Wolfpack and UOX3 are the two only candidates I'm considering. I was looking at POL, and while it looks good, I'm not sure I like the way it's set up. I also see that both UOX3 and Wolfpack appear to be way ahead of POL.

_________________
Better Deader

I would not trust any of the emulators, insofar as security goes. I imagine it would take a trivial amount of effort to compromise an entire system running any of them, especially the open-source UOX variety. I do have a bit of experience toying with the source of UOX3, and I know that, right now, they are far more concerned with getting things to work than security ? which is understandable. The newer UOX versions are more secure than the older ones, due to the more extensive use of STL (which is fairly secure compared to home-rolled solutions), but there is little (if any) exception-handling, and buffer overflows are still possible. It only takes ONE buffer overflow to take complete control of the system, install any trojans you want, etc. So using Linux purely for the sake of security is folly, in my opinion, even though it would make it more difficult for other programs to interfere ? a trojan could grow from the inside out of UOX in no time. The same likely goes for the rest, though RunUO might have a slight advantage due to the language used.

_________________
Blog: http://www.sydius.org
Web: http://www.sydius.net

I have to disagree with that statement Sydius.

I don't have any trust for .NET what-so-ever... if it was developed by M$, odds are it's got exploitable holes in it so large... well, take IE and IIS for example. There are probably very few windows servers that are set up in a way that you can't google a former exploit and own them... of course this largely depends on the server admin, and how the machine is set up.

It's the same for linux really, but the key with linux is I can run any of these servers from a seperate user, in their own memory space, and yeah they may be able to get access to the machine as that user, but unless they're able to somehow run arbitrary commands as that user (which I wouldn't allow on any of my machines) or they're able to do something insane like cat /etc/shadow (if I set up the machine this will never happen) there's not much they're gonna do in the way of busting into my box.

I'm a paranoid individual when it comes to putting a machine on the net. To the point I would say that I probably go far above and beyond what I should have to... but then again I learned from a paranoid SOB...

_________________
Better Deader

I was assuming you were concerned over the integrity of the server data (as in the emulation data ? accounts, passwords, items and such), not over general computer security.

I suppose I would have to agree with the M$ statement, as well, even though I favor the MSVC++ tools over any of the free variety.

_________________
Blog: http://www.sydius.org
Web: http://www.sydius.net