intfiction.org

The printing of the new prompt? Sorry ... what line causes that?

There goes a very basic implementation of it. It doesn't even check the number of the link, just tries to execute "go n" when you click in the "NORTH" link of the room 01 description.



As mentioned, its only drawback is the mixing of the "go north" new command line with anything the player had typed before clicking (which would go unnoticed if she hasn't typed anything, of course).

_________________
English posts in my blog!

Thanks. That was very helpful. I seem to have it working now ... almost. The only bit of piffle that remains is that when I click a link, the result looks like this:



I'm using a dummy object to print the command, and I'm sure that's horribly wrong, but it's the best I've been able to figure out. Here's what I have at present:



If I don't use the four lines before cmdlen = PrintAnyToArray, the new command is never printed at all, even though it's carried out. So evidently I need to get rid of that kluge and figure out a way to stuff the actual command on the line with the command prompt. I have no clue where to look for a way to do that.

Adam Cadre, very unhelpfully, says this: "Now, you can either place that very phrase at the prompt to let the player know that's what's been done, or you can do something like this...." He then gives, more or less, the four lines that are printing my output in the wrong place.

<Sigh.>

No sooner do I solve that problem than I find I have a worse problem. When the player (at the moment, player = me) resizes the game window, a GlkEvent is generated, which means that HandleGlkEvent is called. This has the effect of repeating the last command, whatever it was -- and whether or not it resulted from clicking a link. I have no smegging idea how to prevent this, because nothing in my HandleGlkEvent code seems to be responsible for it. Here's what I have:



One would naively expect that a window resize event would fall through to the default case, which would do nothing. But no ... a new command is silently issued in the background.

Are evtype_Hyperlink and switch (ev-->2) supposed to be indented to the same level like that?

You can change this behavior by taking advantage of one of the new Glk calls: glk_set_echo_line_event.

It lets you turn off the automatic printing of the player's input - but you are then responsible for printing something to the screen in its place. (You might also need to update your copy of infglk.h, depending on how recent it is.)

Indentation is not significant in I6.

As I told you before, you must put the lines that write the new command at the prompt before calling the glk cancel line function, that's to say:

this


goes before this:



And as I mentioned, the ugly side effect is that if the player types something before clicking the result could be like this (in the example she has typed "xyzzy", then, for any reason, changed her mind and clicked on the "NORTH" link)


I'm going to take a look to this glk set echo calls (I didn't know they existed! nice!) to see if they can help with this.



You're doing the "return 2" from the HandleGlkEvent main routine. You should put it in the evtype_hyperlink: case of the switch (ev-->0) switch. If not, you're returning "2" wichever the event is, which has the effect of canceling the current command line. And I miss the glk_cancel_line_event() call in your last code, which surely is causing some more adiotional chaos ^_^'.

_________________
English posts in my blog!

No, that's not legal. You can't print* when there's a line event pending, so the cancelation needs to happen first. The only way to prevent the line break is to use the set echo function that Ben mentioned.

--Erik

*Some interpreters will print text to the window while a line event is pending, but it is unambiguously out-of-spec.

_________________
Glimmr: Advanced Graphics for I7
blog | download | bug-tracker

Thanks to everyone for offering suggestions. My reasons for wanting to use I6 were (a) I dislike I7, but (b) I want my game to be playable in a Web browser.

But the underlying impulse behind (b) is, I want the player to have a pleasant, modern experience. My foray into Glulx programming for I6 has convinced me that I'm unlikely to be able to provide that experience using these tools -- not without becoming so frustrated that I'll lose all interest in the project. The I6/glulx documentation is bad to nonexistent, and the coding requirements seem to be pretty much a mess.

At this point, it seems clear to me that using TADS 3 will be a much better alternative. Even if MJR doesn't have his Web server implementation up and running any time soon, the other aspects of the user experience will be more comprehensive, more reliable, and a whole lot easier to code. On balance, I6 loses; T3 wins.

Too bad. I like I6, and I was sort of looking forward to becoming an I6 virtuoso. YCAGWYW, but if you try some time, you just might find....

--JA