Starting Work on SoF Opcodes/Structs

[trevius]

Originally Posted by KLS

This is going really fast so I apologize, I didn't see either of these issues resolved but maybe I missed it:


equip_chest2 is the field that we fill with "texture".

Also you talked some about serializing items and I'm not sure I understand the problem. We pass an internal serialized item struct to the struct strategy which is:

signed short
ItemInst*

Which we then proceed to turn into a string, turning it into a binary structure instead would be trivial in theory. Is there something I'm missing?

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?

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.

[KLS]

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.

[trevius]

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!

[Yeormom]

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

[trevius]

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.

[trevius]

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.

[KLS]

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