SoF Spawn_Struct Hacking

[trevius]

Woah, thanks! I know Derision has some ways to read through the IDA output from the eqgame.exe that he can use to find many fields. I am not quite that knowledgeable about the ASM code. You have no idea how much of a pain it was to do the field finding stuff I have done for it so far lol. I wish I had this code from the start! I will definitely give it a try.

The SoF spawn struct to this point is pretty much chaotic. The unknown fields are essentially all just spacers at this point. We do not know the exact size of any particular unknown for sure. I had just been breaking them down and testing each section 1 by 1. It is hard to know what fields should be int8, in16 or int32 or maybe char.

I don't know how much of a pain it would be, but possibly if Derision has the time, maybe he could go through and break down the unknown parts of the structure into the proper sized fields. I am pretty sure he can do this just by reading the ASM code. Not that I want to give him more work, or offer him up to do something for us, but I think he is the only one in EQEmu who knows enough to actually do it. I may be wrong, but this step might not be too bad to do by just going down the ASM code.

Then, once the fields are broken down into the proper sizes and places, we can use this testing code to isolate what each field actually does. With the fields all in the right place, this step should be able to be done by just about anyone. I bet we can find new things that we didn't even know existed by doing this lol. Maybe we need to make a list of exactly what we are missing and also new stuff that we might expect to find. That way, we know exactly what to look for when testing this stuff so we do the appropriate test for each change we try.

Without having the proper field sizes and placement, the only other way I can think to do this properly would be to break down each unknown into separate int8s. That would mean a few hundred unknown int8 fields. It would also mean adjusting the case switching on that test code, but it wouldn't be too rough to do if necessary.

[Shendare]

Well, with just poking random 0-15 values into individual unknown bytes one by one over the course of the last hour, I've so far been able to isolate FlyMode.

It's in unknown00771[1], byte offset 174. So, if you use the lastname code *k1=2 or *X174=2 the NPC will have levitation FlyMode on.

I'm still poking away. I'm mostly through unknown0079[] so far, which probably puts me 2/3 through the unknowns!

[Shendare]

Woohoo!

hairstyle = unknown01082[4], Offset 533
haircolor = unknown01082[5], Offset 534
flymode = unknown00771[1], Offset 174

[Shendare]

Fixing hairstyle and haircolor in the struct definition and adding the eq->hairstyle = emu->hairstyle entries for the two into the .cpp code fixes NPCs, but turns my PC bald. Incorrect field location in the player profile?

[trevius]

It may depend on what exactly you are filling into those unknowns. Probably best to convert each one into separate int8s and see what happens. It could be that they are int32 and setting more than 1 of the bytes is making a number that is out of the range of the hair options, setting them to default of being bald. Purely guess at this point until I can do testing later.

Also, for your testing, I didn't think about it before, but it would have been best if you were using a Drakkin (race 522) for finding spawn struct stuff. I am sure they have a decent piece of the struct just for them and the new heritage settings they have.

[Shendare]

IsStatue = unknown0006, Offset 6 (Some models have a "Statue" animation that makes the NPC larger and striking a pose.)

DrakkinHeritage = unknown0011[3], Offset 14 (Body coloring, available colors at character creation dependent on player class)

DrakkinWhite = unknown0011[4], Offset 15 (Nonzero yields a white haired, white tattooed, white face-spotted Drakkin)

DrakkinWhite2 = unknown0011[5], Offset 16 (Acts like DrakkinWhite for all values 0-15 except 0, 2, 8, and 10)

NOTE: It's possible DrakkinWhite and DrakkinWhite2 somehow interact with DrakkinHeritage, and it's possible there's some 16-bit workings going on in the field causing the weirdness. Dunno. I can only test push 8-bit values at the moment.

DrakkinTattoo = unknown0079[0], Offset 369

Targetable11 = unknown0156[3], Offset 625 (If this field is set to 11, the NPC is untargetable. Weird, I know. Totally found it by accident!)

I'm still looking for beard color and Drakkin facial dots.

Also, I found the bug with my bald player character. This block of code in mob.cpp at line # 724 was messing things up. It assumes a zero value for the appearance fields is invalid, and sets such zero fields to 0xFF instead.

	ns->spawn.haircolor = haircolor ? haircolor : 0xFF;
	ns->spawn.beardcolor = beardcolor ? beardcolor : 0xFF;
	ns->spawn.eyecolor1 = eyecolor1 ? eyecolor1 : 0xFF;
	ns->spawn.eyecolor2 = eyecolor2 ? eyecolor2 : 0xFF;
	ns->spawn.hairstyle = hairstyle ? hairstyle : 0xFF;
	ns->spawn.face = luclinface;
	ns->spawn.beard = beard ? beard : 0xFF;

The problem is, zero is perfectly valid. It's generally the first available appearance option for each field! Zero is the matted-hair for high elves, the dark brown hair color for races that can use it, the moustache face for humans, etc. Setting them to 255 actually SET them to an invalid value, making anyone with a zero value for the fields bald or incorrectly colored.

I simply commented out the 0xFF stuff, and things started working normally again.

	ns->spawn.haircolor = haircolor; // ? haircolor : 0xFF;
	ns->spawn.beardcolor = beardcolor; // ? beardcolor : 0xFF;
	ns->spawn.eyecolor1 = eyecolor1; // ? eyecolor1 : 0xFF;
	ns->spawn.eyecolor2 = eyecolor2; // ? eyecolor2 : 0xFF;
	ns->spawn.hairstyle = hairstyle; // ? hairstyle : 0xFF;
	ns->spawn.face = luclinface;
	ns->spawn.beard = beard; // ? beard : 0xFF;

Maybe they were put in place to correct a render problem in a pre-SoF client. I tried messing around with it for a couple of minutes with the Titanium client, but I couldn't even get beards to load with Titanium to test with. Hair color and hair style seemed to work properly with the 0 values, so the 0xFF stuff might have been implemented for a pre-Titanium client, though that would mean this bug would have been around for a long time.

[trevius]

Originally Posted by Shendare

Targetable11 = unknown0156[3], Offset 625 (If this field is set to 11, the NPC is untargetable. Weird, I know. Totally found it by accident!)

That is interesting, because body type 11 is untargetable. So, my guess is that our current field for bodytype is probably incorrect. I got most of the fields originally from SEQ and they really only care about a few key parts of that structure. This probably explains why certain NPCs show up on SoF that shouldn't. Or at least partially explains that possibly.

Originally Posted by Shendare

Also, I found the bug with my bald player character. This block of code in mob.cpp at line # 724 was messing things up. It assumes a zero value for the appearance fields is invalid, and sets such zero fields to 0xFF instead.

	ns->spawn.haircolor = haircolor ? haircolor : 0xFF;
	ns->spawn.beardcolor = beardcolor ? beardcolor : 0xFF;
	ns->spawn.eyecolor1 = eyecolor1 ? eyecolor1 : 0xFF;
	ns->spawn.eyecolor2 = eyecolor2 ? eyecolor2 : 0xFF;
	ns->spawn.hairstyle = hairstyle ? hairstyle : 0xFF;
	ns->spawn.face = luclinface;
	ns->spawn.beard = beard ? beard : 0xFF;

The problem is, zero is perfectly valid. It's generally the first available appearance option for each field! Zero is the matted-hair for high elves, the dark brown hair color for races that can use it, the moustache face for humans, etc. Setting them to 255 actually SET them to an invalid value, making anyone with a zero value for the fields bald or incorrectly colored.

I simply commented out the 0xFF stuff, and things started working normally again.

	ns->spawn.haircolor = haircolor; // ? haircolor : 0xFF;
	ns->spawn.beardcolor = beardcolor; // ? beardcolor : 0xFF;
	ns->spawn.eyecolor1 = eyecolor1; // ? eyecolor1 : 0xFF;
	ns->spawn.eyecolor2 = eyecolor2; // ? eyecolor2 : 0xFF;
	ns->spawn.hairstyle = hairstyle; // ? hairstyle : 0xFF;
	ns->spawn.face = luclinface;
	ns->spawn.beard = beard; // ? beard : 0xFF;

Maybe they were put in place to correct a render problem in a pre-SoF client. I tried messing around with it for a couple of minutes with the Titanium client, but I couldn't even get beards to load with Titanium to test with. Hair color and hair style seemed to work properly with the 0 values, so the 0xFF stuff might have been implemented for a pre-Titanium client, though that would mean this bug would have been around for a long time.

This is an interesting find and might be a great breakthrough for handling face settings. Definitely worth looking into.

I am going to have to give this code a try. It beats the crap out of changing whole chunks of the struct to a certain value, compiling, starting the server, logging in and hopefully seeing a difference, and then starting the whole process over again lol.