Yesterday, I discovered that I'd been caught out by a feature of SAVE that I'd encountered before, and brought up before, but didn't resolve at the time. The SAVE operation during play performs some code checks that are not done by PLAY or PUBLISH, meaning that some code faults in published games are only reported when SAVE is used. Is there a problem with the same checks being added to PLAY or at least to PUBLISH?

In making the change, I also noticed that PUBLISH works on the last saved version of a game. So, if I go in in to make a minor change and don't save, no change will occur. Could PUBLISH check if changes have occurred in the open .aslx game and prompt for a save, or simply save and publish automatically?

This game, like my others, allows for the MAP, GAME PANES and HYPERLINKS to be switched on and off dynamically. The default setting is 'map on', 'links on' and 'panes off'. When resuming play after a SAVE, however, the panes appear! Is there a work around for this problem?

In introducing dynamic game panes last May, it was discovered that there was a problem with white space calculation when the panes were taken out, and a large gap often appeared. K.V. (I think) provided the following code which seemed to work at the time but is not working now and indeed seems to make matters worse! To see the effect, run the game (http://play2.textadventures.co.uk/Play.aspx?id=m4a7-u7kyukbtvhaqtxq-g) and type PANES twice.

JS.eval ("var reHeight = 0;  $('#divOutput').children().each(function(){reHeight += $(this).height();});  $('#divOutput').css('min-height',reHeight);")

In experimenting, I also noticed for the first time that SAVE online no longer saves away the dialogue? I'm not sure when that came in, but seems an okay limitation, presumably to help with the timeout problem online?

This game, like my others, allows for the MAP, GAME PANES and HYPERLINKS to be switched on and off dynamically. The default setting is 'map on', 'links on' and 'panes off'. When resuming play after a SAVE, however, the panes appear! Is there a work around for this problem?

Same as any other javascript. When the player hides them, store this event in an attribute of the game. Then have your UI initialisation script check for this flag when a game is loaded, and hide things appropriately.

Is there a problem with the same checks being added to PLAY or at least to PUBLISH?

I think I remember Pixie toying with this notion, but decided that all that code was better left alone.

It seems like I remember lots of fellow forumers agreeing that authors (along with testers) should definitely be testing their games after editing them, and that they should most definitely test out the SAVE command.

(I'm not saying this wouldn't be nice, or that it wouldn't be logical, by the way. I just don't expect it's a change that will ever be made.)

In making the change, I also noticed that PUBLISH works on the last saved version of a game. So, if I go in in to make a minor change and don't save, no change will occur. Could PUBLISH check if changes have occurred in the open .aslx game and prompt for a save, or simply save and publish automatically?

This happens to me sometimes. I kick myself, saying, "argh! Curses! I must remember to click 'Save' before I do that!!!"

I don't think this change to Quest is likely, though. It's hard to explain why. Let's just say I have had Quest loaded in Visual Studio thousands of times, and I have seen how intricate it is (and one little change usually causes thousands of other errors).

(Again, I'm not saying your suggestion is anything other than good.)

This game, like my others, allows for the MAP, GAME PANES and HYPERLINKS to be switched on and off dynamically. The default setting is 'map on', 'links on' and 'panes off'. When resuming play after a SAVE, however, the panes appear! Is there a work around for this problem?

The User Interface Initialisation script runs when a new game begins and when a saved game is loaded. It sounds like you need to check for the attributes in that script.

In introducing dynamic game panes last May, it was discovered that there was a problem with white space calculation when the panes were taken out, and a large gap often appeared. K.V. (I think) provided the following code which seemed to work at the time but is not working now and indeed seems to make matters worse!

Curses!

This is probably because we changed the way the screen clears in 5.8.

Hrmm...

I'll have to research this one if no one else posts a solution soon. I have a lot of stuff to do today though, and I couldn't call the first place until this very moment. Now that this moment is here, I must begin dealing with bureaucrats.

What I'm saying is: if I happen to survive all the excitement of having dealt with boards and commissions all day, I probably still won't be clear-minded enough to code properly until the morrow.

Good luck, and happy gaming!

Thanks mrangel and K.V., restoring the panes, map and hyperlinks after a save is now sorted out. I'll wait to do the update, however, in the hope that K.V. can help with the white space problem as well! Greedy, I know!!

I'll just have to discipline myself on the other two issues!

This is probably because we changed the way the screen clears in 5.8

Yes, that seems to be problem. If I remove a ClearScreen from the initial opening scene the problem goes away...which is what I'll do for the moment.

I still can't figure out what the proper fix is.

It is either beyond my comprehension or I lack concentration. Probably the former.

Perhaps mrangel will have a solution...