Detail-Wissen und Geheimnise des RPG-Makers -vorallem für Erfahrene/Profis lehrreich

[Mayaki]

Ich weis nicht ob ichs hier reinschreiben soll aber ich kann den Post notfalls ja noch löschn...

Ich habe in einem Event (zum aufrufen des Menüs) eine Forkcondition gemacht in der ein Switch abgefragt wird , (KS On)jedoch kann ich so im KS immernoch das MEnü aufrufen und muss erst den Switch abstellen der direkt mit dem Commonevent verbunden ist ausstellen (also bei Commonevten das Häckchen).
Woran liegt das?
Übersieht/springt der maker dieses einfach? Und wie kann ich das ändern?
Mfg
Mayaki

p.S. @Ultimaman:
Ne das passiert grundlegend immer, auch wenn ichs bei einem anderen Projekt versuche und der Code selbst ist zu Simpel als das dort ein bug stecken könnte...

[Kyuu]

Ich weis nicht ob ichs hier reinschreiben soll aber ich kann den Post notfalls ja noch löschn...

Ich habe in einem Event (zum aufrufen des Menüs) eine Forkcondition gemacht in der ein Switch abgefragt wird , (KS On)jedoch kann ich so im KS immernoch das MEnü aufrufen und muss erst den Switch abstellen der direkt mit dem Commonevent verbunden ist ausstellen (also bei Commonevten das Häckchen).
Woran liegt das?
Übersieht/springt der maker dieses einfach? Und wie kann ich das ändern?
Mfg
Mayaki

...

Es wird nichts übersprungen/übersehen, zumindest nicht unbeabsichtigt. o.o
Das heißt, du hast in deinem Event/Skript einen Wurm drin. Am besten du überprüfst vor dem Aufrufen des Menüs im und außerhalb des Kampfsystems per F9 ob der besagte Switch aktiviert ist, oder nicht. Eine Fehleranalyse halt. Dann kannst du auch gezielt nach dem fehlerhaften Event/Code suchen, sofern du deine Skriptereien noch überblickst.

[Gekiganger]

Ich finde in dem Thread sollten auch weiterhin Eigenheiten und Macken des Makers sowie Trix zur Umgehung selbiger gepostet werden, anstatt Fragen zur Richtigkeit seines eigenen Codes zu stellen. :>

[DR_Zeph]

so, hab mich mal durchgerungen auch mal hier was zu posten

ehm, ein durch Label oder Cycel erzeugtes PP-Event, welches in einer Schlaufe läuft, verhält sich genauso wie ein Autostart Event, mit allen seinen Eigenschaften, z.B.:

man kann sich nicht bewegen


das Event läuft im Gegenzug zu PP schneller, da keine 0,0 sek Waits am Ende des Codes vom Maker automatisch gesetzt werden

...

ehm, habt ihr gewußt,

das man ein Call Event nicht mit einem Clear Timer vorzeitig beenden kann,
das man ein Call Event mit dem Befehl call event vorzeitig beenden kann, wenn man ein anderes event aufruft,
das man das Game zum absturz bringt, wenn man in einem Call Event den Befehl Call Event packt, und das Call Event aufruft,
wenn man aber ein 0,0 sek wait mit in das ganze reinpackt, undzwar vor dem Call Event, das das Event called, der maker das Call Event als Autostart verarbeitet, mit eben den AutoStart Funktionen

...

hiho, ich bin es mal wiedern, und es gibt was neues, habt ihr gewußt, das ihr ein event ohne jeglichen wait befehl in seiner durchlaufzeit negativ beeinflussen könnt,


macht dafür einfach einige viele forks in ein autostart event herein, siehe hier:

http://jpg.250kb.de/cce5f46befc92f9c...e65b007b98.jpg

dieser code begrenzt das event auf 4500 durchläufe in 0,1 sek,
je nach anzahl der forks läuft das event schneller, bzw. langsamer,
dabei kann es aber zu einer großen rechenbelastung kommen, daher ist es zu empfehlen diesem event noch eins parallel zu schalten, was so aussieht,
http://jpg.250kb.de/ffc9a8f78850c476...df4e0ca33c.jpg

würde man dies auch in nem autostart event machen, würde es um eine kleinigkeit schneller laufen, was man aber weniger relevant ist,

hoffe, ihr könnt das irgendwie gebrauchen, z.b. bei einer ATB Leiste ist das ganze sehr gut einzusetzen,

...

[Gekiganger]

ehm, ein durch Label oder Cycel erzeugtes PP-Event, welches in einer Schlaufe läuft, verhält sich genauso wie ein Autostart Event, mit allen seinen Eigenschaften, z.B.:

...

Hm was soll ich dazu sagen, das ist schlicht und ergreifend nicht wahr.
Ein Show Picture in einem Cycle/ einer Labelschleife lässt das Spiel gefrieren aber das wars auch schon mit der "Ähnlichkeit zum Autostart".
Unter welchen Bedingungen hast du das denn getestet?

das man ein Call Event nicht mit einem Clear Timer vorzeitig beenden kann,

...

Was aber durchaus logisch ist, denn im Gegensatz zu einem normal gestarteten Event besitzt ein Call Event keine "physiche Gestalt", da es sich lediglich um eine Kopie des Codes des Events (auf der gecallten Eventseite) handelt, ohne die eventspezifischen (physischen) Eigenschaften wie Grafik, Start Condition etc.

das man ein Call Event mit dem Befehl call event vorzeitig beenden kann, wenn man ein anderes event aufruft,

...

Da musst du vorsichtig sein.
Call Event bedeutet nicht, "rufe ein neues Event parallel auf und setze gleichzeitig den Code fort", sondern "rufe ein neues Event auf und warte. bis dieses Event zum Ende gekommen ist".
Es entsteht also der Eindruck, das jetzige Event wäre zuende, dabei wird nur gewartet bis das neue zuende ist. Befinden sich in dem neuen Event ebenfalls Calls, kann es durchaus seine Zeit dauern, bis das erste Event zuende geführt wird, da jedes einzelne Event auf seine "Kindevents" wartet.

das man das Game zum absturz bringt, wenn man in einem Call Event den Befehl Call Event packt, und das Call Event aufruft,

...

Ganz so tragisch ist es glücklicherweise nicht. Der Maker erlaubt Aufrufketten (bzw. Rekursionen) bis zu einer Anzahl von 1000. Erst beim 1001sten neuen Aufruf in dieser Kette kommt es zum Absturz.
Früher wurde ein Event, welches sich selbst mit Call Event aufruft, als Parallel Process Ersatz missbraucht. Doch das ist es nicht. Bei Call Event wird eine Kopie des aufgerufenen Events im Speicher erzeugt. Das aufrufende Event wartet solange, bis das neue zuende ist. Doch dieses erzeugt selbst immer neue Events.
Bei 1000 Aufrufen stehen also 1000 Events im Speicher, jedes wartet bis sein Kindevent zu ende ist. Von daher hat diese Begrenzung durchaus seinen Sinn.

wenn man aber ein 0,0 sek wait mit in das ganze reinpackt, undzwar vor dem Call Event, das das Event called, der maker das Call Event als Autostart verarbeitet, mit eben den AutoStart Funktionen

...

Wie gesagt, da Call Events nicht "physikalisch" existieren, sondern nur den virtuellen Code einer Eventseite repräsentieren, besitzen sie auch keine Start Condition. Vermutlich hast du das Event aus einem Push Key, Autostart oder ähnlichen Event heraus gestartet. Da dieses natürlich wartet, bis das gecallte Event zuende ist, gelten auch die ganze Zeit über dessen Conditions, sprich, man kann sich nicht bewegen.
Ohne den 0,0s Wait hast du es wahrscheinlich nur nicht bemerkt, da das Event zu schnell wieder zuende war.


Zu dem letzten Quote kann ich jetzt nichts vernünftiges sagen, ich verstehe nicht genau worauf du damit hinaus willst.
Klar braucht ein Event für einen Durchlauf länger, sobald es mehr Anweisungen verarbeiten muss.
Trotzdem verstehe ich nicht, inwiefern das zweite Event das erste beeinflussen soll, schaltet es doch nur den Switch nach 0,1s wieder aus, nachdem das erste Event bereits 4500 Durchläufe in derselben Zeit hatte.
Zudem verstehe ich nicht, ob das zweite Event nun in einem PP oder AS laufen soll. Ein AS kann es ja nicht sein, denn es können keine 2 gleichzeitig laufen, es wird immer der zuerst behandelte AS ausgeführt (Event mit der niedrigeren ID) und der zweite ignoriert.

[Lachsen]

Was aber durchaus logisch ist, denn im Gegensatz zu einem normal gestarteten Event besitzt ein Call Event keine "physiche Gestalt", da es sich lediglich um eine Kopie des Codes des Events (auf der gecallten Eventseite) handelt, ohne die eventspezifischen (physischen) Eigenschaften wie Grafik, Start Condition etc.

...

Ich denke nicht, dass man das so einfach stehen lassen kann.
Siehe Thread:

... dass sich ein Move-Event, das auf "this Event" steht und in einem Call-Event zu finden ist, sich auf das Event bezieht, das gecallt wird? (also macht NIE Move-Event "this Event" in einem Common-.Event ^^)

...

Das heisst: Alle Befehle, die sich auf "this Event" Beziehen, gehen (LEIDER >_< und gleichzeitig ZUM GLÜCK XD... wüsste nicht genau was besser wäre) nicht auf das Event, dass das Skript gecallt hat, sondern auf das Event, das gecallt wurde.
Da wären: Move Events, Coordinaten nehmen, Set Event Place... und ALL das zeug.
Das gleiche gilt (eigentlich o_ô) auch für Clear Timer.
Wenn man ein Event callt und in dem Skript dieses Events Clear Timer anwendet, verschwindet das gecallte Event. (ich denke das ganze Skript von diesem Event wir dann auch übersprungen und das Programm geht direkt zum Event zurück, dass gecallt hat)

Von daher kann man leider nicht so direkt davon sprechen, dass das Skript einfach in das Event, dass den Call-Event Befehl verwendet, rein kopiert wird...

Ich glaube was hier das Problem ist, ist der schwamminge Begriff "Call-Event". Ist vielleicht hier an einer oder anderer Stelle ehr "Common Event" gemeint? Denn da hat "Clear Timer" wirklich keine auswirkung (wie ich schon in einem vorherigen Post geschrieben habe)

"Call Event" ist für mich einfach Event, das gecallt wurde. Das kann auch eine Event-Seite sein von einem Map-Event.

Soviel von meiner Seite

C ya

Lachsen

[Dhan]

Das heisst: Alle Befehle, die sich auf "this Event" Beziehen, gehen (LEIDER >_< und gleichzeitig ZUM GLÜCK XD... wüsste nicht genau was besser wäre)

...

Irgendwas übersehe ich, warum "zum Glück"? Was spricht den dafür?

@Traveler: Net übel net übel, hat sicher viel Zeit gekostet

[Lachsen]

Irgendwas übersehe ich, warum "zum Glück"? Was spricht den dafür?

...

Och, da gibt es EINIGES.
Ehrlich gesagt finde ich es, wenn ich es mir recht überlege, doch um einiges besser, dass es so ist.

In folgenden Fällen ist es nützlich:
1. In einem AKS kann man, um die Coordinaten eines Events zu bekommen einfach eine Event-Seite von diesem Event callen, indem zwei Change Variable Befehle sind die den Variablen Coordinate-X und Coordiante-Y die jeweiligen Coordinaten von "this Event" übergeben.
Wann immer man nun die Coordinaten von diesem Event brauch: man muss es nur diese Seite callen. Das macht das Coordinaten-Nehmen in einiger Hinsicht flexibler.

Denn: Während Change-Variable Befehle, die die Coordinaten von einem Event nehmen, immer ein bestimmtes festes Event gewählt haben müssen, kann man bei Call-Event eine Variable angeben, die bestimmt, welches Event gecallt wird. ^^

2. Auf die Gleiche Methode kann man Event leichter von einem anderen "steuern". Angenommen die BEwegungs-KI von allen Gegnern würd über ein Common-Event geregelt (das hat ja viele Vorteile), spätestens wenn es darum geht, die Events der Gegner zu BEwegen, wird es kompliziert, denn die Gegner-Events können von Map zu Map andere Event-IDs haben.
Hier kann man auch diese Methode anwenden:
Man gibt jedem Gegner-Event eine Event-Seite, die nur zum callen bestimmt ist und die alle Move-Events enthält, die nötig sind, um dieses Event zu Bewegen (natürlich gehen hier alle auf "this Event").
Wenn man nun über das Common-Event ausgerechnet hat, welchen Weg das Event geht, kann man nun das Event callen um es zu bewegen und wie gesagt:
Im Gegensatz zu MoveEvents muss man bei CallEvent keine tausend Forks aufreihen (für alle möglichen Event-IDs), weil man eine Variable angeben kann, die die Event-ID des Gegeners enthält, wodurch dann automatisch das richtige Event gecallt wird. ^^

3. Noch ne Sache, die ich in Velsarbor verwende: Man kann in dem Spiel Büsche zerhacken, die sogar nach einem Map-wechsel (wenn ein Kampf kommt oder man das Menu aufruft) immernoch weg sind.
Und das ganze funktioniert ganz ohne Switches. Das Skript ist so erstellt, das ich nur ein festes Busch-Event kopieren muss, ohne es anzupassen.

Das ganze funktioniert so:
Wenn ein Busch zerstört wird, wird die Event-ID dieses Busches in einer Variablen-Liste eingetragen (ich glaube bis zu 50 Event-IDs können dort eingespeichert werden, also bis zu 50 Büsche können pro Map zerstört werden).
Wenn man nun in einem Kampf kommt oder das Menu aufruft und daraufhin wieder zurück zur Map gelangt, startet automatisch ein Skript, dass die Liste der Event-IDs der Büsche durchgeht. Für jede ID die in dieser Liste gefunden wird, wird folgendes gemacht:
Das Event, dass diese ID hat, wird gecallt, undzwar die erste Seite.
Es handelt sich dabei natürlich um ein Busch Event.
Während die 2. Seite eines Busch-Events das Skript enthält, bei dem der Held es kaputt haut, enthält die erste Seite nur einen einzigen Befehl:
"Clear Timer"
Sprich: Das Event wird gelöscht, wenn diese Seite gecallt wird.
Und somit ist das Event auch weiterhin verschwunden, obwohl die Map durch Kampf/Menu gewechselt wurde. ^^

(Achja: Wenn man die Map verlässt, also zum nächsten Map-Abschnitt wechselt, werden natürlich alle IDs aus der Busch-Zerstört-ID-Liste gelöscht.)

... naja es gibt noch viele andere Sachen, wo ich es verwende.
Beispielweise werden auch alle "Schaden-Einstecken"-Animationen im Vsb-KS per Move-Event geregelt undzwar auch hier, indem man ein Event callt das sich im Gegner-Event selber befindet.

Naja, also mir ist das doch schon ganz lieb so o_ô

Ne, was aber WIRKLICH ultimativ wäre:
Alle Move-Events in COMMON-EVENTs die als Ziel "this Event" haben, gehen auf das letzte Map-Event, das in der Call-Event kette eingebunden ist @_@
Das wäre genial @_@

Aber nya... Wäre alles nicht nötig, könnte man überall Variablen angeben, wo nach Event-IDs oder sonst was gefragt wird, was eine ID oder Zahl hat (Picture Nummer ;___________________

@Darktraveler
Trefferwahrscheinlichkeits-Rechnung mit ner Wurzelfunktion? XD Oh weia...
Wieso kann der Maker die Wurzelfunktion anwenden, stellt sie aber nicht in dem Change-Variablen-Operatoren bereit!? XO
Ansonsten nette Untersuchungen zum Standard KS ^^
Es ist leider nur wirklich sehr schwer im Bereich von Zufalls-Berechnungen mit empirischen Messungen was exaktes herauszufinden o_ô

Soviel von meiner Seite

C ya

Lachsen

[DR_Zeph]

nya^^, ups, das erste hatte ich mal in meiner pixel lauf engine bemerkt, die wohl irgendwie meine rechnerleistung ausschöpfte, und ich mich deshalb net mehr bewegen konnte, *verneig*
k, die anderen punkte auch net richtig durchdacht, ehm, zum letzen punkt,
benutze das ganze wie gesagt, in einem atb für ein KS, das ganze läuft durch das zweite event bei mir, was ich erst nur für testzwecke, wieviele durchläufe das event hat, gemacht habe, um einiges flüssiger, was wahrscheinlich durch die schaltung der events kommt, das erste, das mit den vielen forks, läuft in einem PP event, welches in einem cycle geschaltet ist, das zweite in einem einfachen pp event, was bekanntlich bei einem durchlauf am ende einen wait von 0,0 setzt

[Gekiganger]

@ Lachsen
Ja du hast recht. Das habe ich dabei garnicht beachtet, war dumm von mir.
Natürlich löscht sich auch ein aufgerufenes Event durch Clear Timer selbst, allerdings läuft der Code bis zum Ende hin weiter, verhält sich also wie die Switches die auf ne andere Eventseite Schalten.
Da ich es allerdings ohne Eventgrafik getestet hatte dachte ich, das Event wäre noch existent und kam deshalb zu dem falschen Schluss, da der Eventcode auch nach dem Clear Timer ja trotzdem noch erreichbar ist, es wird praktisch nur die physische Form zerstört.
Insofern stimmt es dann wieder was DR_Zeph gesagt hat, man kann das Event nicht vorzeitig beenden, das bezieht sich dann aber auf sämtliche und nicht nur auf gecallte, mit außname der (mal wieder) Paralel Process Events.

Nunja, jedenfalls sollte man, wie ich bemerkt habe, auf ein durch Clear Timer gelöschtes Event kein Move Event mit Move All machen, sonst könnte man sein blaues Wunder erleben.^^'


Ach BTW, ich meinte nicht, dass der Code aufgerufener Events in das aufrufende Event kopiert wird und sich Befehle mit this Zeigern so auf das aufrufende Event beziehen, ich meite damit dass der Code als eigenständige Einheit in den Speicher geladen wird, ohne die "physischen" Eigenschaften (wie ich sie nannte und was ja letztendlich nicht ganz korrekt war) des aufgerufenen Events.

[Mike]

Wow, ich hab diesen Tread jetzt zum ersten mal gesehen, und bin echt überrascht, dass es noch so manche funktionen gibt, die ich nicht gekannt habe. (Auch wenn ich von vielem schon gewusst habe). Also die Idee für einen solchen Tread ist echt nicht schlecht, und ich werde das ganze weiterverfolgen.

LG Henry

[Darktraveler]

Falls es für irgendjemanden interessant sein sollte ^^ meine ich zwei Formeln des SKS durch mehrfaches Ausprobieren etwa eingegrenzt zu haben...

1) Trefferwahrscheinlichkeit
Ich habe einige Versuche gemacht... unter anderem den Versuch Angreifer: 100 AGI und Verteidiger: 999 AGI...
Wenn die Trefferwahrscheinlichkeit einfach nur nach dem Verhältnisprinzip gehen würde.... müsste ja der Verteidiger immer treffen... (stimmt... zumindest in 99% der Fälle) und der Angreifer nur 1 von 10 mal....... Zu meiner Überraschung war es jedoch weitaus häufiger und ich glaube so viel.... Pech (oder ehe rGlück) habe ich nicht, dass ich soooooo falsch liege......

Da allgemein die Abweichungen nicht allzugroß sind (einer der halb so schnell is wie der gegner trifft aber nicht nur halb so oft) habe ich nach einer Formel gesucht die dies beinhaltet und trotzdem bei gleicher Geschwindigkeit und gleicher Grund-Trefferwahrscheinlichkeit (das habe ich mal als gegeben vorraus gesetzt) beiden auch die selbe Trefferwahrscheinlichkeit gibt.....

Naja lange Rede kurzer Sinn... meine These ist dass die Trefferwahrscheinlichkeitsformel schlicht und ergreifend:

Grundtrefferwahrscheinlichkeit * (Agilität Angreifer / Agilität Verteidiger)^1/2

Sozusagen die Grundtrefferwahrscheinlichkeit mal der Wurzel (falls jemandem nicht geläufig ist was hoch 1/2 zu sagen hat) von der Angreiferagilität durch die Verteidigeragilität......

Grundtrefferwahrscheinlichkeit ist in diesem Fall entweder die von der Waffe in der Item-Database festgelegte Wahrscheinlichkeit bzw. bei Monstern und unbewaffneten Helden 90% meines Wissens....

Ich hoffe IRGENDJEMAND kann mit dem was ich gerade palawert habe etwas anfangen ^^



achja...

2) Zugreihenfolge

Dieses Problem ist mir beim Spielen von Vampires Dawn aufgefallen o_O..... Größte Agilität ist nicht gleich erster Zug.... ^^ Alain war eindeutig die schnellste (also von der reinen Zahl her)... aber Asgar und Valnar kamen dennoch manchmal vor ihr zum Zug (dabei Valnar öfter da er schneller als Asgar war).....

Also habe ich es gleich ausprobiert.... und verschiedene Zufallsfaktoren an die Agilitäten der drei Charaktere in einem gesonderten SPiel gekoppelt und die Testergebnisse dann mit meinen "Alltagserfahrungen" mit den dreien verglichen...... Relativ endgültige Sicherheit bekam ich dann jedoch erst bei einem Test mit Grenzwerten, die dann entschieden ob sich jemals die Zugreihen folge zwischen den charakteren veränderte oder nur sehr selten bzw überhaupt.....

Dabei ist dann folgende "Formel" herumgekommen:

Vor jedem Zug wird folgende Rechnung mit der Agilität eines jeden Kampfteilnehmers vorgenommen:

Agilität * [Eine zufällige Zahl zwischen 0,9 und 1,1]

DANN wird verglichen und dementsprechend die Zugreihenfolge festgelegt... Bei einem Gleichstand würde ich spontan tippen dass eine 50:50 Chance besteht dass dann der eine... oder halt der andere bevorzugt wird.. Da man aber als Großteil der Makerschaft die Makerinternen Zahlen ohnehin nciht zu Gesicht bekommt, wird man dies als Benutzer eh nicht merken o_O


Das wars soweit von mir... probiert es ruhig aus..... berichtigt mich ^^ es hilft ja allen (wer auch immer das gebrauchen kann)

[Darktraveler]

Naja zumindestens würde es am allerehesten an die aus den Testreihen resultierenden Trefferwahrscheinlichkeiten herankommen.... aber wie gesagt ^^ aus meiner Sicht... vielleicht bin ich ja nen Pechvogel oder Glückspilz oO und bild mir diese Formeln nur ein =) wobei es natürlich sein kann das noch iiiirgendein anderer Faktor mithineinfallen könnte... Dann wäre aber fraglich welcher das noch sein soll.... Ausser Agilität und Grundtrefferwahrscheinlichkeit......

Außerdem schätze ich mal ganz stark dass egal wie hoch die Wahrscheinlichkeit für den schnelleren ist... diese wohl auf 99% oder vielleicht sogar 95% runtergeschraubt wird... denn selbst ein übermächtig schneller Gegner schlägt immer noch EIN oder ZWEI mal in zig dutzend versuchen vorbei....

Daraus lässt sich natürlich der Umkehrschluss ziehen dass auch die untere Grenze auf 1% oder 5% festgelegt ist.... aber wie gesagt ^^ Who knows? Wirklich herausfinden werden wir es ohne Hilfe von Enterbrain wohl nie ^^

[Dhan]

Na, mit meiner Frage meinte ich, welche Gründe sprechen dafür, dass sich die Call Events NICHT komplett an das Event anbinden, das sie aufruft

[Lachsen]

@Dhan Genau diese Gründe hab ich doch genannt. Call-Events binden sich nicht an das Event, das sie aufgerufen hat und das sind die Vorteile die daraus folgen...
(das war auch das, was ich mit "Zum Glück" angesprochen habe)

Und Andersrum? Du meinst, wenn Call-Events sich doch an das Event richten, da sie gecallt hat? (was wiederum das war, was ich mit "ist leider nicht so" angesprochen habe)

Man könnte in einem Common-Event alle möglichen Move-Event Befehle einspeichern (die auf "this Event" gehen) die dann von einem existierenden Event gecallt werden, um sich zu bewegen.

Wäre auch wieder für nen AKS sehr praktisch, da man die Bewegungen immernur in dem Common-Event aktualisieren müsste, nicht in jedem einzelnen Gegner Event...
Aber wenn ich es mir recht überlege ist es so wie es ist wohl doch deutlich besser.

C ya

Lachsen

[Krool]

Aber wenn ich es mir recht überlege ist es so wie es ist wohl doch deutlich besser.

...

Warum nicht einfach beides? In dem Call Event ein kästchen mit dem Text Binden an gecalltes Event. dann kann man je nach laune wie mans halt entsprechend braucht umändern.

aber sowas ist wohl ohne eingriffe in die engine nicht möglich.

[Vannir]

lol geil das mit dem wait^^

[GFlügel]

Noch einmal eine Kleinigkeit zu Standard-KS, die ich schon in einem anderen Thread gepostet habe:

Agility beeinflusst normalerweise auch die Treffsicherheit der Techniken (also senkt oder erhöht die Grundtreffsicherheit, es seidenn sie ist 100% oder 0%).
Wenn allerdings HitChance und/oder MindChance auf 10 steht (Maximum) entfällt dieser Einfluss aus irgendeinem Grund. oO
Ich bin allerdings nicht sicher ob es allgemein einen Zusammenhang zwischen "Höhe von Hit-/MindChance" und "Einfluss von Agility auf Treffsicherheit" gibt, meine Tests sagen dazu eher nein (wobei das auch nur sehr schwer klar zu besitmmen ist imo).
Getestet mit:
- 1 Stufe 1 Helden mit 15Agi
- 2 Gegnern mit 1Agi und 999Agi und 1 in allen anderen werten ausser 9999HP
- 4 Techniken mit 90% "Basic success rate" und 1.HitChance u. MindChance auf 0 2.Mind u. Hit Chance auf 5, 3.HitChance auf 10 u. MindChance auf 0 und 4.HitChance auf 0 u. MindChance auf 10.


Damit wäre wohl auch das Vorurteil aufgehoben, dass Agi allgemein keine Auswirkungen auf die Treffsicherheit von Techniken hat, denn es beeinflusst sehr wohl die "Basic Success rate" die man eingeben kann je nach Differenz zwischen Angreifer und Opfer. Ledigleich bei einer HitChance oder MindChance von 10 hat sie keine Auswirkungen mehr.

[Goldenmaumau]

Frage:
Was ist schneller: Labels oder Cycles?

Gruß, Maumau

[Heaven]

Von der Logik her würde ich sagen, es sind Cycles, weil diese darauf ausgelegt sind, sich an einer gespeicherten Stelle zu wiederholen, wobei bei einem Label davon ausgegangen werden kann, das es mehrere gibt. Demnach muss das gewünschte Label erst nochmal im Code gesucht werden, damit von der Position aus wieder begonnen werden kann.

Ist von der Logik her so, denke noch über einen Versuch nach, bei dem man beide wirklich parallel abfragen kann.
Das wirft mir gleich ne neue Frage auf:
Wenn zwei CE als PP durch ein und denselben Switch aktiviert werden, welches CE wird zuerst ausgeführt, bzw beginnt zuerst. Ich tippe auf das vom Zahlenwert niedrigere....