Jump to content


Photo

Gm's Event Order


  • This topic is locked This topic is locked
37 replies to this topic

#1 icuurd12b42

icuurd12b42

    Self Formed Sentient

  • GMC Elder
  • 18181 posts
  • Version:GM:Studio

Posted 28 August 2008 - 11:08 PM

I know Gm's help tells you the event order... But not in this much detail

First, From the Help File With a little more details on xprevious,yprevious

sequence begins (<-xprevious,yprevious is set to x,y)
Begin step events
Alarm events
Keyboard, Key press, and Key release events
Mouse events
Normal step events (<-xprevious, yprevious still equate x and y, unless you changed x,y manually)
(now all instances are set to their new positions) (<-now xprevious, yprevious no longer equate x,y)
Collision events
End step events
Drawing events


Now, from start to end, going to another room, here is the event trigger sequence

<- Game starts, mouse is over the instance
InstanceRoomCode
Create (x,y = xstrat,ystart = xprevious,yprevious)
GameStart
RoomCode
RoomStart
Draw <- NOTE the draw here
Begin Step
InstanceMouseOver(NoButton)
Step
Collision
End Step
Draw

<-Pressed key and mouse button
Begin Step
Key
KeyPress
InstanceMouseDown
GlobMouseDown
InstanceMousePressed
GlobMousePressed
Step
Collision
End Step
Draw

<-Still holding the key and mouse
Begin Step
Key
InstanceMouseDown
GlobMouseDown
Step
Collision
End Step
Draw

<-Released key and mouse
Begin Step
KeyRelease
InstanceMouseOver(NoButton)
InstanceMouseReleased
GlobMouseReleased
Step
Collision
End Step
draw

Begin Step
<-RoomNextOnKeyPress
Draw <-NOTE THE DRAW
RoomEnd
<-now in next room
InstanceRoomCode <-Alarm is set to 1
Create
RoomCode
RoomStart
Draw <-NOTE THE DRAW
Begin Step
Alarm
InstanceMouseOver(NoButton)
Step
Collision
End Step
Draw

<-Escape was pressed to end the game
Begin Step
InstanceMouseOver(NoButton)
Step
Collision
End Step
Draw
RoomEnd
GameEnd


Complementary Thread By Paul23

Edited by icuurd12b42, 25 February 2013 - 07:28 AM.

  • 0

gmcbanner.pnggmcbanner_tools.png

ICU Live Tutoring Through Slack or Skype | My Tools Page follow.png

I FRANTICALLY MADE MY 18000 POST TOPIC BEFORE MIKE ANNOUNCED A DELAY...
Now I'm squirming not to hit that reply button


#2 petenka

petenka

    The Chosen One

  • New Member
  • 911 posts

Posted 28 August 2008 - 11:14 PM

dang, this is way helpful but i could probably make a completely accurate version just using show_message
  • 0
My Stuff:
Attack of the Jelly - A game about (oh, the horror) strawberry jelly!
Math Based Platformer Engine - The best physics for a platformer, ever.
Realtime Dynamic Fog - For realistic environmental effects.
Windy Snow - The best snow in all of gmc.
My Hate List:
Kubanen, Alex4Red, johnjoe

#3 icuurd12b42

icuurd12b42

    Self Formed Sentient

  • GMC Elder
  • 18181 posts
  • Version:GM:Studio

Posted 28 August 2008 - 11:37 PM

dang, this is way helpful but i could probably make a completely accurate version just using show_message


So could I and so I did and this is the result... I did not type all that.

show_debug message log...

script show_debug_message
//overrides GM's show_debug_message
hf = file_text_open_append("t.txt")
file_text_write_string(hf,argument0)
file_text_writeln(hf)
file_text_close(hf)



I set Room speed set to 1 to give me time to react and save on the logging quantity. And Added all (most) the events to an object...
  • 0

gmcbanner.pnggmcbanner_tools.png

ICU Live Tutoring Through Slack or Skype | My Tools Page follow.png

I FRANTICALLY MADE MY 18000 POST TOPIC BEFORE MIKE ANNOUNCED A DELAY...
Now I'm squirming not to hit that reply button


#4 slayer 64

slayer 64

    Slayer of gingers

  • GMC Member
  • 4301 posts
  • Version:GM:Studio

Posted 28 August 2008 - 11:47 PM

very good stuff to know.

most of the time gm is a pain just because things are happening at the wrong time.
  • 1

5y5rs3d.pngfg0UQNL.png


#5 Tahnok

Tahnok

    Friendly Madman

  • GMC Member
  • 1854 posts
  • Version:GM:Studio

Posted 29 August 2008 - 12:27 AM

Seems a little unorganized. Some formatting and such would do wonders for that list. Also, a lot of this information can be expressed in an easier to understand format (like not putting separate lists for each press/hold/release variant).

I didn't read through it too closely, but at a glance it seems like it has some information that my list lacks and misses some that my list contains. Here's the list I'm talking about for reference:
http://gmc.yoyogames...opic=155878&hl=

Like I said, I didn't compare them directly but if you want you can to make sure the list is complete.
  • 0

gmc_signature.png


#6 T-Bird

T-Bird

    GMC Member

  • New Member
  • 1326 posts

Posted 29 August 2008 - 12:29 AM

I saw no mention of the instance create or instance destroy events. Unless I over looked them.

[edit: found the create event, but only in the context of game start. Create as it relates to instance_create() would be nice to have as well.]

Something strange I noted today if you use instance_create() then assign values to variables in instance they're overwritten by the create event (which I already knew) but they aren't yet assigned for the first draw event of the new instance. Quite annoying.

So for example object0 has this code

inst = instance_create(x,y,object1)
inst.words = 'Hello World'

object1 has this draw code
draw_text(x,y,words);

GM will throw an unassigned variable error.

At the same time adding this to object1's create event

words = 'Goodbye World';

GM will not throw an error (the draw event will pull the variable from the create event) but it appears that the create event overwrites what object0 has set (as can be expected).

Does this mean GM calls the new instance's draw event immediately when instance_create is called?

Short of using an alarm to make a one step delay is there a way around this?

Edited by T-Bird, 29 August 2008 - 12:32 AM.

  • 0

#7 icuurd12b42

icuurd12b42

    Self Formed Sentient

  • GMC Elder
  • 18181 posts
  • Version:GM:Studio

Posted 29 August 2008 - 12:40 AM

Seems a little unorganized. Some formatting and such would do wonders for that list. Also, a lot of this information can be expressed in an easier to understand format (like not putting separate lists for each press/hold/release variant).

I didn't read through it too closely, but at a glance it seems like it has some information that my list lacks and misses some that my list contains. Here's the list I'm talking about for reference:
http://gmc.yoyogames...opic=155878&hl=

Like I said, I didn't compare them directly but if you want you can to make sure the list is complete.


It's as organized and as ordered as GM triggers them...

Your list is missing the room code, the instance room code. the initial draw when the room starts and the draw when the room end and the sequence of events key down being called before the key pressed.



t-bird, I never experiences this... But I never add a variable to an instance without having it set to a default on create.

Testing... Nope, I dont have the problem.

I have GM7

Edited by icuurd12b42, 29 August 2008 - 12:49 AM.

  • 0

gmcbanner.pnggmcbanner_tools.png

ICU Live Tutoring Through Slack or Skype | My Tools Page follow.png

I FRANTICALLY MADE MY 18000 POST TOPIC BEFORE MIKE ANNOUNCED A DELAY...
Now I'm squirming not to hit that reply button


#8 T-Bird

T-Bird

    GMC Member

  • New Member
  • 1326 posts

Posted 29 August 2008 - 12:54 AM

I use GM7 too, I was using the first method (without the create event). I had always thought that variables assigned after the instance create overwrote the ones in the create event, but they dont seem to for me this time. The only thing I can think of is that the created instance has a depth significantly lower than the creator (and actually is dynamically set soon after creation).
  • 0

#9 xot

xot

    GMC Dismember

  • GMC Elder
  • 4785 posts
  • Version:GM:Studio

Posted 29 August 2008 - 01:12 AM

Something strange I noted today if you use instance_create() then assign values to variables in instance they're overwritten by the create event (which I already knew) but they aren't yet assigned for the first draw event of the new instance. Quite annoying.

I don't have a problem with this either. As far as I can tell, when you create an instance in GML, it's Create Event code runs immediately. After that, any variables you set for the instance, while in the same event from which you created the instance will also be treated as Create Event code, meaning new variables will become local variables. So you do not have to explicitly define your local variables within the object's normal Create Event (although it is probably good practice), this can be done after creation.

About the problem of an instance's Create Event undoing your external code, maybe you are thinking of creation code that you enter into the Room Editor. Code in an instance's Create Event will run after the code in the Room Editor's instance Creation Code block. That's a strange design decision that can cause unexpected problems and interfere with the "good practice" above.
  • 0
GMLscripts.com, rise from your grave!

If any of my posts contain broken images or links, I can probably supply them for you. PM with a link to the post.

#10 T-Bird

T-Bird

    GMC Member

  • New Member
  • 1326 posts

Posted 29 August 2008 - 01:21 AM

Nope, haven't used the room creation code in this program (it only has one room). It was a long day full of alot of bugs, maybe I'm mistaken and am crossing a couple of different issues I've had. At any rate, I've never noticed the problem before, so until I've done further testing I'll write it off as a variable name conflict somewhere else in my program.
  • 0

#11 Tahnok

Tahnok

    Friendly Madman

  • GMC Member
  • 1854 posts
  • Version:GM:Studio

Posted 29 August 2008 - 03:52 AM

[...]
It's as organized and as ordered as GM triggers them...

Your list is missing the room code, the instance room code. the initial draw when the room starts and the draw when the room end and the sequence of events key down being called before the key pressed.
[...]

I mean formatting and making it look more organized, so it's easier to read and follow.

Take another look. It has the initial draw and the room creation code under "game start". It also clearly shows that the key hold is before the key press and release (listed under "normal step"). I'm not sure about the final draw call, I'll have to take another look at that one. Instance room creations code was added to a later version of the list (after someone in that topic pointed it out). Here, I put the final list I came up with back online since my website is down right now:
PDF order of events list
  • 0

gmc_signature.png


#12 icuurd12b42

icuurd12b42

    Self Formed Sentient

  • GMC Elder
  • 18181 posts
  • Version:GM:Studio

Posted 29 August 2008 - 04:19 AM

Take another look. It has the initial draw and the room creation code under "game start". It also clearly shows that the key hold is before the key press and release (listed under "normal step").


LOL, I guess we both can't read each other's style.
  • 0

gmcbanner.pnggmcbanner_tools.png

ICU Live Tutoring Through Slack or Skype | My Tools Page follow.png

I FRANTICALLY MADE MY 18000 POST TOPIC BEFORE MIKE ANNOUNCED A DELAY...
Now I'm squirming not to hit that reply button


#13 Tahnok

Tahnok

    Friendly Madman

  • GMC Member
  • 1854 posts
  • Version:GM:Studio

Posted 29 August 2008 - 04:21 AM

Take another look. It has the initial draw and the room creation code under "game start". It also clearly shows that the key hold is before the key press and release (listed under "normal step").


LOL, I guess we both can't read each other's style.

Haha, yeah, I guess not. To each his own I suppose.
  • 0

gmc_signature.png


#14 NakedPaulToast

NakedPaulToast

    GM Studio/Mac/Win

  • GMC Member
  • 8808 posts
  • Version:GM:Studio

Posted 29 August 2008 - 05:55 AM

One addition to your list, could be how events are affected by persistant rooms, and persistant objects.

I seem to remember some non-intituitive event stuff, but can't remember off-hand what it was.
  • 0

If the Bible truly is inspired by God, you would think that somebody as omnipotent and all-knowing would have known to get his message out using TCP instead of UDP.

 


#15 icuurd12b42

icuurd12b42

    Self Formed Sentient

  • GMC Elder
  • 18181 posts
  • Version:GM:Studio

Posted 29 August 2008 - 07:01 AM

One addition to your list, could be how events are affected by persistant rooms, and persistant objects.

I seem to remember some non-intituitive event stuff, but can't remember off-hand what it was.


I'll check later... Right now my assumption is that instances will not get a create event nor instanceroomcode... They'll get all other room and game start end events. But we'll see.
  • 0

gmcbanner.pnggmcbanner_tools.png

ICU Live Tutoring Through Slack or Skype | My Tools Page follow.png

I FRANTICALLY MADE MY 18000 POST TOPIC BEFORE MIKE ANNOUNCED A DELAY...
Now I'm squirming not to hit that reply button


#16 Stubbjax

Stubbjax

    RandomGuy General

  • GMC Member
  • 4208 posts
  • Version:GM8

Posted 29 August 2008 - 07:05 AM

Please disregard this post. I interpreted you're "InstanceRoomCode" as the room creation code. Sorry.

Very helpful list of events though. :) I will most surely revisit this topic.

Edited by stubbjax02, 29 August 2008 - 07:07 AM.

  • 0
2qi1d8l.jpg

#17 Pallas

Pallas

    GMC Member

  • GMC Member
  • 94 posts

Posted 29 August 2008 - 03:15 PM

I'm wondering in what order the create events occur. According to depth, according to which instance is first placed in the room? What is it? I've got enough problems with that.

EDIT: It's in order of depth. Now, what happens if instances has the same depth? Does it depend then in which order they're placed?

Edited by Pallas, 29 August 2008 - 05:29 PM.

  • 0
Ninjamboree, my YoYo Games competition #03 entry!
See:
GMC Ninjamboree Topic
Play and vote:
Ninjamboree on YoYo Games (Instant Play and Download)

#18 Tahnok

Tahnok

    Friendly Madman

  • GMC Member
  • 1854 posts
  • Version:GM:Studio

Posted 29 August 2008 - 08:11 PM

I'm wondering in what order the create events occur. According to depth, according to which instance is first placed in the room? What is it? I've got enough problems with that.

EDIT: It's in order of depth. Now, what happens if instances has the same depth? Does it depend then in which order they're placed?



Grabbed from that pdf I posted:

The order the objects are handled is determined by depth (lower numbers execute first) and then, for objects at the same depth, by the order they were created (placed in the room, first placed will execute first).



Edit: Scratch that, read below.

Edited by Tahnok, 29 August 2008 - 09:21 PM.

  • 0

gmc_signature.png


#19 icuurd12b42

icuurd12b42

    Self Formed Sentient

  • GMC Elder
  • 18181 posts
  • Version:GM:Studio

Posted 29 August 2008 - 09:05 PM

I'm wondering in what order the create events occur. According to depth, according to which instance is first placed in the room? What is it? I've got enough problems with that.

EDIT: It's in order of depth. Now, what happens if instances has the same depth? Does it depend then in which order they're placed?


Grabbed from that pdf I posted:

The order the objects are handled is determined by depth (lower numbers execute first) and then, for objects at the same depth, by the order they were created (placed in the room, first placed will execute first).


I seem to recal ragarnak or torigara saying some events are actually ordered by object index, then by creation order. But the draw is always by depth (then possibly by object index) then by creation order.
  • 0

gmcbanner.pnggmcbanner_tools.png

ICU Live Tutoring Through Slack or Skype | My Tools Page follow.png

I FRANTICALLY MADE MY 18000 POST TOPIC BEFORE MIKE ANNOUNCED A DELAY...
Now I'm squirming not to hit that reply button


#20 Tahnok

Tahnok

    Friendly Madman

  • GMC Member
  • 1854 posts
  • Version:GM:Studio

Posted 29 August 2008 - 09:20 PM

I seem to recal ragarnak or torigara saying some events are actually ordered by object index, then by creation order. But the draw is always by depth (then possibly by object index) then by creation order.

Hmm, looks like I made a mistake three years ago when I ran that test. I haven't verified that what you said is correct, but I just verified that what I said was incorrect. Oh well, can't be right all the time, haha.
  • 0

gmc_signature.png


#21 paul23

paul23

    GMC Member

  • Global Moderators
  • 4147 posts
  • Version:GM:Studio

Posted 29 August 2008 - 10:10 PM

Lol well I just did my own research too... Mostly exactly the same as icuurds apart from some extra points that might be fun:

http://www.gmlscript...opic.php?id=138

# creation code (A). This is the "ctrl-right-click-creation-code" from the room editor, don't confuse it with the creation event# creation event (A)# Game start (A)# Room creation code (A) (again, not the "event" but the code you can put in the room editor)# Room start event (A)# Draw event (A) - This is a bit strange drawing event, since the "updating" from image_index doesn't happen...# begin step event (B )# ---alarm0 timer updating---# alarm[0]# ---alarm1 timer updating---# alarm[1] - This is the general scheme, notice however that if the alarm turns "0" the event is triggered: but the step after that the alarm is still updated to -1.# keyboard events (B )- This is simply in order in which they also appear at the gm-editor, except for the any key (which is list executed after all keyboard events) and the "no-key" (which I simply couldn't test...)# keyboard press events (B )# keyboard release events (B )# mouse events (B ) - this is in some strange order    * normal left    * global left    * normal middle    * global middle    * normal right    * global right    * pressed events (as above)    * release events (as above)    * mouse up/down    * mouse enter/leave# step event (B ) - NOTICE: THE INSTANCE IS STILL AT IT'S "OLD" POSITION!# ---position updating with "hspeed/vspeed*---# ---position updating with *paths*---# path end (B ) - the instance is now at it's "NEW" position for the step!# Outside room (B )# Intersect boundary (B )# Boundary view[X] (B ) - It handles all views in order (from lowest to highest)# outside view[X] (B ) - see above# ---Collision calculating--- in case of a solid collision the instances are set back NOW (notice: while the position changes, to <x,y>previous, it isn't the same as saying: <x,y>=<x,y>previous since the <x,y>previous itself ISN'T updated!)# Collision (B ), also the collisions are handled in "B" order: first with the smallest object id, and the instance id as tiebreaker# end step (B )# Draw event (A) - the draw events are all (also the one before) executed for each view in order of view index# ---updating the image_index---# animation end event (A)# BACK TO BEGIN STEP EVENT!It's a bit hard to determine what a "round" is, but I think best would be to call it from "begin step event to animation end event".. The first few rounds are "special" rounds (the draw event because it isn't followed by an updating from the image index)...

  • 0

#22 icuurd12b42

icuurd12b42

    Self Formed Sentient

  • GMC Elder
  • 18181 posts
  • Version:GM:Studio

Posted 29 August 2008 - 10:21 PM

I seem to recal ragarnak or torigara saying some events are actually ordered by object index, then by creation order. But the draw is always by depth (then possibly by object index) then by creation order.

Hmm, looks like I made a mistake three years ago when I ran that test. I haven't verified that what you said is correct, but I just verified that what I said was incorrect. Oh well, can't be right all the time, haha.


I have not verified what I said (rag or tori said) either. From my own tests, I thought the events were called by creation order except for the draw. The object index added in the mix was news to me. Possibly got by my own tests, as the tests I made progressively added new objects in the project then new instances added to the room when instances of older objets were already there.

So we'd need to add object0, then add object1 to a project. In the room, add instances of object1, then object0 then object1 then object0

And here is the sesult of the step event, showing object index then ID.

0 100002
0 100004
1 100001
1 100003

Confirming the statement.

Now the draw. Both at same depth
1 100001
1 100003
0 100002
0 100004

***Reversed... Interesting. But note, it's NOT in the creation order of all, but object_index (descending) then creation order (ascending)

Now object0 deeper than object1
0 100002
0 100004
1 100001
1 100003

Now Object1 deeper tha object0
1 100001
1 100003
0 100002
0 100004


BUT, Adding a 3rd object in the mix and the results change
Adding object2, Now the romm has the instances in this order (object indext) 2 1 0 2 1 0
Now the draw at same depth
2 100006
1 100007
2 100009
1 100010
0 100008
0 100011

***So here goes my assumption on object index +creation order in the draw

Here 2 and 1 are at the same depth (deeper than 0)
2 100006
1 100007
2 100009
1 100010
0 100008
0 100011

***Now it really looks like is depth + creation order (don't be fooled as the other test showed)

Here 2 and 0 are same depth deeper than 1
2 100006
2 100009
0 100008
0 100011
1 100007
1 100010

Here 0 and 1 same deeper than 2
1 100007
1 100010
0 100008
0 100011
2 100006
2 100009


***So, I assume the draw order is NOT predictable when at the same depth


in the step it's the same
0 100008
0 100011
1 100007
1 100010
2 100006
2 100009

Edited by icuurd12b42, 29 August 2008 - 10:43 PM.

  • 0

gmcbanner.pnggmcbanner_tools.png

ICU Live Tutoring Through Slack or Skype | My Tools Page follow.png

I FRANTICALLY MADE MY 18000 POST TOPIC BEFORE MIKE ANNOUNCED A DELAY...
Now I'm squirming not to hit that reply button


#23 Dangerous_Dave

Dangerous_Dave

    GMC Member

  • Global Moderators
  • 9450 posts
  • Version:Unknown

Posted 30 August 2008 - 02:31 AM

Begin step events (<-xprevious,yprevious is set to x,y)

If xprevious and yprevious were set in the begin step event, then you could not use them in the step event as they would be equal to x and y.
I believe they are only set once, in the end step event.
  • 0

#24 icuurd12b42

icuurd12b42

    Self Formed Sentient

  • GMC Elder
  • 18181 posts
  • Version:GM:Studio

Posted 30 August 2008 - 03:49 AM

Begin step events (<-xprevious,yprevious is set to x,y)

If xprevious and yprevious were set in the begin step event, then you could not use them in the step event as they would be equal to x and y.
I believe they are only set once, in the end step event.

Nope. Sorry. I am correct here.
  • 0

gmcbanner.pnggmcbanner_tools.png

ICU Live Tutoring Through Slack or Skype | My Tools Page follow.png

I FRANTICALLY MADE MY 18000 POST TOPIC BEFORE MIKE ANNOUNCED A DELAY...
Now I'm squirming not to hit that reply button


#25 Dangerous_Dave

Dangerous_Dave

    GMC Member

  • Global Moderators
  • 9450 posts
  • Version:Unknown

Posted 30 August 2008 - 03:56 AM

Think about it logically. Setting xprevious = x and yprevious = y in the begin step event would render them useless.
  • 0

#26 icuurd12b42

icuurd12b42

    Self Formed Sentient

  • GMC Elder
  • 18181 posts
  • Version:GM:Studio

Posted 30 August 2008 - 04:06 AM

Think about it logically. Setting xprevious = x and yprevious = y in the begin step event would render them useless.


Test it. I did and it's set in/before the begin step nowhere else. See all those people who posted there "compare x to xprevious in the step event code" and it never works..

before begin step xyprevious is set to xy
in begin step; xy == xyprevious
in step; xy == xyprevious
between step and collsion, GM updates xy
on collision; xy != xyprevious
in end step; xy != xyprevious
in draw xy; != xyprevious
  • 0

gmcbanner.pnggmcbanner_tools.png

ICU Live Tutoring Through Slack or Skype | My Tools Page follow.png

I FRANTICALLY MADE MY 18000 POST TOPIC BEFORE MIKE ANNOUNCED A DELAY...
Now I'm squirming not to hit that reply button


#27 NakedPaulToast

NakedPaulToast

    GM Studio/Mac/Win

  • GMC Member
  • 8808 posts
  • Version:GM:Studio

Posted 30 August 2008 - 04:09 AM

I have not verified what I said (rag or tori said) either. From my own tests, I thought the events were called by creation order except for the draw. The object index added in the mix was news to me. Possibly got by my own tests, as the tests I made progressively added new objects in the project then new instances added to the room when instances of older objets were already there.


Sometimes I wish that GM supported a processing order, for all events, (but the draw), that allowed us to control the order of object event processing. It would work similar to depth.

99.9% of the time it could be left at it's default, but that .1% of the time where you want to specify the object order, there's no better solution.
  • 0

If the Bible truly is inspired by God, you would think that somebody as omnipotent and all-knowing would have known to get his message out using TCP instead of UDP.

 


#28 Dangerous_Dave

Dangerous_Dave

    GMC Member

  • Global Moderators
  • 9450 posts
  • Version:Unknown

Posted 30 August 2008 - 04:50 AM

Test it.

I can't, no GM.

I did and it's set in/before the begin step nowhere else. See all those people who posted there "compare x to xprevious in the step event code" and it never works..


I always used to compare in the step event. Where else would you do it?
However, I just worked out why you're right :whistle:

x/yprevious is set in the begin step event, momentarily before the x and y positions are updated. So begin step is something like this:

xprevious = x;
yprevious = y;
x+=hspeed;
y+=vspeed;

Which means that in the step event, x/y and x/yprevious are different, allowing them to be usefull.
  • 0

#29 icuurd12b42

icuurd12b42

    Self Formed Sentient

  • GMC Elder
  • 18181 posts
  • Version:GM:Studio

Posted 30 August 2008 - 05:09 AM

Test it.

I can't, no GM.

Then why don't you get GM and test it for yourself.

I did and it's set in/before the begin step nowhere else. See all those people who posted there "compare x to xprevious in the step event code" and it never works..


I always used to compare in the step event. Where else would you do it?
However, I just worked out why you're right :whistle:

x/yprevious is set in the begin step event, momentarily before the x and y positions are updated. So begin step is something like this:

xprevious = x;
yprevious = y;
x+=hspeed;
y+=vspeed;

Which means that in the step event, x/y and x/yprevious are different, allowing them to be usefull.


Not quite. Listen I have tested this. xy != yxprevious in the step...

Normal step events (<-xprevious, yprevious still equate x and y, unless you changed x,y manually)


between draw and begin step
xprevious = x; yprevious = y;

begin step

other events

step

between step and collision
x+=hspeed; y+=vspeed;

collision

end step

draw


hspeed = 2.

logs
Event Name
x xprevious

Begin Step
164 164
Step
164 164
Collision
166 164
End Step
166 164
Draw
166 164
Begin Step
166 166

Edited by icuurd12b42, 30 August 2008 - 05:15 AM.

  • 0

gmcbanner.pnggmcbanner_tools.png

ICU Live Tutoring Through Slack or Skype | My Tools Page follow.png

I FRANTICALLY MADE MY 18000 POST TOPIC BEFORE MIKE ANNOUNCED A DELAY...
Now I'm squirming not to hit that reply button


#30 Dangerous_Dave

Dangerous_Dave

    GMC Member

  • Global Moderators
  • 9450 posts
  • Version:Unknown

Posted 30 August 2008 - 06:22 AM

Then why don't you get GM and test it for yourself.

My computer can't run GM.

Not quite. Listen I have tested this. xy != yxprevious in the step...


But xprevious and yprevious work in the step event... I've used it plenty of times.
  • 0

#31 icuurd12b42

icuurd12b42

    Self Formed Sentient

  • GMC Elder
  • 18181 posts
  • Version:GM:Studio

Posted 30 August 2008 - 07:04 AM

Then why don't you get GM and test it for yourself.

My computer can't run GM.

Not quite. Listen I have tested this. xy != yxprevious in the step...


But xprevious and yprevious work in the step event... I've used it plenty of times.


They never did for me. Perhapse you used the End Step, perhapse you compared xprevious with x after you modified x manualy. Anyway, my log does not lie.

Make me a GM file that proves your theory and post it here to prove me wrong. Because your argument is nulified by my event logger.
  • 0

gmcbanner.pnggmcbanner_tools.png

ICU Live Tutoring Through Slack or Skype | My Tools Page follow.png

I FRANTICALLY MADE MY 18000 POST TOPIC BEFORE MIKE ANNOUNCED A DELAY...
Now I'm squirming not to hit that reply button


#32 Dangerous_Dave

Dangerous_Dave

    GMC Member

  • Global Moderators
  • 9450 posts
  • Version:Unknown

Posted 30 August 2008 - 08:06 AM

Make me a GM file that proves your theory and post it here to prove me wrong. Because your argument is nulified by my event logger.

Believe me when I say I wish I could. But I've already told you my computer can't handle GM.

Edited by Dangerous_Dave, 30 August 2008 - 08:17 AM.

  • 0

#33 paul23

paul23

    GMC Member

  • Global Moderators
  • 4147 posts
  • Version:GM:Studio

Posted 30 August 2008 - 08:27 AM

Uhm I made a program too for this (simply outputting a code to an csv file every event).. And yes icuurd is right: this is new for me too btw I always thought the "xprevious" would change at the instant "x" changes - bit like nomorelives is triggered at the instance lives hits 0.

But these are the kind of things that I believe should be documentated better...
  • 0

#34 icuurd12b42

icuurd12b42

    Self Formed Sentient

  • GMC Elder
  • 18181 posts
  • Version:GM:Studio

Posted 30 August 2008 - 08:31 AM

Lol well I just did my own research too... Mostly exactly the same as icuurds apart from some extra points that might be fun:

http://www.gmlscript...opic.php?id=138

# creation code (A). This is the "ctrl-right-click-creation-code" from the room editor, don't confuse it with the creation event
# creation event (A)
# Game start (A)
# Room creation code (A) (again, not the "event" but the code you can put in the room editor)
# Room start event (A)
# Draw event (A) - This is a bit strange drawing event, since the "updating" from image_index doesn't happen...
# begin step event (B )
# ---alarm0 timer updating---
# alarm[0]
# ---alarm1 timer updating---
# alarm[1] - This is the general scheme, notice however that if the alarm turns "0" the event is triggered: but the step after that the alarm is still updated to -1.
# keyboard events (B )- This is simply in order in which they also appear at the gm-editor, except for the any key (which is list executed after all keyboard events) and the "no-key" (which I simply couldn't test...)
# keyboard press events (B )
# keyboard release events (B )
# mouse events (B ) - this is in some strange order

	* normal left
	* global left
	* normal middle
	* global middle
	* normal right
	* global right
	* pressed events (as above)
	* release events (as above)
	* mouse up/down
	* mouse enter/leave

# step event (B ) - NOTICE: THE INSTANCE IS STILL AT IT'S "OLD" POSITION!
# ---position updating with "hspeed/vspeed*---
# ---position updating with *paths*---
# path end (B ) - the instance is now at it's "NEW" position for the step!
# Outside room (B )
# Intersect boundary (B )
# Boundary view[X] (B ) - It handles all views in order (from lowest to highest)
# outside view[X] (B ) - see above
# ---Collision calculating--- in case of a solid collision the instances are set back NOW (notice: while the position changes, to <x,y>previous, it isn't the same as saying: <x,y>=<x,y>previous since the <x,y>previous itself ISN'T updated!)
# Collision (B ), also the collisions are handled in "B" order: first with the smallest object id, and the instance id as tiebreaker
# end step (B )
# Draw event (A) - the draw events are all (also the one before) executed for each view in order of view index
# ---updating the image_index---
# animation end event (A)
# BACK TO BEGIN STEP EVENT!

It's a bit hard to determine what a "round" is, but I think best would be to call it from "begin step event to animation end event".. The first few rounds are "special" rounds (the draw event because it isn't followed by an updating from the image index)...


I missed that on. Nice. I referenced it in my main post

Can you edit your message and change the codebox tag with code tag? I'm loosing my reply buttons


Oh, and thanks for the validation about the xyprevious. (Post Above)

Draw event (A) - This is a bit strange drawing event, since the "updating" from image_index doesn't happen...


Remember the room transition routines need an image to work with.

So you get a draw (screen_redraw()) before room end and after room start

Edited by icuurd12b42, 30 August 2008 - 08:39 AM.

  • 0

gmcbanner.pnggmcbanner_tools.png

ICU Live Tutoring Through Slack or Skype | My Tools Page follow.png

I FRANTICALLY MADE MY 18000 POST TOPIC BEFORE MIKE ANNOUNCED A DELAY...
Now I'm squirming not to hit that reply button


#35 paul23

paul23

    GMC Member

  • Global Moderators
  • 4147 posts
  • Version:GM:Studio

Posted 30 August 2008 - 09:56 AM

<snip>

I missed that on. Nice. I referenced it in my main post

Can you edit your message and change the codebox tag with code tag? I'm loosing my reply buttons


Oh, and thanks for the validation about the xyprevious. (Post Above)

Draw event (A) - This is a bit strange drawing event, since the "updating" from image_index doesn't happen...


Remember the room transition routines need an image to work with.

So you get a draw (screen_redraw()) before room end and after room start



uhm why couldn't you? - I just used codetags to stop cluttering up the whole page :medieval:

Did you follow the link already? This part might be usefull too:

There are a few events not listed here these can be in 2 groups:
instance_destroy, room_end and game_end These 3 events are all executed immediatelly after the calling event has "triggered" the event..
nomorelives, nomorehealth and creation Those events are executed at the right moment of "triggering": it even "interupts" the current event...


  • 0

#36 icuurd12b42

icuurd12b42

    Self Formed Sentient

  • GMC Elder
  • 18181 posts
  • Version:GM:Studio

Posted 30 August 2008 - 10:17 AM

Did you follow the link already? This part might be usefull too:

There are a few events not listed here these can be in 2 groups:
instance_destroy, room_end and game_end These 3 events are all executed immediatelly after the calling event has "triggered" the event..
nomorelives, nomorehealth and creation Those events are executed at the right moment of "triggering": it even "interupts" the current event...


Yep. I think referencing you thread will make it more complete without me needing to copy it.

room_goto triggers right away and stops everything... The tiny detail you miss is the draw event before the room end.


Oh, and pressing escape, letting GM handle it, you will see the events sequence will run it course, looks like the esc detection happens between draw and begin step. I don't know about calling game_end() though.
  • 0

gmcbanner.pnggmcbanner_tools.png

ICU Live Tutoring Through Slack or Skype | My Tools Page follow.png

I FRANTICALLY MADE MY 18000 POST TOPIC BEFORE MIKE ANNOUNCED A DELAY...
Now I'm squirming not to hit that reply button


#37 paul23

paul23

    GMC Member

  • Global Moderators
  • 4147 posts
  • Version:GM:Studio

Posted 30 August 2008 - 11:07 AM

Did you follow the link already? This part might be usefull too:

There are a few events not listed here these can be in 2 groups:
instance_destroy, room_end and game_end These 3 events are all executed immediatelly after the calling event has "triggered" the event..
nomorelives, nomorehealth and creation Those events are executed at the right moment of "triggering": it even "interupts" the current event...


Yep. I think referencing you thread will make it more complete without me needing to copy it.

room_goto triggers right away and stops everything... The tiny detail you miss is the draw event before the room end.


Oh, and pressing escape, letting GM handle it, you will see the events sequence will run it course, looks like the esc detection happens between draw and begin step. I don't know about calling game_end() though.


game_end() is after the current event... - if you call it in the step event I noticed the step event is the last, if I call it during the draw event the draw event is the last reported etc...


However strange, very strange things have happened to me when pressing esc which might be related:
first of all it calls the room_end event too (which, as far as I could test, game_end() doesn't do), but futhermore if you put this code inside it:
instance_destroy()
(in all objects' room_end events)
and in the destroy code you put something like this:
with (all)
	{
		//hp-=argument[i+1]
		if (id != other.id)
		{
			  show_message(string(id));
			  hp+=1;
		}
		
	}
it gives an error! :medieval: "unknown variable hp"..

Now what even more strange is that this only happens for object which have a SMALLER index than the calling object (the one in which I have put above with statment in the destroy event).
AND, it only happens with "custom" variables which are not declared in the creation event!
in my game hp is declared this way:
---creation event ----
alarm[0] = 1;
---alarm[0]----
hp=SI;
show_message(string(id) +"|"+string(hp));
And yes the message shows up for the ID which also "acts up" at the above with statement... So the error is in GM itself.
A simple fix is to add "hp=1" in the creation event (0 would trigger a special thing during the begin step event). Though I don't really like that (it simply isn't correct).


What happens I think is this: during a instance_destroy() call all instance-destroy events are "handled" in the order of object_id/instance_id (B).
However after these events the instance isn't really "destroyed" yet: it still exists for the other instance's destroy events.. Yet all variables that aren't "predefined (x,image_index etc)" or "initialized in the instance creation event" are removed.
  • 0

#38 icuurd12b42

icuurd12b42

    Self Formed Sentient

  • GMC Elder
  • 18181 posts
  • Version:GM:Studio

Posted 30 August 2008 - 09:01 PM

That is crazy. But in any laguage you get this sort of craziness.

BTW, it is always better to define variables used by the object in the create event. But yeah, it's a weird one. It should not care that you created the variable in the create or anywhere else. Maybe some odd Native code is recreating the object temporarely to make "the destroyed but not quite gone instances" valid again.
  • 0

gmcbanner.pnggmcbanner_tools.png

ICU Live Tutoring Through Slack or Skype | My Tools Page follow.png

I FRANTICALLY MADE MY 18000 POST TOPIC BEFORE MIKE ANNOUNCED A DELAY...
Now I'm squirming not to hit that reply button