Ahh, thanks, I was thinking that equip_chest2 was probably texture. I will try to get that going tonight too if I can find it.

And yeah, I figure that switching the item structure from being serialized as a long string into being serialized as a binary structure is very simple stuff. But don't forget that I am still quite a noob and without a good example to work from for something that big, I just don't know what to do. That is why I was asking for a little help with it. I posted the structure that it should be above. Lots of those will just basically be unknowns until we can build the rest of the stuff to pull those fields from the database. Adding that other stuff in won't be a problem once the basics are working. I just don't know how to make it do that serialize in binary instead of a string! If you could do that for me, it would help in a huge way!

Note that right now, the clientinventory encode is set to just send an empty item packet until the real item structure is in place.

Anyway, like I said before, I figured changing items from a string to binary would be simple, I just don't know how to do it. Does that scare you people that just spent 6$ on SoF? :D

Items are a really huge factor holding back SoF from being done. KLS, if it doesn't take much time, do you think you could possibly make the change in the SoF patch files so it sends it as binary instead? I think once I see how you write it, I should be able to move stuff around if needed to get it functioning. I don't think you have a copy of SoF yet, so you probably can't test it. Don't worry about messing up the SoF patch file and updating the SVN with them as long as it doesn't break the compile.

I think I could figure out how to do it, but each time I try, I wind up getting stuck and having to revert back to the SVN revision.

I can write something up, I don't have the client... 6 dollars... >< so whether or not it works is anyone's guess.

One thing to remember when working with the patches is it doesn't matter what form the data coming in is in, all that matters is what we send. Right now the data comes in as an internal structure and goes out as a string, it shouldn't be *too* hard to go from internal structure to eq structure.

Well, the main thing I couldn't figure out is how to write a different version of the structure for items. In SoF, many of the fields are changed from int8 to int32 when looking at the structure in item_structs.h and I don't know if just putting a struct for it in SoF_structs.h would work with that like all other normal structs. I don't fully understand why it gets it's own struct file as apposed to being with all of the other structs.

The other important thing to keep in mind when writing it is that all strings like name, lore, charmfile and such need to be variable length. Basically, it sends the string and then it sends 00 after the string to signify the end of the string. Other than that, it should all just be normal binary. Would that mean instead of using "char" for the string fields, we would use "varchar", or would it be more like "char field[1];" to make them variable length? I don't know how to make them variable length...

If you do get something written up for it, KLS, I would really appreciate it!

The goal is to make the new SoF server continue working with titanium I assume?

Yes, it all works perfectly fine together right now and there should be no reason to change that. Since the patch files system were added back when Titanium was added to the emulator, it has always been compatible with both the 6.2 client and Titanium. And now it will be compatible with those 2 as well as with SoF.

BTW, I got the SVN updated this morning with my current SoF patch files and a few more changes. Keep in mind that the SoF_structs.h file is pretty sloppy in a few places that are still being worked on heavily, but once things are finalized, I will clean it all up.

Most importantly, I was able to get the clientupdate stuff almost completely worked out last night! I think spawn position updates should be accurate, at least enough to use for now. I know that X, Y, Z and heading at least are all accurate and the delta stuff probably is as well, but I haven't tested that fully yet. For the client position updates that get sent to the server, I have X Y and Heading all in the right spots now, so Z is the last major part to figure out. The deltas and animation will still need to be verified, but they aren't as important.

I also found a few more things in the spawn struct like flymode, LFG flag, hair and a couple more. I haven't narrowed those down to exact positions yet, because they aren't really what I am looking for and they can be added in at any time after the game is playable. I must say that it is pretty cool changing the unknowns and logging in to see what has changed. So far I have found quite a few fields that aren't even known in Titanium, so maybe we can make use of them starting with SoF.

I still wasn't able to figure out how to get #zone working yet. Either the opcode I have for requestclientzone is wrong, or the structure is wrong. I am going to compare it to a log from EQLive from ShowEQ and should be able to find what I need.

Wouldn't happen to have a packet of a server->client item would you?

Databasce Converter
 

Do you need a Database Converter Professional Edition to help you convert svn to peq etc i'll upload it. This is the best i can do at this time to help you out.

Assuming that the packets in SoF are the same as live, or very close, here is one from EQLive:

Wow, I am surprised that it actually posted that whole item packet. That was pretty big lol.

Anyway, here is how I am breaking down a single item from those examples:

And that should all be fairly well explained in the packet structure I posted for it in this thread earlier here:

After reviewing it a bit more, it looks like there was already code to handle the click/proc/worn/focus/spell section properly. And also one for handling the augments section, so those extra structs here are probably not needed, if it is just set to work the same as the current item structure.

Also, I am only pretty sure of the structure up to the end of the click/proc/worn/focus/spell section, so everything after that is just a guess that will probably need to be moved around later after we can test and see what is what. It should be pretty easy to figure out unknown fields just by changing them and seeing what gets changed.

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.

charter name aspected
 

[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

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

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.

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

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