In any Quest game, the player can type 'take all' or 'drop all' at any time but these operations don't seem to be well defined. How should they operate? Here is a proposal to help the debate:
TAKE ALL
In any location, attempt to take every non-scenery visible object. If an object is a container, attempt to take any non-scenery visible objects within it, and repeat recursively. If there are no objects to take, display "Nothing here to take."
DROP ALL
Drop all non-scenery visible objects held by the player. If no such object is held, display "Nothing here to drop." (Trying this out on existing games on the site can produce surprising results!)

Hello, DavyB!

I think that is already how those commands work, except it will take scenery objects and it ignores any object with npc_type (male of female objects).

I have modded take so it excludes any object with the attribute not_all set to true, and I'm sending a pull request soon. So, if it passes all of Pixie's tests, it may end up in Quest 5.8.

Sorry KV, perhaps I should have given examples! Curently, if the player goes into a room and finds a table with an apple sitting on it, 'take all' will only pick up the apple if the table can be taken with it, keeping both together. I was suggesting that the apple should be added to the inventory even if the table can't be moved?

For 'drop all', the issue is perhaps the implementation. If I make the player a 'surface' to add characteristics that can be examined, these are included in the inventory even if they are scenery and invisible. So, for example, in my Giantkiller Too game, I've described the character ("look at me") as: "Looking medieval, with hobbit-like feet to match. You are surrounded by a mystical aura guaranteed to keep you from all harm." This meant adding 'feet' and 'aura' as scenery objects to the player, which are invisible until "look at me" has been typed. 'Drop all' mentions both 'aura' and 'feet' even when invisible, which seems wrong.

I didn't realise 'take all' avoided male and female characters. That seems a bit inconsistent as 'take' can be applied directly to such objects?

I was suggesting that the apple should be added to the inventory even if the table can't be moved?

That does reasonable. I guess it would need to check if the container can be taken, and if not, see if the contents is reachable. Can anyone think of how this might badly affect existing games?

I didn't realise 'take all' avoided male and female characters. That seems a bit inconsistent as 'take' can be applied directly to such objects?

Do you think? We tried to make it intelligent enough to realise NPCs cannot be taken. If the player tries to take someone by name, then Quest has to match that person to the command, and by default will say he cannot be taken.

Well Pixie, one simple definition of 'take all' is that it should just be a shorthand for 'for all x do take', where 'x' is anything visible to the player that is not currently held. That means including scenery and NPCs. Such objects do have an 'inventory' tab after all? ...and some games can involve picking up male/female characters...as in my female talking pig in Giantkiller Too!

if the player goes into a room and finds a table with an apple sitting on it, 'take all' will only pick up the apple if the table can be taken with it

I never noticed this.

If a takeable object is in a container and the container cannot be taken, I think it should take the takeable object during TAKE ALL.
But, if the container can be taken, too, I think TAKE ALL should just take the container with any objects still inside of it.

I make the player a 'surface' to add characteristics that can be examined

I wonder if we should have a built in container type for NPCs?

Either way, this is another time when we should question if TAKE ALL should apply to the objects. I think not, but I can imagine some will disagree.

I wonder if we should have a built in container type for NPCs?

Sounds good to me.

And, if someone doesn't like it this way, they could easily remove the container type from the object; correct?

I've always found it odd that objects cannot be taken by default, but TAKE is a default display verb for default objects.

I think it would make a lot of sense if "(verb) all" was interpreted by the parser as looping over all all objects with that verb in their displayverbs list in a general case. So in the absence of command-specific "all" behaviour, it would just apply a verb to all objects (in scope) that have it.

"take" is probably one of the few commands that would be a special case; because you wouldn't want it to apply to objects inside containers in the same way.

...and the update from 5.7.2 to 5.7.3 did the same...

Is 5.7.3 out already?

Ha! Whoops!

I meant 5.7.1 to 5.7.2.

My point was that the last two updates each broke a work-in-progress, but that's because I was overriding default functions and commands which were changed during each update.

Yes, it would be useful for functions/commands that have undergone important changes since the last update to be listed with the new update. My 1 1/2 cents.

haven't read all of the comments yet...

but 'take' is a special coding/game-design logic, which pixie pointed out the logic of its intended design in his early post (I read that one, but not all the others yet), whereas there should be another such special coding for handling 'npcs', such as a 'follower/whatever' coding(s), as well as any other such 'whatever' game design objects, needing their own special coding, too.

also, this is a big deal with engine design...

we want the engine to be as universal and generalized as possible, as if you do something specific for one person's game design, it'll break everyone elses games and/or they may not want that engine design for their games.

unless fully tested and done well, any new things should be done as libraries, so as to not specialize/ruin the quest engine, ruining it for everyone. Only once something is fully tested and done well, keeping it generalized and universal, should it be added to the engine

also, it's a lot easier fixing a library (or simply removing/not-using the library until it gets fixed or helped with compatibility of your game and the library) then correcting the engine, as every time pixie changes/adds to the engine... he has to help everyone who now suddenly have conflicts between their games and the engine, unless they can figure out what happened on their own, but most people aren't good coders/programmers who can do this on their own and/or aware of being able to do it.

Oh, sorry. I was unclear. I wasn't complaining about that. Pixie did list the changes when he updated Quest.

I just had some crazy stuff going on in a modified take script. The update to Quest added super-awesome things concerning scope to the take command, and my modified script didn't jibe with the new attributes. Pixie (and mrangel) posted about those changes in numerous places. It was all my fault. And I wasn't the only one who had problems with that, but there weren't very many of us. And we all found the quick fix when we posted about it. (By 'found the quick fix', I mean Pixie promptly posted the code we needed and explained why we needed it. [INSERT LAUGH HERE.])

Anyway... I was just trying to point out that some updates may break games which are still in the creation process when people have crazy mods going on, but, if the updates are worthwhile, I say apply the update. If we can modify the script in the first place, we can find the fix (or post about it).

Also, keep in mind that published games are not effected at all; only works-in-progess.

The discussion here has dropped into implementation detail rather faster than I would have liked!

From a user perspective, when I open a cupboard and see several items, it seems reasonable to type TAKE ALL and expect the items to be removed. Is that a general view?

From a user perspective, when I open a cupboard and see several items, it seems reasonable to type TAKE ALL and expect the items to be removed. Is that a general view?

Seems pretty sensible. However, that couldn't be done with the way the parser's set up now. The parser calls multiple to get a list of objects, and then calls script for each of them. And there isn't actually an easy way to check whether a given object (like the cupboard) can be taken.

I think you'd have to do something like:

<command name="takeall">
  <pattern>^take all$</pattern>
  <script><![CDATA[
    pending = SortObjectList(ScopeVisibleNotHeldNotScenery(), "alias")
    pending = FilterByNotAttribute (pending, "not_all", true)
    untaken = NewObjectList()
    list add (untaken, game.pov.parent)
    taken = true
    while (taken) {
      taken = false
      foreach (obj, ListCompact(pending)) {
        if (Contains (game.pov, obj) or Equal (game.pov, obj)) {
          list remove (pending, obj)
        }
        else if (ListContains(untaken, obj.parent)) {
          list remove (pending, obj)
          taken = true
          // don't display a message saying "I can't take that" for shelves, counters, and other silly things
          if (ListContains (GetDisplayVerbs(obj), "take")) {
            DoTake (obj, true)
          }
          if (ListContains (ScopeVisibleNotHeldNotScenery(), obj)) {
            // The object isn't taken now, and its "take" script hasn't destroyed it
            // So we can try to take its children
            list add (untaken, obj)
          }
        }
      }
    }
  ]]></script>
</command>

(I was going to say that adding something like that to the core would be bad, because it would break take all for games with backdrop scope scripts. But then, I realise that the existing script won't deal with those anyway)

I would like to see a default "all" behaviour included in the parser (and "take" is one of the few commands where it would need to be overridden) but I think it would be quite difficult to ensure you didn't end up breaking existing games. Unless, maybe, it was added as a "feature" that could be checked or unchecked.

(and now my brain's coming up with really silly things. Like a turnscript that loops over all reachable items and combines their verb lists, to dynamically change the pattern of a command whose pattern ends up like ^(?<text_command>drop|take|look|lick|open|close|eat|kick) all$. Of course, that could never work)

when I open a cupboard and see several items, it seems reasonable to type TAKE ALL and expect the items to be removed. Is that a general view?

From a player's or author's perspective, I agree with this.

The discussion here has dropped into implementation detail rather faster than I would have liked!

Sorry. It's all about implementation, but discussing it means it may get fixed.

What about this?

THIS CODE HAS BEEN REMOVED TO AVOID CONFUSION

For archival purposes, it can be found here: 
https://github.com/KVonGit/QuestStuff/wiki/Taking-All

Another test game (with a closed box)

THIS CODE HAS BEEN REMOVED TO AVOID CONFUSION

Passing all the tests in Visual Studio doesn't necessarily mean this modification wouldn't break older games, does it?

I think KV and I have slightly different ideas about how the script should behave.

If there's a briefcase chained to a shelf, and you don't have the bolt cutters yet, should "TAKE ALL" take its contents? I think KV's solution says no, because the briefcase has a 'take' script even if you can't take it now. My script says yes, try to take it first and if that fails take the stuff out of it.

Which would a player more likely expect?

I think mine will try to take the contents if the briefcase's take attribute does not return true, it has no script, and it is open.

I was just messing around and following the same rules as lookat when in darkness. If you have a script, the script takes precedence over everything. So, when you examine something with a look script, that script runs whether or not darkness could prevent you from seeing it. (I guess it is assumed that you are prepared to handle the extra scripting since you're already adding a script.)

Anyway...

mrangel's method (checking to see if something has been taken, then trying to take its contents if not) is probably much more efficient.

I think mine will try to take the contents if the briefcase's take attribute does not return true, it has no script, and it is open.

Yes; if the object's "take" attribute is neither true nor a script.
It seems that if the take attribute is a string, yours will still attempt to take its children. Not sure, but I think that's not expected behaviour.

I went for the other approach; rather than trying to consider all the possible attributes that could affect an object's takeability, just attempt to take it and if that fails consider its children instead. For the briefcase with a 'take' script, my "take all" will attempt to take it, and if that fails will take its children instead.

I'm not sure which behaviour a player is more likely to expect.

I figured that using the displayverbs to govern which objects a player might attempt to take is reasonable. Because having a "take" attribute is a reasonable indication "this object can be taken" or "this object will do something if you attempt to take it", which is hard to distinguish between. But in most games, it seems that a "take" display verb is a reasonable indication "this is an object that a typical person might attempt to take".

I agree with you about everything but the "Take" display verb. I think that is a default display verb on everything that isn't a room or an npc_type. (I grumble obscenities every time I make a game while removing all the "Take" display verbs from the things I haven't changed to "Object can be taken" or added a take script.)

I think that is a default display verb on everything that isn't a room or an npc_type.

The same things that the default behaviour attempts to take when running "take all".

I grumble obscenities every time I make a game while removing all the "Take" display verbs from the things I haven't changed to "Object can be taken" or added a take script.

I'm not sure about the exact usage; but I expect that if you're going through those objects removing the default "take" verb, you probably wouldn't want "take all" to consider them. In most of my games, I think the objects that I've removed the "take" display verb from are the same ones that you will have given a "not_all" attribute.

To me, the display verbs are a way of the player character saying to the player "I think I might be able to take that object"; which is probably the same logic you might expect when the player says to the player character "take everything".

the display verbs are a way of the player character saying to the player "I think I might be able to take that object"

Exactly. Objects cannot be taken by default, BUT "Take" is a default display verb.

I go through each object I never want taken (and think it wouldn't make sense to try to take), removing "Take" from each display verb list, and setting notall to true on each one, too.

...but sometimes (not often) I remove display verbs that will still work when entered as a command (like "Take").

...but sometimes (not often) I remove display verbs that will still work when entered as a command (like "Take").

I can see that. But that's an odd and specific case.

It seems like in most cases, removing the display verb and adding your "notall" attribute are ways of expressing the same thing ("trying to take this object isn't an intuitive action") to different parts of the code.

If you go through doing both of those things to large numbers of objects… doesn't it seem easier to have both pieces of code expect to see the same message in the same way?

I can see exceptions. Like one of my first games, there was a large treasure chest. It's so heavy that you can only carry it if you're not holding anything else, and you can't pass through doors (except double doors) while holding it. That would have the "notall" attribute, but can be taken specifically.
But unless you're globally removing the display verbs for certain commands, I can't think of a case where an object that doesn't have a "take" verb displayed should be collected by "take all".

Your logic is sound. (I say that as if you didn't know. Ha-ha!) I guess I'd just rather check a boolean attribute than depend on an object's display verbs list, when it comes down to it. (I've recently seen two games (by different authors) in which the display verbs lists were being totally overwritten when performing certain actions on objects. This was not happening on purpose.)

I am now thinking of adding a bit of code that removes "Take" from the display verbs list of anything with notall set to true.

Okay, if there is general agreement that TAKE ALL should take any object visible to the player, I'm ready to move on to the implementation. Humour me! ...

The discussion here is much more involved that I would have expected. I know, for example, that the Quest function ScopeReachableNotHeld returns a list of "all objects which the player can reach in the current room (not including those the player currently has in their inventory)," so why is that not the starting point?

I can see that handling a script associated with a take operation is problematic so perhaps it is reasonable to just say "TAKE ALL is not available here" if any object in the scope list has a take script? ...forcing the player to take items one at a time. That still seems like an improvement over what currently happens?

The discussion here is much more involved that I would have expected. I know, for example, that the Quest function ScopeReachableNotHeld returns a list of "all objects which the player can reach in the current room (not including those the player currently has in their inventory)," so why is that not the starting point?

It is. But if there's a box on the floor, you don't want to take the box and then take all the items out of it.

So my 'take all' command works from the top down: it sorts ScopeReachableNotHeld to process the items that are directly in the room first, and then only takes each item if it's not inside a container that was already taken. Whereas KV's option was to filter that list down to only the objects whose parent is immovable. (Just thought: If I have a purse with a hidden pocket inside it, then the pocket clearly can't be taken out of the purse. So I've got a takeable container with a non-takeable container inside it. Do the command(s) presented so far deal with that sensibly?)

Ah, yes I see! I knew I should stay out of implementation discussions!! Happy to act as a tester if/when needed.

I reiterate:

I was just fooling around with the code.

mrangel's method would be the best way to handle things.

one simple definition of 'take all' is that it should just be a shorthand for 'for all x do take', where 'x' is anything visible to the player that is not currently held. That means including scenery and NPCs. Such objects do have an 'inventory' tab after all? ...and some games can involve picking up male/female characters...as in my female talking pig in Giantkiller Too!

Imagine that you are in a location with the following objects:

• table (on which is an apple)
• Bob (who is holding a hamburger)
• basket (in which is an egg)
• a talking pig

Now, I say, "hey! Grab everything from that room and bring it in here!"

What are you going to try to take in real life?

I'm thinking the apple, the basket, and MAYBE the pig.

In a parser game, everything should behave as it would in real life, at least to a certain extent. Otherwise, the player is in some form of alternate reality and will have no idea what to do.

Having had a month to think about this a bit more and hear the various responses in other threads, my current view is that 'scenery' should have a stricter definition so that TAKE ALL works on all non-scenery objects, including those in containers. These appear in hyperlinks so that would feel consistent to the player. So, in your example, if none of the items are 'scenery' all would be 'taken'. Quest 5.8 is now closer to this view, as nested items are taken when visible (excellent!), so it is only Bob and the pig who are left out...through Bob does lose his hamburger!

As a developer, I have to supply 'take' responses for Bob and the pig anyway, as they can be taken individually, ...which seems inconsistent? If they can be taken individually, why not include them in TAKE ALL? I now know that currently scenery items can be taken, but feel that shouldn't be allowed. Conceptually, it seems like a contradiction.

...but, in real life, in the situation I just presented, would you try to take the table? Or would you just grab any items on the table?

...and TAKE ALL will not try to take Bob's hamburger, because things normally can't just be taken from people (unless you are a thief).

My table is fixed in place. It cannot be taken. It is not scenery, either. Neither are the items on the table.

TAKE ALL should not try to take the table, but the table should be listed in the room description in order to list the objects on the table in the room description.

Imagine that the parser is an actual person you know.

The parser does everything for you because you are paralyzed.

The parser is in a room. There is a basket in the floor with an egg in it, and there is a table with an apple on it. Bob is also in the room, and he is holding a tasty beverage.

You say, "hey, parser! Bring me everything from that room!"

If the parser tried to take the table, you'd probably heckle him. "You dumb parser! That table is fixed in place! Why would you try to take it, you dummy?"

Then the parser picks up the basket, then takes the egg out of the basket, and hands them both to you. "You know that you could have left that egg in the basket, right, parser?"

Then, the parser tries to take Bob's beer, Bob sticks his foot up its ass, and now the parser is paralyzed alongside of you!

If they can be taken individually, why not include them in TAKE ALL?

In my example, the table can never be taken. It is fixed in place.

I now know that currently scenery items can be taken, but feel that shouldn't be allowed.

The author may want to mention an object in the actual prose, so the object is set up as scenery at first. Once the object is taken, it is no longer scenery, so it shows up in the object list afterwards. In this scenario, there would be an IF statement on the room description to check whether or not the object has been moved.

I think I'm repeating myself here, but as a player when I can see all of the following with hyperlinks,

    table (on which is an apple)
    Bob (who is holding a hamburger)
    basket (in which is an egg)
    a talking pig

and say TAKE ALL, I would expect a response to everything highlighted, regardless of whether or not the take request is reasonable:

table: You can't move it, never mind carry it.
apple: You pick it up.
Bob: He has a black belt in Karate, better be careful.
hamburger: You snatch it from Bob's hand and eat it one gulp.
basket: You pick it up.
egg: You pick it up.
talking pig: You try to catch him but he runs off.

It also avoids the following:

You see a wounded soldier.
>take all
Nothing here to take.
>take soldier
You pick him up and put him over your shoulder.

as a player when I can see all of the following with hyperlinks

Oh, yeah... I forgot most authors are usually creating hypertext adventures, not straight-up text adventures.

Where I'm from, clicking is for game books and web pages. So, maybe I'm just an old adventurer in new territory.

Also, we didn't have GIGS of drive space or RAM, so we wanted to keep the text that was printed during play to a minimum.

...and don't print that long list of crap that can't be taken during TAKE ALL to my transcript, either! That ink and paper doesn't grow on trees, you know! (Well, no... Even the paper doesn't technically grow on the tree.)

...and don't show me the same room description more than once.

These things all still distract from play now, even if we don't need to worry about the drive space, the RAM, or the ink and paper.

...and my games' response to TAKE ALL when nothing is taken is "There is no 'all' to take." This may still be slightly misleading, but it's not a blatant contradiction.

If you're not making your game with seasoned IF veterans in mind, you're not targeting 90% of the IF crowd.

We don't care about all those pointless responses during TAKE ALL, but we will complain if there's no funny response when we try to interact with an object individually.

Again, I'm not trying to argue with you at all, DavyB. This is definitely not even a heated discussion on my end.

We just have different views, is all. That's what makes the world great!

EDIT

If I check this thread later, and 20 people have posted that they prefer the way you think it should work, I'd be just as happy as if they preferred my method.

Heck, I'd be happy if 20 people posted anything at all (just to be sure everyone is paying attention while their opinions could still effect the next release).

Sorry KV, I hope I haven't stepped over a line anywhere? We seem to have created what looks like a fight so there is a good chance that no one will join in for fear of making matters worse. :)

I started this thread because I felt there were issues with 'take all' and 'drop all'. One way to remove the issues is to remove the operations, as they are only short-cuts anyway. This is probably not a realistic option, however, so we need to improve what is there.

Personally, I would tend to use 'take all' when I find more than one item when I walk into a room, look at a surface, or open a container. The latter cases weren't catered for at the time of the posting but are now handled in Quest 5.8, which feels like a step forward. I also notice that 'drop all' in Quest 5.8 no longer drops scenery objects held by the player, which is another welcome improvement.

My reference to hyperlinks was simply a shorthand way of describing the objects to be included in 'take all' rather than me assuming their use. At the bottom of all this is the need to define 'take all' in a simple way for players.

I think our differences reduce to whether or not 'take all' should include animate objects? ...though perhaps there is also a question mark over taking items out of a container if the container itself can be taken?

If we can agree the problems, maybe others will chip in with solutions?

I don't think anyone thinks we're fighting. I just don't think anyone besides you, me, mrangel, and Pixie really care, and the latter 2 notables have already each deposited two cents.

I also think we're eye-to-eye on everything but the table. So, let's consider it and only it for a moment:

I say objects which are fixed in place and cannot be taken should not be listed when entering TAKE ALL.

Also, seeming how most fixed-in-place objects are supporters, they should not be scenery because they need to be displayed in the room description to list their child objects.

(I say this because it makes sense to me AND it's how things have worked in text adventures for 30 years, making it the expected behavior.)

EDIT

Do note that this is a moot point, because I have to set my table to not_all for it to be ignored anyway.

The default setup in 5.8 is exactly how you dreamt of it, DavyB. Except for animate objects, and that is now 1 extra click while you're already under the inventory tab setting up your take stuff.

Oh, I missed a spot.

99% of the time, male or female objects should not be taken so they are ignored by TAKE ALL.

When we do want one to be listed, it's easy peasy in 5.8. We simply uncheck "Not listed when taking all" under the inventory tab. Takes 1 second.

The default setup in 5.8 is exactly how you dreamt of it, DavyB.

Excellent! I'd missed the change. Allowing individual animate objects to be listed or not listed gives all the control any developer would need.

I also think we're eye-to-eye on everything but the table.

You have lost me here? If all objects can be excluded/included individually, why is the table special?

You have lost me here? If all objects can be excluded/included individually, why is the table special?

Just as far as theory is concerned. That's the only thing we really differ on, I think.

I say the table is not scenery, but it is not included when entering TAKE ALL.

You say anything that is not scenery should be included when entering TAKE ALL.

ME: toe-may-toe
YOU: toe-mah-toe

Luckily, Pixie gave us the not_all checkbox. So, there's no need to call the whole thing off. With Quest, we CAN just all get along!

(Forgive the 3 obscure references.)

Great! I think this thread is finished, so I'm going to call it 'solved'.