UOX3.org

Users normally are atrracted to a server based on stability, features, and how the user interacts with it.

I can't believe in the first two categories, UOX3 rates in anyones rating. The most defining item about UOX3 is the fact the scripting is in JS.

Now couple that with one of the advantages of learning/sharing, is how to use time to get the biggest bang for the buck.

Would it not be more effecient, and provide the user a more feature riched environment, by adding JS to wolfpack? One gets the benifits of an effectively larger developement base (bugs are being worked by that team), with a more "modern" base. Clearly UOX could adapt the base to be whatever they want (not suggesting UOX always stay as a "patch" to WP)).

But does the internal coding really matter? The current base, even it continues, as a long ways to claim stability (doesn't have enough time on it as a stable enviroment), and then the core has to be opened up again to get its feature set up to date (like difs, AOS, etc).

It would seem that one could expose the current features of Wolfpack in JS (first as they expose). One could then get database support, and cross tool support, etc.

Even from a political position, as they both share the same "parent", the old UOX classic (if that matters anymore), one leveraging off another's base shouldn't matter.

Just a thought, given the state, and resources available, and what seems to be the only technical item that makes UOX unique to the user (other then pride, not invented here, ones own design, etc. But that goes at what the objetive is, and how long of commitement are they planning on making? If not an extensive long term commitement, getting a clean base would seem to give the emu a greater chance of survival, in terms of users and new developers).


Just idle thoughts. I know I wouldn't rewrite a rendering engine as I am working on this client, even though I have one in WF. Makes more sense, to spend the time on the other aspects, since others have signed up to that job.

That would be great. Currently I am guessing anyone who uses UOX3 does so for one of these reasons:

1. They only know how to script in JS.
2. They have friends here or they can't abandon their old emulator.

UOX3 needs stability and support for BASIC game mechanics (*coughboatscough*).

Well, I am not saying this would be easy. Wolfpack has tightly coupled python to its core, to gain speed and ease. So it may not be that simple,or if it takes too much, then not clear you gained enough (although one would have to assess that carefully, to ensure one is evaluating the amount of effort for either approach, fix or convert, accurately enough for comparasion).

Just a note that effort on UOX is not consistent, so the longer term commitement (more then a year) to get stable, get updated, and then get enough road time on it to ensure it is workable could easily consume more then that. So the legacy it leaves for others to continue should be a factor as well, not just one's own personal attachment to ones own handiwork (which of course, is not unique to anyone, we all share that).

The main problem UOX has is devoted workers.

There are plenty of people out there itching to use it, and UOX is a very good emulator in theory, however due to a severe lack of people to spend time getting UOX to the point it should be at, every step is a small one, and every length of time is a long one.

This, largely, is why I am working at making the UOX core as easy to maintain as possible. Ironically enough, the enormity of the aforementioned task makes doing so a long process in itself. However, eventually, with enough hard work, it will one day reach that goal, at which point the oness will be on the users and script-guys to add new features and modify things as they desire, rather than on us to try to keep up with OSI.

As for Wolfpack, while it was derived from UOX, as was UOXC, its relation ends there, by and large. Between the changes made from the 70.x series to the 90.x series on UOX3, and the changes the Wolfpack team has done to WP since its original branch from UOX (69.03 was it?) they are two almost entirely different emulators, with very little in common.

UOXC, on the other hand, is just v.70.x with a few extra additions tossed on (badly, might I add). Sure it has stability, but only because it doesn't die at problems, it allows them to accumulate (the original reasoning behind a complete rewrite).

However to each their own, I, personally, have no interest in really any UO emulator. My days of the free time to actually play any of them have long-since ceased. However I still desire self-education, and UOX presents a very nice facet in which to do so. Thus I will continue to hum away at UOX just as it is, worrying little about Wolfpack, UOXC, RunUO, or any other emulator out there, as none of them really offer what I seek.

Toodles

giwo wrote:The main problem UOX has is devoted workers.

There are plenty of people out there itching to use it, and UOX is a very good emulator in theory, however due to a severe lack of people to spend time getting UOX to the point it should be at, every step is a small one, and every length of time is a long one.

That was exactly the point. There is a limited amount of people, so what is the best way to get the most of those that work on it? Is there a way to capitalize on others work (just as it did with the JS engine,it didn't write its own. And every emu is a very good emu in theory. The key is getting the resources and time to get beyond theory.

This, largely, is why I am working at making the UOX core as easy to maintain as possible. Ironically enough, the enormity of the aforementioned task makes doing so a long process in itself. However, eventually, with enough hard work, it will one day reach that goal, at which point the oness will be on the users and script-guys to add new features and modify things as they desire, rather than on us to try to keep up with OSI.

Again, that is the point. It by itself will be a large resource investment.

As for Wolfpack, while it was derived from UOX, as was UOXC, its relation ends there, by and large. Between the changes made from the 70.x series to the 90.x series on UOX3, and the changes the Wolfpack team has done to WP since its original branch from UOX (69.03 was it?) they are two almost entirely different emulators, with very little in common.

Of course, as I said, it was only a political connection. Never meant to imply the code bases shared anything at this point.

However to each their own, I, personally, have no interest in really any UO emulator. My days of the free time to actually play any of them have long-since ceased. However I still desire self-education, and UOX presents a very nice facet in which to do so. Thus I will continue to hum away at UOX just as it is, worrying little about Wolfpack, UOXC, RunUO, or any other emulator out there, as none of them really offer what I seek.

I am curious why taking another emu doesn't meet your stated desire, self-education. One can not learn from that base, as it gets adapted and deviated? One didn't take a clean slate this time, it used a base that was done by others. So clearly a starting base on some others work met your interest at one point. What about UOX makes it able to meet the need versus an other? And does exposure to more peoples way of doing things not promote self education, as you have a wider audience to get exposed. The project would still be UOX. It would start with a different base (no different then using the .9 seriese over the .7 series).



At any rate, I was only looking at it based on the following considerations:

1. Limited resources
2. JS engine primary feature
3. Stability in the current base lacking
4. JS engine still evolving

If for a minute we add in the other "restriction", that no other source code base is to be conisidered (unclear how far that extends. For libraries as well?), then I have to ask the second question:

Why isn't the focus on "removing" code, and getting a functional core base working? What I mean by that, is if UOX is really going to be advertised as a "scripted" server, then to really test/flush out the JS engine (are things exposed that need to be exposed, etc), Most of the C++ code could be removed. That would give one a cleaner base of C++ to make modifications to , restructure, etc. It would also provide the following features:

1. More examples of the JS coding (since without JS now, the emu wouldn't do much if anything).
2. Validate that the design of the exposure of the JS is really adequate to extend it in the future
3. Thoroughly test the JS engine implementation, for function and performance (as all functioanlity would go through that engine).

4. Even if all dev's stopped, users could change/extend without them.


Currently, UOX is C++ server, with a JS override capability (for the most part). So the JS engine design/implementation only gets tested as users use it. And the C++ source stays large until it is ported. Why wait on the porting? They believe is users can JS script. So the objective seems to ensure the egine is solid, and flexible. The other C++ implementation shoudn't matter, and could be done whenever.


This would seem to reduce overlap of effort (for instance, your "maintenance" efforts include code that in theory, would be thrown away, and done in JS. At the same time, the JS isn't get a "complete" workout, to identify if it is truely robust enough in its current implementation.

Again, seems like a more effecient use of resources, and would still seem to meet the critieria as has been exposed to date.


peace
peace

punt wrote: I am curious why taking another emu doesn't meet your stated desire, self-education. One can not learn from that base, as it gets adapted and deviated? One didn't take a clean slate this time, it used a base that was done by others. So clearly a starting base on some others work met your interest at one point. What about UOX makes it able to meet the need versus an other? And does exposure to more peoples way of doing things not promote self education, as you have a wider audience to get exposed. The project would still be UOX. It would start with a different base (no different then using the .9 seriese over the .7 series).

At this point, switching over to any other emu would require simply re-learning the design style in that project. While it is not a bad thing to verse ones self in the design style of many, it is a large undertaking to familiarize ones self with that style, and it takes away from the freedom to test out theories and work on my own implementation of things I would like to see done.

punt wrote: If for a minute we add in the other "restriction", that no other source code base is to be conisidered (unclear how far that extends. For libraries as well?), then I have to ask the second question:

Why isn't the focus on "removing" code, and getting a functional core base working? What I mean by that, is if UOX is really going to be advertised as a "scripted" server, then to really test/flush out the JS engine (are things exposed that need to be exposed, etc), Most of the C++ code could be removed. That would give one a cleaner base of C++ to make modifications to , restructure, etc. It would also provide the following features:

1. More examples of the JS coding (since without JS now, the emu wouldn't do much if anything).
2. Validate that the design of the exposure of the JS is really adequate to extend it in the future
3. Thoroughly test the JS engine implementation, for function and performance (as all functioanlity would go through that engine).

4. Even if all dev's stopped, users could change/extend without them.


Currently, UOX is C++ server, with a JS override capability (for the most part). So the JS engine design/implementation only gets tested as users use it. And the C++ source stays large until it is ported. Why wait on the porting? They believe is users can JS script. So the objective seems to ensure the egine is solid, and flexible. The other C++ implementation shoudn't matter, and could be done whenever.


This would seem to reduce overlap of effort (for instance, your "maintenance" efforts include code that in theory, would be thrown away, and done in JS. At the same time, the JS isn't get a "complete" workout, to identify if it is truely robust enough in its current implementation.

Ironic you should say that...

That is the exact goal.

Firstly to shove out as much code as possible on to the JS engine:
1) Commands
2) Magic
3) Skills
4) AI

More?

Then, and only then, to restructure what remains of UOX getting it to an organized and maintainable state (hopefully standardizing much of the code in doing so).

So I think we are, to an extent seeing eye-to-eye, though we have a habit of stating the same thing in two ways

Ironic you should say that...

That is the exact goal.

Firstly to shove out as much code as possible on to the JS engine:
1) Commands
2) Magic
3) Skills
4) AI

More?

Then, and only then, to restructure what remains of UOX getting it to an organized and maintainable state (hopefully standardizing much of the code in doing so).

So I think we are, to an extent seeing eye-to-eye, though we have a habit of stating the same thing in two ways

That isn't exactly the same. Let me try this again, for it should reduce the amout of work to one time on the server, and give the scripting engine a much far greater workout.

1. If UOX is a scripting server, identify what all code is to be scripted. You have a list, is that it? is there more (accounts?). If that is the list, then right now I shouldn't see any code in c++ to do ANY of that. If it is, it should be removed (for it detracts from maintenance, finding bugs, etc). Now, of course, as soon as you do that, the emu isn't a great help without JS versions. See step 2.

2. Work should be on JS those parts. In theory, Xuri and others should be able to do this as well , if not, it is good feedback on where the scripting engine could use work from an understanding issue. If while doing this, you get collective feedback on the engine, and where it is inadequate on the job.


Now, this isn't what the project is doing. It is doing it piecemeal. May not sound like a big deal, but in a resource restricted arena it is. 1. The c++ code that will be thrown out, is just "baggage", that can distract or "mask" other problems. 2. It doesn't give you the entire "picture" of what the JS engine needs to do, espeically in others hands. So if improvement was to happen, it doesn't have all the data to take into account. 3. (perhaps the most important). If resources wind up going away , in theory , if it is all JS, any "user" could do it. If there is still c++ left, it becomes harder for a "user" to carry on without them.


So, a thought to consider. At the moment, watching the posts, and code, the JS engine is getting individiaul input , one system at a time. Versus a complete picture. And othe code is getting in the way at times (the "run this c++ if no JS, etc, which has had bugs and time has been spent fixing them).

While I see your point, I must disagree.

In theory it would be excellent to simply rip the guts out of UOX and then state "ok, script it". However, doing so would cause UOX to be unusable until most or all of those subsystems were re-written in JS.

Why cripple ourselves for an indefinite period of time (which could be simply the end of UOX) when we have fully functioning systems that we simply want to shove out to JS to ease maintenance.

The bugs are, largely, not caused by buggy systems, but by having so many systems, making it next to impossible to do anything.

giwo wrote:While I see your point, I must disagree.

However, doing so would cause UOX to be unusable until most or all of those subsystems were re-written in JS.

The answer was all ready given.

1. It gets bugs out of the multiple systems that "users" can't get to.
2. It flushs out more bugs with the JS engine sooner (which is the draw of uox)
3. It gets the server to a point that "users" could finish it.


Lets make on assumption. That all those "perfectly working systems" are just that, perfectly working. One then still doesn't find "issues" with the JS engine until the get replaced (which becomes by piecemeal) and as they get replaced. So the system never gets updatesd as a whole!

Second, even if all is perfect, the JS engine is the draw of the emu. The systems identified are the most likely ones that one would want to enhance, modify. The user gets no examples on how to do that, and the project doesn't find out if the engine is up for the job until it does get updated. Doesn't sound the way to keep/attract users. You stated there where several users "waiting" to use UOX as soon as it got stable. No matter by whos count, the current base is small. Those waiting, one assumes they are waiting due to the JS engine? So shouldn't it be given in a state "known" and tested to do the job that is advertised?

Third, notice the work on UOX comes and goes. In theory, the JS engine lets users "finish" it. So if the systems are in JS "shape", then even if dev's stopped for a while, a user could finish it.


Now, take the other assumption, that the systems are NOT in perfect condition (and they are not, as there have been bug fixes even in this forum ). You previously stated the issue is having devoted workers. That implies there is more work then devs. So, now what is the way to get more users coding JS (for again, we stated that was the draw of the server). Fixing the systems that are "to be replaced" for JS, takes away your time. It is also not consistent with the "attraction" of getting a JS emu to theusers, with examples of how to change those major systems.


The end of UOX, is no more likely then in its current form. Getting a system that is operable (but not via the JS, that could be "unkown", or no examples to modify from) ihas all ready been stated to not be the attraction to the users. And those that are using it today, if they have gone this long, unlikely they would leave (one has to assume they are also still using it due the JS capability).


Of course you can choose not to take this approach, but I don't see how it can be disagreed upon based on the resource issue, which is one of the major issues you yourself stated is the issue with UOX.

This makes sense to me. Whats the point of endlessly fixing bugs on features that will be converted to Javascript one day (hopefully). Javascript has a *lot* of potential. By building a stable core and adding more functionality into Javascript you give power to the users, which is what all the emulators are doing nowadays. For example Runuo is fully customable due to plugin type assemblies that compile into the base. The whole functionality of Runuo is actually open to alteration, which is why it is so popular. Wolfpack also have got it right with Python, although I haven't used it, their documentation shows how much it is customable http://doc.wpdev.org/ .

In theory it would be excellent to simply rip the guts out of UOX and then state "ok, script it". However, doing so would cause UOX to be unusable until most or all of those subsystems were re-written in JS.

Lets be honest, nobody uses UOX and it isn't really usable to the extent it can be used as a playable shard. Anyone who is interested in UOX is waiting for it to be playable or just like to dabble in the Javascript side, and I am sure they wouldn't mind it being rewritten.

From what I have seen there are people who would like to help out but can't code but they can script Javascript. These are potential "usable resources" that are going to waste.

Anyway I think punt summed it up quite well in his points. I know I haven't been around long but I think most people feel this is the logical way to go.

I believe UOX has a lot of potential but Javascript is the way to go to release that potential. Its all up to the developers though whether they want to go there or not. There is everything to gain and not much to lose!

xir

On another note as well...time to get MYSQL backends in. Wolfpack has them..

You know how awsome it is to be able to tie in your shard with an external management tool or ten? Like how I am setting my site up so users can check on their character, sell items directly from in game and securely (avoids scams for one thing), I can actually do a messenging system now, and more! I mean seriously! I would love to have uox3 with mysql backends, for at LEAST the accounts. I honestly tried to do it a few times but I can't get it working. I was hoping someone would have thrown it in by now. But thats a definitie MUST HAVE at this point!

Jediman wrote:On another note as well...time to get MYSQL backends in. Wolfpack has them..

You know how awsome it is to be able to tie in your shard with an external management tool or ten? Like how I am setting my site up so users can check on their character, sell items directly from in game and securely (avoids scams for one thing), I can actually do a messenging system now, and more! I mean seriously! I would love to have uox3 with mysql backends, for at LEAST the accounts. I honestly tried to do it a few times but I can't get it working. I was hoping someone would have thrown it in by now. But thats a definitie MUST HAVE at this point!

Why wouldn't accounts just be javascript? If so, then again, all that code (which time is spent being debugged), should be done in JavaScript, that one could then of course, modify it as they choose to access database, etc.

I've not wanted to weigh in on this, because I haven't had time to read it all thoroughly, and form an opinion. However, someone threw up the red flag (databases), and I felt compelled to comment.

Why MySQL? What if someone legitamately has something like UDB, SQL Server, or Oracle? Are you going to say, "Sorry guys, we only support MySQL"?

If you tie it to one platform, well, you tie it. But then, if you say no, we want to support more. How much more? What revision level of SQL do you support? SQL-89? SQL-92? Something more recent? What features do you take for granted? Transactions? Primary/Foreign key relationships? What data types do you assume? Access has an auto counter, and while you can have trigger based auto counting in SQL Server, you have to set that up.

Do you rely on the database to retain integrity? How much do you throw into the database? Accounts? World data? Hell, why not scripts and data definitions?

Do you rely on the database for *everything*? IE does every property and object queried come from the database? Or does the server have some of local "caching" involved? If so, you run into synchronisation issues if the server grows to be able to run on more than one machine.

This has come up in the past, will come up in the future, and people have never really answered questions. Eg, from 2000, in a conversation with someone:

"I think there are too many questions that need to be answered before it's event attempted. Among which, these are a minimum question list:

Which DB?
Do you write to a single DBMS?
Do you write to standard SQL?
(For Windows)
Do you use ADO?
Which version? 1? 2? 2.1? 2.5? Some future version?
RDO?
DAO if Jet?
(General again)
ODBC?
If single DB, which are you forcing people to use?
Access?
SQL Server?
MySQL?
IBM's UDB?
Some other?

If you aim at multiple DBMS, then you have to aim for particular SQL
standards. SQL 92? SQL 88? You cannot then use DBMS specific features,
unless you write a modified driver for each and every DBMS
implementation. Also, not all DBMS types fit a particular standard. Access denies
certain field names, while SQL Server lets them slip.

Transaction based system?

If so, how do you cope for a DBMS that doesn't support commit and
rollback?

And last of all, why does everyone think that it has to be faster than the text files that currently exist? I see no benefit of going to a DB based system until the system is threaded. And then you're going to get record locking contention. Different DBMS' will have different locking schemes. Row, page, table and possibly others. It is distinctly possible that all executed queries will be performed cross-process, and that will take a much bigger hit than a simple inprocess (but ugly) current organization.

And other questions exist. How much is going into the DB? Just the world files? What about scripts and accounts? How much will it be used? Will it be used for anything other than saving/loading, and script control? Or will UOX's in memory db be replaced with it?

All in all, there are too many questions, and any one of them could severely restrict compatability and future operation. If it weren't for Linux support, I'd say that your best bet would be ADO on Windows, as that's faster than other access mechanisms, and provides an abstraction layer, for which most major vendors have written real drivers. Also supports real transactioning, as well as things like disconnected recordsets."

My thoughts have changed somewhat since, but still, these are all the sorts of questions that should get answered before diving in and finding out it isn't really the way you want to do it.

Maarc wrote:"I think there are too many questions that need to be answered before it's event attempted. Among which, these are a minimum question list:

Which DB?
Do you write to a single DBMS?
Do you write to standard SQL?
(For Windows)
Do you use ADO?
Which version? 1? 2? 2.1? 2.5? Some future version?
RDO?
DAO if Jet?
(General again)
ODBC?
If single DB, which are you forcing people to use?
Access?
SQL Server?
MySQL?
IBM's UDB?
Some other?

If you aim at multiple DBMS, then you have to aim for particular SQL
standards. SQL 92? SQL 88? You cannot then use DBMS specific features,
unless you write a modified driver for each and every DBMS
implementation. Also, not all DBMS types fit a particular standard. Access denies
certain field names, while SQL Server lets them slip.

Transaction based system?

If so, how do you cope for a DBMS that doesn't support commit and
rollback?

And last of all, why does everyone think that it has to be faster than the text files that currently exist? I see no benefit of going to a DB based system until the system is threaded. And then you're going to get record locking contention. Different DBMS' will have different locking schemes. Row, page, table and possibly others. It is distinctly possible that all executed queries will be performed cross-process, and that will take a much bigger hit than a simple inprocess (but ugly) current organization.

And other questions exist. How much is going into the DB? Just the world files? What about scripts and accounts? How much will it be used? Will it be used for anything other than saving/loading, and script control? Or will UOX's in memory db be replaced with it?

All in all, there are too many questions, and any one of them could severely restrict compatability and future operation. If it weren't for Linux support, I'd say that your best bet would be ADO on Windows, as that's faster than other access mechanisms, and provides an abstraction layer, for which most major vendors have written real drivers. Also supports real transactioning, as well as things like disconnected recordsets."

A few observations:

1. If accounts are moved out of the core, then the user can script in whatevery they want. Isn't that the purpose of the JS ? As it is in a sperate thread, performance isn't the largest issue anymore (getting "into" the server).

2. Your questions could apply to any design. To whom must they be answered to ? Did those questions get asked and answered before the .95 series was started? I recall linux support being "added" at the very end, so that seem to accept a tied approach at least iniitally, and then expanded out. I don't necessarly disagree to the questions, but I believe it shouldn't be help to any higher standard then the approach that was taken for the .9 series. At least in this case, the "suggested" database, Mysql, at least works on all the supported OS, not something that could have been said for the initial .9x release.

3. The thrust of the thread was to delete NOW all systems that are intended to be JS (make it a true scripted server). And then focus on the JS scripts, to flush out and validate the JS design/engine. The reasons are those stated above. If that was in place, users could easier decide on their own, to add a database (one that fits their criteria, not one for everyone). To me, it just supports, strip out all the C++ and focus time on getting the JS in (for examples, validation, etc).

I find it unlikely we will ever move such pertinent subsystems as account to JS.

But nothing is impossible.

As for moving less-important things (and those that need more customization) like skills and the like. There's nothing stopping users from creating them in the JS now. Hell, when we first put in the JS engine Yeshe wrote some cooking scripts (which notably probably need to be re-written since the changes) but the functionality of most things skills need to do was in back then.

Once the File IO is fixed I am going to start redoing the shard status, guild and player pages in the js. I think on a whole it would be much nicer, since instead of messing with both source AND templates, you have it all in one, plus this way the guild outputs and stuff wiill work correctly, and its just easier to maintain when its externally available. Its also way more customizable in that fasion as well!

Sounds excellent Jedi...

What, exactly, is wrong with the FileIO?

I may be able to at least have a look at it in my spare time, if I knew what the problems were.

All i heard was that its broken, if not great! I can start tonight