TADS 3 workbench / macos wine / Web UI

Excited to be giving TADS 3 a try again, and I’m setting up my development environments.
The Workbench works fine for me so far under Windows 7.
It also seems to work fine on my MacOS (10.8) using wine, with one exception: If I create a new project using “Web UI”, I only get a blank window when the game is run. This was easily reproduced on a friend’s mac laptop. However, creating a standard project works fine (game displays when ran). Is there a Web UI workaround?

From what I understand the web UI uses IE, so I guess wine on Mac is missing something there? Maybe a Windows VM on Mac would be a better choice?

I can recommend “parallels” for OSX: with a win xp installation tads workbench runs perfectly.

Using Crossover (on OSX), I find that the Workbench Options box is displayed in a defective manner, and also that whatever options you set are not saved between sessions. I’ve never tried using the WebUI within OSX.

Parallels is a better choice like Mikawa says, as I think Crossover is emulation (like wine) but Parallels is virtualization.

Was going to see if I could use qtads as a substitute for htmltads, but it appears to have not kept up with newer releases of the language. So, I finally installed VirtualBox (a free alternative to Parallels or VMWare fusion), and am now installing an old copy of Windows XP x64. I expect this to work (fingers crossed).

Cool, workbench web UI now works! I was hoping I’d get to develop on this nice Mac laptop. :smiley:

What do you mean? QTads is as up-to-date as it possibly can be. It supports TADS 3.1.2, which is the latest available release.

Are you sure you went to the correct website?

Edit:
Oh, I missed the “WebUI” part. WebUI games aren’t supported yet (regardless of the TADS version used to create them.)

Sorry, not dissing on qtads at all. I’m still in the setting up my environment stage, and I’m trying everything out.

When I had tried qtads 2.1.5 (Mac OS), testing it on the web version of Return to Ditch Day (ditch3web.t3) produced a VM run time error: “program requires intrinsic function set tads-net/030001, which is not available in this interpreter”.

I’m hoping to web deploy my final effort, so I’m trying to make a simple hello world (or would it be “hello sailor” :wink: ) example work from end-to-end before I really get started. But now that I’m typing this, I’m thinking I might be confusing HTML TADS with simply hosting standard TADS in a playable form online. I’ll check…

Anyway, this was a long way of saying that I’m not besmirching all the (what I’m sure is) good work you’ve done on qtads.

TADS3 game compiled for web UI cannot be played in QTads, however you can launch web UI game in FrobTADS, which is another RealNC’s interpreter. I’m using it on linux, however it should run on Mac OS too. It is designed for command line use. You would run it something like this:

frob -i plain -k utf8 -N 44 web-game.t3

And it will print URL you could open in your web browser.

HTML TADS is an extension to the standard TADS interpreter allowing game authors to use some HTML tags to do some simple formating of output text. See http://www.tads.org/t3doc/doc/htmltads/intro.htm. Hosting game online is different matter: http://www.tads.org/t3doc/doc/sysman/web.htm. In online play you will actually use real web browser instead of HTML TADS to interpret tags and display formated text.

This is good news. I had been under the impression that you can’t run a web UI game unless you set up a web server to host it on. I did not know that you can test run it without a separate web server configured and running. This is good news because it means if I develop for web UI I’m not automatically cutting out all those users who would rather run the game locally and aren’t tech saavy enough to configure and run a web server of their own. I may have to reconsider what I was doing now that I know this is an option, because the HTML available in QTads does not handle the HTML DOM model like a modern browser does, and using DOM to control placement of status boxes would be a LOT nicer than the banner system. It would also allow me to make images overlap images, which could be nice to make a game with transparency images that overlay on top of the image for the room you’re standing in.

Players don’t need to run a web server to play WebUI games. You can publish to IFDB and it will automatically offer a “Play Online” button for your game.

Alternatively you can put your game file anywhere that offers an HTTP interface (Dropbox, S3, Github) and then use gs.tads.io to serve up player sessions, by linking to a URL similar to this one for Return to Ditch Day, but with your own t3 file as the storyfile parameter.

WebUI games can also be downloaded and played like a regular IF game on Windows desktops. A web server is involved but it runs as a background process and the player doesn’t need to configure anything.

I had no idea that frobtads could run webUI games as a server! I’ve been kinda hemming and hawing on messing with that because I don’t like to use VMs for anything more than a few minutes and I work on OSX.

This is great news! runs off to try it out

This is such good news! Now I can focus on getting right to work on what I have wanted to do all along.

Thanks so much RealNC for your contributions to the TADS world!

I just tried frobTADS webUI method described above, and modified my t3make file as described here:
tads.org/t3doc/doc/sysman/we … anual_port
to build a webUI version of my test game and it works great. Thank you so much RealNC. This is great.

(I haven’t done anything with any HTML to try it out yet - just verified that the plain vanilla text shows up in the browser right.)

Mignon, the most recent version of frobTADS on RealNC’s website was built on August 31. If your version is older than that you probably want to get it updated first. My version (downloaded August 7) didn’t work so well with webUI until I did that.

Well, I had downloaded it, but realized that I had already the new version installed. I created a dummy game with webUI enabled and it worked as advertised. This is so great! I had given up on wonky HTML Tads limitations (I guess I’m spoiled by CSS 3) that I really didn’t want to be bothered to even try to support it. Now to decide if I want to try to build my game with support for both (limited support for html TADS but ability to run on command-line only interpreters) or just web UI…

One feature I’d like to support would be simply having two info-boxes like so:
box 1 = the current room’s long description, with a mechanism for automatically knowing when it has become “dirty” and needs refreshing, without you having to consume a turn to issue an explicit “look” (*) command it would refresh the box when needed.
box 2 = your current inventory list, again with a mechanism that knows when it becomes dirty and needs a refresh without you having to issue “inventory” commands.

I did this with banners once before, but trying to control placement of banners is nearly impossible without the benefit of the cascading style controls.

The fact that you have to take up game turns issuing look and inventory commands often bugs me about a lot of interactive fiction games. Because often all you’re doing is just trying to re-display information that has scrolled away and yet would still be right in front of your eyes if you were actually there. (So it doesn’t make sense that it advances the clock).

That’s just the default behavior. You can set the time the LOOK action takes to 0. It’s just three lines of code:

modify LookAction { actionTime = 0; }

I already knew about that. But this is a frustration I usually feel when playing someone else’s game I didn’t write. It’s extremely common for writers to leave the default behavior in place and it’s a default that in my opinion makes no sense.