Beiträge von Ssnake

Kommt darauf an, "wie grob" das Zeitfenster sein darf.

"In diesem Jahr" ist sehr, sehr wahrscheinlich.
"Vor Oktober" ist mit "an Sicherheit grenzender Wahrscheinlichkeit" eine zutreffende Prognose.
Ich bin ziemlich zuversichtlich, daß es "vor Mitte August" sein wird, und ich will nicht ausschließen, daß es am Ende doch noch im Juli klappen könnte.

Absolute Sicherheiten gibt es aber nicht. Das einzige, was an absolute Gewißheit heranreicht, ist, daß wir steuerpflichtig sind und eines Tages sterben müssen. Die Gelehrten streiten noch, welches von beiden schlimmer ist.

Keine Ahnung, ob OkaySoft daran Interesse hat. An uns wird es nicht scheitern.

Für die genannten beiden kann ich sagen, daß unsere Parameter-Abweichungen (=systematischer Fehler) vermutlich im Bereich der natürlichen Streuung liegen.

Der Webshop wird im Laufe des Wochenends sicher wieder bereit sein. Und auch wenn die derzeitigen Wartungsarbeiten im weitesten Sinne der Vorbereitung auf das Release dienen, ist es noch nicht ganz so weit. Es könnte sich also insoweit lohnen, noch ein, zwei Tage zu warten, um bei einer Direktbestellung den aktuellen Rabatt mitzunehmen.

Nein, wie soll das gehen?
Der Timer für die Relativzeit wird (nur dann) auf Null gestellt, wenn eine Einheit an einem Wegpunkt ankommt. Nun könnte man diese Ankunft natürlich als auslösedes Ereignis referenzieren und hätte insoweit Synchronizität - aber man kann die Relativzeit ja nur bei Folge-Bedingungen referenzieren. Nein - hier ist erforderlich, daß ein Bestimmtes Ereignis für einen bestimmten Zeitraum wahr ist. Dazu muß es das Ereignis geben (beispielsweise die Ankunft an einem bestimmten Wegpunkt). Dieses Ereignis kann dann in einer globalen Bedingung referenziert werden (also, "Ereignis X ist wahr für weniger als N Minuten").
ERST DANN kann man testen, wie lange diese Bedingung schon ununterbrochen wahr ist (mit anderen Worten, wie lange es her ist, daß Ereignis X eingetreten ist), und bei Zeitüberschreitung dann die Schadensbedingung abschalten, damit man anschließend reparieren kann, ohne daß der Schaden gleich wieder angewandt wird.

Ronin(911) schrieb:

Btw: die letzten Fahrzeuge sind in der pic-gallery.
Der Leopard 2A5 A2 DK,...mit DM-11 und programierbarem Zünder sowie barracuda-tarnsystem und Slat-panzerung gegen RPG-7

Naja, eben KEIN programmierbarer Zünder, denn die Dänen haben ja die dafür nötige Zusatzbox und modifizierte Zündbaugruppe gerade NICHT eingerüstet. Insofern also nur Aufschlagzünder.

Vielleicht sollte der Motorschaden zunächst an eine Globale Bedingung ("Ereignis: Motorschaden ist WAHR") geknüpft werden, die höchstens X Minuten wahr sein darf, damit der Schaden eintritt. Wenn nach diesem Zeitraum dann repariert wird, ist die Schadensbedingung nicht länger erfüllt, und es sollte zu keinem Konflikt mehr kommen.

Also, von persönlichen Empfindlichkeiten einmal abgesehen:

Wenn sich im eSim Team der Eindruck verfestigt (und es gibt da ja nun mittlerweile mehr als nur mich als deutschsprachiges Mitglied), daß in diesem Forum nur pauschal unzufriedene Meckerpötte den Ton angeben, dann werden hier irgendwann auch berechtigte Kritikpunkte nicht mehr wahrgenommen werden. Ich kann ja keine unliebsamen Äußerungen unterdrücken (selbst wenn ich es wollte - und ich will es nicht!), da ich hier ja auch nur ein Benutzer unter vielen bin. Ebenso wie hier jeder seinen mehr oder minder qualifizierten Senf dazugeben darf, kann aber auch ich meine Meinung äußern.
Ich bin dabei quasi von Amts wegen zur Zrückhaltung verpflichtet, sonst hätte ich deutlichere Worte gewählt. Aber jedem hier sollte klar sein, daß wir im eSim Games-Team nicht primär aus finanziellem Interesse an Steel Beasts arbeiten (sonst müßte ich die Arbeiten an der Personal Edition sofort einstellen lassen). Es geht eben auch um Anerkennung der Leistung, und um Respekt für unser Engagement. Beides vermisse ich in letzter Zeit.

Das Forum hier hat in den letzten Jahren einen besonderen Status gehabt, auch was Hintergrundinformationen anging, die ich mit Euch geteilt habe. Offenbar ist das vielen aber gar nicht wichtig - kein Problem, damit werde ich in Zukunft keinen hier mehr belästigen. Die 911-internen Streitereien haben aber auch das Klima hier ungemütlich gemacht und die Community mittlerweile in drei Fraktionen gespalten, was auch die Bedeutung von 911 geschmälert hat. Ich hoffe, das war es wert.

Retro schrieb:

Manchen Leuten ist einfach nicht mehr zu helfen..

Heidegeist(911) schrieb:

Ähm... wie meinen? :confused:

Ihr merkt es echt nicht mehr, oder?

Also, man muß das in SB selbst machen, obwohl es eigentlich automatisch passieren sollte?
Mit wieviel Zeitverzögerung nach Abgang des Flugkörpers?

Eisenschwein(911) schrieb:

Zusatzfrage: Wird der simulierte Wind Einfluss auf die Akustik haben ??

Irgendwann vielleicht einmal, aber was mich mehr beschäftigt ist die Frage, ob Informationen von Horchposten in die elektronische Lagekarte einfließen sollten, und wie man das ggf. umsetzen will. MAW, computer-gesteuerte Einheiten sollten auch "Ohren" bekommen, und akustische Informationen sollten ausgewertet werden und dann auch deren Verhalten ggf. beeinflussen, speziell, wenn es sich um Aufklärer oder Einheiten mit Befehl zur Überwachung eine Geländeabschnitts handelt.

Falli(911) schrieb:

Apropos Akustik... hierzulande fährt man oft "Gefechtsaufklärung" mit Horchhalten und als Grösster Spähtruppführer aller Zeiten hätte ich da eine eher pragmatische Frage.
Was das Hören in der Simulation angeht, wird sich da auch etwas tun? Also in erster Linie zur besseren Unterscheidbarkeit verschiedener Modelle.

Nun ja, wir haben eine Lizenz für MILES erworben, damit wir in Zukunft echten Rundum-Klang (Surround Sound) und Umgebungsakustik (Environmental Sound Effects) implementieren können. Dazu müssen aber alle Klangdateien, die wir zur Zeit verwenden, komplett überarbeitet werden. Man kann sich vorstellen, daß das allein schon einen Haufen Arbeit bedeutet. Dann ist es auch eine Frage, ob man überhaupt an ein bestimmtes Fahrzeug herankommt, um den Motorsound aufzunehmen, zumal es dann ja noch die besondere Schwierigkeit gibt, daß zwar der Leerlaufklang gut aufzunehmen ist, das Fahrzeug in der Bewegung aber ein ganz eigener Fall ist (man bekommt Windgeräusche, wenn man mitfährt, oder Doppler-Effekte, wenn man an einem Aufnahmepunkt verbleibt, ggf. noch zusätzliche Geräusche der eigenen Bewegung, wenn man neben dem Ziel herläuft oder fährt - das macht's alles nicht so ganz einfach).

Zitat

Und was auch immer so ein Punkt ist, wird man im Editor in Zukunft den Einheiten sagen können, dass sie den Motor ausmachen?

Irgendwann bestimmt.

Zitat

Bislang kann man das nur über "Schaden: Motor" machen und das Blöde ist, dass sich KI Einheiten - selbst wenn der Schaden repariert ist - auf Teufel komm raus nicht mehr weiter bewegen.

Interessant. Das klingt nach einem Bug. Kannst Du mir ein Test-Szenario zusammenstellen mit einem Fahrzeug, daß das Problem sofort nach Szenariobeginn zeigt?

Nacht und alles, was damit zusammenhängt, wird noch etwas warten müssen. Abgesehen von der Stimmung, die vielleicht bei Nachtszenarios aufkommt, bringt Dunkelheit nicht so den enormen Gewinn in der Ausbildung mit virtuellen Simulationen.

Gut: Es ist dunkel, da fällt die Orientierung schwerer. Für diese Erkenntnis braucht es keine Simulation.

Jetzt ist der Ausbildungsnutzen nicht das einzige Entscheidungskriterium im Designprozeß, insofern werden wir ganz sicher noch mehr Arbeit in dieses Gebiet investieren. Aber ich habe schon immer gesagt, daß unser Anspruch an eine Umsetzung von Nachtkampf über Beleuchtungeffekte hinausgeht. Die neue Engine schafft die Grundvoraussetzungen für die Visualisierung, die eigentliche Umsetzung kann aber erst nach dem 3.0-Release in Angriff genommen werden.

32 parallele Prozessoren... Ich wär' ja schon mit vier zufrieden.

Parallelität und Speicher-Adressraum haben nicht viel miteinander zu tun. Man kann Single-Threaded und trotzdem eine 64-Bit-Anwendung sein (oder umgekehrt).

Hinsichtlich der Hardwareempfehlungen sind die Optimierungsarbeiten an der Engine soweit vorangeschritten, daß wir jetzt eine Erhebung durchführen wer mit welcher Hardware bei welchen Einstellungen welche Frameraten bekommt. Ich werd übers Wochenende mal versuchen, das alles in einer Tabelle zusammenfassen.

Ich befürchte allerdings, daß wir die Hardware-Empfehlungen deutlich werden anheben müssen. Zumindest bei Full HD kommt meine alte Radeon 4870 nur noch mühsam mit, von den höchsten Detaileinstellungen mal ganz zu schweigen. Es ist aber eben nicht nur die Grafikkarte. In vielen Fällen wird die Framerate durch den Prozessor begrenzt. Die Umstellung von Single Thread auf Mehrprozessor-Unterstützung ist derh mühselig und bringt am Anfang fast gar nichts (oder macht es sogar noch ein klein wenig schlimmer). Als das Design für Steel Beasts festgelegt wurde, waren Mehrkern-Prozessoren absolut kein Thema, und jetzt kommen wir halt an die Grenzen dessen, was überhaupt noch geht.

Später, aber nicht in Version 3.0

Falli(911) schrieb:

Hach, die Krach-Bumm-Peng Fraktion Mal abseits der russischen Kaviarbüchsen da auf den Bildern....
Wirds auch ne PzH2000 geben?

Nein.

Zitat

Wenn ich das richtig verstehe... muss jetzt die verfügbare Artillerie auch auf der Karte sein?

Es ist eine reine "Kann-Bestimmung". Die magischen Artillerie-Batterien in der erdnahen Umlaufbahn bleiben als Option weiterhin erhalten, und für 90% aller Szenarios, denke ich, bleiben sie auch das Instrument der Wahl. Wenn andererseits das Bewußtsein geschärft werden soll, daß nur begrenzte Munitionsmengen für einen beliebigen Einsatz bereitstehen und man daher mit der Artillerie streng haushalten muß, kann es sinnvoll sein, die Haubitzen mit ihrer Grundbeladung (aber ohne Nachschubfahrzeuge) einzusetzen. Will man die Möägichkeit eröffnen, dem Feind die Artillerie zu nehmen, ohne aber gleich die ganze Munitionslogistik am Hacken zu haben, wäre es wohl sinnvoll, den Haubitzen im Munitions-Dialog "Unbegrenzt" Munition zuzuteilen. Andererseits ist natürlich gerade der Munitionstransport eine wesentliche Schwachstelle des Systems Artillerie, was es interessant macht, auch diesen Teil mit aufzunehmen.
Es eröffnen sich also eine Menge neue Möglichkeiten, ohne daß das Bestehende gleich zerstört würde.

Zitat

Wenn das Gerödel aber auf der Karte steht und es wird vernichtet, dann wars das mit Anforderung, richtig?

Korrekt.

Zitat

Berücksichtigt das die KI-Artillerie, wenn feindliche aufgeklärt wird und schiesst automatisch auf Primärziele oder müsste so etwas quasi gescripted werden?

1. Nein, und 2. Ich wüßte nicht, wie man das Skripten wollte. Es wird sich schon jemand persönlich um aufgeklärte feindliche Feuerstellungen kümmern müssen.

Dr.Thodt(911) schrieb:

Ich frage mich gerade, ob ich das jetzt richtig verstehe:

Es wird in 3.0 einen "Schwung" (neuer) Technicals mit diversen Waffensystemen (3 x sMG, 2 x mMG und TOW) geben, ja?
Im .com Forum heisst es nun, dass alle diese Technicals bedienbar (playable) sein werden, ja?
Das bedeuted, dass auch die Waffensysteme bedienbar (playable) sein werden, ja?

Bis hierhin richtig.

Zitat

Und hier wird der Wunsch nach einem bedienbaren TOW System auf dem Waffenträger Wiesel mit der Begründung abgelehnt, es sei zuviel Wartungsaufwand, wenn sich mal etwas an dem Waffensystem ändern würde, ja?

Nein. Was ich geschrieben habe ist, daß der "copy & paste"-Ansatz als solcher, der vorgeschlagen wurde, aus den genannten Gründen langfristig problematisch ist. Und der Wiesel ist im Übrigen genau so ein "copy & paste"-Altfall, der erst einmal umgestellt werden muß auf einen universalen Ansatz, damit dann die TOW quasi von selbst spielbar wird. Insofern ist es ein brilliant gewähltes Beispiel dafür, warum diese Schnellschüsse kurzfristig eine Scheinlösung bieten, aber langfristig sehr teuer werden, was die Wartungsarbeiten angeht. Genau deswegen will ich weg von diesem alten Ansatz. Ich wollte damals der deutschen Fangemeinde einen Gefallen tun, und jetzt treten gewissenmaßen die wahren Kosten des Gefallens zutage.

Im Übrigen geht es überhaupt nicht um die Frage, ob wir hier kurzfristig noch was dran drehen können. Die Technicals haben wir ja schon vor einer ganzen Weile fertiggestellt. Jetzt präsentiere ich die Erweiterung des Funktionsumfangs von Version 3.0 gegenüber 2.654 - ich stelle also lediglich vor, was in den vergangenen 18 Monaten insgesamt erarbeitet wurde (soweit es für den Endanwender überhaupt sichtbar wird).

Daß der Wiesel nicht spielbar ist, mag enttäuschen. Du kannst aber davon ausgehen, daß Version 3.0 aus einer sehr schwierigen Ausgangssituation heraus das bestmögliche Ergebnis darstellt, was man mit den gegebenen Mitteln überhaupt erreichen konnte. Die Frage ist nicht, ob man nicht auch die TOW im Wiesel hätte spielbar machen können (ja, hätte man), sondern was der Preis dafür gewesen wäre (Beispielsweise der Verzicht auf ALLE neuen Technicals). Damit kommt man dann zu einer Güterabwägung, was der Mehrheit der Spieler am Meisten bringt. Daß man niemals alle zufriedenstellen kann, ist dabei eine wenig überraschende Binse.

Ja. Man kann das so machen, aber wenn man später was am TOW-Modell verändern will ("Wartungsarbeiten"), muß man das an jeder Stelle tun, die man zuvor auf die schnelle dupliziert hat. Irgendwann kommt da Spaghetti-Programmierung heraus und man kann gar nichts mehr verändern, ohne an anderer Stelle etwas kaputtzumachen, weil niemand mehr durch den Alptraum durchsteigt. Es ist das programmiertechnische Äquivalent zum Frisieren der Buchhaltung.

Hinsichtlich Geländeeditor: Ursprünglich sollte SB Mapper Pro die Erweiterung der Funktionalitäten abdecken. Es war mit dem Programmierer so abgesprochen, daß er SB Mapper Pro weiterentwickelt und mindestens einmal jährlich ein Update bereitstellt. Daher ist im Bereich des Karteneditors nicht viel geschehen. Leider hat sich herausgestellt, daß die Absprachen nicht eingehalten werden. Daher werden wir in den kommenden 12...18 Monaten vermehrt Arbeit in diesen Bereich investieren. Das betrifft dann sowol die Gelände-Engine selbst als auch das Benutzerinterface des Editors und die Objektbibliothek.

Man wird also zunächst weitgehend mit dem auskommen müssen, was bereits bekannt ist.