A tester just found something that’s an issue for both Automap and Glimmr Automap. If the player enters multiple move commands at once, like “e.e.e.s.e.s”, none of the rooms inbetween the first room and last get mapped.
I guess the issue is related to the mechanisms of Automap, as Glimmr piggybacks off it, but I’m just saying that the same thing happens whether you’re looking at an ascii map or a graphical one.
Anyone have ideas on how to deal with this? Thanks.
The automap add adjacent rooms to map rule is not listed in the before constructing the status line rulebook.
The automap add adjacent rooms to map rule is listed last in the when play begins rulebook.
The automap add adjacent rooms to map rule is listed in the every turn rulebook.perhaps?
[rant]On a guess, it looks to me that the business of adding rooms to the automap happens in the phrase “To decide whether map is drawn” (!), which gets called from the phrase “To fill status bar with (selected table - a table-name) and map,” which in turn gets called from the automap standard status line rule, which is a rule for constructing the status line. So the problem is probably that the “constructing the status line” activity only gets carried out just before accepting input from the keyboard (see Writing with Inform 17.21), which means only once per string of commands.
Maybe you can fix this by forcing the activity to run every turn:
Every turn: carry out the constructing the status line activity.
EDIT: Well, if you include this in example B of the documentation, it crashes the interpreter in the IDE! But then if you add “Use static map allocation” it seems to work; type “e.u.w.w” and it’ll work. So I think this solves the problem, but introduces the crash that the Automap documentation mentions for example A, so you have to use static map allocation.
EDIT 2: No, that just causes the crash to occur at a different time, so you get a crash with a nicely drawn map. Hm.
EDIT 3: No wait, it’s not a crash, I just made the command prompt disappear, and also all the text for the rooms after the eastern hall. What the hey? I suspect that constructing the status line at the wrong time has caused text to start getting printed to the wrong buffer or something, except that I have no idea what the stuff that I just typed means.
EDIT 4: Well, it looks to me as though the issue is that the map-drawing routine calls the I6 “VM_MoveCursorInStatusLine” which according to Appendix B switches printing to the status line (and moves the cursor). So it may be a simple matter of calling whatever I6 routine switches printing back away from the status line. Someone who knows I6 can probably figure it out.[/rant]
EDIT 5: This is all wrong, see below.
I haven’t dug into this extension. But it sounds like its code needs to be split into the stuff that figures out the map (silently), and the stuff that draws the map.
Maybe it already is, in which case you just need to call the right bits at the right time.
Well, I should’ve tried eu’s code first, because it works. It’s actually the phrase for “To decide whether (r - a room) is explored:” that adds the room to the map, and the automap add adjacent rooms to map rule calls that. I had been confused because the automap add adjacent rooms to map rule didn’t look impressive, but I should’ve checked what it was calling. The extension’s documentation actually explains this.
(And I guess this is how it splits off the stuff that figures out the map and the stuff that draws it.)
Sorry for causing confusion.
Thanks everyone for the musings and eu for the fix. It’s working for the ascii version and the graphic version.
I don’t really understand the i6 level of the extension but I think it calculates the map internally then draws it in the status line. (I’m not sure if these steps are one and the same.) Since I do understand the status line bit, but I don’t want the map in the status line, I then in turn read the map data from the status line and redisplay it in a new window where I do want it for the ascii map.
Good to hear that somebody’s using Automap.
Hear hear. Vastly underused great extension.