SoF Development Tracking - Page 3

**trevius** · #31 06-20-2009, 10:06 PM

Really, the discussion on other clients should be saved for another thread as it doesn't relate to this topic at all. This thread is for tracking SoF development :P

**trevius** · #32 06-21-2009, 05:53 AM

Ok, so I am making to head-way with the AA stuff again. Apparently many of the fields we didn't think mattered in Titanium actually do matter in SoF. So, the tables may need further adjusting.

It seems that some of the problems I have been running into were caused by the code hard setting certain fields instead of using what is in the tables. One thing that surprised me is that the title and description fields aren't even being used lol! Instead, we just have it sending the AA ID.

Since the desc and title fields are already in the tables, we don't have to add those. We will just need to assign the correct values to them, since all of them currently have the wrong settings. Titanium won't care if they are changed, because it doesn't even use them. The values for those on the client comes from the dbstr_us.txt file, but it always matches the skill ID anyway, so it will be very easy for us to set them in the tables if needed. We may not need them at all if I can figure out how to make the server send what the client is wanting.

I will need to collect more info on how the table gets sent when actually purchasing AAs. I am hoping the new 51/50 SOE server will make this easy to do. It starts you at level 51 with 50 AAs, so if they are untrained AAs, I can spend them and watch how it works. Then, it is just a matter of having the code support sending the adjusted table each time to allow it to train past the max points in Titanium.

Right now, I can get it to send a single AA even if I send 2 tables for the same AA matching what I have seen on Live. I can then purchase past the max point on Titanium, but each time I spend a point, it copies the AA in the window and makes a second one of the same AA listed in there. So, after training 10 points, I see 10 Innate Strengths listed. It sends the AA table again each time you spend a point, so I just need to figure out what it is changing each time to make them stack and not separate like they are doing.

Getting closer anyway, and with more research I should be able to at least figure out how they need to be sent to work properly. Once I know that, I may need some coding help to make that happen correctly. Depends on how complicated the system for dealing with it is, I guess.

EDIT:

Actually, things might be easier than I have been thinking. Part of the problem is that the code is set to use max_level to know when to stop sending table updates, which explains why the client doesn't think it can train past the max level set for Titanium AAs in the table. I have started working to add in extra code for SoF clients to let it send them properly with the right max levels for the AAs. Part of the problem is that I still don't understand all of the AA code yet, so I need to get a better grasp on that before I can do what needs to be done. Basically, I am thinking that for SoF, once the char has trained to the max level setting in Titanium for a certain AA, then the next one to be sent would be for the improved version. Basically, buying SoF AAs will be the same as buying Titanium AAs, accept the client will need to be tricked into thinking it is buy more of the base version of the AA. I am pretty sure this is possible to do, but need to figure out what to do to properly trick the client and to get it coded and working.

**trevius** · #33 06-26-2009, 07:07 AM

I started looking into recast timers on clicky items that have recast delays on them along with a recast type. I think I actually got it figured out now, but really don't know how to code it to do what it needs to do.

Basically, the field we have labeled as PotionType in the item Serialization for SoF is actually supposed to be for all items that have a recast delay/type set on them. It appears that this field of the serialization is supposed to pull the recast timers from the player profile for the recast type of that item. I think I have the structure set properly for where to save the recast timers, but I don't know how to set it to save a unix timestamp to those fields of the profile, so it isn't coded yet.

Once the PP is coded to save the timestamps, we would pull those timestamps and send them in the potiontype field (which probably needs to be renamed to something more like LastCastTime) for any item that has a recast delay > 0. This should tell the item whether it should be greyed out/counting down or if it should be shown as ready to use. Setting a time/date definitely stop items with recast delays from being greyed out. Here is the serialization packet of an item I have on Live broken down into the structure that shows an example:

Book of Knowledge

Code:

01 00 00 00 stacksize
00 00 00 00 unknown004
2a 01 00 00 slot
00 00 00 00 price
01 00 00 00 merchant_slot
00 00 00 00 unknown020
ec e6 5d 00 instance_id
00 00 00 00 unknown028
94 3a 48 48 potion_type - Unix Time - Thu Jun 05 14:12:20 2008
04 00 00 00 charges
00 00 00 00 inst_nodrop
00 00 00 00 unknown044
00 00 00 00 unknown048
00 00 00 00 unknown052
00 00 00 00 unknown056
00 unknown060
00 unknown061
00 ItemClass
00 Doesn't Exist in SoF

So far, it seems like items with recasttype of 10 will count down properly after being clicked, but the others do not. I believe this is probably something to do with us not sending the manachange or some other spell casting packet with the proper information. I would guess that we need to send the recast type somewhere after casting a spell.

It would probably help to figure the recast stuff out if anyone with a Live account that has an epic 1.5 could collect a packet log of their player profile as well as the item packet for their epic so I can see how those are serialized. It could be that one of the other unknowns sends the recasttype to go along with the last cast time from the player profile.

**trevius** · #34 07-09-2009, 04:12 AM

BTW, thanks to some help from AndMetal while working on a solution for the AA issues in SoF, I was able to figure out a nice temporary work-around for handling SoF AAs until we have a final solution to handle them properly.

Basically, what it does now is it sends the Title and Description of the AAs according to what is set in the sof_next_skill field. In most cases, that info will match the skill ID of the AA. In the cases where we were previously getting the unknown DB string message in the AA window, we can now adjust the table to trick the client a bit to allow full functionality of all AAs. Since the issue was that many upgraded versions of AAs were removed in SoF and consolidated into the base version by raising the max that can be trained in them, we could no longer send the client the descriptions for those removed AAs. The work-around is to force it to send the client the information for the upgraded AAs, but send it with the Title and Description of the Base AA. An example is that it now sends Innate Strength 2 times instead of sending Innate Strength and Advanced Innate Strength. The result is that you will see 2 entries for Innate Strength in the AA window. You can tell which is which by looking at the requirements when you select the AA. The upgraded version will show the requirement to be trained in the base version for a certain amount. It will also normally show a higher level requirement and will remain greyed out until you meet the requirements to train the upgraded version. Essentially, it will work exactly like it does for us in Titanium, it just won't show the upgraded name and description of the AAs.

I have included some SQL changes with the update that should make the AA window look quite a bit better in SoF now as far as the ordering of the AAs and which tabs they are displayed on. I tried to get all of the AAs with Prereq_skills set properly, but it is possible I could have missed one or 2. It is really easy to fix that if you see any. You just look at the number it gives in the unknown DB string message and that number will correspond with the skill ID of the AA it is trying to show. Then, you just look at the prereq that is set for that AA in the altadv_vars table and copy that prereq_skill number into the sof_next_skill column for that AA. That should correct the problem. If it still doesn't show up correctly, you might have to look at the AA that is the prereq and see if it also has a prereq. If it does, you can try putting that AAs prereq into the sof_next_skill field of the AA you are seeing the error message for.

There is still a fair amount of work to be done to get AAs to display as they should in SoF, but this work-around should do for now. I think AndMetal and I were able to figure out what needs to be done and it probably isn't too extremely complicated. Basically, we just need a function that can add up the max_level of any AAs that need to be combined into a single one. It would have to send it to the client that way and would also have to be able to reverse what it did when the client purchases AAs that are combined so it knows where to disperse the points to in the player profile. Once that is working, I think the only other thing we might need to do is to have it send the upgraded versions of an AA immediately after it sends the base version and both of them need to use the same sequence number. I think the sequence number is how the client knows to stack multiple AA tables being sent to it into a single AA being displayed on the AA window. I am still not sure on how to handle the coding for all of this, but hopefully it can be done at some point.

Here is some code that AndMetal wrote that should be a good place to start as far as working on totaling the max_level of multiple AAs:

Code:

int Client::GetAAMaxLevel(SendAA_Struct* aa, int count = 1) {
	if (count >= 1000) //just in case we create an infinite loop somehow
		return 0;
	if (!aa) //need to make sure we have an aa to work with first
		return 0;

	int max_level = 0;
	if (this->GetClientVersion() < EQClientSoF) {
		max_level = aa->max_level;
	} else
		max_level = aa->max_level + GetAAMaxLevel(aas_send[aa->sof_next_skill], ++count); //may be able to replace 'aas_send[(aa->sof_next_skill)]' with 'zone.FindAA(aa->sof_next_skill)'

	return max_level;
}

I am unsure where the best place is to do that calculation, but I know the reverse would need to be done in the buyAA code.

**KLS** · #35 07-10-2009, 08:27 PM

Did some work on SoF raids today, seems they changed the general struct some; which is the struct for the majority of raid actions: everything from adding members to changing loot types is through a single packet.

Code:

struct RaidGeneral_Struct {
/*00*/	uint32		action;
/*04*/	char		player_name[64];	//should both be the player's name
/*04*/	char		leader_name[64];
/*132*/	uint32		parameter;
};

is the current struct from a quick playing around with #optest it appears the sof struct will look something like:

Code:

/*00*/	uint32		action;
/*04*/	char		unknown[68];
/*04*/	char		player_name[60];
/*132*/	uint32		parameter;

I'll have to spend more time on it, the opcodes seem to work though and it shouldn't be too hard to encode this packet to make raids work, I just gotta fiddle around with it some more to figure the rest of everything out.

**KLS** · #36 07-10-2009, 09:22 PM

Code:

struct SoFRaidGeneral_Struct 
{
	uint32 action;
	char player_name[64];
	uint32 unknown;
	char leader_name[64];
	uint32 parameter;
};

Is the correct raid general struct for sof.

Problem with the raid join though:
OP_RaidJoin=0x0000 #RaidJoin and RaidUpdate seem to be using the same opcode on Live

This is a little problematic: not impossible to circumvent but I doubt this is entirely true because after finding the raid general struct I can see the behavior isn't changed. I can send a raid general action 8 then a raid general action 30 with the group leader in the encode though and it should do the same thing.

**KLS** · #37 07-11-2009, 01:01 AM

Raids should be working in my next commit

**trevius** · #38 07-11-2009, 03:01 AM

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

I will mark it off the list, thanks.

**KLS** · #39 07-11-2009, 04:36 PM

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** · #40 07-11-2009, 04:52 PM

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.

**KLS** · #41 07-11-2009, 08:09 PM

It's more of a work around for the disconnects, I'm not entirely sure what causes them yet; I suspect it's somewhere in the dying code that destroys the client a certain amount of time after death. Cause I know with #optesting the appropriate packets that you can be dead and just sit there forever and ever and ever without the client disconnecting you =o

**KLS** · #42 07-11-2009, 08:29 PM

Okay I'm looking into it right now on the dead disconnection thing:

When a client dies they call Client::Death() which sets
dead = true
and dead_timer is set to go off in 5000MS

From there in the main process there's entity_list.MobProcess() which runs Process() on every mob in the entity_list and if it returns false it will drop the client or depop the npc it's processing.

and... in client::process we have

Code:

if(dead && dead_timer.Check()) {
			database.MoveCharacterToZone(GetName(),database.GetZoneName(m_pp.binds[0].zoneId));
			m_pp.zone_id = m_pp.binds[0].zoneId;
			m_pp.zoneInstance = 0;
			m_pp.x = m_pp.binds[0].x;
			m_pp.y = m_pp.binds[0].y;
			m_pp.z = m_pp.binds[0].z;
			Save();
			
			Group *mygroup = GetGroup();
			if (mygroup)	// && zone.GetZoneID() != m_pp.binds[0].zoneId
			{
				entity_list.MessageGroup(this,true,15,"%s died.", GetName());
				mygroup->MemberZoned(this);
			}
			Raid *myraid = entity_list.GetRaidByClient(this);
			if (myraid)
			{
				myraid->MemberZoned(this);
			}
			return(false);
		}

So 5 seconds after dying the client's process returns false and they are dropped even if they haven't zoned. To facilitate this we would need to alter the logic to only drop and move the client to the zone if they had a return to bind flag set, 6.2/titanium would set it automatically and would zone normally and SoF would set it when you clicked return to bind or whatever, and then could also have the code for instantly returning to the body after being revived.

**KLS** · #43 07-11-2009, 08:34 PM

oh and also

Quote:

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.

It's actually an empty window but it says monster abilities and has the load and save buttons on it. I suspect the requestpacket recieves a reply to fill it up.

**KLS** · #44 07-12-2009, 02:40 PM

I turned off the disconnection stuff but still cannot get the client to zone to itself. It will often just cause the corpse you make to warp to it's bind point instead(and your UI still does not respond), the respawn window does the same thing as that packet. I assume there's more packets that need to be sent to do it right or something.

**Derision** · #45 07-12-2009, 03:06 PM

I had a play around with this a few weeks ago. IIRC, the closest I got was to use the same 'hack' as the EvacToSafeCoords and use OP_RquestClientZoneChange if the player was using SoF and died in the same zone they where bound in. The problem I had was that once the player respawned after zoning, the camera angle was from up above, looking down on them, just like it was when they died.

I don't appear to have saved a diff of the changes I made.