SoF Development Tracking

[KLS]

Raids should be working in my next commit

[trevius]

That's awesome, KLS! One more issue with SoF bites the dust

I will mark it off the list, thanks.

[KLS]

I figured out a work around for disc on zoning to bind too.

I tried to figure out the can't level over 75 thing but failed, it's gotta be there though: one of the main features of this expansion was the ability to level over 75... =(
I did note some parts of the PP that were unknown and do stuff though.

unknown12852[0]:
if set to 1 you act like a NPC, your hp / mana / endurance is fixed off some value in the PP that I haven't found yet.
You have no experience bar, no face button and your AA window shows monster abilities instead of AA abilities, also when you open the AA window it sends an opcode, probably something like OP_MonsterAbilityRequest.

unknown12864 is a field of data we send fixed data for but it includes resists in there:
const uint8 bytes[] = {
0x01,0x00,0x00,0x00,
0x02,0x00,0x00,0x00,
0x03,0x00,0x00,0x00,
0x04,0x00,0x00,0x00, //cold resist
0x05,0x00,0x00,0x00, //fire resist
0x06,0x00,0x00,0x00, //magic resist
0x07,0x00,0x00,0x00, //disease resist
0x08,0x00,0x00,0x00, //poison resist
0x09,0x00,0x00,0x00,
0x0a,0x00,0x00,0x00, //corruption
0x4b,0x00,0x00,0x00,
0x4c,0x00,0x00,0x00,
0x4d,0x00,0x00,0x00,
0x4e,0x00,0x00,0x00,
0x4f,0x00,0x00,0x00,
0x50,0x00,0x00,0x00,
0x51,0x00,0x00,0x00,
0x52,0x00,0x00,0x00,
0x53,0x00,0x00,0x00,
0x54,0x00,0x00,0x00,
};

I suspect 6.2 and titanium also have resists in the same chunk of data, and we could probably have some way for servers to change the default resist levels if they wanted.

[trevius]

Wow, KLS! Knocking out 2 fairly major issues in 2 days is amazing I was actually thinking about going back and trying to do more work on the respawn window, but atm I am working on trying to make commands to spawn/create/despawn objects in real-time. The commands shouldn't be too hard, I just need to get them written up and tested. Once I am done with that, I will probably try to work on the respawn window again if I can figure anything else out with it. If you can stop the client from being disconnected, I might be able to look at what you did and slip the respawn window packet in there. Then, I think we can do the disconnect/zoning when we get the respawn packet back from the client when they make their selection. The packet handling for the opcodes is in place, it just doesn't have code to actually do anything atm.

Once you have the fix for disconnects up on the SVN, I can remove that one from the list of issues as well. The disconnect was the actual issue. The respawn window is just a new feature that we can put in at any point, but it isn't an actual issue. I think the main point is to get caught up to be as fully functional as Titanium is and we can add in the new features for SoF at any time after that.

There may be a couple more issues with SoF that I don't have on the list just yet, but I haven't confirmed any of them yet. I have seen reports of randomly disappearing items, but I have been unable to verify it and don't really see what would cause it yet. I also noticed that some particular items I have on my server that are set to stack are not stackable. They also are unable to be moved around in the inventory unless you place another item from your cursor into their spot, then it will pick them up and they can be moved. I am pretty sure this is still an issue with the serialization header, but I haven't been able to figure this one out yet. While I was working on it, I did happen to find that the spot we thought was for potions_type is actually for setting the last cast of the items' recast_type, and should be pulled as Unix Time from the Player Profile. I did add the recast types field into the player profile, but I don't know how to make it save the current time upon being cast just yet. Sorry, kinda going off on a tangent here :P

Edit: Just saw the extra notes you made about the PP!

Those are some nice finds!!! I know that we had to be storing resists there somewhere. I think probably half of the PP is for shrouding, since most of it gets ignored due to other packets overwritting the info when they come in after the PP is sent. So, the NPC field you found is probably either for toggling shrouding off and on or for the old code where they made it so players could become NPCs and fight players briefly years ago, or maybe for both.

I think ShowEQ has a few more shrouding structures that we don't have or use yet. I may have copied a couple over into the SoF_structs.h file, but not all of them I am sure. If we ever try to get shrouding working, we could probably find some good info from ShowEQs files for it.

That is really interesting that we get a monster ability window that already has abilities in it without even having to send tables to do it like AAs and such. I assume it works more like skills, where we don't really need to send anything for them to be listed, the client just knows them and it is a static list.