Starting Work on SoF Opcodes/Structs

[cubber]

I take it we need to copy the 2 spells_ text files from the SoF client and replace the old titanium ones with them in order to use the new spells from the new expansions?

Will the new files be compatable with old clients? If so is there any harm in making the switch now, or should I wait?

[AndMetal]

I started working on OP_Consume the other night (otherwise, client freezes when you right-click on food), but since I haven't really worked with the encoding/decoding of packets much, I'm not sure what we need to do in SoF_ops.h & SoF.cpp, but here's the new struct:

struct Consume_Struct
{
/*0000*/ int32 slot;
/*0004*/ int32 unknown4; // usually 0x0, but also saw 0x43
};

That's specifically from right-clicking though. Here are some captures from the log (after adding a hex output to client_packet.cpp):

Right-clicked food (Bread Crumbs*) from slot 24
3652 [02.09. - 02:28:02] [NET__ERROR] OP size error: OP_Consume expected:16 got:8
3652 [02.09. - 02:28:02] [NET__ERROR] 0000: 18 00 00 00 43 00 00 00 -                          | ....C...

Right-clicked drink (Skin of Milk) from slot 23
3652 [02.09. - 02:31:28] [NET__ERROR] OP size error: OP_Consume expected:16 got:8
3652 [02.09. - 02:31:28] [NET__ERROR] 0000: 17 00 00 00 00 00 00 00 -                          | ........

Right-clicked food (Misty Thicket Picnic [9662]) from slot 28
3652 [02.09. - 02:38:09] [NET__ERROR] OP size error: OP_Consume expected:16 got:8
3652 [02.09. - 02:38:09] [NET__ERROR] 0000: 1c 00 00 00 00 00 00 00 -                          | ........

If someone wants to finish it off before I have a chance to learn it, feel free.

As far as the items issue, 32768 is for Shrouds in Titanium. Here's an excerpt from my PHP editor (that I haven't worked on in forever):
items/index.php

        // Class(es)
        echo "Class: ";
        if ($db_row[classes] == 65535) echo "ALL ";
        elseif ($db_row[classes] == 0) echo "NONE ";
        else {foreach ($ClassesShort as $key => $value) if ($db_row[classes] & pow(2, $key - 1)) echo $value . " ";};
        echo "<br>\n";

includes/constants.php

// Race List
$Races = array(
        1 => "HUM",
        2 => "BAR",
        4 => "ERU",
        8 => "ELF",
        16 => "HIE",
        32 => "DEF",
        64 => "HEF",
        128 => "DWF",
        256 => "TRL",
        512 => "OGR",
        1024 => "HFL",
        2048 => "GNM",
        4096 => "IKS",
        8192 => "VAH",
        16384 => "FRG",
        32768 => "Shroud"
);

As a matter of fact, it looks like this actually got buried in the Wiki:

races

* What race or races can use the item. Rememeber to add up the results.
o 0 = None
o 1 = Human
o 2 = Barbarian
o 4 = Erudite
o 8 = ELF
o 16 = HIE
o 32 = Dark Elf
o 64 = HEF
o 128 = Dwarf
o 256 = Troll
o 512 = Ogre
o 1024 = HFL
o 2048 = Gnome
o 4096 = Iksar
o 8192 = Vah Shir
o 16384 = Froglok
o 32768 = Shroud
* These are combined values, but with special meaning:
o 32767 = Any/All
o 65535 = Usually a container

So it sounds like we may need to convert the races in Titanium & 6.2 to delete that bit for the Drakken, then everything else should be fine.

[trevius]

Originally Posted by cubber

I take it we need to copy the 2 spells_ text files from the SoF client and replace the old titanium ones with them in order to use the new spells from the new expansions?

Will the new files be compatable with old clients? If so is there any harm in making the switch now, or should I wait?

Yeah, you would need to copy the spells_us.txt file from SoF into your server directory and replace the one from Titanium (maybe rename the titanium one first just to be safe). You don't need the spells_en.txt file in the server directory for anything. Another option would be to use the new feature that lets you load the spells file directly into your database. As far as I can tell, the Titanium and SoF spell files seem to line up very well, so there shouldn't be any expected issues by using the SoF file for Titanium users. Each client should work fine with their default spell file. I don't see a reason to wait to do this, but I would definitely keep an eye out for reports of issues with spells. If you want to be absolutely sure you won't have any issues with Titanium users, you can just open both the Titanium and SoF spell files and then scroll to the bottom of the Titanium file. Look at the last spell ID in the Titanium file and then find that same one in SoF. Then, just copy all spells after that ID from the SoF file into the Titanium one and then you should have 0 chance of having an issue on Titanium and everything should be functioning for SoF for the most part as well. You would only need to use that customized file on the server, and both clients should work properly with it.

[trevius]

AndMetal, thanks I didn't think about shrouds being a race. I am still not sure of the best way to handle this now either way. I am sure someone will figure it out at some point. Hopefully soon, since it is fairly high priority. At least all other races still work fine for SoF, just not Drakkin.

For the consume structure work you are doing, that is a nice easy one to start off with and learn how this stuff works. Should be very straight forward. I am actually using your consume structure post as an example for a wiki page I just started to help explain Encode and Decode a bit better. Hopefully that wiki page will help others get involved if they want to.

The new wiki page for encode and decode is here:

http://www.eqemulator.net/wiki/wikka...a=EncodeDecode

I still have to do the main part of the guide where it explains what to put in the SoF.cpp file, but that shouldn't be all too bad to at least get the basics. Once it is done, it should show you exactly what to put to get consume to decode properly. I may be able to get the wiki page mostly finished today

[AndMetal]

Alright, so I was able to get Consume working (somewhat), but it doesn't look like we have the correct structure or OpCode for OP_Stamina, which is sent to the client after eating something. Here's the diff for OP_Consume:

Index: common/patches/SoF.cpp
===================================================================
--- common/patches/SoF.cpp	(revision 343)
+++ common/patches/SoF.cpp	(working copy)
@@ -1273,6 +1273,14 @@
 	FINISH_DIRECT_DECODE();
 }
 
+DECODE(OP_Consume) {
+	DECODE_LENGTH_EXACT(structs::Consume_Struct);
+	SETUP_DIRECT_DECODE(Consume_Struct, structs::Consume_Struct);
+	IN(slot);
+	emu->auto_consumed = 999;	//auto_consumed, e7030000 = 0x37e = 999
+	emu->type = 1;//type, 1 = food, 2 = water
+	FINISH_DIRECT_DECODE();
+}
 
 DECODE(OP_WhoAllRequest) {
 	DECODE_LENGTH_EXACT(structs::Who_All_Struct);
Index: common/patches/SoF_ops.h
===================================================================
--- common/patches/SoF_ops.h	(revision 343)
+++ common/patches/SoF_ops.h	(working copy)
@@ -26,6 +26,7 @@
 E(OP_ExpansionInfo)
 E(OP_LogServer)
 E(OP_Damage)
+//E(OP_Stamina) //not sure we have the right structure 
 //E(OP_ZoneServerReady)
 //E(OP_BazaarSearch)
 //E(OP_Trader)
@@ -43,6 +44,7 @@
 D(OP_ClientUpdate)
 D(OP_MoveItem)
 D(OP_WhoAllRequest)
+D(OP_Consume)
 //D(OP_SendExpZonein) 
 //D(OP_TraderBuy)
 #undef E
Index: common/patches/SoF_structs.h
===================================================================
--- common/patches/SoF_structs.h	(revision 343)
+++ common/patches/SoF_structs.h	(working copy)
@@ -1426,12 +1428,22 @@
 };
 
 struct Consume_Struct
 {
 /*0000*/ int32 slot;
-/*0004*/ int32 auto_consumed; // 0xffffffff when auto eating e7030000 when right click
-/*0008*/ int8  c_unknown1[4];
-/*0012*/ int8  type; // 0x01=Food 0x02=Water
-/*0013*/ int8  unknown13[3];
+/*0004*/ int32 unknown4; // usually 0x0, but also saw 0x43
 };

Unfortunately, I'm not sure what the best way is to figure out the OpCode/Struct for OP_Stamina... In addition, I'm not sure how exactly I can pull the inventory from here to get the item stored in "slot" & look at the ItemType to see if it is food or drink (cast to Client/Mob/Entity from a packet?). Any thoughts?

[trevius]

I recall most food/drink stuff being in bonuses.cpp, so you might check there.

For stamina, I would need to know exactly what to look for to find it. I know ShowEQ has an opcode listed as Stamina, so I assume it is the same thing. I am not really sure what that even means anymore, since Stamina was replaced by Endurance. Is food supposed to help regain Endurance?

I doubt that structure changes much/often, so we can probable get it from EQLive easily.

Here is an example I have from a Live collect I did recently:

Feb 16 2009 04:50:17:123 [Decoded] [Server->Client] [Size: 10]
[OPCode: 0x02d6]
[Name: OP_Stamina][Updated: 10/21/08]
000 | 96 02 00 00 96 02 00 00 3d 55                    | ........=U

I can easily figure out the SoF Opcode that relates to whatever this actually is (if it isn't actually stamina like it is labeled). With a struct size of 10, it shouldn't be too tough to figure this out.

Without even looking at the struct, this is how I would break it down:

96 02 00 00 - int32 
96 02 00 00 - int32 
3d 55 - int16

Now, lemme look at the struct that is set in SoF:

struct Stamina_Struct {
/*00*/ int32 food;                    // (low more hungry 127-0)
/*02*/ int32 water;                   // (low more hungry 127-0)

};

So, since the struct is size 8 and the packet in Live is 10, then most likely, we just need to adjust the structure and do an encode.

SoF_structs.h

struct Stamina_Struct {
/*00*/ int32 food;                     // seen 96 02 00 00 
/*04*/ int32 water;                   // seen 96 02 00 00
/*08*/ int16 unknown08;            // seen 3d 55
};

SoF_ops.h

E(OP_Stamina)

SoF.cpp

ENCODE(OP_Stamina) {
	ENCODE_LENGTH_EXACT(Stamina_Struct);
	SETUP_DIRECT_ENCODE(Stamina_Struct, structs::Stamina_Struct);
		OUT(food);
		OUT(water);
		//eq->unknown08 = 21821;
	FINISH_ENCODE();
}

Then try that and see if that seems to work. It may be that the last 2 bytes are actually 2 int8s for food/drink hunger/thirst level. I don't know why they would use int32s if the value doesn't exceed 127 as noted in the comments of the struct in Titanium. But, it wouldn't be the first time that things would work that didn't seem to be accurately documented. I think the problem is that often things will change and people don't update the comments, so it is hard to know what to trust sometimes.

Either way, I read through my logs from Live and had quite a few of these stamina packets over the 6 minutes or so that I logged. But, oddly, every packet was exactly the same values as I posted above. It never changed once.

[trevius]

I got doors almost working now. It looks like there are a few more fields in the doors struct and 2 of them have to be set to 1 for the door to be clickable. Now, I am getting the clickdoor opcode when clicking them and also getting the too far away message when clicking at a door from out of range. So, the client is seeing the doors as clickable now at least. I also changed the clickdoor struct slightly, because it seems like doorid is now int8 instead of int32. I haven't tried it yet, but I bet a Titanium client would now actually see a door open when a SoF client clicks on them, even though the SoF client doesn't see them open just yet.

I am pretty sure that the only thing left to do for doors is to adjust the movedoor struct and get the opcode and then they should be fully functional. I imagine that click portals like in PoK probably work already, since they don't need the movedoor packet, but I haven't tested that yet. I will test it out tonight and try to finish doors too so that they work. I haven't updated anything onto the SVN yet, but I will get this added tonight if I can get it working. I will also be adding some more opcodes that one of my players has been helping to find/identify.

Once doors are done, that will leave AAs as the last really major issue that needs to be take care of. Most of the rest of the issues should just be things that need minor adjustments here and there. I have been working on getting AAs to work, but still have had no luck yet. I am 99% sure that the opcodes are correct, because they are really easy to verify in IDA. Also, I know that if you change the AATable packet structure, that it will crash the client if it is too wrong. So, it has to be the right opcode and probably the right structure too. I think we are just missing some new packet that needs to be sent to allow the AAs to list. As far as I can tell, the client isn't even making use of any AAs (no stat bonuses, etc), so it isn't that it is just not listing them in the window, it is more like it is just ignoring them completely.

I went through and re-aligned the player-profile as best as I could and I think it is pretty accurate now. There are only a couple of sections that I am not very sure about. But, since almost everything I can verify already seems to line up, it really narrows down areas that might be a bit wrong. One of those unsure areas is where the AA Array is loaded. From looking at Live, it looks like the AA Array struct is now 12 bytes instead of 8 bytes. I adjusted for that, but it didn't seem to make a difference.

I can't stress enough how nice it would be to have a single packet collect of a character logging into live on 9/7/07 lol. Almost everything is fairly well worked out, but it would be nice to have info to make everything perfectly aligned. Ahh well, we will get it eventually either way I am sure lol.

[Angelox]

I still have Titanium - I did order a couple of SoFs, should be in soon, and I'll have that running so I can help you out at least with reports.

For anyone that's interested - SoF Expansion is for sale at Amazon.com , very cheap - the used ones are like 6.00 each. Better grab some while thery're there, cause when trevius finishes this work, you won't find them as easily anymore .