Starting Work on SoF Opcodes/Structs

[trevius]

Yeah, I am pretty sure that the opcode to send AAs is correct. It could be option 1, but you are probably right that it is something in the player profile. I am going to work back through the PP anyway soon to try to align some of the areas that are harder to confirm. I am going to be using a Live packet as a reference, so it might not be too easy. The only good thing is that the difference from EQLive and SoF is only about 96 bytes in size (live is actually less now, which is rare for structures to shrink). I will just base the changes off of relative fields that we know are correct. Hopefully I can get it more accurately aligned and that may resolve a few issues. It is a big struct, so it may take a while to complete though lol.

[trevius]

Unfortunately, I just had to back out of the fix I put in for Drakkin to be able to use equipment and weapons and gain stats from them. It was working great for SoF, but the fix caused the same problem to start happening in Titanium. So, right now, it seems like only 1 or the other can work. I am sure there is a way to let both work properly, but I just don't know of a good solution right now. If anyone has a suggestion, it would help

Here is the piece of code that needs to be changed to work with both client versions:

/common/item.cpp

bool ItemInst::IsEquipable(int16 race, int16 class_) const
{
	if (!m_item)
		return false;
	
	bool israce = false;
	bool isclass = false;
	
	if (m_item->Slots == 0) {
		return false;
	}
	
	uint32 classes_ = m_item->Classes;
	uint32 races_ = m_item->Races;
	int32 race_ = 0;
	#ifndef PACKETCOLLECTOR
	race_ = GetArrayRace(race);
	#endif

	race_ = (race_==17? 15 : race_); // For SoF this should be: race_ = (race_==18? 16 : race_);
	// @merth: can this be optimized?  i.e., will (race & common->Races) suffice?
	for (int cur_class = 1; cur_class<=PLAYER_CLASS_COUNT; cur_class++) {
		if (classes_ % 2 == 1) {
    		if (cur_class == class_) {
    			isclass = true;
				break;
			}
		}
		classes_ >>= 1;
	}
	for (unsigned int cur_race = 1; cur_race <= PLAYER_RACE_COUNT; cur_race++) {
		
		if (races_ % 2 == 1) {
    		if (cur_race == race_) {
    			israce = true;
				break;
   			}
		}
		races_ >>= 1;
	}
	return (israce && isclass);
}

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