Lavastorm newer models

[Derision]

KLS added support to allow newer clients to zone into the new versions of zones, e.g. SoD (and SoF?) to zone into the new version of nektulos, and I think highpass and maybe some others.

If you are using Underfoot, then this is broken currently due to a change I made (I changed the version number for Underfoot).

This SQL might fix it (untested, so either backup those tables, or be prepared to reverse the update if required):

update zone_points set client_version_mask = 4294967292 where client_version_mask = 2147483660;
update doors set client_Version_mask = 4294967292 where client_version_mask = 2147483660;

I don't know off the top of my head if there are any other tables that have a client_version_mask field that may also need updating.

EDIT: Just did some tests zoning into/out of nektulos and high pass and those update statements look good to me.

[provocating]

Well I am going to stick to Underfoot so I will just make them permanent.

[provocating]

All the zone points work now. I am getting some bounce on the mobs in Nektulos which I am guessing could be because the map file appears to be changed within the database itself. I am going to try renaming the file or copying it to nektulos(v3), which is what the database says the map should be.

[Derision]

Yes, you need to generate a new .map file for nektulos from the nektulos.eqg included in your Underfoot client, rename the generated nektulos.map to nektulos(v3).map and put it in your server Maps directory.

The .map file your downloaded from the maps SVN is probably for the old version of the zone.

Before running azone2 on nektulos, rename nektulos.s3d to nektulos.s3d.old or somethiing as azone2 looks for the .s3d first. The .map for the new nektulos should be around 47MB compared to about 800KB for the old version.

[provocating]

Yeah, got it all worked out now. Just curious what is the s3d file for ? Should I leave it renamed ?

[Derision]

.s3d is the original zone format that SOE used, newer zones use the .eqg format. Where SOE have updated the zone, they still seem to distribute both the old and the new versions.

The EQ game client looks for the .eqg version first and loads that if present. For some reason, the original version of azone looked for the .s3d file first and generated a .map from that if it found it, or generated a .map from the .eqg if an .s3d version could not be found.

So yes, leave the old version renamed.

[provocating]

My guards are in the water, no doubt from the zone being changed. I wonder if this SQL would fix them.

http://www.peqtgc.com/logs/file.php?...s-cavedude.zip

I may snapshot my VM tonight and try it, if the date of the file corresponds to when Cavedude did the capture, it may be the newer SQL from a Live capture. If I snapshot my VM, nothing lost.

[Huppy]

Originally Posted by Derision

KLS added support to allow newer clients to zone into the new versions of zones, e.g. SoD (and SoF?) to zone into the new version of nektulos, and I think highpass and maybe some others.

If you are using Underfoot, then this is broken currently due to a change I made (I changed the version number for Underfoot).

This SQL might fix it (untested, so either backup those tables, or be prepared to reverse the update if required):

update zone_points set client_version_mask = 4294967292 where client_version_mask = 2147483660;
update doors set client_Version_mask = 4294967292 where client_version_mask = 2147483660;

I don't know off the top of my head if there are any other tables that have a client_version_mask field that may also need updating..

I had the same problem and now the zone points are fixed, but I found a few
different entries of client_version_mask using a number 3 or 28.
I did notice that all of the other client_version_mask entries had a number
of 4294967295 (ending in 5, not 2), so I used that for the ones that needed
it. Not sure if this makes a diffrerence or should I change them all to end with
number 2 (as with your update entry above) ??

[provocating]

I have got to add an entry from PoK to places like Freeport whenever I get a chance. Not sure where it is supposed to drop me off so I think I will just do it from live and get a /loc.

[Derision]

Originally Posted by Huppy

I had the same problem and now the zone points are fixed, but I found a few
different entries of client_version_mask using a number 3 or 28.
I did notice that all of the other client_version_mask entries had a number
of 4294967295 (ending in 5, not 2), so I used that for the ones that needed
it. Not sure if this makes a diffrerence or should I change them all to end with
number 2 (as with your update entry above) ??

If you understand binary, the mask has a bit for each client, with the 6.2 Client being the least significant bit. In decimal, these correspond to:

1 Client 6.2
2 Titanium
4 SoF
8 SoD
16 Underfoot
32 HoT
64 and upwards are reserved for any future client versions.

So if a door/zone_point entry has a client_version_mask of 3 (1 + 2), it only applies to Client 6.2 or Titanium.

A mask of 28 is made up of 16 + 8 + 4 (i.e. Underfoot, SoD and SoF), so an entry with that mask applies to those clients.

4294967292 means any client from SoF onwards.

4294967295 means all clients, which is why most of the entries have this value, since most doors and zone_points are the same for all client versions.

So, to sum up, if a door or zone point is to apply to Titanium/6.2, use a mask of 3, for SoF and later, use a mask of 4294967292, for SoD and later, use a mask of 4294967288. For all clients, use 4294967295.

Where there are two zones for two sets of clients, there will be two entries for each door and zone_point, usually one with a mask of 3 for the old clients, and one with a mask of 4294967292 to apply to SoF onwards. Of course if any zones were revamped in SoD, then one set of entries would have a mask of 7 (6.2, Ttanium, SoF) and the other 4294967288.

[provocating]

Wow, thanks for that incredibly well written post. I totally understand what you are saying now.

[Huppy]

Originally Posted by Derision

So, to sum up, if a door or zone point is to apply to Titanium/6.2, use a mask of 3, for SoF and later, use a mask of 4294967292, for SoD and later, use a mask of 4294967288. For all clients, use 4294967295.

Thank You Derision, learning that is making sense now
I guess I can just leave them all at 4294967295. For myself, I would be using
the UF client all the time on my own server, but for future, I like to keep the
options open for all clients, just in case, for other people's clients.

[provocating]

Afraid I have just one more question.

If I were leaving PoK for let's say Freeport. I could put two zone points right on top of each other, with two different required clients. Would that work ? Ones supposed to be going to the old FP would go there, ones destined for the new Freeport would go there ?

[provocating]

Derision, I noticed since my last PEQ update I cannot zone from NeriakA to Nektulos without it going into a zoning loop, this is with SOF, SOD and UF but TIT works fine. I ran this SQL, after my PEQ update and restarted the server, no go. Ideas ?

update zone_points set client_version_mask = 4294967292 where client_version_mask = 2147483660;
update doors set client_Version_mask = 4294967292 where client_version_mask = 2147483660;