Ci sono vari problemi con il verbo vai_a per implementare sintassi alternative per le direzioni; le sintassi "VAI A <DIREZIONE>" e "A <DIREZIONE>" non funzionano.

Vedi il test vari/direzioni.a3log:

> ; **ERR!** Per qualche ragione la sintassi "VAI A" non funziona:
> vai a nord
Non ho capito la frase.

> vai a sud
Non ho capito la frase.

e

> ; **ERR!** Per qualche ragione la sintassi "A" non funziona:
> a nord
Non ho capito la frase.

> a sud
Non ho capito la frase.

Premesso che "VAI" è sempre ignorato dal parser in quanto sinonimo della NOISE_WORD "GO", rimane da capire perché la sintassi "A <DIREZIONE>" non funziona...

Rimuovi dai verbi le clausole IF di verifica che un prendi-implicito sia andato a buon termine, poiché supeflue.

• Individua tutti i verbi che contengono tali clausole.
• Rimuovi il blocco IF e lascia solo il codice.
• Cerca di trovare altri verbi che utilizzino clausole superfluo di questo tipo, anche se non relative al prendi-implicito.

Spiegazione

Nei vari verbi che impiegano un "prendi implicito" è presente una clausola IF per verificare che esso sia andato in porto. Esempio (tratto da lib_classi.i, verbo dai_a su luquido):

    DOES ONLY
      -- >>> prendi implicito: >>>
      IF THIS NOT IN hero
        THEN
          IF THIS:recipiente = recipiente_fittizio
          OR THIS:recipiente IS NOT prendibile
            THEN SAY mia_AT:impossibile_maneggiare_liq1.
            ELSE LOCATE recipiente OF THIS IN hero.
              "(prima prendi" SAY THE THIS:recipiente. SAY THIS:prep_DI. "$1)$n"
          END IF.
      END IF.
      -- <<< prendi implicito <<<

      IF THIS IN hero -- (se il prendi implicito è andato a buon fine)
        THEN
          "Consegni" SAY THE THIS:recipiente. SAY THIS:prep_DI. "$1"
                     SAY png:prep_A. "$2."
          LOCATE recipiente OF THIS IN png.
      END IF.

Questa clausola è inutile dato che se il LOCATE del prendi-implicito dovesse fallire per qualsiasi ragione (e.s. l'oggetto è posseduto da un attore) allora l'esecuzione del verbo si interromperebbe.

Ho eseguito dei test che confermano quanto sopra, quindi è un'operazione sicura.

Questi sono i titoli originali delle sezioni in cui è organizzato The Inform Recipe Book — da tradurre in italiano:

• 1. How to Use The Recipe Book
• 2. Adaptive Prose
  • 2.1. Varying What Is Written
  • 2.2. Varying What Is Read
  • 2.3. Using the Player's Input
• 3. Place
  • 3.1. Room Descriptions
  • 3.2. Map
  • 3.3. Position Within Rooms
  • 3.4. Continuous Spaces and The Outdoors
  • 3.5. Doors, Staircases, and Bridges
  • 3.6. Windows
  • 3.7. Lighting
  • 3.8. Sounds
  • 3.9. Passers-By, Weather and Astronomical Events
• 4. Time and Plot
  • 4.1. The Passage Of Time
  • 4.2. Scripted Scenes
  • 4.3. Event Scheduling
  • 4.4. Scene Changes
  • 4.5. Flashbacks
  • 4.6. Plot Management
• 5. The Viewpoint Character
  • 5.1. The Human Body
  • 5.2. Traits Determined By the Player
  • 5.3. Characterization
  • 5.4. Background
  • 5.5. Memory and Knowledge
  • 5.6. Viewpoint
• 6. Commands
  • 6.1. Designing New Commands
  • 6.2. Writing New Commands
  • 6.3. Modifying Existing Commands
  • 6.4. Looking
  • 6.5. Examining
  • 6.6. Looking Under and Hiding
  • 6.7. Inventory
  • 6.8. Taking, Dropping, Inserting and Putting
  • 6.9. Going, Pushing Things in Directions
  • 6.10. Entering and Exiting, Sitting and Standing
  • 6.11. Waiting, Sleeping
  • 6.12. Other Built-In Actions
  • 6.13. Magic Words
  • 6.14. Remembering, Converting and Combining Actions
  • 6.15. Actions on Multiple Objects
  • 6.16. Alternate Default Messages
  • 6.17. Clarification and Correction
  • 6.18. Alternatives To Standard Parsing
• 7. Other Characters
  • 7.1. Getting Acquainted
  • 7.2. Liveliness
  • 7.3. Reactive Characters
  • 7.4. Barter and Exchange
  • 7.5. Combat and Death
  • 7.6. Getting Started with Conversation
  • 7.7. Saying Simple Things
  • 7.8. Saying Complicated Things
  • 7.9. The Flow of Conversation
  • 7.10. Character Emotion
  • 7.11. Character Knowledge and Reasoning
  • 7.12. Characters Following a Script
  • 7.13. Traveling Characters
  • 7.14. Obedient Characters
  • 7.15. Goal-Seeking Characters
  • 7.16. Social Groups
• 8. Vehicles, Animals and Furniture
  • 8.1. Bicycles, Cars and Boats
  • 8.2. Ships, Trains and Elevators
  • 8.3. Animals
  • 8.4. Furniture
  • 8.5. Kitchen and Bathroom
• 9. Props: Food, Clothing, Money, Toys, Books, Electronics
  • 9.1. Food
  • 9.2. Bags, Bottles, Boxes and Safes
  • 9.3. Clothing
  • 9.4. Money
  • 9.5. Dice and Playing Cards
  • 9.6. Reading Matter
  • 9.7. Painting and Labeling Devices
  • 9.8. Simple Machines
  • 9.9. Televisions and Radios
  • 9.10. Telephones
  • 9.11. Clocks and Scientific Instruments
  • 9.12. Cameras and Recording Devices
• 10. Physics: Substances, Ropes, Energy and Weight
  • 10.1. Gases
  • 10.2. Liquids
  • 10.3. Dispensers and Supplies of Small Objects
  • 10.4. Glass and Other Damage-Prone Substances
  • 10.5. Volume, Height, Weight
  • 10.6. Ropes
  • 10.7. Electricity and Magnetism
  • 10.8. Fire
  • 10.9. Heat
  • 10.10. Magic (Breaking the Laws of Physics)
  • 10.11. Mathematics
• 11. Out Of World Actions and Effects
  • 11.1. Start-Up Features
  • 11.2. Saving and Undoing
  • 11.3. Helping and Hinting
  • 11.4. Scoring
  • 11.5. Settings and Status Checks During Play
  • 11.6. Ending The Story
• 12. Typography, Layout, and Multimedia Effects
  • 12.1. Typography
  • 12.2. The Status Line
  • 12.3. Footnotes
  • 12.4. Timed Input
  • 12.5. Glulx Multimedia Effects
• 13. Testing and Publishing

Quasi sicuramente il ricettario di Alan seguirà lo stesso criterio organizzativo dato che lo Inform Recipe Book è il risultato di anni di contributi da parte di sviluppatori esperti, revisioni ed esperienza pratica. Ma l'organizzazione delle sezioni e gli esempi varieranno nel Ricettario di Alan, anche in virtù delle differenze tra i due sistemi di sviluppo (p.es., la §12.5 riguardante Glulx, che Alan non usa, ecc.).

Il thread di questo issue è destinato ad eventuali discussioni sulla traduzione dei titoli delle sezioni e se nel Ricettario di Alan suddividerli ulteriormente, introdurre altre sezioni, ecc.

Sarebbe inoltre utile stabilire una priorità su quali sezioni ed esempi debbano avere la priorità, dato che sono parecchi e richiederanno molto tempo per essere realizzati in Alan, commentati e documentati.

Nei messaggi riguardanti i recipienti dei liquidi, non mi piace che il recipiente venga menzionato come <recipiente> di <liquido>. In alcuni casi questo va bene (es. "bottiglia del vino", "recipiente del latte"), ma nel caso di recipienti generici suona un po' forzato (e.s. "tanica del latte", "acquasantiera del vino", "pozzanghera del latte", ecc.).

Il punto è che un recipiente potrebbe essere svuotato e usato per contenere altri liquidi, in quel caso un cartone del latte resta pur sempre un cartone del latte anche se usato per stipare della benzina. In questi casi, il nome del recipiente potrebbe essere definitio per esteso (e.s. "il cartone del latte") e si avrebbero risposte come:

> esamina cartone
Il cartone del latte contiene del latte.

e in caso vi fosse della benzina:

> esamina cartone
Il cartone del latte contiene della benzina.

... che ha molto più senso e consente un'implementazione più versatile.

Alcuni messaggi per i contenitori si sovrappongono a quelli dei supporti. Mi chiedo se non valga la pena ridefinire la prep_IN di supporto tramite INTIALIZE di modo che sia uguale a prep_SU, anziché gestire manualmente i messaggi alternativi per i supporti.

In teoria potrebbe funzionare, dato che un supporto è sempre un contenitore i cui verbi dedicati usano la preposizione su anziché 'in', e quindi non dovrebbero mai esservi messaggi che usano "in". Ma devo verificare.

Ad ogni modo, mancano i check in vari verbi che dovrebbero interessare solo in contenitori e non i supporti. Devo capire come correggerli (tramite WHERE, CHECK, etc.) e se sfruttare anche questa soluzione.

C'è un problema con alcuni verbi che non eseguono un CHECK per controllare se il parametro è un supporto:

• riempi
• lancia

riempi

Vedi il test casa/classi_contenitori.a3log dove digitando "ascolta il cielo" in CUCINA si ottiene:

> ; ------------------------------------------------------------------------------
> ; TESTA parametro 1 inadatto (supporto)
> ; ------------------------------------------------------------------------------
> ; **ERR!** Manca un check per controllare che non sia un supporto:
> riempi il tavolo con la mela
Il tavolo is already full of la mela.

Siccome il verbo riempi non è ridefinito sulla classe supporto, la soluzione sarà o:

1. Aggiungere un CHECK al verbo riempi in lib_verbi.i
2. Implementare riempi sulla classe supporto in lib_classi.i, al solo fine di aggiungere un ulteriore CHECK.

Devo ragionare su quale soluzione sia migliore.

NOTA — Bisgona verificare se un problema simile sussiste anche con i verbi affini "versa" e "svuota" (versa_in, etc.).

lancia

Un problema simile si verifica anche con il verbo lancia. Dal medesimo test:

> ; **ERR!** Manca un check per controllare che non sia un supporto:
> lancia la mela nel tavolo
La mela doesn't belong in il tavolo.

I verbi del gruppo guarda_* (sotto, attraverso, ecc.) condividono scampoli di testo che potrebbe essere spostato in un attributo mia_AT

C'è un problema con il verbo ascolta che restituisce una stringa vuota se usata con un oggetto di luogo presente in un luogo esterno adiacente (ma non in quello attuale).

Vedi il test casa/azioni_esplorazione.a3log dove digitando "ascolta il cielo" in CUCINA si ottiene:

> ; **ERR!** Il cielo non è NEARBY dato che è situato in un luogo che avvolge
> ;          il giardino (ma non la casa).
> ascolta il cielo

> ascolta il giardiniere
Non riesci a sentire il giardiniere da questa distanza.

La CUCINA è a NORD del GIARDINO, la prima è una stanza e l'altro un luogo_esterno (contenente il CIELO).

Il problema sembra essere legato al fatto che nel DOES del verbo ascolta vi sono vari IF che coprono un parametro nello stesso luogo del giocatore, in quello adiacente, ma non contempla un luogo lontanto.

Verbo ascolta

In lib_verbi.i:

ADD TO EVERY THING
  VERB ascolta
    [...]
    DOES
      -- @NOTA: Ho invertito 'hero' e 'ogg' se no il verbo non copriva i casi
      --        in cui l'erore è in una locazione annidata, oppure l'ogg è in
      --        un contenitore esterno (es. il cielo o il soffitto)...
   -- IF ogg AT hero
      IF hero AT ogg
        THEN
          IF ogg IsA ACTOR
            THEN SAY THE ogg. "non sta"
              IF ogg IS plurale
                THEN "$$nno"
              END IF.
              "parlando in questo momento."
            ELSE "Non odi niente di particolare."
          END IF.
-- TODO: Se l'oggetto è lontano non produce nessuna risposta, ma forse dovrebbe CHECK!
--       produrre un qualche testo. Il problema qui è che comunque il tentativo
--       svela l'esistenza dell'oggetto, laddove un oggetto inesistente avrebbe
--       prodotto "Non conosco la parola 'xxx'.", questo messaggio (o la sua
--       assenza) è indicatorio del fatto che l'oggetto esiste ma non si trova
--       in un luogo contiguo.
      ELSIF ogg NEAR hero
        THEN "Non riesci a sentire" SAY THE ogg. "da questa distanza."
     -- THEN "You can't hear" SAY THE ogg. "very well from here."
      END IF.

Problem

After an Alan code block starting with an indentation is processed by Highlight, the indentation on the first line is lost.

• Fix all occurrences in current sources using the {wj} workaround.
• Before committing, check that it doesn't interfere with:
  • PDF builds (via Asciidoc-fopub).
  • Highlight.js (i.e. Alan Manual).

For more info on this problem, see: tajmone/hugo-book#15

For an example, see:

• The Hugo Book: 5.4. Init And Main (a106ed8).

The {wj} Workaround

Right now, the only workaround solution is to add a word joiner character (⁠) at the beginning of the first indented line using its predefined attribute for character replacement ({wj}):

[source,alan, subs="+attributes"]
---------------------------------
{wj}  Add To Every object

This works fine, although it's far from being an ideal solution (but, at least, it shouldn't create any problems for other Asciidoctor backends and output formats).

Vanno risolti parecchi bachi e problemi con il vestiario, alcuni dei quali causano un crash dell'avventura. Per maggiori info, vedi:

• AnssiR66/AlanStdLib#52 — Clothing Table: Coveralls
• AnssiR66/AlanStdLib#57 — BUG: Giving Worn Clothes to Actors Crashes Alan
• AnssiR66/AlanStdLib#58 — Tweak Listing of Worn Clothing Items
• AnssiR66/AlanStdLib#60 — Moving Around Worn Items
• AnssiR66/AlanStdLib#61 — Nested Clothing

Devo approcciare i vari problemi in maniera strategica:

• Crea un issue per ciascun problema isolatamente.
• Documenta i problemi e fornisci riferimenti al codice che li riguarda.

Update Wiki page i18n-Problems and mention that these problems have been fixed in upcoming Alan version.

Crea ed organizza la sottocartella ricettario/:

• Aggiungi script per la compilazione ed esecuzione di tutte le avventure dimostrative del ricettario e relativi script di comandi.
  • Modifica lo script per consentire test multipli per ciascuna avventura.
• Organizza la documentazione automatizzata del ricettario tramite una combinazione di:
  • documenti AsciiDoc gestiti manualmente (in docs_src/).
  • documenti AsciiDoc generati tramite Doxter dai sorgenti degli esempi.

Fondi in un unico script i due batch script che eseguono i test in ciascuna sottocartella.

Questo semplificherà la manutenzione dello script e migliorerà il rapporto finale (che ora viene mostrato alla fine di ciascun ciclo di test).

Modifica la libreria per consentire di definire un protagonista femminile, e fai in modo che la messaggistica che menziona il protagonista si adatti al suo genere.

Ci sono dei problemi con alcuni verbi ridefiniti su pavimento e suolo (es. metti_in) che vanno testati, isolati e risolti. Vedi:

• AnssiR66/AlanStdLib#42 — Floor and Ground problems

E i seguenti test:

• casa/classi_oggetti-luogo-esterno.a3log
• casa/classi_oggetti-stanza.a3log

Aggiungi uno script in ciascuna cartella dei test per consentire di eseguire test isolati:

• test/casa/TESTA.bat — parametro: un file .a3sol, che verrà testato su casa.alan.
• test/vari/TESTA.bat — parametro: un file .alan, esegue tutti gli script .a3sol associatigli.

Entrambi gli script devono compilare il sorgente cui si riferiscono.

Questo velocizzerà i testi isolati, senza dover eseguire tutti i test. Ora che il numero di test inizia ad essere considerevole, i tempi per eseguirli tutti iniziano a rallentare il lavoro sui singoli test.

Alcuni messaggi della libreria in lib_messaggi_libreria.i contengono un testo identico:

Devo decidere quale eliminare dei due e poi sostituire tutte le occorrenze.

Nota che gli attributi della prima colonna hanno anche altri attributi simili, con cui formano un gruppo: ogg2_non_ottenibile ("Non puoi avere $+2.").

Quindi conviene:

1. ELimiare la versione non_possiedi_ogg1
2. Oppure eliminare la versione ogg1_non_posseduto rinominando ogg2_non_ottenibile in non_puoi_avere_ogg2.

La seconda scelta è più vicina al messaggio realmente stampato, la prima ha una forma più comunemente usata nella nomenclatura dei messaggi attuale.

Switch to the upcoming official extensions .a3s and .a3t for ALAN3 solution files and transcripts, respectively (see alan-if/alan#2):

• Change file extension of all:
  • Solution files: .a3sol → .a3s
  • Transcripts: .a3log → .a3t
• Update all repo files accordingly:
  • Documentation (.md).
  • Git and EditorConfig settings files.
  • Scripts:
    • Bash .sh
    • Batch .bat
    • SED scripts?
• Update Wiki accordingly (if needed).

Prendi il file .editorconfig dal progetto ALAN Repository Template e mettilo nella root del repository.

Questo offrirà un miglior supporto per i file di Alan (*.alan, *.i, *.a3sol, *.a3log) tramite EditorConfig, assicurando uno stile consistente nei diversi editor e IDE, oltre che migliorare la visualizzazione dei sorgenti Alan su GitHub.

Il verbo prendi_da va rivisto perché contiene clausole impossibili e contradittorie.

• Risolvi le falle di logica nel verbo che contraddicono l'assunto che l'oggetto possa anche essere un attore ma, di fatto, i CHECK lo prevengono.
• Verifica tutti i CHECK che impediscono di eseguire il corpo DOES del verbo a un parametro di classe ACTOR.
• Cerca di aggiustare la situazione di modo che sia possibile usare questo verbo simulando attori in contenitori tramite l'uso di attributi.

La sintassi:

SYNTAX prendi_da = prendi (ogg) da (detentore)
  WHERE ogg IsA THING
  ...
  AND detentore IsA CONTAINER
  ...

... consente di prendere un attore da un contenitore (incluse un altro attore), ma questo non può accadare dato che Alan non consente di mettere attori in contenitori.

Credo che l'idea originale fosse quella di implementare un qualche sistema per emulare attori in contenitori tramite classi specializzate che ridefinissero il verbo prendi_da — in fatti nel corpo del verbo leggiamo:

      DOES
        IF ogg IsA ACTOR
          THEN SAY THE ogg. "would probably object to that."
            -- actors are not prohibited from being taken in the checks; this is to
            -- allow for example a dog to be picked up, or a bird to be taken out of
            -- a cage, etc.

... ma questo è impedito dai seguenti CHECK:

ADD TO EVERY THING
  VERB prendi_da
    WHEN ogg
      CHECK [...]
      ...
      AND ogg IS spostabile
      ...
      AND ogg IS prendibile
      ...
      AND ogg IN detentore      <-- NON ACCADRÀ MAI!

Una possibile soluzione sarebbe quella di implmentare il verbo prendi_da anche sulla classe object e spostare lì i CHECK che non riguardano gli attori.