Moin,

habe das Problem, dass ich kurz nach dem einloggen keine Spieler Chars mehr sehen kann. NPCs und Gebäude sind noch da, aber etwa 10 sec nach dem einloggen sind alle anderen Spieler Chars nicht mehr zu sehen - ihre interaktion mit mobs sehr wohl.

Habt ihr ne Idee woran das liegen kann?

Das Problem scheinen mehrere zu haben, hast Du daoc neu installiert und dann gepatched und danach den Uthgardpatch installiert?
Oder nutzt Du evtl. eine alte Daoc Version mit der Du auf nem anderen Shard o.ä warst ?

http://www.uthgard.net/forum/viewtopic.php?f=15&t=36459&start=15

Added an entry for how to disable UDP permanently (not recommended):
https://uthgard.org/howto#5

Laothiel wrote:Moin,

habe das Problem, dass ich kurz nach dem einloggen keine Spieler Chars mehr sehen kann. NPCs und Gebäude sind noch da, aber etwa 10 sec nach dem einloggen sind alle anderen Spieler Chars nicht mehr zu sehen - ihre interaktion mit mobs sehr wohl.

Habt ihr ne Idee woran das liegen kann?

Ich hatte das gleiche Fehlerbild auf dem Live Server. Ich weiß nicht, ob die Ursache identisch ist, ich kann dir aber sagen, wie ich das Ganze beheben konnte:

Mein Internetprovider ist Kabel Deutschland. Standardmäßig wird dort ein IPv6 Protokoll verwendet. Dieses führt aber dazu, dass (zumindest auf dem Live Server) nach ein paar Sekunden alle Spieler verschwinden und man keinen mehr sehen kann. Ich habe dann bei Kabel Deutschland den Support angerufen und meinen Anschluss auf IPv4 Protokoll umstellen lassen. Seitdem funktioniert alles einwandfrei und ich kann alle Spieler sehen.

Ich kämpfe gerade mit dem selben Problem. Gestern war es dann so schlimm, dass selbst reconnecten nichts mehr brachte, weil mein Kollege nach dem ersten Bewegen nach dem Rebuffen sofort wieder weg war. Ich habe dann mal mit integriertem Skin statt BobsUI 1.110 v6.00 gestartet. Das ging dann (zufällig?) den ganzen Abend gut. Ich werde aber noch ein paar Abende testen müssen, um das zu verifizieren.

Falls es wirklich an BobsUI liegen würde, welche Alternativen gibt es denn für Classic Servers? Oder würdet ihr die 1.117 v7.0 empfehlen? Klingt aber on den Icons her halt nicht mehr "klassisch". Das gefällt mir ja gerade an dem Skin, besonders da er den "Derida-Style" für die Dialoge unterstützt, welchen ich damals auf live nutzte.

Ich hatte übrigens erst direkt über den Genesis-Client drüber installiert, dann hab ich die Genesis-Patch deinstalliert, Mythic gepatched und Uthgard repatched (danach waren einige Buff- und Icons gefixt), und zum Schluss nur noch den ui/custom-Ordner gesichert, DAoC deinstalliert, Ordner geleert, und komplett mit dem EA-Installer und Uthgard-Launcher reinstalliert. Also blitzblanker kann eine Installation imho. nicht sein.

Das Einzige, das mir zufällig vorhin im Ressourcenmonitor aufgefallen war ist, dass DAoC 2 Verbindungen aufbaut, gemischt über IPv4 und IPv6. Remoteport für IPv4 ist 10307 TCP und für IPv6 80 TCP. Auf der IPv6-Connection läuft aber kein Traffic. Den IPv4 UDP port kann ich mit dem Ressourcenmonitor nicht überwachen. Erwähnenswert an der Stelle wäre evtl., dass Kabel Doofland/Vodaphone mit DS-Lite-Tunnel arbeitet bei IPv6-Anschlüssen. Aber das Ausbleiben von Paketen erklärt doch nicht, das gleichzeitige Verschwinden aller Spielercharakter, wärend alle Mobs und Pets sichtbar bleiben. @_o Eher müssten diese doch bis zum Eintreffen neuer Pakete in die alte Richtung laufen/laggen.

Edit: Auf dem PC, wo ich das Problem hab, gibt es überhaupt keine Port 80 TCP-Verbindung. Hatte eben das Problem auch mit Atlantis-Skin... liegt also nicht am BobsUI. Muss mal schauen, ob ich im Virenscanner oder der WinFirewall noch was freischalten kann.

Das Problem wird immer merkwürdiger. Gestern in Celedonia hatte ich es auch mal wieder, auf dem Porter nichts Ungewöhnliches, laufe Caledonia HPK heraus und sehe nur die Ench pets. Ein bissel hin und herlaufen, tauchen die Spieler auf. Kurz darauf wieder alle verschwunden. Reloggen, alle Spieler blieben für die nächsten ~5min wieder stabil.

Ich bin völlig ratlos, was es sein könnte. Firewall läuft nur die fritz.box und Windows Firewall, als Virenscanner ist BitDefender im Einsatz. Auf einem anderen PC an der selben fritz.box mit der selben Windows-10-Version habe ich das Problem bisher nicht beobachtet.

Prüf mal ob UDP Pakete problemlos durchgehen. Spieler-Positionen werden mit UDP versendet.

Dass Du Spieler siehst wenn Du rumläufst liegt daran dass wenn sie erstmalig in view kommen sie mit einem TCP Paket angelegt werden im Client. Die nachfolgenden Bewegungen der Spieler werden aber mit UDP gesendet.

Das größte Problem bei IPv4 UDP sehe ich in meinem DS-Lite-Tunnel von Kabel Doofland/Vodafone. Aber ich sag mal, meistens geht es ja und reloggen hilft auch meistens, aber es kann auch nach mehrmaligem reloggen nicht klappen, die Update-Informationen kommmen dann ja irgendwie doch meist... aber halt nicht zuverlässig immer, ich schätze mal es muss von mir über die selbe Port-Kombination ein UDP-Paket zum Server laufen, bevor vom Server diese zurück zu mir fanden (NAT-Prinzip). Aber wie sende ich bewusst ein UDP-Paket zum Server über den Datenkanal, um so etwas zu testen? ^-^ Selbst bewegen scheint zwar also so ein Aufblinken zu bewirken, aber so ein "geil jetzt gehts" hatte ich mit Bewegen noch nie.
Was ich halt komisch finde ist, dass selbst Charaktere, die stehen, verschwinden und es meist alle oder keine Spieler sind. Abet Pets sehe ich immer, die bewegen sich sogar.

Dein Client sendet UDP Pakete wenn Du Dich selbst bewegst. Du kannst einen Freund bitten Dich von einem anderen Rechner ingame zu beobachten ob er Deine Bewegungen sehen kann. Wenn Du Dich in seinem Client nicht bewegst dann sind UDP Pakete blockiert.

Hatte gestern das Problem noch einmal. Kam in CM rein (also im Sinne von durch den Eingang geportet), sah die Leute. Diese verschwanden dann nach einigen Sekunden (halbe Minute?), bewegte mich, dann tauchten sie auf, verschwanden nochmal für 1-2 Sekunden und blieben dann wieder permanent sichtbar. Hatte da keine Chance schnell noch den Ressourcenmonitor zu öffnen zum Schauen, ob da was Auffälliges zu sehen wäre.

Wird nach dem Zoning eine neue UDP-Verbindung aufgebaut evtl.?

UDP ist verbindungslos.

Firewall/NAT koennte aber komisches verhalten verursachen ...

TheKrokodil wrote:UDP ist verbindungslos.

Firewall/NAT koennte aber komisches verhalten verursachen ...

naja, jeder hat firewall und NAT, das waer ja dann ein andauerndes problem ... wenn Probleme jedoch zur gleichen Zeit fuer eine groessere Menge Spieler auftritt (wie gestern abend disconnects and lags) dann danke ich ist der Fehler eher auf der Serverseite

(Disconnect & Lags) != (Verschwindende Spieler)

Zwei verschiedene Probleme

Gestern war es auch wieder verhäuft aufgetreten, aber da hatte der Server ja sowieso ein Schluckauf. Rumlaufen hat nichts gebracht, auch nicht im BG am PK z. B. mehrfach durch die Tore porten. Komplette Gruppe war verschwunden, andere sahen meine Bewegungen, konnten mich in Gruppe einladen, buffen, etc.. Aber ich konnte niemand sehen und auch niemand via Gruppe markieren. Passierte 2mal, leider hat der Ressourcenmonitor nicht mal ein Paket-Counter, sodass ich leider echt ohne Fiddle or so nichts über den UDP-Traffic sagen könnte. Ich war auch, wenn es kein Vorbote vor einem Massen-LD war (was ironischerweise ähnliche Symptome hat), in der Gruppe immer der Einzige mit dem Problem. Leider kann ich in der fritz!box auch nicht aktivieren, dass alle UDP-Ports an diesen PC gehen sollen, von der selben IP wie eine TCP-Verbindung auf Port x besteht. Aber wenn das ein Problem wäre, wären sicher andere fritz!box-User in merklicher Anzahl betroffen.

Aber Firewall mäßig habe ich wirklich nichts aktiv. Die interne Firewall der fritz!box ist es bestimmt nicht, das hätten andere Probleme mit. Interne Firewall von Windows 10 gilt das Selbe. Für letzteres habe ich auch explizit die uth.dll für alles freigegeben. Auch ergäbe es ja auch wenig Sinn, dass Reloggen etwas bringt, wärend bewegen nicht. Mutmaßlich würden beide Traffic über den UDP-Kanal senden, aus Firewall/NAT Sicht sollte das doch auf das Selbe herauskommen, oder nicht? Leider ist der UDP-Port auch nicht fix, sodass ich ihn auch nicht explizit in der fritz!box als Port-Mapping eintragen könnte. Reconnecten aus der Charakterauswahl wechselt auch kein UDP-Port. Würde er auf eine UDP-Portrange kommen, die in der fritz!box auf ein anderen PC geleitet sind, dürfte auch gar nichts funktionieren. Denn dann ginge ja kein einziges Packet durch und das Problem müsste auftreten bis ich DAoC neustarte und einen anderne Port bekäme. Zumal ich nicht denke, dass ein Port unter 10000 von DAoC überhaupt benutzt wird. Die Ports, waren bisher immer in den 40 oder 50k rum.

Einziges NAT über das ich keinen Einfluss habe, ist das NAT vom DS-Lite-Tunnel mit der IPv4<->IPv6-Übersetzung. Aber da das Vodofone mittlerweile auf allen Neuen und angeblich auch schon auf vielen Altverträgen (vermutlich nur wo das Modem es unterstützt) umgeschaltet hat, sollte ich ja auch nicht so einsam sein mit dem Problem. Mein Kollege im Teamspeak hat leider Telekom, sodass ich das weder bestätigen noch ausschließen kann.

Code: Select all

|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                               fritz.box -    0 | 3341 | 3341 |    0 |    0 |   11 |    1 |
|        83-169-183-125-isp.superkabel.de -    1 | 3330 | 3327 |   13 |   26 | 1016 |   21 |
| ip5886ea55.dynamic.kabel-deutschland.de -    1 | 3295 | 3283 |   13 |   22 |  914 |   16 |
| ip5886eae9.dynamic.kabel-deutschland.de -    1 | 3318 | 3312 |   15 |   24 |  915 |   17 |
| ip5886eacf.dynamic.kabel-deutschland.de -    1 | 3326 | 3322 |   16 |   25 |  969 |   23 |
|          kabeldeutschland-gw.hetzner.de -    1 | 3326 | 3322 |   15 |   25 |  997 |   22 |
|                        core1.hetzner.de -    1 | 3307 | 3298 |   15 |   24 |  997 |   18 |
|                       core24.hetzner.de -    1 | 3338 | 3337 |   20 |   29 | 1004 |   26 |
|                   ex9k1.rz19.hetzner.de -    1 | 3315 | 3308 |   20 |   29 |  916 |   21 |
|                      server.uthgard.net -    1 | 3323 | 3318 |   20 |   29 | 1005 |   26 |
|________________________________________________|______|______|______|______|______|______|
   WinMTR v0.92 GPL V2 by Appnor MSP

Packet-Lose sind unter 2 Promille. Ich sehe auch kein Zusammenhang zum Problem. Hatte heute Mittag einmal länger WinMTR laufen lassen und eben als das Problem wieder auftrat, war immer noch kein Packet-Lose über 1% festzustellen, auch die Pings, die zeitgleich rausgehen bleiben nicht zeitgleich aus, die verlorenen Pakete bauen sich also verstreut auf und sind unter 100 Pings noch bei jedem nicht so halbwegs gleichmäßig verteilt wie in dem längeren Auszug. Auch die Ping-Laufzeit ist relativ stabil mit den gelegentlichen Ausreißern, aber das ist ja normal im Internet.

Ich habe das Problem seit einigen Tagen auch wieder. Interessanter Weise sehe ich meine Gruppenmitglieder, aber die Feinde nicht. Das kann also nichts mit dem UDP zu tun haben. Sonst würde ich meine Verbündeten ja auch nicht sehen.
Vielleicht könnte man hier so das ein oder andere Testscript zur Verfügung stellen, mit dem man testen kann ob der eigene PC alle Anforderungen erfüllt damit die Darstellung ok ist.
Was ich nicht verstehe, ist dass es nur ab und zu ist. Ich kann das leider nicht reproduzieren.