As detailed in this blog post, Ade McTavish and furkle have developed code that allows Inform to pass some signals to javascript. In the working code they have published, you can change the background color and images and pop up a modal window. This is very exciting, and they are working on expanding and developing this.
It’s very easy and much safer to add extra opcodes to Glulx or functions to Glk. At the very least they should be checking a gestalt code - some people will make mistakes and misunderstand that initial question.
Hi Dannii - can you elaborate on this - I don’t fully understand what you mean ‘extra opcodes to Glulx’ - what will that achieve?
Ade.
You could for example implement a “call JavaScript function” opcode in your interpreter, in the private use area. If someone’s using a different interpreter, it just won’t understand it.
You could, but then wouldn’t the game be online 'terp dependent? At the 'mo, I’ve tested in both Parchment and Quixe and it works.
For outputting JS code, the most straightforward thing codewise is to add a new type of stream, which is like a memory stream. Open the stream, write to it, and when you close it evaluate the code and put the result into the memory location.
You can see in eblong.com/zarf/glk/glk-spec-074_12.html#s.1.6 the list of selectors and that one block of extensions has already been reserved. If you email Zarf he will (most likely) be happy to assign you a block of selectors. To implement what I just suggested you’d need one function to open the new stream, and one gestalt to check that the interpreter supports it. The rest would use the regular glk functions.
What you’re doing currently relies on the player understanding what is going on. That’s a bad assumption 
On the other hand, this is the first working example of a game I’ve ever seen that is glulx and incorporates javascript signals. If the other way works why is no one using it?
Sorry. You’ve lost me. I don’t know what a selector is, and as a developer, are you saying I need to rely on someone assigning (and presumably) managing them for me? This doesn’t sound straightforward. It sounds like a unmanageable nightmare. Every time I want a new JS function I have to have a new selector?
Well Vorple has been out for years but almost no one uses it either… And actually people have done it before: Parchment / quixe + JavaScript?
No, only assigning, you would be responsible for specifying what the codes do. And no, you would only need to add one function, to open the stream. You could then run any arbitrary code. This is how Vorple works.
It’s a little bit extra work to set up, but it would result in safe, reliable, user friendly code. They wouldn’t need to know whether they’re running the story in your custom interpreter. Nothing would break if its run in a different interpreter. It’s the IF parallel to JS feature detection.
Sorry Dannii - re-reading your posts I know you were making constructive suggestions.
Not at all. The end-user would never need to work with glk directly. That would only be required once, for one single selector, gestalt, and opcode, by the creator of the interpreter. Then a function would be written in Inform 6, which used those to pass information through to the interpreter. All of this is the equivalent to what you and furkle have already done here. (And equivalent to what Vorple does for the Z-machine, though Vorple adds other syntactic sugar and niceties at the Inform level.)
Then instead of putting |code| into their text, authors would use a line equivalent to
make the JavaScript call "window.alert('Hi!');".On most interpreters, this would do absolutely nothing. On the special interpreter which knows how to handle it, it would cause the code to be run.
The main reasons I could see for modifying Glk would be:
- An automatic method for checking the interpreter, instead of asking the player
- Not polluting the transcript with JavaScript calls
However, apart from those two issues, this seems to offer equivalent functionality with less effort to set up.
Thanks Draconis. That’s really useful feedback.
From a quick look at the blog post (I haven’t had time to go into detail) it looks like you are modifying the the interpreter to react to specific text output. Given that fact, the idea is that you might as well modify the interpreter further so that the game can ask it “have you been modified in this way?” If so, the game prints the special codes; if not, not.
The gestalt stuff is just a codified way of asking that.
(sigh)
FyreVM-Web is pure signal metadata. Sending JS signals is just there. But as is mentioned in the OP link to the blog post, FyreVM is still in development on the delivery side of things. Meaning, it needs “standard template” so people can actually use it.
You can see Vorple’s interpreter detection here. It’s for Z-Machine but the basic principle is the same for Glulx.