ATTENTION: QUEST AUTHORS WHO USE THE ENTER VERB

In Quest 5.8.0:

image


image


The Fix

image


^^^ Show the library elements.


image


^^^ Select the enter_verb verb, and click the "Copy" button to copy it into the game's main code.


image


^^^ Now it is editable.


image


^^^ All we need to is copy that pattern to the clipboard, then change the pattern's drop down from "Regular expression" to "Command pattern".


image


^^^ Paste the pattern back in. (It's enter #object#, if you forgot to copy it.)


image


Now the dropdown menu shows "Enter" rather than "enterverb", which is already a good sign; right?!?


image


...and now it works as expected!

I reported this issue on GitHub already.

This should be fixed the next time Quest 5 gets updated.


If you want a verb's displayed name to be something other than its name or property, you can do something like:

enter_verb.displayverb = "enter"

I reported this issue on GitHub already.

This should be fixed the next time Quest 5 gets updated.

Which library contains the enter verb? I suspect filing a bug request with whoever maintains that library would be more helpful. (I note that the verb is apparently named enter_verb, presumably because the Quest core won't allow you to create a verb named enter; it says that you should use a command rather than a verb for that task)


Which library contains the enter verb? I suspect filing a bug request with whoever maintains that library would be more helpful.

https://github.com/textadventures/quest/blob/master/WorldModel/WorldModel/Core/Languages/English.aslx#L515


  <!-- Need a special verb in English because of the name collision with the "enter" script rooms use -->
  <verb name="enter_verb">
    <pattern>enter #object#</pattern>
    <property>enterverb</property>
    <defaultexpression>"You can't enter "+object.article+"."</defaultexpression>
    <scope>notheld</scope>
  </verb>

That's the existing code on GitHub.

Funny thing is, that should be correct.

This is treated as a regular expression: <pattern type="string">enter #object#</pattern>

This is treated a command pattern: <pattern>enter #object#</pattern>


Here's the code when I copy enter_verb into the game:

  <verb name="enter_verb">
    <pattern type="string">enter #object#</pattern>
    <property>enterverb</property>
    <defaultexpression>"You can't enter "+object.article+"."</defaultexpression>
    <scope>notheld</scope>
  </verb>

But this is what's actually in Core/Languages/English.aslx in the Quest directory (same as on GitHub, of course):

  <verb name="enter_verb">
    <pattern>enter #object#</pattern>
    <property>enterverb</property>
    <defaultexpression>"You can't enter "+object.article+"."</defaultexpression>
    <scope>notheld</scope>
  </verb>

I don't understand why the editor is changing it like that, but this is the best actual fix to apply to the source code I've come up with:

BAD CODE REMOVED

SCROLL DOWN TO NEXT POST FOR CODE

Also, I already have a fork of Quest with a pending pull request to fix a different issue.

The last time I tried to put in more than one pull request, there were merging problems.


If you want a verb's displayed name to be something other than its name or property, you can do something like: enter_verb.displayverb = "enter"

I was not aware of that.

I bet that will come in handy one day!


note that the verb is apparently named enter_verb, presumably because the Quest core won't allow you to create a verb named enter; it says that you should use a command rather than a verb for that task

Yeah, the enter attribute is for the after entering scripts.


History shows that this is my fault, by the way:

https://textadventures.co.uk/forum/quest/topic/o5h4rt5qcuoyqdbfvnwnaw/how-to-use-enter-as-a-verb

https://textadventures.co.uk/forum/quest/topic/1tfgwylwrkyw2-mpmcpnrq/the-command-enter-solved


Sorry, mrangel.

I should have been more detailed in the first post.

I am porting a huge game from ZIL to Quest right now, and that's how I keep finding all this odd behavior in the dark corners of the code.

I am consumed by the porting process, and I'm a little more scatter-brained than I normally am (which is really saying something, when you think about it).


Nope. That last code I posted broke a game with the existing enter_verb copied into it.

I had to change the property to "enter_verb" so it named it correctly (like the existing one).

  <verbtemplate name="enter_verb">enter</verbtemplate>
  <dynamictemplate name="DefaultEnter">WriteVerb(game.pov, "can't") + " enter " + object.article + "."</dynamictemplate>
  <verb template="enter_verb" property="enter_verb" response="DefaultEnter"/>

Ah… I thought I'd not seen that verb before, and checked in the core files… didn't think to look in the language library.


didn't think to look in the language library

Neither did I. I had to use grep to find that sucker.


Neither did I. I had to use grep to find that sucker.

Yeah :p

I did

grep enter_verb $QUESTCORE/*

Which didn't find it, so I assumed it must have been pulled into your project from some other library :p
Although… I'm looking now, and I don't see it in the language file either, so I'm assuming this is new

Putting it in the language file is a weird move. Names of things should be in the language file, but functional code shouldn't be.

 <!-- Need a special verb in English because of the name collision with the "enter" script rooms use -->

That is a little silly. The property/attribute names for verbs are in English regardless of the target language, so the name collision is just as much an issue in other languages. The verb should be defined in CoreCommands.aslx.

If I'm understanding correctly, in CoreCommands.aslx it should be something like:

  <verb name="enter" template="enter" property="enter_verb" displayverb="[enter]" response="DefaultEnter"/>

and in English.aslx

  <verbtemplate name="enter">enter</verbtemplate>
  <verbtemplate name="enter">go in</verbtemplate>
  <verbtemplate name="enter">go into</verbtemplate>
  <verbtemplate name="enter">get in</verbtemplate>
  <verbtemplate name="enter">get into</verbtemplate>
  <dynamictemplate name="DefaultEnter">WriteVerb(game.pov, "can't") + " enter " + object.article + "."</dynamictemplate>

and in CoreEditorObjectVerbs.aslx, change:

        <item>
          <key>enter</key>
          <value>Use a command, rather than a verb, to allow the player to enter this object.</value>
        </item>

to something like:

        <item>
          <key>enter</key>
          <value>Input the verb name as "enter_verb". It will appear as "enter" to the player.</value>
        </item>

(Just realised I didn't see all of your replies, as Chrome was being weird and only scrolling a page at a time earlier. Looking at your code… is it necessary to use enter_verb anywhere other than the "property" field? As far as I can tell neither object names nor templates should clash with an attribute name that is used for something else. If this is another oddity of the editor, I'd appreciate knowing about it)


(Also, looking at the updates on github since the version I have… I see that some of my idiocy made it on there. I was quite proud of the modifications to Conjugate, but only later realised that there should be special treatment for "will" and "can". These auxiliary verbs in English are weird and follow their own rules; they are never conjugated. But we have other verbs meaning other things: "can" meaning to put something in a can, and "will" meaning to intend, which are conjugated normally. So I think that for real consistency, it would be ideal to have Conjugate not called for messages that use these verbs)

Also… this just occurred to me while writing the post above. Can we have text processor functions for "conjugate", "writeverb", and "capfirst"? It would make so much of the language file neater.


  1. See all that stuff you came up with that I didn't even think about? That's another reason I hadn't done a pull request yet.

  2. I abuse grep. I just go into the main quest directory and grep -rn enter_verb *.


Looking at your code… is it necessary to use enter_verb anywhere other than the "property" field? As far as I can tell neither object names nor templates should clash with an attribute name that is used for something else. If this is another oddity of the editor, I'd appreciate knowing about it

Oh, I don't really know. I was just trying to copy how the other verbs I found were coded.

I definitely defer to you concerning verbs.


Also, looking at the updates on github since the version I have… I see that some of my idiocy made it on there.

Hey!

That's the same thing that led us here!

I posted the enter_verb code that's in Quest right now, and I reckon it seemed like a good idea to include it.

I mean, it is a good idea to include it -- just with the proper code. (Ha!)


Also… this just occurred to me while writing the post above. Can we have text processor functions for "conjugate", "writeverb", and "capfirst"? It would make so much of the language file neater.

I don't see why not, as long as we test it thoroughly before including it.

I know a guy who has access to the files on GitHub now. So, if you've got some code, create a pull request (or an issue).

Plus, since Quest 6 will be coming out sometime in the far-away future, I'm trying to help get all the little bugs in Quest 5 ironed out so the next release can be the stable (and possibly final) release.


Log in to post a reply.

Support

Forums