General: zone_points, spawn2, grid, pathing issues

[AdrianD]

Various issues familiar to many, no doubt. I've searched and read up on these but resolution has been elusive.

I use old zones and I'm trying to build a classic DB. I updated everything except the DB about a month ago.

I'll paste my notes and follow them with comments/questions:

1. Zoning

	
ToDo: Figure out zone_points for nro/efp

		nro 4160, 280, -24, 0, -1275, -700, -50, 254
		fre-1200, -670, -50, 0, 3875, 380, -27, 128
			y,x,z,heading		y,x,z,heading
		(lack of continuity with coordinates is inefficient)

I've fixed many other zones but, I'm stuck on this. I zone to the same spot no matter where I come from. Both directions.

Zone_points nro/oasis still messed up - put z at 999999 and its a little better but still get stuck
	- put y and target_y closer together - little better not fixed

'oasis', 2535, -765, 7, 0, -1856, 999999, 999999, 0
'nro', -1876, -765, 7, 0, 2515, 999999, 999999, 134
	y,x,z,heading		y,x,z,heading

A majority portion of zoning is fine but some areas I get stuck under the terrain.

** Fixed

2. Spawn/Grid

ToDo: look into lavastorm spawn and grid stuff - check eqclassic DB
	- eqclassic table schema is different - easy fix
	- eqclassic data is vastly different - spawngroupid's
		- I don't think queries would line up eqclassic coords with peq ids at the scale I need
		- I'm also not sure how accurate the coords are

The npcs show up on track but I can not see any on the map. I know the spawn2 table has values for the newer zone. I would like to get data for the old zone. Where can I find this?

ToDo: look into nektulos spawn and grid stuff - spawn2 has two versions - version 0 uses old zone
	- changed spawn2 query and added `where version = 0` - commented out for now - looking into weird spawn occurances
	- can't attack many npcs
	- spawn2 points are both to low or too high by up to ~20
	- is there a way to #spawnfix an entire zone; same with grid_entries

Nektulos is in much better shape than lavastorm. There are many spawns and grids which are in bad shape but, most of the data is salvageable, in my opinion. Replacing the data would be easier if it's available. Like my notes say: is there a way to #spawnfix an entire zone so the npcs spawn on "solid ground" and take to their grids on solid ground?

3. Possibly relating to #2 - four rules each ruleset

rule_values of `Map:FixPathingZMaxDeltaXXX..` from 12 to 20 and 45 to match what was shown on the wiki
	- I don't know what this does but it sounds like it could correct bad spawn2/grid
	- I still don't know what this does and I didn't notice a difference

4. Is the underworld like the bottom of the ocean? What issues does changing the underworld value help to resolve?

For every issue I bring here, I fix ten on my own. I have notes for everything. I admit I am running out of things to fix on my own. Most of these issues have been present for months or since I started back in March of 2014. I don't want you to think I'm being lazy.

Thanks

[AdrianD]

Update:

I seem to have fixed the zoning issue for nro/oasis, only.

I spent some time in-game and walked along the same axis the zone line runs to visually analyze the terrain. The coordinates which utilize "keep", 999999, are all pretty much spot on for this area of both zones. I was close but, not close enough.

Since the coordinates match the visual representation for both zones (z has the same value in both zones for the same visual representation) , I needed to match the coords with a visual corresponding to the values for zone_points.

To fix this, I had to shift the appropriate coordinate, in this case the y, for one zone for both in and out of that zone. (I changed the `target_y` corresponding to the zone I changed the `y` in) I also closed the gap between `target_y` and `y`.

Doing this in flat zones with even terrain is quite a bit easier. You'll notice in later expansions they don't have the zone line span the entire length of the zone as frequently. I can see why.

My other issues still stand. I would appreciate those with knowledge to assist.

* What makes corrections? I see a column named `buffer` in the table zone_points - what does this do?

[AdrianD]

My questions still stand...

And to clarify, this was not fixed:

I've fixed many other zones but, I'm stuck on this. I zone to the same spot no matter where I come from. Both directions.

ToDo: Figure out zone_points for nro/efp

		nro 4160, 280, -24, 0, -1275, -700, -50, 254
		fre-1200, -670, -50, 0, 3875, 380, -27, 128

Someone has likely had to deal with this issue and the ones listed previous. I'd like some assistance.

[Nightrider84]

Your probobly changing the zone points for the wrong version of northro make sure it's the version your using either old or new. They both say northro in the dB but one has a different zone id

[AdrianD]

Data for revamped zones does not exist in the DB I'm using live. The zoneidnumber is 34 for nro and 10 for freporte.

This particular issue is not a game-breaker. I was hoping someone who uses old zones and has these transitions working properly to chime in with their experience.

The other zone and spawn issues are related to above in that I was hoping someone could share their data for these troubled zones.

What remains of my questions from previous is how things work or the purpose of something, without repeating myself from above.

Thanks for the response.

EDIT: I have a couple of other databases not exactly "peq-style" which I use for reference. I was in the process of taking data from those DB and plugging it into my live peq DB. As can be imagined, this isn't as simple as it sounds. The table schema is different in many cases. The indexes and peq-specific values are causing problems.

What I am trying to do is, take spawn2 coords from a different DB and plug them into the peq DB but only if the npc_types.name exists in both DB and corresponding to those npc_types. The above issue with varying ids is presenting quite a challenge. I've made a few temp tables for this process.

So far, I've been able to assign the spawn2 coords and spawnentry.npcid's properly. I am stuck on plugging in the correct spawngroupid's into a temp spawn2 where the coords already exist. I don't know if it's possible or if I'm using improper syntax. My final results are less than desirable.

If anyone knows what I am trying to do and has experience doing it please respond or PM me.

Thanks

[AdrianD]

2. Spawn/Grid

ToDo: look into lavastorm spawn and grid stuff - check eqclassic DB
- eqclassic table schema is different - easy fix
- eqclassic data is vastly different - spawngroupid's
- I don't think queries would line up eqclassic coords with peq ids at the scale I need
- I'm also not sure how accurate the coords are
The npcs show up on track but I can not see any on the map. I know the spawn2 table has values for the newer zone. I would like to get data for the old zone. Where can I find this?


ToDo: look into nektulos spawn and grid stuff - spawn2 has two versions - version 0 uses old zone
- changed spawn2 query and added `where version = 0` - commented out for now - looking into weird spawn occurances
- can't attack many npcs
- spawn2 points are both to low or too high by up to ~20
- is there a way to #spawnfix an entire zone; same with grid_entries
Nektulos is in much better shape than lavastorm. There are many spawns and grids which are in bad shape but, most of the data is salvageable, in my opinion. Replacing the data would be easier if it's available. Like my notes say: is there a way to #spawnfix an entire zone so the npcs spawn on "solid ground" and take to their grids on solid ground?

I have been able to insert data from the other DB through a process referred to as mapping. It's quite a process but, not as involved as what I was trying to do with futility. I was trying to get a bit more precise in combining data from both databases than I have knowledge of sql or that is even possible in sql.

The result, although, is not perfect, as I was expecting. Lavastorm has npcs on solid ground and none in the underworld that I can tell. This zone still needs work but, that will be for a time when I can tolerate massive tedium.

Nektulos, on the other hand, had a mixed bag of results. Some were improvements, some a wash and some would create more work than the previous data. Of course, I only tested this on the live DB so nothing was permanent. This basically leads me to where I was, seeking a willing, generous person to share this specific DB information.

I'd still like to know what the purpose of `underworld` is and the function of the rules stated in 3/4 in the OP.

Thanks for reading as it seems that is all that's being done here.