If you're like me, you owe a lot to previous coders like Pixie and Mrangel et al for coming up with great innovations and libraries, then sharing them with us. Many of these great innovations include having rooms "outside the game" for storing stuff, making weather, having conversations, etc.

But then if you go to get a list of AllRooms for some reason, they all show up. One easy example is K.V.'s "Real XYZZY" posted years ago below. Super useful bit of Zork ingenuity for testing out your game and being able to go anywhere instantly.

Do you really want your player to see all those rooms in the teleport list while you're testing out your game? Does he have to go to "x_shopinventory" or "Kobold_conversations"?

So I decided to type all these rooms and call them "gamestorage"

type name="gamestorage">
descprefix type="string">
objectslistprefix>storing
dark />
exitslistprefix type="string">
gamestorageme type="script">
list add (game.gamestorage, this)
/gamestorageme>
attr name="grid_fill">Black
usedefaultprefix type="boolean">false
attr name="grid_label">{this.name}
/type>

And you can see in there that the new type has a convenient script attribute to add it to the gamestorage list if called. It's named gamestorageme. It's part of an older idea I had, before I saw I could filter the lists by type. Maybe it can still prove useful for random room generation or something.

I added this in the Game's start script:

game.gamestorage = NewObjectList()
foreach (obj, FilterByType (AllRooms(), "gamestorage")) {
list add (game.gamestorage, obj)
}

So now, modifying the XYZZY command can exclude the gamestorage type from the rooms list!

Now that I can do this, I'm wondering if it can be used to filter "noise" from some of the library dropdowns in CombatLib?

There are two options I found for modifying Pixie's XYZZY code from K.V's forum post so that it now filters out those gamestorage type rooms:

room = ListExclude(AllRooms(), FilterByType (AllRooms(), "gamestorage"))
ShowMenu ("{once:Surprisingly, a menu appears.

}Where to?", room, true) {
MoveObject (game.pov, GetObject(result))
}

or cleaner after the list is made

room = ListExclude(AllRooms(), game.gamestorage)
ShowMenu ("{once:Surprisingly, a menu appears.

}Where to?", room, true) {
MoveObject (game.pov, GetObject(result))
}

So now that the gamestorage rooms are typed, and listed, they can be removed from results when they're just clutter. Or added somewhere if needed.

With the gamescript auto-listing them, you don't have to filter the rooms list by type if you simply want a list of rooms with that type.

So the opposite, an XYZZY command that would only produce gamestorage type rooms looks like.

ShowMenu ("{once:Surprisingly, a menu appears.

}Where to?", game.gamestorage, true) {
MoveObject (game.pov, GetObject(result))
}

It's exciting and useful to me, I'm already planning to work out other implications for other types I'm going to make.

But hopefully it turns out useful to you. Of course, to my Heros here in the quest forums, it probably just reads like a tutorial on common sense haha.

Clean command from the test game:

XYZZY
Surprisingly, a menu appears.

Where to?
1: room
2: shop
3: shop stockroom
4: frontyard
5: backyard
6: charactergeneration

Or its opposite:

XYZZYgamestorage
Where to?
1: weathers
2: the gale of the thunderstorm pushes you now, as the downpour reaches its strongest yet, and there is frequent lighnting. you cannot hear anything except frequent peals of thunder.
3: lesswindts
4: a shaft of sunlight breaks through the clouds of this thunderstorm. is that? yes! you'd better believe that there's now a rainbow visible amidtst the lightning.
5: questroom
6: verses_known
7: verses_forgotten

AllRooms is already doing a filter to exclude everything that doesn't have isroom true.

Rather than creating a whole new attribute, wouldn't it be simpler to set those containers to type "Object" rather than "Room"? Or if they must be rooms for some reason, just set their isroom attribute to false

You know, Mr. Angel.... I had never considered it.

I just used the "room" method as it came because that's how Pixie introduced it and uses it in libraries. I never considered what might happen if "isroom" were set to false or if I had decided to use containers instead... hmmm.

If "isroom" is false, will the object still have exits and will they work? One of the things Pixie's weather library does is have a turnscript that sort of travels from room to room to get the different weather descriptions by randomly using an exit. So exits would be a must, or else changing the script to move from container to container I suppose. But it would be harder to "lock the door" to certain weather patterns mid-game if using containers and a move script.

Can you scope the descriptions on objects in containers to make lookable weather for a player? I suppose you probably could, huh?

Yeah, that one would just look differently. hmmm.

I honestly never thought to have a room that wasn't an "isroom."

I'm still excited that I learned how to do this with the code. Using lists and eventually dictionaries I think is going to be something very helpful as I move more and more from concept to actually growing and building the game.

I figured it would be pretty simple to you veteran folks though! Mrangel is probably right, it could be simpler to remove your utility rooms out of "AllRooms()" by removing "isroom." Still, I'm liking types and lists for sorting all my stuff during the "developer" phase.

If nothing else, when I'm looking to build a conversation, and forgot where the repository happens to be for a certain situation, or forgot where I'm hiding this or that type of thing, I could do my XYZZYgamestorage and pull up a quick list of just those rooms to look through haha. Since I've already coded it all anyway.

In my "real" game, the list is much bigger and currently looks like the below and will grow exponentially from here I think.

Where to?
1: progrooms
2: convlibtopics
3: she_topics
4: holy spirit_topics
5: francois frederick_topics
6: nino caposki cat_topics
7: gamemaster_topics
8: uptopicsstore
9: combadge_topics
10: apothecarykeyworld_topics
11: vagabond_topics
12: topics wings
13: twgamemaster
14: climate
15: the sun is shining, the sky is blue, the grass is green.
16: the weather is pleasant. a few white clouds dot the sky.
17: thewings
18: shopstocks
19: she stockroom
20: apothecaryshop stockroom
21: gamestorage
22: exits room
23: gamequests
24: keyworldquests
25: islandworldquests
26: sheolquests
27: faithworldquests
28: invpanestuff
29: verses_known
30: verses_forgotten
31: verses_waiting
32: sheol
33: keyworld
34: islandworld
35: faithland

There are still several worlds to add, myriads of talking folks, and at least a couple of different systems for interacting with book types. The verses sections here are Bible ones, but I'm also going to be adding Qur'an type verses, Jewish Bible type verses, and a type for Hindu Scriptures. Etc, Etc, and onward. I might decide to develop each world separately as it's own game to a point while building them, but they're really each meant to be discoverable from the Keyworld depending your choices and type of player you are, whether you find the key objects, etc. Anyway, all that rambling to say that I'm going to have a lot of these "other" kinds of rooms and objects, so this type of coding is at least an interesting crutch/milestone for me.

It might be easy and smart just before publication to set this particular type's "isroom" to false, and then remove these extra little bits of code.

I heard somewhere once that the really expert coders are engineer minded and make the most efficient codes and there's less risk of conflict.

I think you strike me as one of those with a great head for finding a simpler way to do things Mrangel. Thanks for that!

If "isroom" is false, will the object still have exits and will they work?

Yes. isroom is a recent addition, which is only used by the AllRooms function.

There is nowhere in the core code that cares if something is an object is a room. (The core code treats any object the player is inside as a room, and anything the player isn't inside as an object; prior to the addition of the isroom attribute in Quest 5.7.2, the "Room"/"Object" drop down in the editor only controlled which tabs were shown in the editor)

But in the examples you give, like the stock room for the store, weather, conversation trees etc… do they need to have exits? Hmm… I can see a way you could use exits for conversation trees; it's not the way I would do it, but I guess you could. In that case, you could just manually override the isroom attribute to make it false, so that you see the "Exits" tab in the editor, but it isn't treated as a room by AllRooms.

Thanks for the info Mrangel.

The only library truly dependent on the exits is the Weather one that I can think of. It determines which weather the player sees by scoping the current room the weatherscript is in. It then travels through a randomly chosen exit to another connected weather room depending upon how often you want it to, or whether you specifically tell it to move. But if it travels through an exit, the description on using the exit is used. So you get "the wind dies down a bit" as the script moves from the very windy weather room to a room which is going to show whatever you said for the less windy.

So it would take a bit of redoing to make WeatherLib work differently, but could be done.

This all makes me curious if there's an easier way to work with types as if they were lists though.

In the documentation/tutorial I see that we can do

If (doesInherit (objectname, "typename")

To check whether something is generally a part of a type before running whatever script.

But what if I want to have my game look through all things of a certain type to find a match for what was entered and then run a script based on the result?

Is there an easier way to do that than running something like the system I made above?

Are there already lists of objects by type?

One example I can think of is auto-hiding everything that's "Pervert" type when a player selects "minor".
Or making a command that looks for all "Fairyland" types in the room to react to them in a certain way.
Also specific uses, like checking the type for objects that have a certain script on them, and running that script.
That's where my mind went when I first made the Gamestorage type with Gamestorageme on it. I'd thought, "I could make the game run that script automatically for everything with the Gamestorage type. But then realized there was an easier way to get them into a list. But what if it was "Sheol" types that have a "revivecorpse" script on them where we don't want that happening to the Fairyland types who happen to also have that script?

Hmmm... I'm sorry. This went from being about something very specific to accidentally asking you to brainstorm how to program my whole game with me! I definitely don't mean to impose on that level!

But if you can point me to anywhere that might let me know about functions for types, how the game handles types, etc. that would be awesome. If these don't exist yet, hold on to your horses, because I'm going to be working with types a lot and probably building these sorts of things to get them listed, functioned, and accessible for programing.

Forgive if I'm asking something that I just haven't read in the documentation yet, or that seems like a stupid question. haha.

I hope I never forget to remind you how much I appreciate you Mrangel.

Doh!

I could set each type to have flags with it's typenames, couldn't I?

Would that essentially make them all accessible in the above way?

The only library truly dependent on the exits is the Weather one that I can think of. It determines which weather the player sees by scoping the current room the weatherscript is in. It then travels through a randomly chosen exit to another connected weather room depending upon how often you want it to, or whether you specifically tell it to move. But if it travels through an exit, the description on using the exit is used. So you get "the wind dies down a bit" as the script moves from the very windy weather room to a room which is going to show whatever you said for the less windy.

Ah, I hadn't come across that one. That's an interesting way to do it. I suspect that it would be relatively easy to edit that library so that the "Exits" tab is shown in the editor even if weather rooms aren't actually rooms; or (if the library creates a type for its rooms) to set isroom to false and exclude them from AllRooms.