Any news on this one?
That said, it’s important to understand that the usage of HTML tags in the Web UI implementation is not entirely the same as the usage in TADS 3.0 games. Certain things have to be done differently in order to get the game to use the Web UI. And at present, from what I understand, there is no support for audio output in the Web UI implementation.
Also, games targeted for online play have to be recompiled. Older games can’t be uploaded and played.
Fine, fine. I never cared for that tricky stuff anyway.
I can now make text games that can play in a browser using T3 – very cool. I’m sure there will be future developments, which will also be cool.
Thanks, T3 Web UI team!
Conrad.
More broadly, I notice that Jimmy Maher calls T3 a “nonstarter” in reference to making text games for the kindle, as he’s done recently for his King of Shreds and Patches. (Cthulhu meets Hamlet! Does he eat Hamlet? Is this why Hamlet’s insane? – I haven’t actually finished the game yet.)
Anyway, he’s got it published for real…
filfre.net/2012/01/the-king- … e-answers/
…but you Just Can’t Do these things with TADS 3. – I don’t mean to stupid here, but why on Earth not? Is it because we’re hung up about stupid crap like the status line not properly displaying? Or is there something inherent to TADS 3’s inner workings that can’t be done on a kindle or is difficult to implement on the web?
Conrad.
ps - Inform 7 – man, I just have trouble wrapping my head around using English that way.
It’s because the TADS VM is just so much more complicated than Glulx. ZMPP is the only new implementation that I know of (and it’s incomplete too), all the other TADS interpreters are ports of the original C code. Whereas there are many independent Glulx implementations.
This is a longish saga. Briefly, there is no inherent reason why a TADS 3 virtual machine couldn’t be written in Javascript. It’s just a huge job, and nobody has bothered to do it (though Dannii has considered it, I believe).
The route that MJR chose for the T3 online delivery system is more powerful – for instance, it will allow multi-player real-time online play, I believe – but it also places some rather stringent requirements on how the author can deliver the file to players via hardware devices.
I would not (offhand, not being a programmer) expect that the TADS 3.1 Web UI would ever be suitable for a Kindle. I don’t know how Jimmy is doing what he’s doing – by modifying Quixe to work with the Kindle or by some other method. You’d have to ask him.
It’s a bit of a chicken-and-egg problem. Amazon won’t accept you into the Kindle Developers program unless you have an app that you can convince them is worth bringing to the platform, and once you do have the app, you still have to port it to Java and make it perform well on the hardware.
I gather from some of Jimmy’s previous posts that Amazon is involved in vetting and testing the apps throughout the project. It’s not like the App Store where you pay your developer fee, do the work, and cross your fingers when you submit it for review.
TADS 3 on the Kindle is only a “nonstarter” because Jimmy is not interested in writing an interpreter to run TADS 3 games. I can’t say I blame him; it’s a giant pile of work and it leverages almost none of his existing code. He’s basically saying if you want it, find a different publisher. That’s entirely fair.
I like my Kindle. If and when I finish my own giant Lovecraft thriller, I’d like to get it running on the Kindle. iOS support will probably come first, because it can leverage an HTML5 UI and a C++ engine, which basically what we have today with Web UI. The main hurdle is coming up with a touch interface that doesn’t suck.
The VM is really not that complicated, and it’s well documented. I have an independent, partially complete implementation in JavaScript, and I’m hardly an expert on either VMs or JavaScript.
However, there are a lot of intrinsics, and you need most of them working to run anything beyond very simple programs. The documentation here is not as helpful; implementation involves a lot of time with the System Manual and the T3 headers.
As I understand it, intrinsics are like the accelerated opcodes in Glulx, except they’re not optional. But outside of a narrow technical sense, neither are the Glulx ones, if you’re talking about running modern I7 titles on less powerful hardware.
You have a partial T3 JS implementation?? Is it public yet?
Well now here’s a question–
Can I make a game that automagically emails me a transcript of the play? Such that the player would need to turn it off rather than turn it on?
As far as the “far more powerful, but far more difficult to deploy” – well, that says it all, doesn’t it? I don’t have a server to upload games onto, don’t want to have a server, don’t know the first thing about it… I just want to write text games.
Conrad.
ps - That’s not me being anti-technical. I don’t at all mind TADS having a rigorous, technical approach. That’s me being a hobo by choice and having a budget of $0 to spend on buying servers and keeping them online.
Yes, you can. But it’s a bad idea. It would be spyware.
Nah. I’d warn 'em.
C.
No, not really public, but you can look at the code if you promise not to judge me.
The image loading code from the top of the file to the first half of start_v1 does what it’s supposed to. The big chunk of TODO code at the end is where the fabled intrinsics would go, if I had any of them in place.
Everything in between is a mess.
At one point it was able to add some numbers together and print out a result. I commented out most of that when it became clear I didn’t understand exception handling. What’s there now will pretty-print a function with nested try/catch/finally blocks. (Assuming you run it from the command line with d8; I haven’t tried it in a web browser.)
It’s a fun project and I do intend to pick it back up again soon. You could maybe repurpose the image loading code and the intrinsic functions (once implemented) for ifvm.js, but I doubt my method compiler is going to be very useful for you even once I get it working.
Intrinsics are some kind of semantic primes that T3 uses to manage the virtual world?
C.
No, the world is managed entirely in T3 code. The VM does not know anything about it. Intrinsics are system code. They deal with I/O, pointer arithmetic for managing memory, converting between datatypes, stuff like that.
Good lord! And that stuff isn’t documented?
You’re trying to build that by reverse engineering–
–Can’t you ask for the code to the original VM or something?
You’re bonkers.
You are of course correct, the VM itself is the easier part, the intrinsics are what I thought were quite challenging (and there are some subtleties about searching the object system that I have not completely figured out either), and there’s just a huge amount of this stuff. In addition to what Ben mentioned, I also at times found it impossible to gain understanding of things without looking at the source code (which is available). I stop before I start ranting which would not be fair since I actually have not completed that work so far 
It’s documented, and the source code is available to everyone; no need to ask for it, it can be downloaded at tads.org. However, having source code with good comments does not mean a re-implementation is easy.