Minor Adv3Lite bug

johnnywz00 · January 13, 2024, 1:13am

I didn’t know Lite defined gRoom but I’ve been using “gor” for the same thing in adv3 almost since the beginning

Piergiorgio_d_errico · January 13, 2024, 8:56am

I reitereate, you should share your TADS macro library… Imp’s keyboards will be eternally grateful !

Best regards from Italy,
dott. Piergiorgio.

johnnywz00 · January 13, 2024, 1:23pm

Ha! It’s about 500 lines long, very adv3 specific, and most people would probably be more confused than helped!

johnnywz00 · January 24, 2024, 1:49am

Hi, @Eric_Eve … I’ve spotted a typo. In the message switching to TERSE mode, “explicit” is spelled “explict”.

johnnywz00 · January 24, 2024, 1:53am

@Eric_Eve
I have a separate issue, which is in fact a question. I notice that objects in the player’s inventory are not available to be DROPped if they are not directly held (say, they’re in a BagOfHolding), and no implicit take seems to be attempted. Is this the intended behavior? If so, is there a rationale, and/or do most people prefer this?
I confess that I am finding this characteristic quite bothersome as I play through Only Possible Prom Dress…

Piergiorgio_d_errico · January 24, 2024, 1:03pm

Concur with John’s question.

Best regards from Italy,
dott. Piergiorgio.

Eric_Eve · January 30, 2024, 9:53pm

Well, the rationale is that it doesn’t obviously make sense to drop something you’re not holding. The normal way to trigger an implicit take would be to add an objHeld preCondition to the handling for dobjFor(Drop0, but that would produce perverse results with DROP ALL.

That said, it would be interesting to get a wider set of views on this. It may be possible, for example, to modify the behaviour of DROP so that it performed an implicit take in the case that the object being dropped was in a container held by the actor, but this would need careful thought, both to avoid messy ad hoc code and, perhaps more importantly, to avoid behaviour that might appear messily unpredictable to the player. The rule “if you’re not directly holding it, you can’t drop it” is at least clear and predictable.

Piergiorgio_d_errico · January 30, 2024, 10:00pm

hmmm… if the modifying of the behaviour is paired with allVerbsAllowAll = nil, the perverse results with DROP ALL should be averted, or I’m missing something ?

Best regards from Italy,
dott. Piergiorgio.

Eric_Eve · January 31, 2024, 9:31am

But wouldn’t want players want and expect DROP ALL to work (by emptying their inventory) or am I missing something?

Anyway, I’ll take a closer look at this when I get a chance to do so. Off the top of my head I think there could be tricky design issues as well as tricky implementation issues here, but it could be that when I look into it more thoroughly I’ll be able to come up with something workable.

An initial point on which I’d welcome opinions is whether DROP should only trigger an implicit take when the direct object is in a BagOfHolding directly held by the actor (the logic of this would be that the BagOfHolding acts as a kind of extension to the actor’s direct inventory).

johnnywz00 · January 31, 2024, 12:07pm

From my own perspective, yes! the BagOfHolding is indeed an extension of direct inventory… from the angle that its reason for implementation seems to be to remove inventory limits from the player (by serving as a “plausible” means for carrying just about anything), rather than actually trying to model heldness vs. unheldness.

I didn’t mean to stir the pot, though… I don’t know how much library code depends on the current arrangement. I’m just used, in the games I happen to have played (and in creating, I’ve only worked with adv3 thus far), to being able to DROP anything that’s in my inventory, so it came as a little surprise to me. I’m not saying it’s objectively wrong. I too, would be interested on more players’ opinions. Maybe a forum poll would be interesting? It wouldn’t have to just be TADS users that could chime in on the basic concept…

Eric_Eve · January 31, 2024, 12:47pm

My current (but as yet undeveloped) thinking is to add a canDropContents property to Thing that would be nil by default but overridden to true (or maybe canDropContents = isOpen) on BagOfHolding, and then allow a DROP command to (also) proceed at the verify stage if the location of the direct object is the actor and has canDropContents evaluating to true. This would then make it reasonably easy for game authors to customize the behaviour. The trickier thing is then how and where to implement any implicit TAKE (or perhaps better, TAKE FROM); this might need to happen at the action stage, but I’ll need to experiment. It would also enforce the condition that the BagOfHolding would need to be directly held by the actor for the DROP command to work on its contents, which seems reasonable if the BagOfHolding is being regarded as an extension of the player’s inventory.

johnnywz00 · February 1, 2024, 1:15am

When I phrased the question, originally, I used DROP as the only example… but the broader consideration was the fact that BagOfHolding objects were not treated as held/usable. For instance (at least in Only Possible Prom Dress) if I had matches in my BagOH, I could not LIGHT CIGAR without first TAKE MATCHES. I had a book which I could not READ, without first TAKE BOOK.
So I think what I was approaching was not so much DROP in particular, but having free access to inventory within a BagOH (sort of like adv3’s meetsObjHeld)…

So that potentially, the canDropContents property could just be a treatAsHeld property instead, for authors to determine? Or simply to make sure there is always an implicit take for basically any held-required verb when it’s used on an object within a PC-held BagOH…

Eric_Eve · February 1, 2024, 10:41am

Good point. I’ll look into it and see what I can come up with. But I would have thought that DROP was a special cases here, since I would expect the other actions to enforce an objHeld PreCondition which would trigger an implicit TAKE, so if this is not happening with a BagOfHolding it may be a different problem.

Eric_Eve · February 1, 2024, 11:00am

Thanks for catching this. This has now been corrected (along with several similar typos in comments) and the change pushed to GitHub.

Eric_Eve · February 1, 2024, 11:42am

Further to this I’ve just created a small test game with a BagOfHolding (called bag) and a red ball. If I take the bag and then the ball and put the ball in the bag and issue the command THROW BALL, this triggers an implicit take and the ball is thrown as expected.

EDIT: I also tried adding a book with a readDesc. The adv3Lite library does not enforce an objHeld PreCondition on the READ command by default, so I didn’t get the problem you describe. I still didn’t get it wihen I added an objHeld PreCondition for the book, since then an implicit take was perfomed when the book was in the bag and the READ command went ahead.

So I’m wondering if something else was going on in the implementation of the game you encountered and it is indeed just DROP that needs addressing, but I’ll investigate further.

johnnywz00 · February 1, 2024, 1:45pm

I thought this could be the case, which is why I qualified it by citing which game it was… I would be glad to think you’ve got less work ahead of you! Did you also check the LIGHT verb? Because there were many verbs which would implicitly take from the bag, but again, some did not…

Piergiorgio_d_errico · February 1, 2024, 2:57pm

john is right: a torch[1] is something whose isn’t always in use, but carefully kept in the inventory, so is natural that ends in the BoH (well, aside the cases (e.g. a setting in which the dynamo/alternator are temperamental) where a torch is best kept attached to the belt, Jedi-style…)

The case above open an interesting detail: personally, I appreciate affinityFor whose theoretically allows interesting coding like:

rucksack.affinityFor (torch) = 0 
belt.affinityFor (torch) = 100

(albeit I think that a code where the affinity to BoH is in the definition of the obj is more logical in the source layout, I dunno if BoH.affinity for (self) = x can actually work…)

[1] known on the new side of the Atlantic pond as “flashlight”, albeit usually shine a steady light…

Best regards from Italy,
dott. Piergiorgio.

Eric_Eve · February 2, 2024, 12:04pm

I’ve now checked the LIGHT and LIGHT WITH verbs and again encountered no problems; implicit takes went ahead as expected.

I’ve also now modified the handling of DROP along the lines indicated above (via a new objCarried PreCondition). The changes to implement this have just been pushed to GitHub.

Eric_Eve · February 2, 2024, 2:08pm

Harlock:

In actor.t, travelvia:
 /* 
         *   If the player character can see this actor, display a message
         *   indicating this player's departure.
         */
        
        if(wasSeenLeaving)
            sayDeparting(conn);
Will in turn later call getDepartingDirection. However, it calls it on the destination after travel, so the travel vague message will always be displayed rather than the direction specific version.

I think this is just a matter of displaying the departure message immediately before the actor departs instead of immediately after. I’ve now made this changed and pushed it up to Github,

Eric_Eve · February 3, 2024, 5:57pm

When I investigated I found several other issues with Attachables as well. Hopefully I’ve now managed to track them all down and fix them. The changes have now been uploaded to GitHub. Note that with these changes, if one object starts out attached to another, this will now need to be defined on its intiallyAttachedTo property (instead of the attachedTo property as before).