Dialog Wishlist

Authoring Dialog
506

The thesis stress is getting overwhelming again, so have another poll!

Here are the Standard Library rules for HUG and KISS (synonyms: LOVE, EMBRACE).

%% KISS <obj>

(grammar [kiss/love [animate]] for [kiss $])

(prevent [kiss $Obj])
	(current player $Player)
	{
		($Obj = $Player)
	(or)
		($Obj is part of $Player)
	}
	Your feelings for yourself are primarily of a platonic nature.

(perform [kiss $Obj])
	(The $Obj is) unmoved by your display of affection.

%% HUG <obj>

(grammar [hug/embrace [animate]] for [hug $])

(perform [hug $Obj])
	(try [kiss $Obj])

Specifically, if you try to hug or kiss anyone or anything that is not yourself (or part of yourself), you get this message:

(The $Obj is) unmoved by your display of affection.

Some testers have pointed out that this message is fine for inanimate objects, but usually not appropriate for people. Most non-player characters should respond in some way if you actually successfully kiss them, whether that’s a cat squirming away, a love interest blushing, or a boss reporting you to HR.

I’m considering changing this default message to not imply that the kiss actually happens:

(The $Obj) (doesn’t $Obj) seem receptive to that sort of thing.

If a character is receptive to this sort of thing, after all, the author will probably have written their own code for it!

What do you all think?

  • Keep the existing message (“unmoved by your display of affection”)
  • Switch to the new message (“doesn’t seem receptive to that sort of thing”)
  • Objects “are unmoved”, people “don’t seem receptive”
  • Something else!
0 voters

Personally, I’d like to keep the same failure message for people and objects just for the sake of simplicity (fewer library messages for someone to change), but it’s not a technical problem to have two messages instead of one. Compare how GIVE is handled:

(perform [give $ to $Dest])
	(if) (animate $Dest) (then)
		(The $Dest) (doesn't $Dest) appear to be interested.
	(else)
		Giving things to (the $Dest) doesn't appear to work.
	(endif)
	(tick) (stop)
507

I voted for the split but really any solution that includes changing the response for kissing NPCs is an improvement whether or not it changes the one for inanimate objects.

Although if the message is going to change to avoid implying that the player actually kissed the object, should that be a refuse rule rather than a perform?

508

The library broadly tries to put “you tried to do this but couldn’t” in (prevent $) rules and “you did this but it had no effect” in (perform $) rules, but the latter are a lot easier to override in specific cases than the former. So I try to have default messages that the author will want to override be (perform $) rules that (stop) the action whenever possible.

1 Like
509

It looks like absolutely everyone wants the structure of option strings specified. I’m leaning heavily toward my key: value, key: value system, because it’s easy for the interpreters to accept, and as the primary maintainer of those interpreters I need to make sure they work well. But I do want to give other people a chance to chime in; if there’s a strong consensus for something else, I’ll adapt.

So, here are the main options being considered:

(define resource @keyword)
    path/filename.ext,
    key0,
    key1: val,
    key2: val1,
    key2: val2,
    alt text alt text alt text.

(define resource @keyword)
    path/filename.ext,
    key0,
    key1 val,
    key2 val1,
    key2 val2,
    alt text alt text alt text.

(define resource @keyword)
    path/filename.ext,
    \[ key0 \[ key1 val \] \[ key2 val1 val2 \] \];
    alt text alt text alt text.

It’s unfortunately infeasible to do this third one without the backslashes, because the meaning of bare [ and ] is baked into Dialog’s lexer at a deep level in a way that’s not easily compatible with resource definition syntax. If someone wants to change this, I’ll happily accept a PR for it! We could also use < and >, which have no special meaning.

Similarly, it’s currently infeasible to use ; as an option delimiter, because existing code relies on that separating options from alt text. I’m hesitant to break absolutely all existing code that uses alt text on resources(!) without a very good reason. But if someone sees a way to use semicolons without changing the syntax for optionless resources ((define resource @keyword) path/filename.ext; alt alt alt.), by all means pitch it!

What do you all think of them? Which of these should Dialog and the Å-machine commit to for the future?

  • key: value
  • key value
  • \[key value\]
  • <key value>
  • Something else!
0 voters
510

And it’s the weekend, so why not keep launching polls? I think we’re quite close to a 1b/01 release candidate, so now’s the best time to get any disagreements squared away.

Over the last few weeks, and with the assistance of several lovely people from this forum, I’ve created a second version of dgdebug for Windows. This one works just like the Linux and Mac versions: it runs entirely in the terminal rather than launching a separate Glk window, which means you can do things like redirecting its output to a file.

It’s rapidly approaching feature parity with the Linux version—in particular, it now offers line editing, color and style support, [more] prompts, Ctrl-C support, and more. The last thing we’re working on now is integration with dgt.

So, I’m inclined to have the official version of dgdebug.exe in 1b/01 be the terminal one. The Glk version will still be available as dgdebug_glk.exe or dgdebugw.exe or the like, but the default one the docs point people toward will be the terminal version.

How does everyone feel about that? Personally, I’m fully in favor, because it means dgdebug will work the same on every platform instead of having special exceptions for Windows. (And even the Glk version needs the terminal to launch it properly!) But I want to give people a chance to weigh in on a major change like this.

  • Yes, the default dgdebug on every platform should be the terminal one; give the graphical one a different name
  • No, Windows-users should have the graphical version be the default; give the terminal one a different name
0 voters
511

Eep! I need to get writing; my manual chapter is only half done.

1 Like
512

No worries if it’s not; I’m hoping to get 1b/01 out by the end of April, mostly so that we can have a cohesive standard for the Å-machine 1.0.0, but it’s not a problem if the manual chapter ends up in 1b/02 instead.

513

All right!

Kissing animate objects will now have a new failure message!

Option strings will be specified as:

RESOURCE-DEF = URL [, OPTION-LIST] [; ALT-TEXT]
OPTION-LIST = OPTION [, OPTION-LIST]
OPTION = KEY [: VALUE]

(This is not proper BNF, but it should get the idea across.)

This new format will break…I think exactly one (1) existing project, since I believe The Wise-Woman’s Dog is the only released Dialog project that uses option strings. I’ll survive somehow.

On Windows as on Linux and Mac, dgdebug will now invoke the terminal version of the debugger, not the graphical one. The graphical one can be accessed as dgdebug_gui if you have an old terminal that doesn’t handle ANSI codes or line editing. But in general, the terminal one is better.

(The GUI one could possibly be brought to Mac and Linux as well via garglk, but this runs into two problems: one, garglk is released under the GPL, so incorporating it into the core distribution of Dialog is nigh-impossible; and two, I’ve never seen a Mac or Linux system that doesn’t support the basic POSIX features needed for good line editing, so there’s not much reason to try. If someone else wants to do it, though, a separate project incorporating dgdebug and garglk is just fine under the license terms, so fire away!)

I think this should be all the major changes I have pending for 1b/01, so with any luck, I’ll move toward a release candidate as soon as my dissertation is deposited. (Others are welcome to keep working at their own pace; don’t feel bound to my frenetic work schedule!)

3 Likes
514

I’m not sure how hard this would be to implement, but would it be possible to have the compiler try to match up every grammar definition with a default action processing rule (like perform or prevent) and vice versa, and give a compiler warning if it can’t find a match? For instance, if you accidentally typed a rule to (prevent [tak $Obj]) instead of (prevent [take $Obj]), the compiler would give you a Possible typo: warning.

515

Unfortunately not possible for the compiler—the parser and action handling are just normal Dialog code, so the compiler has no idea what (prevent $) means.

The compiler could offer the library authors some way to implement this, ideally, but I don’t know what that way would be.

This might be a better task for a linter or preprocessor of some sort.

1 Like
516

The release candidate is coming along well, but I’d like to make one final poll on the Å-machine spec.

The Å-machine has eight-bit opcodes, where the bottom seven bits choose the opcode and the top bit chooses the variant. For example, $30 checks if equal to a value, $B0 checks if equal to zero. $69 enters a link, $E9 leaves a link. $73 gets line input, $F3 gets key input.

Originally, $67 entered a status area, and $E7 left a status area. But the implementation of $67 turned out to not be quite ideal, so now $6F also enters a status area (with a better implementation). In Å-machine version 1.0, $67 will be removed entirely (the Dialog compiler now always emits $6F instead). But this means $6F enters a status area and $E7 leaves one, while $67 and $EF are undefined.

This is consistent with version 0.* of the Å-machine, but it’s not very symmetrical. We could potentially deprecate $E7 too, and have $EF become the opcode for leaving a status area.

The question is: continuity or symmetry?

  • Continuity over symmetry: use $6F and $E7, like in version 0.*
  • Symmetry over continuity: use $6F and $EF, making a matched pair
  • Something else?
0 voters

Version 1.0 of the Å-machine will also add a new opcode, SET_BODY, for body styles. This properly belongs in the output control range ($6X and $EX)…but there are no completely free pairs left in that range.

Currently I’ve pencilled it in at $ED, the counterpart of the entirely unrelated $6D (which draws a progress bar). This isn’t really ideal either; it’s the only place in the whole spec where the top bit isn’t selecting variants of the same basic operation. But I don’t really foresee a need for a variant of progress bars, or a variant of body styles.

We could keep it at $ED, or we could change that—if we go with continuity, then $EF will almost certainly never be needed for anything, and if we go with symmetry, then the entire pair $67/$E7 will be available.

What do you all think?

  • Stick with $ED (paired with PROGRESS)
  • Switch to $EF (paired with ENTER_STATUS) or $67 (newly-freed)
  • Something else?
0 voters

Incrementing the major version seems like the proper time to make breaking changes, so if we don’t change this now, it will probably not change any time soon. So I want to get the community’s feedback now, before anything becomes irreversible.

(I realize this also doesn’t matter at all to most authors. This will have no impact whatsoever on how you write Dialog code; it only affects the people coding Å-machine interpreters.)

517

Are there any Å-machine files in the wild with the old opcodes? Does choosing the “symmetry” option mean that Linus’ games won’t run on new Å-machine interpreters, for example?

1 Like
518

Yes there are existing files, but no they will not break—that’s a priority. Like with the different Z-machine versions and their different opcode definitions, the interpreter will check the story file’s header and use that to choose the right behavior.

This is already the case with existing interpreters: even before version 1.0, the encoding of strings changed from 0.3 to 0.4, so all interpreters currently check the header every time they print a string to decide what to do. So the only things that will break are “1.0-dev” story files compiled with prerelease versions of Dialog 1b/01-dev; I don’t think there are any of those out in the wild, since it’s not common to distribute a raw Å-machine file (people usually bundle the file with the interpreter).

This constant checking is kind of inefficient on the C64, so I’ve considered making the interpreter only work for a specific Å-machine version, and then bundling the appropriate interpreter with each file. But that’s currently entirely theoretical. (And body style setting is very rare compared to printing strings!)

1 Like
519

But the Z-machine has settled down quite a bit; the only versions that are really used are Z5 and Z8, with some Z3 for vintage hardware. It’s not currently the case that there are third-party interpreters that support native .aastory files out there, but I’d love to see that supported in the future, particularly if 32-bit Å-machine becomes the alternative to having dialogc output Glulx. Reserving breaking changes for major things such as adding the aforementioned 32-bit support, and fitting smaller improvements into non-breaking changes, might be a good policy, to make that support easier.

520

Definitely! That’s part of why I’m proposing this now: we’re going from version 0.5 of the Å-machine to version 1.0, and we’re already making a couple breaking changes in the process (like removing $67 in the first place). I wouldn’t want to make a change like this when we’re only incrementing the minor version, and I don’t foresee another major version bump in the near future. So I figure it’s now or never! (Or wait for 2.0, which isn’t anywhere near.)

2 Likes
521

I am not so active here due to many other commitments but I secretly hope your thesis never ends. Although we’re a small user base (a third-degree niche?), we really appreciate your dedication to making Dialog even greater than it already is.

3 Likes
522

Thank you so much for the kind words! And while I’d sincerely like to keep doing PhD work forever, I won’t be stopping work on Dialog once it’s over—I can justify it to myself by saying maintaining an open-source project looks great on a resume.

1 Like
523

I was hoping to freeze the 1b/01 release candidate, but then I made those last polls, and for an architectural decision like that I’d like to leave them open for a few more days at least. So I’m back to tinkering a little bit in the meantime. (I will have it formalized before the TALJ deadline, though, since I’m planning to release a project with the new Å-machine version.)

The current focus of my tinkering: every time I start a project, I generally grab stdlib.dg and run a bunch of regexes on it to replace " and ' with “ ” and ‘ ’. Straight quotes are a pet peeve of mine, and both the Z-machine and Å-machine support the proper ones now, so I want to use them!

But that made me think…why not just put those regexes in the Dialog project itself and distribute an automatically-generated stdlib.unicode.dg alongside the ASCII stdlib.dg? That way, other people can also use the curly-quote version if they want.

How do people feel about this? If you don’t like the idea, I can just keep doing the substitutions on my own. But since it’s automatically generated, we don’t need to worry about keeping it up to date.

  • Yes, distribute stdlib.unicode.dg alongside stdlib.dg
  • No, do not make stdlib.unicode.dg part of the distribution
0 voters

Under the hood, this is what happens:

stdlib.unicode.dg: stdlib.dg Makefile
	## This runs a bunch of regexes on stdlib.dg to replace straight quotes with curly
	rm -f stdlib.unicode.dg
	echo "%% Auto-generated from stdlib.dg: straight quotes changed to curly" | cat - stdlib.dg > stdlib.unicode.dg
	## First: double-quotes between whitespace and non-whitespace
	perl -pi -e "s/(\S)\"(\s|$$)/\1”\2/g" stdlib.unicode.dg
	perl -pi -e "s/(\s)\"(\S)/\1“\2/g" stdlib.unicode.dg
	## Second: single-quotes between whitespace and non-whitespace
	perl -pi -e "s/(\s)\'(\S)/\1‘\2/g" stdlib.unicode.dg
	## The following one is more broad to hit "they're" etc
	perl -pi -e "s/(\S)\'/\1’/g" stdlib.unicode.dg
	## Third: double-quotes in parentheses
	perl -pi -e "s/\"\)/”\)/g" stdlib.unicode.dg
	perl -pi -e "s/\(\"/\(“/g" stdlib.unicode.dg
	## Fourth: double-quotes between words and any other punctuation
	perl -pi -e "s/(\w)\"(\W)/\1”\2/g" stdlib.unicode.dg
	perl -pi -e "s/(\W)\"(\w)/\1“\2/g" stdlib.unicode.dg
	## Not currently covered: something like " (print words $) " or "(print words $)"
	## Fortunately, this does not currently occur in the library
	grep "[\"']" stdlib.unicode.dg && exit 1 || echo Success!
524

Branching the standard library on such a thing seems … ham-fisted. What other options will call for their own branch? Will user have to select the option they need most or would we get into a combinatorial explosion of library alternatives?

Dialog is – like TeX, PostScript and friends – half programming language, half typesetting engine. Seems like a typesetting engine should default to typographically correct quotes on platforms that support it, and not use them when building against those that don’t. (Possibly with some sort sof escape sequence for quotes that are not supposed to be curly.)

Is that possible?

2 Likes
525

I voted no. To explain my reasoning:

  • I don’t think this will be automatic with zero overhead in the long term because the replacements being made are effectively best guesses.
  • It happens to work now but once the file is distributed there will be an expectation that it is always there, especially if the filename is referenced to actually build a game. This is different to distributing advice on how the file could be changed; explaining standard library modifications in the manual lets you update an example where you promote the idea of modifying the single standard library.
  • The expectation that the user will be editing the relatively small standard library is a design choice of Dialog. Beyond translations to other languages, supplying a additional variants which are pre-modified goes against that design choice.
  • If someone chose to edit the standard library in place they may also presume that the Make target will work correctly with their edited version and there are no guarantees that it will.

i.e. This is just one case of expected standard library modification by the user and is better as an example of a modification.

2 Likes