Cannot open include file adv3.h and en_us.h

Yes, hello. Aspiring new Interactive Fiction writer here, but I seem to have hit a bit of a snag when I try to compile my stuff.

I’m working with qtads, under Debian sid, and here’s what happens when I do the command t3make -d -f Firstgame:

When I just do t3make Firstgame:

I can post the code I used if that would help.

That looks like a really old version of the T3 compiler - it’s up to now. IIRC the Debian package for frobtads includes 3.0.8, which may be where it came from.

Your best bet would be to uninstall the Debian package and then build frobtads from source.

Well, is there a difference on whether I run qtads or frobtads? And does it really matter, what version of the compiler I’m using? I mean, maybe I did a coding error?

[code]#charset “us-ascii”
#include <adv3.h>
#include <en_us.h>

versionINfo: GameID
name = ‘My Practice Game’
byLine = ‘by Silver Smoulder’
verision = ‘1’

gameMain: GameMainDef
initialPlayerCharacter = me
me: Actor
location = startRoom

bedroom: Room
roomName = ‘Bedroom’
desc = “Your bed lurks in one corner of the room. There’s a pile of clothing in another corner. The moon is bright in the sky, as can be seen from your window. The only way out is to the east.”
east = landing

landing: Room
roomName = ‘Landing’
desc = “This is a landing on the staircase. The only place to go is back to your room, to the west.”
west = bedroom

Am I forgetting something, or is it really the compiler?

Nope. The only difference is that the former is an HTML TADS interpreter, the other a text-only one. And of course, frobtads also provides the TADS compiler (the “frob” utility is the interpreter, “t3make” the compiler.)

Only that you’re missing out on many bug fixes and new features. The version you’re using is really ancient and pretty much unsupported. You should be using the compiler that comes with frobtads instead. Being a command-line tool, it’s really easy to build on your own. It only requires ncurses. On Debian Lenny, that means installing the “libncurses5-dev” package should be enough. After that, it’s the usual “unpack, ./configure, make install” business.

Anyway, to solve your specific problem: you should create a makefile for your game. Frobtads comes with a sample game and sample makefile in the “t3compiler/samples” directory. Here’s an example makefile:


The game will be built with “sample.t3” as filename.

-o sample.t3

US English.


Tell the compiler to put object and symbol files in the “obj”

directory, so that they don’t pollute the current directory.

“obj” should be an already existing directory, it won’t be created


-Fy obj
-Fo obj

This is the list of source files making up the sample game.

TADS libraries.

-lib system
-lib adv3/adv3

Game sources.

-source myawesome_game.t
-source rooms.t
-source custom_verbs.t

Game information resource to embed in the game.


If you name your makefile “Makefile.t3m”, then you only need to call “t3make” without any options to compile your game (not sure if this is true on the old version you’re using.) If you named your makefile differently, then you need to use “t3make -f mymakefile”.

O…kay. Well, I got Frobtads, and it "make"d almost perfectly well, until:

./configure worked fine, and it stopped at tcprs.cpp. I have NO idea what this means.

I answered the email, but I’ll reply here too for anyone else encountering the issue:

It’s a new error recognized by GCC 4.6. As a temporary work-around, try to configure by adding “-fpermissive” in CXXFLAGS. Something like:

./configure CXXFLAGS="-pipe -O2 -fpermissive -fno-strict-aliasing"

should work. This has been fixed properly in current Git a while ago, so this won’t be necessary in the next release.

GCC 4.5 and older is not affected.

Btw, I just checked Debian Sid’s packages, and (thanks to Daniel Schepler who maintains the various IF Debian packages) it seems to already provide the latest frobtads version in the “non-free” repository: … ection=all

So it looks like you don’t need to build it from source. Adding the non-free repo and doing “aptitude install tads3-dev” should install everything you need.

I noticed that you need to install the “1:0.13-2” version. The “3.0.8-1” which is also listed there, is the older, deprecated version.

Well, the good news is that with your expert adivce, it compiled like a song.

The bad news is that when I frob Firstgame, it gives me this:

Runtime error: nil object reference Stack trace: ->/usr/local/share/frobtads/tads3/lib/adv3/misc.t, line 511 /usr/local/share/frobtads/tads3/lib/adv3/report.t, line 1926 /usr/local/share/frobtads/tads3/lib/adv3/exec.t, line 1270 /usr/local/share/frobtads/tads3/lib/adv3/misc.t, line 516 /usr/local/share/frobtads/tads3/lib/adv3/misc.t, line 121 /usr/local/share/frobtads/tads3/lib/adv3/misc.t, line 536 /usr/local/share/frobtads/tads3/lib/_main.t, line 126 /usr/local/share/frobtads/tads3/lib/_main.t, line 30 [Hit any key to exit.]

I’m guessing this means that there’s a problem with the adv3.h file… namely that it’s missing these… objects on those lines?


Okay, nevermind. It seems I have made a coding error of some kind, because the game text I copied from “Getting Started in TADS 3” worked like a charm, so now I’m just trying to figure out what I did wrong.

But seriously, thank you SO much for your help. I have to say that it was mega-cool that you responded in like… 5 minutes after I sent you my e-mail. That makes you better than like… 99% of most tech support places, heh.

This is a so called “stack trace”. It lists the chain of function calls (“call stack”) that led to the error. The line numbers represent the line at which a function call happens. The “->” represents the place where the actual crash happened. The relevant place to look for mistakes is near the bottom of the stack trace (since it’s near the place where the error originates from.)

To give you a better idea of it, imagine you have a function (or object method) named foo(val) in the file “foo.t”. Now that function calls bar(val) which is implemented in bar.t, and bar(val) calls another one, baz(val) which resides in baz.t. If you call foo(val) from one of your game source files, say “myfile.t”, with a wrong argument (say you pass ‘nil’ to it, but that isn’t allowed), then foo() calls bar() which calls baz(). baz() crashes because of the ‘nil’. The stack trace is going to look something like:

->baz.t, line X
bar.t, line X
foo.t, line X
myfile.t, line X

So in this case, the place to look for the error is in line X of myfile.t. It might not be obvious, since more files can be listed under myfile.t (since the call stack can go back to the very beginning of the program, like the main() function of the TADS system library.) The way to track down the error is to look at the files you wrote yourself, since it is assumed that the library files that come with TADS don’t have bugs. (They do, of course, as all software has bugs, but it’s not common.)

Heh, OK; I don’t have a support line or something like that set up :laughing:. It just happened that at the time I was sitting in front of the computer.

So, let me see if I got it theoretically:

When I tell it to run Firstgame.t, something in it causes an error because of line 30 in _main.t, then line 126 in _main.t, then line 536 in misc.t, and so on and so forth.

So in order to fix it, I have to find the line in my file, which causes a problem at line 30?

Well, main.t should be error-free. Can you check the version info on t3make? An old compiler building a new version of the library could run into trouble.

Also try removing the files in your obj/ directory and recompile the project.