ATB -> CTB

[Cornix]

Falls du immernoch mit deinem Algorithmus etwas ähnliches implementierst, wie das was ich beschrieben hatte, dann müsstest du eine "Aktions-Dauer" beim abziehen des Ready-Werts implementieren. Also diese Zeile von meinem Algorithmus würde sie ändern:

Alt:

Sobald ein Charakter seinen Zug durchgeführt hat gilt: Ready-Wert = Ready-Wert - Ready-Limit

...

Neu:

Sobald ein Charakter seinen Zug durchgeführt hat gilt: Ready-Wert = Ready-Wert - (Ready-Limit * Aktions-Dauer)

...

Eine Aktion könnte also eine Dauer von 2,0 haben und würde dann doppelt so lange dauern wie eine Aktion mit einer Dauer von 1,0.

Falls du keine Kommazahlen zur Verfügung hast kannst du eine simple Prozentrechnung durch eine Teilung durch 100 nach der Multiplikation erreichen. Also:

Ready-Wert = Ready-Wert - (Ready-Limit * Aktions-Dauer) / 100

...

Hierbei wäre die Aktions-Dauer ein Prozentwert, also 100 für 100%, 175 für 175%, etc.

Vielleicht hilft dir das ja in irgendeiner Weise weiter.

[IndependentArt]

@Cornix

Von der Seite könnte man das natürlich auch angehen. Muss ich mal ausprobieren. u.U. droppt der Wert dann halt zeitweise ins Minus.
Bis jetzt hab ich quasi versucht, die Prozentrechnung auf den Wert, der immer hinzugefügt wird (quasi den Tempowert) anzuwenden. Bin mir nicht sicher, was das für nen Unterschied macht.
edit: das scheint mir zum genau gleichen Ergebnis zu führen. ich schreib morgen nochmal, womit ich momentan etwas hadere.

[IndependentArt]

Ich habe das Gefühl, es wird langsam. Trotzdem gehen dem Skript noch nicht die Ideen für neue Bugs aus.
Ich versuche mal mein gegenwärtiges Problem mit Hilfe dieses Videos zu erörtern:



Ich verlange nicht, dass da jemand durchsieht. Vielleicht hilft es mir ja auch schon, das einfach aufzuschreiben.
Die Aktion Zauber hat in diesem Beispiel eine Geschwindigkeit von 20% (vom Tempowert, bei Tempowert 10 also 2). Man könnte auch sagen, sie ist 80% langsamer als der normale Angriff. Dementsprechend viele Züge bekommt der Gegner, wenn ich sie auswähle. (ich benutze dann nur Abwehr, weil das als Aktion keine wirkliche Dauer hat)
Verfolgt man das Video weiter, sieht man, dass der Hase 2 Mal dran ist. Nach dem 2. Zug, verändert sich jedoch die Reihenfolge (etwa bei Sekunde 9, Tipp: mit , und . kann man Frames springen ). Das hat damit zu tun, dass die "Aktionsdauer" zurückgesetzt wird. Das heißt, ab da werden die nächsten Züge nicht mehr mit 20%, spondern wieder mit 100% berechnet und der Charakter ist schneller dran als ursprünglich gedacht. Das hat damit zu tun, was ich weiter oben beschrieben habe, dass die veränderte Aktionsdauer nur für den nächsten Zug angenommen wird und die Züge danach wieder mit 100% berechnet werden.

Nun könnte man auf die Idee kommen zu sagen: "Na dann lass die Zugdauer halt bis zum nächsten Zug des Charakters gleich".
Das war auch mein erster Impuls, aber ich habe den Eindruck, wenn ich mit 20% NEU berechne, funktioniert das auch nicht wirklich. Vielleicht hab ich da aber auch nur irgendnen Fehler drin, den ich grad noch nicht checke.

[Caledoriv]

Was wäre denn das gewünschte Verhalten? Irgendwie stehe ich hier öfter auf dem Schlauch...
Soll der Hase bei dem niedrigen Tempowert des Helden 4x hintereinander dran kommen? In dem Fall sollte der Tempo-Modifikator erst mit dem nächsten Zug des Charakters geändert werden.

Als kleine Anmerkung: Die Berechnung zeigt hier teilweise falsche Prognosen an; es wird angezeigt: Hase Hase Hase Hase Hase Ramirez Hase Hase Hase Hase Hase Ramirez ....
Der unterstrichene Teil ist da ja noch korrekt, aber danach stimmt es nicht mehr.

----
Was hälst du davon, jedem Zauber einfach einen (ggf. vom Tempowert abhängigen) Malus zu geben, der einmalig abgezogen wird? Dann sollte die Berechnung immer korrekt angezeigt werden.

[IndependentArt]

Soll der Hase bei dem niedrigen Tempowert des Helden 4x hintereinander dran kommen? In dem Fall sollte der Tempo-Modifikator erst mit dem nächsten Zug des Charakters geändert werden.

...

Ja, so soll das eigentlich laufen. Den Tempo-Modifikator erst mit dem nächsten Zug zu ändern hab ich wie gesagt versucht, aber vlt hab ich da auch nen Fehler reingebaut.

Hase Hase Hase Hase Hase Ramirez Hase Hase Hase Hase Hase Ramirez ....
Der unterstrichene Teil ist da ja noch korrekt, aber danach stimmt es nicht mehr.

...

Wo genau siehst du da den Fehler ...?

Was hälst du davon, jedem Zauber einfach einen (ggf. vom Tempowert abhängigen) Malus zu geben, der einmalig abgezogen wird? Dann sollte die Berechnung immer korrekt angezeigt werden.

...

Das dürfte ungefähr auf das gleiche hinauslaufen, was Cornix mit "Ready-Wert = Ready-Wert - (Ready-Limit * Aktions-Dauer) / 100" vorgeschlagen hat, oder?

[Caledoriv]

Wo genau siehst du da den Fehler ...?

...

Angezeigt wird: 4x Gegner, Held, 4x Gegner
Aber die tatsächliche Reihenfolge ist doch eher: 4x Gegner, Held, 1x Gegner, Held
Weil der Held ja erstmal wieder sein "normales Tempo" zurückbekommt, wenn er das erste Mal wieder dran ist, oder?

Das dürfte ungefähr auf das gleiche hinauslaufen, was Cornix mit "Ready-Wert = Ready-Wert - (Ready-Limit * Aktions-Dauer) / 100" vorgeschlagen hat, oder?

...

Das geht alles irgendwo in die gleiche Richtung . Ich dachte eher an:
Ready-Wert = Ready-Wert - Ready-Limit - (Aktionsdauer / Tempowert)

[IndependentArt]

Puh, dieses Skript fuckt mich mehr ab, als ich gedacht hätte. Deswegen will ich mein Hauptproblem nochmal mit Hilfe eines Videos illustrieren.

Bedingungen:
Charakter Tempo: 20
Gegner Tempo: 20
ReadyWert: 41

Ich habe im Video das jeweilige Durchzählen beim Charakter mit einer Message Box visualisiert (nicht für das Preview allerdings).
Außerdem läuft die Formel jetzt wieder mit einem "Malus", wie es Caledoriv nannte. Die Aktion Zauber hat eine Aktionsdauer von 500. Es wird also der ReadyWert*5 abgezogen. Bei 00:27 sieht man dann, dass das erfolgreich erledigt wurde und der aktuelle Wert des Charakters bei -194 liegt.
In der Folge bekommt der Gegner ganze 6 Slots, bevor der Charakter wieder einen bekommt.

Jetzt kommt allerdings das Problem: Der Charakter-Wert hat schon in dieser ersten Runde wieder aus dem Minus "herausgefunden" und einen normalen Wert erreicht. Deshalb wird er in der Berechnung, die ab ca. 00:50 stattfindet, wieder weiter vorn eingegliedert.
Vielleicht hab ich ja mal wieder ein Brett vorm Kopf und die Lösung dafür ist relativ offensichtlich.

[Caledoriv]

Kann es sein, dass du irgendwo den Wert auf 0 setzt? Weil im Video nach dem Hasenangriff bei 0:47 wieder 0 eingeblendet wird.

Alternativ kann es auch sein, dass es einen Bug gibt, wenn der Wert genau 0 erreicht, sobald das Ready-Limit abgezogen wird. Wenn ich mich nicht irre, passiert das an genau der Stelle nämlich auch. Das kann Zufall sein oder auch nicht^^.

[IndependentArt]

Dass der Wert dort auf 0 droppt ist Zufall. Der letzte Wert davor, der für den Charakter errechnet wurde, war 21. als nächstes wird also 21+20-41 gerechnet und es kommt genau auf 0.
Das Problem ist halt, dass die Aktionsdauer angewendet wird, aber für den nächsten Rechendurchgang schon wieder aufgehoben ist.
Ich hab zwar ein paar Ideen, wie man das lösen könnte, aber die erscheinen mir im Moment furchtbar kompliziert.
zB könnte man versuchen, dass von der Aktionsdauer bei jedem Rechendurchgang maximal 100%=1 Zug=ReadyWert abgezogen wird. Das heißt, bei der ersten Berechnung nachdem man den 500% Zug ausgeführt hat, werden auch die 500% abgezogen. Gleichzeitig wird allerdings die Aktionsdauer selbst um 100% erleichtert. Danach werden also dann 400% abgezogen, dann 300% usw., bis der Charakter wieder dran ist und eine neue Aktionsdauer festlegen kann.

[Caledoriv]

Das Problem ist halt, dass die Aktionsdauer angewendet wird, aber für den nächsten Rechendurchgang schon wieder aufgehoben ist.

...

Ganz doofe Frage von meiner Seite: Warum wird da überhaupt etwas aufgehoben?

Das sollte eigentlich auch so funktionieren. Genau das ist ja das Elegante an der Idee, einfach die Dauer als zusätzlichen Malus draufzurechnen .
Beim Erreichen des Ready-Limits wird neben dem Ready-Limit zusätzlich noch die Dauer der Aktion abgezogen. Mehr muss dann eigentlich nicht gemacht werden, weil die Berechnung der Züge wie gehabt weitergehen kann... Die Verzögerung entsteht dann durch diesen Malus, d.h. es dauert länger, bis der Ready-Wert erreicht ist, weil zuerst dieser Malus "abgearbeitet"

Oder übersehe ich da etwas?

[IndependentArt]

Ich bin zwar glaub ich einen Schritt weiter, aber es spackt immer noch rum. Wenigstens mit einem bestimmten Wert für die Aktionsdauer hat es funktioniert.
Noch ein Video mit einer Aktionsdauer von 200 (Rechnung siehe unten) für Zauber:

Man sieht, dass ein Zug des Gegners zwischendrin geschluckt wird.

Evtl übersiehst du bei dem Malus tatsächlich etwas. Ich versuche mal zu erklären warum:
Ich habe das momentan so geregelt, dass ich die Aktionsdauer auf 2 Variablen festlege (1848, 1849). 2 Variablen, weil ich eine davon für das Preview brauche.
Preview Codeblock:

Code:

 @> Conditional Branch: Switch [1733:CTB PREVIEW] is ON
      @> Conditional Branch: Variable [1849:R CTB Aktionsdauer%] > 0
        @> Control Variables: [1806:CTB Ready Abzug] = Variable [1805]
        @> Control Variables: [1806:CTB Ready Abzug] *= Variable [1849]
        @> Control Variables: [1806:CTB Ready Abzug] /= 100 
        @> Control Variables: [1855:R-CTB Order Preview] -= Variable [1806]
        @> Control Variables: [1849:R CTB Aktionsdauer%] = 0 
        @>
       : Branch End
      @> Comment: 
      @> Control Variables: [1855:R-CTB Order Preview] += Variable [1815]
      @> Conditional Branch: Variable [1855:R-CTB Order Preview] >= Variable [1805:CTB Ready]
        @> Control Variables: [1855:R-CTB Order Preview] -= Variable [1805]

Der erste Teil ist quasi die Malus-Rechnung. Wenn eine Aktionsdauer festgelegt wurde, diese also größer als 0 ist, wird die Rechnung durchgeführt. Für eine StandardAktion nehme ich aus gewissen Gründen eine Aktionsdauer von 0 an. Die Rechnung wird also nur ausgeführt, wenn die Dauer drüber liegt.
Der Malus wird errechnet und vom Preview-Wert abgezogen. Außerdem wird die Aktionsdauer 0 gesetzt, weil das ganze nur 1 Mal durchgeführt werden soll. Ich glaube, das funktioniert auch soweit ganz gut. Wenn ich zB einen Aktionswert von 100 festlege, bekommt der Gegner genau einen Zug mehr.
Ich bin nicht sicher, in wie weit das mit eurem Ansatz überein stimmt. Ich fand es wichtig, dass der Malus vor der sonstigen Rechnung abgezogen wird. Passiert das erst danach, könnte ja zwischendrin schon ein Zug berechnet und ein Slot gefüllt worden sein.

Code der eigentlichen Berechnung des Malus nach dem Zug:

Code:

@> Conditional Branch: Variable [1848:R CTB AD% SAVE] > 0
    @> Control Variables: [1806:CTB Ready Abzug] = Variable [1805]
    @> Control Variables: [1806:CTB Ready Abzug] *= Variable [1848]
    @> Control Variables: [1806:CTB Ready Abzug] /= 100 
    @> Control Variables: [1807:R-CTB Order] -= Variable [1806]
    @> Control Variables: [1848:R CTB AD% SAVE] -= 100

Der Block befindet sich direkt am Anfang des Gesamtcodes. Dadurch war es einfacher, ihn nur 1 mal durchlaufen zu lassen. Eigentlich ist fast alles gleich wie bei dem für das Preview. Der Hauptunterschied ist, dass V1848 nicht 0 gesetzt wird, sondern 100 abgezogen wird, weil die Variable ja mehrere Züge, jeweils unter Abzug eines Zuges (-100%) in Benutzung ist.

Die Formel "Ready-Wert = Ready-Wert - Ready-Limit - (Aktionsdauer / Tempowert)" verstehe ich aber offen gesagt auch nicht so recht. Kann es sein, dass da ein falsches Zeichen drin ist?

btw: Irgendwelche Tipps, wie man bei sowas besser den Überblick behält? Ich hab das Gefühl, das ist einfach zu viel für mein gehirn. xD

Gesamtcode:

Code:

@> Conditional Branch: Switch [1733:CTB PREVIEW] is ON
  @> Control Variables: [1855:R-CTB Order Preview] = Variable [1807]
  @> Control Variables: [1856:M/B-CTBOrder Preview] = Variable [1808]
  @> Control Variables: [1857:C/V-CTBOrder Preview] = Variable [1809]
  @> Control Variables: [1858:G1-CTB Order Preview] = Variable [1810]
  @> Control Variables: [1859:G2-CTB Order Preview] = Variable [1811]
  @> Control Variables: [1860:G3-CTB Order Preview] = Variable [1812]
  @> Comment: 
  @>
 : Else
  @> Conditional Branch: Variable [1848:R CTB AD% SAVE] > 0
    @> Control Variables: [1806:CTB Ready Abzug] = Variable [1805]
    @> Control Variables: [1806:CTB Ready Abzug] *= Variable [1848]
    @> Control Variables: [1806:CTB Ready Abzug] /= 100 
    @> Control Variables: [1807:R-CTB Order] -= Variable [1806]
    @> Control Variables: [1848:R CTB AD% SAVE] -= 100 
    @>
   : Branch End
  @>
 : Branch End
@> Control Variables: [1804:Teilnehmer Abfrage] = Variable [1803]
@> Control Variables: [1814:current CTB slot] = 1821 
@> Control Variables: [1841:CTB Kapsel ID] = 2000 
@> Control Variables: [1842:CTB Kapsel X] = 116 
@> Control Variables: [1843:CTB Kapsel Y] = 227 
@> Jump to Label: 10
@> Label: 1
@> Conditional Branch: Switch [1005:Ramirez tot] is OFF
  @> Conditional Branch: Switch [1001:Ramirez nicht im K] is OFF
    @> Conditional Branch: Switch [1733:CTB PREVIEW] is ON
      @> Conditional Branch: Variable [1849:R CTB Aktionsdauer%] > 0
        @> Control Variables: [1806:CTB Ready Abzug] = Variable [1805]
        @> Control Variables: [1806:CTB Ready Abzug] *= Variable [1849]
        @> Control Variables: [1806:CTB Ready Abzug] /= 100 
        @> Control Variables: [1855:R-CTB Order Preview] -= Variable [1806]
        @> Control Variables: [1849:R CTB Aktionsdauer%] = 0 
        @>
       : Branch End
      @> Comment: 
      @> Control Variables: [1855:R-CTB Order Preview] += Variable [1815]
      @> Conditional Branch: Variable [1855:R-CTB Order Preview] >= Variable [1805:CTB Ready]
        @> Control Variables: [1855:R-CTB Order Preview] -= Variable [1805]
        @>
       : Else
        @> Jump to Label: 10
        @>
       : Branch End
      @>
     : Else
      @> Comment: 
       :               : 
      @> Control Variables: [1807:R-CTB Order] += Variable [1815]
      @> Conditional Branch: Variable [1807:R-CTB Order] >= Variable [1805:CTB Ready]
        @> Control Variables: [1807:R-CTB Order] -= Variable [1805]
        @> Control Variables: Variable [1814] = 1 
        @>
       : Else
        @> Jump to Label: 10
        @>
       : Branch End
      @>
     : Branch End
ANZEIGE R

      @>
     : Branch End
    @> Control Variables: [1814:current CTB slot] += 1 
    @> Control Variables: [1841:CTB Kapsel ID] += 1 
    @> Control Variables: [1842:CTB Kapsel X] += 14 
    @>
   : Branch End
  @>
 : Branch End
@> Jump to Label: 10
@> Comment: 
 :               : 
@> Label: 2
@> Conditional Branch: Switch [1009:Gegner 1] is ON
  @> Conditional Branch: Switch [1733:CTB PREVIEW] is ON
    @> Control Variables: [1858:G1-CTB Order Preview] += Variable [1818]
    @> Conditional Branch: Variable [1858:G1-CTB Order Preview] >= Variable [1805:CTB Ready]
      @> Control Variables: [1858:G1-CTB Order Preview] -= Variable [1805]
      @>
     : Else
      @> Jump to Label: 10
      @>
     : Branch End
    @>
   : Else
    @> Control Variables: [1810:G1-CTB Order] += Variable [1818]
    @> Conditional Branch: Variable [1810:G1-CTB Order] >= Variable [1805:CTB Ready]
      @> Control Variables: [1810:G1-CTB Order] -= Variable [1805]
      @> Control Variables: Variable [1814] = 4 
      @>
     : Else
      @> Jump to Label: 10
      @>
     : Branch End
    @>
   : Branch End
ANZEIGE G1

    @>
   : Branch End
  @> Control Variables: [1814:current CTB slot] += 1 
  @> Control Variables: [1841:CTB Kapsel ID] += 1 
  @> Control Variables: [1842:CTB Kapsel X] += 14 
  @>
 : Branch End
@> Jump to Label: 10
@> Comment: 
 :               : 
: Branch End
@> Comment: 
 :               : 
@> Label: 10
@> Conditional Branch: Variable [1814:current CTB slot] < 1838
  @> Control Variables: [1804:Teilnehmer Abfrage] += 1 
  @> Conditional Branch: Switch [1733:CTB PREVIEW] is OFF
    @> Control Variables: [1803:Teiln.Abfrage SAVE] = Variable [1804]
    @>
   : Branch End
  @> Conditional Branch: Variable [1804:Teilnehmer Abfrage] == 1
    @> Jump to Label: 1
    @>
   : Else
    @> Conditional Branch: Variable [1804:Teilnehmer Abfrage] == 2
      @> Jump to Label: 2
      @>
     : Else
      @> Conditional Branch: Variable [1804:Teilnehmer Abfrage] == 3
        @> Jump to Label: 3
        @>
       : Else
        @> Conditional Branch: Variable [1804:Teilnehmer Abfrage] == 4
          @> Jump to Label: 4
          @>
         : Else
          @> Conditional Branch: Variable [1804:Teilnehmer Abfrage] == 5
            @> Jump to Label: 5
            @>
           : Else
            @> Conditional Branch: Variable [1804:Teilnehmer Abfrage] == 6
              @> Control Variables: [1804:Teilnehmer Abfrage] = 0 
              @> Jump to Label: 6
              @>
             : Branch End
            @>
           : Branch End
          @>
         : Branch End
        @>
       : Branch End
      @>
     : Branch End
    @>
   : Branch End
  @>
 : Branch End

@> Control Switches: [1733:CTB PREVIEW] = OFF

[Caledoriv]

Die Formel "Ready-Wert = Ready-Wert - Ready-Limit - (Aktionsdauer / Tempowert)" verstehe ich aber offen gesagt auch nicht so recht. Kann es sein, dass da ein falsches Zeichen drin ist?

btw: Irgendwelche Tipps, wie man bei sowas besser den Überblick behält? Ich hab das Gefühl, das ist einfach zu viel für mein gehirn. xD

...

Für den Code ist es mir jetzt zu spät...

Zur Formel:
Die Idee dazu ist folgende: Wende die Formel an, soabld der Ready-Wert überschritten ist. Hier mal zwei Beispiele (das erste ohne Tempowert, um es einfach zu halten):

Ready-Wert = Ready-Wert - Ready-Limit - Aktionsdauer
Ready-Limit = 300
Ready-Wert nach dem neuen Update: 320
Tempo des Helden: 40

Schritt 1: Ziehe Ready-Limit ab, damit ganz normal die Reihenfolge berechnet werden kann.
Neuer Ready-Wert: 320 - 300 = 20

Schritt 2: Aktion wählen. Die Aktion hat eine Dauer von 100. Ziehe diesen Wert ebenfalls vom Ready-Wert ab:
Neuer Ready-Wert: 20 - 100 = -80

Berechne jetzt ganz normal die Reihenfolge, indem in jeder Iteration der Tempowert auf den Ready-Wert draufgerechnet wird. Der Held braucht ca. 3 Runden, bis er diesen zusätzlichen Malus aufgeholt hat, sodass der Gegner früher wieder dran kommt.

...

Ready-Wert = Ready-Wert - Ready-Limit - (Aktionsdauer / Tempowert)
Das hier macht genau das Gleiche wie oben, allerdings ist die Aktionsdauer (und damit der Malus) jetzt nicht immer konstant, sondern hängt vom Tempowert des Helden ab. D.h. wenn der Held ein höheres Tempo hat, hat er auch einen niedrigeren Malus. (Allerdings muss hier die Aktionsdauer wesentlich höher sein als oben!)

Ready-Limit = 300
Ready-Wert nach dem neuen Update: 320
Tempo des Helden: 40

Schritt 1: Ziehe Ready-Limit ab, damit ganz normal die Reihenfolge berechnet werden kann.
Neuer Ready-Wert: 320 - 300 = 20

Schritt 2: Aktion wählen. Die Aktion hat eine Dauer von 4000, d.h. der Bruch (Aktionsdauer / Tempowert) hat einen Wert von 4000/40 = 100. Ziehe diesen Wert vom Ready-Wert ab.
Neuer Ready-Wert: 20 - 100 = -80

-----
Der Held levelt auf und hat jetzt Tempo 50 (statt 40). In Schritt 2 ändert sich damit die Rechnung:
Schritt 2: Aktion wählen. Die Aktion hat eine Dauer von 4000, d.h. der Bruch (Aktionsdauer / Tempowert) hat einen Wert von 4000/50 = 80. Ziehe diesen Wert vom Ready-Wert ab.
Neuer Ready-Wert: 20 - 80 = -60

...

Die Idee dahinter ist quasi, dass der Malus sich mit der Zeit verringert, d.h. der Held kann die Aktion über die Zeit schneller ausführen. Da müsste aber wohl noch etwas bei der Berechnung nachjustiert werden, weil der Effekt marginal ist...


Tipps:
Du kannst dir das ggf. mit einem Diagramm bzw. Automaten veranschaulichen:
https://de.wikipedia.org/wiki/Zustandsdiagramm_(UML)
https://de.wikipedia.org/wiki/Determ...licher_Automat
Der ganze mathematische Hintergrund kann ignoriert werden... Scroll einfach zu den Bildern und lies die Überschiften dazu . Diese Dinger sind zwar nicht genau das, was du möchtest, gehen aber in die richtige Richtung.

Genau geht es mit einem Aktivitäsdiagramm, weil du damit den Code quasi "grafisch" vor dir hast:
https://de.wikipedia.org/wiki/Aktivit%C3%A4tsdiagramm
Ich fand es aber am Anfang relativ schwer, mir sowas aufzumalen. Ggf. reichen ein paar einfache Kreise mit ein paar Pfeilen wie oben ja auch schon aus, um den Überblick nicht zu verlieren.