Newsgroup: it.comp.giochi.avventure.testuali
Titolo: Nsua e il suo bug con l'ultima versione di winfrotz

Salve a tutti
dopo aver esaminato il sorgente del mio vecchio gioco "Non Sarà
un'Avventura", mi sono accorto che l'occorrenza "move oggetto to nothing"
compare molto spesso, e anche vari algoritmi basano la loro consistenza
sulla presenza di alcuni oggetti spostati in nothing.
In sostanza, se volessi eliminare queste occorrenze dovrei riscirvere molte
parti di codice e il tutto solo per evitare un errore (a mio avviso tutt'ora
inspiegabile) con l'ultima versione di winfrotz.
Per quanto precede ho deciso di mettere nsua in uno stesso zip insieme ad
una versione precedente di winfrotz, un po' più arretrata, che non supporta
le accentate (tanto nemmeno il gioco le prevede), ma che per lo meno
funziona alla perfezione.
Lo zip è pronto, vorrei fare l'upload su IF-ITALIA.
A che indirizzo lo mando, e soprattutto, verrà messo online?
Grazie e ciao
RB

 sulla presenza di alcuni oggetti spostati in nothing.
Anzichè move oggetto to nothing usa move oggetto to magazzino, e crea una
locazione con nome magazzino.
Ciao,
Pedonzolo
--
"E' vero che tanto tempo fa i vigili del fuoco
spegnevano gli incendi invece di appiccarli?"
"No, è una leggenda. Le case sono sempre
state antincendio, potete prendermi in parola."

 locazione con nome magazzino.
Sicuramente Roberto già conosce questa soluzione ma come ha già detto 
non vuole mettere le mani sul codice e lo capisco visto che NSUA ha già 
qualche annetto ed è sempre meglio occuparsi di cose nuove che di quelle 
vecchie.
Roberto, manda a me che lo metto io su IF-ITALIA.
Giovanni
-- 
Giovanni Riccardi - 
giov...@composizioni.net
 - 
http://www.composizioni.net

 locazione con nome magazzino.
Ottima idea....
Pero' l' idea originale e' del buon erix nel suo modulo base.... con tanto 
di brontosauro sonnolento ! ;)
Saluti,
Dott. Piergiorgio.

 locazione con nome magazzino.
eh si, è un errore di concetto e sicuramente il buon BaR c'è già 
arrivato da tempo, il problema è che giustamente non ha voglia di 
ricompilare tutto...  lo capisco... :)

 locazione con nome magazzino.
Cosi' non da warning, ma concettualmente continua ad essere sbagliata. 
La soluzione giusta rimane remove oggetto, e (parent(oggetto)) per 
vedere se l'oggetto esiste (comunque la correzione non e' 
necessariamente cosi' semplice).
D'altronde se BaR non vuole rimettere le mani sul codice, lo capisco; 
anche perche' se si inizia a rimettere le mani su qualcosa di vecchio, a 
quel punto diventa (almeno per me) quasi impossibile sistemare solo una 
cosa; si inizia a sistemare tutto e il lavoro diventa non trascurabile.
E comunque il problema non e' poi cosi' grave. Credo proprio che tutti 
gli interpreti possano essere settati per ignorare errori simili.
bye
-- 
Paolo Lucchesi
email: 
pluc...@tin.it
homepage: 
http://www.paololucchesi.it
"Non viviamo in un mondo perfetto (per fortuna)"




 gli interpreti possano essere settati per ignorare errori simili.
si, però è bruttino... dai bar, riscrivi tutto! :)
ciao
S

necessariamente cosi' semplice).
perche' dici che una soluzione del genere e' sbagliata? come esponente
della categoria dei novellini, esigo una spiegazione terra terra!  :)
max "torredifuoco" bianchi

 della categoria dei novellini, esigo una spiegazione terra terra!  :)
Perché un conto è rimuovere l'oggetto (non c'è più) e un conto spostarlo 
semplicemente nell'albero degli oggetti come figlio della locazione 
magazzino (puoi di nuovo rimetterlo in gioco).



Perche' gli oggetti non esistenti devono stare staccati dall'albero 
degli oggetti.
Con il magazzino introduci un "trucco" inutile, per fare qualcosa che 
andrebbe fatta semnplicemente con remove. Aggiungi una complicazione 
inutile.
E inoltre corri il rischio di introdurre degli errori: ad esempio con la 
soluzione del magazzino tutti gli oggetti non esistenti sono fratelli 
tra di loro, e questo e' sbagliato.


 si, però è bruttino... dai bar, riscrivi tutto! :)
Sbonk! (caduta dalla sedia)
R

bye
ciao,
max "torredifuoco" bianchi

 oggetto?
remove(oggetto) non distrugge l'oggetto, lo "stacca" dall'albero... Puoi 
rimetterlo in gioco in qualsiasi momento.
Comunque, tanto per parlare, l'idea del magazzino puo' essere utile in 
certi casi. Ad esempio se voglio togliere temporaneamente tutti gli 
oggetti del player, o tutti gli oggetti in una locazione.



Aborro questa soluzione, se ti dovesse capitare poi di fare qualcosa
tipo "ciclo tutto l'albero" che fai, inizi a scrivere nel ciclo un'istruzione
di controllo per escludere il magazzino?
bai
t

> Anzichè move oggetto to nothing usa move oggetto to magazzino, e crea una

Beh, la cosa non cambia molto se devi fare un objectloop con una istruzione
per escludere gli oggetti che non hanno parente. Siccome non si può usare
objectloop con una espressione che non inizia per la variabile che devi
assegnare, e siccome "obj in nothing" non è un'espressione valida, eseguire
un loop sugli oggetti che hanno un parente risulta in:
[1a]
objectloop( obj ) {
        if ( parent(obj) == nothing ) continue;
        ....
}
Analogamente, quelli che sono in nothing (quindi nel nostro "non magazzino"
standard):
[1b]
objectloop( obj ) {
        if ( parent(obj) ~= nothing ) continue;
        ...
}
Ciò è operativamente uguale a (anche se un 'pelo' più lenta)
dell'espressione necessaria per gestire gli oggetti "non esistenti" in un
programma che implementa l'idea del magazzino:
[2]
objectloop( obj ) {
        if ( parent(obj) == nothing or magazzino ) continue;
}
ma in compenso è possibile fare objectloop per gli oggetti in magazzino:
[3a]
objectloop( obj in magazzino ) {
        ...
}
o nel caso tu voglia vedere tutti gli altri:
[3b]
objectloop( obj notin magazzino ) {
        ...
}
le espressioni 3a e 3b sono molto più efficienti (e operativamente più
gradevoli) della soluzione 1 (a o b), quindi non vedo cosa ci sia da
aborrire. Ovviamente, la cosa deve essere fatta bene, ma avere un parente
"magazziniere" per tutti gli oggetti non locazione del gioco che devono
essere "rimossi" è una soluzione elegante e potente; ammesso che venga
gestita come si deve.
Volendo, si potrebbe avere un oggetto che contiene tutte le locazioni. Non
vi siete mai sentiti in imbarazzo per dover cercare fra tutte le locazioni
possibili? E cercare tutti gli oggetti che non hanno parente non è un
criterio soddisfacente...
Saluti,
Giancarlo.

 possibili?
Mai capitata una necessità del genere...
bai
t

Tommaso Caldarola wrote:

A me sì: la prima versione del dordum permetteva di aprire un portale verso
tutte le locazioni. Nella MFS ho anche il VEDONIT, che non ho usato in
warmage, che permetteva originariamente di vedere cosa succede in una
qualsiasi locazione del gioco come se il giocatore si fosse trovato lì. Poi
ho inventato il banzor, che è necessario per designare in anticipo
l'oggetto del dordum e del vedonit, anche se è ancora possibile dirigere
sia il dordum che il vedonit in locazioni diverse da quella immagazzinata
dal banzor, a livello di libreria.
Giancarlo.

 si, però è bruttino... dai bar, riscrivi tutto! :)
Ma guarda te!!! :(
Il solito Gaburri ;D
--
Lory S.

 Sbonk! (caduta dalla sedia)
Ecco Gab... visto?
Ne hai combinata un'altra delle tue!!! :P
--
Lory S.