[Roadmap] DOL to 1.115 Client Support and Fix Merge

[Leodagan]

The 1.115c is available from "Live Server" (update with camelot.exe)

Like Mark said, keep a backup of any "Pendragon" or 1.115a~b "Live" DLL, once you used camelot.exe patcher you won't be able to get a working DLL anymore !

There could be a 1.115c pendragon from an old revision that doesn't match the 1.115c live, 1.115f Pendragon == 1.115c Live

So actually there is no distribution of working client through mytic patcher either way... and Pendragon just used this new DLL for 1.115f and there was no trouble before that !

Actually a lot of things have changed (listing for research purpose) :

• First Client packet with Version header changed (C=>S 0xF4), it can be match on its "Size" to use the correct Version Parsing, once the first packet Version have been "matched" the Client PacketProcessor will work fine and we will be able to use logical switch based on version to change Packet (using PacketLib subclass etc...)
• Login Client Packet has changed (C=>S 0xA7),version header changed, username and password are now transmitted in some kind of what I called "LowEndianShortString", it's like a pascal string but prefixed with a low endian ushort instead of a byte...
• CryptKey Exchange has changed (C=>S 0xF4, longer one with symmetric key included), the Version header changed, position of the key in the packet is not the same, and the key is writed with a "LowEndianShortString"
• Actually changing the "Crypt" Flag in the First Client Packet prevent the Portal From Working ! The workaround for previous version is not working anymore so, after the second 0xF4 packet with symmetric key, client only expect encrypted data, and will only send encrypted packet to server... If the server asks for unencrypted stream the client keep sending its First Packet until the server tells he handles crypto...
• We can either research how to update portal (but I'm really not able to use a decompiler), or research how to handle DAOC crypto...
  It looks like a symmetric crypto, all existing code "comments" around crypto only talks about RSA and (Pseudo)RC4, the default client key is 64 byte long (512bits) and from "DAOCLogger" which can log clean text packet there is some way to know what is the expected result... From a recent session on Pendragon I'm pretty sure I haven't see any asymmetrical key exchange ! So it must be a symmetric algorithm only... (even if that's really WEAK !!!)

[Tolakram]

Do we want to break some of this talk out into the private dev forum?

[Leodagan]

No use

I'm wrong about Crypto anyway

The compatibility of this 1.115c+ only relies on portal update, I have no skills to do this, I hope to run in someone who can while researching packet change with "logger" !

Actually that depressed me a bit

At first all we needed was just some packet upgrade and debug to be "live" compatible, now there is some low-level trouble, and we're back to apply an old DLL again...

[Tolakram]

No worries, I think the portal will get updated soon, it always seems too.

[Leodagan]

Ok then, it's not released for now, but the 1.115c DLL trouble is no more (at least for me )

I can continue on implementing new features !

Actually I could Update the Packet Handler to handle the new 0xF4 (version and cryptkey, also first packet) and the new 0xA2 (login packet)

The code need some cleanup as it was made fast and ugly...

I will also rework the Tooltip ID generator, I don't like having two places to track those unique numbers, and I need to detect identical "script" spells to lower the unique count !

I must admit once these id are well inserted into database each shard owner should review the scripted spells he use (the one that create a DB object from code and spawn a SpellHandler from it !!) as it could create some overflow if it's actually done in a mob script for example (each time the mob will spawn or execute some script there is a chance a dynamic db object get created again and occupy a new ID slot !!)

[Graveen]

Big work mate !

[Leodagan]

Actually something annoys me around "TooltipID"

I made this property to handle ID differently than the auto-increment in database, but in the Spell constructor the DBSpell.SpellID is casted to (ushort) to fit into "Skill.ID" property which is the base property of Spell.ID

Actually I don't know how spell above 65 535 ID do work, is the int binary 'truncated', is it set to max value ? Is there another Reference for Spells used in other way ? (Dictionary cache based on int ?)

In SpellHandler some checks of "Spell.ID" is made against "SubSpellID" which is an int, SubSpellID may not contain value above 65535 or the match will fail !

SkillBase.GetSpellByID() only contains spell loaded from database thus it can use overflow value... SpellEffect Saving take Spell.ID property to store in database, so it can result in overflow and when loading the value will be wrong !

Most of the updates we need for over 1.110 needs to truncate any of the internal ID's to an ushort (for now...) but we still use, and need internal int range (for easier maintenance and linking values).

This Skill.ID property could need an improvement to have an "int" range, this need a lot of code update to handle typecast, but it will prevent from having weird trouble with spell, I'll check Style and Abilities to see if this could have any side effects...

[Leodagan]

Committed : DOL SVN Revision 3354

- All Packet Code update for 1.115c, this revision won't work with rolled back 1.115 dll (and it obviously need the new connect.exe)
- Moved All Tooltip Logic from DBSpell to (Game)Spell Object, keeping all these funny auto-valueing code around "Skill" Object Tree !

With this I can further advance on other matter like this Skill.ID limitation, or Keep Texture / Warmap Trouble...

[Leodagan]

Committed : DOL SVN Revision 3355

- Updated Skill.ID from ushort to int.
The last cast is mostly made around PacketLib, so all int value should now be available for internal use, but it can send "colliding" ushort ID to client, colliding should have no effect until the skills are meant to be used in Game UI...

This only impact Spell that could use ID above 65535 range, it will now correctly "internally" link with any mechanisms that checks SpellID to an int ! (subspell, style spell, item spells etc etc...)

Other Skills like Ability or Styles never used ID above ushort range !

Update : GameServerScript need to be forced to compile after this update or a lot of getter will fail...

[Leodagan]

Comitted : DOL SVN Revision 3356

Some database oriented update...

I'm starting to merge some Freyad Change that will be needed around Spell/Skill/Ability upgrade (a lot of these merges will be needed to handle tooltip and UI correctly for future update, and are needed to fix some too long lasting bugs around summons and weird classes like necro...)

I added some improvement around table altering that allow for flawless migration from auto-GUID to Auto-inc, it doesn't remove the old GUID col but it doesn't fill it anymore, this can't be used on table that use the GUID as reference !! (mostly around account/player/inventories/guild ?)

I wrote this code to allow for a flawless migration of Ability to Auto Inc (that's not much to begin with, the Ability key is in fact KeyName string with a Unique index...) maybe more to come for other harmless table...

[Leodagan]

Comitted : DOL SVN Revision 3357

- Extended some interface around Spellhandler and EventMgr
- fixed some behavior around GameLiving, lot of cleanup there, some small fix to reduce code, an important fix allow NPC to dual swing with no weapon (as most of dual swing NPC are bare handed, and even with weapon I don't think the code would have worked !)
- a lot of cleanup in any area, readability, removing unused "using", expanding ternary operator to full if then else
- Preparing a new debuff category and an Effectiveness property to stop handling effectiveness as a class property. (and handle rez sickness as any debuff !!)
- Preparing some checks for importing future abstract property calculators !

Should not do much harm for now I'm trying to merge slowly with "fancy" adding first then I'll try with more important updates !

[Leodagan]

Comitted : DOL SVN Revision 3358

- Some more cleanup on code
- Small fix to GameNPC to handle Living Equipment update instead of its own method
- Update to Util with the method I was using (Crypto Random, Multiple keyword for Pet /say command, List<T> Shuffle...)

This is a small one, I'm getting tired for today ! And it's getting harder to find harmless code to merge

[Tolakram]

Did you fix the issue that cropped up on Storm where abilities no longer had an icon?

[Leodagan]

Really ? I'm checking frequently that "stealth" icon is working because it's specific, it's a linespec icon and a clik'able icon...
And appart from that I'm using sprint frequently as a basic ability test...

I had no issues when working on a storm DB with actual SVN...

[Tolakram]

It was reported here and you replied, but it was minutes before the 1.115c fiasco so maybe forgotten. Trying to find the thread.