Parsing of fancy_long() descriptions in base_room.c

[azerwyn]

Summary: The function fancy_long() in /std/base_room.c parses all long() text without exception causing difficulty with more granular formatting of text.

Specifics: When working with the academy files, one challenge is to eliminate the @FOO..FOO text construct. To accomplish this, I discovered I could not simply add a single linefeed without it being doubled. So I traced the command stack beginning with the look verb to isolate where the linefeed doubling was being applied (fancy_long in base_room).

I have placed three rooms in /open that demonstrate several look/long() processing methods. The first two, while they inherit my new_base_room they do not set_no_double_spaced_long(1). The third file does.

1. The first room (fancylong1.c) shows a room with text in set_long() with @FOO..FOO.
2. The second room (fancylong2.c) shows the room text with @FOO..FOO removed, quotes added, and a single space at EOLs.
3. The third room (fancylong3.c) shows the room with the new no_double_spaced_long variable being set to bypass the linefeed doubling but preserving the indentation.

While I have fixed this for my needs, I feel it appropriate to raise the discussion that seems to have an origin in feeding all long() descriptions through this fancy_long() method in an attempt to standardize the presentation of text and paragraphs.

The private variable no_double_spaced_long and set_ query_ methods supporting it presume a "no change" requirement to existing room objects and thus should not (itself) be a compat-breaker for legacy or existing code.

If there is an alternate or more desirable approach, for now, let's get it on the table. Should we desire a more in depth approach to the look->long_display command stack, this small change now should not interfere and might even help craft requirements should someone desire.

Before I end my discussion question, I stipulate that my current approach to the academy includes the display of text that might better be put into separate in-room objects and not into the room description. Currently, almost all the 'teaching' material is embedded in the room descriptions. This might not be where we end up, but it is where we are now.

It is my desire to set milestones of achievement that allow for progress instead of getting in a quagmire seeking perfection. I'd like for us to think of the Lima Academy is a living domain that will grow and be more easily maintainable as features are introduced and changes are implemented. That said, this discussion is really about a specific change to basic_room.c.

I'm willing to open another discussion that invites discussion on the subjects of the academy's mission, priorities, and integration with supporting continuous improvement of Lima itself.

Your thoughts, please. :)

[azerwyn]

A follow-up note:

I found a function that seems oddly unused in /std/room/roomdesc.c:

92 protected
93 int show_fancy_long()
94 {
95    return 1;
96 }

I searched the entire lib tree with: grep 'show_fancy_long' $(find . -type f) and the only place it appears is that one occurrence in that one file. Almost seems stubbed in for future consideration... [cue up x-files music]

[tsathoqqua]

Sounds like there is some general clean up needed in there :-) Also, do you think rooms that would need not to be automatically "fancied up", could set a function like

int show_fancy_long() { return 0; } to avoid the fanciness?

[azerwyn]

We are on the same wavelength. Of course, my thinking is steered by the assumption that most admin would consider consistency to be guiding principle. Therefore, I'd posit that rooms that deliberately circumvent consistency would be the exception rather than the rule.

[tsathoqqua]

Yeah, agreed. I think it might be temping to do something like

void setup()
{
  ...
  set_no_fancy_long(1);
}

But that would require all rooms to carry an extra variable, thereby increasing memory consumption of each and every room just to handle the exception as you put it. So I still think creating a custom function in the rooms that can override the show_fancy_long() further down the inheritance chain would be a better option.

[azerwyn]

Yes, the solution ends up being quite easy. Toward the top of the room, I define:

string fancy_long(){ return ::simple_long(); }

I suspect this is why that show_fancy_long() stub never got fleshed out and probably can be removed from /std/room/roomdesc.c since it is likely cruft.

[azerwyn]

Discussion resolved. No actual enhancement required. Solution is to overload the fancy_long function.