Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!
Kannst Du in den Treiber-Einstellungen den Analogstick für den Daumen zur primären Achse für Steuerbewegungen machen, oder das womöglich sogar zur Laufzeit umschalten, je nachdem ob Du auf dem Richtschützen- oder Kommandantenplatz bist?
Das könnte vielleicht die Lösung sein.
Ein Großteil des Pionierwesens hat ein dynamisches Gelände mit (sehr viel) höherer Auflösung zur Voraussetzung. Daran arbeiten wir seit über einem Jahr. Die höhere Auflösung benötigt viel mehr Speicherplatz, also müssen wir einerseits auf 64 Bit umstellen (das ist quasi abgeschlossen), andererseits können wir auch dann nicht mehr den Ansatz fahren, die Geländedaten komplett im Speicher zu halten. Hier warten die nächsten großen Herausforderungen (wie finden computergesteuerte Kräfte ihren Weg im Gelände, wenn das Gelände gar nicht im Speicher gehalten wird? Gar nicht, natürlich. Das Gelände muß also in unterschiedlichen Detailstufen vorgehalten werden).
Sobald diese Grundsatzfragen beantwortet sind, geht's ans Eingemachte: Die bestehende Software, die vom Design her an jeder Stelle implizit oder explizit annimmt, daß die notwendigen Geländedaten "vorhanden" sind, muß so umgeschrieben werden, daß alles weiterhin funktioniert, obwohl sich die Verhandlungsgrundlage radikal geändert hat.
Sobald das alles abgeschlossen ist, funktioniert SB Pro so, wie schon jetzt auch. Es ist also scheinbar ein Riesenaufriß ohne sichtbares Ergebnis. Aber er schafft eben die Voraussetzungen für die nächsten Schritte:
Wenn das Gelände dynamisch veränderbar werden soll, müssen auch die Wegfindung und die Sichtlinienberechnungen dynamisch angepaßt werden. Dynamische Geländeveränderung ist entscheidend, um bestimmte Pioniertätigkeiten zur Laufzeit zu ermöglichen (z.B. Stellung schieben, PzSperrgraben, ...) - das werden wir dann Schritt um Schritt einführen. Es ist aber insgesamt eine ziemlich komplexe Aufgabe, wie man sich vielleicht vorstellen kann - als ob man einen gigantischen Mikadohaufen hätte, bei dem die Stäbe allesamt ersetzt statt einfach nur weggenommen werden müssen.
Sören hat Mehl.
Wir werden versuchen, relativ kurzfristig einen Patch bereitzustellen. Wir können nicht garantieren, daß er funktioniert, und es wird auch nicht ewig funktionieren, aber es verschafft Euch hoffentlich ein bißchen mehr Zeit, den Server umzustellen.
Das Ticket kommt, alter Mann ist doch kein D-Zug...
Trotz wiederholter Versuche ist es mir noch nicht gelungen den LFK Spike LR so zu nutzen, dass ich einen Zielwechsel durchführen kann, bzw ein Nichtfahrzeugziel bekämpfen kann. Die /den Javelin bekomme ich ebenfalls nicht gehandelt, da scheitert es bereits am Auslösen!
Zunächst muß das Ziel aufgeschaltet werden (simuliert durch Benutzen des Laser-Knopfs). Sobald das Target Lock da ist kann man ggf. noch das Flugprofil festlegen (Hi/Lo), die Leertaste feuert dann die Rakete ab.
Zielwechsel mit Spike ist anspruchsvoll; es bedarf schneller Reaktion, funktioniert in SB auch nur bei stehenden Zielen, und man braucht viel Übung. Der Freiflugmodus ist nahezu unmöglich zu bedienen, aber das ist beim echten System wohl ganz ähnlich.
Dann geb ich jetzt auch mal meinen Senf dazu^^
Hab mir gestern die V.3019 runterladen.
Entpackt und so. Verschieben bringt ja nichts, wenn ich keine Lizenz habe - gelle?
Also versucht die Lizenz zu bekommen - aber Fehlanzeige
Das Lizenzkontingent für die Betaversion ist erschöpft. In Einzelfällen bin ich durchaus bereit, noch ein Ticket auszustellen (eMail, bitte). Da wir für jede Lizenz, die wir ausstellen, einen gewissen Betrag bezahlen müssen, und die Betalizenzen kostenlos waren, haben wir uns eine Obergrenze gesetzt, was uns der Spaß kosten darf.
Entscheidend wäre, die Log-Datei sowohl vom Host also auch von denjenigen Clients zu bekommen, bei denen das Problem aufgetreten ist; idealerweise mit einem Hinweis zum ungefähren Zeitpunkt, zu dem es erstmalig aufgetreten ist sowie dem Callsign der betroffenen EInheiten. Die Logdateien existieren wahrscheinlich noch; immerhin werden die jeweils letzten elf Stück aufbewahrt.
Vielleicht wird der CodeMeter-Dienst von irgendeiner Anwendung beendet oder gestört, und es ist gar kein Lizenzproblem?
Schwer zu sagen.
Schau Dir mal den Ordner C:\ProgramData\CodeMeter\CmAct an hinsichtlich Schreib- und Leseberechtigungen und der Dateien, die darin gespeichert sind. Wenn es da Einschränkungen gibt, könnte es erklären, warum die Lizenz nicht länger nutzbar ist.
Oder vielleicht ist die Systemzeit geändert worden durch Vor- oder Zurückstellen? CodeMeter hat Sicherungen dagegen. Wenn also beispielsweise ein Virus damit herumspielt?
CodeMeter wird sich NORMALERWEISE mit einem Zeitserver wieder synchronisieren ... wenn die Verbindung zum Zeitserver nicht unterbunden wird.
Ansonsten mal CmDUST laufen lassen wenn die Lizenz funktioniert, und dann nochmal, wenn sie nicht mehr funktioniert. Vielleicht fördert der Vergleich zwischen den Ergebnissen eine Erkenntnis zutage. Ich denke, man sollte auch begleitend den Support @ CodeMeter.de in Anspruch nehmen.
WNA HECK und WNA TEMP werden angezeigt. WNA TEMP muß als Schaden definiert werden, und wird behoben durch Wechsel zur Betriebsstufe Beobachten (sonst eskaliert es zum Shcaden "Stabilisierung").
Vorschläge, welche Texte zu bestehenden Schäden hinzugefügt werden sollten, nehme ich gerne entgegen.
Bei reproduzierbaren Abstürzen oder Aufhängern bitte ein Duplikat der Steel Beasts-Verknüpfung auf dem Desktop (oder an eine anderen genehmen Ort) anlegen, und dann in den Eigenschaften der Verknüpfung
Eine Sache sollte ich noch klarstellen: Du kannst ohne weiteres noch eine zweite Betalizenz auf unserer Website bestellen. Irgendwann ist natürlich Schluß, denn für jede Lizenz, die wir ausgeben, müssen wir Geld bezahlen (insofern müssen wir dem Mißbrauch durch irgendwelche Internet-Vandalen natürlich vorbeugen). Aber für den Fall, daß ein Nutzer mehrere PCs hat oder auch mal sein Betriebssystem während des Tests neu installiert ist vorgesorgt. 
Im Einzelfall kann man mich deswegen auch per eMail kontaktieren.
Ja, natürlich. Wir wollen ja so viele Leute wie möglich damit spielen lassen, um sicherzugehen, daß es auch funktioniert. Wir müssen halt nur erst mal die 32-Bit version testen, damit das, was dann während des 64-bit Tests gemeldet wird, auch zuverlässig als Resultat der 64-Bit-Umstellung eingeordnet werden kann. Sonst sucht man sich blöd bei den Fehlerursachen.
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.
