TADS Q - Examine Afteraction

Authoring TADS
1

Hi all,
hopefully this is the right place to ask this sort of question…
I’m writing an adventure where the Player has a special ability to change certain game objects into alternate versions (eg. light to dark). And so far, it’s been fine for normal Thing objects where I hide the old object and show the new one using the sightPresence attribute.
However, it hasn’t been going so well for roomParts.
So I have a roomPart (a ceiling) that is initially invisible (I used sightPresence = false).
Then when I perform another action, it makes this object (the dark ceiling) visible and hides the existing ceiling (the light ceiling).
Up to here, things work…
However, the dark ceiling is a special case in that as soon as it’s examined, it needs to become invisible again and the light ceiling replaces it (Player did not have enough power to transform the light ceiling permanently).

Here’s my code - TADS won’t allow it to compile unless I remove the sightPresence = false; statement.

darkCeiling: RoomPart 'dark ceiling' 'dark ceiling' "The ceiling is now clear glass. You can make out a figure above. Are they watching you? The rather hideous lion mask they are wearing makes it hard to tell. But before you can get a better look, the ceiling shimmers and frosts over. " sightPresence = false; dobjFor(Examine) { afterAction() { inherited(); sightPresence = false; lightCeiling.sightPresence = true; } }

Am I going about this the right way?

It seems TADS doesn’t think that I can examine the invisible ceiling in it’s declaration (even though I can change that attribute in another object’s actions)

This is in TADS 3 by the way.

Any advice welcome! :slight_smile:

2

(Btw, it’s better if you write code using code tags.)

Normally, when you need to swap an object for another one, you don’t mess with sight (or other senses) but simply put one object out of scope entirely and bring the other in. The easiest and probably safest way to put an object out of scope is to move it to the ‘nil’ location. This needs to happen with the help of the baseMoveInto() method, since that method makes sure not to trigger any travel side-effects (you don’t want side-effects since you effectively need to make an object just disappear without any other objects noticing.) To replace the light ceiling with the dark ceiling, you would do:

  lightCeiling.baseMoveInto(nil);  // Remove the light ceiling from play.
  darkCeiling.baseMoveInto(kitchenRoom); // Replace it with the dark ceiling.

Normally, that would be enough. However, since the ceilings are RoomPart objects, there’s two additional methods that need to be called: moveOutOf() for removing a RoomPart from its location, and moveIntoAdd() for adding a RoomPart to a location (I discovered those two methods while looking at the RoomPart definition in travel.t.) So the correct procedure for RoomParts is:

  lightCeiling.moveOutOf(kitchenRoom); // Not a part of the kitchen room anymore.
  lightCeiling.baseMoveInto(nil);  // Remove the light ceiling from play.
  darkCeiling.baseMoveInto(kitchenRoom); // Put the dark ceiling into the kitchen.
  darkCeiling.moveIntoAdd(kitchenRoom); // Make it a part of the kitchen.

And vice versa when you need to swap them again. The darkCeiling needs to have an initial ‘location’ of nil. When you define the darkCeiling:

  darkCeiling: RoomPart
  // ...
  location = nil
  // ...

To make the dark ceiling disappear again when it’s examined, you would do the swap in its description:

  desc()
  {
      "As soon as you raise your head up to look at the ceiling, it disappears in a
      cloud of orange smoke. ";
      // Remove dark ceiling from play.
      darkCeiling.moveOutOf(kitchenRoom);
      darkCeiling.baseMoveInto(nil);

      // Bring the light ceiling back.
      lightCeiling.baseMoveInto(kitchenRoom);
      lightCeiling.moveIntoAdd(kitchenRoom);
  }

In this case, you’re using ‘desc’ as a method rather than a property. This is allowed and in fact very useful.

Using the above means you don’t need to mess around with sightPresence. Hope that helps.

3

thanks! - I knew there had to be something better than just making things hidden. just wasn’t sure what. :slight_smile:

4

…also, I don’t know if anyone in the thread mentioned it, but “false” is not a defined constant in T3. You want to say “nil”.

–JA

5

Oops, Jim is right. My brain is so wrapped around C++ that I totally missed that TADS uses ‘nil’ instead of ‘false’.