Handling of "This would probably be a good time to save the game."

[agwells]

While replaying "The Legend Lives!" I noticed another (minor) issue. The game sometimes hints that you're about to do something risky by suggesting you should save your game. But it doesn't work in TADS2-html5.

Inside the Escape Pod

   You are standing inside the escape pod.  The interior is spartan, lacking even seats and
tables, and it's barely big enough to hold several people.  The only control seems to be a big red
button marked "LAUNCH."

   The top and front of the spherical pod are made of glass.  This affords you a spectacular view
of space.                                                                                         

>push button
This would probably be a good time to save the game.

Would you like to save?  (YES or NO) > yes
Failed.

Here's a copy of "The Legend Lives!" with a save file right before one of these points. Doing push button should cause the yes/no save prompt.

legend.zip

[agwells]

Looking at the JS developer tools, what's happening is that The Legend Lives is invoking askfile() with prompType 2 (save) and fileType 11 (unknown)!

The source code for The Legend Lives is available on IFDB: http://ifdb.tads.org/viewgame?id=bi8rb6cieq8p05wl

... so I traced this down. And it looks like the cause is that it's invoking askfile() with no filetype parameter:

savegame: function
{
       local savefile;

       savefile := askfile('File to save game in');
       if (savefile = nil or savefile = '')
               "Failed. ";
       else if (save(savefile))
               "Save failed. ";
       else {
               "Saved. ";
       }
}

So, I took a look at the TADS2 documentation for askfile(). The docs say that this way of invoking askfile(), with no params, is there for backwards-compatibility, and it'll auto-detect whether it's an open dialogue or save dialogue based on whether the prompt string contains the string "save" or "write". So prompt type "save" and file type "unknown" appears to be the correct behavior.

The docs also seem to say that the file type parameter is meant to be a hint for the OS if it wants to filter the files shown in the dialogue. So I think the ultimate problem here is that the JS save code (in index.html) is being too stringent by trying to verify the filetype.

[agwells]

Here's a pull request. I also looked into loosening the filetype restrictions on the "open" dialogue, but it didn't seem like there's much point to that, because in normal gameplay a game typically only needs to open .sav files.

(Update) On further reflection, it seems prudent to also remove the filetype restriction on the open dialogue. If a game tries to do "restore" similarly to how Legend does "save", via askfile() and restore(), and it omits the filetype parameter to askfile(), it also winds up with filetype 11 (unknown).

To demonstrate, I've updated my test game to have a "saver" object, that invokes the save prompt when you do take saver, and an "opener" object that invokes the open prompt when you do take opener. I've also added a "widget" item that can be picked up or dropped in order to make a visible change to the state of the game, so you can see whether or not saves and restores are actually working.

issue2.zip

[agwells]

Merged

[my2iu]

Thanks for the pull request.