EQEmulator Forums - Starting Work on SoF Opcodes/Structs

EQEmulator Forums (https://www.eqemulator.org/forums/index.php)

- Development::Development (https://www.eqemulator.org/forums/forumdisplay.php?f=590)

- - Starting Work on SoF Opcodes/Structs (https://www.eqemulator.org/forums/showthread.php?t=26939)

Excellent work Trevius!

(I know you don't want your thread cluttered up, so feel free to delete this post :) ).

LOL, Thanks Derision! No worries about the clutter. After all of the hours it took to get past that part, I am glad to see a reply :)

I am still working on figuring out some of the unknown opcodes I am getting from the client atm. I may be able to have something up tomorrow night.

Quote:

Originally Posted by trevius (Post 163189)

I forgot we had message boards. I admit it.

you are a god, keep it up. If I was any good with graphic design i'd photoshop your avatar onto Jesus.

k, maybe not THAT far.

but good job!

WAY TO GO!

Well done Trev, that is so exciting!

All I can think of is this.....

"I think and think for months and years. Ninety-nine times, the conclusion is false. The hundredth time I am right. "
~ Albert Einstein

Way to go and a big round of applause 8-)

Just as an update, I wanted to let you guys know that I am still working some stuff out before updating it to the SVN. So far, all I can do is log in. After that, my character is just hovering above the ground and cannot move at all. I do see spawns, but they are partially below ground. I was able to get the AA structure aligned well enough that it will load even with sending the AA table. But, for some reason, it doesn't show any AAs in the actual AA window yet.

Before I release it for people to start helping with and playing around with, I would like to get it so the character can at least walk around. So, that is my main focus. Other than that, I have been working on cleaning up and aligning some of the other packet structures so that things work properly.

My other priority is figuring out what a certain opcode that the client is sending me is. For some reason, it is sending 0x7580 to the server about 10X or more per second. I have no clue what the opcode is, but I am hoping that it is just some kind of error from the client that will be fixed by some of the other structure work I am doing. My guess is that it is some kind of underworld message, because the client probably thinks it is under the world.

The last thing I want to do before releasing it is to get the files separated into their own SoF files instead of using the Anniversary files. Then, I want to clean them up a bit so they aren't so sloppy.

So, it might be a few more days before I have anything on the SVN. But, I kinda doubt anyone else will be helping much with it yet at this point anyway. So, it doesn't really matter much when I release it, unless it is fully playable.

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.

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 :)

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.

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.

would actualy be nice to have eq2 style local respawn spots

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.

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.

Code:

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.

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

I accidentally a SoF is this bad?

http://i43.tinypic.com/1zb857n.jpg

fueling the war effort.