Starting Work on SoF Opcodes/Structs

**trevius** · #1 02-06-2009, 05:40 AM

Well, zoning via normal zone points from one zone to another is working. Any other type of zoning via commands isn't yet, though. It looks like the client is now expecting to get the zonechange structure from commands instead of the requestclientzonechange structure like Titanium uses. Using commands, I get a message that it was unable to find the player name, and requestclientzonechange doesn't send a player name, but zonechange does. I am guessing that the best way to handle this for the / commands usable by GMs would be in the SoF.cpp file by doing an encode on those opcodes. But, for # commands, that is handled by the server and doesn't get an opcode from the client, so I am not sure what the best way to handle those would be yet.

I am going to keep messing with it and see what happens. First off, I will see if I can verify for certain that it is looking for the zonechange struct now. If it is, then we will have to figure out a way for SoF to handle those commands differently. Off the top of my head, the only easy solution I can think of would be to make alternate zone related commands for SoF. I would prefer not to have to do that, but there may not be a choice unless someone can come up with a better way to handle it.

OscarGrouch05 · #2 02-06-2009, 02:18 PM

[Fri Jul 25 2008]00197:Initializing character select UI.
[Fri Jul 25 2008]00198:Resetting game UI.
[Fri Jul 25 2008]00199:Zone Connect -- 0 -- Received MSG_ZONE_ADDRESS
[Fri Jul 25 2008]00200:Zone addr [199.108.3.107:21509] received...
[Fri Jul 25 2008]00201:ZONING
[Fri Jul 25 2008]00202:Networking: Connection Closed [0] with 0 pending bytes.
[Fri Jul 25 2008]00203:Networking: using port [1133].
[Fri Jul 25 2008]00204:Networking: Connection Established [1]
[Fri Jul 25 2008]00205:Connected to 199.108.3.107:21509...

[Fri Jul 25 2008]00206:Zone Connect -- 2 -- Sending MSG_EQ_ADDPLAYER
[Fri Jul 25 2008]00207:Zone Connect -- 3 -- Received MSG_SEND_PC
[Fri Jul 25 2008]00208:Received our Player from zone.
[Fri Jul 25 2008]00209:Received MSG_EQ_ADDPLAYER, Player = *charter name here *, zone = Skyfire Mountains
[Fri Jul 25 2008]00210:MSG_TIME_STAMP received.

[Fri Jul 25 2008]00211:MSG_TIME_STAMP received. (Items inc).

I took out my charter name where you see *Charter name here* is where it goes

**trevius** · #3 02-07-2009, 05:45 AM

LOL, after working on the client update position stuff over and over trying to figure out why what I was seeing wasn't matching up with what I was setting for the packet structure, it looks like I finally got it all working perfectly as far as I can tell. Apparently, the logs from the server can't always be trusted. It was telling me that the client was sending 36 byte packets for clientupdates, but it is actually sending 40. It was also re-arranging all of the blocks in the packet for some reason, which made working out the structure nearly impossible. Luckily, I just tried using the exact structure from ShowEQ around that time and it works flawlessly! I dunno what the logging is doing to cause me all of that trouble, but at least it works now

I am still working on getting zone commands to work. I think I can just redo the requestclientzonechange structure for SoF, but I need to figure out how to get the client's character name in the SoF.cpp encode for it. I have tried a few things, but none of them seem to work yet.

I am also still working on the ground spawn structure, because something is definitely wrong with it. Objects spawn about 100X bigger than they are supposed to. I have tried adjusting all of the unknown fields and none of them are making any difference, so I am guessing the known fields are probably ordered wrong or in the wrong place.

I also still need to narrow down a few more fields in the spawn structure, but that is mostly just cosmetic stuff like armor, tint, texture and size.

Something is still missing from the AA stuff that is keeping them from loading, but I think it should be sending them correctly, so I am guessing it is maybe just the list of AAs that isn't going out properly yet.

Most of the rest of the stuff to work on will probably be best to wait until items are working. I could start working on the action stuff for fighting, but without being able to load items, it will probably just keep causing crashes. Once items are working though, I don't think the action structures will be hard to get going.

The /who all related structures also need work, but I think I can probably figure that out by looking at EQLive packets. I just haven't checked that yet.

**KLS** · #4 02-10-2009, 02:11 AM

This will probably take a while to get working, I'm not sure on the size of the item struct... which will probably take a lot of time in itself. I think I've got the item header right though.

It's very tedious -.-.

janusd · #5 02-10-2009, 08:42 AM

And yet, every time someone makes a post about progress, a hundred thousand voices cry out in bliss and tremors of joy.

leslamarch · #6 02-10-2009, 05:06 PM

Quick question guys,
for the most part is this already enabled? I was going to check this out when I have time, Just was wondering if this is set to go with normal server compile or is something else needed to be defined before compile?

**trevius** · #7 02-10-2009, 07:07 PM

It is disabled on the SVN revisions for now by default. Mainly because we don't want everyone to try using it on public servers and causing zone crashes due to any unknown bugs. Once it is fairly bug free and complete, it will probably be enabled by default.

For now, you just have to edit the /common/patches/patches.cpp and uncomment the #define line at the top to enable SoF. Then compile and it should be enabled.