Roodylib v 3.7

Of course, as soon as I submitted that last version, I remembered some other things I had meant to put in.  Luckily, a couple other things popped up along the way so this update isn't quite as minimal as it could be.

Get it here: http://hugo.gerynarsabode.org/index.php?title=Roodylib

v 3.7 -
        * Added CallFinish, MakePlayer, CoolPause, PauseForKey routines
* Updated shell files to make it easier to turn Roodylib off (for tracking errors down to original library code)
* Updated credits text

Roodylib version 3.6 release

Uploaded a new Roodylib.  Mainly, it fixes some things that Juhana Leinonen found in his Hugo dabbling.  Go download it from Hugo By Example or the Hugo Code Lab (up in the links section to the right).

v 3.6 - * Added DoOpen replacement
* Fixed a ParseError bug (caused by me, not original)
* Added DoGet replacement, updated CheckReach for dealing with instances where the player is in a closed enterable
object and is trying to get something else in the same object

I'm no good at versioning

I recently ran into some annoyances with my WIP where I realized that Hugo's default message for GO-ing at a non-enterable object is "You can't enter that."  I think, more often than not, GO TO <object> will be typed by an IF newbie unfamiliar with IF's world model.  I have updated DoGo to reflect this.  It now results in a "<the object> is right here." message.

Anyhow, I had forgotten that I had already uploaded a version 3.5 of Roodylib (in my memory, I was still sitting on some changes for the next version), so I have uploaded another version 3.5.  Don't care enough right now to change it.

Other things:

• Been meaning to write a game design theory post with thoughts about designing routines for jumping around your game.  My WIP has several dream and flashback sequences that can be triggered almost whenever so debugging theory has been on my mind.
• I asked Kent for some ideas for responses for the "You can't enter <the object>." replacement mentioned above.  Besides giving several responses, he jokingly suggested randomizes between them.  It didn't sound like a terrible idea, though.  While I wouldn't provide multiple, random responses to something like verbstub verbs, I could almost imagine randomized responses for some hugolib-centric messages, like ParseError or something.  Ideally, it could give the illusion that the parser/library is more robust than it is.  Still, at the moment, it's probably not worthwhile to go through hugolib and decide which responses could be multiplied.  More important things to do.

Roodylib update

After months of neglect, I've uploaded a new Roodylib.

One is the DoExit bug mentioned in the last post.  Additionally, there are some verb things suggested by Mike Snyder.

Not sure if I ever properly uploaded the previous release (3.4), so here's the changelog from that, too:

v 3.4 - * Updated DescribePlace so it can be called without arguments
* Found another USE_PLURAL_OBJECTS DescribePlace bug in the NEW_DESC stuff
* Updated SpecialDesc, WhatsIn, DoTakeOff
* Checkheld versions of DoWear and DoTakeOff
* Updated FindObject, ExcludeFromAll, VerbHeldMode, SpeakTo, CheckReach
* DoLookIn no longer requires container grammar (now works with non-container, transparent objects)

As always, Roodylib can be downloaded here:
http://hugo.gerynarsabode.org/index.php?title=Roodylib

new old bug! (DoExit)

We've had some new eyes looking at Hugo code lately, and sometimes that's all it takes to discover a long-existing bug.  Don't really know how it didn't turn up before, but this person noticed that when the player is in a closed, openable, and enterable container, typing "OUT" would result in "Nothing is closed."

Initially, I was worried that this was due to the SetUpDirectionObjects routine not properly setting the object global to the out_obj object (since I still don't entirely trust how Perform uses that routine), but the problem turned out to be in DoExit itsellf (in fact, the out_obj doesn't really matter when DoExit is called since almost all applicable error messages will mention the parent of the player, if anything).

The problem turned out to be that the "so-and-so is closed" VMessage text was expecting the object global to exist, and DoExit wasn't properly defining it in that instance.  So, here's a version of DoExit where that is fixed:

replace DoExit

{

local p

#ifclear NO_OBJLIB

! >GO OUT winds up calling DoExit with object = out_obj, thanks to

! the direction-parsing code in Perform().  English ambiguities being

! what they are, we correct that interpretation of "out" here, and

! treat the command as a generic instruction to exit whatever

! container context we may be in.

if object = out_obj

object = nothing

if object = nothing or object = location

{

if player in location and out_obj in direction

{

word[1] = out_obj.noun

word[2] = ""

return Perform(&DoGo)

}

}

elseif object = d_obj and player in location

{

return Perform(&DoGo, object)

}

#endif

p = parent(player)

#ifclear NO_OBJLIB

if object and player not in object

#else

if object and player not in object

#endif

VMessage(&DoExit, 1)             ! "You aren't in that."

elseif p is openable, not open

{

object = p

VMessage(&DoLookIn, 1)           ! "X is closed."

}

else

{

if object = nothing

object = p

move player to location

if not object.after

VMessage(&DoExit, 2)     ! "You get out.."

}

return true

}

Of course, this will be added to future versions of Roodylib.

Dead Laptop

So, a couple nights ago, my laptop died.  Now, as far as my Hugo stuff goes, that isn't extremely dire.  First off, I was pretty good about uploading Roodylib and other extension stuff to my bitbucket account as I worked on it, so, at most, the bitbucket version might be missing a day or two's amount of work.  Also, I backed up all of my game work in progress code before a trip some months ago, and both fortunately and unfortunately, I've been so bad about working on my games in progress the last several months that there isn't probably a whole lot changed between what-I-most-recently-had and what-I-have-backed-up (I did recently have my games open and did a whole lot of code-cleaning and optimizing, but no real new content was added).

Beyond that, I'm pretty sure the hard drive in my defunct laptop is ok, so I should be able to retrieve all of my old data once I get an external dock or something.  Between that and the fact that I was in a midsummer coding slump anyhow, I'm not in any real hurry to work on anything in the near future.

Mainly, I'm just kicking myself for not making better use of today's free cloudspace so I had more of my data still at my fingerprints.

As far as music goes, while I don't have my ~100 GB mp3 collection uploaded anywhere, all of my purchased-from-Amazon mp3s are always available in the Amazon Cloud Player (plus the extra 240 songs I could fit into my remaining free space).  My Amazon music might make up for a fraction of my overall collection, but it's still 4000 some songs so it's not shabby, either.  Plus, some of my music is on last.fm, too, so I can just sign into that and do the playlist where it only plays songs it has already played previously in my music library. Lastly, spotify can be good for individual album listening.

My bought games can all be re-downloaded, but I have to say that I'm especially glad that Steam has added cloud saving.  It is really nice that I don't have to restart on the few Steam games I really cared about.

My coding projects are mostly in various states of "backed-up".  The most backed up projects I have are the ones that I share with Robb Sherwin and are repo'd.  It's a really nice thing that with a repository, you always know you have the working copy of something.  On the other hand, I'm currently borrowing time on somebody else's laptop, so I'm not sure if I'm actually going to install repo software on it.

Robb Sherwin also set me up with a linode server account, so maybe I should have kept all of my stuff on there.  Also, maybe I could just bitbucket all of my game code, besides just library stuff.

There's also just being better about backing up to USB devices and stuff, but that's such an easy thing to fall out of habit with.  Just the same, I wish I had been better about stocking a USB stick with as many of my favorite apps that support running from portable drives.

I'll also say that I was happily surprised that since I had used the multiple-user feature in Chrome on my dead laptop, when I added accounts to this temporary one, all of my bookmarks and passwords were instantly accessible.  Besides that, of course, all of my Google Docs stuff is already all save in the cloud.  On my old laptop, I pretty much used Chrome for just e-mail and productivity stuff (Google Docs, Google Tasks, etc.), but with how easy it is to have your stuff follow you everywhere, maybe I'll get in the habit of using it for more things.

I can understand why some people are distrustful of the cloud and warn people to not put all of their eggs in that basket. I agree with that, too, but there are still plenty of ways of using it to your advantage.  I'll try to be smarter about it in the future.

recent updates

So, first off, updating Roodylib to support non-container, transparent objects did take quite as many changes as I thought it would.  I just need to replace DoLookIn and add some more code to CheckReach and DoLook but that's basically it.  Now it's just a waiting game to see if I made more problems for myself.

Anyhow, let's get back to that situation the other day, where I was helping code a wearable coat with a pocket.  The problem was that its contents weren't showing up in inventory listings.  First, this required a change to WhatsIn to fix some spacing issues.  After that, I realized that SpecialDesc was only listing children-of-children if the object had more than one child, so I added some code to check for that when there is one child.

You can see the evolution of my code over at this thread: http://www.joltcountry.com/phpBB2/viewtopic.php?t=8938

While testing all of these compiled coats with their various pockets, I would often take the keychain from the coat pocket just to make sure inventory was still printing correctly even when the coat has no children.  At one point, I noticed that while >REMOVE KEYCHAIN FROM POCKET worked, >REMOVE KEYCHAIN alone did not.  I thought, huh, well, it really should be smart enough that if the object has a parent other than the player, it should be directed to DoGet.

So, I added some code to fix that, but in doing so, I noticed that DoTakeOff and DoWear both had multi grammar tokens, so out of curiosity (and since my test game had both a coat and the player wearing some shoes), I started testing the commands >WEAR ALL and >REMOVE ALL.

Oddly, I found that the multi grammar token defaulted to not-held items, so both of these commands often would respond with things like "Nothing to wear." I thought, huh, I'll fix that!

So, besides playing around with grammar, I tracked down the problem to hugolib's VerbHeldMode routine, which redirects the parser to held or not-held behavior based on the verb being used.  I also turned on the checkheld system and added some code to FindObject.

By this point, >WEAR ALL and >REMOVE ALL were working correctly, but the results had the player trying to wear or remove everything in his inventory, so I added some code to ExcludeFromAll so non-clothing items would be ignored.

Long story short, Hugo is now "AIF"-ready!

Welcome, AIF Authors!

So yeah, Hugo can now accept >WEAR ALL and >REMOVE ALL.  Still, I wasn't excited about the prospect of default Roodylib behavior making it too easy to disrobe, so I thought, huh, maybe I could do something about that, too.

In the end, I changed ExcludeFromAll so that in the default behavior, it excludes all clothes, too, and in the case of DoTakeOff and DoWear, I changed the ParseError message to "Be specific about what you'd like to <blank>."

So, that means something like >WEAR PANTS AND FUNNY HAT will still work, but >WEAR ALL will get the "Be specific..." message.

Of course, if you want >WEAR ALL to work, all you have to do is set the new "AIF" flag.

My one point of conflict right now is that >REMOVE <object>  gets directed to DoGet even when the object is in your location (and not a child of something).  On one hand, I feel like I should give that instance a "you can't do that." message, but on the other hand, I wonder if there are room descriptions where "remove" will feel like an applicable verb (and I imagine that most players wouldn't notice that it works there otherwise).  Feel free to weigh in!

So yeah, I'll try to get the latest Roodylib uploaded to HbE soon enough so anyone who wants to play around with this stuff can do so.