Workbench Woes

I’ve just noticed that Workbench has no Save As command for projects. This is a problem. I need to be able to create several versions of a project – one with mp3 resources, one with ogg resources (which, by the way, are not recognized as multimedia files in the file browser), and one with no audio. Possibly one optimized for Web distribution, another not – I don’t understand the variables there yet.

I can do this … sort of, I think … by copying and renaming the .t3m file. But for some reason, this morning it appears that only one of my .t3m files (which were mostly identical last night) contains any pointers to the source, include, or resource files. The other .t3m files are totally empty and totally useless. This strongly suggests that TADS is doing some sort of misguided housekeeping behind the scenes, because I certainly didn’t delete every file in those projects.

I’ll try making complete copies of the entire project folder. That ought to be safe, though it will mean lots of extra housekeeping, as I’ll have to drag-copy source files from one project folder to another each and every time I make changes.

No Save As??? What’s up with that?

For the normal version, you can stick with Ogg files. All multimedia interpreters support it (MP3 is not supported on some platforms due to legal reasons.) You’ll only need to worry about MP3 in the WebUI version.

For the web build, you can probably just put your mp3 files in one directory, and the ogg files in another and simply change the makefile to include one of the other. Like:


When building the ogg version, comment the one out and uncomment the other. Finally, take a moment to marvel at the W3C committee’s decision no to make Ogg Vorbis mandatory for HTML5 support and instead letting users deal with all this nonsense.

Yeah, I agree that leaving out Ogg support from HTML5 was dumb. (I’ve heard that ogg was scotched due to pressure from Apple, which would not be surprising.)

I’m not sure changing the makefile will do the job, though. All of the tags have filenames, which will have to be edited to end with either .ogg or .mp3. And if they’re in folders, which they are, I’ll also have to change the path. This is very manageable – it’s just a few extra steps.

You can use preprocessor directives to switch between mp3 and ogg in your source.

modify PlayAction
	execAction() {
		"""<sound src="mp3/science.mp3"/>""";
		"""<sound src="ogg/science.ogg"/>""";
		"Playing sound. ";

It’s kind of ugly but not unbearably so.

TADS_INCLUDE_NET needs to be defined for WebUI to function, so it’s a good definition to test when you want to handle things differently based on the output format.

Wouldn’t it be better to directly test for MP3/OGG support, rather than checking TADS_INCLUDE_NET? Like so (warning: code not tested):

[code]modify PlayAction
execAction() {
if (systemInfo(SysInfoMpeg3))

  "Playing sound. ";


Testing for the inclusion of WebUI seems a bit fragile, given the variations in file-type support between different browsers (and possibly desktop interpreters as well).

At the moment, this is moot, since the WebUI doesn’t currently support audio output in any form.

It’s a bit unsettling to realize that I may be the first person who has any concrete need for audio output in the WebUI. I’m working on a game for the Spring Thing and writing some short music cues for it, and I’d like it to be playable in a browser, because I suspect players are starting to think of that as an emerging standard.

But if there’s no audio support, I’ll simply have to decline to provide a browser-playable version – because, you know, the game should be evaluated based on what it is, not based on a subset of what it is. You can turn off the music in the game if you want to, but the interpreter shouldn’t exclude it without giving you the option.

I’m not actually complaining, here – I’m just saying, that’s the situation. I’m comfortable with asking players to download QTads, because that’s not hard to do.

What about Ben’s offer here,

Ben and I have exchanged a few messages about this. I know he’s interested in putting together an audio implementation. I would be very happy to see that happen! But I have no idea how long it might take, or what other priorities he may have.

Also, I’m not competent to provide him much in the way of assistance, other than sending him a game that has audio in it, which I did.

Even when such an implementation becomes available, it’s not at all clear to me how a game with audio could be tested prior to release. What the TADS 3.1 documentation says is, there are two ways to make a game playable online: Either you upload it to the IF Archive and create an IFDB page for it, or you set up your own server. In the former case, it’s released – it’s not something that testers can try out privately, such as, oh, before a competition entry deadline, for example. And I’m certainly not competent to set up my own server.

When I create a WebUI version of a T3.1 game and double-click on the game file, it runs in the HTML TADS interpreter. It does not run in Chrome, Firefox, Safari, Opera, or IE. It should be obvious that an author would want to test a game in all of the leading browsers, on both Mac and Windows (and possibly Linux too) prior to releasing the game. Until we understand how the pre-release testing process can be handled, it would be premature to plan on doing a browser-playable version of a game that includes audio, even if the software for including audio becomes available. There are just too many unknowns.

Actually, it runs in IE. What you see is an IE window with the HTML TADS GUI wrapped around it.

The main drawback to that approach is that the .t3 file would have to include both MP3 and OGG, since either could be requested based on the result of that test at runtime.

The compiler directives make it one or the other: you pick the one that’s most likely to work on the platform you’re targeting, and set up the makefile accordingly. For web it’s MP3, for desktop it’s OGG.

I haven’t tested it either, but I believe that systemInfo(SysInfoMpeg3) will query frob or t3run - the command line program executing the .t3 file - rather than the browser.

If you could instead PM me the actual sound tags you use in your game, that would help me understand the critical features you need - which may or may not be some smaller subset of the overall functionality.

Online testing is just a matter of putting the file online somewhere - your web site, the public folder in your Dropbox, anywhere it can be downloaded.

For example, here is a link to the sample game I put together for Ron G. earlier: … ractice.t3

The first part - - stays the same for all games everywhere. The second part is where you put in your own file’s URL.

My file URL was - if you click it you will download the actual WebUI .t3 file, which you can play in the offline player.

Put the two parts together and it becomes a link to play online.

One thing to look out for is that the filename of the game needs to include the version. Because if you upload a new version of the game but don’t rename it, the old one will be used because of the local cache of the server where the game runs.

They’re just standard HTML TADS tags:

playAlbum { "<SOUND SRC=\"res/oggs/Trawler.ogg\" LAYER=FOREGROUND FADEIN=0.001>"; "<SOUND SRC=\"res/oggs/Title.ogg\" LAYER=FOREGROUND FADEIN=0.001>"; "<SOUND SRC=\"res/oggs/Naiad.ogg\" LAYER=FOREGROUND FADEIN=0.001>"; "<SOUND SRC=\"res/oggs/Undersea.ogg\" LAYER=FOREGROUND FADEIN=0.001>"; "<SOUND SRC=\"res/oggs/Bull.ogg\" LAYER=FOREGROUND FADEIN=0.001>"; "<SOUND SRC=\"res/oggs/MInotaur.ogg\" LAYER=FOREGROUND FADEIN=0.001>"; }

I wasn’t aware of this … and I don’t recall seeing it mentioned anywhere in the documentation for web delivery. The docs specifically say, unless I’m misremembering, that either you upload it to the archive, or you set up a server.

If that works, that’s terrific. I’ll try it out. I mean, I have a website and all – I don’t need to use dropbox.

This would be the “or you set up a server” case. Which you have; or rather paid for access to one that’s already been set up and on which you uploaded your website.

Not working yet. I compiled the Web version using the WebOutput makefile you provided. It compiled. I uploaded it to dropbox. Then I added the prefix shown above to the dropbox link. I get “The TADS interpreter can’t run this game, because the story file path is invalid.”

I will test further.

Weirdness. Both firefox and chrome delete the “http://” from the complete URL I enter, and then the Show Details on the error complains that it’s not a valid URL because there’s not . I could be wrong about that, though.

The game server will check the remote file’s modified date and length before using its cached copy. So there’s no need to rename it to avoid the cache.

It might still be a good idea, to make sure everyone is testing the same version, and to deal with the usual headache of incompatible save files across versions.

No, the TADS server accepts the storyfile= parameter exactly as sent.

It may help to construct the URL in notepad and then paste it into the Firefox / Chrome address bar.

Thanks. That does the trick – it’s working now – hooray!!!

OK, that’s easy enough. I’ll have it working soon - if not this weekend then within the next week.

Excellent! :slight_smile: