naja, aber du kannst damit immerhin WÄHREND EINES SPRUNGS die Grafik ändern! Damit brauchst du die Sprünge nicht mehr über CharSets realisieren!
Das Problem wäre damit gelöst!Zitat von Caine Luveno
naja, aber du kannst damit immerhin WÄHREND EINES SPRUNGS die Grafik ändern! Damit brauchst du die Sprünge nicht mehr über CharSets realisieren!
Das Problem wäre damit gelöst!Zitat von Caine Luveno
--
Mir war nichtmal bewusst dass ich nominiert wurde, aber: Cool! Hälfte des Lobes muss aber unbedingt an Archeia!Now all new and shiny:CherryShare | Patches und Tools | Programmwunschthread | www.cherrytree.at | Cherry = CherryDT
Geändert von Cherry (20.09.2007 um 20:13 Uhr)
--Aktuelles Projekt
"Uns're Ordnung ist das Chaos!
Verändern heißt zerstör'n!
Sorry, hatte grade keine Zeit, um den ganzen Beitrag zu lesen, aber falls es sich um ein Action-KS handeln sollte, würde ich dir in jeder Situation dringend davon abraten, deinen Helden transparent zu setzen... aus dem einfachen Grund, dass es da manchmal zu Bugs kommt, wo er nachher einfach nicht mehr auftauchen will. Bei einem rundenbasierenden KS geht das zwar in Ordnung, ich würde es da aber mit Variablen bzw. Switches lösen und einfach eine Seite im Heldenevent machen, wo nichts zu sehen ist, die dann per Switch startet.
Greetings!
Alan
heldenevent? lol
@caine luveno: der Satz macht sehr wohl Sinn, du hast ja geschrieben, dass du, wenn du die Animation mit CharSets machst, du die Grafik während einer Sprungs nicht ändern kannst, und den Sprung nur in der CharSet Grafik zu realisieren sieht blöd aus, weil du dann nur einen kleinen Hopser machen kannst. DIESES Problem ist dann gelöst, du kannst also das ganze CharSet für die Ani nutzen und musst nichts freilassen zum Sprungandeutn
--
Mir war nichtmal bewusst dass ich nominiert wurde, aber: Cool! Hälfte des Lobes muss aber unbedingt an Archeia!Now all new and shiny:CherryShare | Patches und Tools | Programmwunschthread | www.cherrytree.at | Cherry = CherryDT
@Alan
Es handelt sich um ein AKS. Den Helden transparent zu setzen ist kein Problem, die Bugs von denen du warscheinlich sprichst tauchen wohl dann auf wnen ein anderes MoveEvent (z.b. Held wird angegriffen) das erste untebrricht welches den Helden wieder sichtbar machen müsste.
@Cherry
DAs ist soweit klar. Damit kann ich dann alles was in ein CjarSet passt problemlos darstellen.
Fehlt mir nur noch eine Lösung für Anis die größer als ein CharSet sind <_<°
--Aktuelles Projekt
"Uns're Ordnung ist das Chaos!
Verändern heißt zerstör'n!
@Caine Luveno: Jup, das hast du völlig richtig erkannt - leider passiert das in der Praxis nur allzu oft. Aber es ergibt sich noch ein weiteres Problem. Nehmen wir an, deine Schlag-Taste ist die Enter-Taste (oder Leertaste, je nachdem...) und du gestaltest den Angriffsablauf so:
Held: unsichtbar werden -----> Schlaganimation (BA)------>Held sichtbar werden
So. Und jetzt stell dir mal vor, was passiert, wenn der Held mit Enter eine Kiste aufmacht.... Ich sag's dir - diese Hero Opacity macht nix als Ärger...
Für den Fall den du bschrieben hast: Ein PP Event welche sabfragt ob der Held vor der Truhe steht. Wenn ja, wird nix transparent gemacht
Das Problem mit den sich überschneidenden MoveEvent ist gelöst. Da selbiges ja auch für Fix Direction, MoveSpeedUp, MoveSpeedDown u.s.w. gilt. Ich sage mal vor so einem "kritischen" Move Event aktiviert man einen Switch und deaktiviert ihn danach wieder. Nun kann man abfragen ob das kritische MoveEvent noch aktiv ist oder nicht, und ggf. das Ausführen eines zweiten MoveEvents verhindern
Zu meinem Problem: Ich hab mich jetzt dran gesetzt das Spiel für die RPG_RT.exe 1.04 umzucoden. Das scheint mir nochd as einfachste zu seind a man ja bedenken muss ds wenn ich so komplizierten Kram mit vielen Events etc. zusammenschuster das ich diese auf JEDE Map kopieren muss <_<° Dadurch fliegen zwar einiges Features.... aber es wird Platz frei für wichtigere Features x)
--Aktuelles Projekt
"Uns're Ordnung ist das Chaos!
Verändern heißt zerstör'n!
Das leuchtet mir nicht wirklich ein. Wenn ein Event erstellt wird, dass die obere Körperpartie beim Sprungangriff darstellen soll und jenes Event bei der Ausführung des Angriffs auf die Heldenkoordinaten mit y-1 gesettet wird, dann kann doch kein anderes Event den Weg blockieren. Durch Set Event Place können sich meines Wissens jedenfalls so viele Events überlappen wie man lustig ist.Zitat von Caine Luveno
Da ging es darum um den Helden herum Events zu positionieren um Animationen die größer als das Heldenevent sind darstellen zu können.
Das Problem ist folgendes:
Y ist der Held. X sind die Events um ihn herum. Wir gehen davon aus der Held will nach rechts. Also prüft ein Testevent die 3 Positionen Z ob alle begehbar sind. Ist das der Fall wird ein Switch angeschaltet und der Held kann weitergehen. Das MoveEvent startet also seine Arbeit.
Nun lassen wir A einen Gegner sein welcher auf den Helden zugeht um ihn anzugreifen. Wenn das MoveEvent der Heldenevents noch nicht beendet ist, und der Gegner sich schneller bewegt als die Heldenevents kann es vorkommen das der Gegner das Feld Z schneller erreicht als das Heldenevent auf gleicher Höhe.
Womit das ganze dann so aussieht. Sowas habe ich halt schonmal ausprobiert. Die einzige Lösung wäre die Events auf OverHero zu stellen, was bei der Kollision mit Objekten, je nach Art der Animation, unschön aussieht.
--Aktuelles Projekt
"Uns're Ordnung ist das Chaos!
Verändern heißt zerstör'n!
Gut, war dann falsch bei mir angekommen =3.
Was ja schon unnötig rechenintensiv ist, da die Animationen nur bei den entsprechenden Aktionen abgespielt werden. Die x Events bei der Aktionsausführung per Set Event Place an die richtige Stelle zu setzen wäre nicht nur wesentlich weniger Aufwand, sondern auch unanfällig für das Problem (da eben kein x Event mehr parallel mitlaufen muss). Zumal du dann auch nur OverHero benutzen musst wenn es nötig ist.Zitat von Caine Luveno
Vielleicht stehe ich aber immer noch auf dem Schlauch, was ich nicht hoffe =/.