Beiträge von Ssnake

Ein Zug mit vier Autos ist bei weiten Abständen 300m "lang". Das bedeutet, daß die erste Formationsänderung frühestens 300m HINTER der Brücke gegeben werden darf. Möglicherweise ist das der Grund für das unerwartete Ausscheren?

Falls nicht, bitte ich, mir das Szenario mal zuzusenden, wobei Du bitte alle Einheiten und Pfade löscht, die unnötig sind, um diese Brücken-Überquerung zu demonstrieren. Ich lege das dann gerne den Programmierern als Testfall vor.

Tjaaa... das kann natürlich mehrere Ursachen haben. Ist jetzt nicht einfach, nur auf der Basis der Beschreibung und eines Screenshots zu antworten.

Gesetzt den Fall, wir hätten die Möglichkeit perfekter Navigation für alle Fahrzeuge unter allen Umständen. Es bliebe die Frage, ob das wünschenswert wäre. Eine Brücke ist nun mal eine Engstelle, und wenn die blockiert wird, dann WILL man ja auch aus Sicht des Verteidigers, daß Chaos ausbricht. Solche Siege sind leicht erkämpft. Wenn's einen selber trifft, ist man natürlich nicht so begeistert. Aber es ist jetzt schwer zu entscheiden, ob es sich um einen echten Bug handelt oder um einen Planungsfehler. Womit ich nicht sagen will, daß unsere gegenwärtige Lösung stets zufriedenstellend funktionieren würde.

Gut, wenn es jetzt funktioniert, wären da noch zwei Empfehlungen.
1. Firmware-Update. Man starte das "CodeMeter Kontrollzentrum", klicke dort auf den Kreispfeil, und folge den Anweisungen auf dem Bildschirm
2. (Optional, bei Gefallen der vorhandenen Version): Update-Lizenz für Version 2.640 bei OkaySoft oder im eSim Games Web shop erwerben und die neueste Version hier herunterladen. Zu beachten wäre, daß die alte Version vollständig deinstalliert werden soll, bevor die neue aufgespielt wird.

Weil's da keine administrativen Beschränkungen hinsichtlich der Dateigröße gibt und das Benutzerkonto in wenigen Minuten eingerichtet ist...?

...oder bei Dropbox.com ein öffentliches Verzeichnis anlegen und den Link dann hier posten.

Oder mit RAR ein mehrteiliges Archiv anlegen...

Dr.Thodt(911) schrieb:

It's not a bug, it's a feature (wenn auch, n ziemlich doofes)

Die Bradley-Vorschrift ist da ziemlich eindeutig, und die Bradley-Experten wollten es so. Ich persönlich finde auch, daß es unter dem Gesichtspunkt Bedienbarkeit für den Durchschnittsbenutzer ein bißchen weit geht, aber ich respektiere die Gründe derer, die das Fahrzeug besser kennen.
Es gibt eine Gnadenfrist von fünf Sekunden, das Fahrzeug muß schneller sein als 10km/h, und das Startgerät muß zu mehr als Dreiviertel oben sein, damit es kaputtgehen kann. Eigentlich, sollte man meinen, ist das großzügig genug. Wir prüfen noch, ob wir Verbesserungen an Details vornehmen können, aber letztendlich muß man sagen, daß es gewollt ist, gerade weil es in der Realität auch vorkommen kann, und man letztlich "aus pädagogischen Gründen" sicherstellen muß, daß die Botschaft auch wirklich bei den Besatzungen ankommt.

Falls es Dich beruhigt, der Bug ist bekannt und hat im Katalog die Nummer 707... Irgendwann erschlagen wir ihn auch.

Als Benutzer muß man in der Außenansicht folgen, zum zu bergenden Fahrzeug fahren, und dann unten rechts in der Icon-Leiste auf das BergePz-Icon klicken. Da erscheint dann ein Menüeintrag, der einem erlaubt, anschließend das Zielfahrzeug anzuwählen (draufzeigen, klicken). Dann wird die Winde angebracht (unsichtbar) und das Fahrzeug an den BPz herangezogen. Anschließend kann man ihn im Schlepptau an einen sicheren Ort ziehen und dort durch gemeinsames Warten reparieren. Oder vielleicht hat der Szenario-Designer auch einen Wartungs- und Reparaturraum eingerichtet, und man kann die Fahrzeuge dort einfach nur abstellen.

In einer der nächsten Versionen wird man das auch automatisieren können.

Ich wüßte auch nicht, daß wir nur einen Jota in diesem Bereich geändert haben (abgesehen von der einen oder anderen Wärmebild-Textur). Die Szene wird in eine Textur gerendert, die exakt die Sensorauflösung hat, und dann auf die vom Benutzer gewählte Bildschirmauflösung hochskaliert. Das machen wir schon seit Jahren so, um die Grenzen und Unterschiede zwischen den verschiedenen Wärmebildgeräte-Generationen zu verdeutlichen, und um zu illustrieren, warum das Wärmebild gut zum Entdecken von Zielen ist, noch einigermaßen brauchbar zum Erkennen, und nur auf kurze Distanz tauglich zum Identifizieren.

Die Fehlermeldung habe ich aufgenommen mit Verweis auf diesen Thread. Kann aber noch nicht sagen was ist, und wann und wie es behoben wird.

Bei CSI können sie doch aus noch viel kleinerem Mist wunderbar die Nummernschilder hervorzaubern.
Vielleicht sollten wir die mal fragen...

Sobald es behoben ist, erfahrt ihr es.

Das gesamte HE-Wirkungsmodell muß einer Neubewertung unterzogen werden. Das braucht mehr Zeit, als uns zur Verfügung stand.

Giga... Mega... was ist schon ein Faktor von 10³ unter Freunden...

Falli(911) schrieb:

- heute wieder gehabt, Kette gerissen --> Fahrzeug war dennoch (bedingt) voll einsatzbereit

Bekannt, wird in der nächsten Version beseitingt.

Zitat

- wie wird denn das mit dem Umladen geregelt?

So wie bisher. Windows wirft aber als Tastaturcodes diesen verwirrenden Mist aus, weil ja tatsächlich diese Tasten intern doppelt belegt sind (ein Relikt aus dem PC-Paläolithikum, wo man entweder ein Zahlenfeld ODER Cursortasten bekommen konnte, aber nicht beides)

Zitat

Auch bei diesem Szenario beobachtet... beim KE-Umladen (per Maus und DropDown Menü) lädt er zwar den scriptseitig eingestellten Maximalbestand KE in den Turm, lädt aber danach MZ und folgend MG um, obwohl er eigentlich nur KE voll umladen sollte.

Danke für den Hinweis.

PGO schrieb:

Das heißt mehr Speicher einbauen ist eine Lösung oder ist keine Lösung?

Es könnte eine Lösung sein, sofern meine Fehlerdiagnose zutreffend ist. Da gibt es zur Zeit aber noch Restzweifel.

Zitat

Ich würde ja das eine wie das andere investieren..

Dazu würde ich aktuell noch nicht raten. Noch ist ungewiß, was die konkrete Ursache ist. Mittel- bis langfristig kann ich aber schon sagen, daß es eine 64-Bit-Version von STeel Beasts Pro geben wird. Ob es eine 64-Bit PE-Version geben wird, ist noch nicht entschieden, denn "eigentlich" sind die dort erlaubten Kartengrößen so klein, daß es "eigentlich" keine Notwendigkeit für einen größeren Speicherbedarf geben "sollte".
Da in diesem Bereich noch nichts spruchreif ist, bleibt festzuhalten, daß wenn Du mit Deinem nächsten Rechner eine 64-Bit-Windowsversion nehmen solltest, Du hinsichtlich SB Pro kein Risiko eingehst.

single__shot schrieb:

da SB nicht 64bit ist, kann es nixhts bringen. Hab 12Gb und trotzdem Probleme mit der Karte.

Das ist nicht korrekt. Ich habe 8GByte in meinem Rechner, und es funktioniert wunderbar. Wenn eine 32-Bit-Funktion Speicher allokiert, ist sie in einem 64-Bit-System nicht auf die unteren 4 GByte Adreßraum beschränkt. Sie kann stattdessen auch Speicher von oberhalb der 4GByte-Grenze vom Betriebssystem zugewiesen bekommen. Entscheidend ist in diesem Zusammenhang nur, daß überhaupt 150 GByte zusammenhängender RAM-Speicher vorhanden sind.

Wenn es bei Dir trotz 12 GByte nicht klappt, ist möglicherweise noch ein anderer Bug die Ursache. Das müßten wir dann noch genauer untersuchen.

Es ist NICHT ein zu knapp bemessenes RAM an sich. Die Vorschaufunktion benötigt 150 MByte zusammenhängenden Speicher, und daran scheitert es dann. Die steigt einfach kommentarlos aus und als Benutzer steht man dann da und weiß nicht, was los ist. Leider haben wir das erst Ende November herausgefunden und deshalb keine Zeit mehr gehabt, die Funktion durch eine andere zu ersetzen. Mittelfristig steigen wir eh' auf 64 Bit um, dann erledigt sich die Sache von selbst.

SteelClaw(911) schrieb:

ich kann irgendwie in der F9 ansicht nur auf Fahrstufe 1 vorwärtsfahren und rückwärts garnicht sobald ich wieder aussem bin oder Kdt geht alles ohne probs.

Bei einem bestimmten Szenario, bei allen Szenarios, bei einem bestimmten Fahrzeug, oder bei allen Fahrzeugen?