Seite 5 von 15 ErsteErste 123456789 ... LetzteLetzte
Ergebnis 81 bis 100 von 296

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

  1. #81
    Was ich komischerweise noch nie (oder fast nie) gesehen habe ist das man Sounds mischt! Also man Spielt zwei Sounds gleichzeitig ab und das ergibt meisst einen gewissen ... Sound xD
    Naja nun zu dem was ich eigentlich sagen wollte:

    Wusstet ihr das man maximal 2 Tasten aufeinmal drücken kann um diese dann abzufragen?

    Wusstet ihr das der Maker in Parrallelen Prozessen ohne wait 0.0 sec (o.ä.)
    alles auf einmal berrechnet und deswegen das Spiel lahmlegt?

    Wusstet ihr das man mit "Clear Timer" nicht nur Timer Cleart sondern auch Events löscht (solange man auf der Map ist)!

    Okay das meiste wusstet ihr wahrscheinlich x.x
    Mfg
    Mayaki

  2. #82
    Zitat Zitat von Mayaki
    Wusstet ihr das der Maker in Parrallelen Prozessen ohne wait 0.0 sec (o.ä.)
    alles auf einmal berrechnet und deswegen das Spiel lahmlegt?
    Das ist net zwingend, ich hab früher als ich noch n00b war nie ein Wait reingemacht und es hat meistens nicht geruckelt und wenn dann nur minimal.
    Zitat Zitat
    Wusstet ihr das man mit "Clear Timer" nicht nur Timer Cleart sondern auch Events löscht (solange man auf der Map ist)!
    Das liegt daran dass Clear Timer ein Übersetzungsfehler ist. In der Hilfedatei wird es als "Temp Delete Event" aufgeführt und in Gnafs Patch heißts auch Delete Event.

    Zu Clear Timer weiß ich aber auch noch was: Wenn man Move Events auf einen Event ausführt und ihn während der Ausführung per Clear Timer temporär löscht, wird jedes Wait Until Moved danach (solange man die Map nicht verlässt) für eine unendliche Wartezeit sorgen.
    Ob das jemals nützlich sein wird bezweifel ich allerdings XD

  3. #83
    Sorry, falls es die Frage schon gab, aber es ist wichtig und passt hier hin:

    Wie lange dauern Battle anminatins? Die längste dauert 9.9, aber was ist das in sec ???

    Bitte um Antwort!
    Don

  4. #84
    Zitat Zitat von Don_Alexandro
    Wie lange dauern Battle anminatins? Die längste dauert 9.9, aber was ist das in sec ???
    Steht doch gleich auf der ersten Seite:
    Zitat Zitat
    Was ich eigentlich schon seit längerer Zeit weiß, was ich aber hier noch mal passend erwähnen will ist das Verhältnis von Battle-Animation-Frames zur Wait-Zeit

    Es ist (so ziemlich GENAU):
    3 Frames pro 0,1 Sekunde "Wait"-Zeit
    (eine Battle-Animation kann so maximal 3,3 Sekunden lang sein...)

  5. #85
    Tschuldigung, ich bin gerade absolut verwirrt.
    Ich wollte ein Event erstellen, das genau so schnell läuft wie mein Held... also habe ich nach dem Move Event 1x 0.1 und 2x 0.0 sec Wait eingesetzt.

    Dabei musste ich feststellen, dass das Event viel langsamer als der Held war. Ich hab jetzt mal die Wait-Zeit halbiert, also 4x 0.0 Wait... dann hat es gestimmt.

    Stimmt die Tabelle auf der ersten Seite nicht mehr? Mit der hab ich viele Jahre lang gut gearbeitet, und auf einmal...

  6. #86
    Das liegt daran, dass am Ende eines PP ein automatischer 0,0 Sekunden Wait gesetzt wird.
    Entweder lässt du also einen 0,0s Wait weg, oder du setzt alles in einen Cycle.

  7. #87
    Na das kann es ja nicht sein, immerhin ist es wirklich genau die Hälfte, so als sei der Held mit einem Mal doppelt so schnell geworden...
    aber gut zu wissen, ein automatisches 0,0 sec Wait am Ende jedes PP? Und ich dachte immer ohne Wait am Ende würde das Ganze fehlerhaft werden.

  8. #88
    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...

    Geändert von Mayaki (03.05.2005 um 13:13 Uhr)

  9. #89
    Zitat Zitat von 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
    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.

  10. #90
    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. :>

  11. #91
    so, hab mich mal durchgerungen auch mal hier was zu posten

    Zitat Zitat
    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
    Zitat Zitat
    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
    Zitat Zitat
    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,

  12. #92
    Zitat Zitat
    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?

    Zitat Zitat
    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.

    Zitat Zitat
    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.

    Zitat Zitat
    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.

    Zitat Zitat
    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.

  13. #93
    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

  14. #94

    "Vibration of Nature" - It's a long story
    stars_mod
    Zitat Zitat von Gekiganger
    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:
    Zitat Zitat
    ... 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

  15. #95
    @ 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.

    Geändert von Gekiganger (05.06.2005 um 02:12 Uhr)

  16. #96
    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

  17. #97
    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)

  18. #98
    Zitat Zitat von Lachsen
    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

  19. #99

    "Vibration of Nature" - It's a long story
    stars_mod
    Zitat Zitat von Dhan
    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

  20. #100
    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 ^^

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •