Shard-Problem

Hab da ein paar Probleme mit meinem Shard (RC2 Final). Ein Kumpel hat mir Stygian Abyss Classic (patchnr. 7.0.3.0) runtergeladen. Hab im Datapath den Eintrag zu dem Stygian Abyss verzeichnis gewechselt, bei Razor hab ich das auch gewechselt. Datafiles sind auch von Abyss in den Shard genommen worden. Problem ist jetzt folgendes. Ich komm mit Razor (latest update) zum einlogbildschirm, kann einloggen, den Shard wählen und dann hängt es bei Connecting fest. Das gleiche Prob hab ich bei ConnectUO 2.0. Kann mir da irgendwer helfen, das das wieder geht? (hab noch ne UO-Installation mit dem patchnr. 6.0.9.3 daheim. da geht es mit razor und connect uo. nur nicht bei Abyss :( )

Das liegt entweder daran das Razor noch nicht die Verschlüsselung vom Client rausgehauen hat (bei Standardeinstellungen sollte das aber so sein), oder das im RunUO die neue Version nicht erkannt wird.. Im Ordner Scripts/Misc gibts ne Datei namens ClientVerification.cs oder so, da solltest du fündig werden.

meintest du diese Passage :


//ClientVersion.Required = null;
//Required = new ClientVersion( "6.0.0.0" );
?

hab das 6.0.0.0 auf 7.0.3.0 geändert. bleibe aber nach wie vor bei Connecting hängen. Razar sagt mir (trotz der Pfadangabe) das es keine Chiloc-Datei gefunden hat und deswegen einige Sachen nicht gelesen werden könnten. Egal ob mit oder ohne Razor - bei connecting geht es net weiter :cry:

Nein, Required ist nur eine Angabe für die Mindestversion die man benötigt..

Ich weiß nicht mehr genau wo dran es lag.. was sagt die RunUO Konsole?

Wenn ich den Shard starte (er hat die Datafiles von Abyss), kommt keine einzige Fehlermeldung. Sobald ich versuche über ConnectUO oder Razor reinzukommen, bleib ich bei Connecting hängen. Könnte es vielleicht am NoCryptClient2D liegen? der hat ne nr. von 5.0.4.5. Hab so ziemlich alles schon mal versucht. Hatte das "OSI"-UO auf dem Rechner (bei der Pfadangabe zum "normalen" UO kann ich mich einloggen) und Abyss - da blieb ich bei Connecting hängen. Hab das Abyss ins normale UO-Verzeichnis kopiert - gleiches Ergebnis. Abyss alleine drauf - bleib auch bei Connecting hängen.

Wieso der NoCrypt Client.. startest du den, oder den Client vom normalen UO?
Wenn du den NoCrypt Client startest muss natürlich eine Version bei Required unter der Version des NoCrypt Clienten angegeben werden.

Wieso sollte ich den NCC starten, wenn ich online an meinem Shard basteln will ? Ich gehe immer on, die Umleitung (wegen meiner täglich wechselnden IP) wird von mir aktualisiert, fahre den Shard hoch, warte bis er oben ist und versuche mich dann einzuloggen. Da kommt dann das Problem, was ich schon genannt habe (bei connecting hängenbleiben). Der Shard startet ohne Probs und Warnmeldungen. Nur das Connectingproblem ist halt vorhanden.

Ich weiß das man für SA in Misc/MapDefintions.cs die neue Map noch definieren muss, aber das hat nichts mit dem einloggen zu tun soweit ich mich noch dran erinnern kann.

Code:

using System;
using Server;

namespace Server.Misc
{
public class MapDefinitions
{
public static void Configure()
{
/* Here we configure all maps. Some notes:
*
* 1) The first 32 maps are reserved for core use.
* 2) Map 0x7F is reserved for core use.
* 3) Map 0xFF is reserved for core use.
* 4) Changing or removing any predefined maps may cause server instability.
*/

RegisterMap( 0, 0, 0, 7168, 4096, 4, "Felucca", MapRules.FeluccaRules );
RegisterMap( 1, 1, 1, 7168, 4096, 0, "Trammel", MapRules.TrammelRules );
RegisterMap( 2, 2, 2, 2304, 1600, 1, "Ilshenar", MapRules.TrammelRules );
RegisterMap( 3, 3, 3, 2560, 2048, 1, "Malas", MapRules.TrammelRules );
RegisterMap( 4, 4, 4, 1448, 1448, 1, "Tokuno", MapRules.TrammelRules );
RegisterMap( 32, 5, 5, 1280, 4096, 1, "test", MapRules.FeluccaRules );

RegisterMap( 0x7F, 0x7F, 0x7F, Map.SectorSize, Map.SectorSize, 1, "Internal", MapRules.Internal );

/* Example of registering a custom map:
* RegisterMap( 32, 0, 0, 6144, 4096, 3, "Iceland", MapRules.FeluccaRules );
*
* Defined:
* RegisterMap( <index>, <mapID>, <fileIndex>, <width>, <height>, <season>, <name>, <rules> );
* - <index> : An unreserved unique index for this map
* - <mapID> : An identification number used in client communications. For any visible maps, this value must be from 0-3
* - <fileIndex> : A file identification number. For any visible maps, this value must be 0, 2, 3, or 4
* - <width>, <height> : Size of the map (in tiles)
* - <name> : Reference name for the map, used in props gump, get/set commands, region loading, etc
* - <rules> : Rules and restrictions associated with the map. See documentation for details
*/

TileMatrixPatch.Enabled = true; //OSI client patch 6.0.0.0
}

public static void RegisterMap( int mapIndex, int mapID, int fileIndex, int width, int height, int season, string name, MapRules rules )
{
Map newMap = new Map( mapID, mapIndex, fileIndex, width, height, season, name, rules );

Map.Maps[mapIndex] = newMap;
Map.AllMaps.Add( newMap );
}
}
}

Ansonsten, ohne eine Konsolenausgabe / Fehlermeldung wäre ausprobieren angesagt. Ich weiß nur das ich es mit 7.0.0.0 schon geschafft habe. Die Clients danach sollten aber auch gehen (es sei denn die haben was an den packets geändert.. das kann ich mir aber nicht vorstellen).

der Witz ist ja, das bei beim Startfenster des Shards (wenn ich ihn hochfahre + etwaige Fehlermeldungen kommen) gesagt wird, das ich in der Charakterlist bin. nur connecten tu ich halt leider nicht :(

Demnach ist ein Encryption Problem des Clients ausgeschlossen.
Mit jeder anderen Version kannst du connecten?
Da es keine Konsolenmeldung gibt gehe ich auch davon aus das die Client Verifikation keine Probleme macht.

Übrig bleiben also evt. geänderte Packets.. Aber ich bin mir sicher das mal zum Laufen bekommen zu haben.

Meld dich mal im icq bei mir: 274015704
Dann testen wir mal ob du mit deiner Client Version auf meinen Server zugreifen kannst (hab die Dateien sicherlich noch irgendwo in meinen Scriptarchiven rumliegen)

Die RC2 Final sollte zwar den 389er SVN Commit für den 7.x Client drin haben, aber es gab ein paar Tage später nochmal einen Nachschlag der m.M.n. nicht dazugehört -> SVN 404 hat nochmal das packet handling verändert. Falls du das noch nicht eingepflegt hast könnte das eine Ursache sein.