let's break "checkheld"

[Roody_Yogurt]

If you compile a game with the standard library with the USE_CHECKHELD flag set, certain actions are no longer limited to the grammar token "held". For instance, if you try to PUT a non-held item INTO a container, it'd first call ImplicitTake and automatically pick up the item first, if possible. If it is not possible, the action is still canceled.

Eventually, I think I'd like to code a scenario where an item doesn't even need to be picked up to be moved (for certain object-manipulation puzzles), but before I can do that, I need a better understanding of the checkheld system's failings. According to its own commenting, there are some problems with it and we are advised not to use it.

I've done some testing myself but haven't found problems yet. Anyhow, I thought maybe some of you might want to turn on #USE_CHECKHELD in your games and see what kind of crazy behavior pops up.

[Roody_Yogurt]

So, one of the first successes of this year's Open House comp is that a bug reported by Flack was traced to checkheld behavior- WE BROKE CHECKHOLD FOLKS!

So, the deal is, the checkhold system uses a checkhold object that isn't entirely unlike the "configuration" objects I've been using for my various extensions. The thing is, when using commands with "ALL", it also moves the checkhold object to the current location to keep track of where the action is. Also, when "all" is used under checkheld, everything the player is holding is moved to the location and given a checkheld_flag.


After all action-running is done in Perform, it runs this routine called ResetCheckheld. Among other things, it checks for objects with checkheld_flags and if their location is the parent of the checkheld object and then moves them back to the player object. This works great for commands with "all" where the checkheld object is in the current location.

Now, in the Clockwork Boy 2, throwing a piece of paper in a certain place would remove it from the game (using the 'remove paper' command). The thing is, since the checkheld object hadn't been moved to the location (after all, it wasn't an "all" comand), its parent was "nothing", and removing the paper gave it the same parent.

So, ResetCheckheld would confuse the paper for a held object that was dropped for some checkheld verb and then move it back to the player object.

Of course, there are various ways to fix this. I could move the piece of paper to some kind of storage room or object so its parent was not nothing. A lot of games out there use void objects and rooms just to avoid this kind of thing.

Still, I like the simplicity of the 'remove [object]' command and refuse to give it up. The next version of roodylib will have this code:

Code: Select all

#ifset USE_CHECKHELD
object checkheld_holder
{}

replace checkheld	! 'active' when active; 'plural' for "~all", etc.
{
	misc #CHECKHELD_LIMIT
	size 0		! # of managed objects being managed
	is hidden
	in checkheld_holder
}

replace ResetCheckHeld
{
	local i, obj
	for &#40;i=1; i<=checkheld.size; i++&#41;
	&#123;
		obj = checkheld.misc #i
		if obj is checkheld_flag and obj in parent&#40;checkheld&#41;
			move obj to player
		obj is not checkheld_flag
	&#125;
	checkheld.size = 0
	checkheld is not plural
	checkheld is not active
	move checkheld to checkheld_holder
&#125;

#endif

I both create a checkheld_holder to keep the checkhold object in when not in use, and I move checkhold back to its holder after every action. It's possible that second thing will get me into trouble (depending on how many actions are carried out per turn). We'll see.

Anyhow, I'm sure there are more problems out there, so stay vigilant! Still, we are one step closer to a fully-working checkheld system!

[Flack]

Somehow I was able to find a bug without understanding anything Roody said. Merry Christmas!

[Roody_Yogurt]

I would guess that even other Hugonauts have to stare at my descriptions a while for them to sink in (not because my understanding is so great but because my communication abilities are so lackluster).

[Roody_Yogurt]

This post isn't about the checkheld system, but like the checkheld system, I took notice of another part of hugolib's code that wasn't being utilized. Hugolib forces what it calls "old style pronouns" since the new style didn't work well with certain grammar. I feel comfortable re-enabling the new style pronouns for Roodylib, as long as people are aware of its limitations.

The benefit of using the new style system is that when players refer to objects that you, the author, have moved out of scope, it no longer prints the "(Assuming you mean the so-and-so) That isn't here.", which can sometimes make your game look dumb.

I've already mentioned this over at Not Dead Hugo, but I also put a page about it on HbE: http://hugo.gerynarsabode.org/index.php ... E_PRONOUNS

(The text of that is taken from the Roodylib documentation)