Kein Netzwerk-Training möglich

Wir glauben nicht, daß es eine Steel Beasts-spezifische Ursache hat.
Eher dürfte eine externe Fehlerquelle in Betracht kommen - eine Firewall, oder ein Router mit unerwartetem Verhalten. Die Fehlermeldung "Verbindung zum Veranstalter abgebrochen" zeigen wir ausschließlich in dem Fall an, daß von DirectPlay selbst die Nachricht DPSYS_SESSIONLOST empfangen wurde. Mit anderen Worten, wir sind hier mindestens eine Stufe "unterhalb" vom SB Code (nach ISO-OSI Netzwerkschichtmodell).

Du hast zwar extra darauf hingewiesen, daß Ports etc. korrekt eingerichtet sind, aber irgendetwas scheint dennoch die Verbindung zu beeinflussen. Mit den vorliegenden Informationen können wir nicht mehr dazu sagen.

Gibt es die Möglichkeit in SB, den Log-Level zu erhöhen? Mehr Details also? Vielleicht lässt sich daraus was ableiten?

Die Fehlermeldung tritt nur bei externen Fehlerquellen auf (vgl. Antwort Nr. 1). Daher kann auch ein erweitertes Error-Log in diesem Fall keinen Erkenntnisgewinn bringen.

Ich möchte mich hier dem Problem von Dr. Thodt anschließen. Ich habe, seitdem ich Windows 8.1 habe, genau das gleiche Problem. In habe bei mehreren Sitzungen, bei welchen mir sämtliche Kameraden dieses Forums geholfen haben, dasselbe Problem. Es geht, wenn überhaupt, nur über Hamachi. Vorher war aber alles in Butter. Wie kann das sein?
Ich habe es in einer 1 1/2 Stunden Sitzung mit Erazor, es gerade einmal geschafft, dass ich jemanden reinlassen kann, aber ich selber kann nicht raus. Das mit Hamachi ist zwar gut und schön, aber kann keine Dauerlösung sein, da es ja vorher sehr gut lief.
Ich bitte hier noch einmal um die HIlfe von eSimGames. Vielleicht habt ihr ja etwas bei der Bug-Beseitigung übersehen. Kann ja sein. Oder vielleicht habt ihr einen Vorschlag für unser Problem und wei wir es lösen können. Und ich bitte hier um kein IT- Kauderwelsch, sondern um eine mundgerechte Lösung für den den OG Dosenkohl.

Ich möchte bitte wieder mitspielen können, ohne Probleme und die Anderen verzögern zu müssen.

Vielen Dank im Voraus sagt der

GepardtKdt

Unmittelbar habe ich keine Lösung anzubieten. Aber wir werden möglicherweise eine offene Beta-Version bereitstellen, die auf einem neuen Netzwerk-Code basiert. Vielleicht löst sich das Problem damit von allein, da Port-forwarding und ähnlicher Tinnef dann komplett überflüssig wird.

Also, es hat sich herausgestellt, daß das Problem bei Windows 8.1 auftritt, und zwar bei vielen 8.1-Nutzern und vielen anderen Spielen auch, z.B. hier oder hier. Hier ist Microsofts offizielle Seite zu dem Thema.

Kurzum, es sieht so aus, als hätte MS hier einen kapitalen Bock geschossen. Die "DirectPlay"-Schnittstelle wird offiziell nicht länger unterstützt, das ist auch schon vor einiger Zeit angekündigt worden. Bei Windows 8.0 wird sie aber noch regulär installiert, bei 8.1 hingegen nicht, bzw. sie wird nachinstalliert, sobald eine Anwendung sie erstmaling anfordert. Leider wird aber eine veraltete Version von DirectPlay installiert und nicht diejenige, die man in der letzten Version von DirectX 9.0c bekommt. Manche Spiele kommen unter manchen Bedingungen damit klar, andere aber nicht. Daher zeigt sich ein uneinheitliches Fehlerbild.

Wir können daran gar nichts machen, außer SB Pro PE als "kompatibel zu Windows 8.0" einzustufen, aber eben nicht zu "Windows 8.1".

Wie bereits angedeutet, werden wir allerdings ein etwa zwei Wochen eine offene Beta-Version bereitstellen, die DirectPlay mit einem neuen Netzwerk-Stack ersetzt und daher dieses Problem eigentlich komplett umgehen müßte. Zweck der offenen Betaversion ist, sicherzustellen, daß die neue Multiplayer-Implementierung ein funktional vollkommen gleichwertiger Ersatz zur bisherigen Version ist. Dazu muß einfach damit gespielt werden, und Probleme müssen uns gemeldet werden. Sobald wir also sicher sind, daß der neue Netzwerk-Code funktioniert, werden wir ihn offiziell machen und ihn in ein weiteres (kostenloses) Update für SB Pro PE 3.0 einfließen lassen.
Parallel zu diesem nächsten Update (oder kurz danach) werden wir dann eine weitere offene Beta-Version einführen, die komplett auf 64-Bit-Code umgestellt ist. Wir hoffen, auf diese Weise eventuell auftretende Fehler entweder der 64-Bit-Umstellung isoliert zuweisen zu können, anstatt sie mit eventuellen Fehlern des normalen Netzwerk-Codes zu vermischen. Es wird dann für eine Übergangszeit bis maximal 2017 noch 32-Bit-Versionen von SB Pro und SB Pro PE geben, aber danach dann nur noch 64-Bit-Code. In den nächsten drei, vier Jahren sollte dann also ggf. mit dem nächsten PC-/Notebook-Kauf auch auf eine 64-Bit-Version von Windows umgestellt werden (sofern das nicht schon längst geschehen ist). Nur in einer 64-Bit-Version können wir ausreichend Speicher addressieren, um den Detaillierungsgrad der digitalen Geländedaten weiter anzuheben. Auch werden gewisse Abstürze, die in letzter Zeit aufgrund von Speichermangel auftreten, dadurch der Vergangenheit angehören. Es gibt also handfeste technische Gründe für diese harte Umstellung.

Eine weitere Frage an alle zu dem Thema... zusätzlich zu den hier beschriebenen Problemen, ein komisches Verhalten.

Seit dem Patch auf v3.011 und der damit verbundenen Geschwindigkeitsoptimierung des Szenarioaustauschs/-downloads hatten z.B. Erazor und ich Probleme beim DL von Szenarien.
Der Server wird ohne Probleme gefunden, der Connect ist reibungsfrei, die Weitergabefunktion wird aktiviert und der DL-Prozess startet.
Allerdings hört dieser bei 10-85% Fortschritt auf und die Clienten verlieren die Verbindung zum Server. Leider tritt dieses Verhalten nicht reproduzierbar auf, bzw. ist keine eindeutige Fehlerursache zu erkennen. Meist funktioniert die Dateiübertragung nach 3-4 Versuchen mit dem selben Szenario dann reibungsfrei.
Es ist hierbei unerheblich, ob es sich um 2.5, 2.6, 3.0 Szenarien handelt, ob Coop oder H2H, auf welcher Karte, in welcher Grössenordnung oder mit/ohne Navmesh.

Gibt es eine Möglichkeit, das Pakethandling zwischen SB Client und SB Server zu protokollieren? Ist sowas schon mal in einem LAN aufgetreten und kann es u.U. auf WAN-spezifische Ursachen zurück geführt werden?

Servus,

Falli(911) schrieb:

Eine weitere Frage an alle zu dem Thema... zusätzlich zu den hier beschriebenen Problemen, ein komisches Verhalten.

Seit dem Patch auf v3.011 und der damit verbundenen Geschwindigkeitsoptimierung des Szenarioaustauschs/-downloads hatten z.B. Erazor und ich Probleme beim DL von Szenarien.
Der Server wird ohne Probleme gefunden, der Connect ist reibungsfrei, die Weitergabefunktion wird aktiviert und der DL-Prozess startet.
Allerdings hört dieser bei 10-85% Fortschritt auf und die Clienten verlieren die Verbindung zum Server. Leider tritt dieses Verhalten nicht reproduzierbar auf, bzw. ist keine eindeutige Fehlerursache zu erkennen. Meist funktioniert die Dateiübertragung nach 3-4 Versuchen mit dem selben Szenario dann reibungsfrei.
Es ist hierbei unerheblich, ob es sich um 2.5, 2.6, 3.0 Szenarien handelt, ob Coop oder H2H, auf welcher Karte, in welcher Grössenordnung oder mit/ohne Navmesh.

Gibt es eine Möglichkeit, das Pakethandling zwischen SB Client und SB Server zu protokollieren? Ist sowas schon mal in einem LAN aufgetreten und kann es u.U. auf WAN-spezifische Ursachen zurück geführt werden?

kurios, ich hatte dieses Problem seit 2.654. Seit 3.002 funktioniert es einwandfrei.

MkG

Duke

Also bei mir ist das mit dem fehlerhaften bzw unvollständigen Download erst seit der aktuellen Version.

Und auch nur sehr sporadisch.

DirectPlay/DirectLobby nutzt Port 2300 für die "Suche" nach aktiven Sessions auf einer IP. Normalerweise sollte da nur ein paar Pakete durchkommen, und sobald eine Antwort erfolgt ist, sollte die "Flut" natürlich beendet sein. Letztlich rufen wir da aber nur die API-Funktionen auf, wie die Pakete da gesendet werden, können wir im Detail gar nicht steuern.

Was die Szenario-Übertragungsabbrüche angeht, hängt das vom langsamsten Client ab. Der SB Host sendet die Szenario-Datei-Pakete einmal an alle angeschlossenen CLients, und wartet ab, bis von allen Clients das Bestätigungssignal kommt, daß das Paket empfangen wurde. Danach wird dann das nächste Paket 'rausgeschickt. Wenn ein Client BESONDERS schmalbandig oder mit hoher Latenz angebunden ist, kann das bei den schnellen Clients zu einem Time-out-Fehler führen. Die langsamen Clients machen aber munter weiter; beim zweiten Verbindungsversuch sollte dann eigentlich alles klappen.

Dieses Problem tritt natürlich in erster Linie bei Internet/WAN-Verbindungen auf. Im LAN ist das kein Thema. Vielleicht finden wir auch noch eine Lösung, wie man das insgesamt besser handhaben kann, aber unmittelbar gibt es keine Lösung durch lokale Konfiguration oder ähnliches.

Ich hab derzeit mit einem Kumpel ein ähnliches Problem.

Über Hamachi sehen wir uns zwar gegenseitig, ein Ping darüber abgesendet geht allerdings auch nicht durch.

In SB im Session Fenster taucht die offene Session weder bei mir noch bei ihm auf. Windows Firewalls und Anti-Viren SW konnten wir bereits ausschließen. Da wir die beta nutzen, sollte Port-Forwarding ja auch nicht mehr das Thema sein?!

Mit Hamachi gabs bei mir sonst eigentlich noch nie Probleme bei 1:1 Verbindungen, vielleicht hat ja jemand ne Idee?!

Ganz allgemein gesprochen scheint Windows 8.1 so viele Netzwerkprobleme mitzubringen, daß es schon nicht mehr feierlich ist (da muß man nur mal kurz Google anwerfen und die Trefferzahl anschauen). Für uns ist es zu diesem Zeitpunkt unmöglich zu entscheiden, was von den Berichten ein Steel Beasts-Problem ist, und was in den Bereich "Windows 8.1" gehört. Gegenwärtig konzentrieren wir unsere Arbeit daher auf das Spektrum Windows XP ... Windows 8.0.

Wenn nicht mal ein Ping zustandekommt, kann Steel Beasts natürlich nur kapitulieren. Die Grundvoraussetzung für Netzwerkspiele ist selbstverständlich, daß eine funktionierende Netzwerkverbindung vorliegt.

Zusammenfassend bitten wir Windows 8.1-Opfer, zunächst von der Zusendung von Fehlermeldungen abzusehen, da wir keine Ursachen-Zuordnung vornehmen können.

Wir hoffen natürlich, daß Microsoft die Probleme baldmöglichst behebt, aber leider haben sie zu dem Thema noch keine offizielle Stellungnahme abgegeben, soweit ich weiß. Es gibt auch viele Fälle, bei denen Windows 8.1 keine Probleme macht. Es scheint wohl so zu sein, daß eine direkte Installation von 8.1 ein wenig zuverlässiger funktioniert als ein 8.0 -> 8.1 Update, aber warum das so sein sollte, wäre reine Spekulation im Moment.

Nutzt Du einen CodeMeter STICK? Dann ist die Lizenzfrage völlig egal.
Beim Einsatz eines virtuellen CmContainers für zeitbasierte Lizenzen ist die Sachlage anders. Im Grundsatz ist die Lizenz an Hardware und Betriebssystem gebunden, wobei in gewissen Grenzen Änderungen erlaubt sind. Ich glaube aber nicht, daß Microsoft einen "Downgrade-Pfad" von Windows 8.1 auf 8.0 vorgesehen hat. Man müßte also komplett neu installieren. Je nach Installationsmethode beinhaltet das eine Formatierung der Festplatte (oder auch nicht), und ob ein einfaches Restore der Lizenzdateien von einem Backup zum Erfolg führt, vermag ich nicht zu sagen. Ich bin da allerdings skeptisch. Im Zweifel kann Support(at)CodeMeter.de besser Auskunft geben.

IM PRINZIP wird Windows 8.1 von Steel Beasts schon unterstützt. Spätestens wenn wir den neuen Netzwerkstack mit einem Update im Sommer herausbringen. Allerdings ist das Problem, daß die Lage im Moment sehr unübersichtlich ist. Man kann leider nicht sagen, daß es sich ausschließlich um ein Problem der Kombination von DirectPlay und Windows 8.1 handelt. Dazu gibt es zu viele andere Fehlermeldungen, nicht nur von anderen Spielen, sondern auch ganz allgemein. Unsere Aussage, von Fehlermeldungen im Zusammenhang mit Windows 8.1 im Moment abzusehen bezieht sich primär auf den Betatest. Wir wollen ja zunächst überprüfen, ob der neue Netzwerkstack korrekt implementiert wurde (Anfang nächster Woche kommt die nächste Betaversion). Wenn Meldungen von Windows 8.1-Nutzern kommen, kann man nicht wissen, ob es nun ein Windows-Problem ist oder ein Steel Beasts-Problem. Es verzögert/erschwert unnötig die Grundaufgabe, nämlich die Überprüfung der Implementierung. Erst wenn wir uns "ziemlich sicher" sein können, daß der neue Netzwerkstack korrekt implementiert wurde, ergibt es Sinn, die 64-Bit-Version zu testen. Erst wenn die 64-Bit-Version getestet und für gut befunden wurde, können wir uns um Windows 8.1 kümmern. Wer weiß, vielleicht hat Microsoft bis dahin auch einen Patch erstellt, und dann läuft es plötzlich "von selbst".
Da DirectPlay von Windows 8.1 bekanntermaßen nur fehlerhaft unterstützt wird, bieten Fehlermeldungen zur regulären Version von SB Pro leider im Moment auch keinen Erkenntnisgewinn.

Würde mich jemand fragen, ob er einen neuen Rechner mit Windows 8.1 oder lieber mit Windows 7 kaufen soll, um Steel Beasts zu spielen, würde ich ohne zu zögern Windows 7 empfehlen. Windows 8.0 - wer's mag... mit Classic Shell scheint es ja auch ganz akzeptabel zu funktionieren. Windows 8.1 ist im Moment mit Risiken behaftet - es KANN funktionieren, vielleicht aber auch nicht ... und man weiß nicht, wie lange der Zustand noch anhält.

Vielen Dank für die umfassenden Antworten zu dem Thema.

Wir sollten mal in der FAQ einen prominenten Hinweis zu dem Thema setzen. Immerhin ist Thodt nicht alleine mit dem Problem.