@Plastique,
Panzer/Geschütze hatten einen (mehr oder weniger) beschränkten Aktionsradius nach unten (8,8-cm-Fla wohl nur 4°) - sie sollten also kaum bis gar nicht in der Lage sein, von größeren Geländeerhebungen auf kürzere Entfernung zu agieren.
Alles, was mit Höhenunterschieden zu tun hat ist schwierig. Da das Sust - Prinzip ja auf 2D aufbaut sind Höhenunterschiede nur mit Tricksen zu realisieren. Dazu gehört auch das Unterfahren von Brücken. An dem Konzept, wie Höhen zu berücksichtigen sind wird garbeitet.
Sämtliche Einheiten sollte die "Möglichkeit" gegeben werden, sich zu ergeben! (über Moral?) Beispielsweise müssten so drohende Einkesselungen oder größere Überlegenheit beim Gegner (auch vom Multiplayer) vermieden werden, will man vermeiden, dass die eigenen Einheiten einen neutralen Status erlangen, den Kampf einstellen und automatisch die Karte verlassen. Andersherum könnte ein Script das Absinken der Moral aus diesen Gründen fallweise verhindern.
Interessante Variationen.
Um das Schadensmodell einfach zu halten - also von der Berechnung von Einschlagswinkeln abzusehen - könnte man den Schaden innerhalb einer bestimmten Spanne zufallsweise bestimmen (lassen). (Falls es das tatsächlich einfacher hält...) Letztendlich ergeben sich durch schräge Panzerung ohnehin nur zentimeterweise Unterschiede.
by the way - hat jemand die/eine Formel zu Berechnung der Panzerdicke bei einem bestimmten Aufschlagswinkel?
Bedingung "Entfernung" ins Schadensmodell aufnehmen.
"Nahrung" wäre sicher ein Feature. Dann müsste man aber auch an Schlaf denken... Es sind ja ohnehin nur stundenweise Ausschnitte des ganzen Geschehens relevant. Treibstoff mag man daher auch weglassen - es sei denn, jemand berechnet hunderte Kilometer Wegstrecke auf einer Map.
Auch nicht schlecht wäre "Tarnung" als Feature - legt fest, ob eine getarnte Einheit für eine andere gesehen werden kann. Selbst wenn sie vom Spieler entdeckt wird mag der Angriffsbefehl versagen... Alles natürlich nur bis zu einer gewissen Erfahrung der angreifenden Einheit.
Infanterie sollte selbständig Schanzen (und Tarnen) können und Schützenreihe und- rudel beherrschen.
Sanis unbewaffnet und auf die eigene Seite ziehbar. (Müssen in Kriegsgefangenschaft jedem helfen.)
Fallweises Versagen von Waffen und Gerät.
Auch hier viele wertvolle Anregungen. Es wurde ja schon Einiges über solche Einzelheiten geschrieben.
Als Resuldat bin ich zu dem Konzept gekommen, das Programm grundsätzlich umzustrukturieren. Im Hauptprogramm befindet sich die Karte und die Basisbitmaps der fest installierten Einheiten. Und das Grundgerüst um so eine Szene ablaufen zu lassen.
Alles weitere, also Steuerung der Zusatzanimationen, Parameter wie Treibstoff und Erfahrung sowie alle situationsabhängigen Einzelheiten werden in den Scrptbereich und damit unter die Kontrolle der Mapdesigner übertragen.
Das reduziert auch die Entwicklungsarbeit. Einer alleine kann nicht alles umsetzen was hier schon angesprochen wurde. Aber erzählt ruhig weiter, was gewünscht wird, denn danach muß ja das Scripting gestaltet werden.
Scripting ist ein weites Thema, zu dem etliche Sprachen und Texte im Netz existieren. Da ein Script alleine etwa 15 mal langsamer als ein compiliertes C-Programm ist wird hier ein spezielles Verfahren benutzt:
Das Script selber führt die Aktionen nicht aus, sondern es sendet vor dem Spiel Informationen an das Hauptprogramm, das daraufhin intern die Weichen so stellt, daß die im Script codierten Aktionen ausgeführt werden. Dadurch werden die im Script codierten Abläufe genau so schnell ausgeführt wie die von vornherein zum Hauptprogramm gehörigen Teile.
Aber die Diskussion "MP vs. SP" gefällt mir schon wieder nich´. Wo sind denn da genau die Unterschiede?
Auch hier wird ein neues Konzept eingesetzt: Es bestehen grundsätzlich mehrere Parteien, die vom Mapdesigner frei definiert werden können. Also etwa zum Beispiel "Russen", "Deutsche" "Deutsche Artillerie" "Zivilisten" , hier also 4 Parteien in einer Map.
Bei Spielbeginn kann der Spieler den Parteien wiederum frei die Steuerung zuordnen etwa so:
Deutsche - Spieler
Russen - Internet1
Deutsche Artillerie - Computer
Zivilisten - Computer
(Das wäre eine Art MP)
oder so
Deutsche - Spieler
Russen - Internet1
Deutsche Artillerie - Internet2
Zivilisten - Internet3
(MP zu Viert)
oder so
Deutsche - Computer
Russen - Computer
Deutsche Artillerie - Computer
Zivilisten - Computer
(Wenn der Fernseher kaputt ist)
Hier gibt es also auch schier endlose Variationsmöglichkeiten, die unter der Kontrolle des Mapdesigners und des Spielers liegen.
Zur rechten Zeit könnte ich an Dingen, die mit Zahlen zu tun haben mitwirken
Gerne. Nach obigem Konzept kann jeder völlig frei mitwirken.
Open Strike - Nachrichten
@gehtnix:
Ich glaube, wir reden hier aneinander vorbei. Es geht nicht um einen "Open Editor", sondern um ein neues Spiel "Open Strike".
Ich weiß nicht, wie die Umsetzung geplant ist, denke aber doch, dass der Editor vom Scripttechnischen Erhalten bleibt und zusätzich dazu noch weitere Funktionen bekommt.
Der Editor ist für Sust2 völlig ausreichend - das weiß ich aus eigener Erfahrung und du ja auch (sieht man ja an deinen Karten
) - aber für das Neue Projekt wird er denk ich nichtmehr genügen.
@Packard:
(Wenn der Fernseher kaputt ist)
lol^^
Ich glaube, wir reden hier aneinander vorbei. Es geht nicht um einen "Open Editor", sondern um ein neues Spiel "Open Strike".
Ich weiß nicht, wie die Umsetzung geplant ist, denke aber doch, dass der Editor vom Scripttechnischen Erhalten bleibt und zusätzich dazu noch weitere Funktionen bekommt.
Der Editor ist für Sust2 völlig ausreichend - das weiß ich aus eigener Erfahrung und du ja auch (sieht man ja an deinen Karten
) - aber für das Neue Projekt wird er denk ich nichtmehr genügen.@Packard:
(Wenn der Fernseher kaputt ist)
lol^^
@ Dendro
Es wird ja sehr erhofft der neue Editor wird ausgeweitet, nur wenn dann von "vereinfachen" gepostet wird und nicht mal bekannt ist was man mit dem bestehenden bereits könnte ... schrillen schnell die "Alarmglocken", nur nicht noch einfacher und damit IMMER verbunden begrenzt
Meine Vorstellung wäre so frei verwendbar wie nur möglich um eben seiner "Fantasie" freien lauf zu lassen und nicht eine Reaktion der Einheiten wie die andere abläuft, egal wieviel die Waffengattung von Grund auf mitbekommt, es sollte variabel bleiben/möglich sein zu scripten!
Im Prinzip kann man dies der "KI" überlassen oder man macht es selbst - hier liegt der Reiz, die Abwechslung das Gegenteil von schnell aufkommender Monotonie!
MfG
Es wird ja sehr erhofft der neue Editor wird ausgeweitet, nur wenn dann von "vereinfachen" gepostet wird und nicht mal bekannt ist was man mit dem bestehenden bereits könnte ... schrillen schnell die "Alarmglocken", nur nicht noch einfacher und damit IMMER verbunden begrenzt
Meine Vorstellung wäre so frei verwendbar wie nur möglich um eben seiner "Fantasie" freien lauf zu lassen und nicht eine Reaktion der Einheiten wie die andere abläuft, egal wieviel die Waffengattung von Grund auf mitbekommt, es sollte variabel bleiben/möglich sein zu scripten!
Im Prinzip kann man dies der "KI" überlassen oder man macht es selbst - hier liegt der Reiz, die Abwechslung das Gegenteil von schnell aufkommender Monotonie!
MfG
Im Prinzip stehen drei Möglichkeiten zur Auswahl, die man oben bei der Parteiensteuerung bei "Computer" einsetzen könnte:
1. Sripting wie bisher mit den "Wenn-Dann-Fenstern"
2. Freies Skripting mt einer Skriptsprache.
3. KI vom Hauptprogramm aus.
Falls jetzt was schrillt ignoriert das mal. Bei dem Fenstersystem würde ich bevorzugen Variablen, Zonen und Parteien Namen zu geben. Die einzelnen Zeilen sind dann wie im Klartext lesbar. Es könnte also so etwas geben:
Mehr als 3 Russen in Vorgarten ...
sende MG-Truppe über Kellertreppe in Vorgarten
Hier wurden einfach den Nationen, Gruppen und Zonen sprechende Namen gegeben. Ähnlich kann man es mit den Variablen machen. Daß das eine Verbesserung ist werden mir wohl die meisten zustimmen. Weglassen kann man dagegen die Markierungen. Dafür kann man auch Zonen nehmen. Wenn große Exaktheit gewünscht wird nimmt man eben eine Zone aus einem einzelnen Feld dafür.
Genau den gleichen Code könnte man auch beim freien Skripting verwenden. Nur daß man da zusätzlich noch das ganze Drum und Dran einer Programmiersprache zur Verfügung hat um das in komplexe Strukturen einzubauen.
1. Sripting wie bisher mit den "Wenn-Dann-Fenstern"
2. Freies Skripting mt einer Skriptsprache.
3. KI vom Hauptprogramm aus.
Falls jetzt was schrillt ignoriert das mal. Bei dem Fenstersystem würde ich bevorzugen Variablen, Zonen und Parteien Namen zu geben. Die einzelnen Zeilen sind dann wie im Klartext lesbar. Es könnte also so etwas geben:
Mehr als 3 Russen in Vorgarten ...
sende MG-Truppe über Kellertreppe in Vorgarten
Hier wurden einfach den Nationen, Gruppen und Zonen sprechende Namen gegeben. Ähnlich kann man es mit den Variablen machen. Daß das eine Verbesserung ist werden mir wohl die meisten zustimmen. Weglassen kann man dagegen die Markierungen. Dafür kann man auch Zonen nehmen. Wenn große Exaktheit gewünscht wird nimmt man eben eine Zone aus einem einzelnen Feld dafür.
Genau den gleichen Code könnte man auch beim freien Skripting verwenden. Nur daß man da zusätzlich noch das ganze Drum und Dran einer Programmiersprache zur Verfügung hat um das in komplexe Strukturen einzubauen.
@ Was man mit den Variablen kann ist mehr als 1zu1 auslesen aber ich sollte es ja "ignorieren", jedenfalls dachte ich hier gemeint zu sein ... 
Wie groß das "wenn" sein kann ist klar? dies kann zu einem Scroll-Balken führen um eine (gemeinsame)Bedingung zu beschreiben!
Wenn du die 100 Markierungspunkte auslassen willst wie viele Zonen soll es dann geben? bisher 63 + Karte + 100 Markierungen für "größere" Karte klar zu wenige, ohne Markierungen würden 256 schon wieder enge sein ... ... ganz besonders wenn die Karten eventuell noch größer werden können als bisher ... 
Wie bereits erwähnt nicht jeder mag Kommandokarten wo alles und jedes vorgegeben ist, freie Wahl der Wegfindung für den Spieler dann "muss" die "KI" ausgefeilt reagieren können und dies ist von "variable zentrale Punkte" aus am einfachsten regelbar eben über Zonen/Markierungen damit nicht alles vorhersehbar wird VIELE sollcher Punkte/Zonen! ... das mit der variablen Reaktion der "KI" regelt man dann schon wer ein wüstes Chaos mag .... hier ich mag sowas ... ja, ja, ja ... 
Möchte noch ein Beispiel anfügen zum Verstehen was gemeint sein kann/könnte: Ein Stadtkampf, hier sollen gezielt einzelne Häuser von der "KI" angegangen werden also eine Markierung/Zone gesetzt und schon steuerbar per Script, o.k. der Spieler wiederholt diesen Abschnitt, weis man ja was kommt ... ergo die "KI" wählt ein anderes Gebäude wozu eine Variable benötigt wird die per Zufall auswählt unter mehrere Markierungen/Zonen, jetzt stellt der Spieler sich um, ergo die "KI" läßt im erneuten Aufbauverhalten des Spielers ein besetzen der einzelnen Gebäude aus und geht z.B. massiv gegen die Position/en des Spielers vor, um zu verstehen wo,wie mit was der Spieler sich vorbereitet hat bedarf es wieder der "Lesbarkeit" des Scripts über nah? ... Zonen? ... wenn man jetzt die Sache interessant halten will teilt man die gesamte Stadt in viele einzelne Bereiche auf mit den besonderen Positionen innerhalb der Bereiche an sich ... nun wieviele Zonen wäre da jetzt wohl ausreichend um dem Spieler nicht nachvollziehen lassen zu können wie die "KI" reagieren wird? 20 ... 50 ... 100 ? nach meinem Geschmack noch reichlich mehr als "nur" 100
... erst dann bringt man den Spieler dazu den "Überblick" zu verlieren, wenn man nicht mit Masse statt Klasse arbeiten will und mag ...
Denk mal darüber nach ob da was dran sein könnte ...
MfG
Wie groß das "wenn" sein kann ist klar? dies kann zu einem Scroll-Balken führen um eine (gemeinsame)Bedingung zu beschreiben!
Wenn du die 100 Markierungspunkte auslassen willst wie viele Zonen soll es dann geben? bisher 63 + Karte + 100 Markierungen für "größere" Karte klar zu wenige, ohne Markierungen würden 256 schon wieder enge sein ...
... ganz besonders wenn die Karten eventuell noch größer werden können als bisher ... Wie bereits erwähnt nicht jeder mag Kommandokarten wo alles und jedes vorgegeben ist, freie Wahl der Wegfindung für den Spieler dann "muss" die "KI" ausgefeilt reagieren können und dies ist von "variable zentrale Punkte" aus am einfachsten regelbar eben über Zonen/Markierungen damit nicht alles vorhersehbar wird VIELE sollcher Punkte/Zonen!
... das mit der variablen Reaktion der "KI" regelt man dann schon wer ein wüstes Chaos mag .... hier ich mag sowas ... ja, ja, ja ... Möchte noch ein Beispiel anfügen zum Verstehen was gemeint sein kann/könnte: Ein Stadtkampf, hier sollen gezielt einzelne Häuser von der "KI" angegangen werden also eine Markierung/Zone gesetzt und schon steuerbar per Script, o.k. der Spieler wiederholt diesen Abschnitt, weis man ja was kommt ... ergo die "KI" wählt ein anderes Gebäude wozu eine Variable benötigt wird die per Zufall auswählt unter mehrere Markierungen/Zonen, jetzt stellt der Spieler sich um, ergo die "KI" läßt im erneuten Aufbauverhalten des Spielers ein besetzen der einzelnen Gebäude aus und geht z.B. massiv gegen die Position/en des Spielers vor, um zu verstehen wo,wie mit was der Spieler sich vorbereitet hat bedarf es wieder der "Lesbarkeit" des Scripts über nah? ... Zonen? ... wenn man jetzt die Sache interessant halten will teilt man die gesamte Stadt in viele einzelne Bereiche auf mit den besonderen Positionen innerhalb der Bereiche an sich ... nun wieviele Zonen wäre da jetzt wohl ausreichend um dem Spieler nicht nachvollziehen lassen zu können wie die "KI" reagieren wird? 20 ... 50 ... 100 ? nach meinem Geschmack noch reichlich mehr als "nur" 100
... erst dann bringt man den Spieler dazu den "Überblick" zu verlieren, wenn man nicht mit Masse statt Klasse arbeiten will und mag ... Denk mal darüber nach ob da was dran sein könnte ...
MfG
Eine Scriptsprache zu installieren ist das kleinere Problem. Es gibt reichlich zur Auswahl. Viele stehen unter der GNU.
Die Funktionen aus unserem Game kann man dann dort über verschiedene Mechanismen einbauen, sodaß man diese und die eigenen Funktionen der Scriptsprache benutzen kann um richtige kleine Programme zu erstellem.
Eine Integer-Variable hat eine Breite von 16 Bit (2 Byte) also 65536 Möglichkeiten. Denke soviele Zonen und Variablen wird kaum jemals jemand definieren bei unseren Kartengrößen.
Bei einer Short-Integer ist es eine Breite von 8 Bit (1 Byte), 256 Möglichkeiten. Vorteil: Man spart viel Speicher und Zeit. Bei einer großen Anzahl von Operationen addiert sich das.
(Das mit dem Vorzeichen, + oder - (bei einem Integer wäre die Hälfte der möglichen Werte negativ) jetzt mal außer Betracht, es geht nur um 1 Byte oder 2 für eine Variable)
Markierungen könnte man eventuell doch wieder reinnehmen. Alles, was ich hier vorschlage ist ja nur zur Diskussion gestellt. Wie es sich dann am Ende entwickelt wird sich zeigen.
Ich glaube mit 256 Möglichkeiten bei Zonen, Markierungen, Variablen, Gruppen und Nationen kommt man gut aus, oder?
Beim freien Skripten hätte man unter anderem auch die Möglichkeit sein eigenes Zonensystem zu schaffen. Da kann man es sich einrichten wie man will. Auch einzelne Koordinaten statt größerer Felder wären so möglich abzufragen.
Die Funktionen aus unserem Game kann man dann dort über verschiedene Mechanismen einbauen, sodaß man diese und die eigenen Funktionen der Scriptsprache benutzen kann um richtige kleine Programme zu erstellem.
Eine Integer-Variable hat eine Breite von 16 Bit (2 Byte) also 65536 Möglichkeiten. Denke soviele Zonen und Variablen wird kaum jemals jemand definieren bei unseren Kartengrößen.
Bei einer Short-Integer ist es eine Breite von 8 Bit (1 Byte), 256 Möglichkeiten. Vorteil: Man spart viel Speicher und Zeit. Bei einer großen Anzahl von Operationen addiert sich das.
(Das mit dem Vorzeichen, + oder - (bei einem Integer wäre die Hälfte der möglichen Werte negativ) jetzt mal außer Betracht, es geht nur um 1 Byte oder 2 für eine Variable)
Markierungen könnte man eventuell doch wieder reinnehmen. Alles, was ich hier vorschlage ist ja nur zur Diskussion gestellt. Wie es sich dann am Ende entwickelt wird sich zeigen.
Ich glaube mit 256 Möglichkeiten bei Zonen, Markierungen, Variablen, Gruppen und Nationen kommt man gut aus, oder?
Beim freien Skripten hätte man unter anderem auch die Möglichkeit sein eigenes Zonensystem zu schaffen. Da kann man es sich einrichten wie man will. Auch einzelne Koordinaten statt größerer Felder wären so möglich abzufragen.
Zuletzt geändert von Packard am 04.04.2008, 00:50, insgesamt 1-mal geändert.
@ Packard
... mit 256 Möglichkeiten bei Zonen, Markierungen, Variablen, Gruppen ...
Gut, dies wäre was meiner Vorstellung bis zu einer Kartengröße die max. 768² der jetzigen entspricht, gerade so ausreichend ...
Denn diese Größe entspricht 2,25 mal einer 512² Karte also 256:2.25=ca.114 mögliche Zonen auf 512² Kartenfläche, eben gerade so ausreichend
Die Feldgröße jetzt läßt es zu 4 Inf. oder ein Fahrzeug "konfliktfrei" auf zu stellen, die Koordinaten ... muss der Scripter diese haben? können diese weiter im Hintergrund bleiben?
Wenn ein Höhensystem eingebaut wird kann dies alles auf positive Werte basieren und man läßt grundsätzlich negative aus, wäre nur die Frage wie sieht es bei den Drehrichtungen aus, hier nur linksrum weggetreten ... oder größer 360° ist erst "positiv" ...
MfG
... mit 256 Möglichkeiten bei Zonen, Markierungen, Variablen, Gruppen ...
Gut, dies wäre was meiner Vorstellung bis zu einer Kartengröße die max. 768² der jetzigen entspricht, gerade so ausreichend ...
Denn diese Größe entspricht 2,25 mal einer 512² Karte also 256:2.25=ca.114 mögliche Zonen auf 512² Kartenfläche, eben gerade so ausreichend
Die Feldgröße jetzt läßt es zu 4 Inf. oder ein Fahrzeug "konfliktfrei" auf zu stellen, die Koordinaten ... muss der Scripter diese haben? können diese weiter im Hintergrund bleiben?
Wenn ein Höhensystem eingebaut wird kann dies alles auf positive Werte basieren und man läßt grundsätzlich negative aus, wäre nur die Frage wie sieht es bei den Drehrichtungen aus, hier nur linksrum weggetreten
... oder größer 360° ist erst "positiv" ...MfG
Die Feldgröße jetzt läßt es zu 4 Inf. oder ein Fahrzeug "konfliktfrei" auf zu stellen,
Das System mit den Feldern ist schon gut. Für die blockierten Felder. Bei Infantrie paßt da Einer durch eine 1 Viertelblock breite Lücke, Fahrzeuge brauchen das doppelte. Da sehe ich im Augenblick keine Verbesserungsmöglichkeit.
die Koordinaten ... muss der Scripter diese haben? können diese weiter im Hintergrund bleiben?
Weiß noch nicht ob die jemand braucht. Sonst bleiben sie natürlich im Hintergrund.
Wenn ein Höhensystem eingebaut wird kann dies alles auf positive Werte basieren und man läßt grundsätzlich negative aus, wäre nur die Frage wie sieht es bei den Drehrichtungen aus, hier nur linksrum weggetreten ... oder größer 360° ist erst "positiv" ...
Ob es ein Höhensystem mit einer richtigen Höhenachse geben wird ist fraglich. Dann hätten wir ja schon 3D-Koordinaten. Es wird wohl eher beim Tricksen bleiben, sodaß Höhenunterschiede nur irgendwie grafisch dargestellt werden. Aber da kann man auch schon viel machen. Wenn da jemand Ideen hat, wie die Höhen gemacht werden können bitte erklären.
Das Drehen bei den Einheiten dürfte über die Bildnummer gemacht werden. Bei Personen werden ringsum 8 Bilder, bei kleinen Fahrzeugen 32 für die Basisanimation gemacht. Drehen bedeutet die Bildnummer hoch- oder runtersetzen.
Das System mit den Feldern ist schon gut. Für die blockierten Felder. Bei Infantrie paßt da Einer durch eine 1 Viertelblock breite Lücke, Fahrzeuge brauchen das doppelte. Da sehe ich im Augenblick keine Verbesserungsmöglichkeit.
die Koordinaten ... muss der Scripter diese haben? können diese weiter im Hintergrund bleiben?
Weiß noch nicht ob die jemand braucht. Sonst bleiben sie natürlich im Hintergrund.
Wenn ein Höhensystem eingebaut wird kann dies alles auf positive Werte basieren und man läßt grundsätzlich negative aus, wäre nur die Frage wie sieht es bei den Drehrichtungen aus, hier nur linksrum weggetreten ... oder größer 360° ist erst "positiv" ...
Ob es ein Höhensystem mit einer richtigen Höhenachse geben wird ist fraglich. Dann hätten wir ja schon 3D-Koordinaten. Es wird wohl eher beim Tricksen bleiben, sodaß Höhenunterschiede nur irgendwie grafisch dargestellt werden. Aber da kann man auch schon viel machen. Wenn da jemand Ideen hat, wie die Höhen gemacht werden können bitte erklären.
Das Drehen bei den Einheiten dürfte über die Bildnummer gemacht werden. Bei Personen werden ringsum 8 Bilder, bei kleinen Fahrzeugen 32 für die Basisanimation gemacht. Drehen bedeutet die Bildnummer hoch- oder runtersetzen.
Das System mit den Feldern ist schon gut. Für die blockierten Felder. Bei Infantrie paßt da Einer durch eine 1 Viertelblock breite Lücke, Fahrzeuge brauchen das doppelte. Da sehe ich im Augenblick keine Verbesserungsmöglichkeit.
... nur die Diagonalen besser blocken wie dies jetzt der Fall ist, denn an manchen Stellen geht es nur mit 4 viertel Blockaden ... für Inf. ... und bei einem viertel "schlüpfen" über die Diagonale schonmal Fahrzeuge durch ...! ... nur die Feld-Ausrichtung ändern bringt nicht immer den gewünschten Erfolg ...
@ Zu Anfang hab ich selbst immer mal gedacht die Koordinaten wären nicht schlecht, war wohl nur "Berufsbedingt" ... jetzt brauch ich sie nicht mehr (unbedingt)
MfG
... nur die Diagonalen besser blocken wie dies jetzt der Fall ist, denn an manchen Stellen geht es nur mit 4 viertel Blockaden ... für Inf. ... und bei einem viertel "schlüpfen" über die Diagonale schonmal Fahrzeuge durch ...!
... nur die Feld-Ausrichtung ändern bringt nicht immer den gewünschten Erfolg ...@ Zu Anfang hab ich selbst immer mal gedacht die Koordinaten wären nicht schlecht, war wohl nur "Berufsbedingt" ... jetzt brauch ich sie nicht mehr (unbedingt)
MfG
Habe festgestellt, daß die Fahrzeuge nur in 8 Richtungen fahren können, obwohl 32 Bilder vorhanden sind, die zum Drehen benutzt werden. Mal sehen ob es möglich ist alle 32 Bilder auch zum Fahren zu benutzen. Mit 32 Fahrwinkeln zusammen mit einer Karte, die nicht mehr aus Tiles besteht, sondern als Ganzes geladen wird dürfte die Dartstellung schon ein Stück realistischer als bisher ausfallen.
Aber ich will die Erwartungen nicht zu hoch schrauben. Insgesamt wird die Grafik wohl ähnlich wie bei der SuSt2 - Familie, also in 2D bleiben. Aber ich sehe daß da noch begeistert an den Mods gearbeitet wird. So unbedingt nötig scheint 3D also nicht zu sein.
Das mit den Blockaden ist auch eine Interessante Sache. Mal sehen, vielleicht bringt es was, wenn die Felder etwas kleiner gemacht werden um eine exaktere Anpassung zu ermöglichen.
Aber ich will die Erwartungen nicht zu hoch schrauben. Insgesamt wird die Grafik wohl ähnlich wie bei der SuSt2 - Familie, also in 2D bleiben. Aber ich sehe daß da noch begeistert an den Mods gearbeitet wird. So unbedingt nötig scheint 3D also nicht zu sein.
Das mit den Blockaden ist auch eine Interessante Sache. Mal sehen, vielleicht bringt es was, wenn die Felder etwas kleiner gemacht werden um eine exaktere Anpassung zu ermöglichen.
@ 3D / 2D dachte dies wäre längst erledigt? wer 3D will soll spielen was er will, so lange nicht größzügig Einheiten verwendet werden ohne einen allerwelts PC verwenden zu können braucht Niemand damit zu kommen ... kommt Jemand auf die Idee unbedingt realistische Figuren für ein Schachspiel haben zu müssen? ... und doch versuchen sich viele an diesem Spiel!
Realistisch aussehende Einheiten o.k. wenn es die Möglichkeiten nicht zu sehr begrenzt, sonst etwas auf "Realismus" zu gunsten ordentlicher strategischer Möglichkeiten verzichtet, denn diese wird ein Spiel interessant halten nicht wie die Einheiten im (kleinsten)Detail aussehen
Das man ebenso auf "realistische" Landschaftslelemente verzichten muss ... etwas ist halt immer ...!
Wie stellst du dir das mit der Wegnutzung vor? bei 32 Fahr-Winkeln, alle 11.25° eine durchgängige Wegnutzung bis zum nächsten Hindernis? ausweichen in möglichst diesen 11.25°-Schritten ... zusätzliche Leistungsanforderung die sich bemerkbar macht ...
MfG
... kommt Jemand auf die Idee unbedingt realistische Figuren für ein Schachspiel haben zu müssen? ... und doch versuchen sich viele an diesem Spiel!Realistisch aussehende Einheiten o.k. wenn es die Möglichkeiten nicht zu sehr begrenzt, sonst etwas auf "Realismus" zu gunsten ordentlicher strategischer Möglichkeiten verzichtet, denn diese wird ein Spiel interessant halten nicht wie die Einheiten im (kleinsten)Detail aussehen
Das man ebenso auf "realistische" Landschaftslelemente verzichten muss ... etwas ist halt immer ...!
Wie stellst du dir das mit der Wegnutzung vor? bei 32 Fahr-Winkeln, alle 11.25° eine durchgängige Wegnutzung bis zum nächsten Hindernis? ausweichen in möglichst diesen 11.25°-Schritten ... zusätzliche Leistungsanforderung die sich bemerkbar macht ...
MfG
3D / 2D dachte dies wäre längst erledigt?
Naja, es wird immer wieder von den Höhen angefangen, der 3. Dimension. Umd auch ich würde gerne unterfahrbare Brücken, abtauchbare U-Boote, Einheiten von Flachdächern aus schießen (gabs ja teilweise schon), realistische Berge, Flugzeuge in verschiedenen Höhen ( auch kein Problem) und andere Höheneffekte in der endgültigen Version sehen.
Das läßt sich auch alles irgenswie darstellen, ohne daß man ein 3D- System braucht, wo dann eine Szene mit vielen Polygonen berechnet wird. Zwar bleibt dann der Blickwinkel immer gleich und auch die Sonne bleibt immer an der gleichen imaginären Stelle links oben, sodaß die Schatten immer kurz nach rechts fallen. Es gibt auch keine realistische Perspektive, sondern die Darstellung ist orthogonal.
Aber damit kann man leben finde ich und dafür hat man eine größere Schnelligkeit, die den Einsatz von größeren Karten und mehr Einheiten erlaubt.
wer 3D will soll spielen was er will, so lange nicht größzügig Einheiten verwendet werden ohne einen allerwelts PC verwenden zu können braucht Niemand damit zu kommen
Die Mindestharwareanfordeungen von Open Strike werden wohl ähnlich wie bei SuSt2 sein. Mit einem leistungsfähigen Computer wird man enttsprechend größere Karten schneller spielen können.
Realistisch aussehende Einheiten o.k. wenn es die Möglichkeiten nicht zu sehr begrenzt, sonst etwas auf "Realismus" zu gunsten ordentlicher strategischer Möglichkeiten verzichtet, denn diese wird ein Spiel interessant halten nicht wie die Einheiten im (kleinsten)Detail aussehen
Das man ebenso auf "realistische" Landschaftslelemente verzichten muss ... etwas ist halt immer ...!
Zum Realismus gehört auch der verstärkte Einsatz von Zivilfiguren, wobei das natürlich im Ermessen des Mapdesigners liegt. Bisher gab es ja keine Zivilfahrzeuge, was nicht der Wirklichkeit entspricht. Wenn der Einsatz von allen Arten von Zivilfahrzeugen möglich wird ist es erst eine realistische Simulation.
Wie stellst du dir das mit der Wegnutzung vor? bei 32 Fahr-Winkeln, alle 11.25° eine durchgängige Wegnutzung bis zum nächsten Hindernis? ausweichen in möglichst diesen 11.25°-Schritten ... zusätzliche Leistungsanforderung die sich bemerkbar macht ...
Der Computer "denkt" ja bekanntlich anders als der Mensch. Ein Programm in C oder Maschinensprache zu formulieren klingt gänzlich anders als in Menschensprache. In der Praxis sieht das bei der Wegfindung etwa so aus, daß eine Einheit eine Message bekommt wie move x,y. Sie soll sich zu einer Koordinate bewegen. Jetzt stellt sie fest, auf welcher Koordinate sie sich befindet und errechnet daraus die darzustellende Bildnummer (Luftlinie). Dann setzt sie sich in Bewegung. Bis sie auf ein Hindernis stößt. Hier fangen die Probleme an und es wird kompliziert. Bei SuSt 2 ist die Wegfindung daher begrenzt und man findet Einheiten manchmal in "Sackgassen" wo sie nicht weiterkommen. Da ist im Interesse der Spielgeschwindigkeit die Wegfindung nicht konsequent bis zum Ende programmiert worden. Denn wenn eine Einheit sehr lange "überlegt" wie sie sich weiterbewegt (und am Ende vielleicht doch nur zu dem Ergebnis kommt, das sie eingeklemmt ist oder nicht ans Ziel gelangen kann) nimmt sie dadurch gleichzeitig den Anderen Rechenzeit weg. Wenn das alle oder viele Einheiten machen, bleibt am Ende nur ein quälend langsamer Spielablauf. Darum wurde im Handbuch von SuSt2 darauf hingewiesen, daß man bei komplizierten Wegen mehrere - möglichst grade - Etappen mit der Befehlskette verwenden soll.
Bei Open Strike wird man (wahrscheinlich) die Möglichkeit haben, die Standardwegfindung durch eine eigene zu ersetzen, wenn man da besondere Sachen einbauen möchte.
MfG
Naja, es wird immer wieder von den Höhen angefangen, der 3. Dimension. Umd auch ich würde gerne unterfahrbare Brücken, abtauchbare U-Boote, Einheiten von Flachdächern aus schießen (gabs ja teilweise schon), realistische Berge, Flugzeuge in verschiedenen Höhen ( auch kein Problem) und andere Höheneffekte in der endgültigen Version sehen.
Das läßt sich auch alles irgenswie darstellen, ohne daß man ein 3D- System braucht, wo dann eine Szene mit vielen Polygonen berechnet wird. Zwar bleibt dann der Blickwinkel immer gleich und auch die Sonne bleibt immer an der gleichen imaginären Stelle links oben, sodaß die Schatten immer kurz nach rechts fallen. Es gibt auch keine realistische Perspektive, sondern die Darstellung ist orthogonal.
Aber damit kann man leben finde ich und dafür hat man eine größere Schnelligkeit, die den Einsatz von größeren Karten und mehr Einheiten erlaubt.
wer 3D will soll spielen was er will, so lange nicht größzügig Einheiten verwendet werden ohne einen allerwelts PC verwenden zu können braucht Niemand damit zu kommen
Die Mindestharwareanfordeungen von Open Strike werden wohl ähnlich wie bei SuSt2 sein. Mit einem leistungsfähigen Computer wird man enttsprechend größere Karten schneller spielen können.
Realistisch aussehende Einheiten o.k. wenn es die Möglichkeiten nicht zu sehr begrenzt, sonst etwas auf "Realismus" zu gunsten ordentlicher strategischer Möglichkeiten verzichtet, denn diese wird ein Spiel interessant halten nicht wie die Einheiten im (kleinsten)Detail aussehen
Das man ebenso auf "realistische" Landschaftslelemente verzichten muss ... etwas ist halt immer ...!
Zum Realismus gehört auch der verstärkte Einsatz von Zivilfiguren, wobei das natürlich im Ermessen des Mapdesigners liegt. Bisher gab es ja keine Zivilfahrzeuge, was nicht der Wirklichkeit entspricht. Wenn der Einsatz von allen Arten von Zivilfahrzeugen möglich wird ist es erst eine realistische Simulation.
Wie stellst du dir das mit der Wegnutzung vor? bei 32 Fahr-Winkeln, alle 11.25° eine durchgängige Wegnutzung bis zum nächsten Hindernis? ausweichen in möglichst diesen 11.25°-Schritten ... zusätzliche Leistungsanforderung die sich bemerkbar macht ...
Der Computer "denkt" ja bekanntlich anders als der Mensch. Ein Programm in C oder Maschinensprache zu formulieren klingt gänzlich anders als in Menschensprache. In der Praxis sieht das bei der Wegfindung etwa so aus, daß eine Einheit eine Message bekommt wie move x,y. Sie soll sich zu einer Koordinate bewegen. Jetzt stellt sie fest, auf welcher Koordinate sie sich befindet und errechnet daraus die darzustellende Bildnummer (Luftlinie). Dann setzt sie sich in Bewegung. Bis sie auf ein Hindernis stößt. Hier fangen die Probleme an und es wird kompliziert. Bei SuSt 2 ist die Wegfindung daher begrenzt und man findet Einheiten manchmal in "Sackgassen" wo sie nicht weiterkommen. Da ist im Interesse der Spielgeschwindigkeit die Wegfindung nicht konsequent bis zum Ende programmiert worden. Denn wenn eine Einheit sehr lange "überlegt" wie sie sich weiterbewegt (und am Ende vielleicht doch nur zu dem Ergebnis kommt, das sie eingeklemmt ist oder nicht ans Ziel gelangen kann) nimmt sie dadurch gleichzeitig den Anderen Rechenzeit weg. Wenn das alle oder viele Einheiten machen, bleibt am Ende nur ein quälend langsamer Spielablauf. Darum wurde im Handbuch von SuSt2 darauf hingewiesen, daß man bei komplizierten Wegen mehrere - möglichst grade - Etappen mit der Befehlskette verwenden soll.
Bei Open Strike wird man (wahrscheinlich) die Möglichkeit haben, die Standardwegfindung durch eine eigene zu ersetzen, wenn man da besondere Sachen einbauen möchte.
MfG
Die Formel findest Du hier: http://www.panzerworld.net/relativearmourplastique hat geschrieben:
Um das Schadensmodell einfach zu halten - also von der Berechnung von Einschlagswinkeln abzusehen - könnte man den Schaden innerhalb einer bestimmten Spanne zufallsweise bestimmen (lassen). (Falls es das tatsächlich einfacher hält...) Letztendlich ergeben sich durch schräge Panzerung ohnehin nur zentimeterweise Unterschiede.
by the way - hat jemand die/eine Formel zu Berechnung der Panzerdicke bei einem bestimmten Aufschlagswinkel?
Bedingung "Entfernung" ins Schadensmodell aufnehmen.
Für MS Excel verwende ich:
=DICKE/(SIN(WINKEL*3,141592654/180))
Danke!
Ein Schlaumeier würde jetzt sagen, DICKE/SIN(WINKEL*PI()/180) geht auch. Bin ich aber nicht!
Wie sind denn eigentlich folgende Angaben zu verstehen?
Distance, m: 914
Meet angle 60°, mm: 46
Meet angle 70°, mm: 53
Wie groß der Winkel ist, müsste doch egal sein, wenn einzig der Weg (in mm) entscheidend ist. Trotzdem wird bei solchen "Penetration-Tables" oft der Aufschlagswinkel mitangegeben und hier und da findet man mehrere Winkel mit unterschiedlichen Angaben (wie oben - Link).
Mal abgesehen davon, dass für dieses Geschütz bei 30° und 914m ebenfalls 46mm zu finden sind - beziehen sich die Angaben auf die wahre Dicke, d.h. sind sie umzurechnen in die relative 46mm -> 53mm bzw. 53mm -> 56mm (auch wenn sich hier leichte Unterschiede ergeben)? Will meinen, durchschlägt das Geschütz in diesem Beispiel nicht 46 bzw. 53mm, sondern eigentlich den Weg von ca. 53-56mm Panzerung?
Ein Schlaumeier würde jetzt sagen, DICKE/SIN(WINKEL*PI()/180) geht auch. Bin ich aber nicht!
Wie sind denn eigentlich folgende Angaben zu verstehen?
Distance, m: 914
Meet angle 60°, mm: 46
Meet angle 70°, mm: 53
Wie groß der Winkel ist, müsste doch egal sein, wenn einzig der Weg (in mm) entscheidend ist. Trotzdem wird bei solchen "Penetration-Tables" oft der Aufschlagswinkel mitangegeben und hier und da findet man mehrere Winkel mit unterschiedlichen Angaben (wie oben - Link).
Mal abgesehen davon, dass für dieses Geschütz bei 30° und 914m ebenfalls 46mm zu finden sind - beziehen sich die Angaben auf die wahre Dicke, d.h. sind sie umzurechnen in die relative 46mm -> 53mm bzw. 53mm -> 56mm (auch wenn sich hier leichte Unterschiede ergeben)? Will meinen, durchschlägt das Geschütz in diesem Beispiel nicht 46 bzw. 53mm, sondern eigentlich den Weg von ca. 53-56mm Panzerung?
Zum Thema Schadenssystem by SuSt habe ich einen interessanten Beitrag von Cougar6 bei Strateticgames gefunden. Schaut euch mal den PWM 2 genau an. Der hat Ahnung vom Modden!
"Hallo,
ich möchte mal die an anderer Stelle von Tijn gestellte Frage nach der Berechnung des Schadens bei Sudden Strike aufgreifen und ein paar Dinge zum Schadenssystem des Spiels erklären (soweit ich es jedenfalls verstanden habe...)
Die abgezogenen Hitpoints hängen im wesentlichen von vier Faktoren ab:
* Waffenschaden
* Panzerung des Ziels
* Einstellungen der Datei "HITSNAMES"
* Einstellung der Datei "MISC"
1. Waffenschaden
Das erklärt sich ja von selbst. Man stellt einen Wert in der Einheitenbeschreibung ein und teilt eine sogenannte shot_id zu. Jede shot_ID ist einer "Schadensart" zugeteilt. (z.B. PIERCE oder EXPLOSIVE)
Die Parameter für diese Schadensart werden dann in HITSNAMES und MISC definiert.
Das könnte dann so aussehen:
shot_id 75mm_KWK
shot_damage 50 50
2. Panzerung des Ziels
Auch fast selbsterklärend. Jeder Schadensart werden 6 Werte zu geteilt, für Front-, Seiten- und Heckpanzerung.der vordere Wert zählt bei 0 und der zweite bei 100% Erfahrung. zu beachten ist, daß der maximale Wert für Panzerung 256 ist.
Das sieht dann z.B. so aus:
armor PIERCE 100 100 49 49 10 10
(ich benutze selbst keinen Erfahrungsgewinn für Panzerungswerte, deshalb sind hier die Werte gleich)
3. Einstellungen in "HITSNAMES"
Diese Datei definiert die Grundparameter für die Schadensarten. Man kan eigene Schadensarten hinzufügen. Ich kann nicht alle Werte vollständig erklären, aber hier schon mal das wichtigste.
- name rad step typ add
PIERCE 2 1 all 1
name definiert die Schadensart.
rad gibt den "Trefferradius" vor, gemessen in Pixeln. Jeder, der sich schon mal eine Einheitenbeschreibung angesehen hat, konnte den Wert "radius" darin finden. Dieser gibt die rechnerische Größe einer Einheit im Spiel an. Wie groß dieser Wert ist, hängt vom Geschmack des Modders ab und wird verschieden gehandhabt. Als Anhaltspunkt kann man sagen, daß jedes "Geländefeld" 32 Pixel mißt.
Das ganze Sytem funkioniert so, daß bei Beschuß überprüft wird, ob sich die beiden imaginären Kreise mit den Radien der EInheit und des Geschosses schneiden. Ist das so, wird Schaden ausgelöst.
typ stellt unter anderem ein, ob es sich um boden oder Luftbeschuß (AIR) handelt.
Zu den anderen Werten muß ich noch ein wenig testen.
4. Einstellungen in "MISC"
Dies ist der Kern des Kampsystems. Hier wird definiert, welcher Schaden, wieviel Panzerung durchschlägt. Es wird eine einfache lineare Beziehung aufgestellt.
Das sieht dann so aus:
shot_damage pierce 1 256
shot_armor pierce 1 256
shot_delta pierce 1
Das bedeutet, daß 1 Punkt Schaden 1 Punkt Panzerung durchschlägt und 256 Punkte Schaden 256 Punkte Panzerung. da höhere Werte als 256 nicht zulässig sind, macht es keinen Sinn hier mehr einzutragen.
Abhängig davon, wie viele Hitpoints die Objekte im Spiel haben sollen, kann man die Steigung der imaginären Gerade verändern:
shot_damage pierce 10 2560
shot_armor pierce 1 256
shot_delta pierce 1
Hier hat sich der notwendige Wert um 1 Punkt Panzerung zu durchschlagen schon auf 10 erhöht, usw.
Der Clou ist aber der Wert Shot_delta. Dieser stellt nämlich ein, wieviel Schaden nach Überwinden der Panzerung gemacht wird. 1 bedeutet, daß der VOLLE Schaden, wie er in der Beschreibung der angreifenden Einheit defiiert wurde, auf das ziel angewendet wird. Wird dieser Wert erhöht, wird der Schaden verringert. Für unser Beispiel vom Anfang:
Ein Panzer mit 200 Hitpoints wird von der shot_id 75mm_KWK mit 50 Punkten Schaden und den oben beschriebenen Einstellungen angegriffen:
Treffer in die Front (100 Panzerung): kein Schaden
Treffer in die Seite (49 Panzerung): 50 punkte Schaden
Treffer in das Heck (10 Panzerung): 50 Punkte Schaden
Man kann also frontal so lange drauf ballern, wie man will. Seitlich und von hinten reichen 4 Treffer aus, da Ziel zu vernichten.
Wie man sich vorstellen kann, gib es unendlich viele Kombinationen von Einstellungen und Werten. Man kann auch sekundären Schaden über die Explosionsdateien einbringen, oder den Wert Delta vergrößern, um weniger Schaden nach Durchschuß zu bekommen, da ist dann der persönliche Geschmack gefragt.
Auch scheint das System nicht vollständig ohne fehler zu funktionieren. Es kam schon vor, daß Treffer in die Bugpanzerung, eigentlich zu gut gepanzert, Schaden machten und Hecktreffer weniger Schaden machten als erwartet, wobei dabei Explosionen im SPiel waren..."
(Cougar6)
"Hallo,
ich möchte mal die an anderer Stelle von Tijn gestellte Frage nach der Berechnung des Schadens bei Sudden Strike aufgreifen und ein paar Dinge zum Schadenssystem des Spiels erklären (soweit ich es jedenfalls verstanden habe...)
Die abgezogenen Hitpoints hängen im wesentlichen von vier Faktoren ab:
* Waffenschaden
* Panzerung des Ziels
* Einstellungen der Datei "HITSNAMES"
* Einstellung der Datei "MISC"
1. Waffenschaden
Das erklärt sich ja von selbst. Man stellt einen Wert in der Einheitenbeschreibung ein und teilt eine sogenannte shot_id zu. Jede shot_ID ist einer "Schadensart" zugeteilt. (z.B. PIERCE oder EXPLOSIVE)
Die Parameter für diese Schadensart werden dann in HITSNAMES und MISC definiert.
Das könnte dann so aussehen:
shot_id 75mm_KWK
shot_damage 50 50
2. Panzerung des Ziels
Auch fast selbsterklärend. Jeder Schadensart werden 6 Werte zu geteilt, für Front-, Seiten- und Heckpanzerung.der vordere Wert zählt bei 0 und der zweite bei 100% Erfahrung. zu beachten ist, daß der maximale Wert für Panzerung 256 ist.
Das sieht dann z.B. so aus:
armor PIERCE 100 100 49 49 10 10
(ich benutze selbst keinen Erfahrungsgewinn für Panzerungswerte, deshalb sind hier die Werte gleich)
3. Einstellungen in "HITSNAMES"
Diese Datei definiert die Grundparameter für die Schadensarten. Man kan eigene Schadensarten hinzufügen. Ich kann nicht alle Werte vollständig erklären, aber hier schon mal das wichtigste.
- name rad step typ add
PIERCE 2 1 all 1
name definiert die Schadensart.
rad gibt den "Trefferradius" vor, gemessen in Pixeln. Jeder, der sich schon mal eine Einheitenbeschreibung angesehen hat, konnte den Wert "radius" darin finden. Dieser gibt die rechnerische Größe einer Einheit im Spiel an. Wie groß dieser Wert ist, hängt vom Geschmack des Modders ab und wird verschieden gehandhabt. Als Anhaltspunkt kann man sagen, daß jedes "Geländefeld" 32 Pixel mißt.
Das ganze Sytem funkioniert so, daß bei Beschuß überprüft wird, ob sich die beiden imaginären Kreise mit den Radien der EInheit und des Geschosses schneiden. Ist das so, wird Schaden ausgelöst.
typ stellt unter anderem ein, ob es sich um boden oder Luftbeschuß (AIR) handelt.
Zu den anderen Werten muß ich noch ein wenig testen.
4. Einstellungen in "MISC"
Dies ist der Kern des Kampsystems. Hier wird definiert, welcher Schaden, wieviel Panzerung durchschlägt. Es wird eine einfache lineare Beziehung aufgestellt.
Das sieht dann so aus:
shot_damage pierce 1 256
shot_armor pierce 1 256
shot_delta pierce 1
Das bedeutet, daß 1 Punkt Schaden 1 Punkt Panzerung durchschlägt und 256 Punkte Schaden 256 Punkte Panzerung. da höhere Werte als 256 nicht zulässig sind, macht es keinen Sinn hier mehr einzutragen.
Abhängig davon, wie viele Hitpoints die Objekte im Spiel haben sollen, kann man die Steigung der imaginären Gerade verändern:
shot_damage pierce 10 2560
shot_armor pierce 1 256
shot_delta pierce 1
Hier hat sich der notwendige Wert um 1 Punkt Panzerung zu durchschlagen schon auf 10 erhöht, usw.
Der Clou ist aber der Wert Shot_delta. Dieser stellt nämlich ein, wieviel Schaden nach Überwinden der Panzerung gemacht wird. 1 bedeutet, daß der VOLLE Schaden, wie er in der Beschreibung der angreifenden Einheit defiiert wurde, auf das ziel angewendet wird. Wird dieser Wert erhöht, wird der Schaden verringert. Für unser Beispiel vom Anfang:
Ein Panzer mit 200 Hitpoints wird von der shot_id 75mm_KWK mit 50 Punkten Schaden und den oben beschriebenen Einstellungen angegriffen:
Treffer in die Front (100 Panzerung): kein Schaden
Treffer in die Seite (49 Panzerung): 50 punkte Schaden
Treffer in das Heck (10 Panzerung): 50 Punkte Schaden
Man kann also frontal so lange drauf ballern, wie man will. Seitlich und von hinten reichen 4 Treffer aus, da Ziel zu vernichten.
Wie man sich vorstellen kann, gib es unendlich viele Kombinationen von Einstellungen und Werten. Man kann auch sekundären Schaden über die Explosionsdateien einbringen, oder den Wert Delta vergrößern, um weniger Schaden nach Durchschuß zu bekommen, da ist dann der persönliche Geschmack gefragt.
Auch scheint das System nicht vollständig ohne fehler zu funktionieren. Es kam schon vor, daß Treffer in die Bugpanzerung, eigentlich zu gut gepanzert, Schaden machten und Hecktreffer weniger Schaden machten als erwartet, wobei dabei Explosionen im SPiel waren..."
(Cougar6)