Starting Work on SoF Opcodes/Structs

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

[trevius]

It seems I am kinda stuck on another thing I can't quite figure out just yet. I may be wrong, but it seems like some of the packet structures change for the client between a couple different structure versions each time I log in. One of the main ones I have notices so far are the clientupdate packets. I don't know why, but it seems like sometimes it swaps the 0 - 15 part of the struct with the 16-31 section. My guess is this is an attempt for SoE to keep us (or the SEQ project) from being able to make structures that work every time. I also see that the newzone struct seems to change as well unless I am just missing something. For some reason, sometimes NPCs show up exactly where they should be and I can move around just fine, but if I /quit out and log in again, they are almost always all gone. No NPCs show up at all. This could also be an issue with the newspawn struct or opcode though, but I just haven't figured it out for sure. It seems that if I restart the server, the first time I log in, I see spawns, but logging in any time after that, I don't.

I got the clientupdate struct partially figured out. I know for sure where a few things are for it like X Position. The weird thing is that even though the hex coming from the client seems to be reversed, the server still reports the correct location for X when I do a #loc. The odd thing is that even if the hex for the section where X should be in the struct is all 0s in the hex, it still reports properly. I don't know why that is yet.

The other odd thing I have noticed is that wearchange struct size seems to change coming from the client as well. The weird part is that if I change the struct to size 19, which I see coming from the client and then restart the server with the new struct size, the client starts sending wearchange as size 9 instead of 19. Then, if I change it back to size 9 and restart the server (after recompiling of course), the client starts sending wearchange as size 19 again. The only thing I can think of is that maybe the logs for the hex isn't showing up properly in the server logs for some reason. Either that, or I need to make separate wearchange structs depending on if it is incoming from the clients, or outgoing from the server.

I still have plenty of other things to work on at this point, so I am definitely not completely stuck. It isn't anywhere near as bad as when I couldn't get all of the way in game for a month, lol. I will keep working on things from different angles and maybe one of the things will fix my other issues. I am hoping that there isn't some new kinda security or encryption happening that I am not aware of. But, as far as I can tell, SEQ doesn't seem to have a problem even with Live and I don't see anything new and special for them to handle it. So, maybe I am just having other unrelated issues :P

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

[trevius]

As if I had time to make any other changes while I am working on SoF. This thing is like a full time job that I don't get paid for lol.

I will probably be doing an SVN commit for SoF tonight. There is alot more progress since the initial release. Spawns now show up (missing names though), you can actually move around in the zone instead of being stuck in place, doors spawn and ground spawns spawn (but still need work), and a few new opcodes are verified.

Items are a big one that needs work, but those shouldn't be too bad once I know how to do the serialization like a structure so it sends it the way it needs to. I think it is almost to the point where other people might actually be able to start helping out on it soon. I am probably going to try to write a beginner's guide in the wiki for packet structures and maybe some opcode stuff.