PRO | Problem mit Alarmen!

  • GM 7

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • PRO | Problem mit Alarmen!

    Hallo!
    Ich hab ein kleines Problem mit Alarmen'!
    Also:
    Ich mach gerade ein Super Mario!
    Wenn ich da unter einen ? Block Springe kommt was raus und der ? Block wird zu einem anderen Objekt: Dem schon benutztn ? Block! Da setz ich den vspeed im Create Event auf -1 (nach oben) und setz Alarm 0 auf 10! Alarm 0 setzt den vspeed auf 1 (wieder nach unten)! Dann hab ich noch einen Alarm (Alarm 1) der den vspeed wieder auf 0 (steht :P ) setzt! Jetzt stoppt der Block aber öfters schon wieder einen Pixel weiter oben, wie von dem Punkt von dem er gestartet ist nach oben zu "gehen" (ich weiß kompliziert! :D )!
    Weiß einer von euch woran das liegen könnte?
    Danke schon mal im voraus! :D

  • Ich weiß jetzt nicht so ganz, was dein Problem ist, aber ich denke, ich weiß, was du meinst - berichtige mich, wenn ich mich irre:

    Create:

    GML-Quellcode

    1. vspeed=-1
    2. alarm[0]=10
    3. alarm[1]=20


    Alarm 0

    GML-Quellcode

    1. vspeed=1


    Alarm 1

    GML-Quellcode

    1. vspeed=0


    Ist das so richtig?


    EDIT: Ich sollte vielleicht auch einen Lösungsvorschlag machen :D

    Da du vspeed im Create-Event auf -1 setzt, beginnt die Bewegung schon dort. Das heißt, der Block bewegt sich nicht 10 Pixel aufwärts, sondern 11. Du musst Alarm 1 auf 21 setzen, dann sollte der Block wieder an seiner Ursprungsposition ankommen.


    EDIT2: Copy war wohl schneller :P

  • Die Alarm Events werden scheinbar ausgeführt, bevor der vspeed zu y dazugerechnet wird.
    Mach den 2. Alarm weg und im Step Event:

    GML-Quellcode

    1. if (y > ystart) {y = ystart; vspeed = 0;}


    EDIT: Habs nochmal editiert, weil es scheinbar nicht immer so ist.
    @ Irrenhaus3: Nicht ganz richtig :P Und eig. bist du ja schneller ^^

  • Na gut copy, deine Lösung eignet sich für minimale Pixelabstände am besten - die Bewegung wirkt dadurch aber ein bisschen abgehackt.

    ED: Hmm, die Alarmevents kommen vor der Bewegung? Das wär mir aber neu... :huh:
    Ich kenn mich mit der genauen Aktionsreihenfolge des GM nicht so richtig aus (Von den Events mal abgesehen), aber meines Wissens nach kommt zuerst die Bewegung und dann die Events... hab mich wohl geirrt. :)

  • Irrenhaus3 schrieb:

    Na gut copy, deine Lösung eignet sich für minimale Pixelabstände am besten - die Bewegung wirkt dadurch aber ein bisschen abgehackt.

    ED: Hmm, die Alarmevents kommen vor der Bewegung? Das wär mir aber neu... :huh:
    Ich kenn mich mit der genauen Aktionsreihenfolge des GM nicht so richtig aus (Von den Events mal abgesehen), aber meines Wissens nach kommt zuerst die Bewegung und dann die Events... hab mich wohl geirrt. :)

    1. Wenn ihn das stört kann er den Code ins End Step Event tun - das wird noch vor dem Draw Event ausgeführt aber nach der Bewegung - so sieht es flüssig aus.

    2. Ich bin nicht ganz sicher aber danach sieht es aus.
    Außerdem, rein logisch gesehen: Events, ändern Geschwindigkeit und dann werden die Bewegungen ausgeführt. :P

  • Benutzer online 1

    1 Besucher