Adv3Lite Version 1.6.2 Now Released

Authoring TADS
1

The latest version of adv3Lite (v. 1.6.2) is now available from https://github.com/EricEve/adv3lite/releases/download/v.1.6.2/adv3Lite16-2.zip.

The change log can be viewed at Change Log · EricEve/adv3lite Wiki (github.com).

17 Likes
2

I’ll test it soon against the major, then the derived WIP (the latter having a deadline easy to figure, so In case of troubles, reverting to 1.6.1 is a matter of editing the relevant .t3m)

Thanks for your efforts and
Best regards from Italy,
dott. Piergiorgio.

3

assumption disproved: (huge spoiler ahead):

Which do you mean, the daemonic horns, the diadem, the daemonic wings, the elfin girl’s bosom, the canines, the aqua girl’s face, the horn covers, the daemonic girl’s bosom, the polished talons, the red streamers, the aqua girl’s eyes, the red dress, the angelic girl’s bosom, the daemonic girl’s eyes, the angelic girl’s face, Angelic girl’s eyes, the aqua girl’s ears, the aqua girl’s hands, the copper plaque, the angelic girl’s hair, the daemonic girl’s hands, the angelic girl’s hands, the aqua girl’s hair, the daemonic girl’s face, or the copper cord?

how I can raise the default ?

sorry for having disappointed you, and
Best regards from Italy,
dott. Piergiorgio.

4

You can modify disambigPreParser to extend the list in its ordinals property, e.g.:

modify disambigPreParser
   ordinals = inherited + ['thirteenth', 'fourteenth', 'fifteenth', 'sixteenth',
        'seventeenth', 'eighteenth', 'nineteenth', 'twentieth', 'twenty-first',
        'twenty-second', 'twenty-third', 'twenty-fourth']
;

That said, experimentation suggests that the underlying Mercury Parser (written by Mike Roberts) is unable to cope properly with more than 12 items (and that this would have been the case before the current update, when the player could reply FIRST or TENTH or whatever). So this may not be so readily fixable.

2 Likes
5

You replied when I was just editing i162.t3m (the test .t3m) :wink: Thanks for the quick and just-in-time answer !

EDIT: indeed work up until twenty… let’s think later on the issue; perhaps is best deactivating this feature, at least for the derived WIP…

Thanks again, and
Best regards from Italy,
dott. Piergiorgio.

6

Yes, I was just about to say it works up to the twentieth.

I think you’d still get the same problem if the player typed TWENTY FIRST in full.

One partial workaround, which I’m implementing in the library, is to change line 3809 of english.t to read:

if(libGlobal.enumerateDisambigOptions && names.length < 21)

This will have the effect of automatically disabling the enumeration where there are more than 20 items to choose from.

3 Likes
7

Or, more simpler, put out of disamb’s scope five elements, bringing the major disamb into the limit of 20, at least for the derived WIP…

Can make sense w/o getting another barrage of questionable criticism, because all these disambgs can be seen as three depths of detail (depth, not breadth) and the absence of five (actually, six) disamb entries will have a logical sense, and this simple solution can give to me more than two year for a solid solution of the issue for the major WIP.

so, let’s not wrap much the head around this problem, after all, is a limit (crank)case…

Best regards from Italy,
dott. Piergiorgio.

8

Oo, me likey. Me especially likey that numbered disambiguation choices, a la the appropriately named Inform 7 extension, is now a thing in TADS.

2 Likes
9

I am now contemplating (with misgivings) the possibility of writing a game for this year’s comp. If I do, I’ll definitely use 1.6.2 and give it a thrashing.

I’d really like this game to be a lot smaller than “The Only Possible Prom Dress,” but my list of puzzle-type actions is now around 50 items long. The map will be smaller, though, I promise!

2 Likes
10

Glad to see you back!

1 Like
11

A minor, but potentially player-confusing, bug:

if the player starts, for example, on a chair, the game’s status line at the very start don’t report the (on the chair), but after the first (non stand/get out) move, the status line correctly report the fact.

(the postures library isn’t used)

The relevant (and NOT spoilerish) code is:

showIntro ()
   {
     cls();
     gActor.actionMoveInto(sofa);
	"You started adventuring, blah, blah...";

Best regards from Italy,
dott. Piergiorgio.

12

The reason you get this is that the initial status line is shown before showIntro() is called; my immediate reaction is to ask whether there’re any good reason for not simply locating the player character in the sofa from the start:

me: Player 'you' @sofa // or me: Thing 'you' @ sofa
  ...
;

Then you won’t get this problem.

In case you were wondering, there is a reason for calling showStatusLine() before showIntro(); the comment in misc.t reads:

         * 
         *   Show the statusline before we display our introductory.  This
         *   will help minimize redrawing - if we waited until after
         *   displaying some text, we might have to redraw some of the
         *   screen to rearrange things for the new screen area taken up by
         *   the status line, which could be visible to the user.  By
         *   setting up the status line first, we'll probably have less to
         *   redraw because we won't have anything on the screen yet when
         *   figuring the layout.  
         */

So, on balance, I’m afraid I don’t regard this as a library bug.

2 Likes
13

concur and agree: perhaps the issue stems from what perhaps is a remnant of the original adv3 implementation:

etuye: Player

location = living

(yes, I have tried location = sofa, with the same results…)

That is, the PC’s startroom is defined in the player object, not in the gameMain, and is now clear that the issue lies here.

For the record, the gameMain, is really short:

gameMain: GameMainDef
   allVerbsAllowAll = nil // there's too many bodyparts, decos &.c
   initialPlayerChar = etuye

   showIntro () [...]

of course, because of the complexity of PC and the two major NPC, there’s separate files for them (whose is why I’m entuthiast about ProxyActor…)

UPDATE: indeed this works as expected:

etuye: Player 'etuye' @sofa

//location = living

I can’t figure out why the template assignment works but the nominally identical location = [loc] assignment don’t work, but what matters is that the 0 turn status line is OK and can’t confuse players…

Thanks for the solution, and
Best regards from Italy,
dott. Piergiorgio.

1 Like
14

But you would need location = sofa surely. That seems to work for me.

2 Likes
15

Sorry for replying late, but indeed also

etuye: Player //'etuye' @sofa

location = sofa

works as expected. This put the issue squarely in the “lost in translation (from adv3 to a3Lite)” category. My apologies.

Sorry for having wasted your time, and
Best regards from Italy,
dott. Piergiorgio.