Some after-every-turn rules

I’ve got a big chunk of important processing that needs to happen every turn.

It has to happen after any and all every turn rules have happened. You might say ‘Well, then make it the last every turn rule.’ But then it doesn’t happen at just before the prompt appears when you boot game, and it needs to happen then, too.

Attempting to hack that last situation (run it just once at the end of the first ‘move’) hasn’t been working out, mostly because I find it hard to identify the perfect moment, even with ‘rules all’.

Anyone have some advice on what/how I should do this? Thanks.


PS - I thought I’d throw in that I did try placing the code right at the start of the command prompt displaying section. Which made it work better than everything else so far, except that if input is called for out of turn, then everything bombs. I then thought ‘I could put in a flag to bookend that section, which would only allow this code to run on certain passes!’ - but that’s classic hackery of the kind I’m trying to avoid here.


Does it need to not happen on parser errors/meta actions? If you don’t care, then you could make it the first of the turn sequence rules.

If you do care, then can you just run it as the last of the start up rules in addition to the last of the every turn rules?

So to add as the last start up rule, do I just say?

Last startup rule:
do important stuff


EDIT: I tried the last startup and last every turn combo, and it was close, but if you undo, the process doesn’t go off for the turn you undid back to, thus freezing things up.

EDITEDIT: I threw in a manual run after an undo, which seems to have got it going again, but I still feel a bit fragile.


This sounds like you are doing something else strange. The basic concept is correct:

The Kitchen is a room.
The player carries a rock.

The counter is initially zero.

Last every turn:
	increment counter;
	say "Counter is [counter]."

Last startup rule:
	increment counter;
	say "Counter is (initially) [counter]."

The catch (for what I need) is that in your example, you don’t see the message ‘Counter is 2’ reappear after you undo. Whereas, that’s what I need. It’s about the value of what appears on the screen, plus unfortunately I have to bind the processing that generates what appears on the screen to the printing of it at that incredibly late stage in the turn. So both things need to happen or the wheels fall off.

Btw, I have so far got it working with Dannii’s last startup / every turn combo, plus I manually run the process once after an undo.

The longer explanation - this is for the CYOA extension. Weaving the appearance of choices in with the output of the regular world model has proven to be the hardest part of this project. The main mechanism is wrapped around ‘look’, so I do need to ‘look’ every turn when in CYOA mode.

I’ve created ways the author can auto-generate choices. EG If you want to have ‘examine (blah)’ appear for all things in a room, and you want those at the top of the choices in that room, you use a ‘before preparing choices’ rule which generates those Examines. Originally, the processing and printing of this was happening in the tail-end of ‘looking’.

What I realised the other day in testing is that if characters and other things are moving around at the every turn stage, the automatically generated choices don’t catch them. So an auto-examine for a person might be generated during ‘look’, then the person walks out of the room at the every turn stage, then you’re left with a choice that shouldn’t be there.

For this reason I had to move both the generation of the automatic and main choices, and printing them out, to after the every turn stage.


Why not use a “before reading a command” rule to tie it to the prompt appearing?

I may reinvestigate that idea. Some of the mechanisms in that vicinity behave differently under Glulx Unified Input, which I’m using.


If you are mucking around with input choices, it is definitely better to work with the reading-a-command activity rather than trying to work with actions or turns. A given player input may result in zero, one, or several turns.

(Or, with UGI, one of its rulebooks – maybe prompt displaying. Hm. Reading a command seems more sensible, but you’ll have to try it.)

I don’t understand the part about several turns? And you’re talking about in Inform generally there, right? Not just in UGI.

My attempt at all this, before I made this thread, was to put The Process at the start of prompt-displaying in UGI. But then things would go nuts if I detoured to call for input in a different context during the turn. That informed my earlier anecdote in this thread about ‘maybe I could set up a flag’, etc.

(I won’t entirely rule out that there was some other problem when it went nuts. Changing lots of things at the same time…)

That said, my plan now is to try putting it at the start of ‘Reading a command’.


It might not matter with your CYOA extension, but IIRC disambiguation prompts don’t run “Before reading a command” rules (though they do run “After reading a command” rules).

If I ever create a CYOA game which asks the player to disambiguate the specific choice they just chose, I will credit you with the idea, Matt. I would do such a thing either for comedic reasons or because I want to earn a special place in hell.


I may have managed to make A Colder Light do that once.

Seriously, I’m guessing that whatever you’re doing with Unified Glulx Input bypasses NounDomain completely? IIRC that’s where disambiguation gets run from. If not, well, never underestimate the ability of authors to mess stuff up using your extension.

An actually helpful suggestion here might be to look at whether “If the player consents” messes you up–I could imagine an author writing a routine to make “If the player consents” display links for yes/no, and from a quick scan of the UGI input it looks like that wouldn’t call “before reading a command.” But it might not matter.

Also, when you do release the extension I will probably be trying to see if I can manage to wedge a disambiguation into it myself.


Well, when you made your post, I sat back and tried to think how disambiguation could happen.

I decided it can’t happen as a result of automatically generated choices. If it repeats through a bunch of objects and attaches an action to each one, the actions and objects are linked at a level below the parser.

It can happen by author programming. If I have a red cup and a blue cup in my game, and I just 'link taking cup to ‘Get the cup’, well there’s your possible disambiguation cue.

I’m going to advise people to avoid this. You can avoid it by using sufficiently specific object names behind the scenes. (eg link taking blue cup to ‘get the cup’ - or to ‘get the blue cup’, depending on the situation) And this structure I just quoted is an author-directed one. Disambiguation tends to happen in unexpected circumstances, and the autogenerated actions are usually the ones that will be dealing with unexpected circumstances.

So I see it as something that could happen, and which you can easily make happen if you want (“wedge away!”) but which is, overall, easily avoided.

Player consenting… thanks for the reminder. I need to write a routine to do that with links. This being a Glulx Unified Input project, the great mercy is you don’t have to run everything through the same input loop. The different contexts you can create can keep things well apart from each other. I’m really grateful for this because it’s far more the way my brain works.


Oh, well I’m not going to do it if it’s easy. That’s no fun.