Every parser game I've ever played which had a transcript feature worked like this:

- When play begins, the transcript is disabled.

- The player must enter TRANSCRIPT or SCRIPT to enable the transcript.

Now, I remember the 80s, and, in the 80s, each time text printed to the screen with the transcript enabled, that very same text printed to the page loaded in your printer.

Nowadays, when interacting with fiction on a laptop or desktop, instead of printing to paper, a .txt file is created, and each line of text is appended to that file as it prints to the screen during play. When enabling the transcript, the game asks for a file name (with the game name preloaded by default). If this file exists, everything is appended to it. If not, the file is created, then (you guessed it) everything is appended to it.

When playing games in modern browser via the Quixe interpreter (which is what runs Glulx games), the transcript is saved to the browser's local storage. (They say you have to do a little work in your browser's developer console to get to the transcript when playing in your browser, though. I've never tried.)

- Once the transcript is enabled, the player must enter TRANSCRIPT OFF or SCRIPT OFF to disable it.

The Point

The next version of Quest will have a transcript feature.

Everyone thinks it should behave just like transcripts in all the other parser games, right?

I only ask because we have two main ways to handle it.

1. The old way. The transcript only records after the player has entered the command to disable it.

With this setup, an author could set game.notranscript to 'True' to disable the transcript features.

The player has the same commands they have had since the 1980s. They can start and stop the transcript themselves at any point during play.

2. Option B, where there is always access to every line of text which has printed (even what has been cleared), starting from the title (if it prints in the game).

If we did it this way, an author could still set game.disabletranscript to 'True', but the player would have no control over what was included, which is the norm.

Either way, entering VIEW TRANSCRIPT will show the transcript's contents in a dialog popup during play, unless it is disabled, in which case it will print, "there is no transcript feature in this story."

The popup will have a 'Print' button, which allows the player to print to paper or print to a PDF file (if their system is set up do print to PDF).

I am so tired of not being able to edit my posts...

So... transcript on will print to screen and print to game.txt file???
Sounds like a good way to record an adventure...
As an interim...
Print to screen and Transcript=Transcript + (what was printed to screen)
At game over:
open "Game.txt"
print Transcript
close "Game.txt"
(Or however the save to text file works...)

Hrmm?

Are you wanting Quest to open the text document when play ends?

The way I would do it in Basic...
save the game text in a variable as you play, in this case, Transcript... Or, more than likely: Game (or player).Transcript...
When the game is over...
open "Game.txt" for output as #1
print #1, Transcript
close #1
this way, the file is only opened, saved to, then closed at just one time...
If a file is open and the game is printing one line at a time as you play...
An OOPS can corrupt the file and make it unreadable and therefore loosing everything.
(Ding...)

Aargh!!!

You guys can find my crazy code and ideas on my QuestStuff wiki on GitHub, where I can edit my posts when I mess something up, which happens quite frequently... Syntax errors, typos... Stuff like that.

https://github.com/KVonGit/QuestStuff/wiki

save the game text in a variable as you play, in this case, Transcript... Or, more than likely: Game (or player).Transcript...
When the game is over...
open "Game.txt" for output as #1
print #1, Transcript
close #1
this way, the file is only opened, saved to, then closed at just one time...
If a file is open and the game is printing one line at a time as you play...
An OOPS can corrupt the file and make it unreadable and therefore loosing everything.

Okay, this would be OPTION 1.

With Option 1, the player would have to enable the transcript to record anything and disable it to stop recording. Usually this wouldn't be to print the entire transcript. It would be for beta-testing purposes.

Also, appending each line to the file as the text is printed to the screens seems like it avoids possible errors. Like if the game always messes up at a certain point, the transcript would be intact up until that point, but what you foresee could also happen just as easily...

Hrmm...

Option 1 is the way it has worked since the mid eighties. That's why I feel it would be the best way to go.

Option 2 does not save to the hard drive at all. The clearScreen() function is modified to hide the cleared text rather than removing it. If you enter SHOW SCRIPT, the dialog popup simply displays all the text that has been printed during play, and the player has the option to press 'Print' to print to paper or save to a PDF.

Option 1 only records text when commanded to do so, while option 2 will always grant the player access to the entire game's text.

And option 1 is the only one that saves to a local file. It would be pointless to do so with option 2, since the text is always accessible.

If you'd like to automatically record the entire transcript from the first line of text, set game.savetranscript to true.

If you'd like the transcript to display when play ends, in the script(s) where you put finish, add JS.showTranscript().

...but with Option 2, it looks better. All the text is intact, and it is saved without having to worry about it...

Also note that you can't modify Quest to make it save to a local file without building from the source code.

If we go with Option 1 (appending each section of text output to .txt file as it prints to the screen, which is what I vote for), this could easily be disabled by setting game.notranscript to true. Then anyone can set up Option 2 by adding a simple library (or coding it themselves, but I've already got that code; in fact, it's in Quest580beta2 right now).