Code: Alles auswählen
/138+139
int hue2 = pvSrc.ReadInt16();
//140-141 - Fixed
int face = pvSrc.ReadInt16();
Console.WriteLine("Face:{0:X4}",face);
//142+143 - Fixed
int hairHuef = pvSrc.ReadInt16();
//144+145- Fixed
int hairValf = pvSrc.ReadInt16();
sicher kann man das überladen. Aber: Dazu muss der Kram erstmal beim Client sein.
Bisher: Scripter/Programmierer baut einen neuen Dialog, legt Hintergrund, Buttons, Tiles, Gumps, Texteingaben, wasauchimmer fest. Im Skript (oder im C#-Code bei RunUO, menno
). Das wars. Der ganze Ramsch wird on the fly zum CLient geschickt, der es darstellt.Jetzt: Alle Dialoge müssen vor dem Start des Clients bei diesem vorliegen und können dann nur noch vom Server aus aufgerufen werden (wie ein Cliloc eben, inkl. Text-Parameter); im Günstigsten Fall kann man dem Client selbstgebaute Dialoge "unterschieben", im ungünstigsten nur vorhandene ändern.
Damit wäre KR ein absolutes No-Go nicht nur für stark gepatchte Shards, sondern auch für jene, die ihre eigenen Gump-Dialoge haben - und welcher "lebendige" Shard hat die nicht? Die Hälfte aller Rassen-/Klassen-Systeme und was weiss ich ist ohne eigene Dialoge nicht denkbar.
Ich hoffe ja immer noch darauf, eine Art "wildcard dialog packet" zu finden, das XML und LUA als payload transportiert. Indes, für OSI ist so eine Funktion nicht wichtig - die ändern an den Servern eh nur etwas, wenn sie down sind, und beim nächsten Login werden die Clients gepatcht. Kann man natürlich nachmachen - vorausgesetzt, man entwickelt auch einen brandneuen Patcher :-/
Vielleicht solltest Du einfach mal posten, welche Packets Du inzwischen analysiert hast. Mir sind 0x29, 0x8D, 0xA9, 0xE0, 0xE1, 0xE3, 0xE4, 0xEC und 0xED (mehr oder weniger) klar
![:]](./images/smilies/icon_pleased.gif "Freude"){kind=icon}