Meaning of 'take all' and 'drop all'? [SOLVED in Quest 5.8]

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.

Continue reading.

So, basically, like Pixie says:

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 can't see how it would effect anything, unless an author is depending on it to work the old way for some reason. (Like maybe you can take something and the whole point of the game is to figure out to examine it and take the item out of it.) This would only effect an .aslx being played in the editor, right? So, published games wouldn't be effected. Only works in progress.

The update from 5.6.3 to 5.7.1 broke two of my games in progress, and the update from 5.7.1 to 5.7.2 did the same (to the same two games). My initial solution was to revert to 5.6.3 until my games were completed. Later, once I admitted to myself that I wouldn't be completing those games any time soon, I created a post on this site, asking why TAKE no longer worked, and Pixie fixed me up with some working code within two hours.

My point? Changing this may break someone's game, but we can help them out with it. (What's that saying about making omelettes and breaking eggs?)


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.

Also, setting the player up as a surface is something Quest is not programmed to check for. Quest just checks for everything inside of the game.pov object. If the object is visible and the drop setting has not been changed, it will be dropped.

even if they are scenery and invisible.

If objects are set to invisible, they shouldn't exist as far as Quest is concerned. Quest is definitely dropping things set to invisible when carried by the player (whether the player is a surface or not, and whether you DROP ALL or specifically DROP OBJECT). I assume this is because Quest doesn't expect the player to be carrying something which is not visible. (SIDENOTE: When a scenery object is taken, Quest changes the scenery attribute to false.)


some games can involve picking up male/female characters

Having defaults in Quest is what makes game-making easier on the whole.

99% of the time, you cannot pick up an NPC. Therefore, I believe this should be the default.

With the current scripts, if anyone wants to make an NPC object which is takeable, they should simply not set the object up as "male or female named". Just change the object's gender, article, alt, and possessive attributes. (That's all adding the object type actually does (I think), besides excluding the object from TAKE ALL.)

This seems fair to me. The author would already be doing extra coding to make the NPC object takeable. They may as well have to change 4 more attributes to reflect the object's gender, rather than the rest of us having to do extra things to exclude every single NPC object we create from TAKE ALL.


Again, a single not_all attribute would be a good solution (and its currently being considered for the next version of Quest).

Instead of excluding npc_type from TAKE ALL, that line of code could exclude things with not_all set to true. So, since npc_type is added to a named male or female object already, we could add the not_all att to thenpc_type type, setting it to true by default. With this set up, when you make something male or female named, not_all is set to true by default. This would be a checkbox on the object, which you simple uncheck to include the object when entering TAKE ALL. (Sound good?)


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?

Continue reading.

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.

That's where not_all would come into play.


While we're discussing TAKE:

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

...but I digress.


Here's how I envision things:

All default objects cannot be taken by default, and each object's not_all attribute is set to false by default (or simply doesn't exist as an attribute).

When you change an object to male (named) or female (named), this sets not_all to true. There will be a new checkbox in the editor, on the inventory tab, so this would be easy to change.

When the player's command is TAKE ALL or DROP ALL, objects with the attribute not_all set to true will be ignored.

If an object is in a container and the container can be taken, ALL should include the container only. If the container cannot be taken, the objects it contains which can be taken individually should be included in ALL, but not the container. (Surfaces are types of containers, so they would work the same way.) [Coding this sounds like it would be a little tricky to me, but Pixie has probably already figured out how to do it!]

Another thing that I'd like to change is the way Quest hides objects before examining a container. I think those items should be scenery rather than not visible. On the first play through, it's not a big deal, but, if I die then restart, I know the apple is on the table. I don't need to examine the table to see it this time. So:

>GET APPLE.
I can't see that.

> EXAMINE APPLE
I can't see that.

>EXAMINE TABLE
Nothing out of the ordinary.
It contains an apple.

>GET APPLE
You pick it up.


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?

Check out some code
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)

Check out some code
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.


Nothing to see here.
Please move along.

Okay... I tried to steer you away...


How many text adventures has everyone successfully completed?

I've beaten every Infocom game except Cutthroat Island, and that's because it depends on too many random things. When I say I haven't beaten it, I mean that I haven't successfully played through all of the possible endings. ...and, seeming how everything works randomly, and my choices as a player do not effect the outcome at all, I said [expletive deleted] that game.

Besides the Infocom library, I've taken out at least 30 games made with Inform or Tads, and maybe 10 made with Quest.

Why am I tooting a dumb horn that is impressing no one? I'm not really. I'm just pointing out that I'm an experienced text adventurer. I've grown up playing them. This leads me to believe my input may be valuable (not that I think anyone is saying it's not, or that everyone else's input isn't equally valuable).

Now, over the past ...what's it been? Nearly 40 years? Infocom games have always been considered the best of the bunch. This is because Infocom payed attention to the players and the things the players expected while text adventuring.

Inform came along almost 20 years ago, giving us a way to make games in the same exact format as Infocom games, and they knew to stick to the same formula. Games made with Inform get much respect. Games made with Quest very rarely even get played unless they are entered into a competition and someone HAS to play them. Gamers mostly complain about the parser (many standard commands were missing, but many of those have recently been added). Besides missing standard commands, things are handled strangely. Like tables...

If I'm playing a game, and the description includes a table, but it doesn't mention anything being on that table, I'd probably still enter TAKE ALL. If that didn't score me anything, I might LOOK UNDER TABLE. At which point Quest would say "I can't see that," unless the author took the time to think that someone might try to look under the table and script accordingly. Never would I assume that I had to LOOK AT TABLE for items to magically appear on the table which have presumably been there the whole time. Not only that, but if I happen to play that game again, upon entering that room, I KNOW that there's something on the table, so I enter GET APPLE.

"You can't see that."

X TABLE.

"Nothing out of the ordinary. On the table, you can see an apple."

QUIT


Also, if I see a basket (in which is an egg). I expect TAKE ALL to get the basket and NOT the items from inside of it. (Especially if the game has an inventory limit.)


I'm just rambling now...

There are four of us discussing this (here and on GitHub), and we each have a different perspective, which is cool. The players each view things differently too, I'm sure.

So, I'm cool with whatever gets added to Quest. (If I don't like it, I can easily modify my core library files.)

I was just trying to help make Quest handle things the way serious gamers expect, which is the way things have been handled for decades. Quest deserves respect, but gets none outside of this community. The parser handles things differently than the norm, quite a few common commands were not previously included, and most games are created by lazy and/or inexperienced authors who set up USE on everything instead of taking the time to add actual commands to the code. (Seasoned gamers would never in a million years think to try to USE HAMMER ON NAIL or USE BOWL ON WATER. We were trained to USE more specific terminology.)


END OF INCESSANT RAMBLING

I hope I didn't offend anyone. I was trying to share my point of view. I am in no way saying, "I'm right, and you're wrong."


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'.


Log in to post a reply.

Support

Forums