[ARCHIVED] Latest Version of UOX3 (Updated March 8th 2006)

[Grimson]

Code: Select all

[color=yellow]2/23/2006 - grimson (0.98-3.4g [3.5 BETA])[/color]
	Added three new ini settings:
		PETHUNGEROFFLINE=0/1 	Sets whether pets should hunger while the player is offline or not.
		PETOFFLINETIMEOUT=#  	Sets the offline time of a player in days after that a pet becomes
					wild again.
		PETOFFLINECHECKTIMER=#	Sets the intervall in seconds between checks for the player offline
					time.

	Added 2 new NPC values to CChar to state whether the char has been mounted or stabled and check those
	in the DoHunger() and the new checkPetOfflineTimeout() functions. And made them available to the JS
	engine as the 2 new propertys:
		.mounted	Can be used to get or set the mounted status
		.stabled	Can be used to get or set the stabled status

[Maarc]

Couple of things.

1) IsMounted already existed, we were already tracking whether or not a Char was mounted. This is through the IsMounted() function. Adding a new flag was essentially redundant. I have not reverted this out, as a) I don't have the time and b) You may want to look at it's impact.

2) Lots of bools is bad, and something we try to avoid. Adding lots of bools slowly eats away at memory, whereas using a bitmask is much more memory efficient.

I have committed a patch that modifies it, so that it uses a bitmask instead of multiple booleans.

[Grimson]

Couple of things.

1) IsMounted already existed, we were already tracking whether or not a Char was mounted. This is through the IsMounted() function. Adding a new flag was essentially redundant. I have not reverted this out, as a) I don't have the time and b) You may want to look at it's impact.

I somewhat dislike the way the IsMounted() function works, by checking the coordinates of the char, as there may be other reasons for the char being at those coordinates (for example the stable master JS script I'm planning will also send the pet to those coordinates). Or the coordinates may even need to be changed when the map size changes.

If you have nothing against it I will take out the IsMounted() function an replace it with the GetMounted() function from me.

2) Lots of bools is bad, and something we try to avoid. Adding lots of bools slowly eats away at memory, whereas using a bitmask is much more memory efficient.

I always use bools when first implementing things, leaves less space for errors (which I tend to make using bitmasks). But I'll use bitmasks from now on.

I have committed a patch that modifies it, so that it uses a bitmask instead of multiple booleans.

Thanks.

[Grimson]

Code: Select all

[color=yellow]2/23/2006 - grimson (0.98-3.4h [3.5 BETA])[/color]
	Prevent spamming of weather packets when riding a boat.
	Added a quick fix to the inMulti() function to make boats workable again.
	Changed the HP and HPMAX tags so that you can set a minimum and maximum value.
	Removed the IsMounted() function and replaced all it's calls with the GetMounted() function.
	Allow a food list to contain a link to another food list.

@Maarc
I hope it's okay that I replaced the IsMounted() function.

[Grimson]

Code: Select all

[color=yellow]2/23/2006 - grimson[/color]
	Changed TurnStuff() in boats.cpp to fix players getting stuck when turning the boat.

[Grimson]

Code: Select all

[color=yellow]2/23/2006 - grimson[/color]
	Added a Dirty( UT_LOCATION ) to HandleDeath() in pcmanage.cpp to make shure the player gets
	properly updated when he dies.

[giwo]

Code: Select all

[color=yellow]
2/23/2006 - giwo (0.98-3.4i [3.5 BETA])[/color]
	Fixed an issue causing players to not disembark boats properly.
	Fixed an issue causing boat holds not to be made part of the multi.
	Updated the INI loading code to make it more verbose.
	Removed "Golden" health until we know when (if ever) OSI uses it.
	Created a new class, CJSEngine along with the files CJSEngine.cpp/.h
	Created a new class, CJSRuntime to allow multiple runtimes (for threading purposes).
	Moved JSObject creation and handling into CJSRuntime.
	Moved global JS Context and Runtimes into CJSRuntime.
	Moved JS Engine loading code into CJSEngine.
	Modified cScript so all JS Scripts on a runtime share a single context.
	Removed global.cpp from the project.

Please note that this is still a work-in-progress, and I fully intend on unexpected issue coming up that I will need to address. However per my own testing things seem to be working well with the new system, and it is much less prone to extreme memory usage.

[Grimson]

Code: Select all

[color=yellow]
2/23/2006 - giwo (0.98-3.4i [3.5 BETA])[/color]
	Created a new class, CJSEngine along with the files CJSEngine.cpp/.h
	Removed global.cpp from the project.

I just updated UOX3_Official.dsp to reflect these changes. So far it builds without problems on VC6.

[giwo]

Thanks Grim.

[Grimson]

Code: Select all

[color=yellow]
2/23/2006 - giwo (0.98-3.4i [3.5 BETA])[/color]
	Fixed an issue causing players to not disembark boats properly.

That currently doesn't seem to take statics, like the pier at the harbor, in mind. If you want I can take a look at this.

[Maarc]

No problems on the change, Grimson. Hopefully the quick #define macros I threw in should make it easier to deal with bitmasks, at least in CChar. It wasn't a complaint by me, just more a pointing out of things. You never know when something might already be implemented, so that checking to see if something is already there is a good thing, that's all!

[giwo]

Grim, pretty sure I know what the issue is, let me see if I can whip out a fix.

[giwo]

Code: Select all

[color=yellow]2/23/2006 - giwo (0.98-3.4j [3.5 BETA])[/color]
	Fixed some issues with Multi and Static height calculations.
	Moved Definition of global JS classes into CJSRuntime.
	Locked the JS Class prototypes for Garbage Collection purposes.

[Grimson]

Code: Select all

[color=yellow]2/23/2006 - giwo (0.98-3.4j [3.5 BETA])[/color]
	Fixed some issues with Multi and Static height calculations.
	Moved Definition of global JS classes into CJSRuntime.
	Locked the JS Class prototypes for Garbage Collection purposes.

Ok, no problems with leaving a boat now.

But JS seems to be worse, calling 'cleanup spikes the memory usage to over 250 MB (was around 130 with earlier builds) and upon quitting the server it crashes in the "Destroying class objects and pointers" step.

[giwo]

Well memory usage may spike when it runs garbage collection, what is important is if you are recovering said memory.

[Grimson]

Well memory usage may spike when it runs garbage collection, what is important is if you are recovering said memory.

Ok, I will let it run a bit longer and monitor the memory usage.

[giwo]

It may be worth noting that we never ran JS garbage collection during the normal operation of a server, it was only done on the deletion of a script. With these changes it is done every save and can be done (dependant on current usage) when the IterateOver() JS function finishes. This should help (over time) the reclamation of wasted storage used by the JS engine.

I'm currently working on the crash, btw.

[giwo]

Code: Select all

[color=yellow]2/23/2006 - giwo (0.98-3.4k [3.5 BETA])[/color]
	Fixed a crash when shutting down the server.

[Grimson]

It may be worth noting that we never ran JS garbage collection during the normal operation of a server, it was only done on the deletion of a script. With these changes it is done every save and can be done (dependant on current usage) when the IterateOver() JS function finishes. This should help (over time) the reclamation of wasted storage used by the JS engine.

No sign of the memory recovering upon worldsaves. Actually the memory usage is still increasing it's now at 270MB.

[giwo]

I checked it out, and see what you are talking about... here's the situation.

The first time an object is used, we allocate a JSObject for it, this is why memory usage increases. I was only testing wipe, so on my tests it recovered the memory it used (as the JSObjects were deleted). However, on a normal IterateOver() call, we allocate those JSObjects (unless one has already been allocated for the object) and don't free them until the object itself is deleted.

I am considering a way to release those JSObjects after a while of non-use, but alternatively since it is only the IterateOver() function that would every cause so many allocations, we can de-allocate the JSObjects it created immediately after execution. Downside would be more time spent to Re-allocate those JSObjects next time (try running a cleanup again and notice how quick it runs), upside is faster recovery of that memory (which will be quite a large chunk on a big server).