Brief notes for each new release appear in this forum thread .

The Dialog Manual will tell you everything about the latest version.

Since Dialog version 0d/01 there's an interactive debugger, and since version 0g/01 there's a separate backend for the Å-machine story format.

Dialog is a domain-specific language for creating works of interactive fiction . It is heavily inspired by Inform 7 (Graham Nelson et al. 2006) and Prolog (Alain Colmerauer et al. 1972).

The release archive includes:

The compiler is distributed under a 2-clause BSD license.

For reasons outlined in the Treaty of Babel, the Dialog compiler may bug you about declaring a story-specific IFID. To generate the required declaration, simply click the button below.

This is what Cloak of Darkness looks like in Dialog.

My IFComp 2018 game Tethered is the first published Dialog game.

Discuss this page

Disclaimer: I am not responsible for what people (other than myself) write in the forums. Please report any abuse, such as insults, slander, spam and illegal material, and I will take appropriate actions. Don't feed the trolls.

Jag tar inget ansvar för det som skrivs i forumet, förutom mina egna inlägg. Vänligen rapportera alla inlägg som bryter mot reglerna, så ska jag se vad jag kan göra. Som regelbrott räknas till exempel förolämpningar, förtal, spam och olagligt material. Mata inte trålarna.

Anonymous

Tue 11-Dec-2018 18:44 if I have an object in a closed transparent container how do I override the default 'you can't reach obj' take fail message?



(instead of [take *]) doesn't seem to work in this case (scope?)

lft

Linus Åkesson

Wed 12-Dec-2018 10:35 if I have an object in a closed transparent container how do I override the default 'you can't reach obj' take fail message?



(instead of [take *]) doesn't seem to work in this case (scope?)

The "can't reach" message is printed by (refuse $), which is invoked before instead-of. So you can override refuse with a negated rule:



~(refuse [take *]) %% Don't refuse to take this object. The "can't reach" message is printed by (refuse $), which is invoked before instead-of. So you can override refuse with a negated rule:~(refuse [take *]) %% Don't refuse to take this object.

Anonymous

Thu 13-Dec-2018 12:55 Is it possible to suppress implicit actions temporarily.

For example

1.dropping something in a held container first tries to take the object before dropping.



2. putting something into something where the first something is in a held container tries to take before putting in



If I know that the take will always succeed can I suppress the first trying to take reporting.

lft

Linus Åkesson

Thu 13-Dec-2018 23:54 If I know that the take will always succeed can I suppress the first trying to take reporting.

Yes, there are several ways. You can override the before-predicate for that particular case, with a negative rule. For each particular action:



~(before [drop $X])

($X is #in $Y)

($Y is #heldby $Z)

(current player $Z)



But many actions invoke a common predicate, '(ensure $ is held)', and you can add a new rule to that one instead:



(ensure $X is held)

($X is #in $Y)

($Y is #heldby $Z)

(current player $Z)



When the given conditions are true, your rule will succeed, and this prevents the later rule definition in the library from executing. Yes, there are several ways. You can override the before-predicate for that particular case, with a negative rule. For each particular action:~(before [drop $X])($X is #in $Y)($Y is #heldby $Z)(current player $Z)But many actions invoke a common predicate, '(ensure $ is held)', and you can add a new rule to that one instead:(ensure $X is held)($X is #in $Y)($Y is #heldby $Z)(current player $Z)When the given conditions are true, your rule will succeed, and this prevents the later rule definition in the library from executing.

Eleas

Björn Paulsen

Fri 14-Dec-2018 12:30



fatal error: attempting to store to nonexistent local variable 3:

routine has 0 (pc = 0x2aba)

The Cloak of Darkness example seems bugged under 0.15. Attempting to go somewhere yields a crash:

Eleas

Björn Paulsen

Fri 14-Dec-2018 12:34 Eleas wrote: The Cloak of Darkness example seems bugged under 0.15. Attempting to go somewhere yields a crash:



fatal error: attempting to store to nonexistent local variable 3:

routine has 0 (pc = 0x2aba)

The Cloak of Darkness example seems bugged under 0.15. Attempting to go somewhere yields a crash:

This is odd. I get the same error when running the first example in chapter 5. I'm running the win32 version of dialogc on Windows 10, in case that matters. This is odd. I get the same error when running the first example in chapter 5. I'm running the win32 version of dialogc on Windows 10, in case that matters.

Eleas

Björn Paulsen

Fri 14-Dec-2018 12:44 I've now checked each release of the compiler, and found that moving between rooms only works under release 0b/01. Later than that leads to the fatal error described above.

Anonymous

Fri 14-Dec-2018 13:18 Eleas wrote: I've now checked each release of the compiler, and found that moving between rooms only works under release 0b/01. Later than that leads to the fatal error described above. I've now checked each release of the compiler, and found that moving between rooms only works under release 0b/01. Later than that leads to the fatal error described above.

Not sure if it's related but I only get the error when using Gargoyle. Frotz doesn't give the error. (latest versions Windows 10) Not sure if it's related but I only get the error when using Gargoyle. Frotz doesn't give the error. (latest versions Windows 10)

Eleas

Björn Paulsen

Fri 14-Dec-2018 13:54 Not sure if it's related but I only get the error when using Gargoyle. Frotz doesn't give the error. (latest versions Windows 10)

Thank you. Can verify. Does anyone know the best way to pass a bug report to one of the maintainers? Thank you. Can verify. Does anyone know the best way to pass a bug report to one of the maintainers?

lft

Linus Åkesson

Fri 14-Dec-2018 14:47 This looks like a Dialog bug. Thanks for reporting; I'm on it!

lft

Linus Åkesson

Fri 14-Dec-2018 15:36 Fixed in 0c/04.

Anonymous

Tue 18-Dec-2018 13:05 Can I reference an object variable from within the scoring options?

(increase score by (#object variable))

lft

Linus Åkesson

Tue 18-Dec-2018 14:14 Can I reference an object variable from within the scoring options?

(increase score by (#object variable))

As a general rule, queries can't be nested; they don't even have return values.



(Confusingly, rule heads may contain nested expressions, but that is a special case of syntactic sugar.)



But output can be communicated using ordinary parameters. To take the output from one query, and use it as input in another, you would write the queries one after the other. Then you'd use a variable to carry the value.



Assuming you have a predicate ($ has score $) that assigns a score to every object:



(#object has score $X) %% Here, $X becomes bound (i.e. to the output).

(increase score by $X) %% Use the value of $X as input. As a general rule, queries can't be nested; they don't even have return values.(Confusingly, rule heads may contain nested expressions, but that is a special case of syntactic sugar.)But output can be communicated using ordinary parameters. To take the output from one query, and use it as input in another, you would write the queries one after the other. Then you'd use a variable to carry the value.Assuming you have a predicate ($ has score $) that assigns a score to every object:(#object has score $X) %% Here, $X becomes bound (i.e. to the output).(increase score by $X) %% Use the value of $X as input.

mstram

Sun 3-Feb-2019 08:01 The following code crashes the compiler



If I substitute the (else) with (if), I get a more reasonable message : "Error (if) without (then).



** The comment editor seems to strip away the indentation ... does it accept some kind of 'markup' ? (I.e. the second line (else) *was* indented.



Also I had much more in the source file, I isolated the crash down to these two lines.



Assertion failed!



Program: c:\bats\dialogc.exe

File: backend_z.c, Line 3348



Expression: call_lab



--------------------

(story title)

(else)

mstram

Sun 3-Feb-2019 08:15 The actual 'realistic' use case for the above was that I had accidentally "not-escaped" the title i.e.

(story title) ( Else) test file

instead of



(story title) \(Else \) test file

lft

Linus Åkesson

Sun 3-Feb-2019 08:54 Thanks! I'll fix that.



There's currently no tag to retain formatting in the comments; sorry for that. I've been using hardspaces to get around it. I suppose I'll fix that too.

mstram

Sun 3-Feb-2019 09:39 Are global flags (or maybe it's the (now) predicate) designed to work in "open code" (like global variables?



If I put :



(now)(a-global-flag) in "open code", I get :



"Special syntax cannot be redefined"



Mike

lft

Linus Åkesson

Sun 3-Feb-2019 21:54 mstram wrote: Are global flags (or maybe it's the (now) predicate) designed to work in "open code" (like global variables?



If I put :



(now)(a-global-flag) in "open code", I get :



"Special syntax cannot be redefined"



Mike Are global flags (or maybe it's the (now) predicate) designed to work in "open code" (like global variables?If I put :(now)(a-global-flag) in "open code", I get :"Special syntax cannot be redefined"Mike

Anything that starts in the very first column of a line is interpreted as a rule definition, so the compiler thinks you're trying to define a rule for a predicate called '(now)'. But that's special syntax, so its behaviour can't be modified.



If you would like the global flag to be initially set, define a rule with an empty rule body:



(a-global-flag)



This is analogous to how the initial values of other kinds of dynamic properties are defined. For instance:



(#box is #heldby #player)

(#box is open)

(current player #player) Anything that starts in the very first column of a line is interpreted as a rule definition, so the compiler thinks you're trying to define a rule for a predicate called '(now)'. But that's special syntax, so its behaviour can't be modified.If you would like the global flag to be initially set, define a rule with an empty rule body:(a-global-flag)This is analogous to how the initial values of other kinds of dynamic properties are defined. For instance:(#box is #heldby #player)(#box is open)(current player #player)

mstram

Mon 4-Feb-2019 00:24 Ok, thanks, that works ... but ...



The "first-column-global" (fcg ? :)) is not showing up in the debugger's @dynamic output.



The flag *does* work though (of course),if I enter

(a-global-flag), giving the expected "Query succeeded:(a-global-flag)



The @dy(namic) cmd seems to be only finding global flags that are referenced inside a rule :



(test)

__ (now)(a-global-flag)





Mike

lft

Linus Åkesson

Mon 4-Feb-2019 15:02 mstram wrote: The @dy(namic) cmd seems to be only finding global flags that are referenced inside a rule The @dy(namic) cmd seems to be only finding global flags that are referenced inside a rule

That is correct. A predicate is only considered dynamic if it appears in a (now)-statement somewhere. So, if there's a (now) (a-global-flag) somewhere, then (a-global-flag) is regarded as a boolean variable that can be toggled at runtime. And its initial value is determined by the rule definitions for it. Otherwise, it behaves more like a boolean-valued function, and the rule definitions make up its function body.



It's a matter of terminology. Something that can change is dynamic, but something that cannot possibly change is not. That is correct. A predicate is only considered dynamic if it appears in a (now)-statement somewhere. So, if there's a (now) (a-global-flag) somewhere, then (a-global-flag) is regarded as a boolean variable that can be toggled at runtime. And its initial value is determined by the rule definitions for it. Otherwise, it behaves more like a boolean-valued function, and the rule definitions make up its function body.It's a matter of terminology. Something that can change is dynamic, but something that cannot possibly change is not.

mstram

Wed 6-Feb-2019 11:12 This crashes both the windows and linux-64 compilers, version

0d02_0_19, and 0e01_0_20,but NOT the 0c05_0_17 version



#gnue

(name *) gnue

(dict *) plane

(vehicle *)





Again it's only a code fragment, but I was trying to split a larger program into multiple files.



Mike

lft

Linus Åkesson

Wed 6-Feb-2019 20:10 Thank you! I can reproduce it. Amusingly, I can get the program to compile by adding a room:



(room #x)



But it's still a compiler bug, of course, and I'll fix it as soon as possible.

lft

Linus Åkesson

Wed 13-Feb-2019 22:01 Fixed in 0e/02.

Anonymous

Sun 19-May-2019 12:00 I think there may be a bug with (fungibility enabled appearance $ $ $)



I noticed that when I had (fungibility enabled) an explicit (appearance $ $ $) rule set on an object did not fire until the object had been moved. After a bit of digging I came to the conclusion that the problem was with stdlib line 3788. What seems to be happening is that when nothing's been touched the list being handled by (fungibility-enabled appearance $ $ $) starts with an object with no appearance, which means that a rule fails on the first object and it never recurses.



If I add an (or) so that it reads



(if)($Ninc = 1)(then)

(appearance $Head $Rel $Loc)

(or)



it works. I'm not sure that adding an (or) simply to prevent failure is good style of course ...



Paul

lft

Linus Åkesson

Tue 21-May-2019 21:59 I think there may be a bug with (fungibility enabled appearance $ $ $)

Thank you! This was indeed a bug, and I've added the '(or)' in library version 0.24. I think it's a reasonably clean fix. The alternative would have been to add a default rule definition for '(appearance $ $ $)' with a blank rule body, but such a change would also have affected stories that do not make use of fungibility, so I decided against it. For now, at least. Thank you! This was indeed a bug, and I've added the '(or)' in library version 0.24. I think it's a reasonably clean fix. The alternative would have been to add a default rule definition for '(appearance $ $ $)' with a blank rule body, but such a change would also have affected stories that do not make use of fungibility, so I decided against it. For now, at least.

Anonymous

Thu 6-Jun-2019 00:21 I can't seem to build this. backend.c and backend_z.h seem to be missing from the tarball.

lft

Linus Åkesson

Thu 6-Jun-2019 01:16 I can't seem to build this. backend.c and backend_z.h seem to be missing from the tarball.

Whoops! Should be fixed now in 0g/02, which is otherwise identical. Whoops! Should be fixed now in 0g/02, which is otherwise identical.

Anonymous

Sun 23-Jun-2019 18:52 lft wrote: I can't seem to build this. backend.c and backend_z.h seem to be missing from the tarball.

Whoops! Should be fixed now in 0g/02, which is otherwise identical. Whoops! Should be fixed now in 0g/02, which is otherwise identical.



That got me going, thanks. Have you ever considered putting this in a public repository so that others can contribute, too?





I really like the idea of this system: it's a nice sweet spot between writing and programming. That got me going, thanks. Have you ever considered putting this in a public repository so that others can contribute, too?I really like the idea of this system: it's a nice sweet spot between writing and programming.

Anonymous

Thu 15-Aug-2019 20:33 I have published a mostly-complete conversion of Pick Up the Phone Booth and Die to Dialog.



https://github.com/jpcompton/Dialog-diversions



Please enjoy dubious code examples, make improvements, or be inspired to greater heights!

Anonymous

Mon 16-Sep-2019 13:52 I just tried a hello world example and segfaulted the compiler (Dialog, release 0h/02, library 0.30, prebuilt for Linux x64)



$ cat test.dg

(story ifid) B0E2A7D1-45F7-46A1-8348-53ADA71F2CD8

(program entry point)

We'll find out how this works, slowly.



$ valgrind dialogc test.dg

==14539== Memcheck, a memory error detector

==14539== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.

==14539== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info

==14539== Command: dialogc test.dg

==14539==

==14539== Invalid read of size 1

==14539== at 0x12A4FA: addstr_escape.constprop.1 (in /usr/local/bin/dialogc)

==14539== by 0x12AE3D: emit_blorb (in /usr/local/bin/dialogc)

==14539== by 0x129FF1: backend_z (in /usr/local/bin/dialogc)

==14539== by 0x10D487: main (in /usr/local/bin/dialogc)

==14539== Address 0x0 is not stack'd, malloc'd or (recently) free'd

==14539==

==14539==

==14539== Process terminating with default action of signal 11 (SIGSEGV)

==14539== Access not within mapped region at address 0x0

==14539== at 0x12A4FA: addstr_escape.constprop.1 (in /usr/local/bin/dialogc)

==14539== by 0x12AE3D: emit_blorb (in /usr/local/bin/dialogc)

==14539== by 0x129FF1: backend_z (in /usr/local/bin/dialogc)

==14539== by 0x10D487: main (in /usr/local/bin/dialogc)

==14539== If you believe this happened as a result of a stack

==14539== overflow in your program's main thread (unlikely but

==14539== possible), you can try to increase the size of the

==14539== main thread stack using the --main-stacksize= flag.

==14539== The main thread stack size used in this run was 8388608.

==14539==

==14539== HEAP SUMMARY:

==14539== in use at exit: 613,930 bytes in 657 blocks

==14539== total heap usage: 1,170 allocs, 513 frees, 1,450,866 bytes allocated

==14539==

==14539== LEAK SUMMARY:

==14539== definitely lost: 7,600 bytes in 50 blocks

==14539== indirectly lost: 206,966 bytes in 102 blocks

==14539== possibly lost: 0 bytes in 0 blocks

==14539== still reachable: 399,364 bytes in 505 blocks

==14539== suppressed: 0 bytes in 0 blocks

==14539== Rerun with --leak-check=full to see details of leaked memory

==14539==

==14539== For counts of detected and suppressed errors, rerun with: -v

==14539== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

Segmentation fault (core dumped)

Anonymous

Mon 16-Sep-2019 13:57 This seems to be linked to the (default) zblorb format. The others work fine.

lft

Linus Åkesson

Wed 18-Sep-2019 12:44 I just tried a hello world example and segfaulted the compiler (Dialog, release 0h/02, library 0.30, prebuilt for Linux x64)

Thanks for reporting it!



This appears to happen for small input (i.e. without the standard library), in combination with the zblorb format. I'll fix it tonight. Meanwhile, either switch to the z8 format or include the standard library. Thanks for reporting it!This appears to happen for small input (i.e. without the standard library), in combination with the zblorb format. I'll fix it tonight. Meanwhile, either switch to the z8 format or include the standard library.

lft

Linus Åkesson

Thu 19-Sep-2019 08:01 I just tried a hello world example and segfaulted the compiler (Dialog, release 0h/02, library 0.30, prebuilt for Linux x64)

This is now fixed in 0h/03. This is now fixed in 0h/03.

Anonymous

Mon 23-Sep-2019 14:13 Using dialogc-0h03:



The following program crashes the compiler, regardless of the output format. It works on version 0d02.



(program entry point)

(now) ~($ has parent $)



Error messages:

backend_z.c:2010: generate_code: Assertion `ci->oper[0].value != DYN_HASPARENT' failed.

and

backend_aa.c:1350: compile_routines: Assertion `ci->oper[0].value != DYN_HASPARENT' failed.



--------------------------------------------------------



The following three programs crash the compiler when compiling for the Aa-machine but work fine on the Z-machine:



(program entry point)

(#a = $X)



Error message:

backend_aa.c:752: encode_dest: Assertion `0' failed.



--------------------------------------------------------



Note: I have been unable to minimize this program further because removing any line will cause the crash to disappear.



(program entry point)

($x = 3)

($y = 3)

($ = $)

([#a #b] = [#a #b])

([#a #b] = [#b #a])

([1 [@a] 3] = [1 [@a] 3])

([1 [@a #b] 3] = [2 [@a #b] 3])

([1 [@a #b] 3] = [1 [@a #b] 3])

([1 2 3 4] = [$a $b $c $d])



Error message:

backend_aa.c:3151: opersize: Assertion `aao.value <= 0x3f' failed.



--------------------------------------------------------



And a similar program, also as simplified as possible:



(program entry point)

($x = 3)

($y = 3)

($ = $)

([#a] = [])

([#a #b] = [#a #b])

([#a #b] = [#b #a])

([1 [#a #b] 3] = [1 [#a #b] 3])

([1 [#a #b] 3] = [2 [#a #b] 3])

([1 [#a #b] 3] = [1 [#a #b] 3])

([1 [#a #b] 3] = [1 [#a] 3])



Error message:

backend_aa.c:3151: opersize: Assertion `aao.value <= 0x3f' failed.

lft

Linus Åkesson

Mon 23-Sep-2019 23:36 Thanks! I'll look into these. The first two are corner cases that I hadn't thought of; they should be easy to fix.



The last two happen because the compiler is running out of registers for holding temporary values. Fixing this involves a more substantial implementation effort that I've been putting off. But it needs to be done, of course.

Anonymous

Sat 5-Oct-2019 02:31 Any chance of linking to the source repo, to accept patches. I've found a couple of nits in the documentation I could fix.

Anonymous

Fri 11-Oct-2019 03:39 Is there a GitHub project for this? I noticed a couple of tiny documentation bugs that I would submit a PR for.



Also, what's the trajectory here: do you know what "feature complete" looks like, and what's the journey there look like?



I've been dabbling in IF for quite some time; As a coder (I work in Clojure) I prefer the Dialog syntax over Inform (as nifty as Inform7 can be).



Also your forums are broken; database error, can't register.



HLS

lft

Linus Åkesson

Sun 20-Oct-2019 23:35 Is there a GitHub project for this? I noticed a couple of tiny documentation bugs that I would submit a PR for.

It's on the todo list. My own repo is intertwined with the development of Tethered, so I have to create a new, public repo with a clean history.



Also, what's the trajectory here: do you know what "feature complete" looks like, and what's the journey there look like?

There's no detailed long-term plan, but I think the bulk of the functionality is already in place. The Å-machine needs to run on vintage hardware, as promised, and I'm currently working on that. I have some ideas for new bells and whistles, but the core Dialog language feels fairly stable, and will probably evolve in a backwards-compatible way. But I don't promise this until we get to version 1, which will probably happen when (if) people start to release stuff made in Dialog.



Also your forums are broken; database error, can't register.

Huh, I haven't been able to reproduce this. Is it still broken from your end? It's on the todo list. My own repo is intertwined with the development of Tethered, so I have to create a new, public repo with a clean history.There's no detailed long-term plan, but I think the bulk of the functionality is already in place. The Å-machine needs to run on vintage hardware, as promised, and I'm currently working on that. I have some ideas for new bells and whistles, but the core Dialog language feels fairly stable, and will probably evolve in a backwards-compatible way. But I don't promise this until we get to version 1, which will probably happen when (if) people start to release stuff made in Dialog.Huh, I haven't been able to reproduce this. Is it still broken from your end?

hlship

hlship@gmail.com

Sat 2-Nov-2019 00:47 Thanks for the update.



I was able to register on the forum this time, so whatever it was, resolved itself.

hlship

hlship@gmail.com

Sat 2-Nov-2019 01:12 So, out of an abundance of hubris, I'm trying to bring Threaded Conversation to Dialog, despite:



- insufficient experience w/ TC in Inform7

- not fully fluent in Inform7

- new to Dialog

- very limited time to work on this!





I'm struggling with scope.



Quips are the basic thing in TC - they represent a exchange between the player and the NPC, and include predicates that govern who can say the quip, and how quips directly or indirectly follow each other (plus much more in TC).



So a player command might be ASK BARMAID ABOUT RUMORS and this should be understood as [discuss #whether-rumors-tell-truly with #barmaid].



But my code, as it stands, is failing:



> ask bar maid about rumors

The whether the rumors tell truly isn't here.



So that's a scoping issue.





What's confusing to me is that, when tracing, it looks like it found it:



| | | | | FOUND (understand [ask bar maid rumors] as [discuss #whether-rumors-tell-truly with #barmaid]) /usr/local/share/dialog-if/stdlib.dg:4710



(I haven't put in any code to restrict quips in any way, that comes soon)



but then Dialog continues on from there:



| | | | | | | | | ENTER (parse [bar maid] as object [1] [13] [1] 0) /usr/local/share/dialog-if/stdlib.dg:4394

| | | | | | | | | QUERY (allowing parse errors) /usr/local/share/dialog-if/stdlib.dg:4395

| | | | | | | | ENTER (split [maid rumors] anywhere into [maid | $] and $) /usr/local/share/dialog-if/stdlib.dg:5273

| | | | | | | | QUERY *(split [rumors] anywhere into $ and $) /usr/local/share/dialog-if/stdlib.dg:5274

| | | | | | | | | ENTER (split [rumors] anywhere into [rumors | $] and $) /usr/local/share/dialog-if/stdlib.dg:5273

| | | | | | | | | QUERY *(split [] anywhere into $ and $) /usr/local/share/dialog-if/stdlib.dg:5274

| | | | | | ENTER (understand [ask bar maid rumors] as [ask $ about $]) /usr/local/share/dialog-if/stdlib.dg:1916



So despite finding a good match, it seems to wander off based on the built-in ask action (?).



Later in the trace it feels like it's back to my discussing action, but something (even with the trace, it's hard to follow) deciding that #whether-rumors-tell-truly is not reachable.



I tried adding



((quip $) in is scope)



to make all quips in scope, but that doesn't seem to help.





My code so far (cobbled from stdlib.dg and guess work and experimentation):





(rewrite [ask | $Words] into [ask | $TailWords])

(split $Words by [about] into $Person and $MoreWords)

(append $Person $MoreWords $TailWords)



(understand [ask | $Text] as [discuss $Quip with $Person])

*(split $Text anywhere into $Someone and $QuipWords)

*(understand $Someone as single object $Person preferably animate)

*(understand $QuipWords as questioning quip $Quip)



(understand $Words as questioning quip $Quip)

*(understand $Words as quip $Quip)

(questioning quip $Quip)



(understand $Words as quip $Quip)

(filter $Words into $Filtered)

(nonempty $Filtered)

(determine object $Quip)

*(quip $Quip)

%% TODO: In scope for conversation ...

(from words)

*(dict $Quip)

(matching all of $Filtered)





So I thought I'd check to see if I'm even headed in the right direction on this.



For TC managing the scope is pretty essential; TC is about a balance of revealing what you can talk about in the current point of the current conversation without giving away other possible conversation quips that don't (yet) apply. So ultimately, whether Dialog should recognize 'rumors' as referring the quip depends on who the player is conversing with, what quips have already been performed, and whether a potential quip follows (directly or indirectly) some previously performed quip.

Anonymous

Sat 15-Aug-2020 15:57 Am I missing something? The third example in Chapter4 Items doesn't appear to work. As shown the amethyst is not in the bowl. Adding (* is #in #bowl) to the amethyst seems to fix this. All of the options for multiple stones now work. Latest windows version.

Anonymous

Sun 16-Aug-2020 19:01 Okay, does this example need updating? Changing ((stone to (*(stone in line 39 seems to fix this.