You seemed to expect when() to fire for each call when you called it in that script. Each when would have only one id, but there's an issue with that, anyway; neither x nor argument0 is a constant. We haven't specified any way of denoting that one of the parameters passed to when() is constant. So when that when() was called, the condition x > argument0 would be superimposed on the step event, and that check would be done each step verbatim.

Hmm I had not thought of that, I have edited it out of the examples so it is not an issue.

What syntax could be used be used to specify constants? You can define a variable local to a script for it to be constant, for example:

Code (EDL) Select Expand

var arg0 = argument0;
when (x >= arg0)
{
  game_save();
}
But it would be useful to have a way of defining constants.

I would expect it to only run once. I would expect something like whenever for running multiple times:

Code (EDL) Select Expand

whenever (x >= 300 && xprevious < 300)
{
  show_message("You crossed the 300 line!");
}
This would be just the same as adding an if check in the step statement though so is pretty pointless:

Code (EDL) Select Expand

step
{
  if (x >= 300 && xprevious < 300)
  {
    show_message("You crossed the 300 line!");
  }
}

As I said previously I think these statements will actually improve efficiency. Let's look at an example. Say you are making a platform game and you want to the game to save once automatically when the player's x reaches 300. Now this is the method I would normally use in GM:

Creation Event:

Code (EDL) Select Expand

saved = false;
save_dist = 300;

Step Event:

Code (EDL) Select Expand

if !(saved)
{
  if (x >= save_dis)
  {
    game_save();
    saved = true;
  }
}

And this is the method I would use with a when() statement:

Creation Event:

Code (EDL) Select Expand

var save_dist = 300;
when (x >= save_dist)
{
  game_save();
}

Using the when() statement there is no need for a saved variable check because once the when statement has been met it will be removed and not checked again. Thus the code will be more efficient both before and after the player reaches 300 because that extra 'saved' check is not needed. Note also the decrease in memory and the opportunity to use no extra local variables.

You can then go even further, imagine you want to add a save point from a key press instead of just the creation event. Easy to do with the when() statement but try doing it in GML, you have to add another variable and it's even messier.

Isn't the whole event system already on a queue?

This can be fixed with some kind of queue, but that seems just like another way to lose memory and speed.

Why would it lose memory and speed?

If you have multiple draw{}until(); statements, in which order are they executed.

I presume in the order they were called. I see it as just adding them in a list to the end of the draw code, then if their until statement is met they are removed from the list.

For instance, is draw{} drawn BEFORE or AFTER the draw event contents?

After would make more sense to me.

If current_step != step_now + 4*room_speed for a bit, and then equal once again, would some text be rendered in the screen or not?

Text would be drawn while (current_step != step_now + 4*room_speed) and then when (current_step == step_now + 4*room_speed) the code piece would be removed so it would not be drawn again.

Also, regarding WHEN, couldn't it significantly harm performance?

Why?

[beginstep]

I like the draw {} idea. I think we'll limit it to that.

OK. I suppose beginstep and endstep aren't exactly 'pretty' as statements. Draw and step will be nice enough

As for current_step making lives easier... I suppose so, but I think ENIGMA inherits enough bloat from GM as it is. I... guess I'll consider it since current_time in fact will not take space in ENIGMA's RAM unless used.

Hmm, I'll try to think of some other uses for it to try and justify it's inclusion. Perhaps you should not add any unnecessary extra bloat though like you said, it is a variable you kind of expect to exist though.

EDIT: It could be useful with timelines maybe? In fact wouldn't you actually need an internal variable like this if timelines were used in a game (that's if you even bother to actually implement them of course :p).

Another thought, could you add a read-only global variable current_step, which would work just like current_time except with steps. Then alarm codes will become even easier and not need to involve creating a local variable each time:

Code (EDL) Select Expand

var message_end = current_step +  4*room_speed;
draw
{
  draw_text(x, y, "some text");
}
until (current_step == message_end)

Code (EDL) Select Expand

var step_now = current_step;
when (current_step == step_now + 30)
{
   // Alarm code
}


[until]

Oh I have just had some sudden thoughts.

I was thinking could you make it so using until after step was optional, if it wasn't added it would just always execute the code in the step event. While visualising that and due to your changed naming convention I then thought could you not also add beginstep and endstep statements as well? This would then give you control over when the step code is actually executed. And, then I thought surely a draw statement could also be added in the exact same way. So things like this could be done:

Code (EDL) Select Expand

draw
{
  draw_text(x, y, "Yo");  //this would draw the text "Yo" from now on
}
OR

Code (EDL) Select Expand

i = 0;
draw
{
  i++;
  draw_text(x, y, "some text");  //this now actually solves the original problem I stated! :]
}
until (i == 4*room_speed)
This would be great. Not being able to draw in events other than the draw event is actually another one of GML's common problems but this would be a neat way of solving it if it is possible to implement, which I'm thinking it is ...

Timers:
Ah, I see. Not a bad idea; I'll implement it when Ism reads events.res after we have our own format.

Cool. Maybe think of a better name for them though

Actually, it'd be as simple as another setting script like the four she offers now under "ENIGMA Settings." Each of those is supposed to be game-specific, and Definitions scripts are supposed to be instantiable. ENIGMA will, at that point, let you set code to be executed before game start, after game end, and (with my proposed addition) during game pause.

Ah I see, that's a good idea yeah. I didn't realise you could do something like that so easily. If you could get that to work it would be a very good way of implementing pausing.

I see no distinction between your proposal and additional alarms. We could easily make alarms unlimited.

The timer suggestion I made is different to alarms, the code in alarm events only executes when the alarm timer reaches 0. The code in timer events would execute every step until the timer reaches 0. Timer event probably isn't the best name for it as it's confusing, I couldn't think of a proper name for it though.

How do you feel about when(){} and step(){}[until()]?

Yes step() is a good name instead of do_step. That all works good.

I didn't think of the ++do_explode trick, I see how that makes things even easier.

So are you happy with that syntax yourself now? I think it all works well and comes rather naturally to write, I don't think a beginner would struggle with the concept either, it seems pretty easy to follow in my opinion (it's probably easier to understand than a for loop).

Due to the multi-platform nature of LGM-ENIGMA, I have been considering modifying LGM's events system, so you may see this implemented in the somewhat near future. I might work on it next. And good thinking about the Trigger system. We'll have to see what can be done there.

Neat.

That code is also a lot slower than if it was done internally. And it's long winded to write. Looping through instance_position like that is even slower.

[Timer Event]

OK I have thought about things some more and I think come up with a good setup. Adding these features would be hugely beneficial, allowing things to be done much more simply and I believe actually more efficiently than is currently possible. The reason I see it could be more efficient is I presume once executed these checks could be completely removed internally, whereas a user cannot do this themselves with a standard alarm or step check, the alarm or check will always remain even if it's not being used any more.

Timer Event

I think you should add a separate event for timers, which is executed every step until the count hits 0. Just like alarms, eg:

Code (EDL) Select Expand

timer[0] = 4*room_speed;

Timer 0 Event:

Code (EDL) Select Expand

draw_text(x, y, "some text");
That would be the way of solving my original problem. (Except you wouldn't be able to draw in the event but you get the idea...).

Do Step Statement

The when statement suggestion I think should definitely be added also, it really is a more powerful system. I don't think it's best suited like a for statement though, more like a do, until statement and I think it should be renamed from when to something else I'm just using do_step for now but it will obviously need to be changed from that also. I'm seeing something like this:

Code (EDL) Select Expand

i = 0;
do_step
{
  draw_text(x, y, "some text");  //will draw some text every step
  i++;
}
until (i == 4*room_speed)  //until i is equal to 4*room_speed
When the until statement has been met the code will be removed from the game.

Alarm Statement

You could maybe also do a similar statement with alarms, I think the keyword when is more suited to this actually:

Code (EDL) Select Expand

i = false;
when (i == true)
{
  show_message("hello");  //will show the message when i is set true
}
Basically it would set a dynamic alarm, when it has been executed once the code can again be removed from the game I presume.

You could then do standard alarm functionality by combining the two. ie:

Code (EDL) Select Expand


i = 4*room_speed;
do_step
{
  i--;
}
until (i == 0)

when (i == 0)
{
  show_message("hi");  //will show the message in 4 seconds.
}

[1. Referencing multiple instances]

Upon reading the rest of the replies, they seem to have resolved themselves or have already been answered above. I don't have an API to iterate instances other than rooms, which you can do in GML like so:

Code (EDL) Select Expand

for(r = room_first; r != -1; r=room_next(r)) map[room_get_name(r)] = r; I could add such an API for all resources, if you like.

I think it would be obviously useful to add an API for all resources, I've seen this wanted many of times in GM. It's just nice to have the consistency anyway. I presumed this would be something you would naturally add.

1. Referencing multiple instances
I've actually been thinking about this myself for my own purposes, and this is what I have so far:
... <snip>

Interesting ideas, maybe you could start a new topic to discuss some of these concepts further. As they could lead to some changes I think they are perhaps best discussed earlier rather than later.

2. Referencing resources as strings

I've never thought of this. It could be implemented but is not in any plan thus far. As you may be aware, maps are much easier to use in ENIGMA, but if you feel this is beneficial, file a suggestion in the tracker and I'll see about implementing it.

Like I said I'm not personally a fan of the process but I think it's little things like this which really add up in appealing to beginners. I'll put it in the tracker if that's the best place for it.

3. Exiting Code

I've been chewing on this issue for tears. Presently, scripts and DND are homogeneous; one exit means all exit. And, game_end() is instantaneous at the moment because I've not standardized an exit method. I've been waiting for someone to complain about this behavior before I modified it; suggestions are always welcome. I may define "exit" as goto <label generated at end of this script> and leave "return" as an omnipotent breaker. I Intended to do this about the time I index the code for quick position lookup on C++ compile error.

So the current behaviour doesn't actually match GM's but I presume you plan on changing it to do so. A little idea I thought of, which isn't exactly 'nice' but rather convenient for usage would be to have an optional argument for those functions. For example:

Code (EDL) Select Expand

game_end(inst)
If it was plain called with no argument as game_end() it would execute as inst being false so would behaviour exactly like GM's but if wanted you could could call game_end(true) to end the game instantaneously. I'm not sure how this idea fits in with how Enigma currently works but I think the same concept could also be used for other functions, like instance_destroy(). It's a lot more naturally for beginners to be able to specify and argument to that function to destroy a specific object, I see this all the time. So I was thinking it could possibly be done in the same way as previously suggested:

Code (EDL) Select Expand

instance_destroy(obj)
When called plain with no argument as instance_destroy() it would destroy the current instant exactly like GM's but if wanted you could call game_end(obj) to specify a particular instance to destroy.

5. Pausing The Game

In the beginning, when the earth was young, young me wanted a pause feature that would put that kind of functionality in the hands of the user. Back then, it was intended that ENIGMA would have its own interface, and I would have a special resource to implement draw code for the pause screen. I haven't even presented the idea to Ism, because I have enough things on my wish list for her. Do you suppose it will require more than a single script executed each paused step? And should it paused immediately, or just after the frame? (You mentioned this point in another issue on this list).

I'm not actually sure it would work very well having it's own interface, it sounds like a lot of work to implement as well which is never good for Ism.

I was thinking before of perhaps a separate set of functions for pausing, like something similar to that of the high-score functions. So it's functionality is not fully in the hands of the user but more generalised. This would be easy for most people if they want plain pause menus but then some pause menus also need to interact with the game itself which would be more difficult to do (maybe script_execute could be utilised by the user for this?).

I don't know really. It's not a particularly nice thing to implement but then it's also currently not very nice for the user to implement either which is why it would be rather useful if something could be worked out. Surely some other game creation programs use a pause system. It might be worth looking around to see how some of them have implemented it.

7. Timers
... <snip>

I'm going to think about this some more and get back to you. Again it's one of those things that isn't exactly very nice to implement but I'm sure something neat could be worked out.