Inform best practices mud wrestling: ‘undescribed’

Authoring Inform 7
41

The “can’t take what’s fixed in place” rule already covers this case. We don’t need both rules.

If we want to be backwards compatible, we could just vary the message depending on whether the fixed-in-place object also has scenery.

2 Likes
42

With far fewer changes than you might expect, I have something that has eliminated described/undescribed/the I6 concealed attribute altogether and other than where you’d expect (references to the can’t take scenery rule, uses of described/undescribed) passes the I7 test suite.

It should be the case that the functionality desired in Case 1, above, can be achieved by making things scenery and the things in Case 2 by making things concealed (I7-concealed). Case 3 isn’t relevant: it’s taken care of.

The code’s overall simpler and a little shorter.

1 Like
43

Nice.

So (in your scheme) the I7 concealed flag means both unscopable and unmentioned in listings?

44

Yup, the consequences of concealment are unchanged: not mentioned, not in scope.

45

Can a concealed thing still be targetted by e.g. a bare GET?

46

nope, if the only thing present is concealed, a bare get will try to get yourself (just like if there were really nothing there).

47

committed it to my repo if anyone wants to see the diff.

2 Likes
48

@severedhand: Before you start to worry about losing the functionality that you like, it should be possible to get it another way that’s pretty simple.

A thing can be hidden.

[This is wrong; see below.]
Rule for choosing notable locale objects for a room (called R):
	repeat with item running through hidden things in R:
		set the locale priority of the item to 0.

Then you can use hidden/not hidden just like you would described/undescribed.

EDIT: No, that’s wrong. A little better…

A thing can be hidden.

For choosing notable locale objects (this is the revised notable locale objects rule):
	let the domain be the parameter-object;
	let the held item be the first thing held by the domain;
	while the held item is a thing:
		if the held item is hidden:
			set the locale priority of the held item to 0;
		otherwise:
			set the locale priority of the held item to 5;
		now the held item is the next thing held after the held item;
	continue the activity.

The revised notable locale objects rule is listed instead of the standard notable locale objects rule in the for choosing notable locale objects rules.

First Before doing something:
	now noun part of the current action is not hidden;
	now second noun part of the current action is not hidden.

EDIT 2: Second version improved courtesy of @Dannii; see below.

1 Like
49

Thanks for the thoughtfulness! While it is mildly disturbing to have people devising a new spec after you said it works fine for you, I also figured that any change would appear in – current Inform? And I won’t be out of my WIP in 6M62 for a long time yet. I will be ready for lots of changes when I do move to current Inform.

-Wade

50

Pace, Wade. I’d already abandoned throwing that use case under the bus before you spoke up, all this is just spitballing – so far as I know, no one’s mentioned it to Graham and I feel sure he’d call for an inform-evolution proposal if he thought it worth considering, and your use case should continue to be handled by calling things scenery instead of undescribed even if something like this scheme were pursued.

1 Like
51

Hmmm. Getting weirder: we could probably skip separate tests for “or if the item is the player” by… making the player scenery.

52

Better to check the variable because the player character can change.

A micro-optimisation is that you shouldn’t need to check if it’s hidden, just set not hidden. However if the now phrase might complain if the noun part is nothing then you might need to check if it’s a thing. I don’t remember if that’s the case or not.

53

But ChangePlayer can maintain player has scenery just like it maintains player has concealed today.

1 Like
54

Ah, I guess it wouldn’t matter then. Just whichever is conceptually clearer. If you can avoid multiple checks setting player to scenery makes sense. If it’s only tested in one or two places then it might be better to just check the player variable.

55

I was kind of hoping to get rid of those lines in ChangePlayer(). Just one fewer thing that can go wrong.

1 Like
56

I was thinking of it as the lesser of two evils… rather than needing to remember scenery or player in all sorts of places, two lines of code in the one routine that can reassign player takes care of it. That’s why I went back and tried player as scenery.

A don’t-mention-it function to use in place of asking scenery-or-player would be another approach.