If an author has coded both an easier more and more challenging mode into their game, they could definitely use this system for switching between the two. There isn't much I could do just on the library side alone except possibly have it take away ease-of-use features like automatically unlocking doors when trying to walk through a door for which the player has the key.

I don't think I'll add the "klepto" mode because Roodylib's default isn't that much different from the old behavior. The main difference is that it won't try to pick up other characters, and I feel like players like >GET ALL mostly for how it lists all of the miscellaneous objects and there isn't really much I can do to affect it listing more or less of those.

Possibly a toggle fron novice to more challenging? I use GET ALL in most rooms, but only after I read all the text. It eliminates repeat typing and sometimes it finds stuff I didn't see the first time through.

option list_displays
{
	name
	{
		if (FORMAT & LIST_F)
			return "Tall or wide inventory listings (Current setting: tall)"
		else
			return "Tall or wide inventory listings (Current setting: wide)"
	}
	in config_menu
	is option_toggle
	toggle_code
	{
		if (FORMAT & LIST_F)
			FORMAT = FORMAT & ~LIST_F
		else
			FORMAT = FORMAT | LIST_F
	}
}

#ifclear NO_MODE_CHANGE
option verbosity_level
{
	name
	{
		select verbosity
			case 0 : return "Room verbosity (Current setting: brief)"
			case 1 : return "Room verbosity (Current setting: superbrief)"
			case 2 : return "Room verbosity (Current setting: verbose)"
	}
	in config_menu
	is option_toggle
	toggle_code
	{
		select verbosity
			case 0 : verbosity = 1
			case 2 : verbosity = 0
			case else : verbosity = 2
	}
}
#endif

I was going to upload a new Roodylib release today, but then I remembered I hadn't added that "configuration menu" idea to newmenu.h yet.

Anyhow, I put something together and this is what it looks like:
[url]https://photos.app.goo.gl/UYpGZbm5A8caZy9n7[/url]

Here is what the toggle code on the author side looks like (for authors that want to add their own options):
[code]option list_displays
{
name
{
if (FORMAT & LIST_F)
return "Tall or wide inventory listings (Current setting: tall)"
else
return "Tall or wide inventory listings (Current setting: wide)"
}
in config_menu
is option_toggle
toggle_code
{
if (FORMAT & LIST_F)
FORMAT = FORMAT & ~LIST_F
else
FORMAT = FORMAT | LIST_F
}
}

#ifclear NO_MODE_CHANGE
option verbosity_level
{
name
{
select verbosity
case 0 : return "Room verbosity (Current setting: brief)"
case 1 : return "Room verbosity (Current setting: superbrief)"
case 2 : return "Room verbosity (Current setting: verbose)"
}
in config_menu
is option_toggle
toggle_code
{
select verbosity
case 0 : verbosity = 1
case 2 : verbosity = 0
case else : verbosity = 2
}
}
#endif[/code]

Since the configuration menu is a menu page, an author could set up a "config" command to MakeMenu(config_menu) directly if they wished.

The main intent of Roodylib's default menu is that authors will edit it to fit their game, but if anyone has any opinions on the wording I used, I'd be happy to hear it.

Ok, if anyone predicted that this saga wasn't over, you were right. I did finally find a way for a character's belongings to show up in >GET ALL.

I remembered that I wanted to test my scenario with Hugofix's FindObject and Parser monitoring turned on. What I eventually discovered is that if the parent object (character or not) has a true exclude_from_all property, >GET ALL successfully proceeds to trying to pick up all of its children. If the parent object doesn't have a true exclude_from_property, after the >GET ALL message is done for the parent (successful or not), the code won't bother to do anything with the children.

So, this is good to know if you have objects that you explicitly want to be available to >GET ALL. Say, for instance, your game has some objects on a coffee table. You'd want the player to be able to pick up whatever he sees without having to type >GET ALL FROM COFFEE TABLE. So, in this case, you would make sure the coffee table itself has a true exclude_from_all property.

I think what we've learned here today is more useful to authors than it is applicable to a hypothetical kleptomania mode.

I forgot to say that I haven't been able to replicate that trying-to-grab-stuff-that-characters-are-holding behavior at all, even with the original IF Archive upload of Spur. So it's possible that in the time after Kent added that fix to Future Boy! library-side, he hard-coded the behavior engine-side (since there has been at least one round of official interpreters since Future Boy! was released).

So, it's probably unwise to let >GET ALL apply to hidden objects and we can't have it apply to objects characters are holding, so that just leaves the option of >GET ALL applying to the characters themselves. Which is more of a case of being handsy than klepto.

Well, this idea is turning out to be a total bust. Even though Roodylib has that code borrowed from Future Boy! that disallows >GET ALL applying to objects held by other characters, even if I compile without Roodylib with the official library, >GET ALL still doesn't end up trying to pick up anything held by another character (making one wonder why Future Boy! needed that code in the first place).

In my test code, the character Sam has a ham. The ham is successfully run through FindObject (returning true), and when Perform is called, it says there is a queue. Sam gets the "Sam: You can't pick that up." treatment but then it totally drops the ball and just stops after that.

It's starting to look like this idea isn't very worthwhile. The configuration menu is still a good idea, but it'd be best if we could think of some other useful settings to toggle so it's not just one or two options.

Nevermind. I've been testing with Spur since that's the game that brought this whole idea up, but there are differences between the source code that Kent uploaded to the IF Archive and the version of Spur uploaded there. So the object I was expecting to see because it shows up in >GET ALL in the original wasn't showing up because it *does* have the hidden attribute so even the non-Roodylib modern library will always skip it.

Ok, it turns out that >GET ALL is already broken in current versions of Roodylib, skipping some items for no reason that I can see. So I'm first going to have to track this bug down before I can adjust any of these other things. Annoying, but I'm glad this came to light.

Well, looking at the code again, this is a little trickier than I first imagined. Historically, all hidden objects (which includes scenery) have always been excluded from >GET ALL. Changing this has possibility of being game-breaking if an author has a fake object in the room just for scope purposes (and using the found_in system doesn't work with whatever verb they are trying to catch). I'm not sure I want to open Pandora's Box here.

So, the main differences in Roodylib's modern >GET ALL and the old Hugo library behavior is that it borrow's Future Boy!'s code which excludes objects held by other characters (while >GET ALL FROM <npc> still works). Hugo's default handling of friendly characters is to let the player just take whatever they want from them, which I feel is probably not the author's intention in many cases, but it's easier to add code to disallow it than it is to add code that allows it when the default is that you can't. So, my point is, "klepto" mode would bring more attention to that issue, but hey, maybe it's a good thing if authors see the effects of that more often.

Roodylib also automatically excludes trying to pick up other characters with >GET ALL.

Maybe I'll have klepto mode apply to characters and their belongings to begin with.

That's an interesting idea.

Out of the box, a generic game compiled with Roodylib has these options that could be conceivably toggled:
1. Verbosity
2. Display wide/tall (affects how things like inventory lists are written, but I've always assumed that basically no one ever uses this one)

And my accessibility additions:
3. Cheap mode on/off (prints text in a way that aims to be friendliest to screen readers and simple interpreters that do not do menus properly)
4. Clearscreen off (an option to block the clearing of the screen, for interpreters that can't do an actual screen clear)

Considering that half of the options are accessibility ones, I'd probably be more inclined to have the config menu be similar to the Hugofix menu I have pop up at the start of a game compiled with Roodylib, as the accessible and non-accessible versions are pretty similar (and wouldn't look super crazy if it were to jump from one to the other mid-menu). Anyhow, that would mean that arrow keys would not be used but options would be turned on and off by numerical keypress.

Of course, I'd try to design it in a way to make it as simple for authors to add additional options if their games require them.

If we really want to go the control-by-arrows route, I could add a configuration page to the newmenu extension so that anyone who uses that always has it by default. I probably would not include the accessibility toggles with that approach since those commands will also be listed under the "special commands" menu.

Hmm, maybe that is the better idea.

No, but, allow me to suggest a sort of Roodylib menu with settings that a user can toggle for this stuff. Having verbs for it is totally fine, but it'd also be cool and useful to do something like >config and then have the various ..................... options pop up, letting the player use the arrow keys to turn things on and off.

For an example of how not to create a menu of toggles, allow me to find some screenshots of everything Apple and Microsoft have done in the last 20 years.

Well, it doesn't take much to convince me so, yeah, I think I'll put this into the next release. I'm also thinking that maybe >KLEPTO ON/OFF might be a better command for it, as I don't like forcing "old school" into one word and it isn't self-explanatory enough in its usage.

Is KLEPTO too gauche, though?

I am a huge fan of "GET ALL" or anything"ALL" just spitting out a slew of text that interacted with all sorts of things. If someone prefers the alternative I can see how that might be cool for other flavors of games. However, my favorite is when listing everything it's cool to have different things specified while listing..

To me the natural flow is:

UNDERNEATH PUMP HOUSE

You are standing in the drainage pit underneath the pump house. Various objects are scattered on the floor and shelves. Sam the plumber is here.

TAKE ALL:

Screwdriver: Talen.
Sam: They step and protest; "Get your hands off me!"
Vice: That's too heavy.
Tube of Sika-Flex: Upon picking it up, you notice it is empty.
Wine vat filled with dead people: That's too heavy. Also, what is wrong with you?

Earlier this year, I chatted with an IF-loving fellow who hadn't played any Hugo games. I put together a handful of games that I felt represented the system well. One of them was my personally updated version of Spur which has some quality-of-life improvements like being able to follow the kid who runs around town on a script and other things.

The guy quickly found a bug in my version (although it was due to a change in the Hugo library over the years and not Roodylib's fault), so he started the game again with the original file uploaded to the ifarchive. Anyhow, he noticed the different behaviors to >GET ALL (Roodylib ignores scenery objects and characters and such while the old behavior lists everything, which a bunch of "You can't pick that up.") and thought it also was a bug.

Now, of course, Roodylib's behavior is intentional as I think it makes a game feel shoddier when you read all of those "You can't pick that up"s, but I have some sympathy for the strategy of using >GET ALL as a tool for seeing what [i]is[/i] implemented in a room, even if the player doesn't really intend to pick most of these things up. This is especially useful in puzzle-heavy games or just games where it's easy to lose track of what's important in any given room description. It ruins the magic, but sometimes people feel more comfortable when they can peek behind the curtain.

I would not consider making the old behavior the default behavior, but I think I would be open to having Roodylib provide a command that allows for switching between the two. I'm thinking something like >OLDSCHOOL ON/OFF but maybe you guys can think of something less awkward. Of course, I'd add a flag to the code so authors could turn off this behavior switch completely for their game.

What do you all think about this? And if you like it, should >OLDSCHOOL ON/OFF affect any other behaviors? I kind of doubt there are other old school behaviors equally useful, but maybe you can think of something where I cannot.