SoF Development Tracking

[trevius]

Well, it wasn't as simple as I thought, so I really didn't make any breakthroughs last night. I will give it another shot tonight. I think I am close, but there is just something keeping it from working. Might still have to do some tricky conversion stuff to get AAs working between both clients properly. I am still pretty confident that we can do it using the same tables as they are now setup.

Here are the AA table packets from EQLive that make me think it is just tricking the client:

Mar 13 2009 07:28:57:131 [Decoded] [Server->Client] [Size: 120]
[OPCode: 0x3683]
000 | 02 00 00 00 01 ff ff ff ff ff ff ff ff 02 00 00  | ................
016 | 00 02 00 00 00 33 00 00 00 01 00 00 00 01 00 00  | .....3..........
032 | 00 01 00 00 00 00 00 00 00 00 00 00 00 01 00 00  | ................
048 | 00 ff ff ff ff 00 00 00 00 00 00 00 00 fe ff 01  | ................
064 | 00 0f 00 00 00 ff ff ff ff 03 00 00 00 01 00 00  | ................
080 | 00 00 00 00 00 00 00 00 03 00 00 00 ff ff ff ff  | ................
096 | 00 00 00 00 01 00 00 00 04 00 00 00 02 00 00 00  | ................
112 | 00 00 00 00 01 00 00 00                          | ........

Mar 13 2009 07:28:57:131 [Decoded] [Server->Client] [Size: 120]
[OPCode: 0x3683]
000 | 09 00 00 00 01 ff ff ff ff ff ff ff ff 07 00 00  | ................
016 | 00 07 00 00 00 33 00 00 00 01 00 00 00 02 00 00  | .....3..........
032 | 00 03 00 00 00 00 00 00 00 00 00 00 00 01 00 00  | ................
048 | 00 ff ff ff ff 00 00 00 00 00 00 00 00 fe ff 01  | ................
064 | 00 0f 00 00 00 08 00 00 00 0a 00 00 00 03 00 00  | ................
080 | 00 00 00 00 00 00 00 00 03 00 00 00 ff ff ff ff  | ................
096 | 00 00 00 00 01 00 00 00 07 00 00 00 06 00 00 00  | ................
112 | 00 00 00 00 01 00 00 00                          | ........

Mar 13 2009 07:28:57:131 [Decoded] [Server->Client] [Size: 120]
[OPCode: 0x3683]
000 | 0a 00 00 00 01 ff ff ff ff ff ff ff ff 07 00 00  | ................
016 | 00 07 00 00 00 33 00 00 00 01 00 00 00 02 00 00  | .....3..........
032 | 00 04 00 00 00 00 00 00 00 00 00 00 00 01 00 00  | ................
048 | 00 ff ff ff ff 00 00 00 00 00 00 00 00 fe ff 01  | ................
064 | 00 0f 00 00 00 09 00 00 00 0b 00 00 00 04 00 00  | ................
080 | 00 00 00 00 00 00 00 00 03 00 00 00 ff ff ff ff  | ................
096 | 00 00 00 00 01 00 00 00 07 00 00 00 08 00 00 00  | ................
112 | 00 00 00 00 01 00 00 00                          | ........

The first packet is Innate Str, which I didn't have anything spent in, so it just sent the one packet. The second and third packets both fall into the Innate Stamina skill ID range. Those 2 packets are what make me think the server just uses the old separate AA information but sends them twice to stack the effects. Basically, the AA Effects are the same between the 2 aas for Innate Stamina and Improved Innate Stamina. But since the improved version no longer exists in SoF, it simply sends the normal innate 2 times and the client knows to double the stats up. I am sure that the extra effects work, because if I train Chaotic Potential (doesn't exist in SoF) and Planar Power while using a Titanium client, and then log in with SoF, I still get +50 to all caps as if I had both AAs. So, the only thing that is left to figure out is how to stack the AAs so it doesn't show the unknown DB entries in the AA Window. Also, we need to have something that will do conversion stuff for when an AA is purchased above what the base AA allows. An example of what I mean by that is Innate Stamina has a max of 5 train points allowed, but Improved Innate Stamina has 10, so that totals 15 between the 2 which is what should show up for normal Innate Stamina in SoF. But, since they are actually stored separately and sent separately just like in Titanium, we need something to tell the server that after 5 are trained into Innate Stamina that it needs to start putting the remaining 10 points into the improved version.

Hopefully this is starting to make more sense. Anyone who wants to chime in or give a shot at figuring this all out is more than welcome LMAO! I think I am on to something, but just need to get 1 working so I know exactly what needs to be done. Currently, I emptied out the alt_vars AA table on my server and left only 2 entries. One being Innate Str and the other is the improved version of it. This should make it easiest for testing as I only need to worry about getting 1 working. Once one is working, the hard part should be over, but no luck just yet.

[AndMetal]

Have we thought about using a bitmask instead of a number for clientver? Since we're only working with 3 clients (6.2, Titanium, & SoF), it would only use 3 bits (values 0-7), and allow for more flexibility (and fewer ORs in our IF statements):

0: None
1: 6.2
2: Titanium
3: 6.2 & Titanium
4: SoF
5: 6.2 & SoF
6: Titanium & SoF
7: 6.2, Titanium, & SoF

[cavedude]

That's the way to do it, I think AndMetal. It has the advantage too that if one day another client gets added it can just be assigned 8, and the next 16, etc.

[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