[Bug in TADS?] How would I edit a method, in TADS 3, and still retain the previous behaviour?

[myrkraverk]

Ok, the next part of the exercise is to figure out how “edit” a method. The below does not work.

modify Floor
   basicExamine() { "You bend over to see the floor."; inherited(); }
;

A quick look through Learning T3 did not cover how to do this; or did I miss it? Page reference welcome.

[myrkraverk]

When I step through

modify Floor
    basicExamine() {
        "You bend over to see the floor.";
        inherited();
    }
;

in a debugger, I obviously execute

"You bend over to see the floor.";

and then eventually

modify RoomPart
  desc() {  defaultReport(&nothingUnusualAboutMsg, self);  }
;

through the second line. So how come it only shows

>x floor
You bend over to see the floor.

when I play the game? Is this a bug? Why doesn’t defaultReport() print anything?

How would I verify this is a bug in TADS 3? I have version 3.1.3, build Win121. Do other versions or editions behave differently?

[RealNC]

Default reports are fallbacks. They only get printed if nothing else was. See:

https://www.tads.org/howto/t3res.htm#action

defaultReport( msg, params… ) . This generates a “default” report. This is a special kind of report used to indicate a very simple, minimal acknowledgment of a successful action. The important thing about default reports is that they merely acknowledge that we have done exactly what the player asked. For example, if the player enters the command OPEN BOX, and the response is “Opened,” this would count as a default report: it tells the player only that we have done exactly what they asked, and nothing else. If opening the box reveals something inside, that wouldn’t be part of the default report, because the player’s command didn’t say anything about revealing the object. (Even if the player expected the object to be revealed, that part still wouldn’t be a default report - the revelation wasn’t part of the explicit request, no matter what the player actually expected.)

The important thing about default reports is that they’ll only be displayed if there’s not also another report of some kind, and the command was explicit. We don’t show default reports for implied commands, because, by definition, a default report merely acknowledges a command, and a command that the player didn’t actually enter requires no acknowledgment. We leave out default reports if there are any other reports as a convenience to custom overrides; a custom “action” routine can freely inherit base class code from the library without having to worry about any default message that the library code generates, since the default message won’t be shown if the custom code shows a main report instead.

Default reports will probably not be used very often in game code. They’re mostly for low-level library classes that implement the basic commands.

[myrkraverk]

Thank you. I’ll have to go back to the drawing board then, for what I really have in mind. I’ll try to share an example when successful.