In actor.t, in dobjFor(SayTo), defaultSayReponse is misspelled.
I’ll reuse this thread if I come across additional bugs to limit the number of bug threads I may create.
4 Likes
Thanks for catching that and pointing it out. I’ve now corrected it in my version and pushed the change to GitHub.
By all means please do!
3 Likes
I think there is a typo in Learning TADS 3 with adv3Lite
Page 226 refers to endConvTravel. In the library I found endConvLeave but not endConvTravel.
2 Likes
I found an issue but don’t have an easy solve for it.
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.
A second oddity (not an issue) is that ActorHelloTopic calls inherited() from noteInvocation, but there isn’t anything up the class heirarchy that corresponds to noteInvocation. I guess in TADS its harmless to call inherited().
3 Likes
Aha! So I did actually catch this a few months ago as well, but I just figured it was some big-brain thing that I wasn’t following at the time! 
1 Like
I’ll take a look at this in due course.
It is; and it’s better to call it when it’s not needed than to omit it when it is, so I may have been over cautious here. Again, I’ll look at this.
Thanks for both reports!
4 Likes
The nominal owner distinguisher (ownerDistinguisher) has incorrect casing on appliesto (should be appliesTo) so the override will not be called.
ownerDistinguisher: Distinguisher
sortOrder = 400
appliesto(obj) { return obj.nominalOwner() != nil; }
equal(a, b) { return a.nominalOwner() == b.nominalOwner(); }
;
3 Likes
Hold on a sec, Harlock, are you going through the entire library—line-by-line—as part of your journey to learn Adv3Lite? 
Because you are finding a lot of buried stuff…!
Also wondering if any of these fixes will accidentally cause bugs for my custom Adv3Lite branch… For example, once this recent minor bug gets patched, what behaviors will this change? I’m not sure what this code does, functionally… I do know that my branch has a few awkward workarounds in place, which address some behaviors that I didn’t prefer, but there might be a chance that these behaviors were not intended in the design of Adv3Lite.
I also have a few neurotic and verbose habits when coding with this library to make various declarations air-tight, and I’m wondering if maybe I can loosen up on some of them.
Also, more importantly, zero shade to Eric Eve or MJR whatsoever. Creating Adv3 and Adv3Lite are both tasks of grand scale and complexity.
I’m only bringing any of this up because I have been working with a professional tester and many forum volunteers while hunting bugs in my custom branch, and we have been digging deep into many behaviors that I have been making adjustments and patches for, so if I download the latest version of Adv3Lite, there might be many behavioral changes that I might get blindsided by, lol.
3 Likes
Technically isn’t needed an eyeball line-by-line research, esp. having around 'nix tools, namely grep (1) whose can read its pattern from a file, and search both case sensitive and insensitive.
With a file containing all methods, calls, classes, vars &c. names in their correct casing, running grep twice, the second time with -i (ignore casing) switch, all tadsPeculiarCamelcase incongruences & typos will quickly surface.
Best regards from Italy,
dott. Piergiorgio.
1 Like
You’re right Joey, these could cause downstream issues. I’m not recommending them for fixes, just pointing them out as possible areas of checking as I find them in my research.
On that note, I was wondering if there is a game that regression tests the full library.
2 Likes
This looks like a clear error to me, so I’ve now corrected it in my copy and pushed the change to GitHub,
3 Likes
cannotThrowToMsg = BMsg(cannot throw to, '{The subj dobj} {can\'t} catch anything. ')
should be subj iobj e.g.
cannotThrowToMsg = BMsg(cannot throw to, '{The subj iobj} {can\'t} catch anything. ')
3 Likes
Found an issue with Attachables. Given the following:
+ rope: Attachable 'rope'
maxAttachedTo = 2
;
+ pointA : SimpleAttachable 'point A'
isFixed = true
allowableAttachments = [rope]
;
+ pointB : SimpleAttachable 'point B'
isFixed = true
allowableAttachments = [rope]
;
+ pointC : SimpleAttachable 'point c'
isFixed = true
allowableAttachments = [rope]
;
The order that items are attached determines if detach works or reports but doesn’t work:
>attach rope to point a
You attaches the rope to the point A.
>attach rope to point b
You attaches the rope to the point B.
>detach rope from point b
You detaches the rope from the point B.
>attach rope to point c
You can’t attach the rope to anything else while it’s attached to the point A and the point B.
The reason is that in Attachables attachedTo is defined as follows
attachedTo = (attachedToList.length == 0 ? nil : attachedToList[1])
And SimpleAttachable.detachFrom is as follows
detachFrom(obj)
{
/* If we're not attached to obj, then there's nothing to do */
if(obj != attachedTo || obj == nil)
return;
A fix could be adding a detachFrom to Attachable that iterates through the list of attacheditems and responds accordingly.
2 Likes
Thanks for catching these. I’ll look into them.
2 Likes
Thank YOU for the excellent library. It is truly a work of art.
3 Likes
another typo, this time in extensions/postures.t, line 214:
//*
* Modification for SitOn handling [DEFINED IN POSTURES EXTENSION]
* If the actor is already on the dobj, we just try to change the actor's posture
* to sitting. Otherwise we first move the actor to the dobj and then change the
* actor's posture to sitting.
*/
dobjFor(SitOn)
{
There’s one excess / leading to the comment block NOT seen as comment, and the typo render unusable the entire extension.
Solution: remove the excess / that is, from //* to the proper block comment opening, /*
hope to have explained well the typo whose led to a minor bug (for whom don’t use postures.t, otherwise, I fear that is a major one…) and I give my
Best regards from Italy,
dott. Piergiorgio.
2 Likes
Thanks for catching this. I’ve now corrected it and pushed the change up to GitHub.
3 Likes
Quite right. I’ve now corrected this and pushed the change to GitHub.
3 Likes
not a code bug, nor a documentation bug, but perhaps an oversight in documentation:
A pair of useful (for keyboards…) macros are easily to be missed for people whose don’t use the source (cit.) or are lost, periplus or not, in the maze of twisty little links (semi-cit.) of the reference manual, that is, the people whose can gain the most from the concisiveness of the two macros:
#define gTurns (libGlobal.totalTurns)
#define gRoom (gPlayerChar.getOutermostRoom)
the usefulness for easy and muuuch more concise coding of these two macros are so evident, that I suggest that pointing and/or explaining them at least in Learning a3Lite manual.
Best regards from Italy,
dott. Piergiorgio.
2 Likes
Has gRoom been here the whole time…?
2 Likes