listing discontent

So, a couple things to talk about today, but one of them is more useful to Hugo users everywhere so I'll cover that one first.

As mentioned in another post, Roodylib now automatically lists the contents of the room's (non-quiet) platforms in a room's description. This might give some pre-existing games some unexpected behavior, but logically, I don't know why platforms should be treated any differently than containers.

Still, this puts some in an awkward position, because they are not familiar with the ways to avoid listing contents. Of course, the quiet attribute will prevent content listing until the player explicitly looks into the object (at which point it'll list the contents at every opportunity).

To have full control over when contents are listed, you have to use the list_contents property.

To only allow content-listing when the player explicitly LOOKS IN/ON:

list_contents

{

if verbroutine ~= &DoLookIn

return false

else

return true

}

To allow content-listing only for EXAMINE or LOOK IN:

list_contents

{

if verbroutine ~= &DoLookAround

return false

else

return true

}

So yeah, the three times that contents are listed are room descriptions ( &DoLookAround), object descriptions (&DoLook), and when looking in objects (&DoLookIn). Knowing that, you can write your own list_contents rules. Of course, you can still use list_contents to print your own content listings before you return true.

The other thing is that, while applying Roodylib to another game, it became apparent that there was a problem with my new DescribePlace system when the USE_PLURAL_OBJECTS flag is set. I had copied over some code from the old one that checked for identical objects without finessing it into the new code. When this error made me take a look at the code again, I had to calculate exactly how useful the code was.

In the old DescribePlace, the lines in question prevent identical objects from being listed among objects-with-short_desc's. I started thinking, well, hey, why can't we have it both ways? I then altered my code to allow identical objects with short_descs and found that, ok, ListObjects (the routine that tallies the identical objects) lists the same total regardless of which objects have already been described. So, long story short, there's now some code in there preventing that from happening.

There's still some work to do with the new DescribePlace. Right now, I think objects and characters with descriptions always have to be listed before their description-less counterparts. Eventually, I should see if I can make the order truly interchangeable. I'm not sure how often that situation comes up, but it'd be good to support it just the same.

goods news, bad news

So, after some more playing, it turns out that the game I was testing the 16-bit interpreter with, the Vault of Hugo, won't restart even if you only use the standard library (also, a small Roodylib game will still restart in the 16-bit interpreter). If I drop the HugoFix debugging suite and identical and plural object support from Vault of Hugo, the game will work, but add either one of those and it's back to shenanigans. I take this to mean that the issue is deeper than anything I can do to fix.

For the most part, not being able to provide games for the 16-bit interpreters isn't a big loss. It'd really only be useful for things like the @ party thing mentioned in the last post (although it's still very possible that IF doesn't even need to meet the 1992 requirement) or targeting other real die-hard retro fans.

When I do the @ party thing, I'd like to go somewhat hardcore. I think that means that I'll probably have to use ZIL for that, which is cool, but my only regret is that it's probably too late this year for me to write a ZIL game in time for @ party. Still, next year, the @ party might be a great thing for a ZIL competition to piggyback on to.

not surprising, but disappointing

A recent post on the int-fiction forums informed me that @ party demoscene gathering has continued to invite interactive fiction into its yearly competition. I had considered submitting something a couple years ago when I first heard about it (although at the time, it had one of those wordings where Inform games were preferred). Anyhow, not having heard about it at all since then, I had assumed that they had dropped the IF invitation.

I don't exactly have a game idea ready as much as a malnourished concept. We'll see if I turn it into something worthwhile.

While the Interactive Fiction section of the @ party rules doesn't request any particular requirements, one of the other ones requests that submissions be run on computers available in 1992 so I'm approaching it from the same angle. Out of curiosity, I tried compiling a couple games to see how the current Roodylib works with the 16 bit and simple Hugo interpreters.

Disappointingly, there were two problems that popped out at me right away. For one thing, the status line wasn't being drawn properly in the 16 bit interpreter. For another thing, both interpreters would hang when I tried to restart the game. That problem wasn't just Roodylib's DoRestart's fault, as replacing it with the original did not help. I think the interpreters were just out of memory.

As far as PrintStatusLine stuff goes, it seems that the 16 bit interpreter also miscalculates the screenwidth, just as the simple interpreter does. The actual screenwidth is one character shorter than the detected screenwidth (in the simple interpreter, it is two characters short). Possibly, this is DOSbox's fault, or possibly, print to works differently in each of these interpreters. Also, Roodylib's latest PrintStatusLine also doesn't work in the DOS 32-bit interpreter, either, but I, admittedly, do some strange window-drawing stuff in that. It works fine with the previous PrintStatusLine.

Anyhow, making Roodylib compile a game that works with all of these interpreters is probably impossible, especially since the 16 bit interpreter considers itself a non-MINIMAL_INTERFACE interpreter. Still, I put some stuff in Roodylib that specifically helps out interpreters like the simple interpreter, so it'd be a shame to stop supporting it altogether. I'm going to try to go through Roodylib and provide a switch for turning off unnecessary features, and hopefully the resulting games will still work with older interpreters. Authors will unfortunately have to compile multiple versions of their games (if they wish to support old DOS interpreters), but I don't really see a way around it.

That said, games compiled with the minimum-feature Roodylib probably won't work with extensions like newconverse.h, which is another shame. Oh well.

Update: Ok, it's not so much that the DOS 'terps are detecting the wrong width (although the simple interpreter still is short by one character), it's just that when they write the last character to the line, it automatically goes to the next line, whereas in the Windows 'terp, you can stop right there. Right now, I'm thinking that I'm going to make the Infocom-style status line (two spaces on the left and right sides) the default, regardless of whether you set the DESCFORM_F flag. Again, not optimal, but better than trying to code for every possible interpreter.

more character stuff

So, the character DoGet stuff mentioned two posts ago allows >GET ALL FROM <character>. I was thinking about how this will not always be optimal behavior and what to do about that.

There's probably a grammar-based solution (especially if you use Roodylib's GRAMMAR_HELPER stuff), and actually, that is probably the easiest way to deal with it.

Still, if you want to avoid grammar-tampering, another way to do it is to replace the ExcludeFromAll routine:

replace ExcludeFromAll(obj)

{

if obj is hidden

return true

! Exclude things NPCs are carrying unless the NPC is explicitly

! given as the parent

if parent(obj) is living

{

! if IsPossibleXobject(parent(obj)) or parent(obj) = player

! return false

return true

}

return false

}

Making sure it always returns true when the parent is living gets the player a "Nothing to get." message when he tries >GET ALL FROM <character>. To change this, we'll need to add a case to NewParseErrror:

replace NewParseError(errornumber,obj)

{

     select errornumber

case 9

{

if xobject is living and children(xobject)

{

"You will have to specify one object at a time."

return true

}

else

return false

}

         case else : return false

     return true

}

So yeah, that's that. To do more complicated behavior, like allowing the first item but not allowing the rest, I'd probably incorporate the use of a global or, more likely, the word array (with SaveWordSetting and CheckWordSetting), but that  scenario is unlikely enough that I won't put it together unless I need it myself or someone asks for it.

Roodylib 3.2 has been released

Just since practically everyone who uses Roodylib follows this blog, yes, I uploaded the latest version of Roodylib and it is available at the usual spot:
http://hugo.gerynarsabode.org/index.php?title=Roodylib

always more to do

I have to admit that recently, I've been yet again not working on my own games but have found a distraction. I've been applying Roodylib and my extensions to somebody else's already-released game-with-available-source-code. Mainly, I've been curious how well my code can integrate with other games and whether it helps the overall playing experience. So far, I'd say the results have been fairly promising, although the experience has brought some more issues to my attention

Objects Can Be Grabbed From the Possession of Friendly Characters Without Comment

I was kind of surprised to find out that a character has to be unfriendly to refuse you from taking its possessions, and when you do take possessions from a friendly character, you just get the default "Taken." message.

Now, without modifying Roodylib, there is this solution:

replace character
{
   type character
   pronouns "he", "him", "his", "himself"
   capacity 50
   holding 0
   is living, transparent, static
   exclude_from_all true
   before
   {
      parent(object) DoGet
      {
         local l
         l = string(_temp_string, self.name)
         l--
         print "Nah, that is "; The(self);
         if _temp_string[l] = 's'
         {
            "'."
         }
         else
            "'s."
      }
   }
}

The above disallows taking things from friendly characters. To allow it, you'd have to replace the before routine with something that calls Acquire and prints its own "so-and-so lets you have the <blank>" message.

Just in thinking about the issue while I write this post, I think I will update Roodylib so that DoGet calls a character's after property to allow for different messages when you take objects from friendly characters.

EDIT: Actually, looking at DoGet closer, it already has a parent(object).after check, so I think I'll just give a default after routine to the character class.

Platforms Get No DescribePlace Love

While testing my code, I also noticed that contents of scenery platforms were not being listed by DescribePlace. The game (and others) have gotten around this by having code like this in a room's long_desc:

if child(self)

Perform(&DoLookIn, self)

else

"There's nothing on it."

Really, though, I can't think of a reason why you wouldn't want DescribePlace to handle platforms automatically. You can always deny content listing for &DoLookAround in list_contents, if you want.

The original scenery-contents check looks like this:

         if obj.type = scenery
         {
            obj is known
            if player not in obj and
               (obj is open or obj is not openable)

My check now looks like:

if obj.type = scenery

{

if player not in obj and

! (obj is open or obj is not openable)

((obj is container and (obj is open or obj is transparent))  or

obj is platform) and obj is not quiet

There's probably some overkill in there, and hopefully I didn't introduce new problems.

Platform Problems Part 2

Another problem cropped up, where even looking at scenery platforms or containers like above didn't prompt a listing of their contents. Since I've run into a problem like this before, I quickly guessed that my DescribePlace had left those items with the already_listed attribute, which DoLook looks for before listing contents. At first, I tried updating DescribePlace to always remove that attribute from them, but the thing is, in my modular version of DescribePlace, I really want the author to be able to list objects in any order they want, and I didn't want to restrict them to always having to list scenery contents last.

In the end, I thought, huh, why does DoLook even care about already_listed, anyway? Those attributes will just be reset the next time DescribePlace is run. The only thing instance where I think the already_listed-check might be important is in the case of identical plurals, but in my cursory testing, removing the check has had no effect on identical-plural behavior. Guess I'll just keep the check off the next version of Roodylib and see what problems pop up.

Speaking of Roodylib, I should probably upload a new official release soon. I guess I've been putting it off. I think I'll probably do something about that DoGet issue mentioned above, and here is some other stuff that'll show up in the new version:

 * added a missing printed bracket in parser monitoring code

* added NEW_EMPTY system for more container/platform-emptying options

* added AMERICAN_ENGLISH flag to switch between quotation punctuation styles

* added NEW_DESCRIBEPLACE to give more DescribePlace options

* added WhatsIn replacement and ListObjects RLibMessage-call for more printing options

* updated CenterTitle to not draw extra window in simple, non-Glk terps

* Fixed some places in the supercontainer class that didn't work right with transparent supercontainers.

* Fixed a problem where non-door items with door_to properties weren't being accepted by DoGo. Probably still some perfecting to do on this one.

* Attachables DescribePlace code was missing some parentheses.