Interesting... Idea? [Easier TADS library for new users]

I definitely, at the moment, won’t be able to make this BUT, I hope somebody else might take interest in this little brainchild, you could put it.


I’m making/writing ideas for a library based on adv3. Wanna help?

Okay, now I begin my speech.

I’m new to TADS, realistically, but after a whole bunch of reading, and just coding around in general, there are a couple things I miss. Not that I think are flaws or ‘inspiration walls’ or anything, but simple things that could be easier. I spent all day today not programming, but reading through, really reading through various conversation here on the forum. And the general consensus is that TADS isn’t very beginner-friendly, as stark as that is. Now, this library I’m proposing, it’s not a solution to that. I want, kind of, to make TADS programming, to newcomers, less defining custom properties and coding in methods just to make a simple table, and more just making and experimenting and learning things. Because that’s what people want to do when they are writing stories. Especially when they’re newbies. I know I, if I wasn’t so stubborn and wasn’t so taken with the shear power of TADS, would’ve left a week ago. And if I didn’t find, I would’ve left even earlier than that. So here I am, bringing to you a light of a little idea I had this week and spent writing from last night up until right now, Basic Lib (we’ll work on the name)
Thank you for listening to my TED-talk. :smiley:

Right now it’s a adv3 based library (in my eyes many things extend from existing classes in adv3) but maybe later it’ll expand into adv3Lite and source code. Maybe. That’s a complication I don’t understand because I’m just the ideas guy.

I wrote up an entire .txt doc on Github here if anyone wants to see the potential of this, and other suggestions for things to add. I really want to see where this library goes and how it helps others. In any case, it’s stuff I’ll write in a source file myself if I have to because I would like to use these features!

IMPORTANT: It’s not finished! I have ideas down, but not how exactly they’d work. Take the Nothings, for example. I don’t know where to begin coding an entirely new primitive class, so I don’t know exactly where I would start with that. But, I do have what each feature’s main purpose would be.

If there’s any features that ALREADY EXIST in adv3, not ‘can be worked-around’, please let me know.


Hey there. Some of your classes are fine ideas. I wonder if your idea is more of an extension idea rather than a library replacement idea. It may be a little overwhelming to load the basic library with a bunch of extra classes that could potentially be easily implemented with the base classes. Some people say the adv3 library is already daunting enough with its many classes. Again, an extension with a bunch of basic furniture types wouldn’t be a bad idea. Feel free to implement them and share them either here or on IFDB…

1 Like

The minus sign thing would probably have to be coded into the TADS language, so I don’t know how likely that would be…

Yes, I’m not sure I made it clear that those furniture extensions (that don’t have to be used for furniture) extends off of ComplexContainer, because I hate having to write a new one for every table I want to properly implement.

I’ve seen that view. And… yes there are a lot of classes in adv3. Maybe I’m not adhere-ing to that… but I would really like those classes! Also I just thought last night that my Script class is obsolete. But RunningScript and ActorScript might be useful, but their workarounds are probably just as big as the actual class… I’ll see when I implement it.

Okay. Maybe no minus sign. But, I still think Attachment should work differently. I thought that might be a controversial topic :smirk: but I left it in to see, generally, what people think of a new meaning of ‘attachment’.
^ Scratch that. A fallacy in the Tour Guide mislead me to believe that all attachment had to be made explicit, but taking a look again at LT3 tells me otherwise. The system now works just fine.

But cool, thanks! I’m going to try and see what those class defs look like today, should be simple. At least it’s straightforward with this plan.

I haven’t experimented with Dialog much but from what I understand it’s a good bridge between “too codey” in TADS and the natural language of Inform 7 which authors usually love or hate.

I didn’t learn Dialog extensively, but from a cursory documentation review it felt like “oh this is how you’d do this in I7” but more concisely in a way that would appeal to coders.


haha … wrong post here, buddy.

Sure buddy, was just pointing out another potential system that splits the difference between TADS pure code and Inform’s version of English based on-

Glad you enjoyed it!

Oh. Well then, yes. I don’t have enough experience with other IF development systems to make an educated thesis on the matter, so I didn’t compare TADS with anything.

Oh wait you’re a mod sorry…

P.S… Um, thank you for the title change, although I don’t want to clarify this as an easier library. Like John said, it only plans to add more classes and complication, possibly. My intention is to simplify some common things done in TADS a lot I’ve seen and others have too, and that AIMS not to be easier, but to make things intuitive. I really don’t like to feel like I’m over designing a common thing when without the over designing the user feels left out. So, not easier, but … intuitive. That’s probably not the word I’m looking for. If somebody finds something right, let me know.

Feel free to edit your original post and change the title to anything you’d like then, preferably something more descriptive than “Interesting Idea” so people searching the forums in the future will have a better idea of your post content.


I DID IT! Took me all day researching how a ComplexContainer works BUT I DID IT!
I kind of feel annoyed about how easy it was, to be honest lol…

class ComplexSurface : ComplexComponent, Surface
class ComplexUnderside : ComplexComponent, Underside
class ComplexRearContainer : ComplexComponent, RearContainer
class ComplexRearSurface : ComplexComponent, RearSurface
class ComplexInnerContainer : ComplexComponent, Container

class Table : ComplexContainer, Heavy
    subSurface = perInstance(new ComplexSurface())
    subUnderside = perInstance(new ComplexUnderside())
    initializeThing() {
        subSurface.targetObj = self;
        subUnderside.targetObj = self;
    contentsListed = nil

Okay, sorry I’m being a bit spammy but I released an extension.t file on Github with a couple of furniture items, if anyone’s interested. More updates coming soon, I hope!

What’s the link to your extension?

Link? The github should contain the WIP extension.t

That’s this GitHub?

Yes that is the github. Is the link not linking correctly?

Seems fine, it’s just all the way at the top of the thread in the first post so I thought it might be helpful for the other commenter to re-post it down here.

1 Like

Hello again everyone! I made another update to the extension, and I wanted to ask, are there object pointers, i.e. can I make referring to one object refer to another instead? If anyone knows, please let me know. Thanks!

I don’t think I understand what you mean by “object pointers”, can you give an example of what you’re wanting to do?

Okay so I have the Transformer Class which is supposed to ease use of switching object around. Each VocabObject is modified to have a self_ prop, which usually points to self. But, when a Transformer object transforms, it’s self_ prop changes to refer to it’s reference object. It’s in this way you can easily use obj.self_.desc or some manner in order to access properties without a bunch of conditional stuff to check whether the object changed or not. And in cases of recursive and looping transforming, it gets really complicated. What I was wonder was do I have to refer to the object by a property, or can I replicate the object to be pointed to, if I just call obj. So instead of obj.self_.prop it’s obj.prop.