Beiträge von Ssnake

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.

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.

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.

Das mag ein Symptom von Arbeitsspeichermangel sein (d.h. wegen des 4-GByte-Limits für 32-Bit-Anwendungen). U.U. hilft es momentan, SB Pro neu zu starten, bevor man im Editor weitermacht. Das wäre natürlich keine dauerhafte Lösung, aber bis zum Sommer (wenn wir den offenen Betatest für die 64-Bit-Version starten) könnte man es vielleicht noch ertragen.

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.

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.

Heidegeist(911) schrieb:

Konnte bis jetzt nur feststellen, daß das Erzeugen von Nav-Meshes n büschn fixer geht. Kann das sein?

Ja, das ist richtig beobachtet.
3D-Charaktere sehen jetzt deutlich besser aus, und auch Fahrzeugoberflächen, die nicht im direkten Sonnenlicht stehen.

Hauptsächlich bringt das Update aber Fehlerkorrekturen.

Zitat

Wann kann man denn mit den Releasenotes rechnen?

Ich arbeite noch dran. Es schien mir wichtiger zu sein, das Update zum Wochenende bereitgestellt zu haben als die Vollständigkeit der Dokumentation. Aber die kommt noch. Jetzt geh' ich aber erst mal schlafen.

Hier geht's zum Download.

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.

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.

Könntest Du mir die Szenario-Datei (und evtl. zugehörige Kartendaten) zukommen lassen, dann können sich die Programmierer das mal ansehen.

Eisenschwein(911) schrieb:

Für den Editor kann ich das leider bestätigen.
Ich prüfe das Ganze mal im SP.....

Um es nochmal ganz klar zu formulieren: Du hast ein (globales) Ereignis gelöscht. die Szenario-Datei gespeichert, und danach wird das Ereignis trotzdem im Szenario ausgewertet (wo und wie genau). Selbst wenn Du den Szenario-Editor beendest und anschließend neu öffnest und das Szenario nochmal lädst, existiert das "Geister-Ereignis" immer noch?

Tritt der Fehler auch auf, nachdem Steel Beasts neu gestartet bzw. der Szenario-Editor verlassen und dann mit dem Szenario neu geöffnet wurde?

Typischerweise helfen in diesen Fällen Wechsel des Grafikkarten-Treibers (entweder eine neuere, oder eine ältere Version).

Mag ein Bug sein. Schau mal nach, ob bei SB Pro nach einem Neustart die Straßen geräumt sind. Ändere außerdem, wenn es nicht klappt, mal probeweise einen der Mobilitätsparameter um ein winziges bißchen und speichere die THM-Datei dann wieder ab. Mal sehen, ob's dann klappt. Wenn ja, handelt es sich um einen Bug, und beide Fälle zu wissen wäre hilfreich für die Beseitigung.

Also, beim BTR und beim BRDM sind die Türme rein mechanisch über Handkurbeln betrieben. Da die Türme aber sehr leicht sind, abern wir uns damals entschlossen, sie trotzdem per Maus bedienbar zu lassen. Stabilisiert sind sie natürlich nicht.

Guter Punkt. Wir werden uns das anschauen.

...es wäre ja nicht nur der Ulan. Auch der LMV mit Waffenstation ERCWS ist für das ÖBH entwickelt worden, ebenso die Bill-1, die Mörsermunition wurde österreichischen Schußtafeln entnommen. Heerestruppenschule und Militärakademie setzen Steel Beasts und SB Pro PE in der Ausbildung ein. Aktuell wird der Gefechtssimulator Leo 2A4 (hierzulande besser bekannt als AGPT) auf SB Pro umgerüstet. Weitere österreichische Systeme werden folgen.

Du hast die richtige Einstellung noch nicht gefunden. Ich muß an dieser Stelle aus Zeitgründen auf das Wiki bei SteelBeasts.com verweisen, das einen relativ umfangreichen M1A2-Artikel hat. Ggf. muß der Google-Übersetzer aushelfen.

Also, ich denke wir können uns darauf verständigen, daß das 3.0er-Upgrade schon von geradezu barocker Fülle ist.