@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.
Geändert von IndependentArt (10.04.2019 um 22:36 Uhr)
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.
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.
--
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.Zitat
Wo genau siehst du da den Fehler ...?
Das dürfte ungefähr auf das gleiche hinauslaufen, was Cornix mit "Ready-Wert = Ready-Wert - (Ready-Limit * Aktions-Dauer) / 100" vorgeschlagen hat, oder?
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 geht alles irgendwo in die gleiche Richtung
Ready-Wert = Ready-Wert - Ready-Limit - (Aktionsdauer / Tempowert)
--
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.
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^^.
--
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.
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?
--
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:
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:
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:
Geändert von IndependentArt (17.04.2019 um 17:31 Uhr)
Für den Code ist es mir jetzt zu spät...Die Formel "Ready-Wert = Ready-Wert - Ready-Limit - (Aktionsdauer / Tempowert)" verstehe ich aber offen gesagt auch nicht so recht.
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
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):
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.
--
Ich denke, das ist im großen und ganzen das, was ich versucht habe einzubauen. Wir müssen nur ein bisschen aufpassen, dass wir mit den Namen für die Werte nicht durcheinander kommen.
Deine Bezeichnungen dürften bei mir so heißen:
Ready-Limit = CTB Ready
Ready-Wert = R-CTB Order (Preview)
Ich bin nicht sicher, ob du das bedacht hast: Wenn erst im Schritt 2 die Aktionsdauer abgezogen wird, wurde ja vorher mit Erreichen des Ready-Limits schon ein Zug berechnet. Vielleicht hängt das aber auch von der Reihenfolge des ganzen Ablaufs ab.
Außerdem: Bei mir wird die Aktionsdauer prozentual auf das Ready-Limit bezogen. Bei Ready-Limit 300 und Aktionsdauer von 100 (%) wäre das also -300. Eine feste Aktionsdauer von 100 wäre ja bei sich veränderndem Ready-Limit etwas schwierig, aber das hast du vmtl. Auch nicht so vorgesehen.
Außerdem muss man da auch wieder unterscheiden zwischen Preview und eigentlicher Berechnung (wie ich es oben getan habe):
Preview:
Hier kann natürlich bequem einfach die komplette Aktionsdauer abgezogen werden. Ich setze wie oben beschrieben anach die Aktionsdauer 0, damit das nur 1 Mal geschieht. Damit also die nächsten Züge wieder mit normaler Dauer berechnet werden.
Eigentliche Berechnung:
Angenommen nach dem Zug des Charakters hat der Gegner 3 Züge, weil die Aktion so lang dauert. Für den ersten Zug ist die Rechnung im Prinzip genau so wie beim Preview: die volle Aktionsdauer wird abgezogen. Nach dem ersten Zug des Gegners wird alles wieder neu berechnet. Die Aktionsdauer muss also sozusagen um 1 Zug verringert werden, so wie oben beschrieben.
Ich hoffe, wir verstehen uns irgendwie. ^^
Danke auch für die Links, mal sehen, ob ich damit was anfanen kann.
Berechtigungen
Zitieren
