Why is there an eEventRestoreGame but no eEventSavedGame?

[bx83]

eEventRestoreGame will trigger *after* the restore game function is finished - this is useful since normally you have to wait for the function containing the RestoreGameSlot() to finish, meaning you can't check the end result without a switch.
But why not eEventSavedGame? This would be perfect for a savegame rather than uses of switches and timers to generally guess when it's over.

[Crimson Wizard]

As usual, because no one had ever got to make it.

[bx83]

What is easy to do eEventRestoreGame? 5 lines of code or a more prosaic thing with bits all over the project?

[bx83]

added an issue: https://github.com/adventuregamestudio/ags/issues/1295

[eri0o]

I don't understand, ags savegames are currently synchronous, if the game is running in the next tick, then it has saved.

(maybe in the long future it's worth to move to assynchronous saving but moving to assynchronous is not as easy)

[bx83]

But you don’t know when this has happened, cannot verify it’s happened, cannot track an event - it’s up to you.

[Snarky]

If what eri0o says is correct, then this should work:

Code: ags

bool saveGameStarted;
bool saveGameCompleted;

void SaveMyGame(int slot, String description)
{
  SaveGameSlot(slot, description);
  saveGameStarted=true;
}

function repeatedly_execute()
{
  if(saveGameCompleted)
  {
    // TODO: whatever it is you want to do when SaveGame is complete
    saveGameCompleted=false;
  }
  if(saveGameStarted)
  {
    saveGameCompleted=true;
    saveGameStarted=false;
  }
}

It's not clear from the documentation what happens if saving the game should somehow fail (no write access?).

[Crimson Wizard]

I don't understand, ags savegames are currently synchronous, if the game is running in the next tick, then it has saved.

(maybe in the long future it's worth to move to assynchronous saving but moving to assynchronous is not as easy)

I think the point is that it's simply inconvenient to code around this everytime, cluttering your script with pseudo-events as in Snarky's example above. Having a proper event would be definitely useful. My hopes are this is also easy to add.

The big question is whether on_event is run before any other callback, so that user could catch it and reset things before anything else happens.

It's not clear from the documentation what happens if saving the game should somehow fail (no write access?).

I recently found that at some condition it displays an error, and on another it quits...... which is probably a "typo". This is fixed in 3.5.1. But I'm still not sure if it's okay to "display" it, as it's done with a default "Display" function and default font index.

PS. Maybe the save event could report a result of this operation, there's an available event argument.

[eri0o]

About Display, it works but maybe in the far future we need to figure a way to read errors in general.

Spoiler

I am not 100% sure if it's still the case but in the past Display used to break Joystick input from plugins because it only went through with real mouse clicks and not with mouse.Click(). Maybe now that there's a simulated mouse click it would work with it though.

[close]