Starting Work on SoF Opcodes/Structs

[Congdar]

I was wondering why you went for the Secrets of Faydwer expansion pack instead of the new Seeds of Destruction that also is a complete all expansions package.

[Andrew80k]

Originally Posted by Congdar

I was wondering why you went for the Secrets of Faydwer expansion pack instead of the new Seeds of Destruction that also is a complete all expansions package.

SoF is currently download only. There is no disk. So you don't have a static client to work from. Working with live is problematic in that it changes so often and it's difficult to keep up. SoF would be a LARGE step toward bringing the emu up to (more) modern EQ. That's quite a bit of additional content and functionality to add. Should keep us busy for a while...

[trevius]

Originally Posted by Congdar

I was wondering why you went for the Secrets of Faydwer expansion pack instead of the new Seeds of Destruction that also is a complete all expansions package.

The reason to use SoF instead of SoD is because as far as I have read and heard, SoD is a digital download only. That means you patch to get it. Basically, it means that we would be trying to keep up with Live in order to use SoD unless we picked a certain patch revision and stuck with it, but that brings up legal issues since there is no way for new players to get an old patch legally. And since SoD is digital download only, then I think it is fairly safe to assume that all future expansions probably will be as well.

It was all of that that pushed me to finally decide that this was our last option as an upgrade and it was time to start working on it :P

Also, another reason is that EQLive apparently does something new with their Login Server and will not connect to the server list of EQEmu anymore. I am sure we could fix that if we had access to the source code of the Login Server, but that isn't much of an option. Plus, chasing live is way more work than anyone around here have time for. Otherwise, it would be a million times easier for me to get the emu working with EQLive than it is to get it working with SoF.

I think SoF is a pretty huge upgrade and will be worth all of the work. We are getting almost 2 years of updates over what Titanium has.

BTW, I am going to try to get the zonechange and requestclientzonechange structs working tonight. That way, at least once you guys get your copies of SoF, you will be able to zone around to check out the new zones, and spawn the new races and fun stuff like that. Those structs may depend on clientpositionupdate being correct though, so no guarantees. I was having a blast last night just checking out the new global races. Having a global dragon race is just awesome, and he looks great too! Oh, and I will update #race and #fixmob to both go up to 600 or whatever I find the max race to be. I know it is well into the 500s now at least.

[KLS]

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

I don't see texture as one of the fields in Titanium

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?

[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?