Starting Work on SoF Opcodes/Structs

[jenco420]

They cmpletely revamped the ranking/ names of AA's in SoF as i recall, so that might have something to do with it. Keep up the good work Trev.

[trevius]

I went ahead and stuck what I have so far on the SVN. It is pretty sloppy, but it is the point I am at. I made new SoF patch files for it in the common/patches directory. As I fix more things, I will just continue to add the updates to the SVN when I think something is pretty accurate and complete.

So, if anyone has a copy of SoF and a server, they can now check it out. Though, there isn't much they can do other than log in and float in the air at this point :P Hopefully it won't be long before they can do much more than that

[Yeormom]

You haven't found any snags yet where Sony went in and did major redesign? Sony's normal habbit would suggest they wouldn't redo anything already paid for but I can see a sneak attack on the client combat system or the likes.

[KLS]

There will probably be a big issue with how death is handled since they changed EQ1 to use EQ2esque style release to respawn / wait to get rezed.

[ChaosSlayer]

would actualy be nice to have eq2 style local respawn spots

[trevius]

I am sure there will be some bumps along the way. But some progress is better than nothing and I think we can get most of the basics functioning. Filling in the rest of the details may be a bit tougher, but I don't think anything is impossible just yet

I have already been able to get it to put spawns in the correct places and finally able to move around. I have been experimenting with the newzone struct and that is what has let me start moving finally lol. Unfortunately, after I had it working, I tried adjusting something else and now it doesn't work anymore and I can't seem to get it working again yet. But, I am sure I can get it soon. The newzone struct is probably only off by a very small amount currently. As soon as I have it correct (or at least better), I will get it updated on the SVN. Being able to move is pretty important lol.

Oh, and I dunno about the new death system yet, but I know I already died once. I think it kicked me out of the game when I did though. I don't think it should be too hard to figure out a death window. It should probably work similar to rez or teleports. And, I can use my EQLive account to find exactly what the Live server sends to compare to SoF IDA output and find the opcode.

[Derision]

The code for the 'hover on death' and respawn window is also in the Titanium client as I was playing with it before Christmas, so it's use for SoF client support may also be optional.

In Titanium, OP_RespawnFromHover=0x011d

This is the code I was using to play with it, it is far from usable in it's current form.

When you die, it brings up the respawn box with two hardcoded options, respawn at bind in Pok, or Rez in Great Divide. It doesn't handle the Client reply which is OP_RespawnFromHover, with a uint32, 0 for respawn at bind, or 1 for the Rez option.

Index: common/emu_oplist.h
===================================================================
--- common/emu_oplist.h (revision 283)
+++ common/emu_oplist.h (working copy)
@@ -419,3 +419,4 @@
 N(OP_VoiceMacroOut),
 N(OP_WorldObjectsSent),
 N(OP_BlockedBuffs),
+N(OP_RespawnFromHover),
Index: zone/attack.cpp
===================================================================
--- zone/attack.cpp     (revision 283)
+++ zone/attack.cpp     (working copy)
@@ -1703,7 +1703,7 @@
        SetPet(0);
        SetHorseId(0);
        dead = true;
-       dead_timer.Start(5000, true);
+       dead_timer.Start(300000, true);

        if (other != NULL)
        {
@@ -1908,6 +1908,10 @@
        //

        m_pp.zone_id = m_pp.binds[0].zoneId;
+
+       RespawnWindow();
+       return;
+
        database.MoveCharacterToZone(this->CharacterID(), database.GetZoneName(m_pp.zone_id));

        Save();
Index: zone/client.cpp
===================================================================
--- zone/client.cpp     (revision 283)
+++ zone/client.cpp     (working copy)
@@ -3803,3 +3803,42 @@
        if(!worldserver.SendVoiceMacro(this, Type, Target, MacroNumber, GroupOrRaidID))
                Message(0, "Error: World server disconnected");
 }
+
+
+void Client::RespawnWindow() {
+
+       EQApplicationPacket* outapp = new EQApplicationPacket(OP_RespawnFromHover, 90);
+
+       char* buf = (char *)outapp->pBuffer;
+
+       VARSTRUCT_ENCODE_TYPE(uint32, buf, 0);
+       //VARSTRUCT_ENCODE_TYPE(uint32, buf, 0x000493e0); // Time in milliseconds, this is 300 Seconds
+       VARSTRUCT_ENCODE_TYPE(uint32, buf, 60 * 1000); // Timer ?
+       VARSTRUCT_ENCODE_TYPE(uint32, buf, 0);
+       VARSTRUCT_ENCODE_TYPE(uint32, buf, 2);
+
+       VARSTRUCT_ENCODE_TYPE(uint32, buf, 0x0); // Bind Location ?
+       VARSTRUCT_ENCODE_TYPE(uint32, buf, 0xca); // 202 Poknowledge
+       VARSTRUCT_ENCODE_TYPE(uint32, buf, 0xc3586717); // Unknown
+       VARSTRUCT_ENCODE_TYPE(uint32, buf, 0xc2491983); // Unknown
+       VARSTRUCT_ENCODE_TYPE(uint32, buf, 0xc31ecf78); // Unknown
+       VARSTRUCT_ENCODE_TYPE(uint16, buf, 0);
+       VARSTRUCT_ENCODE_TYPE(uint16, buf, 0x4399);
+       VARSTRUCT_ENCODE_STRING(buf, "Bind Location");
+       //VARSTRUCT_ENCODE_TYPE(uint8, buf, 0);
+
+       VARSTRUCT_ENCODE_TYPE(uint32, buf, 1); // Resurrect ?
+       VARSTRUCT_ENCODE_TYPE(uint32, buf, 0x76);  // 118 Great Divide
+       VARSTRUCT_ENCODE_TYPE(uint32, buf, 0xc54d79cf);
+       VARSTRUCT_ENCODE_TYPE(uint32, buf, 0xc491f1e5);
+       VARSTRUCT_ENCODE_TYPE(uint32, buf, 0xc360df77);
+       VARSTRUCT_ENCODE_TYPE(uint16, buf, 0); // was 0
+       VARSTRUCT_ENCODE_TYPE(uint16, buf, 0);
+       VARSTRUCT_ENCODE_STRING(buf, "Resurrect");
+
+       VARSTRUCT_ENCODE_TYPE(uint8, buf, 1);
+
+       DumpPacket(outapp);
+       QueuePacket(outapp);
+       safe_delete(outapp);
+}
Index: zone/client.h
===================================================================
--- zone/client.h       (revision 283)
+++ zone/client.h       (working copy)
@@ -466,6 +466,7 @@
       void     SacrificeConfirm(Client* caster);
        void    Sacrifice(Client* caster);
        void    GoToDeath();
+       void    RespawnWindow();

        FACTION_VALUE   GetReverseFactionCon(Mob* iOther);
     FACTION_VALUE   GetFactionLevel(int32 char_id, int32 npc_id, int32 p_race, int32 p_class, int32 p_deity, sint32 pFaction, Mob* tnpc);

I didn't progress it any further because I didn't think it was particularly useful.

[AndMetal]

Originally Posted by trevius

I went ahead and stuck what I have so far on the SVN. It is pretty sloppy, but it is the point I am at. I made new SoF patch files for it in the common/patches directory. As I fix more things, I will just continue to add the updates to the SVN when I think something is pretty accurate and complete.

I would actually recommend creating a branch, like I did with loading the spells via the database. That way, you can upload changes that may sorta work so that others can work on it also, but won't affect the trunk ("stable", if you want to call it that). Then, once it's a little more stable/accurate, we can update the branch back into the trunk.

[KLS]

Given that the patch files are pretty much self contained I don't think it really needs a new branch. At least not unless you need to modify core parts of the server to make it all work, in which case yes I'd agree with a SoF branch.

[trevius]

Any modifications of the core files that are needed shouldn't affect the other clients. So far, the only core file changes I have made are to add a new opcode. The only other change I currently have planned for core files is to add a second way to handle the sendexpzonein opcode. Since Titanium sends the same op and expects it right back, the current files work fine for Titanium. They also work for SoF, but the order in the EQ Debugs is a bit off, which might be a concern. So, I plan to copy the function in client_packet.cpp for sendexpzonein and make a different version for SoF. That won't effect how the other clients work, only how it handles SoF logins. Basically, instead of sending the sendexpzonein and getting it back from the client, SoF will send the send the sendexpzonein and send back the new worldobjectssent opcode and handle it by sending that same opcode back to the client again.

Sorry if that sounds a little confusing, but I have it tested on my test box and it works fine and doesn't change anything about how the other clients currently work. At this time, I don't think another branch is needed really. I will just leave it set so you have to uncomment a #define to enable using/testing SoF. So, by default, servers won't be able to use it unless they make that change. This is really only because of the possible crash issues with the SoF client that should probably be avoided for now on non-test servers.

As KLS said, since the patch files are handled in their own separate way, the SVN updates I make for SoF should be ok.

Right now, I am still working on and testing some structure changes to see if I can get more stuff working. I think figuring out the clientupdate structure is an important one to focus on for now. It is a pretty small struct (only 36 in size), but it uses some split signed/unsigned blocks that I don't really understand yet.

Here is the structure of it that I am currently working on:

struct PlayerPositionUpdateClient_Struct_WIP //from Client Packet Breakdown and testing
{
/*0000*/ uint16 spawn_id;			// Player's spawn id - Verified!
/*0002*/ uint16	sequence;			//increments one each packet - Verified!
/*0004*/ float delta_heading;		// Change in heading - Looks Accurate
/*0008*/ float camera_angle;		//unused camera incline angle
/*0012*/ float x_pos;				// x coord - Verified!
/*0016*/ float heading;				//Heading - Looks Accurate
/*0020*/ signed z_pos:10;			//Not Positive
		 signed y_pos:10;			//Not Positive
		 unsigned padding1:12;
/*0024*/ float delta_z;				// Change in z - Looks Accurate
/*0028*/ signed delta_y:20;			//Not Positive
		 unsigned padding2:12;		// ***Placeholder
/*0032*/ signed delta_x:20;			//Not Positive
		 unsigned animation:12;		//Not Positive
/*0036*/ 
};

The actual packet example from that looks like this:

3F 00 24 3B 00 00 00 00 - 00 40 9a 00 d7 15 a8 c0
23 01 00 00 9a e0 a2 c0 - 00 00 00 00 00 00 00 00
00 00 00 00

Really, once the spawn struct and clientupdate structs are worked out, I think that should have most of the struct work done. I am sure there will still be more little things to work out in the other structs, but after that, it will mostly be finding missing opcodes. I still haven't worked out a way to find all missing opcodes just yet, but I have been verifying more new ones almost every day.

If I only had a packet collect from 9/7/2007 or shortly after that, it would make this whole process ALOT easier lol.

[KLS]

That's not really what I was talking about, that all really falls under patch files. For example when we wanted to fix inter-zoning we had to actually modify how you zone as 6.2 sent a different series of packets overall than titanium and so required changes to both the patch files and the zone server. When I talk about "core changes" that's things that aren't contained to a certain version and could potentially affect other versions. =p

[Yeormom]

Just do us a flavor and make SoF commits contain only SoF related changes!