Note for future reference/comparison - On Worldsave Performance..

[Xuri]

On a P4 2.5Ghz Northwood A, with 512MB ram and a WD 120Gb SE HD - UOX3 needed 119 seconds to save my world consisting of 27.105 characters and 377.816 items to an ASCII worldfile.

I wonder how long it would take if we had working binary saves - and/or the current worldsave system was completed as intended (save only changes or some such?).

[giwo]

Those are both possibilities (and quite likely will be in place in the future, once things are ironed out).

Also something I've thought of is having saves occurr in the background without affecting gameplay. Of course one danger of doing so is the possibility of corruption.

Personally I'm in favor of saves going into a database myself. This would offer speed, possibility of easy archiving, and overall make our life easier (though possibly make users life harder, as you would then need more than a text editor to modify said worlds).

Worldsaves definately need a speed boost at some point, though....

[giwo]

I have also been considering some other ways to not only reduce total memory usage, but speed up worldsaves/loads as well.

CMultiObj is currently derived from CItem. While the two do have some commonalities, there really isn't much that they share, at least not that I have noticed. Of course an in-depth look would need to be taken at what would need to be done to derive CMultiObj from cBaseItem directly (or perhaps an in-between class that both CItem and CMultiObj then derive from). Doing so would remove many entries from houses that are never touched. Of course, since houses are not the primary object in the world, the effects of this would be small (but not entirely negligible).

Secondly, something I worked on a while ago, and I feel UOX is approaching the capability of handling doing so, splitting CChar into CNPC and CPlayer, which would both derive from CBaseChar. There are MANY variables in characters which are unused by one or the other, in fact most of their commonalities are those they get from cBaseObject (meaning the same commonalities they share with CItem). That being the case, the current implementation of CChar can be seen as nothing but bloated. Splitting it, imho, is the only logical way to proceed.

The first change would quite likely not even be noticed by users. However the second (and larger) change, would certainly be noticed. And would once again require a tool to convert worldfiles, or simply starting from scratch. Currently the UOX userbase is small (which makes now the prime time for important restructuring), but it is still never a small thing to disturb the hard work of those building a server. So I am still weighing the worth & value of the latter change.

Anyhow, just some things to think on

Currently I am mostly done updating the JS Docs, much had to be updated or removed (as many of the old-style functions were still documented). I am sure there are things I have missed, but all-in-all it is far more accurate. ;0

[Xuri]

Hm. Wouldn't splitting CChar into CNPC and CPlayer also cause a lot of double-entries, for stuff that is the same for both players and npcs? And what about JScript methods/events?

I don't know HOW this works right now, or how it'd work after such a split - just curious

[giwo]

Basically everything Players and NPC's have in common would be in CBaseChar, thus we would simpy run anything they have in common on a CBaseChar, allowing for either one to be used.

Aside from that, a objectType check here and there, much like with CItem and CSpawnItem would do it.