Add a "start timer" parameter to timer conditions?

[D8H]

According to GDJS\Runtime\events-tools\runtimescenetools.ts, a timer is started when a condition checks its value.

  export const timerElapsedTime = function (
    runtimeScene,
    timeInSeconds,
    timerName
  ) {
    const timeManager = runtimeScene.getTimeManager();
    if (!timeManager.hasTimer(timerName)) {
      timeManager.addTimer(timerName);
      return false;
    }
    return (
      timeManager.getTimer(timerName).getTime() / 1000 >= timeInSeconds
    );
  };

I understand that it makes it easier to make an action repeat every N seconds. But it also makes it harder to use timers to check if something happens in less than N seconds, because it requires to pause the timers at the beginning of the scene and when the condition is "consumed". Without a pause, the condition will always be true for the N 1st seconds of the scene.

I don't really like the idea that conditions can have side effects, but I think that they should at least be explicit.

Should a boolean parameter be added to timer condition to let the user choose to start the timer or not?

Example

In this dumb example, the player tries to press Space when ball bounce on the screen border within a -0.3 to 0.3 second time frame.

• https://www.dropbox.com/s/zmd89fjpozt7cu2/Permissive.zip?dl=1

[4ian]

Yep this design was probably not a good idea. There have been some discussions about adding a toggle parameter to choose if the timer should be started (#3065, #3282) and I think it's a good idea to add this.

[D8H]

Sorry, I forgot to take a look at issues. I think I will try to add it as the wall jump extension might need it.

[4ian]

Feel free to give it a try! We should show the parameter in the events sheet sentence I think, though this might need some adaptations to show a default value for the parameter (especially if we write the boolean description as "Start the timer automatically: [yes] [no]", we might need some code to upgrade projects).

[D8H]

This is a bit hacky but it allows to define "yes" as the default value (in InstructionMetadata::AddParameter).

  if (type == "yesorno" && info.supplementaryInformation == "yes") {
    info.supplementaryInformation = "";
    info.optional = true;
    info.SetDefaultValue("yes");
  }

But, actually, it won't fix the issue for this game example. Indeed, not(timer is greater than) != timer is lower than because if the timer doesn't exist the "not" make it true.
I guess that we don't want to have 2 conditions for greater and lower, but if we add an operator parameter it'll probably be weird to have it at the end.
So, I guess the condition should be deprecated and the the new one will have these parameters:

• timer name
• operator (only >= and <=)
• time value

And we could avoid the "start the timer automatically" parameter because it doesn't make sense to start a timer when <= is used.

[4ian]

So, I guess the condition should be deprecated and the the new one will have these parameters:

Fair enough! It's a good time to re-order parameters (in the order you specified). We should also do this for object timers.

And we could avoid the "start the timer automatically" parameter because it doesn't make sense to start a timer when <= is used.

Yes, we would not have this parameter.

We could also use limit in the editor the relational operators to only have <= or >=

[D8H]

I guess that every time comparisons will need it. So, maybe, a relationalOperatorNoEquality could be added to keep >, <, >=, <=. It might be confusing to have strict operators too as it's almost the same shifted by 1 frame, but I think it can be helpful to make true negations.

I opened a draft

• New timer conditions with an operator. #3450