SoF Development Tracking

[trevius]

Yeah, I thought about that, but the main reason for having the clientver field is to correct an issue caused by the change in the layout of the AA window and the consolidation of improved AA versions. It would still be good to have a bitmask setup, but atm the only thing it would be good for would be for that it doesn't already do as-is would be to give the option to remove AAs from being sent to 6.2.

Personally, I don't think that there are many (if any) people who run current server code that are using the 6.2 client. And even though it would be nice to continue support for all clients, I don't really know if it is still worth the extra effort. And if we ever had a 4th client, that would just mean that much more work to ensure that all 4 stay fully functional with all updates. I am not saying that I think we should break the 6.2 client completely, I just don't think we should waste time on making sure it gets all of the new features we are adding in.

I also have my doubts that we will ever get a client newer than SoF, which is one of the big reasons I started working on it in the first place. A newer client would require updating the LS code. It would also mean we would need to be able to get retail disks for it, which I don't think SOE plans to do. I guess we won't know for sure until they release the next expansion probably in a couple of months.

That is a whole other topic in itself though. For the matter at hand, if someone wants to change it to a bitmask, feel free. I don't really know what all is needed in order to set one up fully, or I would do it myself.

Another point about not really need a bitmask for the AA stuff is that there will never be a scenario when you need AAs for 6.2 and SoF but not in Titanium. You will almost always have AAs starting in 1 expansion and continuing on through all later expansions. The one exception IMO is Titanium to SoF, since they consolidated AAs to reduce the number of individual AAs by combining improved versions with the base AA they are improving. This means that the number of possible combinations is really limited and even if we added more expansions, we would still not need more than 6 or 7 options. Bitmask is fine if someone wants to add it, but again, I don't think it matters that much.

On a couple of side notes; I played Live for a few hours the other night and made some AAs to help figure out how they are handled differently now. In the process, I found out about SOEs new 51/50 server, which starts players at level 51 with 50 AAs. I don't think that server is up fully yet (been locked when I checked), but once it is, I think it might help a lot for collecting what I need about AAs. Another cool thing I found out about is the new group button on the map that shows the location of your group members. I checked SoF on the emu to see if it was there, and sure enough it was. Not only was it there, but it already works! One more selling point for people to make the switch

[ChaosSlayerZ]

Trev is right. I am curious if there is anyone left who is running 6.2. Given there was ultra limited time frame under which 6.2 could have been installed, YEARS ago.

[WillowyLady]

Originally Posted by trevius

It would also mean we would need to be able to get retail disks for it, which I don't think SOE plans to do. I guess we won't know for sure until they release the next expansion probably in a couple of months.

Beta has been announced for next expansion. So we might get another retail disc set yet. Knowing SoE, that shower of bloodsucking leeches will slurp the remaining playerbase for every penny / dime / rupee, while its still viable to do so.

We shall see

Take the scenario of a complete newcomer to EQ, having to DL a shedload of content on a slow connection. Aint it better to have a disc solution.

I know some BB is fast but for the some it just aint that fast yet! Unless SoE know better~

[ChaosSlayerZ]

from what I see SOE makes "all in one" pack every 3 expansions now.

-Titanium*
-Serpent Spine
-Prophecy of Ro
-Aniversary*
-Barren Sea
-Secrets of Faydwer*


so best gues is next all in pack will be either after next expansion, or even after the one after that one.
Which means at least 1 year from now.
Now given the tremendous ammount of effort it took to get SoF working, we do not yet know if it will be fully operational by that time frame to quickly swith to yet another all in one pack.

I also want to point out, that Trev was a starting force behind move onto SoF, and mainly cuase he found it in obudant supply at only 5.95
WHich of course gives opportunity to all curent emu users to cheaply and quickly upgrade their entire software.

Now if next all in one package going to start out at like $45+ - far fewer people will go after it until it significantly drops in price, or become available for download on torents. WHich could be YEARS from now.

[trevius]

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]

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]

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

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]

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:

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.