There are none at all available!

Does anyone know if the message ‘There are none at all available!’ appear in response to anything other than TAKE ALL ?

-Wade

1 Like

A bit of information you surely will be interested in:
§6.15. Actions on Multiple Objects

2 Likes

I had seen that, but I was not getting the message ‘None at all available!’ in response to, say, DROP ALL – I was getting ‘What do you want to drop those things in?’. And this was when I was carrying nothing.

However, that’s in my WIP. if I go back to a vanilla project, then I do get ‘None at all available!’ in response to DROP ALL. So somewhere along the line my project has changed why/how it’s reacting to this. I’m not sure where to start looking because I haven’t rebuilt ‘drop’ myself, but then again I am using ‘Small kindnesses’ and ‘Extended Grammar’ and the revamped ‘Numbered Disambiguation Choices’ and other things I can imagine might be having this effect.

-Wade

I’ve put on TRACE 5 and the last thing that happens is it says ‘Grouped into 25 possibilities by name’ - then it lists 25 objects, including the contents of the room, and the directions (nsw etc.) and says ‘Unable to choose best group, so ask player’. And then it says ‘What do you want to drop those things in?’

-Wade

I’d suggest either starting a tiny little “Test game” and trying the extensions out one by one, or navigating to the folder where your extensions are, opening the relevant ones in a text editor and searching for the phrase “What do you want to drop those things in?”

1 Like

Unless I’m misunderstanding something, this is a known bug or rather a quirk of Inform 7.
http://inform7.com/mantis/view.php?id=1720

I used an ugly hack in Counterfeit Monkey to avoid this, basically adding the player to the multiple object list as a kind of dummy object which is then removed later, printing a custom message if the list now is empty. I’m sure there are better ways.

2 Likes

Thanks everyone for your pointers and suggestions, and thanks Angst for pointing me to this bug.

-Wade

1 Like

@Angstsmurf , Sorry, I’m still pretty confused about this whole bug and possible fixes.

I can’t work out what the scope/circumstances of the bug is. For instance on the bug tracker example, a rule specifically excludes a coin. Is that exclusion the only problem? Or is there a permanent issue with the player being excluded because they’re a person, and a rule always tries to exclude people? And that brings about the bug? I mean, what set of objects must be left in the multiple object list (or are not allowed to be in it) to prevent the bug (or quirk, if someone prefers) occurring?

The reason I haven’t been able to tease all this out is because at different parts of my game, sometimes it goes straight to ‘There are none available,’ when DROP ALL is typed, seeming to skip any multiple action processing rule(s) (they don’t show up in a rule trace). At other times the action processing rule kicks in, but in one part of the game, the player can and will drop all, and in another, the objects they’re wearing don’t seem to be being considered by the game. And I have no rules excluding them, so I don’t know why.

But setting aside any specific weirdnesses in my game that I might not have found yet (if they exist!..) I guess I need to be able to understand the fundament of the problem in order to be able to react properly.

-Wade

Yeah, sorry, that was probably more confusing than helpful.

Just to clarify, the code I cited from Counterfeit Monkey is a dumb workaround, and I can’t remember exactly why I decided to do it this way, except that I tried a lot of things and this worked.

It basically makes sure that the multiple object list is never empty when dropping, by including the player object in it. That is what the line Rule for deciding whether all includes the person asked while dropping does. Then we remove the player from the list again in a multiple action processing rule, and print a custom message if it was the only thing in the list

In this way, we completely bypass the parser’s buggy handling of DROP ALL when there is nothing to drop, because we make the parser think that there is always something to drop.

The actual bug has nothing to do with the player object, I only used that because it is a convenient dummy object that is usually in scope.

Dumb or no, it’s now working for me, too :wink:

Thanks, this explanation cleared up the problem. I also had to discover that worn items are excluded from ALL at a really low level in Inform, as discussed in the following topic: are worn things automatically removed from "all"? … I’m glad I found it, because this secret behaviour was dooming all my rule-based debug attempts to failure.

-Wade