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.
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.
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!
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.
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().
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!
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!
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(); }
;
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.
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.
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.
This looks like a clear error to me, so I’ve now corrected it in my copy and pushed the change to GitHub,
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. ')