Plugs and Sockets by Sean Turner

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.

Just wondering. If Sean Turner reads this.

I have the same problem. Funny enough. I have two copies of I7 ionstalled. One compiles fine, the other gives me the above error message…

They both seem to have the same extensions installed.

Ideas?

BiB

Which versions of I7 are they?

Wow. I didn’t even notice I had two different versions. I thought I installed the same twice.

Well, the one that gives me errors is the 6G60 one. The one that works fine is 6E72.

But doesn’t that mean that there must be a way to resolve this? Unfortunately I have very little clue about how extensions work…

That sucks… :cry:

BiB
P.S.: I also tried the portable version of I7 (man - portableness… :unamused: would be a dream), but that one crashes on me completely (won’t even run).

Since 6G60 is the version mentioned in the first post in this thread, the solution above should work for you too.

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. :wink: 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.

BiB

Failure.

I7 says (surprise!):

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…

BiB

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.

Great. fantastic! :slight_smile:

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]

Hmmm… what could I have missed?

BiB

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?

Good thinking. Checked everything, though. “documented at” is nowhere to be found. :frowning:

This is a mystery. :slight_smile:

BiB

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.

Ok. I posted a report. Hope I did it right. :slight_smile:

If nobody else has an idea I guess i will either have to do without this extension or use the old 6E72 version of IF7. None are nice options.

Well, I am putting my faith in Sean Turner. :slight_smile: Or the IF7 Team will surprise. :wink:

BiB

Hello

My name is Sean. I wrote this extension some time ago. I was pleasantly surprised some people want to use it - quite flattering actually.

I haven’t looked at Inform for some time - busy with work and study and so on - but I was recently emailed on this so I thought I’d take a look.

I’ve read through this thread and I’ll make the necessary changes accordingly. Something changed in version 6G60 to cause the namespace clash.

Anyway, I should have it fixed during the weekend at the latest.

Sorry about the problem.

Cheers

My Hero!!! :sunglasses: Thanks a bundle!!!

Not a problem you caused, Mate. :wink:

Didn’t have the time to write over the last days. I was wondering whether there is any news on the above issue?

So basically this is a bump

BiB

Let me also bump your bug report, which is awaiting feedback. I’d really like to track down the internal error :slight_smile:.