This looks easy enough to implement, so I’ve made the code changes. Once I’ve tested and documented them, I’ll push them up to GitHub.
I’m assuming that this is not really attended for use in a conversational context (the primary purpose of the <.reveal tag> mechansm), so there’s no need for <.unreveal> to uninform any NPCs that happen to be in scope.
IF are since the beginning, games of low cunning, including duping hostile NPC. and <.reveal false_alarm> is a solid, if not classic, solution for the ancient and venerable “remove the guard” puzzle, but, if one plans that the guard can discover that the alarm is bogus, and <.unreveal false_alarm> can led to interesting twists in the narration…
You’re right, it’s not meant to “unreveal” information per se, but I find that I still use it in connection with NPCs and whether or not something should be said. Just as one instance, you might enter a shop and reveal some tag if a particular conversation is initiated with the proprietor, but use the unreveal tag on the way out the door if a certain critical interchange did not take place subsequent to the reveal.
But after I did that, I found that the tag came in handy for other on/off properties, even if they weren’t strictly conversation-related…
Of course, it’s entirely up to game authors how they want to handle things, adv3Lite provides several ways of skinning cats, and an unreveal tag may be the neatest solution in this case, but just in case it’s helpful, I can think of three other ways I might handle it.
The first would be simply to hold back revealing the tag until second conversation had taken place.
The second (if the first wouldn’t work) would be to reveal a second tag when the critical conversation takes place and subsequently test for both tags having been revealed.
The third, which is a variation on the other two, is to only reveal the second tag if the first one has been revealed (if that’s what needed); along the lines of:
In principle yes, although in adv3Lite <.reveal> updates player character knowledge rather that NPC knowledge, which is updated through <.inform> tags. Whether it’s worth implementing a <.uninform> tag just for this situation I rather doubt, since game code could just set a custom flag on the guard object and manipulate that. If a wider implementation of uninforming NPCs were required, game code could define its own <.uninform> tag, since the library provides hooks for user-defined flags.
The Docgen program is still not functional, I still have not been able to get it to work on Linux using Wine. I just tried it in Windows XP and 10 (in Virtualbox), but in both cases I still see the same error, e.g. after:
C:\Docgen\Docgen.exe -i heidi.t -o C:\Docgen\out
or
C:\Docgen\Docgen.exe -i heidi.t -o C:\Docgen\out
I still see the error message:
no inputs specified
Fortunately Docgen is not necessary for game development, so I’ll wait for a possible new version.
everything works perfectly now. If I delete the directive from the source file:
#include <adv3.h>
Docgen no longer throws any errors and generates the documentation correctly, so I do not need Windows OS. I’m glad that everything works as it should, DocGen at least forces me to write correct documentation (like Heidi has for example), I’m happy to be able to make full use of such a great system as TADS3.
Now nothing prevents me from translating the Adv3Lite library, I will do my best.
No worries. I’m glad to hear you’ve got it working now. It may be that to solve the adv3.h file problem (without removing it from your source files) you’d need to list the path, not only to the adv3.h file itself, but to all the files it in turn includes (which would be located in the headers directory of your TADS 3 program installation) - but you seem to have found a solution that works for you.
Hi Eric – this is wonderful news. As an avid adv3Lite user, I’m grateful for the work you’ve put into it. Without your library, I would have given up a long, long time ago.
When 1.6 is released, will a new topic be started on the forum, or will an announcement be appended here? I’m very excited, and want to make sure I don’t miss it!
I’ll almost certainly start a new topic to make sure people don’t miss it. I have in mind a release in early to mid-December. I may do a bit more testing and tweaking, but at this point I’m mainly waiting to see if anyone comes up with any more bug reports (or feature requests). In the meantime, if you’re curious, you can see the draft change log on GitHub.
I’m still aiming for an official 1.6 release in early to mid-December (i.e., in the next couple of weeks), so this is a last call for any bug reports. At this point I’d rather not add any new features or make any but very minor changes to existing features.
If necessary, I may do a 1.61 maintenance release sometime next year, to fix any bugs that come to light in the meantime, along with any new feature requests.
The current change log for version 1.6 remains available to view on GitHub.
Not sure if anyone’s caught it yet, but the documentation for StringBuffer has one error I’ve caught. It seems the arguments for StringBuffer.insert(str, idx) are actually StringBuffer.insert(idx, str).
There was an error that was driving me crazy and it only went away when I swapped the arguments.
EDIT: Wait, I think that’s part of TADS 3 itself…how do we contact the primary TADS 3 author…?
That’s right. The author of TADS 3 is Mike Roberts, who vanished from the scene quite a few years ago. The officials TADS site http://www.tads.org/ directs bug reports to a TADS bug database that is no longer online. The site also gives a contact email address, but I suspect that won’t be active either.
I know you said you probably wouldn’t add new features now, but I just thought I’d check. I frequently like to query whether a TravelConnector has been traversed, similar to querying whether a Thing has been .described or .moved. What about adding a little clause to the base noteTraversal (or something underlying) that marks it as .traversed?
I just recently remembered it… no worries if you’re beyond wanting to add anything!
This looks fairly simple to implement, but does it matter what does the traversing? I’ve just experimented with the following implementation that seems to do the trick for the most general case:
This should allow game authors to use hasBeenTraversedBy(traveler) to determine whether traveler (an actor, vehicle or PushTraveler) has traversed the TravelConnector in question. It’ll be easy enough for me to incorporate this into the library for the upcoming 1.6 release if you reckon it should meet the case. Note that when an actor pushes something via a TravelConnector or rides a vehicle via a TravelConnector, this code adds both the actor and the PushTraveler/vehicle to the traversedBy list.