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
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
@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
lol geil das mit dem wait^^
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.
--
Frage:
Was ist schneller: Labels oder Cycles?
Gruß, Maumau
--Goldenmaumau @ RPG Atelier
-----------also know as--------------
Goldenboy @ Quartier
Greetz to: Blitzyy, Son Geku, Dante, Alzi, Zidane FFIX, KD, Batista
und Brainstormer
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....
Sollte sich doch mittels einer einfachen Variablenzählung möglich sein.
Bei mir kommt nach einem Wait von 0,0 Sekunden folgende Ergebnisse raus:
Cycel 3333 Durchläufe
Label 5000 Durchläufe
Imo sollte damit das Label um ein vielfaches schneller Laufen als wie ein Cycel. Dies könnte vll. daher rühren, das am Ende eines Cycel geprüft werden muss, ob ein Break aufgerufen wurde, erst anschließend wird zum Cycelursprung zurückgesprungen.
Was meinst du mit Wait 0.0?
Wie sah den dein Versuch aus.
Ein Wait mit 0,0 Sek = 0,01666 Sekunden. Wird vorne im Thread näher erklärt.
Ich habe zwei Events genommen. Das erste hab ich auf PP gestellt. Dortrein kam im Versuch eins, der Cycel aus Labeln, in Versuch 2, der einfache Cycel. In dem jeweiligen "Cycel" hab ich nun noch eine Variablen hochzählen lassen.
Event 2 steht auf Automatisch starten, bekanntlich startet ein solches Event 0,01666 Sekunden später als wie ein Event auf PP. Im Event selber hab ich nun noch meine Zählvariable mittels einer Textbox ausgeben lassen. Rauskamen diese Werte. Kannst es gerne Nachtesten.
kann ich nicht weil ich nicht weiß wann und wie es ausgelöst/beendet wird.
Hier nochmal abgeändert und bebildert. Eventreihenfolge beachten!
Ah ok.
Dann isses amtlich xD
Gilt das auch dann, wenn mehrere verschiedene Labels auf ein und derselben
Eventseite vorhanden sind?
@ Zeph: Danke füs Austesten^^
Gruß, Maumau
--Goldenmaumau @ RPG Atelier
-----------also know as--------------
Goldenboy @ Quartier
Greetz to: Blitzyy, Son Geku, Dante, Alzi, Zidane FFIX, KD, Batista
und Brainstormer
Da ich nicht genau weiß, was du meinst sag ich einfach mal, probier es aus, das Prinzip sollte ja eigentlich leicht verständlich sein.
Kopiers mal aus dem Quartier heraus, um auch hier einige Meinungen einzufangen ^^"
Neulich hatte ich mich mit dem Gedanken gespielt, ein AKS mithilfe von den Scene X sowie Scene Y-Befehlen zu gestalten, anstatt den eher plumpen X- und Y-Koordinaten. Also hab ich den Maker angeschmissen und etwas herumprobiert.
So fand ich also heraus, dass sich die Scene X beispielsweise beim Stehen auf einem bestimmten Feld zB 48 beträgt, geht man jedoch ein Feld nach rechts, hat die Variable nun den Wert 64. (Ok, nichts besonderes ^^). Nun habe ich jedoch, während des Überschreiten des Helden von einem Feld zum anderen, f9 gedrückt und bemerkt, dass sich die SceneX Variable laufend ändert. Und da dachte ich mir, dass man so ein AKS eventuell etwas flüssiger gestalten könnte.
Mir ist bewusst, dass das oben genannte für die meistennichts neues mehr ist, aber ich kann mich (bis eventuell auf Lachsen's AKS, welches ich aber derzeit nicht mehr habe) an kein wirkliches AKS, dass über Scene X und Y läuft, erinnern. Falls es doch noch weitere Versionen eines solchen AKS' geben sollte, bitte posten ^^
Also, meine Frage. Wäre es nun vorteilhaft, ein solches AKS zu proggen? Ich meine, so kompliziert kann die Trefferabfrage nun auch nicht sein. Eventuell wäre das Ganze ja auch eine (sehr ^^) simple Alternative zum Pixelmovement beim AKS.
--Auch als "DiGGeN_DoG" bekannt
Machbar, ich denk man gibt einem Gegner seine Scene x/y +/- seiner Charsetbreite, einen Pixel als Schwertspitze nimmt und permanent abfragt ob der Pixel irgendwann im Gegnerscenebereich ist...jo funzt sicher.
Eine solche pixelgenaue Trefferabfrage habe ich bereits vor einigen (3-4) Jahren in meinem AKS für dem RPG-Maker umgesetzt. (zu finden hier auf der Seite unter "Skripten" mit dem Namen "Action-Kampfsystem Deluxe")Zitat von Neri
Sowas lohnt sich schon, da es um einiges genauer ist als nur eine Abfrage mit Feldcoordinaten. So kann es bei einer Feldcoordinaten-Abfrage zum Beispiel vorkommen, dass eine geschossene Kugel durch den Gegner fliegt ohne ihn zu treffen, da Kugel und Gegner in etwa zum Selben Moment den Platz vertauschten. Sowas kann mit Pixelgenauer Abfrage jedenfalls nicht passieren.
Ein Nachteil so einer Abfrage ist, dass man hier keine Event ID und sonstige Tricks verwenden kann, um Abfrage Rechnungen stark zu vereinfachen.
Was immernoch geht ist eine sehr grobe Treffer Abfrage mit Feldcoordinaten (mittleres Feld und Felder drumherun abfragen) und dann eine Pixelgenaue Abfrage hinter her zur Feinabstimmung. Das ist allerdings recht rechnenaufwändig, denke ich.
Joa, das wars dann an sich auch schon...
C ya
Lachsen
PS: Am simpelsten funktioniert diese Szene-X/Y-Abfrage einfach, indem man die Szene-X und Szene-Y Differenz von Zielbereich-Mitte und potentiellem Opfer nimmt und diese dann quadriert und zusammen addiert. Dann hat man praktisch die Entfernung zum Quadrat, die kleiner als ein bestimmter Wert sein muss, damit es trifft. So kann man gut kreisförmige Trefferbereiche umsetzen...
Geändert von Lachsen (15.08.2006 um 18:28 Uhr)
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.
--
Weil es zum Spielabsturz kommt?
So, wir kennen alle die Sondertasten im Testplay, z.B. Strg oder die Umschalttaste in Messages. Als ich heute in den DebugMode wollte und mich verdrückte, ist mir jedoch eine neue aufgefallen.
Die Taste F10. Sie bricht Events ab, wenn diese laufen, ähnlich dem Befehl "Stop Parallel Events".
Haben wir z.B. folgenden MakerCode,
sollte einmalig, die MessageBox angezeigt werden, anschließend sollte der durch Label gestallte Cycel seinen Dienst tun und fortan in einer Schleife das Event quasi "stoppen". Drückt man jedoch nun besagte F10 Taste, erscheint die MessageBox erneut. Das Event wird quasi abgebrochen. Gleiches gilt für einen normalen Cycel. Die F10 Taste muss nach einem Wait aktiviert werden, da der Befehl ansonsten ignoriert wird. MessageBoxen werden übrigens abgebrochen.
Das ganze funktioniert bis auf PP Events bei allen anderen Aktivierungsmöglichkeiten für Events, auch Call Events, sofern der Call in einem Event steht, das nicht mittels PP gestartet wurde.
Inwiefern das nützlich ist, ist fraglich, da ich größtenteils mit einem PP Event und ner menge Call Events arbeite, zum Abbrechen eines Cycels, welcher z.B. Variablen pointert, jedoch definitiv einsetzbar, sofern der Code nicht in bzw. durch ein PP Event ausgeführt wird.
Naja, die F10- Taste ist ja nun nich' wirklich gänzlich unbekannt. das sie laufende Events unterbindet, steht ja sogar in Kurzform in der Hilfedatei:
Somit ist die F10-Taste dazu gut, im Testplay Automatische Prozesse zu unterbinden, wenn man z.B. aus Versehen ein sich nicht selbst abschaltendes Zwischenszenen- Event erstellt hat.
--
~
Berechtigungen
Zitieren
