Has anyone gotten this extension to work correctly?
I’ve emailed the author of the extension filing a bug report, but I thought I could also get your opinions on this.
I get this compiler error when I try to use the extension:Problem. You wrote 'It is always male': but the property male for the PS-plug is not allowed to exist, because you haven't said it is. What properties something can have depends on what kind of thing it is: see the Index for details.
See the manual: 3.7 > Properties depend on kindThis problem highlights the line:
A PS-plug is a kind of PS-connector. It is always male.
I’m running inform 7 build 6G60.
I get the error even when I run the included example story “Home Theater”.
What should I do to fix this so that I can use this extension?
This seems to be the result of a namespace clash. I got the same error message, so I opened the extension and did a Replace All, replacing “male” with “mascul”. (This produces, of course, “femascul”, which is rather silly. For testing purposes only.)
It now compiles, and the test script in the sample game seems to work. Whether my replacement of text has other side effects, I don’t know.
There’s one point (at least?) where the extension prints the gender of the noun (in the “instead of examining a PS-connector” rule). So you’d also want to modify it to print out “male” and “female” instead of “mascul” and “femascul,” but that should be simple. (Also if you want to get something less silly than “femascul,” you can search-and-replace on “female” first.)
If the extension contains “understand the gender property as referring to a PS-connector” or something like that, you probably have to do a little more fancy footwork.
I followed your advice and I replaced male with outy and female with inny.
I also did a quick workaround when it prints the gender.
It works now, thank you for your help.
I hope the author of the extension can get this fixed shortly, it’s a very useful extension.
Yes, I tried that, but replacing first all “female” appearances with something and then all “male” appearances seems to only lead to crashes while compiling. I guess I am just making a mistake somewhere.
Unfortunately
doesn’t help me much. Can you elaborate on this?
I will be testing 6F95 in a moment to see whether it works there (I’ll post the result).
Still, in the end it would be great if the extension could be updated for the current release.
You wrote 'It is always male' : but the property male for the PS-plug is not allowed to exist, because you haven't said it is. What properties something can have depends on what kind of thing it is: see the Index for details.
I send the author an email… I am hopeful that this really nice extension will be fixed or a workaround will come up…
Sure - here is the original section:[code]A PS-connector is a kind of thing. It has an object called the attachment. It has some text called the type. The type is usually “standard”. A PS-connector can be unknown, male or female (this is its gender property).
Instead of examining a PS-connector (called the item):
say "It is a [gender] [type] connector of [the holder of the noun]. It ";
if the item is male:
say "is [if the attachment of the noun is nothing]unplugged[else]plugged into [the holder of the attachment of the noun][end if].";
else:
say "has [if the attachment of the noun is nothing]nothing[else][the holder of the attachment of the noun][end if] plugged into it.".
A PS-plug is a kind of PS-connector. It is always male.
A PS-socket is a kind of PS-connector. It is always female.
[/code]
And here is my updated section:[code]A PS-connector is a kind of thing. It has an object called the attachment. It has some text called the type. The type is usually “standard”. A PS-connector can be unknown, outy or inny (this is its gender property).
Instead of examining a PS-connector (called the item):
if the item is outy:
say “It is a male [type] connector of [the holder of the noun]. It is [if the attachment of the noun is nothing]unplugged[else]plugged into [the holder of the attachment of the noun][end if].”;
else:
say "It is a female [type] connector of [the holder of the noun]. It has [if the attachment of the noun is nothing]nothing[else][the holder of the attachment of the noun][end if] plugged into it.".
A PS-plug is a kind of PS-connector. It is always outy.
A PS-socket is a kind of PS-connector. It is always inny.[/code]
So in summary, I changed the properties from male and female to outy and inny. I think it wasn’t working because male and female are properties belonging to people, and there must have been a conflict of reserved words, or something.
I tried it and the error is gone. Unfortunately what I now get is this (same message when I just substituted all occurences of male and female):
[code]This is the report produced by Inform 7 (build 6G60) on its most recent run through:
Problem. An internal error has occurred: Bad index documentation reference. The error was detected at line 452 of “Chapter 3/Index File Services.w”. This should never happen, and I am now halting in abject failure.
What has happened here is that one of the checks Inform carries out internally, to see if it is working properly, has failed. There must be a bug in this copy of Inform. It may be worth checking whether you have the current, up-to-date version. If so, please report this problem via www.inform7.com/bugs.
As for fixing your source text to avoid this bug, the last thing you changed is probably the cause, if there is a simple cause. Your source text might in fact be wrong, and the problem might be occurring because Inform has failed to find a good way to say so. But even if your source text looks correct, there are probably rephrasings which would achieve the same effect.[/code]
That looks like Bug 47, which is tripped when authors use the syntax
... (documented at ...): ...
It’s supposed to be reserved for the standard rules. Do you see any such code in your story or the extension?
In that case, could you file a bug in the Inform bug tracker? Like the problem message says, ``this should never happen,’’ and a full bug report will (1) help us figure out what exactly is going on and (2) hopefully prevent similar trouble in the future.