Error Message when trying to Release...

Hello - I’m testing the Automap extension in a small example game, the code I’m using is below and seems to run fine inside Inform7, however when I go to Release it so I can play it via Gargoyle I keep coming up with the error message which I’ve tacked on at the very end of this post. I have no idea how to resolve it. If anyone could tell me what I’m doing wrong I would much appreciate it. Thanks for any help!

[code]“Glimmr Automap Test” by Dustin Neff

Include Automap by Mark Tilford.
Include Glimmr Automap by Erik Temple.
Include Glimmr Automap Tileset by Erik Temple.

Include Glimmr Bitmap Font by Erik Temple.

Section - Compass

Section - Compass End

[Before looking for the first time:
	say "This is a small example for Glimmr Automap, a graphical front-end to Mark Tilford's Automap extension. It generates a map as the player explores the world of the game, with very little effort needed on the part of the author.

This example for the Glimmr Automap extension adds new behavior to our procedurally generated map. Clicking on a room in the map will now produce the command GO TO <ROOM>. To query the map about the name of a room, press the ? button, then click on the room you wish to query. Zoom the map by using the + and - buttons."]

Use automap hide paths through closed doors.

The map-window is a map-display window spawned by the main-window. The position is g-placeabove. The measurement of the map-window is 50. The associated canvas of the map-window is the map-canvas.

The map-canvas is a g-canvas. The associated canvas of a g-element is the map-canvas.

When play begins:
follow the opening up the map window rules.

Understand “[any room]” as going by name. Understand “go to [any room]” as going by name.

Going by name is an action applying to one thing.

Check going by name:
if the noun is the location, say “You’re already in [the location].” instead;
if the noun is not adjacent and the noun is unvisited, say “That noun did not make sense in this context.” instead.

Carry out going by name:
let aim be the best route from the location to the noun, using doors;
if aim is not a direction, say “You can’t think how to get there from here.” instead;
say “(heading [aim])[command clarification break]”;
try going aim;
if the location is not the noun, say “You’ll have to stop here.”

Automap graphlink rule for a room (called the target):
let target-text be the printed name of the target in upper case;
change glulx replacement command to “GO TO [target-text]”;

Section 1 - Hit Points

A person has a number called maximum hit points. A person has a number called current hit points.

An animal has a number called maximum hit points. An animal has a number called current hit points.

The maximum hit points of the player is 35. The maximum hit points of the animal is 5.

When play begins:
repeat with victim running through people:
now the current hit points of the victim is the maximum hit points of the victim.

Definition: a person is dead if his current hit points are less than 0.

[Section 1.1 - Diagnosis

Diagnosing is an action applying to one visible thing. Understand “diagnose [something]” as diagnosing.

Check diagnosing:
if the noun is not a person, say “Only people can have diagnoses.” instead.

Carry out diagnosing:
say “[if the noun is the player]You have[otherwise][The noun] has[end if] [current hit points of the noun] out of a possible [maximum hit points of the noun] hit points remaining.” ]

Section 1.2 - Weapons

A weapon is a kind of thing. A weapon has a number called the maximum damage. The maximum damage of a weapon is usually 4.

The player carries a weapon called a mace. The maximum damage of the mace is 3.

Understand the commands “attack” and “punch” and “destroy” and “kill” and “murder” and “hit” and “thump” and “break” and “smash” and “torture” and “wreck” as something new.

Attacking it with is an action applying to one visible thing and one carried thing. Understand “attack [someone] with [something preferably held]” as attacking it with.

Understand the commands “punch” and “destroy” and “kill” and “murder” and “hit” and “thump” and “break” and “smash” and “torture” and “wreck” as “attack”.

The attacking it with action has a number called the damage inflicted.

Setting action variables for attacking something with something:
let the maximum attack be the maximum damage of the second noun;
now the damage inflicted is a random number between 1 and the maximum attack.

Check an actor attacking something with something (this is the can’t attack with something that isn’t a weapon rule):
if the second noun is not a weapon:
if the actor is the player, say “[The second noun] does not qualify as a weapon.”;
stop the action.

Check an actor attacking something with something (this is the can’t attack a non-person rule):
if the noun is not a person:
if the actor is the player, say “[The noun] has no life to lose.”;
stop the action.

Carry out an actor attacking something with something (this is the standard attacking it with a weapon rule):
decrease the current hit points of the noun by the damage inflicted;
if the noun is dead, remove the noun from play.

Report attacking a dead person with something (this is the death-report priority rule):
say “You attack with [the second noun], killing [the noun]!” instead.

Report attacking someone with something (this is the normal attacking report rule):
say “You attack [the noun] with [the second noun], causing [damage inflicted] point[s] of damage!” instead.

Section 2 - Scene

The Courtyard is a room. The Palace is north of the Courtyard.

The guard dog is a male animal in the Courtyard. The description is “He looks mean and nasty.”

There is a club in the Courtyard. “There’s a gnarled old club here studded with thorns.” Understand “stick” as club. The club is a weapon.

Instead of going north in the Courtyard:
if the dog is in the Courtyard:
say “The dog snarls at you and won’t let you through the door!”;
continue the action.

The Fountain is west of the Courtyard.

The Drawbridge is east of the Courtyard.


When I Release so I can play the example with Gargoyle I get this error:

Packaging up for Release - Failed

Glimmer Automap Test Materials
Glimmr Automap Test.gblorb

Inform translated your source text as usual, to manufacture a ‘story file’: all of that worked fine. But the Release then went wrong, for the following reason:

Fatal error: unable to read data: filename ‘C:\Documents and Settings\Loree\Desktop\Glimmer Automap 02-27-2011\Glimmer Automap Test Materials\Figures\Automap_Tileset_059.png’

It looks like the file Automap_Tileset_059.png is missing from your Materials–>Figures folder. Inform doesn’t care if you’re missing files when you’re playing the game in the IDE, but it’s very picky when you do a release (for obvious reasons).

If you downloaded Glimmr Automap before September 22 of 2010, that file and a few others were missing (sorry!). You can download the most recent full Glimmr package to get them; see my signature for the link.


…or I guess it’s possible that you have the file, but it’s corrupt. Either way, getting it from the latest release should fix things.

Thanks for your help, I thought I downloaded the latest package but must have been mistaken, so I’ll do that now. BTW, I’m new to this, but does one of your Glimmr extensions allow you to place a background image behind the automap?

I’m not sure sure if you’ve played the King of Shreds and Patches–or if he used your automapping–but that’s along the lines of what I had in mind. Just curious. Thanks – Dustin

Ugh, actually the newest version is also missing those tiles… Somehow, I managed to introduce some strange atavism into my file archives when 6G60 was released. Anyway, I’ve just posted release 3.3, which restores the missing tiles. Thanks for your patience!

I realized I forgot to answer your question about the background image, so here goes:

The map in King of Shreds and Patches is not an automap–it was carefully laid out and programmed to reveal itself room by room as the player explores. In this, it is more like the map in the Glimmr Canvas-Based Drawing examples, or in this blog post. More to the point–because it was laid out in advance, the KoSP map always looks consistent over its background.

Automaps, on the other hand, are autogenerated and automatically sized to best fit in the available space; they may also be displayed at multiple scales/zoom levels. When you combine this with the fact that, in Glulx, the author can at most control one dimension of the graphics window and can never control the aspect ratio–well, it’s just not likely that you’re going to get as consistent a result. Faced with this, Glimmr Automap simply drops the idea of a background image; instead, the canvas on which the map is rendered is resized as necessary to fit the optimum number of tiles onscreen. This means you have to do more work to make a background image work well, because there is no fixed canvas to pin it to.

One way to get close is to restrain as many of these variables as you can. Here’s some code that fixes one measurement of the window, as well as allowing only one size for tiles:

[code]The measurement of the map-window is 310.[This sets the window split to 310 pixels. You might want to use a different value, of course.]

The zoom-level set of the Glimmr Automap Tileset is {0.3600}. [This trims us down to 1 zoom level, the most zoomed out.]

The initial zoom level of the Glimmr Automap Tileset is 1.

The display status of the UI-frame is g-inactive. The display status of a UI-button is g-inactive. [With only one zoom level, we don’t need the UI buttons.]

map-background is a sprite. The display-layer is 0. It is center-aligned. The image-ID is Figure of Map.

Element scaling the map-background:
let coords be the center-point of the map-canvas;
now entry 1 of the origin of map-background is entry 1 of the coords;
now entry 2 of the origin of map-background is entry 2 of the coords.[/code]

With the window-size variation reduced, we can have a bit more control over how the image will be displayed. For even more control, you can set maximums for the width and height of the automap display (# of tiles); see the Automap documentation.

Another option would be to write a special rule to display the background image so that it is scaled to fit the window, ignoring the canvas entirely. We can cheat a little bit–the map background is here defined as a sprite, but in fact we won’t use the standard rules for scaling or displaying sprites (sneaky, huh?)

[code]map-background is a sprite. The display-layer is 0. The image-ID is Figure of Map.

Element scaling rule for the map-background:
rule succeeds.[We don’t need to do the standard scaling, so skip it to save time.]

Element display rule for the map-background:
let win_width be the width of the map-window;
let win_height be the height of the map-window;
let img_width be the image-width of the image-ID of map-background;
let img_height be the image-height of the image-ID of map-background;
let scale_factor be 100;
let width_factor be (win_width * 100) / img_width;
let height_factor be (win_height * 100) / img_height;
if width_factor is greater than height_factor:
let scale_factor be height_factor;
let scale_factor be width_factor;
let img_width be (img_width * scale_factor) / 100;
let img_height be (img_height * scale_factor) / 100;
let offset_width be the greater of 0 or (win_width - img_width) / 2;
let offset_height be the greater of 0 or (win_height - img_height) / 2;
display the image-ID of map-background in the map-window at (offset_width) by (offset_height) with dimensions (img_width) by (img_height).[/code]

The two options will look a bit different, so try 'em both. I think I like the second one best, personally. With both options, keep in mind that the Automap will change focal point and shift as the player uncovers more of the map, so you’ll never have the kind of consistent display that KoSP has. To get the exact behavior of the KoSP map, where the map is fixed in place over the image, you’d be better off going with Glimmr Canvas-Based Drawing, maybe using the Canvas Editor to build it, as discussed in this tutorial.

Hope that helps!


EDITED to fix an incomplete thought…

Thanks a lot the second example works great! BTW, anyone who wants to create an automap can work with this example to make a header/automap for their game, as in this example:

That looks really nice, thanks for posting it! I’ll try to fold that method into an example for the next release of Glimmr Automap.

The default tiles seem to look good with your background, but just FYI for you and anyone else who comes to this thread: You’re perfectly welcome to edit the tiles to change their colors (easily done with selective color selection/shifting in Gimp or Photoshop), or to create your own tile designs. The release package includes the original tileset art in a format suitable for import into Adobe Illustrator or Inkscape, for use as a template.


Thanks I’m definitely going to try creating some new tiles to experiment with. I think this is both a great way to add some window-dressing to an IF game, and communicate some useful information to the player. What would really be great, IMO, is another button which could open up a notepad or journal, so the player could take notes and store them, then call them up anytime for review with a mouse-click (should anyone want to take up the challenge of implementing it). Or if you could make little sticky notes and comments specific to each room on the map, which would appear with the tooltip query, and you could enter little comments to remind you of stuff in that room. But anyway thanks again for this example I’ll keep working with it!

I’m not feeling quite ambitious enough to implement it, but I think a notepad would be a great feature.

The image is really nice - really makes me want to go play.

Thanks for the ideas. I think I’ll leave those interface suggestions for other people to implement, though. With Glimmr and my other extensions, I really want to encourage people to try many different kinds of things on the UI side–as well as different implementations of the same things–so the idea of wrapping Glimmr Automap into a fully prepackaged interface isn’t something that I personally find motivating. (Glimmr Automap was really just a way to explore the use of Glimmr to deliver a “plug-and-play” option for authors, and since Mark Tilford’s Automap was right at hand and relatively easy to hook into, I went ahead and did it.)

But, of course, if anyone else wants to do a little work to create the kind of UI package that dustinneff is describing, please feel free to utilize/adapt Glimmr Automap as needed!

By the way, Glimmr Automap is Quixe-friendly–it will use a text-only (the one provided by the Automap extension–ASCII or Unicode) map in interpreters that don’t support graphics. If you are considering creating One Interface to Rule Them All, you might want to extend it with the same “graceful degradation” (as the javascript programmers say) in mind.


I’m not sure if anyone who’s used Glimmr Automap has come across this, but in certain places when the map is being drawn onscreen the rooms will overlap each other, covering up the locations of rooms you’ve visited previously. I’m not sure if I missed something in the documentation which addresses this, or if I just have to be more careful in planning the map layout in advance to avoid overlapping, but it anyone knows of a fix or work-around to prevent this please share it here. Thanks!

I’ve never seen that. Does it appear to be a display issue, or a map generation issue? Do you have a screenshot or two you could post?


Thanks for your help Erik, here’s a “before” and “after” screenshot showing how the rooms are overlapping:

w/nw/e/se (overlaps room started from)

It’s kind of a convoluted map example, and I can change the layout to avoid overlapping, was just wondering if anyone’s come across this before. - Dustin

Ah, I see what you mean. This just reflects the fact that the map has only one dimension. In other words, when Automap (Mark Tilford’s extension, the actual mapping engine) creates the map, it’s just a single array of tile references. If you have overlapping rooms, then the room that’s “on top” overwrites all data about the room “below”. This is just the way the Automap engine works (and, incidentally, one of the reasons it’s so fast). You can see this in purer form by releasing to Quixe and looking at the ASCII version of the map, or by using the “dump map” command in a debugging build or in the IDE; the latter will show the actual tile reference numbers.

The solution, as you note, is to tweak your layout. Or, where possible, to use Automap’s (somewhat idiosyncratic) mapping hints to specify how specific features should be mapped.

I like the look of your custom tileset. When you get around to drawing the icons (up, down, in, out, etc.), see if you can come up with something better than I did for the dual-direction in/out tile… (And if you feel like sharing the tileset with other authors when you’re done, you can do so by wrapping it up in its own extension, along the lines of the default tileset.)


Thanks for the explanation. I’m going to make a new tileset which has a grunge hand drawn look to it, and I’ll wrap it up in an extension when I’m finished, in case anyone wants to use it as an option. BTW, for anyone interested, I’ve been experimenting with different ways you could use a background image with your Automapping, as part of a front-end UI, and this example/test was created using the first version you referenced on the previous page (where the map doesn’t scale up):

Thanks again for the help - Dustin Neff

I’m probably way off base here, but in my test I’m trying to display another button which executes a command: “H” when clicked. So the button displays, but it doesn’t launch the command when clicked. Can anyone tell me what to do to get the sprite button to launch the command when clicked? Thanks for any help on this…

Figure of button is the file “button.png”.

button is a sprite. The display-layer is 0. The graphlink status is g-active. The image-ID is Figure of button. The origin is {10, 10}. The linked replacement-command is “H”.[/code]

The map-window has special rules for handling mouse input, bypassing the standard mouse input rules, which is why this doesn’t work. Here’s the explanation in the docs:

I’m not where I can test this right now and my memory is hazy on the details, but the you might be able to fix this simply by writing:

The default command replacement by graphlinks rule is listed first in the clicking graphlink rules.

If that works, let me know. I may just make it the default behavior.


Great, it works…Mostly. Only after further testing, the UI elements zoom/query (±?) seem to be disabled and not zooming/printing room name when clicked? Now the top X button works but the bottom ones don’t. Thanks I’ll keep working on it and see what I can do for now.

That’s what I was afraid of–that the special case map-window rules wouldn’t run. These are the dangers of plug-and-play extensions–they do the thing they were designed for well, but getting them to do other things well is much harder. I’d look into whether you can use the anchor elements for the button–they were designed to be used for added UI elements like this.