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

[giwo]

Yeah, that was the error I fixed in 0.98-3.4u

The danger of using the latest and greatest.


As for the console spam, only happens in debug, and is there for a good reason, lets us know something is going wonky in the world....

[giwo]

As a side note, you'll find that the "excess" objects 0.98-3.4t created will be in the 0.0.wsc file....

[Xuri]

I get these errors when using the default worldfiles

[Grimson]

I get these errors when using the default worldfiles

Try it without the spawn.dfn, I guess I know the reason. To determine whether a place is suitable to spawn a char I had to change the RegionSpawnChar() code from cSpawnRegion.cpp so that it first creates the NPC and then checks for a suitable place, as I need to know what movement type (water/land/both) the NPC has. If it doesn't find a suitable place it will delete the NPC afterwards.

This is where the error seems to come from, the NPC never got added to a map region, but the cleanup() function tries to remove it from a map region. The same also happens to the items the char has been supplied with.

[giwo]

Quite right Grimson...

Something I've been considering... perhaps we should add something to spawnregions... A list of X/Y/Z locations (a point3, perhaps?) that is valid, so when we randomly pick our locations, if it's on that list, don't bother looking, and more importantly, if we can't find a valid spawn location, randomly select from that list so we don't wind up deleting something we just created....


Xuri: I'll modify the ifdefs so you have to specifically declare region debug mode to get the console spam.

For now, just use release mode.

[Grimson]

Something I've been considering... perhaps we should add something to spawnregions... A list of X/Y/Z locations (a point3, perhaps?) that is valid, so when we randomly pick our locations, if it's on that list, don't bother looking, and more importantly, if we can't find a valid spawn location, randomly select from that list so we don't wind up deleting something we just created....

So add a CDataList with point3 entrys, then fill it using a new tag like ValidLocation=#,#,# and use that list in FindCharSpotToSpawn() and FindItemSpotToSpawn(). Shouldn't be to hard.

Edit: We would need to lists, one for land chars one for water chars.

But still, for spawnregions that don't have that tag defined it would be nice if the cleanup() code doesn't try to remove them from a map region. Is the IsSpawned() flag correctly set everywhere in the code, if yes we could only remove them from map regions when it is set to true.

Edit:
Another way may be to not let the user define the valid locations, let UOX3 populate the lists when it reads the spawnregion. Basically going throught the whole square testing every location and adding them to the lists. Upon spawning just pick a random list entry.

The upside is that spawning would work faster. The downside is that it may increase memory usage quite a bit and starting up the server can take quite some time with many big spawnregions.


Or sort of combine both ways, let the user define valid locations and everytime we spawn something and found a valid location add it to the list. The downside would be that the "learned" valid locations are lost upon a server restart.

[giwo]

I was thinking that as we find valid locations, we add them to the list. This saves from extra tags in spawn.dfn (and thus extra work loading and storing those tags) and would reduce the memory usage of physically searching every single square.

As for the water vs land creatures, that would take some consideration, but rather than two lists, you could do something like have an extra flag for each entry in the list, isWater, or something like that.


Overall, water spawnregions should (I would think) be seperate from non-water spawnregions. Otherwise you are going to find yourself doing alot of extra work (finding water spots for those creatures on a mostly-land block, and vise-versa).

[giwo]

As a bit of a side-note, CDataList is most useful for lists that are commonly being updated (objects regularly being removed/added), and/or areas where we need to allow global iteration. For something that would be internal and basically only added to, such as this type of list, a simple vector would suffice, saving the extra overhead CDataList brings with it.

[Grimson]

I was thinking that as we find valid locations, we add them to the list. This saves from extra tags in spawn.dfn (and thus extra work loading and storing those tags) and would reduce the memory usage of physically searching every single square.

I'm currently going to implement something like this.

As for the water vs land creatures, that would take some consideration, but rather than two lists, you could do something like have an extra flag for each entry in the list, isWater, or something like that.

I think seperate lists are better, with one list for everything we have to run through more list entrys upon checking and we have to also compare the location type everytime. With two lists we just have to go over the land list for land creatures, and the same for water creatures.

[giwo]

What you can likely do is make a map, rather than a vector

std::map<UI32, SI08> validXYZList;

This way you can immediately access the X,Y location you are checking, and upon finding one, return a valid Z value for that XY

Would be something like

std::map<UI32, SI08>::const_iterator checkValid = validXYZList.find( y + (x<<16));
if( checkValid != validXYZList.end() )
z = checkValid.second();

[Grimson]

Code: Select all

[color=yellow]3/02/2006 - grimson[/color]
	Added two vectors to spawnregions to store valid locations.
	You can define valid locations using the new DFN tags:
		VALIDLANDPOS=#,#,#
		VALIDWATERPOS=#,#,#
	Changed FindCharSpotToSpawn() and FindItemSpotToSpawn() so that they first check
	agains the list to see whether a location is valid. If the location is not in the
	list but valid it will be added to the list. If no valid location has been found
	it tries to get a random one from the list of already stored locations.

Have a look at it and tell me what you think.

Edit: Another small commit, I used the wrong names for the new tags in CSpawnRegion::Load().

[giwo]

Should use iterators whenever possible for stl containers, Personally I'd go with a map rather than searching through the vector every time.

The one issue with such a list is Dynamics at a spawn location could change... we might want to take that into account.

[Grimson]

Should use iterators whenever possible for stl containers, Personally I'd go with a map rather than searching through the vector every time.

Will convert it to a map. As I have no experience with a map, is there an easy way (like with a vector) to get a random entry?

The one issue with such a list is Dynamics at a spawn location could change... we might want to take that into account.

Let me think about this.

[giwo]

Vector would be easier to pull a random entry from

myVector[ RandomNum( 0, myVector.size()-1 ) ] would return a random entry.

[Grimson]

Vector would be easier to pull a random entry from

myVector[ RandomNum( 0, myVector.size()-1 ) ] would return a random entry.

That's what I used. So what now, using a map for checking and a vector for getting a random location?

[Grimson]

Code: Select all

[color=yellow]3/02/2006 - grimson[/color]
	Added two maps to spawnregions to make checking for valid locations easier.
	Check if the z value of stored locations still match the dynamic z value of the
	current locations to track whether dynamics have changed.

So now I'm using maps for checking whether the location has already been considered good and vectors to pull a random location from. I also check whether the dynamic elevation value still fits the stored z value hoping to catch changes of dynamics with it.

[Grimson]

Code: Select all

[color=yellow]3/02/2006 - grimson[/color]
	It's better to recalculate and check the whole z coordinate of a stored
	location to make shure nothing has changed since we stored it.

[Grimson]

Code: Select all

[color=yellow]3/03/2006 - grimson[/color]
	Removed the IsSurface check of dynamic tiles from cMapStuff::CanMonsterMoveHere(),
	as many landscape tiles don't have the surface flag set. So it prevented valid spawns.

[Grimson]

Code: Select all

[color=yellow]3/04/2006 - grimson[/color]
	Added a new ini setting:
	COMBATARCHERRANGE=#  This defines the range at which archers stop charging
			     the target in combat. (Default is 7)

[Grimson]

Code: Select all

[color=yellow]3/04/2006 - grimson[/color]
	Changed cMovement::SendWalkToPlayer() so that the sequenz number fits the description
	in CPacketReceive.cpp.
	Changed CPIResyncReq::Handle() so that it actually does resend everything around
	the player.