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

Ok it won't let me edit now, but I went and pulled some IDs from the live spell file.

Hand of Tenacity is still 9809, but Hand of Temerity is 14300. So the numbers did change from SoF assuming that that spell with ID 14282 was supposed to be Hand of Temerity. Granted this is just one spell, and one example, but something does seem to be off.

Yeah, I imagine that they may have been moving spells around still at the point when they made the CD/DVDs for it. Level 80 didn't go live until the day that SoF was actually released, but I am sure they must have been running it on the test/beta server for a while at least.

There is another issue with level 76+ as well that I already mentioned once. For some reason, everything works perfectly for 76+ accept that it sets your hps to 5 max (before gear stats get added). The client is doing this for some reason, but I am unsure why. It is probably something that can be fixed in the Player Profile I hope.

Any issues with spells isn't too big of a deal. Many servers have a max level of 70 as it is, and even if they go up to 75, they will still mostly be covered with spells. But yeah, most likely it sounds like some spell adjustments will probably need to be made. That isn't a show-stopper though, it can be worked-around fairly easily. You can't go by the current EQLive spell file anymore, as they changed it around a TON so that they only give the client spells that they need to know about how to cast, so focuses and worn effects and stuff probably aren't in there anymore. It just reduces their file size to save bandwidth on updates I imagine.

I think I still have a Live spells_us.txt file that has the full 20kish spells in it. I will probably use that to make a new spell file for SoF that will work with Titanium and SoF and include spells up to level 80. Then, if he wanted, Cavedude could add it to PEQ so people could get it. Though, it would mean that someone would have to host the file for download so all SoF members could get it. Though, it will most likely only affect players that are level 75+.

There is another issue too that needs to be dealt with on spells. If a SoF player buffs a Titanium player with a spell ID that the Titanium users doesn't see (over 10k spell ID), it can cause some very buggy situations. My thought for a solution might be to expand on my idea to make quest globals usable for flagging spells. In this case, we could have all SoF users hail a mob in an SoF zone to verify that their account has SoF. Once they do that, it would give them access to be buffed by the level 70+ buffs. Basically, there would be an extra check when buffs are cast to see if the client is flagged for SoF or not. Really, this could be expanded to be used for limiting certain buffs to certain players, but I think getting rid of this possible bug would be a priority use for it. Just an idea anyway.

FYI, for anyone who is getting hacker entries for SoF users reporting that they are using /kill, you can ignore that. Apparently the /kill opcode is set to what should actually be the bankerchange opcode I think. Your players may report getting a reported for hacking message, they can ignore that as well.

I will get this corrected in the next update. Just wanted to make people aware so they don't freak out if they suddenly see a bunch of /kill hack entries in the hackers table :)

Just wanted to post to say that just because there haven't been any updates on the SVN for the past week doesn't mean I have stopped working on SoF. Xinu and I have been working on some of the few main things that are still not functioning properly like grouping and buffs and others. We just don't have anything new that is completely fixed yet, so I don't see a reason to update. Though, we have gotten a couple new encodes/decodes done right I think. Once the fixes are ready, I will get the SVN updated.

Finally got AAs loading into the AA window with the help of Xinu. Turns out the only problem is that the RespondAA packet was sending each AA in the list as 8 bytes, and they are now 12 each, the same as in the Player Profile now. Also, the first int32 in the packet needs to be the total AA spent, but that isn't working correctly just yet. AAs still aren't usable, but this is a big step in the right direction :)

We are getting there one step at a time. :)

Trev, PEQ was having a crash with SoF inventory loading the other day. But the stack trace completely befuddles me. You guys haven't gotten any odd crashes with it have you?

Odd, I haven't had any crashes on Storm Haven that were caused by SoF that I know of. Though, I wouldn't be surprised if there are still some item issues or something that could cause a crash. I will keep an eye out for them. Mostly been on my test server lately though and haven't had much time on the server itself.

There's the trace from a PEQ crash cavedude posted. It seems very odd; almost if the STD library is crashing for some reason. I might rewrite it using void* instead of sstreams. Those were just the lazy way to do things back when I was still trying to create the entire format anyway.

Hmm, I can't make much of that debug. At least I think the item struct is just about as final as it is going to get minus maybe some of the new fields that may need to be moved around at some point after they are actually set to pull from the database so they can be tested.

I was able to correct the issue with some items showing as stacking that shouldn't be. I just set the stacksize field to check the IsStackable bool before setting stacksize higher than 0. It seems in this case that charges and stacksize seem to work interchangeably, but if I am wrong, that may need to be adjusted again. Though, stack sizes and item charges seem to be correct now as far as I can tell. I also identified one of the unknown fields in the serialization that was set to always send ff ff ff ff. According to the EQLive packets I was comparing it to, that is the number of current charges an item has. In most cases, that would be 00 00 00 00 for normal items, and ff ff ff ff for clickies with unlimited charges. But, for potions or clickies with limited charges, that should be where the current charges are set on the item. Unfortunately, since clickies aren't working yet, I can't test to see if that updates properly or not just yet. I think it will, though.

It seems that there may have been some changes to some of the systems that aren't yet fully functional. I am not completely sure yet, but I think group update may have changed how it gets sent. It also seems that for deleting stacked items like food/drink or ammo, there are 2 new packets that are sent that seem to only contain the slot that the item is in. First, the client sends an 8 byte packet that only has the slot ID in it and then the server replies with a 12 byte packet that also only has the slot ID in it. Maybe this is some kind of extra confirmation that the item exists before the server tries to delete it. It could be that opcodes already exist for these 2 packets, but I can't find them if so. I also don't see that same thing happening in Titanium. In Titanium, it either just sends the consume packet or it gets sent the delete packet depending on if it is food/drink or ammo.

So, there may need to be a bit of coding to finish off some of the last issues with SoF, but I don't think it will be all that much. At least we have made some nice progress with Items and AAs over the past couple of days :) Still knocking out 1 issue at a time, but the list is slowly shrinking.

Last night, I was able to get selling to merchants working properly. Just had to adjust for the special slot changes that KLS setup in the item struct and do an encode/decode for selling items.

Also, I got trading working from PC to PC/NPC. Though, it will bug your character if you cancel a trade and require you to zone or relog to fix it.

I also corrected a stacking issue introduced in Revision 376 that was causing stackable items that weren't in a stack to show up as being non-stackable.

I thought I did a commit of those changes last night, but I must have forgotten to. I will get it on the SVN tonight.

I am pretty sure that AAs are close to being usable now too, but I just need to figure out why it isn't using the encode I set on it when it sends the packet. It always wants to send a 1920 byte sized packet, which is the same that it sends in Titanium. I am guessing that it is just not using the structs at all and is being forced to send that way in the AA.cpp file. Maybe I can figure out how to set it to use the structures like all other normal packets do. I am sure that respondAA is why AAs aren't being updated after purchasing them until you zone currently. Once respondAA is working properly, that should fix that problem. I am hoping it will also make AAs actually start working too, and it just might. Other than that, it may be that SendAAStats may be needed for AAs to actually work. More testing needed on that one though.

Big thanks to Xinu for helping me by collecting opcodes and logs from Live to make this work alot easier. He has gotten me everything I asked for so far and does it quicker than I would have :D

The SVN has been updated with the updates in the previous post.

Last night, I was able to get the RespondAA packet working almost 100%. This means that we can now buy AAs and they update in the AA window properly without requiring you to zone. It turned out I had the wrong opcode set for it this whole time. It is really odd, because IDA seemed to be pretty clear on what the right one was for Titanium, SoF and Live. Finally figured it out from a packet collect by Xinu. The RespondAA is now sending the correct packet format and size (3604 bytes) for SoF. The only problem I am still having with it is that RespondAA is now responsible for sending the total Spent AA points for the AA window. I have tried a few ways of getting or counting the spent AAs, but everytime it results in the wrong amount. So, for now, I have it hard set to just display 500 spent. Any ideas of how to get the total AAs spent for this would be appreciated. Here is the current encode I have being done:

I was hoping that getting RespondAA working would make AAs actually start working properly, but it didn't seem to change anything in that aspect. It does seem that some of the ones that have hotkeys for them work for creating hotkeys. Also, most AA effects are handled serverside anyway, so as long as we buy them, they will work. The ones that I am mostly trying to figure out are the innate stats and planar power ones to increase stat caps. None of those seem to be working. Though, I am pretty sure those were changed due to the restructuring of the AA tables for the new window format. For example, many AAs that were improvements to previous AAs were combined into 1 AA that just allowed higher training in the same AA. This includes innate stats, resists, defensive, hps, etc. Because of the big overhaul on SoF AAs, for them to be correct, we will want to make new AA tables specifically for SoF. The best way to populate those tables would be by getting the packet collectors working for Live that can parse AA packets and fill in a table with the info from them. Then, just log in 1 of each class and collect them all and fill in the entire AA table(s) that way.

At least for now, AAs should be functional enough to get by with. But, I think this is still a fairly high priority. Some will work, but a fairly large amount of them won't until new tables are created.

If I can get the Total AAs Spent field working properly, I will get this update on the SVN later tonight. Otherwise, I may hold-off until it is working to get the correct AA Spent Total.

Just don't break AAs for other clients =p

I think everything would pretty much have to be done directly from the SoF patch files, so I don't think that would have a chance to break anything (I hope) for other clients. Though, I really have no idea how I would handle pulling all new AA table information into the SoF.cpp properly to use for an encode. Someone with more database/code experience might have to help with that one. I can handle getting most opcodes, encodes/decodes and packet structures fixed, but I am not so great at coding/database stuff just yet lol.

It may just be that the increasestats_struct isn't setup correctly. Though, I am not exactly sure what that struct is for, but I would guess that it could be related to increasing stats from AA purchases.

And I haven't broken anything for other clients that I didn't correct almost immediately. At least I as far as I am aware of! :P

The list of what needs to be fixed in SoF is growing smaller daily :) Last night, I got the NPC/PC trading bug fixed from when the window is closed as well as the tradeskill container bug when the window is closed. Live sends 2 new opcodes when those windows are closed and Titanium doesn't send them. I had to add 2 new opcodes for this to work. I should probably have this updated on the SVN later tonight.

I also got food consumption working and right click items are almost working. There are some new opcodes being used on Live for when an item is right clicked to be used. I haven't figured out exactly what is being sent in all cases, but in most cases, the client is just sending the slot that the item is in and then the server replies with that same slot. It also sends the entity ID of the client's current target. I assume this is some kind of verification that the item exists or something. I added 2 new opcodes for this as well and some handling for it. That got food/drink consumption working, but item right click effects still aren't actually casting their effects yet. It did stop the client from being bugged when trying to use right click effects though. From Live, it seems that these new item verification packets actually trigger the server to cast the effect. In Titanium, right clicking an item is just like casting a spell. The client sends the castspell packet and the server handles it from that point. Since it seems like SoF uses the new way from Live, it sounds like we will have to set the item verification (that is what I am calling it for now anyway) handling to cast the spells. I don't think that should be too hard, but I am open to any code suggestions :)

I also think there may need to be something done to stop right clickable items with recast delays from showing up as grey. I am sure there is either some new opcode that is supposed to tell the item how long the recast countdown is, or the recast delay countdown may be something that goes into one of the unknowns in the item serialization (this is my guess).

The item verification packets seem to be pretty straight forward in most cases. The odd thing is that certain items send "23 fa ff ff" when clicked instead of sending the slot id. I'm not quite sure what that is supposed to be, but it doesn't seem to be anything to do with the slot. I saw that same thing from one of my live packet collects and also on my test server from clicking an item with charges. It will probably take more investigation before I can get clickies all working properly, but at least it is getting closer. I may put the beginning work of these new opcodes and opcode handling on the SVN tonight as well.

Other than AAs, which I think need new AA tables just for SoF and coding to handle that, I think grouping is really the last major thing that needs to be fixed in SoF to have it almost as fully functional as Titanium is. I imagine raids will also need work too, but groups need to be working before we can get to working on raids. Either way, it is almost all done!

trev- Beyond brilliant my friend!

I will order SOF tonight and start playing that.

GeorgeS

Well, I figured out why Drakkin corpses are showing up as Ogres and it also explains why Froglok corpses show up as humans. It is because of the DBPlayerCorpse struct in zonedump.h having race set to int8 instead of int16 or int32. Since Drakkin are race 522 and in hex, that is 20A, the struct can only see the 0A part of that, which is 10 in decimal, and 10 is the race number for Ogres :P I am not sure how to adjust that so that it doesn't mess up people's corpse backup tables. If someone knows how to adjust it, I don't imagine it would be too hard. Here is the struct:

The "int8 race;" needs to be changed to int16. I don't know if anything else would need to be changed though. Maybe some database gurus could chime in on that.

Haha, nice job, then! Not only did you fix something for SoF, but you explained a bug with the Titanium client even =) Yet another issue crossed off the list. Keep it up!

I started working again on getting grouping to work in SoF last night. At first, it was looking like it would be really hard to get it going, because Live seems to handle it completely differently now and it definitely isn't the same way that SoF handles it. It seems like SoF handles grouping more like Titanium does, but the structures that were set weren't right for the group follow packets when joining a group. I was thinking that maybe the group update packet structure had completely changed and was different than both Titanium and Live, which would make it very hard to get it correct for SoF. Luckily, I remembered that last time I tried it, I was able to get an SoF client to group with a Titanium client just fine. That should mean that the Group Update structure from Titanium is just fine for SoF, which means it shouldn't be hard at all to get it working. Right now, I am pretty sure that the issue is with the group follow structures and opcodes. I think I know what needs to be done to get that portion working properly. I will try messing with it more tonight. If I am right, it shouldn't take long at all to get grouping fully functional.

Grouping is one of the last major things that needs to be done for SoF to be fully functional. There will still be plenty of minor to medium issues to work on to finalize it, but it should at least be very playable and a fairly solid replacement for Titanium at that point.

For some of the things that will still need work after that point, I will probably need some help to get them completed. To get AAs fully functional, we will need new AA tables and code to pull that info instead of the current AA table info when loading SoF AAs. That means we will need to get the packet collector tools working that can pull AAs from EQLive and use them to populate new tables. Augments in items don't show up yet either and that will be another thing that needs to get done to finalize everything. Some systems like bazaar trading, mail, chat channels, LDoN adventures, and the task system still need to be added for SoF as I haven't really checked into any of those at all yet. The raid system will have to be checked after grouping is functional. That sounds like alot of stuff, but really most of that isn't what I would consider core systems for normal game play (other than maybe the task and raid systems). Then, it will mostly just be filling in the remaining misc. opcodes that we don't have yet. Many of those opcodes can probably be gotten directly from the client while watching the server logs, and the rest can be gotten from EQLive.

After that, everything that works in Titanium should be fully functional in SoF as well. Then, we could even start working on getting some of the new systems working (whenever time permits). I am sure the new blocked buffs system would be pretty easy to get working. And there are a few others that probably wouldn't be too bad either.

While I have no experience with SQL or Perl and limited knowledge of databases in general. I will gladly help farm data from live server if someone would tell me how to do so and how to go about collecting the needed information. If its any help I do have some experience with C99 and VB as well as tons of experience with number systems: Binary, BCD, Hex, Octal and so fourth.

I no longer play on live server but my account will be active for three more months so I can log in at will and leave toons up for days on end if needed.
Just let me know if anyone wants my assistance and what I can do to help.

As I thought, it turned out that the only thing stopping groups between SoF clients was the OP_GroupFollow packet. It took a bit of research and messing around, but I got groups working smoothly now as far as I can tell. I will get the SVN updated with the fix for it later tonight along with a ton of Opcodes that Xinu had added to our spreadsheet that I just hadn't seen until now :)

blackdragonsdg,
Thanks for the offer. Right now there isn't much we need collecting for just yet, but once the packet collector tools are working for EQLive again, then you are more than welcome to collect your head off :D For SoF work; Xinu has been getting any collect I could possibly need and is really good at doing it. And anything he hasn't gotten for me, I can still get for myself pretty easily.

I just got SOF from Amazon, fantastic deal, thanks for the tip!

Not to derail the thread but I did have a quick question. Newegg has SoF for $4.99. I purchased a couple but it doesn't appear that they have every expansion up to SoF.

Are there two different offerings?

This supposedly includes all expansions up through SoF.

I got mine from Newegg and it has all of them up through SoF.

It seems I was wrong doh!, and I didn't get it from Amazon, my wife ordered it from NewEgg for 4.99

The box says: Includes Everquest Classic and all Expansions!
Comes on 2 DVD's. Thanks again trevius for the tip.

Bring on the OpCodes and Structs.

Yep
 

This was just user head space on my part. Newegg doesn't/didn't appear to mention it had them all.

I gave the boxes a quick look over and failed to see the "includes classic and all expansions" over the title.

At any rate, the $4.99 from Newegg is indeed everything.

Yeah, SoF includes all previous expansions. It is a hard deal to beat for $4.99!

SoF is almost completely done for the emu now. There are still a couple of non-essential systems that need to get worked on, and quite a few tweaks that are needed. For the most part, it should be very playable now and I think most of the crash bugs should be corrected too. So, it should be ok for other servers to allow their players to start using it.

I will need help finding and tracking down new bugs or issues with it, but the best way to do that is for people to report them as they see them. SoF has been enabled on Storm Haven for quite a while now. The reports I have had from our players have helped quite a bit. I am sure there are harder to find issues that will just take more exposure to more players to find them. If anyone does find a bug with it that isn't listed in the bugs post, please post it in a reply to that thread. Here is the SoF Bug Tracking thread:

http://www.eqemulator.net/forums/showthread.php?t=27600

I am still working on resolving the known issues on a daily basis, but hopefully it will be complete enough soon that I won't have to do that anymore. There aren't many issues left to work on to get it up-to-speed with the playability of Titanium. Only a couple of major issues still exists (AAs and Augments), and the rest are not as important. Shouldn't be much longer.

Unless you wanna try a crack at AAs it's probably a bit off for me, I'm kinda behind on everything as it is. In theory it's not *too* hard the empty bits at the end of an item serialization are actually null terminators for augments and I think evolving stuff.

You mean to try a crack at Augments, not AAs, right? AAs are actually in and mostly working I think. To get AAs working 100% for SoF, we will definitely need new AA tables directly from EQLive. If I have to, I will manually parse out all of that info for at least most of the general AAs. But, I am hoping that at some point we can get the EQ Packet Collecting tools working to do all of that for us. Then, it will just mean that on the encode, we have to set it to pull the AAs from the new SoF AA tables instead of using the current ones that work with Titanium and the 6.2 client.

As for Augments, I have actually been thinking about giving it a try to see if I can get them working. I may actually be able to do it using your client inventory encode code as a reference. I am just not exactly sure if I need to use a certain slot ID or range of slots for augments similar to slots for items inside containers. If not, then it shouldn't be too bad. I will definitely try to play around with it and see what I can do.

I know you have more than enough on your plate to keep you busy for a while, KLS. Anything I can't finish myself, or find someone else to do it can just wait. Most things work just fine, and it isn't like augments are required for basic play. I think many servers don't even stress augments if they even use them at all. But, I will have a crack at it and see if I can get it working. I have a good example of an item packet with an aug in it from Live, so it shouldn't be too hard.

I really appreciate what you have already done for SoF BTW. It would have taken me forever to get items working. I think I got most of the structure issues all cleaned up once you had them working, but that was the easy part compared to getting them working in the first place. EQ wouldn't be EQ without the items, so, thanks!