Version 0.9 is out today!

A lot of changes reflect what I have learnt and what beta-testers have said while developing my own game so among other things: transcripts have been redone; CONSTRUCTION and ROOM_SET templates have been added; the parser has been refactored to allow better GIVE command.

Other significant changes include: jQuery has been dropped; a lot of stuff for RPG (though this is still a work in progress); createPaneBox replaced by createAdditionalPane.

If I am honest, the motivation for releasing now is that it coincides with releasing a game for IFComp, and I want the game to be using a released version. However, with the exception of the RPG module, this is in a stable place with no further changes envisaged.

Congratulations. :-)

Sounds great

Just some quick notes/observations whilst running through the tutorial (v0.9).

Please note: I am new to JavaScript but not new to IF programming (I7 and Dialog) - Therefore any problems I have noted may be an issue of: my ignorance or my knowledge/expectations brought over from other systems.

In Chrome/Windows 10 (latest version of both) - in the console the following Violations appear (with the verbose log level selected):
Avoid using document.write()
Parser was blocked due to document.write

Tutorial: Rooms and exits.
A third room - second chunk of code - exit to west is wrong - missing new Exit()?

Although suggested in the text (and I would expect in play) the torch, when held, cannot be turned on in the dark basement. You need to turn it on in the kitchen before you descend.

Tutorial Locks and keys.
Locked cabinet - glass cabinet is missing its starting location.

(wrong item referenced in response?)
If I try to 'open cabinet with the garage key' I get the response
The garage key can't be opened with that.

(no unlock with command? - or lock with)
If I try to 'unlock cabinet with cabinet key' (or any key for that matter) I get the response
There doesn't seem to be anything you might call 'cabinet with cabinet key' here.

Tutorial commands.
Regarding the defmsg test processor directive: The text mentions 'nv' but the defmsg uses 'pv'

Tutorial complex mechanisms.
The charger examine message contains {charger_state} which gives an error. Although {charger_state} is introduced later on the page.

Hi queste

Thanks for the comments. If is very helpful when people effectively beta-test the tutorial.

In Chrome/Windows 10 (latest version of both) - in the console the following Violations appear (with the verbose log level selected):
Avoid using document.write()
Parser was blocked due to document.write

I had not noticed that. I have a new version (on GitHub, but not in a release) that eliminates most uses of document.write, and Chrome seems happy with the remaining three. However, it seems to work fine anyway. I used 0.9 for my game in IFComp, so I really hope there are no actual issues!

I have corrected the errors in the tutorial. Still got unlock and the torch issue to resolve!

ETA: I have resolved the issue with document.write, but not uploaded to Github or to a new release. I have an entry in IFComp, and as that is also on GtHub, updating one updates the other, and I do not want to do this change until the competition is over, just in case there are strange side effects. I will get it sorted for the end of November.

Re: Torch issue.

Objects held in a dark room cannot be interacted with at all - you can't drop it for example. They do show up in the typed inventory though - not in the inventory pane.

So you can (in a dark room) do this:

i
You are carrying a torch

x torch
There doesn't seem to be anything you might call 'torch' here.

A Couple of quick questions.

Is the Q5 inroomdescription for items implemented in Q6?

Is there an easy way to change the You can't go 'dir' message on a per room basis?

Apologies if I've missed these in the docs.

Objects held in a dark room cannot be interacted with at all - you can't drop it for example. They do show up in the typed inventory though - not in the inventory pane.

Definitely a bug then. I am somewhat working on RPG support and I am looking at different visibility effects there, so will look at it as part of that.

Is the Q5 inroomdescription for items implemented in Q6?

Not as such. I would recommend using the text processor and checking the scenery flag.
https://github.com/ThePix/QuestJS/wiki/Dynamic-Room-Descriptions

Is there an easy way to change the You can't go 'dir' message on a per room basis?

No, but there is on a per exit basis, which I think makes more sense.
https://github.com/ThePix/QuestJS/wiki/Attributes-for-exits#use

Apologies if I've missed these in the docs.

A big problem is how people can find stuff in the docs. If you have any suggestions?

Is there an easy way to change the You can't go 'dir' message on a per room basis?

No, but there is on a per exit basis, which I think makes more sense.
https://github.com/ThePix/QuestJS/wiki/Attributes-for-exits#use

I can see use cases for a per-room unresolved exit message.
Although I suspect this could be achieved by creating a dummy exit with aliases matching all of the usual directions that a player can't go in.

I can see use cases for a per-room unresolved exit message.
Although I suspect this could be achieved by creating a dummy exit with aliases matching all of the usual directions that a player can't go in.

You can also add a "testMove" function to the player. If the player cannot move because he is tied up, that would be the way to go.
https://github.com/ThePix/QuestJS/wiki/Restrictions,-Messages-and-Reactions#when-the-character-moves

I can see use cases for a per-room unresolved exit message.
Although I suspect this could be achieved by creating a dummy exit with aliases matching all of the usual directions that a player can't go in.

You can also add a "testMove" function to the player. If the player cannot move because he is tied up, that would be the way to go.

I notice that it says the function receives an exit as the parameter. What if there isn't an exit? Would you still need to create a dummy exit as well?

It gets called when the player tries to move to another room, and is sent the exit the player is trying to use. If there is no exit, you just get the usual message saying there is no exit.

If the player is tied up, you can ignore the exit, and just say that. But there might be exits the player is too big to go through, and it could check that.

Re: Shiftables, using this code.

I can't move east without wearing the boots. But pushing the cabinet east ignores the restriction on the exit. Is this a Quest bug or a misunderstanding on my part?

1. Re Room no exit message - I went with:

settings.customNoExitMsg = function(char, dir) {
	if(dir === "up" && currentLocation.cannotGoUpMsg) return currentLocation.cannotGoUpMsg
	if(currentLocation.cannotGoMsg) return currentLocation.cannotGoMsg
    return "You can't go " + dir + "." 
}

2. There is an ingest command that returns undefined - The cannot_ingest message in lang-en.js has been commented out.

3. Is there an easy way stop the POV character from performing an action or a group of actions? For example if the POV character eats the eat-me cake and shrinks they can no longer take anything.

With regards to shiftables, you need to give the exit a "noShiftingMsg" attribute, either a string or function. If a function, it takes the character and the item, and if allowed should return true, if not it should give a message and return false.

As I look at it, I am now wondering how great that is; it does feel like your code should work.

1 - For The House on Highfield Lane I used this, after someone complained about it not saying what is available:

settings.customNoExitMsg = function(char, dir) {
  const list = w[player.loc].getExitDirs({excludeLocked:true, excludeScenery:true, excludeAlsoDir:true})
  if (list.length === 1) return "She cannot go " + dir + ". Looks like the only exit is back " + list[0] + "."
  const listString = formatList(list, {lastJoiner:lang.list_or, nothing:lang.list_nowhere})
  return "She cannot go " + dir + " - the exits she can see are " + listString + "." 
}

2 - Oops, thanks for pointing that out.

3 - Yes, the "testMove" function attribute on the character (whether POV or NPC).

Whilst checking that, I realised other related functions are named canXyz rather than testXyz, and for consistency they will become the latter in the next release, so "canManipulate" will become "testManipulate".

Also related, NPCs have a "getAgreement" attribute to handle whether they want to do what the player tells them to, and a more specific "getAgreementGo" function. This previously took the direction as an attribute; in the next update it will take the exit.