Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Threaded Conversation by Chris Conley gives wrong parser errors in 6M62 #48

Open
Ordinaryperson2 opened this issue Jul 3, 2018 · 6 comments
Labels

Comments

@Ordinaryperson2
Copy link

When a story includes this extension, the player doesn't get the correct error for trying to interact with something out of scope.
It seems like the game first checks the correct command, then when that doesn't work it checks whether the input is a performative quip. If this test also fails we get the unrecognised verb error.

Sample story:

"Threaded Conversation bug" by Poke
Include Threaded Conversation by Chris Conley.
The stage is a room.
Backstage is a room.
The cake is an edible thing in backstage.
Test me with "x egg / touch sky / eat cake / abcde "

This will output:

>test me
(Testing.)
>[1] x egg
That's not a verb I recognise.
>[2] touch sky
That's not a verb I recognise.
>[3] eat cake
That's not a verb I recognise.
>[4] abcde
That's not a verb I recognise.

If we don't include the extension, we get the correct errors:

>[1] x egg
You can't see any such thing.
>[2] touch sky
You can't see any such thing.
>[3] eat cake
You can't see any such thing.
>[4] abcde
That's not a verb I recognise.
@Ordinaryperson2
Copy link
Author

Ordinaryperson2 commented Jul 5, 2018

I think I've figured out the issue, though I don't know how to solve it properly (can parser errors be stored in a variable?)
These rules are meant to decide how to print parser errors, but end up creating a new parser error which leads to the problem.

Rule for printing a parser error when the latest parser error is the can't see any such thing error (this is the quips are not visible rule):
	if the player's command includes "say/ask/answer/discuss/tell/a/t" or the player's command includes "[any quip]":
		if the current interlocutor is a person and tc reparse flag is false:
			say "That doesn't seem to be a topic of conversation at the moment." (A) instead;
		otherwise:
			say "[text of implicit-conversing needs current interlocutor rule response (D)][line break]" (B) instead; ['You aren't talking to anyone.']
	otherwise:
		make no decision.	
		
Rule for printing a parser error when the latest parser error is the noun did not make sense in that context error (this is the prevent context error rule):
	if the player's command includes "say/ask/answer/discuss/tell/a/t" or the player's command includes "[any quip]" or the current interlocutor is not a person:
		say "[text of parser error internal rule response (N)][line break]" (A) instead; ['Not a verb I recognize.']
	otherwise:
		make no decision.

The issue is different if I unlist and relist the first rule - I instead get "That noun did not make sense in this context".
If in my relisted version I comment out part of the if statement, changing it to:
if the player's command includes "say/ask/answer/discuss/tell/a/t":
Then I get the correct errors for examining out of scope/non existent things. I assume this also breaks the error for performative quips, but for now I'll consider that the lesser of two evils.
I don't know if the second rule needs to be changed, just because I'm not sure how that error gets triggered in the first place (other than in these rules themselves).

@angstsmurf
Copy link
Contributor

I'm unable to investigate this at the moment, but in the current code of Counterfeit Monkey the or the player's command includes "[any quip]" is dropped, and I have not seen the problem you describe.

@Ordinaryperson2
Copy link
Author

Looks like you added the error messages to CM in this big commit (Line 770) and had this condition removed/commented from the start. I wonder if you got it from somewhere else that made this change?

The rule does have another difference, and it's possible other parts of the extension handle something differently to account for this, so I'll hold off on calling this a definite fix. It seems to work though.

@angstsmurf
Copy link
Contributor

Yes, almost every extension included in CM has been modified to some extent, but Threaded Conversation is probably the one that has gone through the most changes, first to make it run on 6M62, then to improve performance. Some unused stuff has been cut as well. It would take some fixes to make it work as a standalone extension.

@angstsmurf
Copy link
Contributor

Oh, and there is no other version of Threaded Conversation that code is taken from. Most of it is from the original 6G60 version, some from the Chris Conley version, the rest from me.

@ChrisPC
Copy link
Contributor

ChrisPC commented Jul 24, 2018

I didn't even notice that bug. Thanks! It's probably time to publish version 7, so I'll see about getting it listed on the Public Library.

I should probably update the version on here...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants