[Adventuron] Examining objects that are inside a container

[adventuron (Chris Ainsley)]

@ChristopherMerriner

I did have some related persistent problems until, in an effort to chase them down, I commented out my entire on_debug section and then a bunch of errors (misfiring system messages and things not puttable or gettable) resolved. There’s nothing in on_debug that would obviously be causing problems (it’s just a bunch of flags I’m setting) but the very presence of that debugging section seemed to upset Adventuron (poor thing).

Chris, is this issue resolved now?

[adventuron (Chris Ainsley)]

Garry, please can you give me some sample source code, and sample inputs so I can replicate the issue?

I’m sorry to keep repeating the same instructions, but without step by step instructions on how to trigger a bug, it’s very hard to fix a bug. Christopher’s original bug was to do with EXAMININING, not getting, so I need a different set of instructions for this newly reported “GET” bug.

Report here if you can - https://github.com/ainslec/adventuron-issue-tracker .

[Warrigal (Garry Francis)]

Shall do.

[Warrigal (Garry Francis)]

I just remembered that I tried to prepare some sample code, but when I’d extracted the code from the full game, the issue disappeared. This was reported above on 28 December 2020. I’ll have to send you the full game. Is that okay? It’s nearly 6000 lines of code with minimal blank lines and comments. I’ll continue working on it in the meantime.

Edit: Incidentally, version 0.0.0 of the game that I emailed you on 7 December 2020 did not exhibit this bug. Versions 0.0.1 onwards do. I’ll do a comparison to see if anything has changed in my code.

[ChristopherMerriner (Christopher)]

Hello Chris - Happy New Year!

All more or less ok for now I think, thanks. Something in on_debug stopped is_present S1 firing for an object in a container…unless another specific container was in the same location. I stopped debugging and it then worked.

[Warrigal (Garry Francis)]

After a lot of discussion, @adventuron has discovered a bug whereby objects in a container in the starting location are in scope, but objects in containers in other locations are not. This has now been fixed in Beta 66m.

In addition, there is now an experimental_auto_propogate_known property that can be used in game_settings{}. If experimental_auto_propogate_known = true, objects in containers are placed in scope so that they can be examined and taken. This is similar to how it works in other languages, such as Inform. If experimental_auto_propogate_known = false, objects in containers are not placed in scope, so they can’t be examined or taken until the parent container is examined. This is the default.

[ChristopherMerriner (Christopher)]

Excellent news: I will add that function. Thanks!

[auraes]

@Warrigal

That was introduced today. To quote from the Telegram group:

“I’ve introduced a new system message called you_see_nothing_special_2. This message will be used when you examine a noun that does not relate to a known object, e.g. examine wibblewobble. “Nothing catches your eye”. There is also a policy in game_settings {}. on_examine_non_known_entity = you_see_nothing_special | you_see_nothing_special_2 | cant_see_one_of_those. By default it’s you_see_nothing_special_2.”

After some discussion, the message was changed to “Try something else.” Don’t ask me why. If you don’t like that, you can either change the policy or redefine the message in the system messages in your theme.

"Try something else." seems to me the worst possible default answer.
The answer I found for the translation of the Inform6 and PunyInform library seems to me the most suitable :
"You can't see or interact with that."
If the object exists in the game, but is out of scope, or not (as in a description) the answer seems appropriate regardless of the verb.

[MikaKujala]

Hi!

I’m trying to write a scene where an NPC would examine and/or take objects available in the current location. For this purpose I have a tmp_list and a objects_available list, as used in the code below. When building the objects_available list, there is some amount of ifs for filtering out the npc objects (could use traits for this also, to make it more dynamic) .

As a first step, I’m attempting to just print out a random item of the list of available objects, but I’m sometimes getting invalid index specified base(0) exception. Just to debug this I’d need to store the random(collection_count(“objects_available”)-1 to some temp integer, but what is actually the syntax for that? It seems

: set_integer var = "rnd" value = {(random(collection_count("objects_available")-1))};

is not working…

If someone could perhaps help me to get around this please? Is there a more intelligent way of getting a random item from a list of objects available in a given location?

   collect_objects_in_location : subroutine {
      : look_inside {
         of               =  current_location
         extract_the      = id
         store_results_in = tmp_list
      }
      
      : collection_clear "objects_available";
       
       :print "Items available in this room :";
      : collection_iterate "tmp_list" {
         // TODO don't add NPCs
         : if ((item() != "priest") && (item() != "android") && (item() != "girl")) {
            : print {("Adding: " + item())}
            : collection_push { collection = "objects_available" content -> (item()) }
         }
      }
      
      
      : print {( "A random item:"+ 
         collection_get{
            collection -> ("objects_available")
            index -> ( random(collection_count("objects_available")-1) )
         }
       )}
     
   }