SoF Spawn_Struct Hacking

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

[trevius]

LOL, I got it setup and playing with it now. Just found some weird effect with "i5" as the last name. It creates a rain cloud above the spawn and rains on them for a few seconds. Also, other ones like i10, i11, i2, and more have really cool effects as well. I am guessing you need spell effects on to see these, but they are things I have never seen before :P Not sure exactly what they are for other than maybe having invisible NPCs use them to create visual effects maybe. Definitely loving the new way of handling this testing.

Also, after trying X613=11, I verified that the current setting for bodytype works, but I wonder why they have 2 fields for it, since X625=11 makes them untargetable as well.

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)

Yeah, 14, and 15 definitely seem to be an int16 for heritage. Not sure why 16 effects it too, but maybe it is an int32 and only accept certain ranges.

Found Drakkin face spikes are 882 and they range from 0 to 7. Also note that Heritage ranges from 0 to 6.

770 appears to be an int32 that if you set anything in (other than 0), the NPC will not be visible. It will still be targetable with /target, but that seems to be the only way.

740 puts an exclamation point in front of the name of the NPC.

656 is invisible/sneaking

[Shendare]

Yeah, I was messing with 770 a little and found that my client crashed if I attacked the NPC while it was invisible.

Good find on the special i-codes. I totally forgot I'd turned off spell effects for something or other. I totally missed them because of that!

The only thing I haven't found that I've been looking for is beard color, and I'm kicking myself for not having the foresight to make sure my test NPCs had beards while I was looking for hairstyle and haircolor. Bonehead.

I also figured out that some races (high elves for one) get their facial hair not from the beard field, but from a tens-digit offset to the face field. This also appears to be the way Barbarians get their woads.

Checks for these should probably be put into the OP_ZoneSpawns area there to check the race and (if necessary) dynamically adjust the eq->face field by (beard * 10) for beard-face races. I'm guessing we'll have to add some fields to npc_types to allow for face decorations like woads (if race == Barb, face += face_decoration*10) and Drakkin spikes, as well as Drakkin tattoos and heritage.

[Shendare]

Originally Posted by trevius

...
740 puts an exclamation point in front of the name of the NPC.
...

Oh my god, I think you found Doug! I remember from years and years ago after a patch, people were finding unresponsive naked human male models in random places in the game with only an exclamation point as their name. The EQ team responded to the community's questions with the response that these were test characters that aren't normally visible, and they'd figure out what broke in the patch that allowed people to see them. The team revealed the little tidbit that they had taken to calling these default human models "Doug", so whenever someone in the game found an unresponsive naked human male NPC that probably shouldn't be there (or should look different), they reported a "Doug".

I wonder if offset 740 marks the character as an EQ dev test character, and the original Doug didn't actually have "!" as its name, but had a blank name with the equivalent of Flag 740 set. That just blows my mind, and totally brings back some old EQ nostalgia. LOL.

- Shendare

[trevius]

Yeah, woads being set by factor of 10 on the face setting is known and in the wiki I believe. Shouldn't be too hard to find beard color and such once test is done with an NPC that has a beard set on them since beard is already identified.

I was thinking about the storm cloud that spawns from i5 and I actually recall something in either BoT or PoStorms about storm clouds spawning over your head and you have to move or something or something bad happens. Not too clear on the details, but it occurred to me that this is probably a case of when those effects are used.

I bet we could apply your same code to figure out more structure related stuff. Like, we could modify it for the player profile by using something that is easily changeable like currency. Just have it so that if the character has 1337 copper on their character, it will go into test mode. Then, use the plat and gold on that character to set the offset (number of plat) and what to set that offset to (number of gold). It would require zoning each time to test the changes, but it is at least a possible option to consider if we need it. Most of the player profile should be pretty good already, but if we still need to find anything in it, this would probably work.

One thing we need to get working better cosmetically is the character select screen. Unfortunately I think the client limits names during creation to only include letters. So either we would need to use letters and convert them or maybe use stats, but stats would probably be even trickier. Maybe for testing, the first 3 letters could be Z (Zzz) to designate that it is a test, and the 4th letter could be the field in the struct and the 5th would be the value to set it at. This might get a bit confusing, but the char select struct isn't overly large so it shouldn't be too much work to get it all figured out. Can't really set offsets since it is a variable length structure. I think the struct is already pretty close, so maybe finding what is throwing it off would make an easy fix to align everything back up again. There are only a few unknown fields in that struct, so I am sure those are Drakkin related, or at least most of them probably are.

Maybe for char select, we could use 1337 speak lettering in place of numbers to make it easier to set.

0 = o (O)
1 = i (I)
2 = z (Z)
3 = e (E)
4 = a (A)
5 = s (S)
6 = g (G)
7 = t (T)
8 = b (B)
9 = q (Q)

So, if you wanted to set field "a" (level) to 25, you would name the character "Zzzazs". Or if you wanted to set field "b" (haircolor) to 10, you would name the character Zzzbio.

This isn't quite as critical as the spawn struct, but everything that gets fixed makes SoF that much closer to being fully completed

[Shendare]

Sounds interesting! I'm all for getting SoF working better.

I did notice I left a quickie hack in the code that should be cleaned up.

This line...

  size_t len = strlen(emu->lastName);

...should be moved up to this block, which should be changed to refer to it...

  char code = emu->lastName[1];

+ size_t len = strlen(emu->lastName);
- char* sep = (char*)memchr(&emu->lastName[2], '=', 10);
+ char* sep = (char*)memchr(&emu->lastName[2], '=', len - 2);

  uint32 ofs;

This prevents reading beyond the end of lastName in case it's fewer than 10 characters including the null.

[trevius]

I finally identified beard color as offset 373. Got all of the new fields in and adjusted the struct to have the proper offset labels as well as correctly renamed all of the unknowns. Seems to work perfectly for NPCs now. I also added in your change to mob.cpp for facial features, but that might require further testing to verify if it is a good change or not (though it makes sense to me). And, I added in your testing code in place of the sloppy hack I had commented out before lol. It is commented out, but I figure it might be useful to others doing struct work, so it may be a good idea to keep it in there as commented out. I put this up on the SVN on R501 and gave you (shendare) credit for it since you did most of it.

I think that pretty much finalizes the spawn struct, or at least very close now. Still need to figure out a few things for players, but that shouldn't be too hard I think. I put temp hacks in for the drakkin extra features so they get set in the encode to whatever face is set to. At least this will let some variety into drakkin NPCs (and PCs for now as well).

[Shendare]

I'm glad to see that BeardColor gets applied to the face-based facial hair as well as the beard field mesh facial hair.

I dinked around a little with player appearance as well, but found that I had to modify some things. SoF's FaceChange_Struct is 24 bytes now instead of 7, assumedly to account for Tattoo, DrakkinFaceSpikes, and possibly DrakkinHeritage (though that's read-only in face changes). The rest must be reserved space.

I also noticed a block in Client::Handle_OP_FaceChange (or whatever it was called) that did something similar to the 0xFF problem above, except this time it's changing zero values to 99. That'll have to be taken out to properly handle face changes as well.

Then it's just a matter of making sure things are applied in PlayerProfile properly.