Newsgroup: it.comp.giochi.avventure.testuali
Titolo: [Pietra della Luna] bug misterioso?

Provate la v. 4 di "La Pietra della Luna" (una delle mie avventure 
testuali preferite!): 
http://www.paololucchesi.it/at/luna.htm
.
Provate ad inserire dei comandi separati dal punto; ad esempio:
---
 > esamina il fiume. esamina me.
Non vedi nulla del genere.
---
Succede tutte le volte che inserite piu' comandi nella stessa riga.
Sto cercando di capire perche'... ma??? (ho provato diversi interpreti)
FRA



premesso che si tratta di libreria piuttosto vecchia (infit 2.1),
partirei da due ipotesi: 1) bug in infit 2.1 (originale o modificata),
2) bug "portato" dal codice di qualche strana estensione usata
dall'autore. non mi preoccuperei troppo per infit 2.1, comunque, visto
che la lib attualmente in uso e' infit 2.5 e tra l'altro, neanche il
compilatore e' piu' quello (6.21).
piuttosto, il bugghetto di cui riferivo nel thread "riservato agli
esperti" sembra essersi sgonfiato (il programming error segnalato al
runtime su input tipo z.z.z.z.z.z.z.z.z.z.z.z.). :) si presenta solo e
solo se compilo con gli switch -GD, ovverosia per glulx *e*
aggiungendo i verbi per il debug (testato su glulxe e git-gargoyle).
non so perche', ma switch tipo -G~S fanno sparire l'insetto meglio del
raid. ;)
-- 
max "torredifuoco" bianchi

 Succede tutte le volte che inserite piu' comandi nella stessa riga.
Ho fatto due provette, e il problema è in scenic.h (tanto che si 
presenta anche in Flamel, che sapevo usare la suddetta estensione).
Se provi a scrivere
 > esamina me. i. n. esamina cavallo.
tutto va per il meglio.
Il problema si manifesta quando si esamina un oggetto di scenografia e 
dopo questo c'e' un punto.
Ora (per valori bassi di "ora") cerco di vedere dov'e' il problema e 
come risolverlo.
Mi chiedo anche (ma credo di no') se il bug si presenta solo in 
avventure italiane.
Conoscete un'avventura anglofona che usi scenic.h?
bye
-- 
Paolo Lucchesi
email: plucchesi(at)tin(dot)it
 

 cerco di vedere dov'e' il problema e come risolverlo.
Mmmh, ho dato un'occhiata al codice: secondo me, la tua intuizione e' 
corretta. In sostanza, credo che il problema stia nell'entry point 
ParserError() di scenic*.h. Praticamente l'estensione funziona cosi':
- per cominciare, se una parola non viene riconosciuta... Inform invoca 
l'entry point (opzionale) ParserError();
- a seconda dell'errore rilevato (CANTSEE_PE o SCENERY_PE), vengono 
eseguite le relative routine;
- queste routine non fanno altro che cercare tra le proprieta' "scenic" 
degli oggetti, dopodiche' stampano un messaggio, eseguono routine, ecc.
Il problema sta nel fatto (credo) che, in una frase composta da piu' 
combinazioni verbo+oggetto, l'entry point ParserError() viene invocato 
*UNA SOLA VOLTA*, proprio perche' presuppone un errore.
In sostanza, dopo il primo "errore", si ferma.
Per farlo funzionare, in teoria occorrerebbe dire ad Inform (quando 
trova una corrispondenza di parola-sconosciuta tra le "scenic" di un 
dato oggetto): "Ehi, puoi andare avanti con la frase, tutto ok!".
In effetti, nella frase (ad esempio) "x me. x fiume. x me", il primo "x 
me" funziona, ma non il secondo: Inform non lo processa (ha appena 
generato un errore), perche' e' convinto che "fiume" sia sbagliato 
(nonostante l'intervento di scenic*.h).
FRA

x hinges. x me.
Conan cannot see that.
si', anche tutti gli anglofoni hanno un bell'insettone sulla
coscienza! 8)
-- 
max "torredifuoco" bianchi