Please post them. I have for the past week been trying to get some world building done with SoF, but I keep getting sidetracked with other projects or requests. :(

The size of the item packet is not the same as the live from june sadly. I don't know if it's too long or too short just that it doesn't align. I also have a feeling there's an option somewhere that dictates how data is displayed cause my first thought was to look at the stats in the item window and see if I could find where they were in relation but it's not making sense compared to the packet im making. =(

Hooray spending hours adjusting the size up and down by bits at a time ><

Here is the SQL to get all of the new zones (after Titanium) working with SoF. This is just a basic setup to give a usable safe point and have the zone display correctly. I am sure that each one could use tweaking (fog, min/max clips, etc), but this is definitely better than what I started with :P

To add this in, you will need to open your zones table and do a sort by zoneidnumber, and then delete all lines from zoneidnumber 369 up to 449. Then, the SQL above should be able to be sourced in the table ok, as long as your table is setup the same way mine is. I got mine from PEQ, but it was a year ago, and there have been a couple of additions to that table from source revision updates since then. So, it might be good to check if it lines up with this setup I have for my zone table:

For working out the item structure size and field locations, I am always willing to give it a shot. If we can find the Heroic stats section of the struct, it shouldn't be much after that. If you stick something up on the SVN for items, I will definitely give it a shot :)

Also, I think I may know why AAs aren't loading, and I am guessing it may be due to an issue with the player profile struct. I think I have verified that many fields are in the correct locations, but some of them are a bit more complicated. And, I am not quite sure which things in game for the client come from the player profile or the spawn struct, since they are both redundant in alot of things.

I use this site the help me or i read the eqnews.txt file in client
http://eqplayers.station.sony.com/game_updates.vm

to help me out with what was changed or fixed

the newest client i have found to be open and say i have all expanshions
is 04/11/08 update, i'm waiting for the next one to be soon i hope and keep my fingers crossed :D

as i have noticed the opcodes for login have changed after May of 08.
i'll keep working on the login opcodes if i find more info i'll be sure to let
you known.

Took a couple hours but:
http://i8.photobucket.com/albums/a2/...e/EQ000007.jpg

Hopefully can get items basically loading soonish, I have a decent idea on augments but I'm gonna probably hold off at first. There's a lot of other packets to do with items that will need to be covered, item links, moving items, using clicky items etc. Every item packet with a slot ref will have to be encoded/decoded even if it hasn't changed because of the 22-39 getting bumped up a slot.

...but ima go lie down now I think.

That is great news KLS! Considering that most other item related packets shouldn't be all too big, I think getting items working in the first place will be the hardest part. After that, it should just be adjusting a few small structs slightly and then finding a few opcodes.

Also, I didn't really think about it until now, but I am betting my issues with AAs displaying is also related to the expansion field issue that Derision mentioned that is causing the Power Source slot to not show up. I will mess with it a bit more. Right now, I am reworking a bit of the player profile struct to be more in line and accurate to what Derision's packet log shows. It seems to be helping so far, at least for displaying armor materials. I know that alot of that struct is already lined up properly, so it is mostly just adjusting the sections in between the parts that already line up. I am not sure why, but my AA window shows that I have 917 unspent AAs (which is accurate to what Titanium shows), but only 62 spent AAs even though Titanium shows 260 spent. Maybe that too is expansion field related, but it makes me think that maybe that field is just in the wrong place. Though, it looks like it should be in the right place from everything I have referenced so far (packet collects, showeq structs and Titanium structs).

And, OscarGrouch, I am not sure what you are trying to accomplish with the different clients you are trying. We will not be using any client after SoF, so any after that is nearly pointless. Yeah, you can find opcodes to log in to character select pretty easily, but that is very easy compared to filling in all of the packet structures properly and the rest of the missing opcodes. Plus, it is unlikely that we would ever want to use a client that isn't legally attainable. The expansion information you are talking about, I am guessing is the list of expansions that show up at the server select screen. That doesn't matter to the development of SoF at all. So, you shouldn't use any more time on that unless you have something else you are working on that isn't related to this development. Maybe I am just not clear on what it is that you are trying to accomplish.

That field is probably in the wrong place. Speaking of wrong placed fields the pop combat ratings seem to of moved... along with faction mods, and I'm still trying to plot out the entire rest of the packet but it's slow goin, hopefully I'll have enough done to start loading inventory soon though.

Ima revise that I don't think they moved but something is definitely keeping them from displaying, there must be some bit that controls that column's vis.

If you get a chance could you go collect a book type item from live? I'm not sure how they're doing filename now... it does seem to be an int size but I'd like an item to study before moving on.

I wouldn't be too surprised if they weren't showing up because we weren't sending the correct expansion packet like Derision said. It is keeping the Power Source slot from showing up, so maybe it also keeps PoP stats from showing up. I am interested to see how much that expansion packet corrects. I have a feeling it will help my AA window issues and probably the max level of 75 issue too.

I am mostly trying to clean up the spawn struct, illusion struct and player profile some while I wait for Derisions next update. There is still plenty I can work on, so no rush :)

And yeah, I will try to get a book now.

Here is a noobie note that should work just as well as anything. The 02 I bolded is itemtype 2 for book:

No, no I don't think that's it at all. I notice when I get my offsets wrong and the items clip each other and I get a 2nd item with garbled stats I'll see accuracy strikethrough etc.

I'm really bad with messing up my offsets too, when I'm stepping through 500 bytes just to realize I've gotten off by 1 byte I wanna kill myself... need to finish this structure already.

You know what it was? I had an uint8 instead of uint32 in one spot and incidentally 3 extra bytes not far down so I didn't catch it right away.

It's basically structured now ima try getting an inventory to load... but first...

I've had it up to here with You will be squished.

Also, if you are able to get a collect of an item with an augment socketed sooner or later that'd probably help. Tho I wont be doing that at first.

Here is "Signet of Might" with an "Onyx Orb of Aggression" augmented in it:

Damn that thing took too many hours of tradeskilling just to be made obsolete when we got into PoTimeB lol.

I've committed the Character Creation stuff.

You will need to update your Expansions variable to see the Power Source slot. I used 16383.

The hairstyle/color on the Character Select screen is wrong for Drakkin, but seems OK for other races.

Tutorial button doesn't work yet.

The character creation in SoF is different in that it doesn't send the player_choice field anymore, rather it sends the actual ZoneID of the requested start zone, so I created a new WorldDatabase::GetStartZoneSoF to handle SoF clients that puts new characters in Crescent Reach if there is no matching entry in start_zones.

I'll try and sort out the tutorial button and then maybe try and find out why you get kicked to character select when you die.

OK so:
http://i8.photobucket.com/albums/a2/...e/EQ000008.jpg

/cheer

I'll commit tomorrow I think. A lot of fields are off, esp with respect to item clickies and scrolls and stuff. Delay seems to of become lost too. But I think it's to the point that it's workable enough that other people besides me should have to do all the work...

Now it's 5hrs past my bedtime but I had to finish that, I'm going to bed =(

Not sure if this will help, but EQItems has an SVN for their itemcollector which may help find the serialization info.

I think this is from Live:
http://eqitems.13th-floor.org/svn/it...ct/EQItem.java
And for evolving items:
http://eqitems.13th-floor.org/svn/it...lvingItem.java

Some good info in there, most known but a few things helps. The biggest problem isn't where things are.. we know for the most part but between versions bytes will slip into strange places and throw offsets off a bit which is what causes fields to be off... and it's annoying as heck btw.

Also I'm going to commit some more item stuff even tho I promised myself I'd take a break. Item movement and bags should work after this.

Some items also cause the client to 'crash', it's an odd crash the client just fails to load and eventually just exits to the desktop with no error. Nothing even in log. Something about the item packet is malformed and causes this.

That's it, end of the log. There's a couple more items after 281 but I've confirmed it's what's at 281 that's causing the crash in this case it's: 5022. I noticed having some fields set wrong (usually the unknowns) causes this to happen when making the packet. So im guessing there's an unknown like this somewhere in the shuffled fields.

Yeah, at some point, the item packet gets off and causes the crash. From the example I have, it looks like it is just trying to load a slot that doesn't exist:

I will take a look at it now that the inventory stuff is on the SVN. I also identified a few more opcodes like MoveItem and Consume I think. I just need to test them out to make sure. Now that items are at least partially done, I think it will help alot to get the game more finalized. It definitely opens up more stuff to work on.

On another note, I was hoping that the expansion struct that Derision added would help my AA structs to start working, but they aren't working just yet. I will keep playing with those too. I am sure we can get them going soon.

Nah I've had good loads with the client thinking it has a bad item slot. It finishes loading the item from the slot but then allocates way too much memory for the next item or something. Bad item slot just fails to load unless it's negative then you'll get an immediate crash... im not sure why some item slots get way off tho. I'll have to look at my output logs and make sure everything it looking right.

I've noticed items in bags tend to be particularly big offenders for some reason it's almost always an item in a bag...

Yeah, that info from 13th floor SVN is definitely useful. I just used it to correct delay, light, and a few other things in the struct and verified that the changes worked and are now accurate. I will try to go through the rest of the struct and see what else can be adjusted.

Not sure if it's been noticed, but 16777216 is 1000000 in hex, so it looks like we're getting 3 extra bytes in there. In the log, it doesn't look like slot 1 was sent, so that's probably it. I've also seen 436207616 (1A000000 so 1A -> 26) while messing around myself.

I've also seen some in-game errors from the server about issues with slots:
I'm not sure if it's directly related, but I think Attack might be also suffering a similar issue.

Yeah, after looking and the error I posted earlier from the EQ debug, I just noticed that slot 1792 would be 700 in hex, so it was probably off a byte since it had just loaded slot 6 and slot 7 would have been next. So, it sounds like we are just adding an extra byte somewhere that isn't needed.

I made some corrections to the item structure and am going to commit them to the SVN in a minute. It still isn't perfect, but seems to be loading at least the starter items I have tried very well now. Using the 13th floor info that AndMetal posted has helped alot I think, though it doesn't seem to be 100% accurate for SoF. At least it is a better guide.

One important one is that it seems like the filename field is just like any other string field. It should load a null byte if there is nothing in that field. The booktype field being set to int16 should have actually been int8, and the other byte there would be the filename field. The FF FF FF FF or 00 00 00 00 after that is actually an sint32 for loregroup. So, I think that makes a bit more sense now.

I am sure we can definitely get most of this structure sorted out without too many issues. Especially once we figure out where it is getting that extra byte from. I am thinking maybe one of the strings isn't supposed to have a null terminator after it or something. From what I can tell, I don't see any major difference between the items it was able to load and the item that threw off the struct by 1 byte. Maybe there is supposed to be an extra byte every few items or something...

I'm thinking maybe I'm not supposed to send bag content on initial serialization. When you open a bag this client sends a small packet to the server that includes the item slot opened...

Bah my packets were too long!

I had two nifty packets to show the diff between an item loading correct slot and an item not loading in correct slot but the forums ate them D=

Long and short of it: the headers are almost exactly the same they just differ by what I've labeled as potion type.. I've gotta look more into it tho.

I devised a workaround for the crashing and failure to load of items... well for the crashing at least :rolleyes:

I'd still like to figure out why it sometimes doesn't work when put into an EQI packet, but this should let us move onto more important things for now.

Work around for items seems to work fine, tho they still need a lot of work. I checked out AAs quickly but I'm kinda at a loss. Using the log I got from derision the data doesn't seem to of changed at all other than how they do string ids. I updated that to match and still nothing.

I notice that the window tabs don't even appear, which isn't entirely unusual. One thing I notice is the AA table is sent directly after the client requests the zone, right before the player profile. And for titanium and below we send it... considerably later, maybe the client is getting picky with how it's sent, or maybe there's some other packet that needs to be sent to get AAs to work.

Yeah, I think the tabs only display as needed. I have messed with it quite a bit and haven't had any luck at all yet. Though, I haven't tried changing when they get sent yet, which is a good point. I noticed that they are one of the first things that get sent now. The only other thing I noticed, but kinda doubt would be a problem is that they all come in as combined packets on live. I don't know how we are sending them exactly, so I am not really sure.

One other thing I was thinking is that there is a good chance that the player profile isn't setup to load the proper AA info yet, but I think that only affects what AAs it shows you as having purchased.

For now, I am working some more on lining up the item struct and maybe getting merchants and combat working.

Derision already mentioned it in this thread, but before the info gets lost, I figured I would note it a bit more clearly here. To enable the use of SoF content (Drakken race and new zones), you must update the Expansions field in the Variables table to have a value of 16383. This number tells the client which expansions to use and you can set it to allow or disallow any expansion you wish. Here is how that number breaks down:

You just add up the numbers from the expansions you want to enable to set the Expansions value to that total. I verified this as well on my EQLive account, which is only enabled up to SoF, and it sends me the same number. It would probably be a good idea to note this in the changelog or maybe put an Optional SQL update file in the /utils/sql/svn/ folder so people don't forget to do it when they update.

Also, I forgot to mention it in the changelog, but I cleaned up the patch_SoF.conf file quite a bit last night. I still plan to reorganize it further by sorting the opcodes into related sections so they aren't just all over the place.

After thinking about AAs more, I am starting to think that there is a very good chance that the expansion field in the Player Profile is in the wrong place and/or not sending the proper expansion information needed for SoF. I will try forcing that field to use 16383 in the encode for all SoF clients. Then, I will see if I can work on it to align the expansion field into the correct place in that struct if it isn't already. I wouldn't be surprised at all if that was the reason the AAs aren't showing up yet. Though, if that is the case, I am surprised that the Power Source slot works and the AAs don't.

I was also thinking that the issue with AAs may be something new for AAs (as KLS mentioned). It could be very possible that there might be a new packet for the new sorting/filtering feature in the AA window. I would think that the client should be doing this sorting and filtering, but I figure it is better to consider all possibilities at this point to hopefully come up with a good solution soon.

I made some changes to the source so it can recognize the new Drakkin race. I haven't looked around much at what else might need to be changed yet though. So far, $race in perl scripts seems to report properly for Drakkin now instead of reporting unknown.

It looks like the reason that weapons and other items aren't working properly for Drakkin is because the source isn't set to handle the Drakkin race properly yet. I added this last night:

From looking at item stats on 13th floor and adding up the races on items, it seems like 32768 should be the correct number for the Drakkin race. ALL/ALL items should be set to 65535 and it seems like most already are. I did notice that it looks like GeorgeS item editor may have been using a value of 131071 for ALL/ALL items at some point. I think that should still work properly, but that may be the source of some issues. If so, I think it would probably be safe to convert all race fields in the items table from 131071 to 65535. I think the main thing is that something else needs to be changed in the source so that the server knows that Drakkins are a player race and that items with 32768 in them should be usable by Drakkins.

For the issues with Item Slot Numbers being re-arranged in SoF, the slots are defined here:

/common/eq_constants.h
Is there some way we can do an IF check that would use different lists depending on the expansion that the client is using? If so, then all we should have to do is do another IF check on usable slots for ammo items and convert 21 to 22.

I just figured out why combat with weapons wasn't working for Drakkin. The bool for IsEquipable was being set to false every time because it had not been adjusted to use the new total of 16 races. I corrected it on my test server and now combat seems to work perfectly. The actual damage during combat isn't being reported yet, but that it is still working. We still need the OP_Damage opcode and structure corrected before the damage will display. At least with this change, it makes basic gameplay functional. I will commit the change tonight when I get home.

I also found that Drakkin weren't set to start with any language skills, so I added Common Tongue and the 2 Dragon languages to them since I figure they would probably be able to speak the Dragon ones due to their nature. I will also commit that tonight.

Drakkin also have a unique racial starting skill that is really a special AA that only they get. Depending on the Heritage they chose, they get a slightly different affect from it, but I think the AA is called Dragon Breath. For that to work properly, we would have to write new code to handle heritage and also implement the AAs. Heritage also defines some slight differences in starting resists from what I have read. None of this needs to be done any time soon, but I figured I would note it for later use.

I don't think the item database needs to be updated much, but I will probably update a small SQL change to change any item set to 32767 (Titanium ALL races) to 65535 (SoF ALL races). I know I have seen at least one item that was supposed to be ALL/ALL that wasn't because it didn't have Drakkin on it. It may have been set that way by GeorgeS tool at some point, but I am not sure. We will need to verify his tool is setting ALL races to 65535 now.

LOL, I got combat damage working finally. ShowEQ was throwing me off, because they call OP_Damage OP_Action2. I finally saw it in some combat logs and tried it and it worked. All I had to do was add 5 more bytes to the end of the combat damage struct and it seems to work fine now.

That leaves AAs as what I consider to be the last major issue. They still aren't displaying properly yet. For now, I am going to try to get doors working properly and maybe adjust the objects structure, because it seems like heading is in the wrong place, since all objects face the same directions.

I tried changing the order of when AAs are sent, did nothing. Either there's another packet, the opcodes are wrong or there's something that needs to be set in the player profile. I lean toward 1 or 3, hopefully 1 but I bet it's 3 =(

Yeah, I am pretty sure that the opcode to send AAs is correct. It could be option 1, but you are probably right that it is something in the player profile. I am going to work back through the PP anyway soon to try to align some of the areas that are harder to confirm. I am going to be using a Live packet as a reference, so it might not be too easy. The only good thing is that the difference from EQLive and SoF is only about 96 bytes in size (live is actually less now, which is rare for structures to shrink). I will just base the changes off of relative fields that we know are correct. Hopefully I can get it more accurately aligned and that may resolve a few issues. It is a big struct, so it may take a while to complete though lol.

Unfortunately, I just had to back out of the fix I put in for Drakkin to be able to use equipment and weapons and gain stats from them. It was working great for SoF, but the fix caused the same problem to start happening in Titanium. So, right now, it seems like only 1 or the other can work. I am sure there is a way to let both work properly, but I just don't know of a good solution right now. If anyone has a suggestion, it would help :)

Here is the piece of code that needs to be changed to work with both client versions:

/common/item.cpp

I take it we need to copy the 2 spells_ text files from the SoF client and replace the old titanium ones with them in order to use the new spells from the new expansions?

Will the new files be compatable with old clients? If so is there any harm in making the switch now, or should I wait?

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.