Lavastorm newer models

[provocating]

Anyone have a list of what the races are on the newer Lavastorm. Like the Lava Crawler race I show is 37, but that shows up as Human. Throwing 89 in there is a blue drake. I am guessing the numbers in my database are for the old models and the old zone.

[Derision]

Live appears to have a_lava_crawler as race 468.

[provocating]

Oh crap. Yeah I was thinking drake for some reason. Just curious though, how did you find that ID ?

[Derision]

I hopped onto Live, did a packet collect, ran EQExtractor2 and looked at the insert generated for a_lava_crawler:

INSERT INTO npc_types(`id`, `name`, `lastname`, `level`, `gender`, `size`, `runspeed`,`race`, `class`, `bodytype`, `hp`, `texture`, `helmtexture`,
`face`, `luclin_hairstyle`, `luclin_haircolor`, `luclin_eyecolor`, `luclin_eyecolor2`,`luclin_beard`, `luclin_beardcolor`, `findable`, `version`,
`d_meele_texture1`, `d_meele_texture2`, `armortint_red`, `armortint_green`, 
`armortint_blue`, `drakkin_heritage`, `drakkin_tattoo`, `drakkin_details`) VALUES(@StartingNPCTypeID + 29, 'a_lava_crawler', '', 16, 2, 12, 1.25,
468, 1, 21, 416, 1, 1, 0, 0, 0, 0, 0, 255, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0);

EDIT: I could have saved myself the trouble There was already SQL for the new lavastorm over on the PEQ logs repo that shows the correct race.

[provocating]

Well that was nice of you.

Can you answer a quick one, kind of related to the same subject. I notice that in the database there is a field for client version in the zone line table. Does the emulator look at the client version to actually see which map file and which zone points to use ?

I am asking because I see where the client version is different for zone points in like nektulos and lavastorm, neriak and such. With SoD and I am in Neriak the zone point for Nektulos does not work, I even did a goto command and stood right there and nothing. I am wondering if it knows that I am using SoD, or better yet does not know what to do with it.

[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.