NOTE: I refer to 55r* versions of sphere unless stated otherwise, those are the "revisions".
1) Sphere uses a text based saved world which is both slow to process and save, as well as large.
Runuo uses a binary based world, which is approximately 6x smaller, and about 12x faster to load.
Sphere's worldfile is easily understandable, readable, and editable as well. The average worldfile for the average shard probably takes a whopping 5 seconds to save. You can have it save in the background where it's completely unnoticable by the players.
2) Sphere uses a propietary scripting language, which is interlocked into its hardcore which is
C++, causing problems. RunUO is coded in C#, both core and source scripts.
Spherescript is quick and easy to learn and use, even for non-programmers. What problems does it cause? Poor scriptors cause problems, I suspect poor programmers would in C# as well. Surely you don't think the server itself being coded in C++ is a problem?
3) Sphere must convert its scripts into usable code in memory, causing excessive CPU cyles.
RunUO compiles it's source scripts into a DLL, which is then loaded to become part of the emulator.
There is no conversion, nor a real-time script updater to cause extra CPU cycles.
This also allows Sphere to edit and resync scripts on the fly, no compiling needed. I don't have to kick my players off so I can restart the shard in order to add or change scripts. I can test something i'm making while logged on, instantly. I know it uses more cpu to read them that way, but sphere is by no means unreasonable on resources.
4) Sphere allows for dynamic script updates using Resyncs. RunUO must be restarted, which is the same
as freezing the world, except the client is disconnected and must reconnect. Support for dynamic updates
could be coded, although is not neccessary.
Read above ^^
5) Sphere scripting is limited to what is coded to be accepted by the core. RunUO is limited to the
power of the language of C# (which is very little).
There's nothing I could think of impossible with it, honestly.
6) Sphere is approximately 85-90% hardcoded in C++. RunUO is approximately 12% C# core, with 5%
of the core being overridable or modifiable.
Hardcoded stuff is overwritable in sphere :p
7) Sphere has approximately 15-35 second world saves with high amounts of players and items.
Runuo barely hits 8 seconds. While system dependant, they are still significantly higher
15-35 seconds for a huge huge number of items and/or a really slow machine.
8 )* Sphere is approximately 23% completed with AOS. RunUO is 99% completed. (preference)
I dun want AOS so can't argue that one :p
9) Sphere requires approximately 4x more memory than RunUO for 1/2 the amount of items, decorations, players
and NPCs.
Are you sure? Someone on this forum said his RunUO was using 600mb ram for not very many players. Sphere isn't that bad on resources.
10) Sphere has hardcore bugs which are not fixable. RunUO may have one, although it is unlikely.
It's all fixable via script.
11) Sphere's IP firewall is bugged. RunUO's works perfectly.
Eh?
12) Sphere requires heavy remodeling of a system when changed from hardcode to script. RunUO
does not. Since the languages are the same, they can just exclude the file and put it into the
Scripts directory.
Yeah, if the system is hardcoded it'd require complete remodeling because you'd have to script it all.
13) Sphere has tags for all items mobiles and players, as well as accounts. RunUO can be coded to
have these if the shard administrator wants them.
14) Sphere barely has item detection support (to find an item within x tiles). RunUO has full support
for this.
Full support in sphere too
15) Sphere has no scope for variables. RunUO uses C++ Style OOP scopes for its variables.
Dunno what a scope is. Sphere has global and local variables if that's what ya mean.
16) Fixed
17) RunUO can be coded to interact with AIM, IRC, ICQ, or any other communication software. Sphere cannot.
It's an emulator for UO! Who cares! My mirc script connects to my sphere btw, for remote admin purposes via irc.
18 ) RunUO has a built in search engine for items in-game. Sphere does not.
I don't understand this, define what it does please.
19) RunUO has full batch command support. Sphere only has the nuke command, which does not work as well as
it should.
Sphere has a lot of commands other than nuke, nuke works just fine. Commands can be added via script as well. They're called functions.
20) Sphere uses Types, where it is impossible to combine types, or modify a hardcoded type. RunUO has
no such problem. An item can be comprised of many interfaces or parent items, and is not hardcoded.
Possible to edit hardcoded types in Sphere too. Possible to add multiple events/types on items as well.
21) Sphere's magery system is hardcoded, and cryptic when it comes to customization. RunUO's is 0% hardcoded
and fully customizable. This includes necromancy, and chivalry (if you want to use those)
Nope, wrong again. It's fully scriptable via the @triggers (there are a lot of them now) and/or do-it-all-yourself as my shard has done.
22) Sphere has no goal when it comes to a default type of gamestyle. RunUO has chosen an OSI clone although
reserves the power to the admin of the shard to change anything they want virtually.
The devs original goal is completely unknown to me, the goal I was told when I asked 'em was a basic functioning server that was easily customizable for the new admins and powerful enough for the old admins.
23) Sphere's gumps run at appromixately 1.75x slower than RunUO, and does not contain the same power
and dynamic functionality.
Gumps are 100% dynamic in sphere and i've never seen one lag lol... gumps actually can lag? :/
24) Sphere's syntax is bugged, preventing the ability to test many features. RunUO has no syntax bugs
considering it uses an actual coding language. Sphere's syntax and features being interlocked will
always cause problems because new features are always added to progress.
Yeah, everything has bugs. Have you seen what's fixed lately?
25) RunUO supports hashs as part of C#, Sphere does not have any such system.
Hashes? *is not a programmer*
26) RunUO can be programmmed to automatically restart when a script is updated on a schedule. Sphere
cannot be programmed to do such a thing.
AHHHHHHHHHHH something sphere can't do
Oh well, I'd never need such a feature anyways *wink*
27) RunUO has full binary, xml, and text (with unicode) file read/write support. Sphere has no support.
Yesh
28 ) RunUO has full support of the house customization system. Sphere has no support, nor will it ever.
Apparently 1.0 does, or will, or something... I dunno, I wouldn't touch 1.0 or the house stuff with a 10 foot pole to be honest. My shard is pretty, players would make it ugly if we let them build :p
29) RunUO has full support of custom maps. Sphere has trouble with certain map dimensions.
No, the *client* has trouble with certain map dimensions, I have no problems with my custom map.
30) RunUO supports up to theoretically, thousands of facets. Sphere has trouble with just trammel.
Sphere was made *BEFORE* facets, keep this in mind. RunUO was not. Sphere has support for 255 planes, ie - the same exactly map/statics but differen't dynamic objects. You can have each one with a different "season" (like giving one that dead effect) but it does not support Haven/diff files.
31) Sphere has a spawning system with no interface. RunUO has a spawning system where you could make
a dynamic quest in-game. Or you can use a system with just a regular spawner that supports up to 10
objects.
Very easy to script anything like that in sphere i'm sure.
32) Sphere uses cryptic TDATA and MORE attributes which you have to memorize for every item type. RunUO
uses descriptive variable properties which can be referred to easily since they are created and used in
script (not hardcode).
Yeah, there are plenty of reference sites that explain these properties though
33) RunUO supports arrays of any datatype. Or an arraylist of multiple datatypes. Sphere has no support
for any type of array or structured datatype.
1.0 does, but again I don't touch that
34) There is no stable version of sphere meant to be used on a live shard. Almost all versions of RunUO
up to the newest, are meant to be used on a live shard and have only extremly rarly crashed using a fresh install during the first 10 beta's at most.
The revisions are fine to use.
35) RunUO has packet throttle regulation for movement of players (and/or staff). Sphere claims to have this
although tests show that gear still works.
Tried gear on the revisions? I'm sure 1.0's is broken if you say it is. I've never had a problem with speedhackers so I don't really know if it's stopped or not, support is added though.
36) RunUO can be coded to have support for custom clients, or other protocols connecting to it. Sphere
will never have this support. It is said to have some iris specials, although they are hardcoded and
consequently not modifyable.
37) Sphere is submissive to certain requests by the client (fixed in general), causing exploits like injection
and its variants to seep through. RunUO has no such problem.
No problems with injection on the revisions :p
38 ) RunUO can be coded to have a full web server integrated into it with ASP.NET and ADO.NET support. Also with
a feature similar to MyUO. Sphere will never have this support.
Yeah, that's why I have a real webhost that'll be away from my shard host. I wouldn't want the extra lag on the server anyways. For the new guy reading this though, Sphere DOES have a webserver for doing things like status pages and such.
39) Sphere has ODBC or some type of database support, although it is said to not be working. RunUO works
with databases via its MyUO clone called MyRunUO. And can be coded to use databases in any way needed.
Revisions have no database support.
40) Sphere changes its syntax to support more complex or "stable/effecient" coding. RunUO's language (C#)
will never change. In the event that it does, it will ALWAYS be backwards compatible. And the language
changing is up to microsoft.
Very very little syntax changes happened in the revisions, tons and tons and TONS of more complex and effecient coding was added. Everything changed is able to be turned off in the ini file, the map script changes (which were extensive) are easily converted automatically by the server for you with a simple command, so people with custom maps don't get screwed.
41) Sphere has linux support which is fairly buggy, and quite possibly discontinued. RunUO will have support
for other operating systems as clones for the .net framework are released.
Revisions have current linux support I believe, I wouldn't swear to that though... it'd be precompiled either way, so not necessarily gonna work on any linux distro.
42) Fixed -
43) Sphere only supports timers with items that have them. Timers do not work in backpacks or bank boxes (on purpose?)
and do not pass arguements, making them very limited. RunUO has full timer support which can be linked to type actions
and arguement passing, allowing a coder to do anything.
They work on the ground though, and equipped on players... so easy to work around the backpack thing. Universal timers are easy too, with an item somewhere to run the timer.
44) Sphere loop and recurse support is not completed, nor does it work for the current support. RunUO has various
loop and recurse support including while, for, foreach, etc.
For and While loops working perfectly
45) Sphere has limited trigger support using the @Trigger system. Theoretically you can make new triggers although
it gives console warnings because its not built in. RunUO uses methods for triggering, and has full support due
to using a real language, for more triggers, and methods.
We had uh *cough* removed that warning to shut the console up. It only does the warning on startup though, not a huge deal. They do work perfectly despite it.
46) Sphere has limited support for new skills becuase they are mostly hardcoded. While RunUO has full support for
new skills. And with edited skill mul files, will be fully displayable by the client.
I have completely new skills in Sphere.
BBL, must get my late butt to work ;P
Login
Register
FAQ
Search
)