I started working on OP_Consume the other night (otherwise, client freezes when you right-click on food), but since I haven't really worked with the encoding/decoding of packets much, I'm not sure what we need to do in SoF_ops.h & SoF.cpp, but here's the new struct:

That's specifically from right-clicking though. Here are some captures from the log (after adding a hex output to client_packet.cpp):
If someone wants to finish it off before I have a chance to learn it, feel free.

As far as the items issue, 32768 is for Shrouds in Titanium. Here's an excerpt from my PHP editor (that I haven't worked on in forever):
items/index.php
includes/constants.php
As a matter of fact, it looks like this actually got buried in the Wiki:
So it sounds like we may need to convert the races in Titanium & 6.2 to delete that bit for the Drakken, then everything else should be fine.

Yeah, you would need to copy the spells_us.txt file from SoF into your server directory and replace the one from Titanium (maybe rename the titanium one first just to be safe). You don't need the spells_en.txt file in the server directory for anything. Another option would be to use the new feature that lets you load the spells file directly into your database. As far as I can tell, the Titanium and SoF spell files seem to line up very well, so there shouldn't be any expected issues by using the SoF file for Titanium users. Each client should work fine with their default spell file. I don't see a reason to wait to do this, but I would definitely keep an eye out for reports of issues with spells. If you want to be absolutely sure you won't have any issues with Titanium users, you can just open both the Titanium and SoF spell files and then scroll to the bottom of the Titanium file. Look at the last spell ID in the Titanium file and then find that same one in SoF. Then, just copy all spells after that ID from the SoF file into the Titanium one and then you should have 0 chance of having an issue on Titanium and everything should be functioning for SoF for the most part as well. You would only need to use that customized file on the server, and both clients should work properly with it.

AndMetal, thanks I didn't think about shrouds being a race. I am still not sure of the best way to handle this now either way. I am sure someone will figure it out at some point. Hopefully soon, since it is fairly high priority. At least all other races still work fine for SoF, just not Drakkin.

For the consume structure work you are doing, that is a nice easy one to start off with and learn how this stuff works. Should be very straight forward. I am actually using your consume structure post as an example for a wiki page I just started to help explain Encode and Decode a bit better. Hopefully that wiki page will help others get involved if they want to.

The new wiki page for encode and decode is here:

http://www.eqemulator.net/wiki/wikka...a=EncodeDecode

I still have to do the main part of the guide where it explains what to put in the SoF.cpp file, but that shouldn't be all too bad to at least get the basics. Once it is done, it should show you exactly what to put to get consume to decode properly. I may be able to get the wiki page mostly finished today :)

Alright, so I was able to get Consume working (somewhat), but it doesn't look like we have the correct structure or OpCode for OP_Stamina, which is sent to the client after eating something. Here's the diff for OP_Consume:

Unfortunately, I'm not sure what the best way is to figure out the OpCode/Struct for OP_Stamina... In addition, I'm not sure how exactly I can pull the inventory from here to get the item stored in "slot" & look at the ItemType to see if it is food or drink (cast to Client/Mob/Entity from a packet?). Any thoughts?

I recall most food/drink stuff being in bonuses.cpp, so you might check there.

For stamina, I would need to know exactly what to look for to find it. I know ShowEQ has an opcode listed as Stamina, so I assume it is the same thing. I am not really sure what that even means anymore, since Stamina was replaced by Endurance. Is food supposed to help regain Endurance?

I doubt that structure changes much/often, so we can probable get it from EQLive easily.

Here is an example I have from a Live collect I did recently:

I can easily figure out the SoF Opcode that relates to whatever this actually is (if it isn't actually stamina like it is labeled). With a struct size of 10, it shouldn't be too tough to figure this out.

Without even looking at the struct, this is how I would break it down:
Now, lemme look at the struct that is set in SoF:

So, since the struct is size 8 and the packet in Live is 10, then most likely, we just need to adjust the structure and do an encode.

SoF_structs.h
SoF_ops.h
SoF.cpp
Then try that and see if that seems to work. It may be that the last 2 bytes are actually 2 int8s for food/drink hunger/thirst level. I don't know why they would use int32s if the value doesn't exceed 127 as noted in the comments of the struct in Titanium. But, it wouldn't be the first time that things would work that didn't seem to be accurately documented. I think the problem is that often things will change and people don't update the comments, so it is hard to know what to trust sometimes.

Either way, I read through my logs from Live and had quite a few of these stamina packets over the 6 minutes or so that I logged. But, oddly, every packet was exactly the same values as I posted above. It never changed once.

I got doors almost working now. It looks like there are a few more fields in the doors struct and 2 of them have to be set to 1 for the door to be clickable. Now, I am getting the clickdoor opcode when clicking them and also getting the too far away message when clicking at a door from out of range. So, the client is seeing the doors as clickable now at least. I also changed the clickdoor struct slightly, because it seems like doorid is now int8 instead of int32. I haven't tried it yet, but I bet a Titanium client would now actually see a door open when a SoF client clicks on them, even though the SoF client doesn't see them open just yet.

I am pretty sure that the only thing left to do for doors is to adjust the movedoor struct and get the opcode and then they should be fully functional. I imagine that click portals like in PoK probably work already, since they don't need the movedoor packet, but I haven't tested that yet. I will test it out tonight and try to finish doors too so that they work. I haven't updated anything onto the SVN yet, but I will get this added tonight if I can get it working. I will also be adding some more opcodes that one of my players has been helping to find/identify.

Once doors are done, that will leave AAs as the last really major issue that needs to be take care of. Most of the rest of the issues should just be things that need minor adjustments here and there. I have been working on getting AAs to work, but still have had no luck yet. I am 99% sure that the opcodes are correct, because they are really easy to verify in IDA. Also, I know that if you change the AATable packet structure, that it will crash the client if it is too wrong. So, it has to be the right opcode and probably the right structure too. I think we are just missing some new packet that needs to be sent to allow the AAs to list. As far as I can tell, the client isn't even making use of any AAs (no stat bonuses, etc), so it isn't that it is just not listing them in the window, it is more like it is just ignoring them completely.

I went through and re-aligned the player-profile as best as I could and I think it is pretty accurate now. There are only a couple of sections that I am not very sure about. But, since almost everything I can verify already seems to line up, it really narrows down areas that might be a bit wrong. One of those unsure areas is where the AA Array is loaded. From looking at Live, it looks like the AA Array struct is now 12 bytes instead of 8 bytes. I adjusted for that, but it didn't seem to make a difference.

I can't stress enough how nice it would be to have a single packet collect of a character logging into live on 9/7/07 lol. Almost everything is fairly well worked out, but it would be nice to have info to make everything perfectly aligned. Ahh well, we will get it eventually either way I am sure lol.

I still have Titanium - I did order a couple of SoFs, should be in soon, and I'll have that running so I can help you out at least with reports.

For anyone that's interested - SoF Expansion is for sale at Amazon.com , very cheap - the used ones are like 6.00 each. Better grab some while thery're there, cause when trevius finishes this work, you won't find them as easily anymore :).

They are still available brand new from Newegg for $5.99 with free shipping:
http://www.newegg.com/Product/Produc...20of%20faydwer

Just got armor tint from Dyes working lol. I just had to swap the color field to near the end of the packet. I should hopefully have doors opening and portals working later tonight. I will get this new stuff on the SVN before I go to bed along with quite a few new opcode additions that Xinu found.

I couldn't tell from the description, but does that SoF expansion include all the previous expansions like Titanium does?

Yup it includes Everquest Classic and all 14 Expansion packs.

The new fixes have been completed and are now on the SVN. Doors and clickable portals now work. Also, armor tint seems to be working great now. And many new opcodes were added by Xinu to help fill in ones that were missing. I also got another looting related opcode added so now looting seems to be flawless too.

Just to try it, I went ahead and compiled Azone2 and read the instructions on how to use it. It is much easier to use than I expected lol. I didn't think many or maybe any of the new zones would work with it from what I was hearing. So, I copied all of the zone files over for the new zones and tried them 1 by 1 and sure enough, over half of them worked fine! I was able to get .map files created for 45 of the 81 total new zones!

For the other 36 zones, it seems that Azone will need to be updated to work with the newer files. Hopefully that can be done at some point, but at least for now, this should give us plenty to keep people busy and happy for a while :D

Here is the total list that I was able to create .map files for:

It is about a 50/50 split on the ones I liked the most. Some really good ones are still not working with Azone yet unfortunately. But at least there are plenty of nice ones that are. I may have missed one or 2 zones too, since I did this kinda fast mostly just to see what kind of ratio we were getting on working zones.

I don't really have a good place to host these for download, but maybe Angelox can put something up once he gets his copy of SoF running. If AX doesn't do it, I am sure someone will. I just assume that he may since he already hosts the other map files we use now.

I don't know what it would take to get Azone2 working with the newest zone types, but maybe I can look at that source at some point and see if I can figure it out. It is probably way over my head, but never hurts to try :P

That's what you said about SoF before you started tinkering with it, and now you've made this whole thing happen. Don't put yourself down, you've learned so much in a very short time, and it shows! Be proud =)

(Done cluttering your thread now, get back to work =P)

/cheerleader off

Well I just got my copy of SoF, so I've been messing around with it some. One thing I've noticed that doesn't seem to have been talked about yet, is there seems to be an issue with the spell file that comes with SoF. Mine is marked 9/27/2007 and contains spells up through ID 15928. Now this isn't really a huge issue that's top priority considering it only effects people 75+, but definitely something that may need to be looked into, that is of course unless I'm doing something completely wrong.

Anyway, I've tried this one 3 caster classes, wizard, cleric, and enchanter. No spells 75-80 will scribe. Everything up to 74 is scribed perfectly fine. So I did some digging around, and the spells are in there and they are in game too, because I can cast them via #cast. I've looked through them and they are listed at their particular class at 75 too, so it's not that they are disabled.

So I also pulled up alla and looked at what spells these classes got at 80, and did a search for those spells and they weren't found. For example, the spell Hand of Temerity, which is the upgrade to Tenacity is not listed. However, for IDs 14282-14284 Hand of Tenacity shows up again from its original 9809-9811 place. Now the spell 14282 increases hp by more than 9809 like it is supposed to be Temerity but the name just hasn't been changed. The only thing I noticed is that the numbers don't match up. Temerity only raises hp by 2400ish, and this spell at 14282 is raising it by 2600ish. That's the base rank. I hope that made sense.

All I can think of is that this was the spell file initially released with SoF, but there was a patch on launch day that cleaned it up, but I have no idea. Then again I may have some settings wrong somewhere, or something could be off, who knows. That's the file that was in my SoF install so that's what I have to go by. I did try to use live's file just to compare IDs and such but it crashes the game if I try to load in.

Anyway if anybody else noticed this it might be worth looking into at some point, obviously since it only effects 75+ it's not a huge priority, but if I am just doing something wrong someone let me know. =p