Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!
AFVsim vegekauft nicht an Privat und ich plane mit einem Budget von ca. 50€.
Doch, tun sie. Sie geben die 3D-Druckdaten 'raus, wenn Du bei ihnen den Elektronik-Bausatz kaufst (was auch Sinn ergibt, weil er dann von SB Pro sofort erkannt wird und die Knöpfe gleich richtig zugeordnet werden). Ich empfehle was CV90-artiges, weil da einfach mehr Knöpfe dran sind, die man in anderen Fz entsprechend auch nutzen kann.
Der Fehler liegt möglicherweise darin, daß der andere Patient unbelebbar war. Auch die besten Sanitäter können ihre Nekromantie nur mit einer under 100% liegenden Wahrscheinlichkeit durchführen. Ich vermute, daß die Programmroutine eine Triage-Funktion enthält, die die Behandlung nur auslöst, wenn der Zufallsgenerator bestimmt, daß die Sache auch Erfolg haben wird. Dadurch werden maximal viele Patienten in minimaler Zeit wiederhergestellt. Ist nix zu machen, wird das Pausenbrot ausgepackt.
Vielleicht sollte man eine Behandlungsanimation IMMER auslösen um den Eindruck der Untätigkeit zu vermeiden.
Ist doch ganz gelungen, finde ich. 
Tiefschnee hat aus Infanterieperspektive vielleicht noch Macken. Wir haben da neulich ein paar Bugs zu dem Thema beseitigt. Aber vielleicht sind sie auch erst nach 4.163 dazugekommen. Falls es noch einen Testlauf gibt oder jemand Zeit in einer frühen Phase hat, das kurz zu prüfen (absitzen, dann TrpFhr-Perspektive (F7), wäre ich über Rückmeldung (im Bug Thread) dankbar.
Danke für diese zusätzliche Sichtung.
Kurze Zwischenfragen zum Verständnis:
- Auf der Taste "R" liegt im Original "GAS Reticle" in der Tastenbelegung ingame ist die Taste belegt mit "TZF: Strichplatte KE / MZ". Welche Funktion steck dahinter? Im Leopard 2 hatte die Taste keine (sichtbaren) Auswirkungen.
Naja, der Leo hat ja auch keine zwei Strichplatten. Am MG3 bewirkt's den Wechsel von und zu Fla-Visier, im M1 gibt's dann wiederum eine KE und eine MZ-Strichplatte. Es ist also abhängig vom jeweiligen System (insofern wohl keine Überraschung).
Von Mosquito bereits beantwortet.
Stab Bereit ist eine Leo 1-Funktion, liegt standardmäßig aber auf L statt O
Danke; die Vermutung, was da los sein könnte, klingt stichhaltig.
Ist doch eigentlich super, daß Bahnlinien jetzt auch einen echten Hinderniswert haben.
Macht's natürlich im EInzelfall ein bißchen komplizierter, gebe ich ja zu...
Windows Startmenü - eSim Games - Steel Beasts Pro PE - Troubleshooting
Da ist auch die Verknüpfung zum "safe mode" und zum CrashDump-Ordner
Wenn es eine Netzwerk-Geschichte ist, dann bitte weiter beobachten und schauen, ob man es irgendwie eingrenzen kann. Die Netzwerk-SItzungen bitte im Debug-Modus betreiben und den ungefähren Zeitpunkt der Ausfälle, wenn sie auftreten, notieren. Dann können wir uns die debug-Logs von Client- und Hostmaschine ansehen (Host sollte auch im Debug-Modus laufen)
Hier wäre zunächst die THM-Datei des Szenarios zu prüfen. Kann ja sein, daß Traktion und Bodenwiderstand in der alten Version gerade so eben eine 30°-Steigung ermöglichten (man bedenke, daß 30° so ungefähr dem Extremwert der militärisch geforderten Steigfähigkeit für Kettenfahrzeuge entspricht - typischerweise wird das bei Trockenheit auf Betonrampen gestet...) und es nun gerade eben nicht mehr geht.
Oder es hat geregnet?
Wenn absolute SICHER ist, daß das Szenario seit 4.161 nicht verändert wurde:
Bitte das Szenario nochmal in 4.161 so modifizieren, daß nur ein BMP und ein T-72-Fz. den Damm überqueren. Dann können wir das Szenario auch gleich als "Unit Test" verwenden beim Vergleich zwischen den Versionen.
Netzwerk?
Einzelspieler?
Testmodus?
Ist der Ausfall wiederholbar oder selten und (zumindest scheinbar) zufällig?
Ja, das hat mich auch etwas übnerrascht. Ist ja nicht so, als ob wir unsere Installer nicht signieren würden... :o
Ist ein Problem mit den Leo 2 3D-Modellen. Ich hoffe, wir kriegen diese Kuh irgendwann vom Eis. Ist einer von diesen fünf-Minuten-Fixes, aber der zuständige 3D-Modellierer muß auch wollen. Leider sind nicht alle immer so professionell wie man das vielleicht erwarten könnte.
Die Numerierung der Objekte im Editor hängt jetzt von der gewählten Palette ab; wir können nur 64 "Landobjekte" adressieren, was aber für "die Welt" ein bißchen wenig ist (es gibt ja viele verschiedene Klimazonen mit unterschiedlicher Vegetation). Da wir nun mehr Objekte in der Bibliothek haben, muß eine Auswahl von 64 dieser Objekte erfolgen, die der jeweiligen THM-Datei zugeordnet werden. (Einer der Gründe, warum wir auf Geländepakete umgestellt haben.)
Mir gefällt diese variable Numerierung allerdings nicht. Deswegen wurde das auch wieder abgeschafft - allerdings ist das ein Bugfix, der wohl nur in Version 4.2 Anwendung findet.
Wann immer wir ein Fahrzeug aktualisieren, ändert sich auch die Fahrzeug-Basistextur. Damit funktionieren Mods für die älteren Versionen leider nicht mehr. Das ist unvermeidlich, wenn es denn überhaupt Updates für bestehende Modelle geben soll.
Also, das ist vielleicht erläuterungsbedürftig. Die Stellungen werden erst während des Ladevorgangs erzeugt. Im Szenario stehen nur die Parameter für "wo", "welches Fahrzeug", "welche Kategorie", und wo der Referenzpunkt liegt. Dann muß daraus berechnet werden, wie das Gelände verformt werden muß, um das gewünschte Ergebnis zu erzielen. Das kostet Rechenzeit, und wird auch in Zukunft Rechenzeit kosten. Aber wir konnten die Berechnungen optimieren, damit der Prozessor schneller damit fertig wird.
