Hi Eric! I did not do any testing on this myself; I was only trying to address a voiced need… and I’m happy to hear that “more” indeed works within action(), which I believed must be the case, which is why I sounded so incredulous that a Fuse would be a necessary fix!
As far as start(), that seems puzzling since it is only two simple assignments in addition to whenStarting()… seems puzzling that that method in particular would be responsible. I may try to set up the Lite library on my computer for the first time a test a few things myself.
Depending on how we define “manually”, I think scenes aren’t really meant to be triggered directly that way.
The standard way is indirect: we define a startsWhen
property and then alter the game state such that the condition expressed in that property becomes true.
From the adv3Lite Tutorial:
A Scene begins when its startsWhen property evaluates to true, and ends when its endsWhen property becomes true. When the Scene starts its whenStarting method is invoked, and when it ends its whenEnding method is invoked.
Example:
myScene: Scene
startsWhen = (me.isIn(throneRoom))
whenStarting()
{
king.moveInto(throneRoom);
"The door opens and a man stomps into the room behind you.
You suddenly find yourself in the presence of the king! ";
}
...
;
I meant maually triggering the scene as in triggering it somewhere else in the code directly, because the condition I want to initiate the scene on isn’t the kind of thing that I can just put in a property. I want to trigger the scene when the player attempts an action (unlocking a door) and fails.
I take your point; it does seem puzzling, but as StJohnLimbo points out in the previous post, Scenes are not meant to be started manually like this, but to be started and ended by library code when their startsWhen/endsWhen properties become true, so it’s possible that trying to start a Scene manually from within action handling causes weird side-effects (given that the Scene class was not designed to be used this way). But you may be right that this isn’t the culprit, in which case it must be something else about alexispurslane’s particular code (which may or may not be triggering an obscure library bug).
As noted above, Scenes aren’t meant to be started manually in this way at all (the Scene class wasn’t designed to be used that way). To use the Scene class as it was designed to be used your action() method would need to change the game state in a way that would make the Scene’s startWhen condition become true.
So, in default of any other condition that makes StartsWhen become true, in outline, you could use a coding pattern like the following:
action()
{
myScene.startsWhen = true
// do other stuff
}
...
myScene: Scene
startsWhen = nil
whenStartting()
{
// whatever
}
;
Provided that there was no other condition that might start the scene (in which case you’d need a more indirect coding pattern). The Scene manager would then start the scene at the appropriate point in the turn cycle following the handling of the actor’s action.
Whether calling start()n directly is the cause of the problems you encountered, I’m not sure (as I say just above), but I’m afraid there’s always the risk of breaking something it you use something (in this case a Scene) in a way it wasn’t designed to be used.
Alright, that makes sense, thank you! As I was reading your post it occured to me that I could set a flag to trigger the startsWhen property on the scene, so it’s good to see you confirming that’d work. It’s simpler and more straightforward than what I’m doing now, so I’ll switch over.
Well… @alexispurslane , I called scene.start
from an actionDobjFor
, pasted your original whenStarting
into the scene
, and all pauses worked as they should! Perhaps something particular to your codebase has caused this issue?
[Oh, yes, that’s right, folks… I’ve finally installed and set up a dummy/test adv3Lite game on my computer after four years of TADSing!]
Huh, now that’s truly weird… I’m working on something else right now, but let me get back to you.
@Eric_Eve @inventor200 @alexispurslane @StJohnLimbo
For those interested, here’s a little light on calling scene.start
. Scenes are just Events that the eventManager calls once each turn… all Actors go first, Scenes go next, Fuses and Daemons next, and PromptDaemons last of all.
There’s nothing inherently dangerous about calling scene.start
from action
… the eventManager simply calls start
on the Scene’s turn if its condition passes (otherwise it looks for an ending condition, or gives it an eachTurn
). Perhaps the only funniness to watch out for would be if you define an eachTurn
on the Scene. In that case, if you call start
from PC code, whenStarting
will fire immediately, but the eventManager will still give that Scene its turn (unless you suspend it for a turn), and since the Scene will already be registered as having started, it will take an eachTurn
on the same turn that whenStarting
showed.
This may or may not be a problem, but if it’s understood, there should be no reason not to call start
from the PC’s turn if it achieves something specific you’re trying to do.
EDIT: notice that if you want whenStarting
to appear to be an immediate consequence of the PC’s turn, you may not get this result unless you call start
from action
. Because otherwise, other NPCs get to run before the Scene fires up, and they might belch out some droll inanities that break up the tension that’s supposed to result from the scene change (unless, with another approach, you suspend all other NPCs for the remainder of that turn, a la @inventor200 )… (none of the above tested, but it seems that’s the way the mechanics work)
Thanks for carrying out and explaining this analysis, which all looks correct to me (although, as you say, it leaves unanswered the question why @alexispurslane was experiencing difficulties with pause for more).
Another approach would be to have your action method display the scene starting text rather than leaving it to the scene’s whenStarting() method to do so, although that would only work if the scene in question is only triggered by the action in question.