reset (select) ?

Authoring Dialog
1

is there any way to “reset” a (select), that is, manually force it to start over at the first branch?

i’m thinking this is a compiler thing and not a dialog thing, but just asking.

2

Unfortunately not. There’s no technical reason it couldn’t be done—under the hood, there’s a byte of memory where each (select) block holds its state, and that byte could be zeroed out to go back to the beginning—but the language currently offers no means to do that.

1 Like
3

As far as adding the capability—the problem is, there’s no real way to reference a particular (select) statement in Dialog syntax, and I can’t think of a good way to add one. One could imagine a (reset) builtin that resets whichever (select) it’s inside of, but you’d mostly want to do this outside the (select), which means needing some way to choose the appropriate one.

For now, the best way to do this is to basically reimplement the (select) behavior with your own global variable.

4

yeah, sounds like more trouble than it’d be worth. the functionality isn’t hard to reproduce “manually”. i was just curious since (select) is so freaking convenient.

5

It really is! And if you think of a nice way for it to work syntactically, it wouldn’t be hard to add to the language. But part of the convenience of (select) is not needing to keep track of labels for them, and I don’t want to lose that.

1 Like
6

Something like this?

    (select #wotsit)  %% optional id
    ...
    (or)
    ...
    (cycling)

    %% elsewhere
    (reset select #wotsit)
7

That would be doable, yeah! Perhaps also a way to access the most recent value of it (the most recent branch printed), but that risks exposing too many implementation details and causing problems for future development.

At that point, there are two ways to handle this:

  • The ID works like a style class ID, in that it has to be a compile-time constant, converted to the appropriate select address when compiling
  • The ID works like a resource ID, in that it can be any sort of value, and the appropriate select address is looked up at runtime

The former is much easier to implement, and I suspect will be enough in most situations.

8

Yeah.

You might want three operations:

  • reset to beginning
  • pause/stop
  • restart a paused select
9

The first one sounds much simpler to reason about and also like it would produce much simpler (Z-machine/Å-machine) code. Is there an obvious use case for the second thing that’s common enough to be worth the marginal benefit of not having to write your own logic for it?

1 Like
10

Not that I can think of, honestly! It would be much nicer to have non-constants for style classes, but that’s built into the structure of the Å-machine at this point.

I can see the use cases for all of them, but at the same time the goal of Dialog is to stay light and elegant wherever possible, so I don’t want to add too much complexity.

1 Like
11

What would pausing a select even do?

12

I think the intent is to keep it from advancing, basically freezing its current value in place and not letting it change.

13

Never update its state so it would always go to the same branch? Not sure about the at random ones, though.

Wouldn’t adding labels to selects also help with the debugger? It would allow it to remember their state between modifications and not reset them.

But all in all I don’t think this feature is worth that much, because it’s easy to make your own version if needed, even if it’s less ergonomic.

14

It would potentially help with the debugger, but the debugger currently has a staggering amount of logic to figure out on its own which (select)s correspond to one another, and I’m afraid to even touch it!