Jolt Country

Can we get an object or class added to TADS for signs that follow the player around?

pinback wrote:Post a code snippet that isn't working that you think should be working. I have never used TADS, and I guarantee you I will be able to point out what you're doing wrong, and where the manual explains what you're doing wrong, within 15 minutes.

Not everything is in the same place in the manuals and some things are not completely clear. It's funny, when I downloaded the PDF reference manual for the MySQL datanase, and opened it, I almost swallowed my tongue to see it is a whopping 5,000+ pages. I thought that was overkill. Now I realize some things can require a lot more documentation to be comprehensive.

Here's the snippet. That should at least allow me to see that if I TRIP BREAKER KITCHEN (in the room where Kitchen breaker is defined) it should show me a message. I have to call it XThrow because THROW was defined and I'm redefining it and I'm not quite sure how to replace the original definitions.

Sorry, forgot

Ice Cream Jonsey wrote:

pinback wrote:
Post a code snippet that isn't working that you think should be working. I have never used TADS, and I guarantee you I will be able to point out what you're doing wrong, and where the manual explains what you're doing wrong, within 15 minutes.

If Pinner can't, I will put a $100 donation to the Blue Cross / Blue Shield in your name, Paul. That's how confident I am.

You've spent so much time complaining about me and Billy Mays that you lose. Pinback has been here, saw all the other messages, so I have to presume he saw this one, and made no response. So much for his promise of half Domino's Pizza's response time.

Can we look at this as an example that maybe all of us make mistakes and forget things?

RealNC wrote:Yes, you are correct. It's broken. It doesn't work as intended. Nobody noticed this before, weird.

Well, either that, or you didn't really RTFM.

I did read the manuals. I took a piece of code that does work for a different verb and made the modifications for the new verb and it does not work. It's clearly obvious I'm doing something wrong and I do not know what it is.

I will now reiterate what I said before. I have said repeatedly that I know I'm doing something wrong. And I don't know what it is. What I am saying is that this system frustrates me because I have to fight it every step of the way to get anything accomplished. It should not be this difficult and it should not be this restrictive.

Maybe someone can explain why it is necessary to forbid a defined object from implementing a processor for a particular verb if it is the direct or indirect object of that verb. I know the process should work because it does work for PLUG IN TV / PLUG TV IN and PLUG TV INTO SOCKET as well as where CABLE BOX is substituted for TV.

So when I tried to implement TRIP KITCHEN (with or without the word BREAKER) it's clear I'm doing something wrong because instead of executing the stub code that outputs my message (which would allow me to later fill in with the actual code to implement the action) it returns "You can't do that." which means that somewhere along the way it either is not seeing the methods I put in, it is not invoking them, or there is something else involved that I'm not seeing that also needs to be done.

Since it works in one context in theory it should work for the same context if implemented the same way but it doesn't. So either There's something I'm not seeing or I'm not doing the same thing.

I think what I will do is, since I'm banned from posting everywhere but here and the Troll room for the remainder of the time, to set up some scaffold code for fictitious words that are not implemented by copying ones straight out of either the library or some TADS3 games and see if I am doing them correctly. Then if XA KITCHEN , XA TV or XE TV, XE BREAKER works, then I know I was implementing THROW KITCHEN WRONG. But if that also fails then I'll know I don't understand the system.

Either that or maybe I'll just see what verbs TADS has built-in support for that Hugo doesn't and rewrite either the system libraries or Roodylib to add them.

I'm just really not seeing a whole lot of benefit to TADS over Hugo at this point and I thought it might be worth trying but every time I turn around it's like I have to fight the TADS system to accomplish what I want to do.

I'm starting to understand what Jonsey was complaining about.

I don't see a handler for Trip in your code.

Also, your throw action cannot possibly work. It clashes badly with the default throw action. Your new Throw is "XThrow", but in your object, instead of handling XThrow, you handle Throw... So when the command is THROW X, which throw action does that refer to? Throw or XThrow? I don't know. So don't do that.

If you want to modify the default Throw action, you can modify its VerbRule. Leave the vocabulary empty to inherit the default one (which is "('throw' | 'toss') dobjList", defined in adv3/en_us/en_us.t):
Why on earth do you want to modify Throw though?

Also, you should probably switch to adv3Lite. The default library (adv3) is extremely simulationist and very complex.

RealNC wrote:I don't see a handler for Trip in your code.

I did have it in the listing I posted: This is intended to make TRIP KITCHEN BREAKER and THROW KITCHEN BREAKER accomplish the same thing.

RealNC wrote:Also, your throw action cannot possibly work. It clashes badly with the default throw action. Your new Throw is "XThrow", but in your object, instead of handling XThrow, you handle Throw... So when the command is THROW X, which throw action does that refer to? Throw or XThrow? I don't know. So don't do that.

When you use the same verb sequence in another definition it uses the later one. I just couldn't figure out how exactly to override the original THROW verb handler.

RealNC wrote:If you want to modify the default Throw action, you can modify its VerbRule. Leave the vocabulary empty to inherit the default one (which is "('throw' | 'toss') dobjList", defined in adv3/en_us/en_us.t):

Code: Select all

modify VerbRule(Throw)
    /* vocabulary empty on purpose */
    :
    execAction()
    {
        // ...
        // your own code here.
        // ...

       // Call overridden method.
       inherited();
    }
;

Why on earth do you want to modify Throw though?

"THROW BATHROOM BREAKER" or"THROW BATHROOM SWITCH" or "TRIP BATHROOM BREAKER" or "TURN ON BATHROOM BREAKER" or "TRIP AIR CONDITIONER", "TURN OFF AIR CONDITIONER" etc. to indicate the person wants to change the position of the fuse box breaker switch from on to off or vice versa. This would be separate from THROW COFFEE POT AT REFRIGERATOR (which is a different and valid action elsewhere in the game).

I don't know TADS.

Could you just override the switch's "throw" action to redirect to "turn on"?

(Also nobody will ever type "throw bathroom switch", and if they did, and the response was "you can't throw that, it's attached to the wall!" then they would surely understand.)

Do not do anything to Throw. Don't modify it, nor add an XThrow.

Just add a new Trip action, and in your class for switch-like objects, implement a Trip handler, and map Throw to Trip with:
Do not modify default actions without a good reason. And the reason you gave is not good :-P

RealNC wrote:Just add a new Trip action, and in your class for switch-like objects, implement a Trip handler, and map Throw to Trip with:

Code: Select all

dobjFor(Throw) asDobjFor(Trip)

This is essentially what I said. So I take it back, I am a TADS expert.