RunUO vs Other EMUs

[Static Loader]

What do you guys rank for stability the best emu?
custimizable, speed, etc..

UOXC, UOX, UOX3, POL, SPHERE, NOX, RunUO, anything else...?

Basically, if there had to be a runner up to RunUO, what emu would it be?

[Ace]

runUO is the better EMU ever created. So customisable ! We can do what we want, no restrictions !

[One Sick Puppy]

I tried Sphere and got frustrated with all the boring work that needs to be done. I tried some others but couldn't get them working.

RunUO was a cinch to instal and get running, and it's turning out to be exactly what I want: a way to play UO from home (I emphasize "play" because most emus require 100's of hours of scripting and configuration before you can even start playing and I found myself getting sick of the game after only a couple hours of that).

[Zippy]

RunUO has the advantage of being a GC memory managed language like Java, which makes it much easier to achive superior stability (with less overhead)....

But I don't think you'll get an objective answer to your question here... thats kind of like going up to Stalin and asking him if he likes capitalism better than socialism....

[Static Loader]

Another question could be then.. if you left another EMU, what EMU did you leave and switch to RunUO for?

[Kiwi]

It beats all others in speed, customizing, ease of use, scripting, and all else

Anyone who thinks otherwise is just in that stage of denial...

[NeG@TiVe]

I'm still in love with POL even though its a complete system hog, but RunUO is climbing the ladder and might one day overtake it.

[Kiwi]

It already has overtaken it :P

Before this, all I used/played on was POL
It still has that "old" look and feel to it, no matter how much you change it, and there are still a crapload of core limitations, even if you hook everything through scripts, those tend to get laggy fast

Well, I come from UOX3, was a developer for a while even, and in terms of "stability/uptime/crash bugs" RunUO is unmatched. POL is closest behind in stability in my opinion.

Next Id say speed - RunUO is the fastest emulator Ive used, and the easiest to understand on setting up.

Next would be customization/packaged. The packaged distrib is as close to OSI as you can get...I know this because I am like the OSI-guru of the UOX3 scene...I have religiously played OSI UO and I still do, so Im up and up on the game itself. As for customization, I think thats a given, seeing all the new AI and stuff that is coming into play.

As for ease of use - it doesnt get much easier than this actually, you download, install, start it. Simple. The only ONLY thorn in the side in the aspect of ease of use is having to install the .NET framework...but thats a small negative factor with all things considered.

[Static Loader]

Im still with UOXC just because it seems to be almost exactly what I want in a emu no more no less.

Its almost right a at a stage where the only things I would want is faster loading and thats about it with less CPU usage.

Have you guys ever had problems with UOXC?

[Spooky]

I often wish that the UO EMU devs from all the projects would get together and create THE UO EMU.

Imagine all those programers with all that UO knowledge put into the same EMU

Back on topic thou other EMU's were designed with earlier versions of UO in mind, hence they got there core right for an older version and now when something new comes out its a major operation for them to put it in.

RunUO is designed now on the latest version of UO, hence it will cope with the current UO features much better.

As for what emu people like its all personnel preference really and the only way to decide properly is to give them a try and pick the one you like. (remembering that non Runuo EMU's will give the feel of earlier versions of UO cause that was what they were designed to run)

----------------------------------------------------------------------------------
I like this answer better than a big what i think of other EMU's

[Aenima]

Different UO emulator developers think different ways, and all want the emulator to be the way they want it to be.

Therefore, this wouldn't work, and would only cause many many arguements.

[Spooky]

LOL I know thats why its only a wish

[robane_altos]

RunUO
POL
UOXC
UOX3
UOX
Sphere
i havent tried NOX and there are a few you left out like wolfpack
and such

My opinions:

1. RunUO's customizability is nothing compared to sphere's and POL's

2. UOX uses much more flexible language than RunUo

3. UOX has better performance since it's being used as an executable

4. RunUO has worse performance than UOX, about the same performance as POL and sphere ( since they all use an interpreter)

5. RunUO's easiness of instalation and customization doesn't match the hardness of the language (C#)

6. RunUO's language (C#) is much more flexible than sphere's and POL's

7. RunUO uses .NET technology which is new, and has never been proven to be stable, and websites that use it normaly can't hold over 1000 connections at a time, thus they crash.

8. Unlike sphere's and POL's developers, RunUO's developers are much more experienced, which let them to avoid critical mistakes that sphere and POL didn't.

9. RunUO has been developing extremely rapidly since it's first appearance.

10. Most of RunUO has been (and will be) scripted, which allows greater, but harder customization, unlike sphere.


... So you see we can't say which emu is the best - every one has it's own pros and cons...

[krrios]

1. True, there are things which the core doesn't provide easy customizability access to (yet), but you also must factor in the "scripting". Scripts have full access to the .NET framework. Can you write a core and script document generator, or web status uploader in Sphere? POL?

2. Old UOX's used triggers, new use Javascript. I couldn't say either of those are more flexible than C#.

3. Does it? Off the top of my mind, UOX uses uncached packets, a horribly inefficient network compression algorithm, and is heavily reliant on serials.

4. This is simply wrong. RunUO's scripts are compiled and optimized by .NET into native machine code.

5. I'm sure I would have a very hard time trying to script in something less structured, such as Sphere scripts.

6. Yes. :shock:

7. Not really sure what to say here.

8. 8)

9. 8)

10. I don't know much of Sphere, so hard to respond, but one great thing about RunUO is the scripting power--some customizations could be scripted, say, to use a config file.

[Ryan]

Originally Posted by Richard

My opinions:

1. RunUO's customizability is nothing compared to sphere's and POL's

2. UOX uses much more flexible language than RunUo

3. UOX has better performance since it's being used as an executable

4. RunUO has worse performance than UOX, about the same performance as POL and sphere ( since they all use an interpreter)

5. RunUO's easiness of instalation and customization doesn't match the hardness of the language (C#)

6. RunUO's language (C#) is much more flexible than sphere's and POL's

7. RunUO uses .NET technology which is new, and has never been proven to be stable, and websites that use it normaly can't hold over 1000 connections at a time, thus they crash.

8. Unlike sphere's and POL's developers, RunUO's developers are much more experienced, which let them to avoid critical mistakes that sphere and POL didn't.

9. RunUO has been developing extremely rapidly since it's first appearance.

10. Most of RunUO has been (and will be) scripted, which allows greater, but harder customization, unlike sphere.


... So you see we can't say which emu is the best - every one has it's own pros and cons...

The key word for this, is OPINION, the majority of this is in fact false.

1. RunUO is by far more customizeable than anything out there.
2. UOX doesnt use a language, UOX uses a language interpreter, we actually use a language.
3. This is a flat out falsehood.
4. I have been a UOX developer and contributor for over 5 years, and there is no way in hell you will ever convince me that UOX's performance can surpass any current emulator out there, I know how bad that code base is, and its the #1 reason why I left. Bad architecture and foundation lead to bad performance.
5. C# is no harder than any other language out there, if you can understand the concepts of JavaScript you can easily understand C#.
6. Wow, correct
7. Sounds like an administration issue. I know of multiple .NET powered web servers that handle 50 to 60 times that load
8. No comment.
9. No comment.
10. If you think learning some proprietary bs is easier than using a standardized scripting platform, that is a user issue.

[Allmight]

Originally Posted by Richard

My opinions:

1. RunUO's customizability is nothing compared to sphere's and POL's

2. UOX uses much more flexible language than RunUo

3. UOX has better performance since it's being used as an executable

4. RunUO has worse performance than UOX, about the same performance as POL and sphere ( since they all use an interpreter)

5. RunUO's easiness of instalation and customization doesn't match the hardness of the language (C#)

6. RunUO's language (C#) is much more flexible than sphere's and POL's

7. RunUO uses .NET technology which is new, and has never been proven to be stable, and websites that use it normaly can't hold over 1000 connections at a time, thus they crash.

8. Unlike sphere's and POL's developers, RunUO's developers are much more experienced, which let them to avoid critical mistakes that sphere and POL didn't.

9. RunUO has been developing extremely rapidly since it's first appearance.

10. Most of RunUO has been (and will be) scripted, which allows greater, but harder customization, unlike sphere.


... So you see we can't say which emu is the best - every one has it's own pros and cons...

1. There you are definitly wrong. I have Used UOX, Sphere and POL, and out of them POL is the most customizable. But it is nothing compared to RunUO.

2. Err, what language. If you refer to the J-Script one, it's nothing compared to C# which is a full fledged programming language.

3. LOL, makes no difference since RunUO compiles the scripts to machine language at startup, hence becomes justa as efficient as an exe.

4. Just shows how little you really know. UOX is one worst emu's out there. The source is so unoptimized you could cry, hence a shitty performance. And you call yourself a good programmer.

5. Now you even prove yourself wrong. Remeber this post?

Originally Posted by Richard

Hmm how interesting. I am also a C++ programmer, with 0 commercial experience, but I've been playing with it for about half a year.

And surprisingly, I understand 99% of RunUO as C#, and have no problem making scripts... No offense but there are 2 things I can think of you :

- LIAR
or
- Shitty programmer

Wonder who qualifies as the LIAR or Shitty programmer.

6. Totally agree with you.

7. Sigh, maybe you should check your source of information. Could'nt disagree with you more. And what does websites have to do with RunUO???

8. Correct.

9. Correct again, and that's partially has to do with the wise choise of using C#. The other factor is that the devs are so experienced and devoted.

10. WRONG!!! I have scripted for Sphere, and their scripting language is terrible. Even Menace admits that openly. C# on the other hand is well structured and easy to use. Sure, you need to learn it first, but that goes for all scripting languages.

So to sum it up. If you are about to post a critic post, make sure your info is correct and not just a bunch of bullshit that you made up based on your own opinion.

lol...

1) RunUO is not customizable and powerful??

Where else can you set different caps for each player AND each skill AND each stat? Where can you restart your server and receive a mail message when it crashes? Where can you set resources by tile ID?

I've shown my shard's project to some Brazilian shard admins and they where like w00t how u gonna do that and stuff

3 days later many of them stated in their forums that RunUO SUCK.
Perhaps they can't write C# scripts and are afraid of RunUO and its
power.

2) RunUO's slow?
Ok, go to sphere and tile 200 objects then cast chain lightning, come back
to the forums and say what has happened.

3) Hard to script in?
I think C# is so easier to script than sphere crap or escript.
Try to write 100 items doing almost the same on sphere. prolly
u'd have to write 100 DIFFERENT items. But on RunUO
you write a base class and then just change it using derived clsases
and ctor. rlz.

I'll present the pro-sphere case here, responding to both Richard and Ryan.

Originally Posted by Richard

My opinions:

1. RunUO's customizability is nothing compared to sphere's and POL's

False. You can almost certainly do in RunUO what you do in Sphere to customize something that's hard-coded - script over it. Of course, since most things in RunUO are in scripts (like POL), that isn't as much of an issue.

2. UOX uses much more flexible language than RunUo

Being an actual programming language, C# is just about a flexible as you can get.

3. UOX has better performance since it's being used as an executable

Absurd, as Ryan said, you have your facts wrong.

4. RunUO has worse performance than UOX, about the same performance as POL and sphere ( since they all use an interpreter)

Again, you have your facts wrong. RunUO doesn't use an interpreter. The scripts are compiled to a DLL.

5. RunUO's easiness of instalation and customization doesn't match the hardness of the language (C#)

I'd say that it's easy to install RunUO, and possible to customize just about anything, but in my experience, it takes longer to customize SOME THINGS with RunUO than with Sphere - For instance, it takes less time to make a script for an item which sits on the ground and changes its color every 3 seconds in Sphere than in RunUO.

This is because Sphere's scripting language makes it very very easy to do things like that, mainly because it ISN'T a real programming language.

However, for the same reason, it takes longer to code some things in Sphere than it does in RunUO. Note: In the latest versions of Sphere (.99t, .99t2, .99u), the Sphere scripting language has gained constructs and abilities which remove most of the limitations which complicate and slow coding on Sphere. It now has while loops, arrays, multiple parameter passing to functions, and returning values from functions (All things that RunUO already has since they're all integral components of any decent programming language).

For some of those things, in .99u, it no longer takes longer to code them in Sphere than RunUO. It doesn't take less time, either. It takes about the same amount of time, because you really have to do the same things, when the scripting language doesn't simplify it for you (as it does with colors and adding variables to things (tags)).

For instance, if you wanted to rescript guilds from scratch in scripts in Sphere 55i, it would take a very long time. (I've actually coded nations from scratch in sphere 55i, and it took several months to do, since I had to use recursion to emulate loops, evaluating variables inside other variable names to emulate arrays, region tags on a house multiregion that the nationstone was forced to be in because I couldn't put tags on the stone itself (for a complicated reason. I could have if I'd changed its type, but I needed it to be something else due to a bug in 55i.), and a number of workarounds for having nation ownership of towns since region tags on non-multiregions don't save and region UIDs for non-multiregions change on server reboot.)

If you did it in RunUO, it would take less time. It would still take a long time, but nowhere near as long as it takes in Sphere 55i.

If you did it in Sphere 99u, it would take about as much time as it takes in RunUO. For some things, you'd have to use SENDPACKET, such as the ally/foe color highlighting (Which you cannot do at all in 55i). That's definitely easier in RunUO.

6. RunUO's language (C#) is much more flexible than sphere's and POL's

I'd agree, except that there are a couple of extremely limited things that Sphere's language can do which C# cannot (easily), as a consequence of those funky <>s, and also the way tags work in Sphere.

For instance, in Sphere you can build something resembling a hashtable with very little effort:

[code:1]
Imagine this code is called when SRC sees ACT.
if 0<src.tag.my_hashtable_<act.name>>==1
src.say I remember you, <act.name>!
else
src.tag.my_hashtable_<act.name>=1
endif
[/code:1]

That makes the person say they remember someone if they've seen them before, and if not, they remember them for the next time.

For obvious reasons, this isn't anywhere near as easy to code in C#. You can do it, though, by using the hashtable classes that come with C#.

7. RunUO uses .NET technology which is new, and has never been proven to be stable, and websites that use it normaly can't hold over 1000 connections at a time, thus they crash.

Ryan answered this well.

8. Unlike sphere's and POL's developers, RunUO's developers are much more experienced, which let them to avoid critical mistakes that sphere and POL didn't.

Sphere's developers have been doing this for almost as long as RunUO's developers. I don't know anything about POL's developers.

9. RunUO has been developing extremely rapidly since it's first appearance.

True. Most of the other major emulators (UOX, Sphere, POL) have developed far slower in the past, but RunUO is brand new as well. People get burned out.

10. Most of RunUO has been (and will be) scripted, which allows greater, but harder customization, unlike sphere.

Yes, so is POL. But for Sphere's part, it is still possible to script replacements for most hard-coded things. On my sphere 55i shard, we replaced lockpicking, taming, trap removal, a number of magery spells (mana vampire, magic trap, untrap), added traps that tinkers could craft, etc. It can be done. In some cases, it's not too hard. In others, you are right (Stealth, for instance, is not something I'd want to try to rescript from scratch because it checks movement - Calling an interpreted script every time a PC moves seems like a good way to increase lag to me)

Originally Posted by Ryan

1. RunUO is by far more customizeable than anything out there.

True.

2. UOX doesnt use a language, UOX uses a language interpreter, we actually use a language.

I'd still call it a language. It's a scripting language, not a programming language, however. There is a difference.

5. C# is no harder than any other language out there, if you can understand the concepts of JavaScript you can easily understand C#.

True, although simple things in Sphere only require copying and pasting and changing numbers in statements like this 'color=05ea' 'name=An orc'. It's a *little* more complicated with RunUO.

6. Wow, correct

7. Sounds like an administration issue. I know of multiple .NET powered web servers that handle 50 to 60 times that load

In all likelihood.

8. No comment.
9. No comment.

10. If you think learning some proprietary bs is easier than using a standardized scripting platform, that is a user issue.

One issue is that people are resistant to learning what they consider real programming language. Nobody comes on the sphere forums complaining because they have to go find some spherescript tutorial to learn to use the language... It's a given. Here, people come and complain because they're told to follow C# tutorials. But like you said, that really is a user issue.

The main reason sphere scripting is thought of as easier is because Sphere's script-interpreter simplifies scripting new items and chars which don't do much of anything special (Just a stronger orc, etc) by requiring only a change of a few variables in the script.
Doing that is more like editing an INI file than coding something. A similar concept is editing the regions.xml for RunUO. If it was a part of Sphere, it would be considered a 'script'. Here, it's a datafile.

Note: The following paragraph contains conjecture about sphere's development before it was called Sphere. I wasn't there. I don't know if my statements about the way sphere 'evolved' are correct or not, this is conjecture based on how I've seen sphere scripting move from 51a to 53-54-55-early 99s, to 99u.

Over the years from 51a to 53-54-55, and then to today with 99t2, 99u, etc, sphere has moved from having files with definitions with a few minor scripting abilities, like changing an item's name on dclick, up to having what amounts to a real scripting language in 99u, while maintaining the simplicity for the specific tasks the language was originally capable of in 51a ('Scripting' an orc with higher str, for instance).

Originally Posted by Kiff

Try to write 100 items doing almost the same on sphere. prolly
u'd have to write 100 DIFFERENT items. But on RunUO
you write a base class and then just change it using derived clsases
and ctor. rlz.

Give an example of what kind of items, please? For something like armor, you're entirely right about Sphere, unless someone uses a script generator (There are some for armor, and they're really really easy to write in any event).

[Ryan]

I'd still call it a language. It's a scripting language, not a programming language, however. There is a difference.

Its still not USING the language, its simply using its syntax and interpreting that syntax. We actually USE the language unlike anyone else out there.

True, although simple things in Sphere only require copying and pasting and changing numbers in statements like this 'color=05ea' 'name=An orc'. It's a *little* more complicated with RunUO.

How is that any different than adding hue=0x489; name="an Orc"; in the constructable.

One issue is that people are resistant to learning what they consider real programming language. Nobody comes on the sphere forums complaining because they have to go find some spherescript tutorial to learn to use the language... It's a given. Here, people come and complain because they're told to follow C# tutorials. But like you said, that really is a user issue.

The main reason sphere scripting is thought of as easier is because Sphere's script-interpreter simplifies scripting new items and chars which don't do much of anything special (Just a stronger orc, etc) by requiring only a change of a few variables in the script.
Doing that is more like editing an INI file than coding something. A similar concept is editing the regions.xml for RunUO. If it was a part of Sphere, it would be considered a 'script'. Here, it's a datafile.

Note: The following paragraph contains conjecture about sphere's development before it was called Sphere. I wasn't there. I don't know if my statements about the way sphere 'evolved' are correct or not, this is conjecture based on how I've seen sphere scripting move from 51a to 53-54-55-early 99s, to 99u.

Over the years from 51a to 53-54-55, and then to today with 99t2, 99u, etc, sphere has moved from having files with definitions with a few minor scripting abilities, like changing an item's name on dclick, up to having what amounts to a real scripting language in 99u, while maintaining the simplicity for the specific tasks the language was originally capable of in 51a ('Scripting' an orc with higher str, for instance).

The fact is, once you become as intimate with the RunUO platform as you are with sphere's you will recognize that its much easier to do things here.

The real problem here, is that there is no way to compare the UO Emulators to us... we are not compatible with them and work on a 10000% different architecture/game plan.

[Static Loader]

I think it would be cool if RunUO did some comparisons with other EMUS based on the same world (possible blank or add like 100000 tiles in one spot adn try to load)

That way you guys could prove your claims (im not saying anything is not true)

I think its just good to prove it in factual records.

Like, with RunUO it can load a average world of 100000 items 2.1 seconds faster using its current code... etc...

[Ryan]

We have already posted benchmarks about what we can do, but no, we will not waste our time downloading 15 UO EMULATORS to compare to our software, that is totally different in design/concept... its like comparing apples to oranges.

If you want to do this feel free to, but I am not going to waste my time doing it Like I said, I have worked on UOX (which you are obviously concerned about since its what you use) for 5 years previous to this project and I know for a fact that it was unable to handle anything near what we do. I cannot speak that claim to POL/Sphere because I only used them a few times