Strange idea: would it be possible to store a value in such a way that it would not be reverted by the UNDO command? As in, you perform an action that increases a value from 0 to 1, immediately UNDO the action, but the value stays as 1 so that if you perform the action again, it’ll go to 2 instead and so on.
I won’t go into detail, but there would be a logical reason for this within the game; it wouldn’t just be me screwing with players for shits and giggles.
Ok, it wouldn’t be ENTIRELY me screwing with players for shits and giggles.
In the Library Reference Manual, under All Symbols, choose the index for ‘I’ and investigate includeInUndo. I haven’t tried this to see how it would work, but it seems to me you could probably customize any action so that the value of includeInUndo was returned by a method rather than simply being set to true or nil.
IncludeInUndo is just a flag on Action class telling whatever to create savepoint for undo or not. But what you are looking for is a chapter “Persistent and transient objects” at the bottom of http://www.tads.org/t3doc/doc/sysman/objdef.htm. Just pay an attention that transient objects are also not saved.
Hmm… I solved the part about transient objects not being saved by copying the value stored in the transient object onto a persistent object at one point. It’s clumsy since there are brief moments in which the transient and persistent values differ, but it’s nothing that would cause problems and is enough for what I want to do.
I did have to muck around with doRestartGame() to stop the transient value from surviving a restartGame() command though. I generally don’t like messing with TADS’ guts that deep though…
But TADS is so throughtfully designed to allow you to mess with this stuff with ease Anyway you may also look on InitObject and PreinitObject classes for more convenient way to run code on start and after restart: http://www.tads.org/t3doc/doc/sysman/init.htm