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:
Code:
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:
Code:
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.
Hybrid Mode
