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:
"... <<if gRevealed('tag-1')>><.reveal tag-2><<end>>..."
The first or second might come about in any case if revealing tag-1 is necessary for the conversation that reveals tag-2 to take place.
That said, I’ve now pushed the code changes for <.unreveal> and gUnreveal() up to GitHub.
3 Likes
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.
2 Likes
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.
Have a nice weekend
Ludek Stastny
That could be because you’re not specifying the command line parameters correctly. As I said above:
So you’d need something like
c:\Docgen\Docgen.exe heidi.t -i C:Docgen\intro.html -v 1 -o C:\Docgen\out
Assuming you had the supplied intro.html file in your Docgen directory.
Good morning, Eric,
I’m so sorry about the wrong parameters, I misunderstood the syntax. I tried generating the documentation again for Heidi:
wine DocGen.exe Heidi.t -i /home/wanbli/Docgen/intro.html -v 1 -o /home/wanbli/Docgen/output
also for my Czech text game Krouzici Orel 2 with multiple files:
wine DocGen.exe /home/wanbli/Docgen/krorel_2_game/*.t -i /home/wanbli/Docgen/intro.html -v 1 -o /home/wanbli/Docgen/output
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.
Ludek
1 Like
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.
1 Like
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. 
– Mike
2 Likes
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!
1 Like
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.
4 Likes
Absolutely stellar!! Thank you so much!
1 Like
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.
4 Likes
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…?
2 Likes
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.
1 Like
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!
1 Like
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:
modify TravelConnector
noteTraversal(actor)
{
inherited(actor);
local travelers = actor.location.isVehicle ? [actor, actor.location] : [actor];
traversedBy = traversedBy.appendUnique(travelers);
}
traversedBy = []
hasBeenTraversedBy(traveler)
{
return traversedBy.indexOf(traveler) != nil;
}
;
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.
1 Like
Thanks! Yeah, in my own game I only needed to track whether the PC had traversed, but there’s no reason not to cover it more generally. Thanks Eric!
1 Like
If I’d add anything, I’d say keep the full functionality but add a .traversed property for the PC to query, analogous to .seen…
Now done, by adding:
traversed = (hasBeenTraversedBy(gPlayerChar))
These changes have been added to the main library and pushed to GitHub, and so will be included in the imminent v 1.6 release.
2 Likes
Great! I’m still finishing my adv3 game, but I’ve been slowly creeping through the Lite docs, so I’ll hopefully give Lite a ride sometime in the future…
1 Like