[TADS]
Mil...@aol.com
types:
Like an Actor, for example
I know I can have sdesc, ldesc, actordesc, isHim, isHer, noun,
adjective but I know there are probably a lot more that I am unaware
of.
Stephen Granade
Your best bet is to look at the actual object code in adv.t and see
what properties it defines. Sometimes the comments before the object
will also tell you its possible properties.
There will still be some things that aren't obvious (like a heredesc
for fixedItems, which gives them a description when someone LOOKs at a
room), but that'll get you started. Reading source code to TADS games
you've played can also be helpful.
Stephen
--
Stephen Granade
ste...@granades.com
Plugh!
I wish that you had posted this as a seprate thread, since it might
have received more attention. I changed the title, but that won't show
as a separate thread on Google, just most good newsreaders.
This is a question dear to my heart, but the only answer I can give is
to advise you to look at Appendix A. I have been searching for a
*long* time for a tree-like representation of classes, showing which
derives from which and which introduces which properties.
If anyone knows of such a thing, please share it with the world -
preferably by starting a new thread with a clear title.
I would urge MJR to consider including such a thing in the T3
documentation.
Richard Bos
> Mil...@aol.com wrote in message news:<e173bb2a.02121...@posting.google.com>...
> > Is there any where that I can get a list of attributes for all item
> > types:
>
> I wish that you had posted this as a seprate thread,
He did.
> I changed the title, but that won't show
> as a separate thread on Google, just most good newsreaders.
Actually, on _good_ newsreaders it won't. Good newsreaders thread by
references, not by something as fickle and human-mungeable as the
subject.
In my newsreader, MileOut's post started a new thread, and yours is part
of that thread. So is Stephen's, and no other (yet).
Richard
Gadget
Bos) wrote:
>> I changed the title, but that won't show
>> as a separate thread on Google, just most good newsreaders.
>
>Actually, on _good_ newsreaders it won't. Good newsreaders thread by
>references, not by something as fickle and human-mungeable as the
>subject.
>
>In my newsreader, MileOut's post started a new thread, and yours is part
>of that thread. So is Stephen's, and no other (yet).
>
>Richard
I have been using Agent for YEARS. I consider it the best newsreader
out there, but it also threads by subject line.
Cheers,
Harry
-------------
It's a bird...
It's a plane...
No, it's... Gadget?
-------------------
To send mail remove SPAMBLOCK from adress.
Mil...@aol.com
If there was a way to edit or delete posts I could have fixed it, and
if I didn't have to wait 3-9 hours I would have known immediately.
What's with the absurd delay?
Matthew F Funke
Degree of distribution.
Usenet files are bounced all over the world, and may take a while
before those packets show up in a place where the newsreader in your PC
can get at them. With that much information posted to that many places,
you have to be willing to wait a bit before you see them again.
There are other issues, of course, but that's a biggie.
--
-- With Best Regards,
Matthew Funke (m...@hopper.unh.edu)
Stephen Granade
> Mil...@aol.com wrote in message news:<e173bb2a.02121...@posting.google.com>...
> > Is there any where that I can get a list of attributes for all item
> > types:
> >
> > Like an Actor, for example
> >
> > I know I can have sdesc, ldesc, actordesc, isHim, isHer, noun,
> > adjective but I know there are probably a lot more that I am unaware
> > of.
>
> I wish that you had posted this as a seprate thread, since it might
> have received more attention. I changed the title, but that won't show
> as a separate thread on Google, just most good newsreaders.
>
> This is a question dear to my heart, but the only answer I can give is
> to advise you to look at Appendix A. I have been searching for a
> *long* time for a tree-like representation of classes, showing which
> derives from which and which introduces which properties.
The TADS documentation came with a tree diagram of classes in adv.t,
though not a list of the properties. I took a look at the archive,
thinking it might be there, but no luck. I'll see if I can scare up a
scanner and make that bit of documentation available once more.
Kevin Forchione
> This is a question dear to my heart, but the only answer I can give is
> to advise you to look at Appendix A. I have been searching for a
> *long* time for a tree-like representation of classes, showing which
> derives from which and which introduces which properties.
>
> If anyone knows of such a thing, please share it with the world -
> preferably by starting a new thread with a clear title.
- Fixed
- UntakeableActor
- Person
- Component
- ComplexComponent
- Decoration
- Distant
- tads#306 ( 32a)
- defaultSky
- RoomPart
- tads#2f0 ( 312)
- Floor
- tads#38d ( 3c7)
- defaultFloor
- tads#3e7 ( 42b)
- defaultGround
- tads#306 ( 32a)
- defaultSky
- tads#326 ( 352)
- DefaultWall
- tads#2f1 ( 313)
- defaultEastWall
- tads#301 ( 325)
- defaultWestWall
- tads#34e ( 37d)
- defaultNorthWall
- tads#353 ( 384)
- defaultSouthWall
- tads#433 ( 480)
- defaultCeiling
- Passage
- Stairway
- StairwayUp
- StairwayDown
- ThroughPassage
- ExitOnlyPassage
- Door
- AutoClosingDoor
- frontDoor
- SecretDoor
- HiddenDoor
- Enterable
- TravelPushable
- tads#42f ( 47c)
- Room
- OutdoorRoom
- DarkRoom
- kitchen
- hallway
- entryway
- suitOfArmor
- tads#581 (Chair, Fixed)
- tads#582 (Fixed)
- tads#583 (Fixed, OpenableContainer)
- tads#585 (Fixed, OpenableContainer)
- Dispensable
- ComplexContainer
- Keyring
- BaseContainer
- Container
- StretchyContainer
- Dispenser
- Matchbook
- OpenableContainer
- LockableContainer
- KeyedContainer
- tads#583 (Fixed, OpenableContainer)
- tads#585 (Fixed, OpenableContainer)
- tads#47d ( 4d4)
- Booth
- tads#376 ( 3ab)
- Surface
- Bed
- Platform
- Chair
- tads#581 (Chair, Fixed)
- Key
- BasicLocation
- NestedRoom
- HighNestedRoom
- tads#372 ( 3a7)
- Vehicle
- tads#450 ( 4a6)
- BasicChair
- BasicBed
- Bed
- tads#3bc ( 3fb)
- BasicPlatform
- Platform
- tads#47d ( 4d4)
- Booth
- Chair
- tads#581 (Chair, Fixed)
- tads#42f ( 47c)
- Room
- OutdoorRoom
- DarkRoom
- kitchen
- hallway
- entryway
- CollectiveGroup
- Button
- OnOffControl
- Switch
- Flashlight
- Readable
- HtmlSign
- Wearable
- Settable
- Dial
- NumberedDial
- Food
- tads#584 (Food)
- FillMedium
- Intangible
- SensoryEmanation
- Odor
- Noise
- Lever
- SpringLever
- lightProbe
- tads#337 ( 364)
- LightSource
- Candle
- Flashlight
- tads#2fa ( 31c)
- Matchstick
- tads#476 ( 4cd)
- Actor
- UntakeableActor
- Person
- tads#579 ( 5fa)
- me
- axe
Richard Bos
> On Wed, 11 Dec 2002 15:56:26 GMT, r...@hoekstra-uitgeverij.nl (Richard
> Bos) wrote:
>
> >> I changed the title, but that won't show
> >> as a separate thread on Google, just most good newsreaders.
> >
> >Actually, on _good_ newsreaders it won't. Good newsreaders thread by
> >references, not by something as fickle and human-mungeable as the
> >subject.
> >
> >In my newsreader, MileOut's post started a new thread, and yours is part
> >of that thread. So is Stephen's, and no other (yet).
>
> I have been using Agent for YEARS. I consider it the best newsreader
> out there, but it also threads by subject line.
Not if you tell it not to. I use Free Agent, and I could set it up to do
so if I wanted to confuse myself, but I don't have to.
Richard
Richard Bos
> Yeah sorry, I made an arse of posting a new topic.
Not particularly - the only real problem was a less than enlightening
subject. The rest is up to overly helpful newsreaders.
> If there was a way to edit or delete posts I could have fixed it, and
> if I didn't have to wait 3-9 hours I would have known immediately.
>
> What's with the absurd delay?
What delay? You mean you cannot send a cancel message until after three
hours? Or are you complaining about the delay in replies? Well, that's
just how Usenet can work - sometimes, people are off-line.
Richard
Gadget
Yeah, I discovered that too. I guess I just never needed to alter
those settings.
Plugh!
newsreaders.
I saw 9 posts on the thread & thought I was going to see a ton of info
about TADS properties :-(
Plugh!
> though not a list of the properties. I took a look at the archive,
> thinking it might be there, but no luck. I'll see if I can scare up a
> scanner and make that bit of documentation available once more.
>
Thanks, Stephen,
that would be most welcome. It would still be nice to have a
definitive statement about the properties too, though. Maybe in T3,
but I don't hold my breath (maybe Kevin can post what he found?).
Gadget
That's usenet ;-) Discussions spin off into infinity and no-one can do
a damn thing to stop that. Must be an alien conspiracy.
Kevin Forchione
> This is a question dear to my heart, but the only answer I can give is
> to advise you to look at Appendix A. I have been searching for a
> *long* time for a tree-like representation of classes, showing which
> derives from which and which introduces which properties.
>
> If anyone knows of such a thing, please share it with the world -
> preferably by starting a new thread with a clear title.
What would this look like? In TADS the introduction of a property by a
class isn't always as important as the class for which a property is
defined for an object. Can you provide a sample of what you'd like to
see?
--Kevin
Shadow Wolf
news:3df860a6...@news.nl.net:
He's talking about the delay between the time you post a message (via
Google) and the time the message shows up on Google -- You can't even _see_
your own message for up to nine hours when Google is your only Usenet
access. And this delay _is_ absurd -- you're looking for the message on the
server you posted it to, after all.
--
Shadow Wolf
shado...@softhome.net
Stories at http://www.asstr.org/~Shadow_Wolf
Craig Thomson
>This is a question dear to my heart, but the only answer I can give is
>to advise you to look at Appendix A. I have been searching for a
>*long* time for a tree-like representation of classes, showing which
>derives from which and which introduces which properties.
Well, I have knocked up a very quick and very dirty perl script which
looks for classes and objects and finds their base classes and
attributes.
I am about at the limit of my limited perl abilities and at the limit
of my parsing ability.
Anyone with some perl knowledge who wants to take the ball and run
with it please let me know and I can post the short script here.
Some caveats:
o The script is probably really bad perl
o It is currently hard coded to only look in advt, but should be
easy enough to add some smarts to
o I have probably made some terrible assumptions due to
my lack of knowledge about the tads grammar and
about parsing in general.
Craig
Plugh!
> class isn't always as important as the class for which a property is
> defined for an object. Can you provide a sample of what you'd like to
> see?
well, there's not really anything to say "if I use an objct of class
Actor, it will have the following properties..." Nor, out of interest,
which class in the class tree introduces which property e.g my Actor
gets a contentsVisible property from class 'thing', an isqcontainer
property from class 'qcontainer' and declares its own maxBulk property
which is arguably redundant since it already has one from class
'container' (no it's not, see next para).
I realise what you mean when you say "introduction of a property by a
class isn't always as important as the class for which a property is
defined for an object" (I think). In this case, we are saying that the
maxBulk property of container (default = 10) is masked by that of
Actor (default = 20).
I think what I am trying to say is that it would be nice to be able to
see at a glance, in one lcoation, "if I declare an objct of class X,
it will have properties Q,R & S".
And, to <digress>, I really dislike the idea that all actors are
automatically containers and would have preferred basicActor which was
not an carrierActor drived from it which was.
But, that's just becuase I strongly dislike TADS ability to put
anything into anything else by just setting its location property. In
my opinion is should only be allowed to put things into objects of
classes derived from 'container' </digression>.
Quintin Stone
> And, to <digress>, I really dislike the idea that all actors are
> automatically containers and would have preferred basicActor which was
> not an carrierActor drived from it which was.
>
> But, that's just becuase I strongly dislike TADS ability to put anything
> into anything else by just setting its location property. In my opinion
> is should only be allowed to put things into objects of classes derived
> from 'container' </digression>.
Coming from a MUSH background, this has always seemed perfectly natural to
me, as anything in a MUSH can act as a container if you @teleport things
into it. It's then just a question of whether or not others can see it.
/====================================================================\
|| Quintin Stone O- > "You speak of necessary evil? One ||
|| Weapons Master & Coder < of those necessities is that if ||
|| Rebel Programmers Society > innocents must suffer, the guilty must ||
|| st...@rps.net < suffer more." -- Mackenzie Calhoun ||
|| http://www.rps.net/ > "Once Burned" by Peter David ||
\====================================================================/
Shadow Wolf
news:68bd0e8.02122...@posting.google.com:
It's _extremely_ useful for objects with sub-parts -- for instance, if you
have a "sword" with "hilt" "crossguard" "pommel" and "blade". How else are
you going to describe the relationship, especially since the parts need to
move every time the sword does. Container simply means the player can
change what's inside something (with put in/remove from, or possibly ask
for/give to in the case of actors).
Note that Inform does the same thing -- any object can "contain" (in the
logical sense) any other object.
Kevin Forchione
> I think what I am trying to say is that it would be nice to be able to
> see at a glance, in one lcoation, "if I declare an objct of class X,
> it will have properties Q,R & S".
Ah, that helps. Currently the proteus metacommand <<@show def obj>> will
only display the properties directly defined by the object definition.
<<@show def Actor>>, for instance, only displays the properties directly
defined by the class Actor, and not those inherited by any other class,
although using the hyperlinks you can drill down into the other classes.
Meta-command <<@show state obj>> on the other hand displays all of the state
attributes of the object, and displays which classes define those
properties. The same is true of <<@show act obj>>, which displays the action
properties of the object, and the classes that define those properties.
So I could see 2 possible further @show commands.
One that displays the defined properties for the object, directly and
inherited. In the case of properties such as maxBulk this would only display
the property in the class that defines it for the object (In other words, in
the case of the me object, Actor would display the property, rather than
Container.)
The second would be a full display of the object definition, working through
the inheritance hierarchy, and displaying all of the properties.
However, as you might imagine, such a display can run to several printed
pages. I believe Actor class ran to six pages when I copied an example of
the second display (all classes, all properties) when I made a Word document
out of it - hence the reason proteus adopted the directly-defined display
for the default @show.
> And, to <digress>, I really dislike the idea that all actors are
> automatically containers and would have preferred basicActor which was
> not an carrierActor drived from it which was.
>
> But, that's just becuase I strongly dislike TADS ability to put
> anything into anything else by just setting its location property. In
> my opinion is should only be allowed to put things into objects of
> classes derived from 'container' </digression>.
In a single-contents containment model an object generally determines what
interpretation is placed on the relationship between itself and its
contents. For Thing class objects the relationship is usually one of
components to the parent object. For Surface class the contents are said to
be "on" the object. For Container class they are "in" the object. Special
classes allow for "under" and "behind" interpretations. In this model the
content object itself can adopt certain "postures", such as "sitting" or
"lying".
The plus-point is simplicity in maintaining the integrity of the containment
model. But the drawback is that an object has one and only one relationship
to the object of its contents list. So a desk must be composed of separate
objects if it is to have both surface and container behaviors (a top and a
drawer, for instance).
This principle can, of course, be violated in the single-contents model, but
only by requiring that the content object itself define the relationship
(Multiform.t attempts to do this). The difficulty with this kind of approach
is that not only does each element of contents need to be interrogated with
regard to its relationship to the parent, but the particular containment
state of the parent must be interrogated as well. So we would need to
determine if the parent is open/closed, opaque/transparent, as well as
filter each contents object based on the relationship required by the
specific action involved. In this approach, adding a new relationship
affects every object in the game, as opposed to the usual approach, which
simply necessitates adding a new class.
--Kevin
Plugh!
> > I think what I am trying to say is that it would be nice to be able to
> > see at a glance, in one lcoation, "if I declare an objct of class X,
> > it will have properties Q,R & S".
>
> Ah, that helps. Currently the proteus metacommand <<@show def obj>> will
> only display the properties directly defined by the object definition.
> <<@show def Actor>>, for instance, only displays the properties directly
> defined by the class Actor, and not those inherited by any other class,
> although using the hyperlinks you can drill down into the other classes.
>
> Meta-command <<@show state obj>> on the other hand displays all of the state
> attributes of the object, and displays which classes define those
> properties. The same is true of <<@show act obj>>, which displays the action
> properties of the object, and the classes that define those properties.
>
> So I could see 2 possible further @show commands.
go for it!
Thanks for the reply so far, I will look into it as soon as I have
time. Unfortunately, I expect to be out of (raif) circulation fcr
quite a while, but appreciate the help given so far.
Thanks, Kevin.