problem with period in adv3Lite custome message text

Authoring TADS
1

I’m having trouble customizing the unmatched noun message using Adv3Lite.

When my custom message text is defined as…

[code] Msg(unmatched noun, '{I} muttered, as it dawned
on him that he {see} no {2} {here}. ')

[/code]

…it works fine.

In the following game play, there is a dresser in the bedroom but the top drawer has not been implemented yet. When I try to open the non-existent drawer, I get the message I am expecting…

But if I change the comma that follows “muttered” to a period, I get a nil pointer exception, with the debugger pointing to the last line in the following snippet from english.t (the local idx = ctx.subj.plural line)…

[code]conjugate(ctx, params)
{
/* get the list of forms for the verb */
local toks = englishMessageParams.verbTab[params[1]];
if (toks == nil)
return nil;

/* 
 *   get the present tense index: third-person singular has the second
 *   slot, all other forms have the first slot 
 */
local idx = ctx.subj.plural || ctx.subj.person != 3 ? 1 : 2;

[/code]

Yes, I understand, changing the comma to a period in my example doesn’t make grammatical sense, but it illustrates the nil pointer. What I’m actually trying to achieve is a two-sentence message.

Here’s the full game…

[code]#charset “us-ascii”

#include <tads.h>
#include “advlite.h”

versionInfo: GameID
IFID = ‘47ca87f1-2d0e-4b54-a776-2bc128e30927’
name = ‘TADS 3 Lite Test Bed’
byline = ‘by Jerry Ford’
htmlByline = ‘by
Jerry Ford’
version = ‘1’
authorEmail = ‘Jerry Ford jerry.o.ford@gmail.com’
desc = ‘Test bed for experimenting with TADS 3 Lite.’
htmlDesc = ‘Test bed for experimenting with TADS 3 Lite.’
;

gameMain: GameMainDef
initialPlayerChar = harry
usePastTense = true
;

// harry, main character
harry: Actor ‘Harry;;man self’ @harrysBedroom
“”
contType = Carrier
globalParamName = ‘harry’
isFixed = true
isHim = true
isInitState = true
ownsContents = true
person = 3
proper = true
;

harrysBedroom: Room
‘Bedroom’ ‘bedroom’
“In the bedroom was a plain brown dresser.”

bedroomMentioned = true

;

  • bedroomDresser: Fixture ‘dresser’
    "A small brown dresser with three drawers, top, middle, and bottom, stood against the
    south wall<>, opposite the foot of the bed. The dresser was plainly built,
    with neither filigree nor ornamental hardware. Just stainless steel
    pulls centered in plain wood drawer faces<>. "

    bedroomDresserMentioned = harrysBedroom.bedroomMentioned

;
CustomMessages

messages = 
[
    Msg(unmatched noun, '{I} muttered, as it dawned
        on him that he {see} no {2} {here}. ')
]

;
[/code]

2

Are you using the latest version of adv3Lite? This is a problem I thought I’d fixed in version 0.8, which was released 8 days ago.

I don’t get the error with my version of the library, but I know why you’d get it if you’re using a version of adv3Lite prior to version 0.8. Using a period in your custom message creates a new sentence, in which the message substitution {see} has no subject (while with the comma in place the message substitution {I} provides the subject, because it’s still in the same sentence).

One of the many changes in version 0.8 was to make the library assume a third-person singular subject in a case like this (where there’s no explicit subject for the verb).

So, if you’re not already using version 0.8 I suggest you get it, otherwise you’ll keep running into issues that it fixes!

That said, your message is constructed a bit oddly. To be consistent you want either:

Msg(unmatched noun, 'Harry muttered, as it dawned
            on him that he saw no {2} {here}. ')

Or else, properly parameterized:

Msg(unmatched noun, '{I} mutter{s/ed}, as it {dummy} dawn{s/ed}
            on {him actor} that {he actor} {see} no {2} {here}. ')

Actually, the second form doesn’t quite work, since the library insists on expanding {him actor} as ‘himself’, rather than ‘him’, which is something I’ll have to look into. For now you’d probably have to write ‘him’ rather than ‘{him actor}’, which would only be a problem if your game ever shifted into first or second person.

3

Yes, I’m sure.

Just to be sure that I hadn’t screwed something up when I upgraded, I just now deleted the adv3Lite library from the project, verified that the adv3lite library in c:\Program Files 9x86)\Tads 3\lib is 0.8 (according to the readme.html in that foler) and reloaded. I still get the error.

(And thanks for the parameterized version; I’ll play around with that.)

Jerry

Jerry
Jerry

4

Well, this is very odd. I have made changes to adv3Lite since the 0.8 release, but I’ve now tried running your exact source code with the 0.8 library and I can’t reproduce your run-time error.

I do, however, get precisely the error you report with version 0.7 of adv3Lite.

I wonder if this has something to do with the fact that you’ve installed adv3Lite in c:\Program Files (x86)\Tads 3\lib instead of the recommended location c:\Users\JerryFord\My Documents\TADS 3\extensions. I’ve noticed that Windows 7 (if that’s what you’re on) can be a bit protective about what goes in the Program Files directory; you can think you’re changing things there while actually the changes are happening elsewhere, which can be a terrible source of confusion for the unwary. This may not be what’s happening in this case, but since I’ve now established on my machine that I get precisely the error you report with version 0.7 of adv3Lite but not with version 0.8, I think this may be what’s happening here.

I can’t remember the precise details, but when you try to make changes in the Program Files (or Program Files (x86)) directory on Windows 7, Windows has the nasty trick of actually applying the changes to a copy of the file it makes elsewhere to which it then silently directs some operations but not others (such as manipulating files in Explorer). So it could be that Explorer is showing you one set of files while Workbench is silently being redirected to another.

I suggest you try installing adv3Lite version 0.8 in another place, like c:\Users\JerryFord\My Documents\TADS 3\extensions (or wherever your My Documents folder lives) and see if that solves the problem. (And then of course you’ll have to make sure that Workbench is using version of adv3Lite in …\My Documents\TADS 3\extensions instead of the one it’s been using up until now, by removing adv3Lite from your project and then adding it again from the new location. When you do so, make sure you move adv3Lite down below the TADS System Files in the file pane, or you’ll get a whole lot of compilation errors).

5

Okay, it appears to be working now.

I did what you suggested—put the library files in a folder other than a Windows system folder—and replaced the old, (x86) library path with the new one.

And got the same results.

So then I started poking around in Workbench and I noticed there were still references to the (x86) folder. I shut Workbench down and restarted it, and now it seems to be working correctly. At least, I get the two-sentence message I was looking for.

That doesn’t explain why I had the problem before reloading the library, but I suspect you are right that Windows does some sleight of hand under the hood. I’m sure I installed the 0.8 version of the library the day you released it. But it was installed in the (x86) directory.

Now that I’m not using the Windows system folder, I’m wondering if some of the other problems I’ve been having will disappear (for example, the {s/ed} parameter you steered me to has not worked yet; message displays the parameter name, curly braces and all).

Jerry

6

From my own recollection of being caught out by this charming Windows feature, I think what’s going on is something along the lines of the following: When you edited versions of the adv3Lite files in the Program Files directory (in order to apply various patches I posted here), Windows in fact created copies of those files so the originals wouldn’t be changed. Your edited copies were put in some quite different part of the file system (something like …\users\program data.., I don’t recall exactly). These edited copies then masked the originals for all purposes except for what shows up in Windows Explorer (or any other file manager). When you copied the version 0.8 files over the version 0.7 ones (or, at least, into the same location where the version 0.7 ones had been), everything would have looked fine in Explorer, but (I’m guessing) the edited versions of former 0.7 version files were (and still are) lurking around elsewhere in your file system, masking their version 8 equivalents from Workbench and any other application that wants to use them, with the result that what Workbench was seeing was a mixture of new 0.8 files and previously edited version 0.7 files, with the consequences you encountered. Windows gives you no warning that it’s doing this, making it all but impossible to detect, except by some rather determined detective work when you realize things aren’t working as expected.

This is why it’s a good idea not to install anything you don’t need to in Program Files directories.

I would expect this to be related. The (s/ed} parameter (and its close relations) were introduced into adv3Lite in version 0.8, so I suspect the version of english.t that defined them in version 0.8 was being masked by an old, edited version, of the 0.7 version of english.t. Hopefully now you’ve sorted out your adv3Lite installation away from the booby-trapped Program Files directory, these new parameter substitutions should now work properly.

7

From my own recollection of being caught out by this charming Windows feature, I think what’s going on is something along the lines of the following: When you edited versions of the adv3Lite files in the Program Files directory (in order to apply various patches I posted here), Windows in fact created copies of those files so the originals wouldn’t be changed. Your edited copies were put in some quite different part of the file system (something like …\users\program data.., I don’t recall exactly). These edited copies then masked the originals for all purposes except for what shows up in Windows Explorer (or any other file manager). When you copied the version 0.8 files over the version 0.7 ones (or, at least, into the same location where the version 0.7 ones had been), everything would have looked fine in Explorer, but (I’m guessing) the edited versions of former 0.7 version files were (and still are) lurking around elsewhere in your file system, masking their version 8 equivalents from Workbench and any other application that wants to use them, with the result that what Workbench was seeing was a mixture of new 0.8 files and previously edited version 0.7 files, with the consequences you encountered. Windows gives you no warning that it’s doing this, making it all but impossible to detect, except by some rather determined detective work when you realize things aren’t working as expected.

This is why it’s a good idea not to install anything you don’t need to in Program Files directories.

I would expect this to be related. The {s/ed} style parameter substitutions were introduced into adv3Lite in version 0.8, so I suspect the version of english.t that defined them in version 0.8 was being masked by an old, edited version, of the 0.7 version of english.t. Hopefully now you’ve sorted out your adv3Lite installation away from the booby-trapped Program Files directory, these new parameter substitutions should now work properly.

EDIT: I originally assumed this behaviour was intended to protect users from themselves. It’s possible that it’s meant to protect users from each other, so that, for example, if Jack and Jill share the same computer, Jack’s edits to stuff under Program Files will work for Jack (because stored in his own private copy) but won’t affect Jill. The scheme must have seemed terribly clever to the people who devised it, and in a way it is - except that it didn’t account for the kind of situation that’s caught us out.

The most directly related information I could find on line about this was on the MSDN Forum. Although the discussion relates principally to Windows Vista, Windows 7 clearly behaves in the same way (and I imagine Windows 8 does too).

8

Pretty much describes Microsoft in a nutshell, doesn’t it? Why do things the simple way when you can devise a monstrously complex alternative that’s sure to befuddle users everywhere? (Anecdotal aside: Back in the day, when Windows was a 16-bit OS, Microsoft placed system files in a folder called c:\Windows\system. Then, when Windows became a 32-bit system, MS added a second system folder, called system32. Now that Windows is a 64-bit system, there is also a sysWOW64 folder. Makes sense so far, right? Except…the system32 folder contains the 64 bit libraries, and the sysWOW64 folder contains the 32-bit files. :slight_smile:

As for {s/ed} it’s working now. Your theory seems to be upheld.

9

sysWOW64 isn’t the equivalent of system or system32. 64-bit Windows doesn’t really run 32-bit applications natively. Instead it uses a translation layer called “Windows on Windows 64”, or WOW64.(Depending on chipset, this ranges from “switch the chip to 32-bit mode” to “provide full emulation of a 32-bit CPU”. So sysWOW64 is the location of system libraries for WOW64 (which runs 32-bit apps).

As for why they didn’t change system32 to system64, I think that’s inertia more than anything else (too many libraries with hard-coded paths).

10

Not to split hairs too finely—sorry, I’m a tech writer, it’s what we do :slight_smile:—but it still remains, the folder with 32 in the name is where the 64-bit stuff resides and the folder with 64 in the name is where the 32 bit stuff resides. Yeah, hard-coded path names can be a bitch but then, isn’t that sort of what symbolic links are for? Oh, wait, Windows… :slight_smile:

Jerry