one more colorthing...

I forgot, when announcing my colorthing.hex color palette program, to remind everybody that colors are not the same across platforms, so still be aware that what looks cool on Windows might be totally unreadable in Linux (just another good reason to use the roodylib-bundled colorlib extension). Still, sometimes you just want to write a game that looks cool on your system.

Anyhow, I've updated the colorthing.hex file to include that information. Also, that file has the latest version of that HugoFix stuff I was talking about, so typing "$ot 0" should give you an idea of how windows and replaced objects are listed.

So, today was another day where my optimal coding window was in a place where I didn't have much privacy so I didn't work on game-y looking things. I was getting writer's block with the LibreOffice document I've been jotting room descriptions in, so I opened up my update to Christopher Tate's conversation system extension, as I've been meaning to do some things with it.

First, I checked over the properties I created for it and made sure they were alias-able, then proceeded to alias them. Then, I added some more comments to help some of my additions look more organized.

Looking over it now, I think I'm going to routine-ize more of the messages to make more responses configurable. There's a couple other tiny things to do, but overall, I'm thinking it's almost ready for an official release (well, an official upload to HbE, anyway... an ifarchive upload is a long ways off).

To remind people, this conversation system update aspires to give authors several menu conversation options. Conversation options can be at the top of the screen or in game text. Conversations can be topic-based, and players can be informed (or not) of available topics. There's a fair amount of mixing-and-matching available, too. Let's see some screenshots!

Main-text conversation menu, no topic-switching

Top-based conversation menu, topic-switching allowed

go hug an object tree

The good news is, I've actually been writing game text lately. It's been slow going, but I basically have the opening to my new game done. It's coming together.

Now, this aforementioned game should have a couple color changes when its done, but I haven't decided on the color combinations yet. I was getting pretty sick of trying colors blindly. I thought somebody had made a utility that showed all of the available colors, but I couldn't find it so I coded my own: http://roody.gerynarsabode.org/notdead/colorthing.hex

While putting it together, for some reason, I was using HugoFix's "$ot" command to look at the object tree. All of the blank (no-named) objects due to my sample game's many windows bothered me, so I updated DoHugoFix's (and its companion routine, DrawBranch's) code so that the following usually-blank items now have a description:

1. Object 1 is now listed as the display object, which it should always be in a standard library-using game.
2. I gave the window_class object in "window.h" the type "window_class" so it can be checked for. Window objects get some special window-printing code.
3. All other unnamed objects are assumed to be replaced objects and are listed as such.

Note: Even unnamed objects are given a name by the compiler- the object's name within parentheses. Window objects are special in that they override this behavior by declaring their name as "" (window names are assumed to be window titles that need to be printed underneath the applicable window). So, other than window objects and replaced objects, it is unlikely (though not impossible, of course) that an object will be without a name.
 
So yeah, admittedly, that's not the most important roodylib addition I've ever written, but I like it enough.

Other than that, I noticed that Hugor is not handling the MATCH_FOREGROUND constant correctly, so the input color is coming out wrong on some games. I e-mailed Nikos about it, although maybe I've said something about it before as the e-mail gave me a little bit of deja vu (the only implication here is that I'm so disorganized).

Oh, well, progress is progress!

another color oddity

So, today I was adding INPUTCOLOR support to my colorlib extension. After making my changes, I made a test case where the INPUTCOLOR changed every turn. Oddly enough, my game wasn't showing my input colors.

Eventually, I figured out that Hugo interprets:

color <first value>, <second value>

as:

color <first value>, <second value>, MATCH_FOREGROUND

This means that hugolib routines like PrintStatusLine, Menu, and CenterTitle automatically overwrite any non-default input colors you have set. I have updated the relevant routines in roodylib.h and newmenu.h, but anyone who is using non-default input colors in their game(s) should be aware of this.

a color conundrum

In a game that uses non-default text/background colors, UNDOing after a full-screen-color-change will result in "islands" of the old colors on a screen  of the new backgound color. This works in contrast to systems like TADS where changing the background color can be done without clearing the screen. The way Hugo handles it is not necessarily a detriment; I have an idea for at least one game idea that wouldn't work if Hugo worked the other way.

Still, it introduces an interesting dilemma- is there a way for the library to handle such UNDO situations in a non-obnoxious manner? I've been thinking about this since yesterday.

Instead of trying to design some complicated word-array-saving technique to keep track of colors (as the word array is one of the only things not affected by UNDOs, RESTOREs, and RESTARTs), I eventually decided that the best way to handle this will be to write a configuration-file-writing library extension. All of the Hugo ports that I know of that support color also support configuration files, anyway.

The hardest part will be deciding what kind of naming scheme I want for the configuration file so it plays nicely with other games that use the same extension.

Anyhow, when it's written, it should be appreciated by color-lovers and color-haters alike (as it will also give players options to "opt out" of color changes).