GameMaker Alarms

Never needed to use alarms before now for some reason I was able to avoid them quite effectively. However I have confusion now. I need to utilize an alarm. God knows why you can have twelve you only ever need one but any case I need to use ONE.

Like draw functions can only be used in a draw event why is it that I can use alarms in a non alarm event? Why would I want to use an alarm event? I don't understand what benefit this would achieve. As far as I can tell most of the events are just step events.

Take the asynchronous events for example. Can you use an asynchronous function in a normal step or event draw event?
 
H

Homunculus

Guest
what do you mean by “use alarm in a non alarm event”? You only set the alarm timer outside of the event (obviously), but that’s it.
 

TsukaYuriko

☄️
Forum Staff
Moderator
I'm... not entirely sure what the question here is, so I'll be responding to the ones I think are relevant and actual questions. If there's anything I left out, please let me know.

Like draw functions can only be used in a draw event why is it that I can use alarms in a non alarm event?
You can actually use draw functions outside of Draw events, but their effects may not be visible due to the way rendering works.
You can use alarms outside of Alarm events as something first needs to set an alarm before it can count down and therefore trigger an alarm event - if you only used alarms within Alarm events, none of them would ever have a chance to run.

Why would I want to use an alarm event?
You'd want to use an Alarm event if you want to introduce a delay between one thing and another thing and want the second thing to have its own event in the object's event tree and/or don't want to have to program your own delay timer.
 
I'm actually doubly confused now. Although I have solved the problem. I found a YouTube video which stated this without use of alarms.

create code: timer = room_speed * 5;

step code:

timer -= 1;
if timer == 0
{
show_message("x");
timer = room_speed * 5;
}

Exactly what I wanted no alarms. Why is this a problem and why would I want an alarm? I guess the problem with this is that it would depend on the speed of your CPU? I don't know I'm still trying to figure this out from a Gamemaker perspective.

The code I stated above appears to work perfectly. Appears being the operative word.
 
Z

zendraw

Guest
i think you need to get your basics together. youve managed to avoid alarms til now but now you need to use them yet you dont really get how they work? what am i missing,

if (timer)
{
timer--;
if (!timer)
{
//perform code
}
}
that is your alarm in code...
 
Z

zendraw

Guest
I'm actually doubly confused now. Although I have solved the problem. I found a YouTube video which stated this without use of alarms.

create code: timer = room_speed * 5;

step code:

timer -= 1;
if timer == 0
{
show_message("x");
timer = room_speed * 5;
}

Exactly what I wanted no alarms. Why is this a problem and why would I want an alarm? I guess the problem with this is that it would depend on the speed of your CPU? I don't know I'm still trying to figure this out from a Gamemaker perspective.

The code I stated above appears to work perfectly. Appears being the operative word.
that code will constantly run and show you a message every 5 sec.
 
You are correct in you assumption that I don't know how the alarms work (In GMS). But I understand why it's bad to do it in step events as these are variable dependent on, well 'everything else'. This means you can't achieve a consistent tick.

My question is really this. (I understand the difference between Create, step, and draw). What about everything else.

Create: run once
Step: every 'tick'
Draw: draw functions are only effective under this event

So what are the other events for?
 
Last edited:
H

Homunculus

Guest
Alarms should be a fairly easy concept to grasp though. You set any of them at a specific time (in steps, or 'ticks') and after that time has expired, the code inside them is run. If you don't set the alarm again, its event will not run anymore.

The other events (excluding those related to the one you mentioned like begin / end step or the other draw events) are not run regularly, but instead when something happens in your game.

Collision is fairly self explanatory, run when you collide with an instance of a specific object
Destroy happens when the instance is destroyed
User events are a bit odd, they are never triggered automatically, it's just pieces of code you can call manually whenever you prefer.

Everything is documented in the docs though, it's worth reading about every event just to get a grasp of what they are used for.
 
I think we may be talking cross-purposes here. It's my fault. I have a terrible time explaining things. Most of the issues I have with Gamemaker is not understanding what happens in the black box. It's proprietary software at the end of the day. Gamemaker is a fantastic tool for making things look as though they work but actually aren't apparent as to what is actually happening behind the curtain.

I have had Reponses before such as you need to check if this exists before calling it as the events are not intuitive or they may be up to a point but you can't truly know when it happens.

For example if you create a surface in the beginning of a step event that does not mean that if you refer to it after the step event even though it has been created that it will know of it's existence.

I appreciate this is not directly relevant to my original question but this is were all my GMS problems seem to conclude. 'You can't truly know what is happening'. Unless you work for Yoyo, or playtech or whatever.
 
H

Homunculus

Guest
I think you know enough, honestly. Do you really need to know what happens behind the curtains when you set an alarm? Or when you draw a sprite? You know the end result, and you generally don't need to worry about the most technical stuff that happens for you (like textures being sent to the graphic card or the actual implementation of a data structure).

I'm not sure I understand you example about the surface. If you create a surface in the step event, you can definitely draw it in the draw event (which happens after). What's not assured is that the surface still exists at any time after its creation do to its volatile nature, that's why you always have to check first. This is explained and well documented in the docs, it's not part of a "black box".

I do agree that sometimes you want to know how some specific function or feature works in edge cases, but that generally means revising the documentation including the parts that may be relevant to us.
 
Top