Pre-implementation 1.115 client [SVN:3329]

[Leodagan]

Hello,

I committed some code to trunk to begin handling 1.115 client packets.

Actually there is still some merge needed from Eden branch for this to be working.

I committed this to have some help from other contributors that could document/research the new field in "ItemData"

The v1.115 packet code add a "Short" in front of the "Level Byte" of ItemData packet sent through InventoryUpdate (0x0002 S=>C packet) its use is unknown to me...

All I can say is that on live this field is pretty much changed with every items, and when my server send "(ushort)0" it doesn't display the bonus level needed for this item in tooltip as it does on Live client !

Here is a packet logged :

Code: Select all

<RECV TCP Time: 00h00m07s768ms Code:0x0002 Len: 808> 0D 00 00 00 22 01 0A F7 F0 33 A5 2A 00 C4 00 00 ...."..÷ð3¥*.Ä.. 14 64 64 64 23 2F 0F 87 01 00 49 02 4B 14 56 69 .ddd#/.‡..I.K.Vi 72 75 6C 65 6E 74 20 53 6F 75 6C 20 53 61 70 70 rulent Soul Sapp 65 72 0C F7 FE 2D 17 00 00 2D 00 00 14 64 64 64 er.÷þ-...-...ddd 23 2F 0F 91 01 00 48 1A 33 4E 16 41 72 63 61 6E #/.‘..H.3N.Arcan 65 20 53 68 69 65 6C 64 20 6F 66 20 4D 61 67 69 e Shield of Magi 63 3A 08 0F 44 72 61 67 6F 6E 27 73 20 52 65 66 c:..Dragon's Ref 75 67 65 00 12 4C 61 6D 65 6E 74 20 6F 66 20 44 uge..Lament of D 61 72 74 6D 6F 6F 72 17 F8 02 33 66 1B 00 23 00 artmoor.ø.3f..#. 00 10 64 64 64 23 2F 0F 9F 04 00 49 02 00 1F 43 ..ddd#/.Ÿ..I...C 68 61 72 72 65 64 20 44 72 61 67 6F 6E 73 63 61 harred Dragonsca 6C 65 20 43 68 61 69 6E 20 42 6F 6F 74 73 18 2F le Chain Boots./ 8C 32 00 00 00 29 00 00 04 64 64 64 23 2C 01 FD Œ2...)...ddd#,.ý 01 00 00 00 00 0E 53 74 6F 6E 65 77 61 74 63 68 ......Stonewatch 20 50 69 6E 19 F7 F3 33 66 1B 00 23 00 00 0A 64 Pin.÷ó3f..#...d 64 64 23 32 0F 9B 04 00 35 02 00 14 54 69 6D 65 dd#2.›..5...Time 6C 65 73 73 20 49 6E 64 69 67 6F 20 4D 61 69 6C less Indigo Mail 1A BF 74 32 00 00 00 29 00 00 0F 64 64 64 23 23 .¿t2...)...ddd## 06 BA 01 00 12 08 1F 76 0E 41 72 63 61 6E 65 20 .º.....v.Arcane 48 65 61 6C 69 6E 67 00 16 58 61 6E 78 69 63 61 Healing..Xanxica 72 20 52 65 6D 6E 61 6E 74 20 43 6C 6F 61 6B 1D r Remnant Cloak. 30 0F 32 00 00 00 29 00 00 01 64 64 64 23 32 00 0.2...)...ddd#2. 65 01 00 00 00 00 19 50 6F 74 65 6E 74 20 44 65 e......Potent De 61 74 68 77 61 74 63 68 65 72 20 43 68 61 69 6E athwatcher Chain 20 2F 90 32 00 00 00 29 00 00 06 64 64 64 23 2E /2...)...ddd#. 02 55 01 00 00 00 00 15 42 65 6C 74 20 6F 66 20 .U......Belt of 74 68 65 20 50 72 6F 74 65 63 74 6F 72 21 BF 72 the Protector!¿r 32 00 00 00 29 00 00 01 64 64 64 23 2F 02 56 01 2...)...ddd#/.V. 00 00 18 27 6B 14 53 74 72 6F 6E 67 20 41 62 6C ...'k.Strong Abl 61 74 69 76 65 20 41 75 72 61 33 45 19 41 72 63 ative Aura3E.Arc 61 6E 65 20 53 68 69 65 6C 64 20 6F 66 20 53 74 ane Shield of St 72 65 6E 67 74 68 00 16 42 72 61 63 65 72 20 6F rength..Bracer o 66 20 41 72 63 61 6E 65 20 56 69 67 6F 72 22 BF f Arcane Vigor"¿ 72 32 00 00 00 29 00 00 01 64 64 64 23 2F 02 56 r2...)...ddd#/.V 01 00 00 18 27 6B 14 53 74 72 6F 6E 67 20 41 62 ....'k.Strong Ab 6C 61 74 69 76 65 20 41 75 72 61 33 45 19 41 72 lative Aura3E.Ar 63 61 6E 65 20 53 68 69 65 6C 64 20 6F 66 20 53 cane Shield of S 74 72 65 6E 67 74 68 00 16 42 72 61 63 65 72 20 trength..Bracer 6F 66 20 41 72 63 61 6E 65 20 56 69 67 6F 72 23 of Arcane Vigor# 2F 8D 2A 00 00 00 29 00 00 0A 64 64 64 23 2A 00 /*...)...ddd#*. 67 01 00 00 00 00 0F 42 61 6E 64 20 6F 66 20 45 g......Band of E 6C 64 73 70 61 72 24 F7 F9 32 00 00 00 29 00 00 ldspar$÷ù2...).. 01 64 64 64 23 30 00 67 01 00 00 18 27 6B 14 53 .ddd#0.g....'k.S 74 72 6F 6E 67 20 41 62 6C 61 74 69 76 65 20 41 trong Ablative A 75 72 61 33 4E 16 41 72 63 61 6E 65 20 53 68 69 ura3N.Arcane Shi 65 6C 64 20 6F 66 20 4D 61 67 69 63 00 17 52 69 eld of Magic..Ri 6E 67 20 6F 66 20 41 72 63 61 6E 65 20 47 65 73 ng of Arcane Ges 74 75 72 65 73 25 48 6A 32 00 00 00 29 00 00 0A tures%Hj2...)... 64 64 64 0A 05 10 AD 01 00 00 00 00 1B 45 78 65 ddd...­......Exe 6D 70 6C 61 72 27 73 20 4D 69 67 68 74 79 20 4D mplar's Mighty M 79 74 68 69 72 69 61 6E ythirian <RECV TCP Time: 00h00m07s784ms Code:0x0002 Len: 196> 03 00 00 00 22 02 29 D0 6F 01 00 00 00 29 01 00 ....".)Ðo....).. 00 64 00 00 00 00 00 74 01 00 00 08 1F AA 17 47 .d.....t.....ª.G 61 74 65 77 61 79 20 2D 20 50 65 72 73 6F 6E 61 ateway - Persona 6C 20 42 69 6E 64 00 1A 50 65 72 73 6F 6E 61 6C l Bind..Personal 20 42 69 6E 64 20 52 65 63 61 6C 6C 20 53 74 6F Bind Recall Sto 6E 65 2B 00 FA 01 0F 19 80 83 00 00 0A 64 64 64 ne+.ú...€ƒ...ddd 00 00 00 03 01 00 00 00 00 15 62 72 6F 6E 7A 65 ..........bronze 20 70 72 61 63 74 69 63 65 20 73 77 6F 72 64 2C practice sword, 18 7B 00 6E 00 00 00 00 00 00 64 00 00 00 00 02 .{.n......d..... 02 01 00 00 08 1F AA 0C 52 65 61 6C 6D 20 52 65 ......ª.Realm Re 73 70 65 63 00 1E 31 31 30 20 4C 75 6D 69 6E 65 spec..110 Lumine 73 63 65 6E 74 20 45 78 65 72 65 67 75 6D 20 53 scent Exeregum S 74 6F 6E 65 tone

[Leodagan]

After more analysis : this looks like an internal ID !

I tried to buy some items on live to check this value, items bought following a merchant list have this value incremented one by one.

When crafting the same item this code is always the same, even after imbuing, when choosing another item to craft next to the first one the number is incremented or decremented slightly, the first albion item was created with this flag @ "0x0001" the next item was "0x0003" the next one was "0x0004" etc...

This ID is not unique, most of metal bar use the same, I don't really know what the client is using this field for, I'll try to send random value, and check if my tool tip trouble is not another bug...

[Graveen]

Wow. Good. I'm actually playing a bit on live, if you need things out of Pendragon.

[Leodagan]

My recent improvements over 1.115 comes from packet Logging on Pendragon with a test account

There is still some change around "show warmap" packet code with new Agramon Area, I have a server packet and client packet patch ready for this to just change the map index on a 0-base instead of 1-base, but there is also some "rules" changed around keeps in v1.115 and after getting all around the DOL Keep Manager, I just don't want to work with this code

Shard Admin's will need to find their own way to set keep to "permanently destroyed" or anything

[Graveen]

Haha Actually improving my siegecraft talents and trying to gather new SC on live, this should rock

[dargon]

I think you could almost do a destoryed keep, like how towers and keeps are set up, im not positive on numbers, but a tower in the keep DB has to have a key number of over 200 or something to that extent, we could just have numbers over say 400 be "destroyed keeps", where the HP is always set to 0/1, i would be willing to do tests on this some time next week, if you all think that this would be a good way of going about it.

[Leodagan]

The Current Keep Manager rely WAY too much on Keep ID to set up Frontiers...

And actually it's totally based on real Keep ID sent by Live Servers, using strange computation to enable map/indexing on the warmap !

I don't know if the keep manager can work with anything else than a packet dump database, and if it can then how it should be used except from trying to mimic the live records (which is pretty damn annoying to change anything around keeps !!)

The easiest way to fix this would be a hardcoded id list of keep, which is pretty ugly, or a new field in the keep table, enabling the manager to set keep as destroyed on startup or something similar...

[Tolakram]

Be sure to take advantage of my new keep manager code and create a manager just for this new version, so we don't break the old one and older client support.

What a nightmare.

[Leodagan]

Your new keep manager ?

I haven't seen anything except from the standard Keep Manager...

I don't think Keep Manager can break "player client version" as soon as it never relies on "Packets" and just implement interfaces that allows PacketLib to send the correct packets...

And from what I tested, Warmap or Frontiers Layout does not need "Keep ID" to be fixed, you just need to set "appart" Warmap IndexID and KeepID, one to be compatible to the client, the other one just to track your keep without any fixed ID that compute Index ID... for now Index ID is something like (KeepID - 25 / 25) which give and index between 1 and 6 I think...

[Tolakram]

Yea, the fact you can create a new keep manager and assign it as default on startup in server properties, similar to replacing the gameplayer class. I'm unclear on all the changes needed for 115 but at least with a new keep manager there won't be a risk of breaking the old one for older clients. It IS very fragile and will break when you least expect it.

Anyway you know best here, just suggesting it if you find keep support needs to change for some reason.

[Leodagan]

I'm actively trying to rely on the existing interfaces "IKeep" "IKeepManager" etc..., I think I made some new one or changed some old one to implement more methods or properties REALLY needed for an "IKeep" to be sent by PacketLib... And even for specifics needs (Typically New New Frontier Rules) I use Subclass of Interface (Sub-Interface ??), something like "interface INewFrontierKeep : IKeep"

Actually these Interfaces don't implement enough methods or fields to be able to implement an "own keep manager", typically I needed new Interface for GameKeepComponent, GameKeepHookpoint, GameKeepPosition even IDoor is not enough for a GameKeepDoor interface... So I'm adding some Interface to the Core and try to match them to existing keep Manager and my new one; eventually for "other use" but it's enough work already to not think of what other people could try to do

A lot of Game Code rely on AbstractKeep which is the first implementation of IKeep, but then you can hardly implement IKeep without extending AbstractKeep, the same goes for other interfaces...

When you switch "Abstract Implementation" to "Interface" in object Method (like PacketLib SendKeepInfo) you will see quickly how much of properties are needed for the Interface to at least fully implement the packet properties for a Custom Keep Class to be sent by network...

So my first constraint for upgrade is to at least use interfaces that have enough method for the PacketLib, thus I will change the current Interface and try to implement the new methods in Current AbstractGameKeep (It's not really hard, the Keep Interface was missing Location X/Y, the Abstract class already implemented this...)

Then it's to track every "in game rules" about Keep, like damage calc or spell calc, that will mostly need an "AbstractGameKeep" class or a designated subclass of the "vanilla Keep Manager", thus not allowing for other implementations... I will try to switch those class or abstract class for Interface checks or Interface Methods...

This should Allow anybody to load a custom Keep Manager, because I lurked around the code and I think there is some server properties to configure your keep manager implementation at startup rather than destroying code, but as no one (I think...) ever tried to write a new implementation from this there are a lot of flows, and a lot of legacy code that wont bother using the designated Interfaces...

[Tolakram]

D2 has its own keep manager, which is why I added all of that to the core. My goal for D2 was to be able to customize everything without having to put custom code in my core. This pushed development of core code that would allow me to replace all or parts of a lot of pieces, making the core more customizable.

So when I say replace keep manager I mean the ugly way. Copy all the code, rename it, use it as the new manager. If it ends up working better and with older clients then we make it the default keep manager. My goal is to keep the core as stable as possible AND push new development when needed. In my experience you can accidentally break something without knowing it and then eat up a lot of time with compatibility issues that could have been avoided.

Like I said though, you are IN the code now, not me, so you will have the best idea how to move forward with this.

[Leodagan]

Well I'll give you more details on my implementation when I'll change my workstation motherboard that burned this week end

I couldn't work on this new manager since last week I don't remember where I stopped, the easiest thing when I'll be "near end" will be to give you the Interfaces changes and see if this can work up with your custom D2 code.

Interfaces are meant to be use for this, so there is no reason to do it "quick and dirty" (anyway I haven't started this Manager Module as a quick and dirty solution), I intend to keep the actual Keep Manager, because I rely on new tables and data that are more "Object View" of Keeps than the current Keep Manager for which tables are "Packet view" of Keeps

For now Everything is in "GameServerScript" except for the Interfaces, which could allow me to distribute easily this Keep Manager as an "add-on" for those that do want to try latest improvement on New New Frontiers (and maybe after it's enough tested it could be used as default Keep Manager)