worst case scenario

Grrr, so annoyed. While testing out that fuses code today, I noticed that games compiled with recent versions of Roodylib don't have enough memory for even one UNDO. Truth be told, I often test new code with Gargoyle since the Gargoyle window is so unobtrusive, but Gargoyle's UNDO buffer is so small that I probably didn't blink twice when newly compiled games were unable to compile.

Testing now with Hugor, Roodylib has been short on UNDO memory since before I started uploading to bitbucket (and definitely before the 3.0 release I uploaded to the IF Archive).

The good news is, getting rid of just one for loop called by PrintStatusLine freed up space for one UNDO, and compiling without my new fuse code frees up memory for even more.

The bad news is, now I need to go through all of Roodylib with a particular eye for optimization. Having games unable to UNDO is unacceptable. I've long been worried that I'd run into this problem, but it is quite annoying to have to deal with it.

My optimization strategy will consist of cutting any loops that I can and making sure that the others are as concise as possible. Beyond that, I've long been suspicious that Perform doesn't need to call SetUpDirectionObjects every time, and I think I'll see if I can move it somewhere else.

I'll make this one quick

I spent 10-15 minutes working on my WIP today. That gave me some motivation to play around with newconverse a bit more. The good news is:

1. Got all types of "[ undoing (last command)]" working to my satisfaction.
2. Moved whatever I could from npc.parse_rank (npc being newconverse's character class object) to ConversePreparse, just because PreParse is only called once per turn while parse_rank is called a lot. In parse_rank, I kept some code that sets a verbroutine value if there isn't one, as that doesn't work in PreParse since the engine clears verbroutine after Parse is finished.
3. Successfully made newconverse both roodylib and non-roodylib compatible. As much as I'd love everyone to always use roodylib, I'm making an effort for all of my extensions to standalone, if possible. That was too much work for cheaplib and colorlib (which now comprise part of the "roodylib suite"), but when I can, I will. Anyhow, it was very satisfying to get it working for both, as I originally thought I had to use some of roodylib's special features for optimal performance.

I think I'm done with newconverse and roodylib for a bit. The latest versions can be downloaded at http://roody.gerynarsabode.org/JC/newconverse.zip and http://roody.gerynarsabode.org/notdead/roodylib_suite.zip, respectively.

Newconverse could use a lot of documentation, and now that I think about it, I probably broke the peaceful coexistence of ASK/TELL characters and menu-driven-conversation characters (which I had purposefully supported with earlier versions of newconverse). I'll probably patch that up down the road, even if I might be the only person who thinks having both kinds of conversations in one game might be kind of cool.

more stuff

Ha, I had already forgotten what my last post was about, but having read it, I can say, my latest problem was a continuation of the old one.

So, newconverse has this feature where >UNDO can remind the player what is being undone:

> talk to man

The man's eyes catch the torchlight for a moment as he looks up at

you.

> undo

[ undoing >talk to man ]

Gloomy Hall

>

It exists for a couple different reasons. I think, originally, the point was so that in a game where >UNDO skips over whole conversations, I wanted a mechanism to allow for a "[undoing to before conversation]" (which it does, under the right circumstances). It's also useful because it clarifies what really is being undone. Sometimes, as Hugo game authors, we might accidentally put important game text or code in something that returns false or, just as likely, a player might perceive a turn as counting (when it did not). This feature always keeps the player in the loop as to what's being done. Take, for instance:

 > talk to man

The man's eyes catch the torchlight for a moment as he looks up at

you.

> sleep

Not now--there's work to be done.

> undo

[ undoing >talk to man ]

Gloomy Hall

>

 ANYWAY...

So I noticed that the above feature was having a conflict with the issue from the last post. If you type only an object, the engine runs FindObject. After that, it jumps straight to SpeakTo. Oddly enough, it clears the word array before calling SpeakTo so my undo-command-saving code (which I stuck in an event, as that runs after every successful turn) wasn't saving the command properly (as concise as it was).

Anyhow, lots of futzing later, I got it working, but I also found out that a major culprit to it not working had been that while roodylib uses the word array to save states during UNDOs, RESTOREs, and RESTARTs, I was saving too low on the word array so some of it was actually being written over after a successful UNDO, screwing over the word-array-checking after-UNDO code.

I don't know how well I described all that, but that's what I did today!