Trying to fix a buggy zone point..if possible

[Huppy]

I have this weird thing going on with only one zoint point from Corathus to Nektulos. Everything else works just great. (this is with SoD client)

If I zone from Corathus to Nektulos using that pok-style book, just inside
the Corathus zone line, it goes smooth, evrything is normal, same as when
travelling to Nektulos, and zoning in to Corathus using the tunnel, it works
fine.

But if I use the zone point in the tunnel/water to zone in to Nektulos, from
Corathus it works, but after zoning, Nektulos is a little buggy.
(npc's in water, can't zone back in to Corathus through that same zone point, etc)

[Yujiro93]

Try to change the Nektulos.eqg file to Nektulos.bat

[Huppy]

Try to change the Nektulos.eqg file to Nektulos.bat

No, I can't do that, that is for the newer Nektulos, which is the one I am using. Everything except that one tunnel zone point (from Corathus to Nek)
is working fine. All other zoint points, zone, mobs, all works fine otherwise.

[blackdragonsdg]

Don't know if this will help or not but here is the zone and zone_points data for corathus creep. This is from a packet collect from today.

-- Zone Config
--
UPDATE zone set `short_name` = 'corathus', `file_name` = '', `long_name` = 'Corathus Creep', `safe_x` = 16, `safe_y` = -337, `safe_z` = -46, `underworld` = -1000, `minclip` = 50, `maxclip` = 1800, `fog_minclip` = 300, `fog_maxclip` = 1800, `fog_blue` = 140, `fog_red` = 100, `fog_green` = 100, `sky` = 0, `ztype` = 255, `time_type` = 1, `fog_red2` = 100, `fog_green2` = 100, `fog_blue2` = 140, `fog_minclip2` = 300, `fog_maxclip2` = 1800, `fog_red3` = 100, `fog_green3` = 100, `fog_blue3` = 140, `fog_minclip3` = 300, `fog_maxclip3` = 1800, `fog_red4` = 100, `fog_green4` = 100, `fog_blue4` = 140, `fog_minclip4` = 300, `fog_maxclip4` = 1800 WHERE zoneidnumber = 365;
UPDATE zone set fog_density = 0.33 WHERE zoneidnumber = 365;
--
REPLACE into zone_points(`zone`, `number`, `y`, `x`, `z`, `heading`, `target_y`, `target_x`, `target_z`, `target_heading`, `zoneinst`, `target_zone_id`, `buffer`) VALUES('corathus', 10, 0, 0, 0, 0, -1237, -948, 186, 66, 0, 362, 0);
REPLACE into zone_points(`zone`, `number`, `y`, `x`, `z`, `heading`, `target_y`, `target_x`, `target_z`, `target_heading`, `zoneinst`, `target_zone_id`, `buffer`) VALUES('corathus', 20, 0, 0, 0, 0, -1125, -1041, 250, 67.5, 0, 362, 0);
REPLACE into zone_points(`zone`, `number`, `y`, `x`, `z`, `heading`, `target_y`, `target_x`, `target_z`, `target_heading`, `zoneinst`, `target_zone_id`, `buffer`) VALUES('corathus', 30, 0, 0, 0, 0, -1026, 1187, -11, 221, 0, 25, 0);

[Huppy]

Don't know if this will help or not but here is the zone and zone_points data for corathus creep. This is from a packet collect from today.

Thanx blackdragonsdg, I sourced that in, but it didn't make any difference.
I tried going through the doors and zone_points to see if anything was out
of wack, but there's a few in the doors for corathus that make reference to
zoning in to nek with more than one using door type 57, but I didn't want
to bugger anything up by playing with it, lol
I took a /loc from the spot where the pok style book puts you into Nek, and
a /loc where the tunnel point sends me, but could not find anything in the
tables to match up with it.
The pok-style book puts me at -1066, 1192.5, -2.62 and the tunnel/water
zone point puts me at -1053, 1193.88, -5.33
So not sure, but I'll keep looking :)

[blackdragonsdg]

I just noticed something....the zone table has underworld = -1000 and one of zone_points output has an x value of -1041. It is possible that the underworld value just needs to be set differently.

Edit: Well I said that wrong but take a look at the underworld value for nektulos then compare it to the target_x used when leaving corathus.....mine is waaaay off.

[realityincarnate]

The problem has to do with the two versions of Nektulos used by the emulator. SoF and later use v3, but the zone point from corathus to nektulos points all clients to the original version of the zone, giving you spawns in the wrong locations. The following sql should send later clients to the proper zone version.

update zone_points set client_version_mask to 3 where `zone` = 'corathus' and `number` = 30 and `target_instance` = 0;
insert into zone_points(`zone`, `number`, `y`, `x`, `z`, `heading`, `target_y`, `target_x`, `target_z`, `target_heading`, `zoneinst`, `target_zone_id`, `target_instance`, `buffer`, `client_version_mask`) VALUES('corathus', 30, 0, 0, 0, 0, -1026, 1187, -11, 221, 0, 25, 1, 0, 4294967292);

[Huppy]

The problem has to do with the two versions of Nektulos used by the emulator. SoF and later use v3, but the zone point from corathus to nektulos points all clients to the original version of the zone, giving you spawns in the wrong locations. The following sql should send later clients to the proper zone version.

THANK YOU very much realityincarnate. You actually helped me remember
something that I forgot about. Awhile ago, I got advice on how to change
the client_version_mask's to be compatible for both Titanium and SoD clients
and set all the ones that had a 3 or 28 to 4294967295 as suggested.
So I just had to go to the zone_point id 1501 and change that to 3 and run
the second syntax from your fix. Now all is working well.
I had made a decision recently to just stick with SoD-UF client support and
put Titanium back on the shelf. I'm just trying to keep some of the old zones
in play (Oasis, east/west commons, etc).
Thanx again for your help.