Floor and Ground problems

[tajmone]

• Add tests to identify and isolate all cases of similar problems.
• Find solutions.

Verbs like put_in, and other, have their own DOES ONLY ovverides in room objects or in floor and ground, but some of these will never be executed due to some CHECKs defined in the main verbs in lib_verbs.i.

Example for put_in:

ADD TO EVERY OBJECT
  VERB put_in
    WHEN obj
      CHECK ...
      ...
      AND obj IN allowed OF cont
        ELSE
          IF obj IS NOT plural
            THEN SAY check_obj_allowed_in_sg OF my_game.
            ELSE SAY check_obj_allowed_in_pl OF my_game.

and then in lib_locations.i, on the floor instance:

  VERB put_in
     WHEN cont
    DOES ONLY "That's not something you can $v things into."

But the latter will never get executed, due to CHECKs inheritance preventing it (unless the obj is included in the allowed of floor, which is unlikely and unwanted).

I've tested this in the Italian library and I can confirm I get the message from the AND obj IN allowed OF cont CHECK ("The XXX doesn't belong...") instead of the expected ("That's not something you can put things into.").

Similar CHECKs in other verbs are preventing DOES ONLY executions in other cases too, especially with the verbs of the 'put,' 'pour' and 'empty' groups, when involving room/site objects, liquids and other specialized library classes.

I'll try to add some tests to pin down all the problematic verbs and see which solution can be adopted. For now, this Issue serves as a reminder.

---

EDIT — For a detailed discussion on this kind of problem, its solutions and possible upcoming changes to the ALAN language to fix it, see: alan-if/alan-i18n#34

[AnssiR66]

OK, thanks! Let's address this issue later when we know the scope of it.

[tajmone]

A Harmless Bug

OK, this Bug is not a bid deal — the reply "The OBJ doesn't belong..." is still acceptable, even though it's not the intended one (i.e. "That's not something you can put things into.") — but still, it would be good to fix it, at least for code consistency sake.

But A Tricky One to Solve...

The problem with this bug is that it's tricky to handle. I vaguely remember having had a go at it, and didn't find any elegant way to tackle it down.

The easiest solution that comes to mind is to dump all the VERB overrides on these special objects (floor and ground), and place an explicit check for them in each verb that might affect them, before the AND obj IN allowed OF cont check, so that it doesn't get bypassed by it. I'm actually not quire sure how to go about this, but my guess would be to add a WHEN cont check:

ADD TO EVERY OBJECT
  VERB put_in
    WHEN cont
      CHECK
        cont NOT IsA floor OR cont NOT IsA ground
          ELSE "That's not something you can $v things into."
    WHEN obj
      CHECK ...
      ...
      AND obj IN allowed OF cont
        ELSE
          IF obj IS NOT plural
            THEN SAY check_obj_allowed_in_sg OF my_game.
            ELSE SAY check_obj_allowed_in_pl OF my_game.

... or something along those lines (need to test it, it's now been a while I haven't worked with Alan code).

I can't really think of another solution since we're banging against inheritance priority here, and the fact that the first parameter obj is processed before the 2nd one cont in the Verbs execution — unless we can exclude the check expression AND obj IN allowed OF cont when cont is floor or ground, which I think can't be actually done (i.e. Checks can't handle chained expressions like this).

Maybe instead of changing the CHECK clause we could intervene in the message itself:

      ...
      AND obj IN allowed OF cont
        ELSE
          IF cont IsA floor OR cont IsA ground
            THEN "That's not something you can $v things into."
          ESLE
            IF obj IS NOT plural
                THEN SAY check_obj_allowed_in_sg OF my_game.
                ELSE SAY check_obj_allowed_in_pl OF my_game.

I'm not sure what the ramification of these changes might be (these edge cases are entangled knots resulting from the complexity of the library elements' interconnections, so it's never easy to predict the avalanche effect that small changes might have).

Another solution could be to remove the AND obj IN allowed OF cont condition from the VERB CHECK, and add it at the beginning of the DOES body — but this doesn't sound an elegant solution at all.

The problem here is that there's no way to handle this in idiomatic Alan — to overcome the conflicts between parameters processing order and verbs execution inheritance we are forced to hack our solution.

I think that one of the dumping-solutions proposed above is the best one right now.

• Do you have any better solutions in mind?
• Should just leave this (rather harmless) bug as it is for v2.2, and handle it in another release with more time?

[tajmone]

Following what you said in #68, I've removed this Bug Issue from the v2.2 Project and milestones, and moved it into the Second Next Release` milestone.

[AnssiR66]

I continue here what I was after in my other comment - sorry I am using a different thread. If we INCLUDE objects in the allowed set of the floor and the ground, we can then print a DOES ONLY at the put_in etc verbs at the floor and ground instances, having the "That's not something you can put things into." message display. It's not maybe elegant, but it is a workaround ... but let me know what you think...

[AnssiR66]

And hey..., how about declaring the floor and ground supporters instead of containers?

[tajmone]

If we INCLUDE objects in the allowed set of the floor and the ground, we can then print a DOES ONLY at the put_in etc verbs at the floor and ground instances

I find this solution a bit "entanglement risky" — hard to foresee how this might impact some end user custom definitions. Basically, we'd have to add the whole object class to its allowed. Also, I'm not sure how this interfere with the StdLib custom way of handling allowed items via sets of objects.

how about declaring the floor and ground supporters instead of containers?

This seems a good approach — after all, these are supporters. Right now, I can't recall all the details of how supporters are implemented in the StdLib, and how this change of class might have a domino effect on the library (because it surely will), but I definitely think that this is a route worth exploring.

Maybe (after the v2.2 release, we should create a dedicated branch to work on this, so we cal do extensive tests to check its impact. The current test suite already covers quite thoroughly these special objects, so switching their class should produce immediate visual results in the test logs.

[tajmone]

And hey..., how about declaring the floor and ground supporters instead of containers?

The more I think about your proposal, the more I think it's appropriate.

We might also want to ensure that ground and floor would have some special behavior in relation to the Hero trying to stand on them, and regarding objects being dropped, or attempts to put them on the ground/floor.

Some examples:

• Hero attempting to "stand on" the floor/ground:
  • If he's already DIRECTLY AT current location, then reply that he's already standing on the floor/ground.
  • If the hero is sitting or lying down on the floor, or on some other surface (i.e. virtually, via the dedicated attributes), the attempt might result in the player returning to the natural position.
• Dropping objects/putting them on the floor/ground:
  • That's an interesting topic to explore; we could even make it so that objects that were dropped will be described (by every location) as being lying of the floor. This would only affect dropped objects, and not objects as defined by the author (unless explicitly declared as being IN the floor/ground surfaces). There's potential in this.