releases.txt

================================================================================
Rella 115



================================================================================
Rella 114



================================================================================
Rella 113

- Aggiunte le opzioni di config.ini:
dam_plr_vs_plr = 100
dam_plr_vs_mob = 100
dam_plr_vs_item = 100
dam_mob_vs_plr = 100
dam_mob_vs_mob = 100
dam_mob_vs_item = 100
dam_item_vs_plr = 100
dam_item_vs_mob = 100
dam_item_vs_item = 100
  Queste opzioni di config sono regolatori in percentuale del danno
  attaccante/vittima, quindi si può impostare
dam_plr_vs_mob = 90
  per diminuire del 10% il danno degli attacchi dei pg nei confronti dei mob,
  mentre se invece si cambia l'opzione
dam_mob_vs_plr = 110
  viene aumentato del 10% il danno degli attacchi dei mob nei confronti dei pg.
  Tutte opzioni che possono essere utilizzate per contrastare l'attuale
  temporaneo e bacoso disequilibrio nel combat.

- Creato un nuovo miml: season
  esempio:
Vedi una radura #season is SEASON.WINTER#ricoperta di neve#rigogliosa#.
  In inverno produrrà l'output:
Vedi una radura ricoperta di neve.
  mentre nelle altre stagioni:
Vedi una radura rigogliosa.
  Testato: funziona!

- Sono riuscito a convertire la creazione della pagina elements_list.htm
  con tutte le entità html al posto degli accenti non vi dovrebbero quindi
  essere discrepanze per la conversione delle codifiche e robe varie.

- Aggiunte le etichette di behaviour
Look:
Listen:
Smell:
Touch:
Taste:
Intuition:
  Servono a far inviare i rispettivi comandi senza alcun argomento.
  Testato: funziona!

- Ho convertito tutti i trigger relativi ai social in questa maniera:
  Tutti i trigger che devono scattare su colui che esegue il social sono
  formati come questo esempio:
  before_active_smile
  after_active_smile
  Tutti gli altri trigger relativi ai social sono formati come questo esempio:
  before_passive_smile
  after_passive_smile
  Questi secondi sono i trigger che scattano su coloro che "subiscono" lo
  smile, cioè che vedono il social.
  Testato su un before_passive_smile, funziona!

- Aggiunta l'etichetta FollowEntityComeMessage alla struttura Walker, funziona
  come FollowEntityGoMessage ma con un tag in più a quest'ultima:
  %followers che è la lista di uno o più nomi delle entità che stanno
  inseguendo entity
  Il messaggio è quello che entità guida leggerà dopo aver ricevuto il look
  dello spostamento per avere conferma visiva delle entità che la stanno
  seguendo.
  Da aggiornare quindi il manuale per tutte queste cosette.
  L'ho testato e funziona, all'inizio avevo inserito l'etichetta nel Walker
  del bidone del caldarrostaio, ma mi sbagliavo, non bisogna inserirla nel
  Walker di chi segue, ma del seguito, quindi l'ho inserita in un Walker di me
  stesso e mi son fatto seguire da Wisdul; magari indicare questo aspetto
  dell'etichetta nel manuale.

- Non so se sia il caso di aggiungere nel manuale che è stato inserito il tag
  %material per gli oggetti rip... mh?
  A discrezione tua.
  Il tutto è descritto meglio qui: http://aarit.wikidot.com/bug:112-distruggi-item

- Bisogna cambiare tutte le etichette Icon in questa maniera:
da
Icon:         icon/
a
Icon:         icons/
Ovvero cambiare la folder dal singola al plurale.

- Ho aggiunto ai materiali le caratteristiche di stato e di durezza, il tutto
  nel file MATERIAL.py, esse serviranno per gestire caratteristiche fisiche
  dei materiali

- Ho rifatto il comando destroy in maniera totale, ora funziona più o meno
  come il dig, ovvero quando il comando viene inviato mano a mano l'oggetto
  viene distrutto e vengono inviati dei messaggi dell'azione in progresso.
  Il comando destroy funziona sulle entità del proprio inventario e anche su
  tutte le altre al di fuori dell'entità stessa, quindi anche sulle porte!
  Se si crea una porta di marzapane chiusa a chiave (senza chiave esistente)
  la si può buttare già distruggendola, visto che è fatta di materiale leggero.
  Il comando come il dig può essere interrotto digitando un altro comando che
  esegue un'azione concreta, come ad esempio il get.
  Visto dall'esterno non è che il comando destroy sia cambiato molto, al suo
  interno invece è molto differente, non fa alcun riferimento al sistema di
  combat tranne che per i messaggi di danno.
  Ho fatto un'ulteriore modifica al codice all'ultima ora che permette di
  distruggere item con life minore dell'hardness del materiale con cui è formata
  in un round solo, quindi subito.
  Il comando destroy dà 1 px per ogni oggetto distrutto, poca roba (aumentabile
  al limite), ma magari serve ad incentivo come sistema di pulizia di entità
  inutili.
  Testato.

- Aggiunta, per i soli item, la struttura Destroy, essa è formata dalle seguenti
  etichette, tutte opzionali:
Destroy:
    Comment:                 # Commento
    StartDestroyEntity:      # Messaggio inviato all'entità che sta iniziando a distruggere qualcosa
    StartDestroyOthers:      # Messaggio inviato a tutti coloro che possono vedere l'azione dell'inizio della rottura
    StartDestroyTarget:      # Messaggio inviato all'entità su cui si ha iniziato l'azione di distruggere
    ContinueDestroyEntity:   # Messaggio inviato all'entità mentre sta continuando a distruggere qualcosa
    ContinueDestroyOthers:   # Messaggio inviato a tutti coloro che vedono l'azione continuativa della rottura
    ContinueDestroyTarget:   # Messaggio inviato all'entità che sta venendo in continuazione rotta
    EndDestroyEntity:        # Messaggio inviato all'entità mentre sta continuando a distruggere qualcosa
    EndDestroyOthers:        # Messaggio inviato a tutti coloro che vedono l'azione continuativa della rottura
    EndDestroyTarget:        # Messaggio inviato all'entità che sta venendo in continuazione rotta
    StopDestroyEntity:       # Messaggio inviato all'entità che ha fermato l'atto di distruggere qualcosa
    StopDestroyOthers:       # Messaggio inviato a tutti coloro che vedono l'entità fermarsi nell'atto di distruggere qualcosa
    StopDestroyTarget:       # Messaggio inviato all'entità su cui viene fermato l'atto di distruggerla
End
  Sono messaggi che vengono visualizzati tramite l'utilizzo del comando Destroy,
  in particolare i primi tre vengono visualizzati se uno invia il comando
  destroy 3 mela
  per dire di distruggere 3 mele, ma nell'inventario ve ne sono solo 2.
  Per tutti i messaggi ci sono questi tag speciali:
%verb = rompere/distruggere
%verb_you2 = romperti/distruggerti
%verb_you = rompi/distruggi
%verb_it = rompe/distrugge
  Testato

- Tutte le strutture di etichetta dal nome Materials devono essere rinominate
  in MaterialPercentages.

- Aggiunta la FLAG.CAN_DAMAGING da aggiungere a tutti quegli oggetti a cui si
  vuole dare la possibilità d'utilizzare il comando destroy e il comando kill
  (attualmente quest'ultimo non è stato ancora attivato gli oggetti, la cosa
  rimarrà in attesa fino alla riscrittura totale del sistema di combattimento,
  tuttavia nonostante l'incompletezza è voluto che la flag venga impostata
  comunque pensando al futuro).
  È una flag pensata per oggetti animati che debbano in qualche modo eseguire
  delle azioni di combattimento, magari per delle quest o dei gamescript.
  Testato.

- Ora è possibile guadagnare px esplorando
  Si guadagna +(livello dell'area * 100) per ogni area nuova scoperta
  Si guadagna +(livello dell'area / 2) per ogni stanza nuova scoperta
  È quasi ovvio il fatto di tenere lontano dalle aree newbie quelle di 200
  livello, oltre al fatto che vi dovrebbero essere mostri impossibili da battere
  dai newbie, un player novello che entra in un'area di livello 200 la prima
  volta riceve 20000 di esperienza, un bel boost iniziale!
  Di certo raggiungere un'area del genere ad inizio livelli è una buona strategia.
  Testato.

- Ora è possibile guadagnare px anche leggendo.
  La prima volta che si leggerà un book verranno guadagnati
  (livello del libro * 10) px, non ho osato dare di più per via del fatto che
  sarebbe facilmente abusato prendendo libri di livello altissimo e dati in
  pasto ai newbie che guadagnerebbero di botto un massimo di 2000px.
  Testato.

- Ora è possibile guadagnare px anche scavando.
  La prima volta che si scaverà in una locazione verranno donati un quantitativo
  di esperienza pari al livello dell'area.
  Testato.

- Inoltre è possibile guadagnare px mangiando, bevendo (comando quest'ultimo
  non ancora concluso in attesa degli affect) o possedendo (tramite get o give
  ricevuto) per un guadagno di px uguale al livello dell'entità mangiata,
  bevuta o avuta nel proprio inventario per la prima volta.
  Testato tutto tranne il comando drink data la sua natura incompleta.

- E ancora! Si guadagnano px sulle entità e le stanze che vengono esaminate
  la prima volta con un qualsiasi comando sensoriale che non sia il look e
  che abbiamo una descrizione (extra e non) sensoriale valida relativa al
  comando utilizzato.
  +(livello delle entità) per le entità su cui è stato usato un senso per la
  prima volta oppure
  +(livello dell'area) per le room su cui è stato usato un senso la prima volta
  Testato.

- Si guadagna px anche seminando o piantando una entità, la prima volta che
  questa verrà piantata verranno guadagnati livello_entità * 10 px
  Stessa cosa per i comandi di open, unlock e unbolt, enter, sell, buy ma con
  moltiplicatori di px rispettivamente di 10, 50 e 10, 100, 10 e 10
  Testati tutti.

- Aggiunta l'opzione di config exp_modifier nella sezione [GAME], serve ad
  impostare quanto in percentuale tutti i guadagni positivi di esperienza
  andranno modificati, impostato a 100, come di default, i valori donati
  rimarranno tali quali.
  Testato.

- Ora con gli oggetti layarable c'è un meccanismo maggiormente intelligente
  di remove e wear, più ordinato.
  Testato.

- Ora i negozianti non dovranno avere del denaro sotto forma di entità reale
  per poter comprare gli oggetti da parte dei giocatori.
  Siamo peggio della Banca Europea! Unlimited!
  Testato.

- Scavando c'è una probabilità del 10% di trovare (se non esiste nulla di
  sotterrato) un oggetto qualsiasi dell'area rip, oppure un oggetto con flag
  RANDOMIZABLE, oppure una entità ENTITYPE.SEED del database, oppure una
  qualsiasi moneta razziale (quelle impostate nel file RACE.py);
  per le monete viene anche inserita una quantità inversamente proporzionale
  al valore della moneta stessa
  da 1 a 1000 monete di rame
  da 1 a 100 monete d'argento
  da 1 a 10 monete d'oro
  1 moneta di mithril
  Tengo a sottolineare inoltre che è possibile impostare la flag
  FLAG.RANDOMIZABLE
  anche sui mob, così da poter far apparire scavando animaletti come serpenti
  e topi.
  Testato parzialmente, non mi è mai capitato di trovare delle monete.

- Ho osservato che il nome in un file dat è impostato così:
Name:    Un [sandybrown]Fradiciume[close]
  So che son stato io a dire di fare così, ma mi sa che è meglio convertirlo
  in una di queste quattro forme:
Name:    un [sandybrown]Fradiciume[close]
Name:    un [sandybrown]fradiciume[close]
Name:    il [sandybrown]Fradiciume[close]
Name:    il [sandybrown]fradiciume[close]
  Ovvero per l'etichetta Name utilizzare gli articoli in minuscolo, poi a
  volte per nomi così "impersonali" come fradiciume utilizzare il minuscolo,
  alternativamente utilizzare al posto degli articoli indeterminativi gli
  articoli determinativi
  Da aggiornare nel manuale.

- Anche riguardo le Short, ShortNight, Name delle descrizioni ho aggiunto dei
  messaggi che avvertono se queste etichette sono iniziate con articoli, o
  simili particelle, maiuscole; e inoltre viene avvertito se è stato aggiunto
  un punto finale.
  Questo sia per le entità che per le room.
  Da aggiornare nel manuale queste particolarità se non vengono dette.

- D'ora in poi anche le etichette di Name, Short e ShortNight supportano i
  tag di act, quindi la sabbietta di entropy viene visualizzata correttamente.
  Da aggiornare il manuale.
  Testato.

- Ora entità con short aventi tag html vengono ripulite correttamente durante
  la creazione delle parole chiave, altrimenti i tag html rimanevano nella
  keyword e l'utente non le poteva utilizzare
  Testato, funziona

- La colorazione tramite span html e colori esadecimali (che utilizzano il
  carattere #) facevano casino con l'uso dei miml e l'output si incasinava.
  Ora tutto a posto.
  Testato, funziona


================================================================================
Rella 112
06/08/12

- Ho aggiunto il parametro finale behavioured all'interfacciamento dei seguenti
  trigger:
  --> tutti i trigger dei canali
  --> tutti i trigger di movimento
  --> tutti i trigger dei sensi
  --> tutti i trigger relativi ai comandi (cioè trigger relativi direttamente
  ad un comando in particolare, esempio: before_buy, before_buying,
before_bought)
  Per esempio, un trigger qualsiasi:
Da:
def before_emote(entity, argument):
def after_emote(entity, argument):
a:
def before_emote(entity, argument, behavioured):
def after_emote(entity, argument, behavioured):
  Il parametro behavioured può essere utilizzato in maniera strategica: può
  servire ad attivare il trigger solo se è stato eseguito in maniera
  intelligente (player, force di un admin o futuro sistema di scheduler) e
  non ripetuta roboticamente come viene fatto dai behaviour.
  Poiché il parametro viene inserito un po' dappertutto forse è il caso di
  descriverlo una tantum all'inizio nella pagina del manuale apposita.
  Bisogna passarsi tutti i trigger dei gamescript ed aggiungere il parametro
  behavioured in coda a tutti gli altri.

- Aggiunti i trigger before/after_enter_in_game e before/after_exit_from_game
  tutti e due funzionano solo sui player ed hanno questo interfacciamento tipo:
def before_enter_in_game(player):
  idem per gli altri 3
  Attenzione: sono trigger da usare solo quando esattamente sapete cosa state
  facendo, in particolare non giocate con la from_location e to_location in
  questi trigger o succedono macelli.

- Per i gamescript una buona notizia, ho aggiunto il metodo
  if proto.has_reached_max_global_quantity():
  che andrebbe della riga di codice:
  if proto.max_global_quantity != 0 and proto.current_global_quantity
>= proto.max_global_quantity:
  sarebbero da modificare gli script a riguardo, per avere una migliore
  leggibilità del codice

- Mi servirebbero dei test sulla flag di act $i
  il cui contenuto sia FLAG.NO_LOOK_LIST e/o con la
FLAG.INTERACTABLE_FROM_OUTSIDE
  Ricordo che:
    $i
    # Ritorna i nomi in elenco delle entità visibili in una locazione.
    # Nonostante la $i sia minuscola fa riferimento sempre a target.
  Alla stessa maniera mi domando come si comporti la numerazione
  1.xxx
  2.xxx
  3.xxx
  con contenuti al cui interno vi sono entità NO_LOOK_LIST o
INTERACTABLE_FROM_OUTSIDE

- Ecco la lista di tutti gli act, ad uso e consumo della pagina web del manuale
  da creare:
Il più delle volte i messaggi di act hanno un soggetto: colui che sta facendo
l'azione.
Tutti i tag minuscoli, se non dichiarato altrimenti, sono relativi a colui
che sta compiendo l'azione: il soggetto, nel caso più tipico il giocatore.
Tutti i tag maiuscoli, se non dichiarato altrimenti, sono relativi all'oggetto
relativo all'azione (per esempio il mob relativo ad un comando di
azione di kick)

Di seguito ci sono gli act di tag utilizzati per la gestione
grammaticale delle frasi:
$o e $O: ritorna il carattere grammaticale 'o' oppure 'a' a seconda
del sesso dell'entità.
$lui e $LUI: ritorna lui/lei
$gli e $GLI: ritorna gli/le

Di seguito ci sono gli act di tag utilizzati per descrivere le parti
del corpo delle entità, variano a seconda della razza:
$hands e $HANDS: ritorna la stringa descrivente le mani dell'entità
$hand1 e $HAND1: ritorna la stringa descrivente la mano principale dell'entità
$hand2 e $HAND2: ritorna la stringa descrivente la mano secondaria dell'entità
$hand e $HAND: ritorna la stringa descrivente una generica mano dell'entità
$feet e $FEET: ritorna la stringa descrivente i piedi dell'entità
$foot e $FOOT: ritorna la stringa descrivente un generica piede dell'entità
$skin e $SKIN: ritorna la stringa descrivente la pelle dell'entità
$tongue e $TONGUE: ritorna la stringa descrivente la lingua dell'entità

Di seguito ci sono gli act di tag utilizzati per la traduzione dei comandi:
$t: Traduce l'input scritto di seguito al tag nella lingua preferita
per l'invio dei comandi dell'entità, per esempio:
$tlook
tradurrà 'guarda' per coloro che usano i comandi in italiano, altrimenti look
$T funziona come $T ma non invia il colore di default utilizzato per i
comandi lasciando la possilità di colorare la traduzione come si
vuole.

Di seguito ci sono gli act di tag relativi al calendario gdr del gioco:
$minute: ritorna l'attuale minuto
$hour: ritorna l'attuale ora
$day_week: ritorna l'attuale nome del giorno della settimana
$day: ritorna l'attuale giorno del mese
$month: ritorna l'attuale nome del mese
$season: ritorna il nome dell'attuale stagione
$year: ritorna l'attuale anno

Di seguito ci sono gli act di tag utilizzati per ricavare i nomi delle entità:
$n: ritorna il nome dell'entità che esegue l'azione
$N: ritorna il nome dell'entità che subisce l'azione
$a: ritorna il nome della prima entità ausiliaria del metodo di act
$A: ritorna il nome della seconda entità ausiliaria del metodo di act

Spiego meglio con un esempio il funzionamento del metodo act:
entity.act("Hai dato un calcio a $N mentre $a e $A stavano a
guardare!", TO.ENTITY, vittima, compagno1, compagno2)
entity.act("$n ti ha dato un calcio mentre $a e $A stavano a
guardare!", TO.TARGET, vittima, compagno1, compagno2)
entity.act("$n ha dato un calcio a $N mentre $a e $A stavano a
guardare!", TO.OTHERS, vittima, compagno1, compagno2)

Concettualmente il metodo di act funziona in questo modo:
entità_$n.act("messaggio con i tag di act",
TO.ENTITY|TO.TARGET|TO.OTHERS, entità_$N, entità_$a, entità_$A)

Solitamente $a e $A non vengono utilizzati, nei messaggi di act più
semplici, con un'azione ma senza la vittima che la subisce non vi è
neppure il bisogno di inserire $N e neppure del messaggio a TO.TARGET:
entity.act("Sorridi sornione...", TO.ENTITY)
entity.act("$n sorride sornione...", TO.OTHERS)

C'è da dire inoltre che i tag ausiliari di $a e $A possono passare
anche una stringa descrivente qualche cosa:
entity.act("miagoli verso $a...", TO.ENTITY, None, str(DIR.NORTH))
entity.act("$n miagola verso $a...", TO.OTHERS, None, str(DIR.NORTH))

Altri tag di act sono:
$l e $L: ritorna il nome dell'attuale locazione in cui si trova
rispettivamente l'entità che esegue l'azione e l'entità che la subisce
$p e $P: ritorna il nome della locazione precedente in cui si trovava
rispettivamente l'entità che esegue l'azione e l'entità che la subisce
$k e $K: ritorna la parola chiave relativa rispettivamente all'entità
che esegue l'azione e all'entità che la subisce

Attenzione a questi due tag di act che non funzionano sull'entità che
esegue l'azione ma sull'obiettivo dell'azione
$i: elenca le entità contenute nell'obiettivo della stringa di act
$I: visualizza il nome dell'entità di peso maggiore nell'obiettivo
della stringa di act

- Bisogna sostituire questi tag di act nei data:
$c -> $l
$C -> $L
$w -> $p
$W -> $P
Attenzione che la prima è una elle minuscola.
Fai attenzione durante la sostituzione che ho visto che ci sono parole
che iniziano con $c che non sono però dei tag di act.

- Ho creato il comando use, funziona come "sinonimo generico" di alcuni comandi:
close
drink
eat
enter
open
read
remove
seed
plant (questo è un comando che ho aggiunto poi)
unlock
unbolt
wear
I comandi si attivano controllando la tipologia d'entità e il suo
possibile stato
Il comando use con il read è stato semplificato, ovvero non si può leggere
entità dentro altre entità come invece fa il read, ma solo entità che si trovano
addosso o per terra.

- Anche il comando use, come quasi tutti quanti ormai, ha i suoi bei trigger:
def before_use(entity, target, argument, behavioured):
def after_use(entity, target, argument, behavioured):
def before_used(entity, target, argument, behavioured):
def after_used(entity, target, argument, behavioured):
I primi due si attivano sull'entità che ha eseguito il comando, gli altri due
invece si attivano sull'entità utilizzata.
entity è l'entità che esegue il comando
target è l'entità utilizzata
argument è l'eventuale argomento rimanente del comando
Bisogna aggiornare il manuale a riguardo

- Ho cambiato tutti i trigger di kill, attack e destroy, ora gli unici trigger
  che rimangono sono quelli di kill e killed:
before_kill(entity, target, attack, destroy, behavioured)
after_kill(entity, target, attack, destroy, behavioured)
before_killed(entity, target, attack, destroy, behavioured)
after_killed(entity, target, attack, destroy, behavioured)
i primi 2 scattano sull'entità che sta eseguendo o ha eseguito il comando
i secondi 2 scattano sull'entità che lo sta subendo o lo ha subito
entity è colui che sta killando
target è colui che subisce il kill
attack è un valore booleano che indica se si sta killando tramite comando attack
destroy è un valore booleano che indica se si sta killando tramite
comando destroy
behavioured funziona come per tutti gli altri: indica se il comando è
stato inviato tramite qualche tipo di behaviour
Concettualmente tutti questi trigger funzionano come il trigger dell'eat, così
da diminuire il numero di trigger da inserire con la stessa tipologia di codice
da copia e incolla
Bisogna modificare i gamescript ed aggiornare il manuale

- Corretti i trigger di read, che avevano un baco relativamente alla lettura
  delle extra, come da punto
http://aarit.wikidot.com/ask:110-trigger-read-extra
  ora il loro interfacciamento è:
def before_read(entity, target, output, detail):
  in pratica ho invertito l'ordine di output e detail
  così anche gli altri relativi al read.

- Riscritti i trigger di wake:
def before_wake(entity, target, behavioured):
def after_wake(entity, target, behavioured):
def before_waked(entity, target, behavioured):
def after_waked(entity, target, behavioured):
I primi due si attivano su chi ha eseguito il comando.
I secondi due si attivano su chi lo sta subendo, non si attivano se il
comando è stato eseguito su se stessi.
entity è colui che esegue il comando.
target colui che lo subisce.

- Ho aggiunto il trigger sul comando date, l'interfacciamento è il seguente:
def before_date(entity, behavioured):
def after_date(entity, behavioured):
entity è colui che ha digitato il comando.

- Ho aggiunto il trigger sul comando equipment, l'interfacciamento è
il seguente:
def before_equipment(entity, target, behavioured):
def after_equipment(entity, target, behavioured):
entity è colui che ha digitato il comando
target è l'entità con l'equipaggiamento da visualizzare, se entity ha digitato
il comando equipment senza argomenti, per vedere il proprio equipaggiamento,
target viene passato a None

- Ho aggiunto i trigger di inventory che hanno lo stesso interfacciamento di
  quelli dell'equipment

- I trigger relativi al list erano sbagliati, questi i corretti:
before_list(entity, dealer, behavioured):
after_list(entity, dealer, behavioured):
before_listed(entity, dealer, behavioured):
after_listed(entity, dealer, behavioured):
I primi due si attivano su chi ha eseguito il comando.
I secondi due si attivano sul negoziante.
entity è colui che ha digitato il comando.
dealer è il negoziante.

- Ho aggiunto i trigger sul comando money (mi sembra di averli tolti
  nell'ultima release, cough cough, ho una consistenza nelle modifiche
  che è allarmante)
def before_money(entity, behavioured):
def after_money(entity, behavioured):
entity è colui che ha digitato il comando
(Sì non è un granché come trigger, ma magari vi viene il pallino di usarlo)

- Ho cambiato nome al parametro di interfacciamento from_where dei trigger di
  remove in location

- In tutti i trigger dei sensi, del look (e del read, ma questo l'ho già detto
  sopra) ho scambiato l'ordine dei parametri descr e detail.

- Adesso i trigger a livello di area dovrebbero funzionare.
  In sostanza basta creare un file py nella cartella relativa ai dati di area,
  con lo stesso nome del codice dell'area da triggerare, ed inserirvi i
  trigger che si vuol far funzionare a livello di area.
  Da aggiungere nel manuale.

- Aggiunta un'etichetta alla struttura Walker:
RunnedVerbIt:
che sarebbe il corrispondente relativo alla corsa di ComeVerbIt

- Ho implementato un sistema che visualizza il personaggio in corsa, invece
  che in camminata, capita quando questi stia inviando comandi di movimento
  con una certa rapidità l'uno dall'altro.

- Aggiunta l'opzione di config running_step_time nella sezione GAME che deve
  essere impostata a 0.5
  Indica i secondi o i centesimi di secondo minimi tra un comando di movimento
  ed un altro per considerarlo come corsa.
  È un valore eventualmente da tarare empiricamente, praticamente fa capo alla
  domanda: quando la rapidità dell'invio ripetuto di una direzione si può
  considerare corsa nel mud?

- Ho mantenuto cmq il check dell'owner nel comando refresh, è meglio che faccia
  meno danni possibile.
  Se ne è parlato qui:
  http://aarit.wikidot.com/ask:111-command-refresh

- Ho cambiato il nome della FLAG.NO_CORPSE in FLAG.NO_REMAINS
  Questo perché anche gli oggetti ora hanno un sistema simile a quello di
  creazione dei cadaveri, anche se non sono propriamente cadaveri, quindi
  ho preferito cambiarne il nome.

- Ho convertito le etichette Corpse in Remains e CorpseNight in RemainsNight.
  Ora tali etichette funzionano anche con gli item con lo stesso meccanismo
  dei mob.
  Bisogna creare almeno una nuova entità perché il sistema funzioni, tale entità
  deve avere codice
rip_item_broken-something
  Per diminuire la presenza di questa entità durante la distruzione
degli oggetti
  per tutte le tipologie di entità si possono creare altre entità con
questo codice:
rip_item_broken-xxx
  dove xxx è il nome del codice di ENTITYPE minuscolo, in pratica suddividere i
  "cadaveri" degli oggetti per entitype, appunto è un po' come fa con la razza
  per i cadavere dei mob.
  C'è da tenere conto di una cosa nella creazione delle short di queste entità:
  all'atto di creazione dell'entità distrutta dell'oggetto viene aggiunga alla
  short la scritta:
di yyy
  dove yyy è il nome del materiale cui era formata l'entità ormai rotta, quindi
  c'è da tenere presente questa aggiunta dinamica all'atto creativo
nella stesura
  delle long delle entità dell'area rip.

- Aggiunta l'opzione max_output_buffer per la sezione [SERVER]
  da impostare a 128000

- Adesso si può utilizzare il comand flee anche per sfuggire dalle persone che
  ci stanno seguendo, tale modalità funziona solo se non si sta combattendo,
  altrimenti in quel caso funziona come prima

- Ho modificato il nome dell'entichetta di TalentsPoints in Talents

- Creato il sistema di ridistribuzione dei talenti (sarebbero delle
  'pratiche estese' per riprendere i nomi dei vecchi mud) sui punti di vita,
  mana e vigore.
  Da testare adeguatamente visto che è una parte delicata per i pg, ovvero
  se c'è un baco in alcuni parti delicate come questa hanno la tendenza ad
  alterarsi.

- Ho creato il comando talents per aprire la tab di distribuzione dei talenti
  Non intendo inserirlo nel bigino dei comandi, il sistema è già abbastanza
  automatico e non necessita di visibilità.

- Aggiungere a tutti i player l'etichetta Practices da impostare con un valore
  di 2 * Level
  In alternativa se lo script bash è troppo complesso da fare si possono
  recupare i comandi già utilizzati nella release r111 e impostare tutti i
  livelli a 1, impostare MaxLife, MaxMana e MaxVigour a 100 e azzerare i
  Talents e ovviamente inserire la nuova etichetta Practices con valore a 0,
  il resto farà Aarit una volta che il giocatore entrerà in gioco.

- Ho modificato la flag RESET.PLANTING in RESET.GROWING.
  Da modificare le eventuali occorrenze nei file dat.

- Ho aggiunto il metodo utile anche agli script chiamato
can_carry_target
funziona così:
if entity.can_carry_target(target):
        allora lo mette in inventario
else:
        lo lascia per terra
can_carry_target fa la stessa cosa di questo pezzo di codice:
if (target.weight * target.quantity) + entity.get_carry_weight() >
entity.can_carry_weight():
        allora lo mette in inventario
else:
        lo lascia per terra
opzionalmente si può passare la quantità di target che si vuole passare in
inventario, per esempio:
if entity.can_carry_target(target, quantity=3):
        allora lo mette in inventario
else:
        lo lascia per terra
can_carry_target fa la stessa cosa di questo pezzo di codice:
if (target.weight * 3) + entity.get_carry_weight() > entity.can_carry_weight():
        allora lo mette in inventario
else:
        lo lascia per terra

- Già che sono in modalità di insegnamento esiste il metodo wait utile per
  fermale l'invio interattivo di una entità.
  Esempio:
  [codice]
  interpreter(entity, "kick vittima")
  entity.wait(3)
  interpreter(entity, "kick vittima")
  [resto del codice]
  Allora l'entità invierà un calcio alla vittima, aspetterà 3 secondi e poi
  ne invierà un altro, attenzione che non è una deferred! il [resto del codice]
  viene eseguito subito e non vengono attesi tre secondi, sono solo i comandi
  interattivi che vengono messi in coda per entity
  Ho pensato che questa conoscenza vi potesse essere utile per ingarbugliare
  ulteriormente le cose.

- Ho cambiato i trigger di put e give in questa maniera:
def before_give(entity, target, receiver, direction, behavioured):
  e così anche gli altri tre, da modificare il manuale.
  Ho cambiato il nome a target e a receiver, ma sono sempre la stessa cosa di
  prima; quello che ho aggiunto è, oltre al behavioured come tutti i gamescript,
  direction.
  Il parametro direction indica la direzione verso la quale una porta, target,
  viene inserita sui cardini, in quel caso receiver è a None.
  Viceversa quando receiver è valido direction è passata a DIR.NONE.

- Relativamente al sistema di buy e sell ho aggiunto il magazzino concreto.
  Esso consiste in varie modifiche:

  Ho aggiunto l'etichetta ProtoStorages, che nel manuale va inserita prima
  delle ProtoLocations per ordine di importanza.
  È facoltativa e se non viene impostata allora ritiene che il magazzino
  sia il negoziante stesso.
  È possibile impostare una o più codici di prototipo indicante l'entità
  da utilizzare come magazzino, dev'essere un'entità direttamente accessibile
  dal negoziante stesso:
  mob, item o la location medesima.

  Ho rimosso la possibilità che una ProtoLocations potesse essere un player,
  non ricordo se l'avevo detto esplicitamente per il manuale o se era una
  feature fantasma, ora cmq non c'è più.

  Ho rimosso il valore relativo allo store dall'etichetta di Buyable, quindi
  quest'ultima avrà la precedente sintassi MENO quel particolare valore.

  Quello che vi manca sapere ora è che per impostare la mercanzia bisogna
  resettare le entità definite in buyables nello storage definito (o nel
  negoziante se non definito) la quantità resettata fa da valore di store.

  Bisogna testare il ProtoLocations che l'ho cambiato, ma vabbé... c'è da
  ritestare tutto il sistema in realtà (a parte il comando offer che non
  ho toccato).

- Rimossi i PersonalResets, da modificare il manuale e i data.

- Aggiunta l'opzione di config time_warp nella sezione [DEVELOPMENT]
  Da impostare normalmente a False quest'opzione se impostata a True eseguirà
  le deferred tutte un secondo dopo la loro definizione, senza attendere il
  loro naturale decorso.
  Anche i loop di aggressivness, digestion e supply non attenderanno il naturale
  decorso ma avranno la tendenza ad attivarsi il prima possibile (dipende dalla
  opzione _loop_seconds di ognuno dei loop, per esempio aggressivness_loop
  viene attivato ad ogni secondo, mentre gli altri due ogni 60 secondi)

- Rinominata l'opzione di config use_mudscripts in use_gamescripts

- Ora il massimo peso trasportabile si basa logaritmicamente sul vigore e
  non più sulla forza.
  È una delle regole fondamentali del nuovo sistema di Aarit, serve anche a
  dare maggior rilievo ai punti di vigore che, tradizionalmente, sono
  maggiormente snobbati rispetto agli altri due.

- Aggiunto il comando plant, ciò comporta un po' di cose:
  Prima di tutto le piante ora si manipolano con il comando plant
  Mentre i semi tramite il comando seed.
  Tali comandi sono uguali, cambia solo la tipologia di entitype.
  Difatti ora esiste l'entitype SeedType: che ha stesse etichette e tutto quanto
  del PlantType.

  Vi sono i relativi trigger per il comando plant, che hanno stesso
  interfacciamento di quello di seed (behavioured incluso ovviamente):
def before_plant(entity, target, location, ground, behavioured):
def after_plant(entity, target, location, ground, behavioured):
def before_planted(entity, target, location, ground, behavioured):
def after_planted(entity, target, location, ground, behavioured):
def before_planting_in_location(entity, target, location, ground, behavioured):
def after_planting_in_location(entity, target, location, ground, behavioured):
  L'unica cosa che c'è da tenere bene in conto è che, mentre tramite il plant
  si possono piantare solo entità con il plant_type, tramite il seed ora
  è possibile piantare qualsiasi entità, ovviamente non avverrà nessuna crescita
  a livello di pianta ma verrà interrata l'entità. (Have fun!)

  Ho notato, riguardando il comando di seed/plant, che per interrare la pianta
  o il seme viene creato un container_type all'interno dell'eventuale terreno,
  è una cosa da tenere d'occhio, per ora non ho trovato alternativa migliore,
  ma la cosa non mi piace moltissimo.

- Modificato il trigger before_gived e after_gived in before_gave e after_gave
  Da modificare il manuale e tutte le occorrenze nei gamescripts.

- Ho rimosso l'opzione di config autoreload_loop_seconds

- Rinominata l'opzione di config allow_robots in allow_web_robots

- Rinominata l'opzione di config news_to_send in news_to_show

- Rinominata l'opzione di config log_accent in log_accents

- L'opzione di config text_color è stata spostata nella sezione [SITE]

- Rimossa l'opzione show_square dal file di config

- Rinominata l'opzione max_square_msg_show in max_square_messages
  Se tale opzione viene impostata a 0 disattiverà la piazzetta

- In generale ho eseguito molte modifiche relativamente al sistema di gruppo
  fisico e attualmente per la maggior parte delle azioni (a parte codice
  particolare di gamescript e altre cose di cui non ho tenuto il conto) la
  manipolazione sulle entità avviene su quantità singola.
  Prima invece a parte i comandi come get, give e put la maggior parte delle
  manipolazioni su entità avvenivano sull'eventuale mucchio fisico relativo
  all'entità obiettivo.
  Ve ne accorgerete presto di che cosa significhi ciò e imparerete altrettanto
  presto a usare la sintassi:
  drop tutti.seme
  Altra particolarità è che anche il look esegue una divisione fisica
  momentanea dell'entità da guardare.

- Ho aggiunto l'opzione di config max_execution_time nella sezione [SERVER]
  da impostare a 0.04
  Ogni qual caso che si cambierà eventualmente server passando ad uno più veloce
  si potrebbe voler aggiustare tale valore a 0.03
  Tale tempo se superato durante l'esecuzione dei comandi invierà un
messaggio del tipo:
  "Il comando %s è stato eseguito in troppo tempo: %f secondi"
  Messaggio già incontrato in passato, e normale se durante il comando è
  intercorso un crash, brutta cosa invece se tale crash non è avvenuto e
  da segnalare (concorrerebbe a problemi relativi ai mucchi fisici)

- Attenzione che ho rimosso tutti i comandi concretly che non erano
  autoconsistenti rispetto al sistema del mucchio fisico, d'ora in poi bisogna
  fare a meno di quei pochi che erano stati definiti.
  Bisognerà invece creare l'argomento stringa in maniera corretta come viene
  fatto in molti gamescript (tramite l'utilizzo della get_numbered_keyword
  ad esempio)
  Ho trovato nei gamescript due occorrenze commentate di command_get_concretly,
  se si ha intenzione di utilizzare gli script bisognerà convertirli con
  command_get e get_numbered_keyword relativa.

- In uno dei gamescript c'è questo pezzo:
    room_weight = 0
    for content in to_room.iter_contains():
        #print "PESO in LOOP = ", room_weight, content.code
        room_weight += content.get_carry_weight()
        room_weight += content.weight
    #print "PESO ROOM = ", room_weight
da modificare in
    room_weight = 0
    for content in to_room.iter_contains():
        #print "PESO in LOOP = ", room_weight, content.code
        room_weight += content.get_total_weight()
    #print "PESO ROOM = ", room_weight

Anche questa riga è da modificare:
total_wielded_weight = asciugamano.weight + asciugamano.get_carry_weight()
in
total_wielded_weight = asciugamano.get_total_weight()

- Ho modificato il nome del metodo get_carry_weight in get_carried_weight
  ho notato che vi sono delle occorrenze nei gamescript, e quindi vanno
  modificate di conseguenza

- Bisogna aggiungere l'opzione
email = info@aarit.it
nella sezione
[MAIL]

- Creata la pagina support_us.html
  Dategli un'occhiata e fatemi avere pareri

- Ho aggiunto il comando comment che funziona come i comandi idea, typo e bug
  Inoltre nella cartella data ora c'è una nuova directory: comments
  Bisogna poi andare al file config.ini ed aggiungere la seguente riga:
max_account_comments = 1000
  nella sezione di config [GAME]
  Ho già aggiunto il comando nel bigino.

- Ho creato il sistema di gift, basta collegarsi come amministratore con trust
  di implementor e andare nella sezione Manage Players, da lì si può accedere
  alla sezione apposita.

- Nela manuale ci sono i trigger
def before_outcoming(entity, from_room, direction, to_room, looker):
def after_outcoming(entity, from_room, direction, to_room, looker):
  e quelli
def before_incoming(entity, from_room, direction, to_room, looker):
def after_incoming(entity, from_room, direction, to_room, looker):
  inseriti in posizione secondo me errorea, concettualmente sono trigger simili
  a quelli di move e di direzione, che si trovano un po' più in alto, magari
  inserirli subito sotto

- Aggiunti i a tutti i trigger di move, direzionali, incoming e outcoming
  un parametro aggiuntivo da inserire prima del behavioured, quindi al
  penultimo posto:
  running
  Servirà ad indicare allo script se si sta correndo oppure no
  Volendo si possono fare dei script ad uopo di una pseudo corsa a premi, o
  persone che si stupiscono se uno sta correndo.
  Da aggiungere nel manuale e modificare i gamescript

- Non ho finito il sistema di ban/punizioni, quindi la pagina relativa è useless


================================================================================
Rella 111
26/06/12

* Cambiare tutte le occorrenze negli script da
target, counter = entity.find_entity(...
  in
target = entity.find_entity(...

* Nei gamescript inoltre bisogna fare questa conversione:
  da
dust.find_entity("bruco", ["mobs"], location)
  a
dust.find_entity("bruco", location, ["mobs"])
  Cioè invertire l'ordine del secondo e terzo parametro

* Rimuovere a tutti i player la flag FLAG.DISTRIBUTE, attenzione che quasi tutti
  i player hanno solo tale flag nell'etichetta Flags, e quindi bisogna
rimuovere

Inoltre:
* Modificare il valore di tutte le etichette:
  Life, MaxLife, Mana, MaxMana, Vigour e MaxVigour
  a 100
* Rinominare tutte le etichette Practices dei player in TalentPoints
  e impostarle a 0
* Impostare tutte le etichette Level dei player a 1
Questa tripletta di modifiche potrebbe divenire un classico in futuro,
serve ad azzerare la ridistribuzione dei punti di talento (pratiche) tra i
punteggi vita, mana e movimento (e poi ci sarà in futuro la parte per azzerare
le conoscenze: skill, spell etc etc)

* Da aggiungere l'opzione
persistent_act_seconds = 2
  nella sezione [GAME] del file config.ini

* Rinominata l'etichetta EntityResets in PersonalResets relativamente
  all'etichetta delle entità, per non confondersela con quella delle aree
  Attenzione durante il replace di non sostituire anche quelle delle
aree quindi.

* Bisogna modificare tutte le occorrenze nei gamescript di
show_wear_messages
in
send_wear_messages

* Bisogna modificare tutte le occorrenze nei gamescript di
get_numbered_argument
  in
get_numbered_keyword

- Di seguito ci sono dei punti relativi ai gamescript, ovviamente tutto ciò che
  ho fatto, anche se non l'ho detto in alcuni punti è da aggiornare nel manuale
  alla pagina dei gamescript.
  ATTENZIONE: esegui il tutto con l'ordine dei punti senza saltare perché
  ci sono modifiche successive e cumulative tra di loro.

- Adesso il trigger on_reset funziona anche all'avvio, se si vuole che non
  funzioni durante l'avvio basta un check nel gamescript di questo tipo:
    from src.engine import engine
    if engine.booting:
        return

- Aggiunti i trigger di before_from_location, after_from_location,
  before_to_location e after_to_location.
  Interfacciamento:
def before_from_location(entity, quantity):
def after_from_location(entity, quantity):
  Funzionano concettualmente come la from_location del codice kernel:
  entity è l'entità (mob o item) da rimuovere per una quantità voluta
  dalla locazione in cui si trovano attualmente.
def before_to_location(entity, location):
def after_to_location(entity, location):
  Funzionano concettualmente come la to_location del codice kernel:
  entity è l'entità (mob o item) da inserire nella locazione voluta
  (room, mob, item o player).

- Elenco per sicurezza tutti i trigger che funzionano in maniera personale:
  "on_booting", "on_shutdown", "on_reset", "on_repop", "on_init_after_booting",
  "before_inject", "after_inject", "before_extract", "after_extract",
  "before_to_location", "after_to_location", "before_from_location",
"after_from_location",
  "on_dawn", "on_sunrise", "on_noon", "on_sunset", "on_dusk", "on_midnight"
  Da aggiornare quindi nel manuale

- Se si ritiene opportuno, inserire nella pagina di manuale dei gamescript le
  funzioni di defer descritte nelle note di release precedente in una sezione
  o in una pagina a parte

- Ho rimosso i trigger before_money e after_money

- Aggiunti i trigger posizionali:
def before_stand(entity):
def after_stand(entity):
def before_wake(entity):
def after_wake(entity):
def before_knee(entity):
def after_knee(entity):
def before_rest(entity):
def after_rest(entity):
def before_sit(entity):
def after_sit(entity):
def before_sleep(entity):
def after_sleep(entity):
entity è l'entità (mob, item o player) che effettua l'azione

- Aggiunto il trigger:
def before_emote(entity, argument):
def after_emote(entity, argument):
entity è l'entità (mob, item o player) che sta effettuando esprimendo qualcosa
argument è l'argomento passato per descrivere l'espressione
L'emote è particolarmente adatto per personalizzare una risposta di un'enigma
che richiede una posizione particolare del corpo, come: coprirsi gli
occhi con una mano
emote si copre gli occhi
Il trigger potrebbe attivarsi con la presenza delle parola copre/coprire e occhi
Stesso discorso lo si potrebbe fare con il before_say comunque (come tra l'altro
ho già visto fare nei gamescript già esistenti)

- Modificato il trigger before_look e after_look aggiungendo un
parametro finale:
use_examine, valore booleano che indica se il comando è stato digitato per
eseguire un look oppure per eseguire un examine, quindi il nuovo
interfacciamento
è:
def before_look(entity, target, detail, descr, use_examine):
def after_look(entity, target, detail, descr, use_examine):
differenziandosi così dagli altri sensi, quindi se sembra il caso forse è meglio
separarlo dagli altri e descriverlo a parte.
Bisogna aggiornare gli script che hanno questo trigger aggiungendovi
il parametro

- Modificato il trigger before_close e after_close in maniera tale da carpire
  se tale trigger è stato eseguito tramite un comando di shut:
def before_close(entity, target, reverse_target, container_only):
def after_close(entity, target, reverse_target, container_only):
container_only è un valore booleano che indica se il comando cercherà solo tra
i contenitori e non anche sulle porte

- Aggiunti i trigger
def before_eat(entity, food, devour, swallow):
def after_eat(entity, food, devour, swallow):
def before_eated(entity, food, devour, swallow):
def after_eated(entity, food, devour, swallow):
entity è l'entità (mob, item o player) che sta mangiando il cibo
food è il cibo
devour è un valore booleano che indica se il trigger è stato azionato tramite
il comando divora invece del comando mangia
swallow è un valore booleano che indica se il trigger è stato azionato tramite
il comando ingoia invece del comando mangia
I primi due trigger si attivano se impostati sul file di script con codice
uguale a entity, mentre gli altri due si attivano se impostati su file di
script con codice uguale a food.
Ricordo che comunque tutti e due possono essere attivati tramite script con
tali trigger della locazione che li contiene.

- before_read e after_read già esistono nel manuale ma comunque scrivo
  tutto per completezza:
def before_read(entity, target):
def after_read(entity, target):
def before_readed(entity, target):
def after_readed(entity, target):
entity è l'entità (mob, item o player) che sta mangiando il cibo
target è l'entità (mob o item) letta
I primi due trigger si attivano se impostati sul file di script con codice
uguale a entity, mentre gli altri due si attivano se impostati su file di
script con codice uguale a target.
Ricordo che comunque tutti e due possono essere attivati tramite script con
tali trigger della locazione che li contiene.

- Per il trigger di open ho fatto la stessa cosa che ho eseguito al trigger di
close, ho aggiunto il parametro finale container_only: medesime considerazioni.

- Modificato tutti i trigger dei canali aggiungendo due parametri finali:
ask ed exclaim
che indicano se il discorso lo si sta domandando o esclamando, esempio di un
paio di trigger modificati, il resto vien da sé:
def before_speech(listener, speaker, target, phrase, ask, exclaim):
def after_speech(listener, speaker, target, phrase, ask, exclaim):
def before_whisper(listener, speaker, target, phrase, ask, exclaim):
def after_whisper(listener, speaker, target, phrase, ask, exclaim):
ask è un valore booleano indica che la frase è stata esclamata
exclaim è un valore booleano indica che la frase è stata domandata
Difatti sottolineo che, nonostante solo per il canale say venga convertito il
verbo nel messaggio da "Di" a "Domandi" o "Esclami", il valore di ask e exclaim
viene definito per tutti i canali a seconda del numero di punti di domanda
rispetto ai punti esclamativi.
Da aggiornare tutte le occorrenze dei trigger di canale nei gamescript.
Da modificare altresì il manuale

- Rinominati i trigger da before_speech e after_speech rispettivamente
  in before_rpg_channel e after_rpg_channel.
  Bisogna cercare eventuali occorrenze nei gamescript e modificarli.
  Da modificare altresì il manuale

- Nella release 109 avevo scritto riguardo ai trigger di sell:
"C'è da tenere conto inoltre che target di before_sell è l'entità originale,
quella con quantità totale, mentre in after_sell target è un'altra entità,
quella ormai venduta, con la quantity voluta."
  Ora non è più vero, ora invece c'è coerenza quantitativa tra before_sell e
  after_sell, quindi se lo si è segnato nel manuale è meglio toglierlo.

- Ho rinominato i seguenti trigger
(LEGGI ANCHE IL PUNTO SUCCESSIVO PRIMA DI EFFETTUARE LE MODIFICHE che purtroppo
l'ho scritto dal punto di vista delle modifiche e non da quello degli
aggiornamenti da fare sul manuale):
before_bolt -> before_bolted e after_bolt -> after_bolted
before_close -> before_closed e after_close -> after_closed
before_dig -> before_digged e after_dig -> after_digged
before_drop -> before_dropped e after_drop -> after_dropped
before_follow -> before_followed e after_follow -> after_followed
before_get -> before_getted e after_get -> after_getted
before_kill -> before_killed e after_kill -> after_killed
before_lock -> before_locked e after_lock -> after_locked
before_look -> before_looked e after_look -> after_looked
before_open -> before_opened e after_open -> after_opened
before_remove -> before_removed e after_remove -> after_removed
before_unbolt -> before_unbolted e after_unbolt -> after_unbolted
before_unlock -> before_unlocked e after_unlock -> after_unlocked
before_wear -> before_weared e after_wear -> after_weared
before_wield -> before_wielded e after_wield -> after_wielded
before_hold -> before_holded e after_hold -> after_holded
before_intuition -> before_intuited e after_intuition -> after_intuited
before_touch -> before_touched e after_touch -> after_touched
before_taste -> before_tasted e after_taste -> after_tasted
before_smell -> before_smelled e after_smell -> after_smelled
before_listen -> before_listened e after_listen -> after_listened
before_kick -> before_kicked e after_kick -> after_kicked
E tutti questi si attivano se li si inserisce sulla vittima dell'azione, bisogna
rinominarli ad uopo in giro per i gamescripts
Ricordo che before_digged e after_digged può essere utilizzato anche per una
room e non solo per una entità

- Mentre sono stati aggiunti i trigger
before_bolt e after_bolt
before_close e after_close
before_dig e after_dig
before_drop e after_drop
before_follow e after_follow
before_get e before_get
before_kill e after_kill
before_lock e after_lock
before_look e after_look  (attento a non confonderti con il lock, sono
due trigger differenti (avviso creato dall'associazione nottambuli))
before_open e after_open
before_remove e after_remove
before_bolt e after_bolt
before_unlock e after_unlock
before_wear e after_wear
before_wield e after_wield
before_hold e after_hold
before_intuition e after_intuition
before_touch e after_touch
before_taste e after_taste
before_smell e after_smell
before_listen e after_listen
before_kick e after_kick
tutti con lo stesso interfacciamento dei precedenti ma questi si attivano su di
colui che esegue l'azione
Aggiornare il manuale! Quante volte l'avrò scritta questa frase in
questa release?

- I vecchi trigger
before_say e simili, compreso il before_rpg_channel (insomma tutti i trigger
dei canali) si attivano su chi fa l'azione, invece i trigger per coloro che
sentono il canale rpg sono:
before_listen_rpg_channel e after_listen_rpg_channel
before_listen_say e after_listen_say
before_listen_yell e after_listen_yell
e così via...
Medesimo interfacciamento, da cambiare tutte le occorrenze nel codice dei
gamescript e aggiornare il manuale

- Aggiunti i trigger
before_drop_from_location
after_drop_from_location
con stesso interfacciamento degli altri trigger di drop
scattano dentro lo script di location

- Rinominato il trigger
before_buy -> before_buying
after_buy -> after_buying
che si attiva se inserito sul negoziante (oppure ovviamente nella locazione
dove si trova il negoziante).
Rinominare le occorrenze nei gamescript se necessario.
Mentre invece è stato aggiunto il trigger before_buy e after_buy che si attiva
su colui che esegue l'azione di buy.

- Per consistenza quando inserirai i trigger buy, bought e buying elencali
  nell'ordine appena scritto (bought sarebbe concettualmente "buyed" nella
  nomenclatura triggerosa di aarit se hai capito il concetto generale che
  sta sotto)

- Aggiunti i trigger:
before_entered e after_entered, con lo stesso interfacciamente dei due trigger
fratelli ma questi si attivano se inseriti nel gamescript relativo al portale.

- Aggiunti i trigger
before_fleeing e after_fleeing che si attivano su colui che sta combattendo
contro colui che sta scappando, hanno lo stesso interfacciamento dei due
trigger fratelli

- Rinominato il trigger da before_offer in before_offering, idem per l'after
tali trigger si attivano se inseriti sul negoziante, mentre ho
aggiunto i trigger
before_offer e after_offer che si attivano se inseriti su colui che
esegue l'offer,
ho inoltre aggiunto i trigger before_offered e after_offered che si attivano
se inseriti nel gamescript della cosa offerta.
Naturalmente tutti hanno la stessa interfacciamento, già scritto nella pagina
di manuale attuale.

- Ho modificato il trigger before_read, after_read e before_readed e
after_readed
aggiungendo due parametri in più in coda, in questo ordine:
output: ciò che viene letto
extra: se ciò che è stato letto viene da una extra questo parametro è l'extra
Inoltre rinominati i trigger
before_read_extra -> before_readed
after_read_extra -> after_readed
da aggiornare eventuali gamescripts

- Rinominato il trigger da before_seed in before_seeding_in_location,
idem per l'after,
  che si attivava sulla locazione in cui si semina.
  Aggiunti inoltre i trigger:
  before_seed e after_seed, che si attivano sull'entità che esegue l'azione
  before_seeded e after_seeded, che si attivano sull'entità che subisce l'azione
  Stessa interfaccia per tutti, già esistente nel manuale.

- Rinominato il trigger before_sell in before_selling, che si attiva
sul venditore
(idem per il fratello after).
Cambiare eventuali nome di trigger nei gamescript.
Aggiunto il trigger before_sell e fratello after che si attiva sull'entità che
esegue l'azione.
Interfacciamento già esistente nel manuale, da aggiornare solo con i
nuovi trigger.

- Ignorare i trigger di die attuali, ora funzionano così:
before_die(entity, opponent):
after_die(entity, opponent):
before_dies(entity, opponent):
after_dies(entity, opponent):
I primi due vengono attivati quando inseriti su un'entità che muore.
I secondi due vengono attivati quando inseriti su un'entità che uccide.
entity è l'entità che muore
opponent è l'entità che uccide, potrebbe essere a None se entity sta morendo
per cause naturali oppure (ad esempio) per una DT.

- Aggiunto i trigger, altri altri due già esistenti:
before_undergoes_aggressiveness e after_undergoes_aggressiveness
Si attivano sulla vittima del messaggi di aggressiveness
Hanno lo stesso interfacciamento dei trigger già esistenti
Da modificare il manuale

- Aggiunti i trigger:
before_digested e after_digested, con lo stesso interfacciamento dei trigger
con nome simile, e che si attivano quando inseriti nell'entità digerita.
Mentre i trigger già esistenti si attivavano se inseriti nei gamescript
dell'entità che sta digerendo (*burp*)

- Aggiunti i trigger:
before_supplied e after_supplied, con lo stesso interfacciamento dei trigger
con nome simile, e che si attivano quando un'entità va a rimpinguare il
magazzino di un negoziante.
Mentre i trigger già esistenti si attivavano se inseriti nei gamescript
dell'entità negoziante che attende il rifonimento.

- Corretti i comandi che gestiscono la quantità per i trigger di before_, ovvero
  droppando un'unità di entità veniva passata tutta la quantità totale e non
  la singola.
  Era un problema identico a quello che aveva il sell, punto descritto meglio
  precedentemente

- Controllare che il manuale sia stato aggiornato relativamente questo punto:
http://aarit.wikidot.com/ask:110-trigger-read-extra

- Il trigger di on_init ora funziona sempre quando le entità o le room vengono
  create, anche all'avvio; bisogna fare attenzione però perché nel momento in
  cui si attivano le entità non si trovano ancora in una locazione valida,
  quindi è ok cambiare caratteristiche intrinseche l'entità ma giocare sui
  riferimenti è proibitivo.

- Aggiunto il trigger
remove_persistence
  con interfacciamento seguente:
def remove_persistence(data):
  dove data è una location (room, mob o item) che viene rimossa
tramite il bottone
  nel web: Rm Persistence
  Mi è venuto in mente di creare il trigger, per esempio, per lenire il problema
  dell'anello che aggiunge la flag NO_LOOK_LIST, in maniera tale che
allo scattare
  di questo trigger vi si possa inserire del codice che scorra nei
personaggi che
  hanno tale aggeggio e rimuovere il NO_LOOK_LIST di conseguenza.
  E' un placebo.. se la persistenza viene rimossa a mano o per qualche
altro errore
  la flag rimane.
  Il problema di fondo è che tale cosa del NO_LOOK_LIST dovrebbe
essere un'affect,
  questa è una frase da aggiungere allo script, così una volta
esistenti gli affect
  lo si converte ad uopo ed è possibile gestire la cosa senza aggiungere codice
  hard coded, che è sostanzialmente inutile agli effetti.

- Ho implementato il sistema dell'impugnatura a due mani per le armi

- Ora i loop persistenti non verranno salvati se non c'è attiva l'opzione
  save_persistence

- Risolto un problema dei reset, quale non ricordo.. ma penso che sia un punto
  relativo la r110 già descritto a fondo lì

- Aggiunta la riga dei px nello score e anche quella dei punti di talento

- Corretto il problema del no_send in molti punti, probabilmente non è stato
  corretto in tutti i punti quindi se sbuca fuori da qualche parte bisogna
  farlo presente di volta in volta

- Ho creato il comando di admin refresh che serve ad aggiornare le vetuste
  descrizioni delle istanze di gioco persistenti con quelle di prototipo
  maggiormente corrette da typo e aggiornate con modifiche

- Ora è possibile inserire entità nella stessa parte/i tramite la flag
  WEAR.LAYERABLE
  nell'etichetta Flags della struttura WearType.
  L'etichetta Flags in tale sottostruttura è da aggiungere al manuale.
  Basta che una delle due entità abbia tale flag per permette che una venga
  inserita sopra l'altra qualchessia l'ordine di vestizione.
  Tramite questo sistema non è possibile inserire più di due entità nella
  stessa parte/i.

- Il comando incognito ora cercherà tra i giocatori online prima di tutto.

- Ho fatto modifiche fondamentali al sistema di connessione di aarit, ciò
  significa che la situazione di quali browser funzionino e quali non per quali
  tipologie di connessioni (comet e ajax) è tutta aperta, in particolare per
  internet explorer 7.0 (che se qualcuno possiede potrebbe fare dei test e
  farmi sapere?)

- Dovrei aver corretto il problema della ricorsione dei reset personali.

- Ora la persistenza dell'azione per le entità in wandering non darà un
  messaggio di long no_send ma una messaggio ad uopo

- Ora i possono mimlare anche le long!

- Ora il prezzo di buy terrà conto anche dei value delle entità all'interno
  sommandole così in un totale unico

- Ora il contenuto delle piante ha una discreta probabilità che cada nella
  stanza invece che nel vaso, dipende tutto dalla grandezza del vaso e della
  pianta

- Aggiunta nelle etichette
EntityMessage
TargetMessage
OthersMessage
della struttura FoodType e DrinkType (quest'ultima forse non esiste ancora
nel manuale e se non lo è attendiamo a farla)
il tag %verb, che indica di utilizzare il verbo normalmente utilizzato
nel comando

- Tutte le etichette personalizzabili dei container e delle door
  (tranne le etichette di eatkey che non avevano comunque verbo)
  che avevano come tag $a il verbo ora utilizzano invece il tag %verb
al suo posto

  Mentre il tag $a serve ad indicare la room di destinazione, ma solo nel qual
  caso il messaggio sia relativo alle porte
  (in questo caso invece anche i messaggi personalizzati di eatkey
hanno questo tag!)

  In più i messaggi personalizzabili di open e close hanno un tag in più:
  $A: serve ad visualizzare il nome dell'eventuale porta che c'è
dall'altra parte

  Per tutti questi messaggi personalizzabili delle porte (ovvero proprio tutti)
  è stato aggiunto il tag %dir che indica la direzione in cui si sta agendo,
  ma ricordo: funziona solo per le porte

- Sia per i messaggi personalizzabili di enter che di exit ho aggiunto i
  seguenti tag:
  %verb: il verbo dell'azione
  $a: locazione attuale
  $A: locazione precedente

  Ai messaggi personalizzabili del no_room ho aggiunto il solo tag
  %verb: il verbo dell'azione

- Aggiunto il tag, per tutti i messaggi personalizzabili del WearType,
  %part: che indica la parte, o le parti, che vengono coperte dal wear o
  scoperte dal remove

- Te lo metto qui nel qual caso te ne dimentichi:
  controllare la doppia esistenza del file, differente tra l'altro, di
  walker.html e walker_struct.html

- Aggiungo che tutti i tag tipo %verb %part %direction etc etc vanno in
  maiuscolo o minuscolo automatico laddove serve.
  Spiegando meglio:
  [...] ciao a tutti! %verb [...]  -->  [...] ciao a tutti! Raccogli [...]
  [...] ciao a tutti, %verb [...]  -->  [...] ciao a tutti, raccogli [...]
  Quindi frasi come questa:
  ...opportuno fare attenzione alla maiuscola e minuscola
nell'iniziale del verbo...
  in walker.html
  non ha più valore e deve essere cancellata.

- Aggiunte le etichette alla struttura Shop
EntityBuyMessage:
OthersBuyMessage:
TargetBuyMessage:
DealerBuyMessage:
che servono a personalizzare i messaggi di buy avvenuto, i tag sono i seguenti:
$n: indica il soggetto che effettua la vendita
$N: mercanzia comprata
$a: negoziante
%verb: verbo dell'azione
%quantity: quantità venduta
%price: prezzo della vendita
Attenzione che in DealerBuyMessage i tag $N e $a sono scambiati
Sono tutti e 4 messaggi facoltativi e non sono "legati l'uno con
l'altro", ovvero
se uno esiste gli altre tre possono anche non essere definiti.
Da aggiornare il manuale

- Aggiunte le etichette alla struttura di Shop
EntityCannotAffordMessage:
OthersCannotAffordMessage:
TargetCannotAffordMessage:
DealerCannotAffordMessage:
che servono a personalizzare i messaggi di buy non avvenuto per
mancanza di fondi
i tag sono i seguenti:
$n indica il soggetto che effettua la vendita
$N: mercanzia comprata
$a: negoziante
%verb: verbo dell'azione
%quantity: quantità venduta
%price: prezzo della vendita
Attenzione che in DealerBuyMessage i tag $N e $a sono scambiati
Sono tutti e 4 messaggi facoltativi e non sono "legati l'uno con
l'altro", ovvero
se uno esiste gli altre tre possono anche non essere definiti.
Da aggiornare il manuale

- Aggiunte le etichette alla struttura Shop
EntityOfferMessage:
OthersOfferMessage:
TargetOfferMessage:
DealerOfferMessage:
che servono a personalizzare i messaggi di offer avvenuto, i tag sono
i seguenti:
$n indica il soggetto che effettua l'offerta
$N: mercanzia offerta
$a: negoziante
%verb: verbo dell'azione
%quantity: quantità venduta
%price: prezzo dell'offerta
Attenzione che in DealerOfferMessage i tag $N e $a sono scambiati
Sono tutti e 4 messaggi facoltativi e non sono "legati l'uno con
l'altro", ovvero
se uno esiste gli altre tre possono anche non essere definiti.
Da aggiornare il manuale

- Aggiunte le etichette alla struttura Shop
EntitySellMessage:
OthersSellMessage:
TargetSellMessage:
DealerSellMessage:
che servono a personalizzare i messaggi di sell avvenuto, i tag sono i seguenti:
$n indica il soggetto che effettua la vendita
$N: mercanzia venduta
$a: negoziante
%verb: verbo dell'azione
%quantity: quantità venduta
%price: prezzo della vendita
Attenzione che in DealerSellMessage i tag $N e $a sono scambiati
Sono tutti e 4 messaggi facoltativi e non sono "legati l'uno con
l'altro", ovvero
se uno esiste gli altre tre possono anche non essere definiti.
Da aggiornare il manuale

- Aggiunte le etichette alla struttura Shop:
EntityUninterestedMessage:
OthersUninterestedMessage:
TargetUninterestedMessage:
DealerUninterestedMessage:
sono messaggi di act di personalizzazione del messaggio di disinteresse da
parte del negoziante nel comando di offer e nel comando di sell
Tag di act utili per tali messaggi sono:
$n indica il soggetto che fa l'offerta
$N indica la cosa offerta
$a indica il negoziante disinteressato all'offerta
Attenzione che in DealerUninterestedMessage i tag $N e $a sono scambiati
Sono tutti e 4 messaggi facoltativi e non sono "legati l'uno con
l'altro", ovvero
se uno esiste gli altre tre possono anche non essere definiti.
Da aggiornare il manuale

- Ho aggiunto la flag NO_CORPSE, come suggerito nel wiki, indica che il mob non
  creerà un cadavere una volta morto, serve soprattutto per quei mob eterei,
  senza corpo

- Creato finalmente il sistema di tab nell'interfaccia di gioco, ho subito
  provveduto a implementare un sistema di log dei canali separato dall'output,
  ricordo che mi avevi indicato un player che aveva fatto richiesta di questa
  feature.

- Infine è doveroso indicare che d'ora in poi i giocatori cambieranno di
  livello una volta raggiunto il valore necessario, alcuni di loro probabilmente
  passeranno due livelli o magari più in rapida successione una volta entrati
  in gioco.
  Non ci sono bonus attualmente nel cambio di livello, tranne i punti di talento
  che però non sono ancora spendibili, ma si spera che lo saranno nella
  prossima release.

- Avendo corretto tutti i gamescript ci sono alcuni punti che ho trovato
  concettualmente errati e su cui è meglio soffermarsi:
1) Ormai esiste la get_numbered_kewyword che funziona così:
   mob_keyword = mob.get_numbered_kewyword(looker=player)
   che ritorna in automatico la prima keyword numerata ad uopo secondo la lista
   delle entità visualizzata da parte di player
   quindi mob_keyword ad esempio potrebbe essere:
   2.cavaliere o cavaliere semplicemente
   questo metodo sostituisce concettualmente quello precedente:
   first_keyword = mob.get_keywords_attr(player).split(" ")[0]
   o robe del genere
2) Bisogna ricordarsi che il metodo act è un metodo che indica l'azione di
  qualcuno, e colui che si trova a sinistra del nome del metodo è il soggetto
  dell'azione, quindi act di questo tipo:
        fabbro.act("$N cerca di darti robaccia ma tu non accetti.",
TO.ENTITY, player)
        fabbro.act("$n non accetta che tu gli dia alcunché.", TO.TARGET, player)
        fabbro.act("$N cerca inutilmente di dare qualcosa a $n.",
TO.OTHERS, player)
  in realtà li ho convertiti così:
        player.act("$N non accetta che tu gli dia alcunché.", TO.ENTITY, fabbro)
        player.act("$n cerca inutilmente di dare qualcosa a $n.",
TO.OTHERS, fabbro)
        player.act("$n cerca di darti robaccia ma tu non accetti.",
TO.TARGET, fabbro)
  perché è player il soggetto dell'azione
  (Da notare anche l'ordine dei messaggi di act: ENTITY, OTHERS e TARGET per far
  funzionare al meglio il sistema delle "azioni persistenti")
  Inoltre ho notato dei messaggi di act con il TO.ENTITY ma senza il TO.OTHERS,
  è un controsenso.. perché un'azione è sempre visibile in un modo o nell'altro
  a tutti: se non volete proprio far visualizzare il messaggio a tutti allora
  considerate l'utilizzo della semplice send_output.
  Le act inserite correttamente sono un plus non indifferente poiché in futuro
  potrebbe esistere il trigger per le act, e quindi è meglio scriverle
correttamente.
3) Ho notato utilizzi di act anche per cose dette al giocatore, concettualmente
   non è del tutto corretto fare così, questo perchè i mob potranno in futuro
   parlare in lingue dalla lingua comune (la lingua che conoscono
tutti) e quindi
   la act stonerebbe perché non si potrebbe convertire nel parlato del mob,
   quindi se volete rendere segreti dei messaggi utilizzate i comandi whisper
   o murmur (sono uguali, cambia solo il verbo)
   Se a tutt'oggi il comando whisper e il comando murmur sono leggibili a
   chiunque è da considerarsi un baco, ci vuole la skill apposita per poterli
   leggere, e quindi è da segnalare.
4) Ho notato utilizzi di inject quando invece si poteva utilizzare il comando
   give, cercate di utilizzare i comandi laddove possibile, lo capite quando
   scrivere delle act che in realtà ricordano dei comandi già esistenti.
   Così, come nel caso del give, avete il check del peso gratis.
   Ricordo che tutti i comandi ritornano True se il comando è andato a buon fine
   (o se si può definire comunque andato a buon fine, dipende dal comando),
   viceversa False.
   Quindi prendendo come esempio il give ritorna True se tutto è ok, ma ritorna
   False se il peso dell'entità a cui dare non può trasportare più di così (o
   per altri motivi come la flag di NO_GIVE).
5) Ho notato che v'è la tendenza negli script a farli funzionare solo
per i player.
   Tendenza più che comprensibile perché ne semplifica il codice.
   Ma immaginate anche la possibilità di renderli usabili anche da
parte dei mob.
   Una delle future feature di aarit sarà quella di poter programmare cosa
   far fare ad una data ora ai mob, quindi potenzialmente si potranno far fare
   le quest ai mob (una sorta di soluzione per il giocatore programmata).
   Fate inoltre conto che con il metodo get_numbered_keyword le cose diventano
   più facili, basta ricavare prima la keyword invece di utilizzare direttamente
   player.code.
   L'ho buttata giù come un'idea, poi vedete voi.
   Se siete preoccupati che i behaviour dei mob inficino troppo sui gamescript
   vi anticipo che in futuro si potrà ricavare lato gamescript se un'azione
   (get, look, say o quant'altro) di un'entità è nata da un behaviour o da
   un'azione genuina (force o futuro sistema di scheduling).
   Stay Tuned!
Tutti questi punti potrebbe essere il caso di scriverli nella pagina dei
gamescript o in una sezione a parte, tipo dei tips per i gamescripts o che

- Ho tolto l'etichetta Materials per la struttura Wall

- Non ho ancora controllato i trigger ad area, non ho avuto tempo, lo farò per
  la r112, sono convinto che non funzionino nella r111 quindi non testarli


================================================================================
Rella 110
06/05/12

* Bisogna aggiungere l'opzione di config
blob_loop_seconds
  nella sezione TIME del file config.ini, bisogna impostarla a 1.0

- Ho diminuito la priorità di ricerca per le porte, cioè se per caso vi fosse un
  oggetto nella stanza con prefisso simile a quello di una parola chiave di una
  porta utilizzando per caso tale prefisso non ritornerà la porta ma l'oggetto
  nella stanza; solo utilizzando la sintassi con il numero puntato (look 2.por)
  verrà ritornata la porta.
  (Per eventuale chiarezza passata questo sistema di priorità era già così ai
  tempi, quando le porte non avevano una location valida, poi il sistema cambiò
  e con esso anche la priorità di ricerca)

- Per la cronaca ora codice come
  entity.prototype non produrrà più una stringa con il codice identificativo
  del prototypo; in compenso repr(entity.prototype) dorrà informazioni utili.

- Aggiunta l'etichetta Materials (per ora non obbligatoria) per le entità.
  Indica di che materiale sono fatti.
  La sintassi è la seguente:
  Materials: MATERIAL.PAPER 100%
  Per scegliere un materiale basta andare alla lista dei materiali basta andare
  nella pagina delle enumerazioni oppure aprire il file MATERIAL.py ove vi sono
  dei commenti utili che spiegano alcuni possibili utilizzi di materiale.
  Il totale della percentuale di tutti i materiale deve essere 100%, se il
  materiale è uno solo deve essere impostato a 100%.
  Il materiale dei mob il più delle volte sarà FLESH, è accettabile che venga
  inserito anche un solo materiale (nonostante la complessità di un generico
  corpo di mob) volendo si può inserire la percentuale delle ossa, deprecato
  invece è l'inserimento in percentuale di liquidi (acqua e sangue per esempio)
  in un corpo di mob che non sia un contenitore (contenente appunto un liquido);
  in generale vige la regola semplificativa de': se è solido ha
materiali solidi,
  se è liquido ha materiali liquidi.
  Da aggiornare il manuale.

- Aggiunte l'etichetta
Materials
  per le stanze, con utilizzo e considerazioni intuibili rilevabili dal punto
  precedente.
  C'è inoltre da tenere conto che se si volessero personalizzare i materiali di
  una delle qualsiasi 10 virtuali pareti direzionali si può farlo visto che è
  stata aggiunta l'etichetta Materials anche per le strutture Walls
  (o meglio è stata cambiata da Material a Materials) e funziona come le
  etichette precedenti.
  Da aggiornare il manuale.

- Volendo si possono proporre dei nuovi materiali (o rimuoverne di
inutilizzati-bili)
  dalla lista di enumerazione dei materiali.

- I materiali si possono vedere tramite il comando esamina sui soli oggetti.

- Ora le extra vengono cercate nell'ordine in cui sono state inserite nel file
  dat e non come prima, la cui ricerca era un po' casuale.
  In pratica extra con keywords simili si dovranno cercare con la sintassi
  2.arg e si otterranno risultati omogenei ad ogni riavvio (diversamente da
  prima).

- E' stato rimosso il sistema di autoreload automatico dei dati che è solo un
  grosso baco difficilmente tappabile (senza del lavoro lato lato builder tutto
  tecnico e inutile per il gioco).

- E' ora possibile inserire degli entity reset dentro le entità
prototipo stesse,
  per esempio nella limbo_item_portal si può inserire:
EntityResets:
        ProtoEntity: limbo_item_porta
End
  e il portale avrà dentro di sé una porta.
  Tale feature serve anche a inserire negli oggetti da vendere un
certo contenuto,
  contenuto che si avrà per qualsiasi entità prototipo richiamata in gioco.
  Per dovere di cronaca tale inserimento di entità di reset avviene durante la
  inject (al caso si dovesse giocare con la before_/after_inject)
  Questo sistema di EntityResets nelle entità sono convinto che serva anche a
  qualche cosa d'altro ma non ricordo che cosa (era una feature che aleggiava
  come idea già da tempo) mi pare servisse per le entità in wandering... bho!
  Dovrebbero pure repoppare correttamente... mah!!
  Da aggiornare il manuale.

- Aggiunta l'etichetta Probability per gli EntityResets, è una percentuale:
Probability: 50%
  Serve ad indicare con quale probabilità da 1 a 100 un entity reset inserirà
  concretamente un'entità in gioco.
  Una volta inserità l'entità il repop successivo ha una probabilità
sempre del 100%.
  Se non viene inserita l'etichetta, che difatti è facoltativa, viene
considerata
  una Probability al 100%
  Da aggiornare il manuale.

- Aggiunto il comando offer e i relativi trigger before_offer e after_offer che
  funzionano come i relativi trigger di sell

- Aggiunta la tipologia di SHOP.DISPENSER, che indica che l'entità negoziante
  (checché sia un mob o un item) è un distributore, tale tipologia di shop
  non accetta i comandi sell e offer mentre il buy e il list funzionano
  normalmente ma con messaggistica più o meno modificata.
  Di contro il comando list funziona se il distributore non si trova in una
  proto_location atta alla vendita.

- I comandi di mcreate e ocreate ora creeranno l'entità nel proprio inventario
  invece che nella stanza in cui ci si trova.

- Ho aggiunto la FLAG.INTERACTABLE_FROM_OUTSIDE che serve a rendere le entità
  interagibili e visibili all'esterno di un contenitore, come ad esempio le
  piante, quindi bisognerà aggiungerla a mano a tutte le piante a cui si vuole
  questa feature, c'è di buono che essendo una flag generica la si può
utilizzare
  per qualsiasi altra entità con lo stesso comportamento.

- Ora se un giocatore eseguirà uno tra i comandi:
  sell, buy, offer o list su di un'entità questa entrerà in una "modalità
  interattiva" ovvero eviterà di eseguire qualsiasi behaviour.
  Questo è utile per i mob venditori ambulanti, visto che magari un pg digita
  il list ma intanto il mob si muove da un altra parte prima che il buy sia
  stato eseguito.
  La modalità interattiva termina quando il giocatore che l'ha attivata
  se n'è andato da quella locazione.

- Aggiunti dei sottovalori opzionali per l'etichetta Buyable, mentre prima
  la sintassi poteva essere solo, ad esempio, questa:
Buyables:       villaggio-zingaro_item_guinzaglio 150% 3 200
  ora può essere anche questa:
Buyables:       villaggio-zingaro_item_guinzaglio 150% 3 200 (10% 15)
  I due valori aggiuntivi tra parentesi indicano rispettivamente la percentuale
  di sconto e la quantità da comprare prima che lo sconto venga applicato.
  Ovvero per ogni quantità superiore al secondo valore tra parentesi verrà
  applicato una percentuale di sconto sul totale del prezzo da pagare.
  Cambiati i comandi list e il comando buy per supportare tutto ciò.

- Ho migliorato il comando read in maniera tale che finalmente leggesse le
  extra flaggate come EXTRA.READABLE; legge altresì le extra leggibili relative
  una direzione, porta o wall.
  Inoltre è possibile leggere libri direttamente da un'entità
contenitore aperta.
  Ho aggiunto poi i trigger di script before_ e after_read_extra che funzionano
  con lo stesso interfacciamento della before_ e after_look.
  Da aggiornare quindi il manuale per quest'ultima cosa.

- Bisogna cambiare in tutto il codice dei gamescript le chiamate di deferred da
task.deferLater(reactor, 60, reset_greetable, astronoma)
  a:
defer(60, reset_greetable, astronoma)

  C'è quindi poi la possibilità di rimuovere tutte le chiamate:
from twisted.internet import reactor, task
  nel codice degli script.

  Volendo si può quindi anche fare così:
defer_random_time(30, 60, reset_greetable, astronoma)
  Per indicare di funzionare dai 30 ai 60 secondi casualmente, diminuendo così
  il bisogno d'utilizzo della funzione randint.

  La defer funziona sostanzialmente come la defer_if_possible tranne
che ha due argomenti
  in meno.
  Per utilizzare tali deferred bisogna importarla così:
from src.defer import defer
from src.defer import defer_random_time
  Anche la defer_if_possible non c'è più nel modulo essential, quindi da:
from src.script.essential
  a:
from src.defer import defer_if_possible

- Il modulo src.script.essential non esiste più, quindi l'altra funzione del
  modulo, la get_target_implicetely, bisogna pescarla da
from src.social import get_target_implicetely
  Tutte le occorrenze di import get_target_implicetely nei gamescript
  devono essere cambiate così.

- Il comando icreate e mcreate può gestire quantitativi del tipo:
  icreate 5 scopa


================================================================================
Rella 108 e Rella 109
03/04/12

* Cambiato il nome della sezione del file config [CALENDAR] in [TIME]

* Da aggiungere le opzioni di config nel relativo file nella sezione [TIME]:
fight_loop_seconds = 0.1
game_loop_seconds = 1
maintenance_loop_seconds = 60
room_behaviour_loop_seconds = 1
decomposer_loop_seconds = 120
aggressiveness_loop_seconds = 1
autoreload_loop_seconds = 1
digestion_loop_seconds = 60
supply_loop_seconds = 60

* Da modificare il nome dell'opzione da port a http_port

* Aggiunta l'opzione di config currency_jump nella sezione [GAME] da
impostare a 1

* Creare la cartella persistence/loops e crearvi a sua volta questi
file testuali vuoti:
aggressivenesses.dat
digestions.dat
supplies.dat

* Bisogna modificare i nomi dei file da -> a:
calendar.dat   -> calendar.rpg
inputs_command_en.dat -> inputs_command_en.list
inputs_command_it.dat -> inputs_command_it.list
inputs_skill_en.dat   -> inputs_skill_en.list
inputs_skill_it.dat   -> inputs_skill_it.list
inputs_social_en.dat  -> inputs_social_en.list
inputs_social_it.dat  -> inputs_social_it.list
little_words.dat      -> little_words.list
vocabulary.dat        -> vocabulary.list

* Bisogna modificare rinominando dappertutto il Code d'entità:
ikea_item_coin-platinum-human
in:
ikea_item_coin-mithril-human
  bisognerà anche cambiare di conseguenza anche la descrizione ed eventuali
  altri riferimenti di etichetta del dato.

* Bisogna modificare tutte le occorrenze nei dati dell'etichetta Coppers
  della struttura MoneyType in CopperValue
  Aggiornare il manuale a riguardo.

* Nel codice dei gamescript modificare tutte le occorrenze di used_as
in entitype
  Inoltre nei dati modificare tutte le occorrenze di UsedAs: in Entitype:
  Aggiornare di conseguenza anche le pagine di manuale.

* Ignorare tutti gli errori nel caricamento relativi alle etichette
Upon:
Below:
Near:
Left:
Right:
Behind:
  Sono tutte etichette relative al futuro "sistema di posizionamento" (una cosa
  che sta sopra un altra, di fianco etc etc), che implementerò in altra maniera
  e quindi non servono più

* Modificare tutti i codici di file e di prototipo dei dati che erano
rip_item_cadavere-
in
rip_item_corpse-

* Se intendi mantenere le persistenze sappi che devi rimuovere la flag
  FLAG.ON_HINGES oramai inesistente et inutile

* Bisogna modificare nei gamescripts tutte le occorrenze di contained_by in
  location e di was_contained_by in previous_location
  Tutto ciò per spostarci in una visione metaforica più attinente ad Aarit
  rispetto gli "old muds".
  Ricordo inoltre che per accedere al valore reale di previous_location bisogna
  utilizzare le parentesi:
  previous_location = entity.previous_location()
  Invece location vi si accede come qualsiasi attributo:
  location = entity.location
  Bisogna inoltre modificare anche tutte le occorrenze nei dati di ContainedBy
  in Location e WasContainedBy in PreviousLocation.
  Oltre a ciò bisogna modificare la pagina del manuale relativo ai MIML poiché
  essi avevano una sintassi che utilizza contained_by invece di location
  ed ho aggiunto la sintassi, oltre che self, looker e location anche di
  previous_location.

* In tutti i dati bisogna modificare le occorrenze di %dir in %direction.
  Aggiornare il manuale, si trova nella pagina relativa al Walker

* Modificare in tutti i gamescripts le occorrenze di proto, come parola intera,
  in prototype

* Ho aggiunto l'opzione use_visual_grouping da impostare a False per la testing
  e da impostare poi a True per l'official poiché è ancora una cosa
sperimentale.
  Ti avevo accennato ai grandi lag in presenza di molte entità in una stanza,
  questo accade perché Aarit raggruppa entità visivamente simili (feature che
  mi consigliasti ai tempi) solo appunto a livello visivo (cioè tante entità
  simili che fanno finta di essere ammucchiate in una sola voce visualizzata
  tramite il comando guarda) e non anche a livello fisico (cioè una sola entità
  che fa finta d'essere tante uguali tra loro: ciò migliorerebbe di molto sia
  cpu che ram).
  Ecco, ora Aarit ha anche il sistema per raggruppare fisicamente le entità,
  è un sistemone che ineluttabilmente porterà bachi con sé; per testarlo
  adeguatamente esiste appunto la sopracitata opzione use_visual_grouping che
  serve a disattivare il sistema di raggruppamento visivo per far emergere
  eventuali raggruppamenti fisici.
  C'è un libro nell'area limbo che contiene al suo interno 1000 monete per tipo,
  l'ho usato per i test su tale parte
  C'è da notare che se si resetta una quantità maggiore di 1 di entità che
  contengono a loro volta qualche cosa le entità resettate non
verranno raggruppate
  per mantenere "il deposito" al loro interno, e non avere casini.

* Per par condicio ho creato l'opzione use_physical_grouping, che indica se
  attivare o meno il sistema sperimentale spiegato sopra.
  Quindi bisogna aggiungere l'opzione nel file di config ed impostarla a True
  (questo sia per la testing sia per la futura ufficiale).
  È doveroso indicare che tutte e due le opzioni disattivate non sono per nulla
  auspicabili poiché porterebbero il Mud ad uno stato di mesi fa: ovvero
  l'inesistenza di qualsiasi tipo di raggruppamento con listoni semi infiniti
  d'entità mostrati tramite il comando look.

- Tutto il sistema di raggruppamento fisico cosa comporta? Comporta una
  modifica a vari gamescripts, ed in particolare al metodo from_location.
  Ho cercato di rendere il tutto il più automatico possibile ma non ci sono
  riuscito al 100%.
  La chiamata che era genericamente:
  entity.from_location()
  ora è diventata:
  entity = original_entity.from_location(1)
  Praticamente original_entity è l'entità originale con quantità N, tuttavia
  dopo la chiamata del metodo, che passa il parametro 1 (indicante la quantità
  voluta da togliere alla locazione):
  - entity sarà un'entità uguale a original_entity ma con quantità 1
  - original_entity è l'entità precedente ma con quantità N-1
  C'è un'altro caso utile nei gamescripts: ovvero quando si vuole ricavare dalla
  locazione tutto il quantitativo di original_entity:
  entity = original_entity.from_location(original_entity.quantity)
  Scrivo qui un po' di esempi presi dai gamescript per far capire meglio come
  convertirli:
DA:
    entity.act("$n fa rotolare $N", TO.OTHERS, dice)
    dice.from_location()
    dice.to_location(room)
    return True
A:
    entity.act("$n fa rotolare $N", TO.OTHERS, dice)
    dice = dice.from_location(1)
    dice.to_location(room)
    return True
In questo caso è facile, si vuole far rotolare un dado per volta, quindi da
  un quantitativo sconosciuto di dadi ne pesco uno tramite la from_location.
  C'è inoltre da notare che non c'è bisogno di differenziare i nomi delle
  variabili come ho fatto sopra con original_entity ed entity (per scopo
  puramente propedeutico).
  Altro esempio:
DA:
    for content in container.iter_contains(use_reversed=True):
        content.from_location()
        content.to_location(room_here)
    container.act("Vomiti tutto il tuo contenuto.", TO.ENTITY)
A:
    for content in container.iter_contains(use_reversed=True):
        content = content.from_location(content.quantity)
        content.to_location(room_here)
    container.act("Vomiti tutto il tuo contenuto.", TO.ENTITY)
In quest'altro caso si vuole spostare da una locazione ad un'altra tutto il
  quantitativo, quindi si passa la quantity totale del contenuto.
  Alla fin fine quello che basta è comprendere quale quantità inserire
  (tipicamente 1 o tutti).
ALTRO ANCORA, DA:
            entity.act("\nIl fiore si contrae in uno spasmo e poi ti
sputa lontano.\n", TO.ENTITY)
            entity.act("Anche $n viene sputato assieme a te.", TO.OTHERS)
            entity.from_location()
            entity.to_location(destination_room, use_look = True)
A:
            entity.act("\nIl fiore si contrae in uno spasmo e poi ti
sputa lontano.\n", TO.ENTITY)
            entity.act("Anche $n viene sputato assieme a te.", TO.OTHERS)
            entity = entity.from_location(entity.quantity)
            entity.to_location(destination_room, use_look = True)
Questo potrebbe spiazzare, perché nonostante anche qui bisogni togliere tutto
  il quantitativo di entità (per lo meno, per come lo vedo io il fiore funziona
  "a gruppi") in questo caso il codice non si trova in un ciclo for (che è
  tipico di una rimozione di tutto il quantitativo), a volte bisogna fare
  attenzione.

- Attenzione che alcuni mob non vengono ammucchiati assieme perché sono uguali
  in tutto tranne che per la mano destra e quella sinistra, ciò potrebbe portare
  a confusione quindi vi avviso.
  Come go detto sopra comunque questo lo si può osservare solo se si avvia il
  gioco con l'opzione use_visual_grouping = False

- Se si vuole ricavare, in un gamescript, una determinata quantità in un mucchio
  fisico, senza volerne cambiare la locazione, allora bisogna fare così:
  entity = original_entity.split(1)
  l'1 è la quantità voluta, funziona come la from_location creando ex novo
  un'altra entità di quantità voluta (e rimuovendo la stessa quantità
dall'altra).
  Questo metodo è da utilizzare soprattutto quando si ricavano le entità tramite
  la find_entity oppure con altra metodologia (un ciclo sugli items del database
  ad esempio).
  Cmq riguardo a questo punto è una cosa da sapere per il futuro, perché ho
  intenzione di passarmi tutti i gamescript alla ricerca di bachi a riguardo,
  quindi non c'è bisogno di fare nulla.

- Sarebbe interessante poi da leggere il commento del metodo group_entities
  nel modulo entity.py che indica sostanzialmente di evitare i comandi look
  o inventory nei gamescript durante la manipolazione delle entità e di
  eseguirli invece solo alla fine di tutte le istruzioni (ed evitando la
  chiamata di eventuali deferred che sarebbero molto subdole a riguardo)

- Questa sistema di ammucchiamento fisico diminuisce di qualche mega l'utilizzo
  della ram già subito all'avvio (114 mega invece di 124 nei miei test, il 9%)

- D'ora in poi, dati i potenziali casini che il sistema dell'ammucchiamento
  fisico delle entità può portare al codice, tutti i nuovi gamescripts, una
  volta considerati abbastanza maturi da essere usati, dovranno essere inviati
  a me per "certificarli"
  Tali casini sono essenzialmente, facendo delle ipotesi esemplificative, il
  comando get che prende tutto il mucchio intero, oppure il comando wear che
  veste il mucchio intero nella locazione voluta invece che una singola parte,
  altro esempio ancora un mucchio di porte tutte uguali che vengono inserite
  sugli stipiti tutte assieme (gli stipiti sono concettualmente creati per
  avere una sola entità per volta quindi sarebbe un bacaccio!).
  Insomma, niente crash di sorta, ma invece una serie di bachi a volte subdoli
  da rivelare.
  I gamescript saranno sicuramente a rischio perchè mancano di sicuro dei metodi
  di split.

- Ho inserito alcune migliorie d'interfaccia sotto il menù: ho aggiunto il
  bottone ufficiale di facebook e l'importo editabile per le donazioni paypal.
  In realtà quest'ultimo l'importo non viene aggiornato nella pagina successiva,
  ma è giusto per far notare che non è che vi sia bisogno di donare chissacché.

- Aggiunti alcuni link nella relativa pagina: +add, elfoladro.it e
aarit su facebook

- Altra miglioria lato interfaccia è il voto up/down per le news, lo noterete
  subito. È data la possibilità al giocatore di cambiare idea anche dopo mesi
  e modificare il proprio voto da pollice sù a giù o viceversa, oppure di
  rimuoverlo del tutto.
  Tutte le informazioni del voto vengono salvate nel file dat delle news,
  quindi d'ora in poi i file dat delle news DEVONO essere considerati alla
  stregua dei file di account di quelli dei player (visto che anche loro
  vengono salvati durante lo shutdown)
  C'è inoltre da tenere bene in mente che se un file di news viene modificato
  a mano mentre il Mud è ancora funzionante un suo shutdown con persistenze
  sovrascriverà qualsiasi modifica effettuata.

- Ho scambiato i colori della direzione di sud-ovest con quello di nort-ovest
  e viceversa, se per caso si foste creato delle stanze con il colore legato
  alle uscite bisognerà modificare di conseguenza.

- Ho creato 10 icone rappresentanti le 10 direzioni del gioco; non
sono il massimo,
  se qualcuno vuole metterci mano si faccia pure avanti con selvatici
esperimenti.
  Preferibilmente il colore principale rappresentante la direzione deve
  rimanere quello.
  L'alternativa è invece quella di non avere nulla come icone cardinali, nel
  qual caso facciano tanto orripilare.

- Aggiunte l'etichette Icon e IconNight per le uscite
  Aggiunte altresì l'etichette OpenIcon e OpenIconNight per la
struttura DoorType
  In pratica l'ordine di precedenza di un'icona relativa un'uscita è questa:
  icona della porta chiusa se non segreta (prende l'icona dell'entità porta)
  icona della porta aperta (prende l'icona in DoorType: OpenIcon o
OpenIconNight)
  icona dell'uscita (Icon o IconNight)
  icona del simbolo cardinale, quello di default (quelli descritti nel
punti precedente)
  Inoltre, poiché viene inserita un'icona di default per tutte le porte sia
  chiuse che aperte, a meno che la porta non venga scardinata non si vedrà
  l'eventuale icona della relativa uscita.
  C'è da aggiornare il manuale a riguardo.

- Premettendo che Le MoneyType le ho inserite nella release 103 ho modificato
  concettualmente un'aspetto di esse: il valore delle monete tra una tipologia
  base ad un'altra varia di 10 in 10 per tutte quante.
  Quindi relativamente alla moneta di platino, ora mithril, che invece eseguiva
  un salto di 100 bisogna cambiarne il CopperValue da 10000 a 1000.
  Tutto ciò per rendere più semplice il sistema per i giocatori.

- Nella cartella aarit\www\icon\money ci sono 4 icone per le rispettive human
  money_type già esistenti, da inserire come Icon nei file di dat già esistenti

- Aggiunta l'etichetta struttura Shop, vediamo subito un esempio e poi la
  capillare descrizione delle etichette:
Shop:
        Comment: bla bla bla
        Types: SHOP.NORMAL
        ProtoLocations: deadcity_room_strada-ns-curva_01
        ProtoLocations: deadcity_room_strada-ns-curva_02
        Buyables: limbo_item_porta 150% 3 200
        Buyables: limbo_item_portal 90% 2 300
        Sellables: ENTITYPE.DOOR 50% 200%
End
Tale etichetta-struttura va inserita come sottostruttura dentro un item o mob
prototipo, quindi nella documentazione l'etichetta Shop ci sarà sia nella pagina
dei mob che in quella degli item (volendo si può inserire una sottostruttura
Shop anche ai giocatori ma questa è una "feature fantasma" e non serve dirlo).

Beh l'etichetta Comment è ovvia e ben conosciuta quindi passiamo a quella di
Types: essa indica la tipologia del negozio (NORMAL, REPAIR o RECHARGE), per
ora la sola tipologia implementata è la NORMAL, l'etichetta non è obbligatoria,
omettendola verrà supposto che il negozio sia un NORMAL.

ProtoLocations: etichetta facoltativa che è una lista dei codici prototipo delle
locazioni in cui il negoziante effettuerà la vendita delle proprie mercanzie.
Attenzione che se sono state resettate più stanze nel gioco con il prototipo
indicato in ProtoLocations tutte tali stanze istanziate sono validi locazioni
per negoziare.
Non è detto che la locazione debba essere per forza una stanza, può essere un
codice prototipo di un mob o di un item (o di un giocatore), in quel caso solo
se il negoziante si trova nell'inventario di tale entità effettuerà la
negoziazione.

Buyables: è l'unica etichetta obbligatoria.
Il primo valore indica quale entità, mob o item, viene messa in vendita dal
negoziante. (comando buy da parte del player)
Il secondo valore indica a quale percentuale il negoziante venderà l'entità
rispetto al suo Value
Il terzo valore indica la quantità del prodotto in magazzino, essendo appunto
una quantità non può avere valori minori o uguali a zero.
Il quarto valore indica quanti minuti reali servono prima che il prodotto venga
rifornito nel magazzino una volta che venga terminato. Per creare un magazzino
pressoché infinito basta inserire come valore lo 0. Se invece viene inserito
il -1 questi viene convertito nel RepopTime dell'area in cui si trova il
negoziante nel momento del bisogno di nuova mercanzia.

Sellables: etichetta facoltativa, indica con quali tipologie di entità il
negoziante comprerà (comando sell da parte del player).
Il primo valore indica difatti la tipologia d'entità che il negoziante accetterà
in vendita.
Il secondo valore indica il fattore di guadagno, in percentuale, che il
negoziante calcolerà sul Value dell'entità a lui venduta.
Il terzo valore indica quale percentuale di buy verrà applicato all'oggetto
se eventualmente rimesso in vendita.
Quindi se, come nell'esempio, un giocatore cercherà di vendere una porta questa
verrà comprata a metà prezzo. Se il giocatore cercherà di vendere qualsiasi
altra tipologia il negoziante non la accetterà.
Se si vuole che il negoziante compri qualsiasi tipo di entità allora bisogna
impostare un solo Sellables in questo modo:
Sellables: ENTITYPE.NONE 50% 100%
Se invece non viene definita nessuna etichetta di Sellables il negoziante
eviterà a priori di comprare qualsiasi cosa.
Nel qual caso che il giocatore venda oggetti con lo stesso prototype questi
non diverranno nuovi oggetti nella list ma aumenterà il numero di magazzino
di quello già esistente, attenzione che ho detto prototype uguale, quindi anche
se i due oggetti sono in realtà molto differenti tra di loro vengono considerati
come uguali.
Altra cosa da considerare è che gli oggetti venduti finiscono
nell'inventario del
negoziante, quindi egli non rimetterà in vendita perchè l'oggetto verrà per
comodità estratto invece di pesargli addosso.

Da aggiungere nel manuale in pagina a parte, non è una entitype e neppure
una struct!

- Tra l'altro colgo l'occasione per indicare che il sistema delle struct è
  morto, quindi la pagina che fa da indice alle due strutture di etichetta
  che sono a parte bisogna toglierla e bisogna invece linkare le pagine di
  ognuna delle due strutture dentro item e mob, visto che sono etichette
  (Walker e ExtractTimeout) che si trovano sia in uno che nell'altro.

- Aggiunto il comando list, buy, sell e money

- Aggiunti i seguenti gamescript trigger:
def before_list(client, dealer):
def after_list(client, dealer):
client è il cliente che chiede la lista della mercanzia
dealer è il negoziante che possiede la mercanzia

def before_buy(client, dealer, purchase, quantity):
def after_buy(client, dealer, purchase, quantity):
Trigger che si attivano, rispettivamente, prima e dopo che una entità abbia
comprato qualcosa.
client: entità che sta comprando qualche cosa
dealer: negoziante che sta vendendo qualche cosa
bought: entità che si vuole comprare o già comprata
quantity: quantità comprata da dealer
Attenzione: i trigger si attivano sul negoziante, cioè dealer.

def before_bought(client, dealer, purchase, quantity):
def after_bought(client, dealer, purchase, quantity):
Stessa cosa dei trigger del punto precedente, solo che il punto di vista è
purchase e non dealer, quindi i trigger vanno inseriti nel gamescript di
purchase.

def before_sell(client, dealer, target, quantity):
def after_sell(client, dealer, target, quantity):
Trigger che si attivano, rispettivamente, prima e dopo che una entità abbia
comprato qualcosa.
client: entità che sta comprando qualche cosa
dealer: negoziante che sta vendendo qualche cosa
bought: entità che si vuole comprare o già comprata
quantity: quantità venduta a dealer
Attenzione: i trigger si attivano sul negoziante, cioè dealer.
C'è da tenere conto inoltre che target di before_sell è l'entità originale,
quella con quantità totale, mentre in after_sell target è un'altra entità,
quella ormai venduta, con la quantity voluta.

def before_sold(client, dealer, target, quantity):
def after_sold(client, dealer, target, quantity):
Stessa cosa dei trigger del punto precedente, solo che il punto di vista è
target e non dealer, quindi i trigger vanno inseriti nel gamescript di
target.

def before_money(entity):
def after_money(entity):
entity è l'entità che ha appena digitato il comando di money, il trigger
potrebbe servire per falsare la visualizzazione della propria ricchezza in
determinate stanze

def before_flee(entity, opponent, dir, portal):
def after_flee(entity, opponent, dir, portal):
entity è colui che fugge
opponent è l'avversario da cui si fugge
dir è la direzione in cui si fugge, se si utilizza un portale per
fuggire questo parametro viene passato a None
portal è il portale da cui si fugge, se si utilizza una direzione per
fuggire questo parametro viene passato a None

def before_supply(supply):
def after_supply(supply):
I trigger vanno inseriti nell'entità negoziante, cioè quella con etichetta Shop
o in una stanza qualsiasi
supply è l'oggetto che contiene tutte le informazioni per il rifornimento:
supply.entity():  entità da rifornire
supply.dealer():  negoziante a cui rifornire
supply.timer: tempo mancante al rifornimento, questo sarà sicuramente
zero o meno
durante il trigger ma può essere modificato in maniera tale da
allungare il tempo
di rifornimento, ricordo che è in minuti reali
Da notare il fatto che vi si acceda all'informazione di alcuni attributi
tramite parentesi.

def before_express_aggressiveness(express_aggressiveness):
def after_express_aggressiveness(express_aggressiveness):
I trigger vanno inseriti nell'entità contenente l'etichetta Aggressivenesses
o in una stanza qualsiasi
express_aggressiveness è l'oggetto che contiene tutte le informazioni per
esprimere aggressività nei confronti di un'entità prima di attaccarla.
express_aggressiveness.aggressor(): aggressore che invia i messaggi di minaccia
express_aggressiveness.victim(): vittima dei messaggi di minaccia e
prima o poi dell'attacco
express_aggressiveness.timer: timer che indica a quanti secondi reali attivare
il messaggio di minaccia. Nel before_express_aggressiveness è 0 o meno, e si può
modificare a piacere, se poi viene ritornato True nello script l'invio del
messaggio non avverrà spostando di tot l'esecuzione.
Nell'after_express_aggressiveness
invece il valore timer potrebbe essere differente da 0 o meno, dipende
se l'invio
dell'espressione è stata rinnovata oppure se vi è stato finalmente l'attacco.
express_aggressiveness.remaining_tries: numero di tentativi massimi prima che
un attacco avvenga, meno tentativi vi sono più probabilità di attacco esistono,
si può modificare il valore a piacere.
Da notare il fatto che vi si acceda all'informazione di alcuni attributi
tramite parentesi.
Ritengo che sia necessaria la conoscenza del metodo execute della classe
ExpressAggressiveness per poter gestire al meglio questo trigger.

def before_digestion(digestion):
def after_digestion(digestion):
I trigger vanno inseriti nell'entità che deve digerire qualche cosa o in
una stanza qualsiasi.
digestion è l'oggetto che contiene tutte le informazioni per poter effettuare
la posposta digestione.
digestion.entity(): è l'entità che sta digerendo
digestion.ingested(): è l'entità che sta per essere digerita
digestion.timer: rappresenta il numero di minuti reali per questa digestione,
sia nella before che nella after è atteso a 0 o meno; può essere impostato ad
un valore differente nella before ritornando poi dal trigger tramite True sicché
da saltare la vera esecuzione della digestione e allungare il tempo della
digestione.

- Risolto (forse!) il famoso baco del look click, da testare!! zamp! zamp!

- Aggiunta l'opzione di account LESS_COLORS, che serve a diminuire il numero
  di colori nell'output di Aarit, questo perché suppongo che vi sia una fetta
  d'utenza a cui dia fastidio i troppi colori di Aarit (mi pare vi fosse
  stata una segnalazione a riguardo tempo fa); et voilà, tutti contenti!

- C'è da ritestare il comando dig che l'ho martoriato un po', anche il comando
  flee essendo importante per l'incolumità dei personaggi è da ritestare
  adeguatamente (a proposito c'è la stanza dei fiori, con porta barbamamma,
  che è un luogo ottimale per i test di flee, specie nelle casistiche in cui si
  combatte con barbamamma e si cerca di fuggire: lei bloccherà la strada)
  In generale quasi tutti i comandi, tranne quelli sensoriali, sono stati
  spulciati aggiungendo colorazione ai verbi d'azione come controbilanciamento
  della feature LESS_COLORS :P

- La pagina test_inputs è nuovamente funzionante, per un baco non andava

- Corretto un problema nella pagina delle descrizioni, problema segnalato
  da Alagor nella piazzetta, le descrizioni venivano salvate correttamente
  ma non vi era nessun feedback adeguato lato client

- Non dovrebbe essere più possibile sentire i canali rpg quando l'entità
  ascoltatrice sta dormendo, non ho potuto testarlo per via della difficoltà
  di avere due player in multiplayer

- Relativamente al sistema di repop devo segnalare che c'è un baco conosciuto
  per colpa del quale non vengono repoppate le porte, cercherò di correggerlo
  nella prossima release

- Aggiunta l'opzione di compact, che serve a visualizzare l'output più compatto
  (personalmente a menon piace per nulla ma nei vecchi mud esisteva, magari a
  qualcuno piace)

- Bisogna convertire tutti i log.msg nei gamescript in log.bug e d'ora in poi
  bisogna utilizzare log.bug per loggare i bachi nei gamescript

- Ora non è più possibile inviare i comandi nella posizione a loro non consona,
  come ad esempio inviare il say mentre stai dormendo

- Ora l'etichetta Value serve ad indicare il valore base, valore utilizzato poi
  a calcolare il costo effettivo da parte dei negozianti, sia per item che
  per mob.
  Tuttavia per i mob vi è anche un altro significato di Value, ovvero quanti
  soldi porteranno con sé.
  I soldi vengono inseriti durante il reset o il repop.
  Ciò significa che i giocatori hanno la possibilità di ammucchiar denaro
  per utilizzarlo poi per comprare oggetti.
  Per evitare che Value abbia questo doppio significato esiste la flag
  FLAG.VALUE_IS_ONLY_COST
  da utilizzare per mob venduti in un negozio che però non debbano lasciare
  per terra della moneta.
  Attenzione che ho visto un mob con un value altissimo, troppo esagerato.

- Ho inserito un sistema di quantità ad alcuni comandi, ovvero se si scrive
  get 5 penna
  l'entità potrà raccogliere, se possibile, 5 unità di penne.
  Inoltre si può anche scrivere
  get all.penna
  get tutte.penna
  etc
  e raccoglierà il totale delle penna trovate nella locazione
  I comandi a cui ho implementato questo sistema di quantità sono:
  buy
  sell
  get
  drop
  put: quindi anche give
  Volutamente non è stato implementato per i comandi:
  seed
  eat: per ora sembra eccessivo da implementare la cosa
  drink: idem come sopra
  Se dovesse risultare che manchino altri comandi a cui sia possibile aggiungere
  questo sistema me lo si faccia sapere.

- Ho aggiunto la flag STAY_ON_DEATH che serve a far rimanere entità, in possesso
  dai soli player, nel loro inventario anche se questi muoiono.

- Aggiunta l'etichetta, per mob e per item, Corpse e CorpseNight.
  Esse servono ad indicare il codice proto, di item o mob, relativo al cadavere
  da utilizzare al posto di quello di default della razza e del sesso.
  Sì, lo ribadisco: si può utilizzare anche un prototipo di mob,
questo significa
  che una volta morto un mob questo è come se rinascerebbe... e così a catena,
  dipende dal mob successivo.
  È da aggiornare quindi il manuale.

- Ora i social "troppo pesanti" sulle entità attiveranno il fight (relativamente
  a ciò non ricordo bene ma vi erano basse o nulle possibilità che la cosa
  scattasse fino a che non implementerò il sistema delle reputazioni)

- Aggiunta la flag FLAG.EXTRACT_ON_QUIT come da accordi, a questo
punto l'eventuale
  extract dell'oggetto di quest potrebbe triggerare il reset della quest stessa,
  comodo!

- Aggiunto il tag di act $k e $K, il primo ritorna la chiave di $n, mentre $K
  quella di $N, quindi se $N è un lupo probabilmente una delle sue parole chiavi
  sarà la parola lupo, $K ritornerà lupo, oppure 2.lupo se necessario.
  Serve soprattutto nei comandi con obiettivo dinamico, sotto v'è un esempio.
  Aggiornare il manuale relativamente la pagina dei tag di act.

- Aggiunta la FLAG.AGGRESSIVE che indica se un mob attaccherà un giocatore.
  L'entità attacherà in questi casi:
  se la vittima è un pg e se ha un livello minore o uguale al livello
dell'aggressore+1
  se l'attaccante è carnivoro e la vittima erbivora (cibo)
  se l'attaccante è carnivoro e la vittima è carnivora (territorio)
  Ricordo che le flag per indicare i carnivori e gli erbivori sono:
  FLAG.CARNIVOROUS e FLAG.HERBIVORE.
  Si può evitare di far attaccare subitamente utilizzando l'etichetta
Aggressivenesses.
  Tale etichetta è una lista di stringhe che possono essere degli echo
  o degli input inviati al giocatore, quindi ecco un esempio:
  Aggressivenesses: Senti un brontolio lontano
  Aggressivenesses: puke $k
  Aggressivenesses: emote sta brontolando di brutto! ahi! ahi!
  Quindi dopo che la vittima sarà entrata nella stanza il mob invierà a caso,
  ogni 3-6 secondi uno di questi echo o input prima che l'aggressore attacchi.
  Maggiore è il numero dei messaggi è minori sono le possibilità d'attacco,
  comunque almeno un messaggio d'avviso viene sempre inviato dando così la
  possibilità al giocatore di passare sotto al naso all'entità aggressiva
  (cosa che invece non deve capitare in mancanza del messaggio Aggressivenesses)
  L'etichetta Aggressivenesses funziona anche sugli oggetti, in questo caso gli
  oggetti invieranno sempre i messaggi di minaccia senza mai attaccare.
  C'è quindi da inserire questa flag, ed eventualmente anche l'etichetta, ai mob
  qui e là.
  Da aggiornare il manuale a riguardo.

- Ho aggiunto un po' di colori alla relativa lista , per lo più metallici:
  copper, brass, quartz, manablue... ed altri
  I codici dei colori non sono più legati ai 147 colori web ma se ne possono
  aggiungere quanti se ne vuole, quindi se dovesse mancare un colore
particolare,
  differente da tutti gli altri, potrebbe essere utile inserirlo.

- Le porte ora si possono inserire sui cardini tramite il comando
  put <porta> <direzione>

- Implementata la prima versione dell'autoreload dinamico, automatico,
  bellissimo e... bacoso(tm).
  In pratica ad ogni modifica di dato (proto o area) questo viene ricaricato
  nel database senza dover per forza riavviare il mud-server.
  Cosa succede quindi?
  Praticamente non molto nel gioco, visto che il gioco è fatto di istanze che
  derivano dai prototipi, quindi per forzare che un'istanza venga creata
  dal nuovo prototipo bisogna per esempio:
  - estrarla con il comando extract ed attendere il relativo repop
  - utilizzare il comando ocreate o mcreate per ricavare l'istanza
basata sul nuovo prototipo
  - non fare nulla che tanto prima o poi le cose si sistemano da sole
(mob uccisi,
    repop temporali, persistenze rimosse, cavallette...)
  Il sistema è decisamente sperimentale e da prendere con le pinze.
  Ad ogni ricaricamento di dato viene inviato un messaggio di log
taggato [autoreload].
  Purtroppo devo già constatare che non sono riuscito a fare i
RoomResets dinamici,
  ciò significa che se in un'area un reset viene modificato l'entità estratta
  in gioco non utilizzerà il nuovo reset ma quello vecchio, obbligando ad un
  riavvio per sistemare le cose.

- Preparare una o più room rappresentanti una banca e un mob bancario
da piazzare in qualche città o villaggio,
  che nella prossima release creo il sistema bancario per depositare
le somme conquistate
  dai giocatori


================================================================================
Rella 107
08/02/12

* Bisogna aggiugere l'opzione di config leveling_restore_points impostata di
  default a False, tale opzione serve ad eventuali altre tipologie di Mud a
  indicare di far recuperare completamente i punteggi di vita, mana e vigore
  ad ogni nuovo livello guadagnato dai giocatori.

* Bisogna rimuovere l'opzione output_end_tag dal file config.ini

* Bisogna aggiungere l'opzione di config news_to_send, da inserire nella
  sezione [SERVER] e da impostare con valore 5, serve ad indicare quante
  news vengono lette o inviate per volta nella homepage

* Ho rinominato l'opzione di config da max_compatibility_msg_len in
  max_feedback_len

* L'opzione di config min_repop_time deve essere impostata a 0 e non a 1,
  perché le aree con etichetta RepopTime impostata a 0 da questa rella in poi
  non effettueranno repop.
  Da aggiornare il manuale riguardo l'etichetta dell'area, che tra l'altro
  trovo mancante nella pagina apposita.

* Da rimuovere l'opzione dal file config.ini use_google_analytics.
  Per utilizzare o meno le statistiche di google analytics ci si basa sulla
  presenza o meno dell'opzione, ora facoltativa (come gift_on_enter ma questo
  lo era già), google_analytics_ua.

* Bisogna rinominare nel file config.ini la sezione [SQUARE] in [SITE],
  inoltre bisogna spostare le seguenti opzioni:
  port
  site_address
  allow_robots
  google_analytics_ua
  max_google_translate
  max_feedback_len
  sending_interval
  nella novella sezione [SITE]

* Bisogna creare il file calendar.dat nella cartella data in cui vi saranno le
  informazioni base relative alla data rpg del gioco e che vengono caricate
  all'avvio e salvata allo shutdown del gioco al posto delle relative opzioni
  nel file config.ini.
  Bisogna quindi aprire questo nuovo file testuale ed inserirvi in una riga
  sola queste informazioni intervallate da spazi:
  minute hour day month year
  ovvero bisogna andare al file config.ini e sostituire minute con il valore
  ivi trovato, hour con il valore ivi trovato... etc etc.
  Quindi il risultato sarà qualche cosa del genere:
  23 4 30 MONTH.FIGHT 3009
  Fatto questo si possono rimuovere le opzioni dal file di config di:
  minute
  hour
  day
  month
  year

- Perchè tutto 'sto bordello riguardo il file di config?
  L'idea ultima è quella di creare una struttura generica utilizzabile per una
  pagina web su cui sia possibilie manipolare e salvare i valori di config senza
  dover riavviare il mud.
  Tale pagina è la config_options.html accessibile dal menù di admin.
  La pagina è visualizzabile da parte di tutti gli amministratori ma i valori
  sono modificabili solo se si possiede la trust IMPLEMENTOR.

- Ora il file di config.ini dovrebbe mantenere le opzioni nell'ordine identico
  a quello delle opzioni visualizzate nella pagina config_options.html, in tale
  maniera sarà possibile confrontare due file di config per vederne le
  differenze

* Bisogna modificare il nome delle etichette da WalkerStruct in Walker
  e da DeadTimeStruct in ExtractTimeout.
  Le entità estratte con tale etichetta repoppano comunque.
  Da aggiornare il manuale a riguardo.

- Se per favore mi copi e invii le righe che si trova entro le
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
  all'avvio mi faresti un favore, che son cose che funzionano sotto *unix-like
  systems.

- Aggiunto un messaggio di avviso nel wield quando si impugnano armi di livello
  più alto del proprio, un avviso simile c'è anche quando il giocatore inizia
  il combattimento con tali armi

- Ho rifatto la funzione che calcola il tempo di un turno di combattimento,
  praticamente ora ho dimezzato il peso della speed sul tempo ed ho inserito
  la variante del livello, segue sostanzialmente queste tre regole:
- Il tempo varia tra i 5.3 secondi ed un minimo (modifier a parte) di 1 secondo
- Ogni dieci livelli l'attacco diminuisce di un decimo di secondo,
quindi al livello 200 vi sarà una diminuizione di 2 secondi
- Tramite logaritmo/2 se la speed è 100 c'è una diminuzione di 2.3
secondi, se la speed è 10 di 1.1 secondi
  Poi c'è il modificatore che in alcuni casi (clumsy hit) va a
raddoppiare il tempo.

- Aggiunta l'informazione Livello nella tooltip (I)dentificativi del look
  sulle entità
  (modifica già inviata in un fix del comando look)

- Aggiunti i messaggi di debug sulla durata dei turni e sul danno effettuato,
  tali messaggi vengono visualizzati dai soli admin mentre combattono oppure
  snoopando i mob.
  Se non è chiaro qualche cosa di tutto quel marasma fammi sapere.

- Diminuito il danno a mani nude

- Aumentato il danno effettuato con le armi, sia tramite la forza, che tramite
  un bonus (o un malus) proporzionale alla differenza dei livelli dei due
  combattenti; inoltre ho diminuito il malus delle armi che hanno un livello
  minore del personaggio e vengono comunque utilizzate

- Ora solo coloro che hanno un'arma in mano potranno deflettere i colpi

- Ho diminuito la probabilità di effettuare parate, tuttavia poiché il check
  della parata si basa sulle tempistiche di durata del turno dei due
combattenti,
  entità in lotta con valori di speed e livello simili o identici avranno quindi
  durata di turno di combattimento simile o identico, propinando durante il
  combattimento una listona semi-infinita di parate o tentativi delle stesse.
  Ho diminuito la probabilità di questo problema, ma non so quanto la cosa mi
  soddisfi, forse farla time-dipendente non è la cosa più corretta.

- Adesso è possibile rimuovere tutte le persistenze cancellando la cartella
  persistence invece che solamente le tre directory al suo interno e il mud
  si caricherà comunque senza dare errore.
  Un danno enorme in un'unica mossa! Huzza!

- Ho creato un utilissimo sistema che allo shutdown controlla la validità di
  tutti i riferimenti dei dati e se trova qualche errore inserisce il tutto
  nella cartella wrong, tale cartella verrà suddivisa per ora di shutdown e
  dentro vi sarà il file errors.log (con tutti gli errori), il resto è una
  copia dei file dat salvati per debug.
  Gli stessi dati errati verranno cmq salvati, nella persistenza quindi non si
  dovrà fare nessun conguaglio.

- Ho rifatto il sistema dei repop in maniera tale che le entità repoppino nei
  contenitori, cosa che prima non accadeva.
  Riguardo a quel discorso del permettere o meno alle entità di invadere le aree
  tramire reset (o repop) successivi posso dire che all'attuale stato dell'arte
  sono favorevole alla cosa. Da tale riflessione ho quindi permesso di base il
  repop alle entità che si spostano dalla loro locazione di reset originaria:
  - il mob viene resettato
  - cammina verso est
  - dopo tot secondi viene repoppato
  - cammina verso est
  - dopo tot secondi viene repoppato
  - e così via...
  Per evitare questo meccanismo bisogna utilizzare la flag
  FLAG.REPOP_ONLY_ON_EXTRACT
  che permette di far repoppare SOLO se il mob viene ucciso o l'item rimosso
  dal gioco.

- Ho aggiunto la flag FLAG.NO_CHECK_STATUS che indica di NON resettare o
  repoppare lo stato delle flag di door o di container
  Prima veniva utilizzata la flag NO_REPOP per questo, quest'ultima ora esiste
  solo per indicare di non effettuare un repop.
  Da tenere conto che la flag NO_CHECK_STATUS viene utilizzata anche per
  indicare che viene eseguito il repop di stato delle cose vestite (che
  potrebbero essere state rimosse e tenute in inventario oppure viceversa,
  vestite al posto di tenerle in inventario)

- Ho inoltre aggiunto la FLAG.REPOP_ON_COORDS_AND_CODE che serve a far repoppare
  l'entità mancante nella locazione originaria solo se quest'ultima
non sia stata
  rimpiazzata da un altro room reset, cioè che abbia ancora le stesse coordinate
  e codice di room.
  Cio significa che per esempio:
  * Un contadino viene repoppato nei campi coltivati
  * Il contadino si sposta
  * Inizia il conteggio repop per il prossimo contadino
  * Ma prima che il repop si attivi avviene un reset dei campi coltivati con dei
    campi innevati
  * Se il contadino NON avrò la flag REPOP_ON_COORDS_AND_CODE verrà ripoppato
    comunque nella locazione campi innevati, perchè controlla solo le coordinate
  * Se invece il contadino ha la flag REPOP_ON_COORDS_AND_CODE non ripopperà
  C'è da tenere presente che qui ci potrebbe essere un problema a livello di
  reboot del mud con relative persistenze, facciamo questo esempio:
  * Un contadino viene repoppato nei campi coltivati
  * Il contadino si sposta
  * Inizia il conteggio repop per il prossimo contadino
  * Ma prima che il repop si attivi avviene un reset dei campi coltivati con dei
    campi innevati
  * E sempre prima che il repop scatti si chiude il mud salvando le persistenze
  * Al riavvio del mud viene controllo se c'è bisogno di riavviare alcuni
    conteggi di repop
  * Se il contadino ha la flag REPOP_ON_COORDS_AND_CODE non è possibile
    ricavare la room online campi coltivati, poiché non è più online e quindi
    il repop non viene attivato
  * Se invece il contadino non ha la flag REPOP_ON_COORDS_AND_CODE è possibile
    dare in pasto per il repop la locazione campi innevati, visto che
il controllo
    è solo relativo alle coordinate

- Quindi ricapitolando:
  Un'entità che viene rimossa dalla sua locazione originaria di reset attiva un
  timer che al termine del quale controllerà se nella locazione originaria vi
  sia bisogno o meno di inserire nuovamente una entità uguale (il repop).
  Se tale entità però ha la flag NO_REPOP allora non attiverà nessun reset.
  Se tale entità invece ha la flag REPOP_ONLY_ON_EXTRACT allora
attiverà il timer
  solo quando verrà estratta dal gioco (particolarmente utile penso per le
  entità in wandering).
  Se non si vuole che un'entità porta o contenitore attivino un controllo
  di stato dopo un tot di tempo che venga manipolata con i comandi appositi,
  facendo ritornare allo stadio originario impostato nel reset, allora bisogna
  Utilizzare la flag NO_CHECK_STATUS.
  La stessa flag si utilizza per evitare che un controllo simile avvenga dopo
  un tot di tempo che un'entità si sia vestita o svestita di qualche cosa, senza
  tale flag di norma l'entità tornerebbe nel suo stadio di
"vestizione" originaria.
  E poi c'è la flag REPOP_ON_COORDS_AND_CODE che mi pare di aver già descritto
  abbastanza.

- Inoltre relativamente ai repop è meglio ricordare/precisare che:
  * Non importa se nella durata del timer l'entità da repoppare è stata rimossa
  dalla locazione di reset originaria e poi ivi rimessa, il comportamento
  di repop alla fine della durata del timer è identico a quello di un'entità
  che non si sia mossa dalla locazione originaria.
  * Il tempo di repop dipende dall'area in cui l'entità si trova, quindi
  riguardo alle entità in wandering con flag ONLY_ON_EXTRACT il tempo di repop
  è quello dell'area in cui vengono estratte e non quella di origine.
  * Le porte sui cardini, per vari problemi codiciosi, non effettuano un check
  status sulle cose vestite. Quindi se barbamamma avesse un cappello e fosse
  chiusa di reset se si eseguisse un force su di essa per rimuovere il cappello
  e aprirla il solo stato di apertura verrebbe ritrovato come differente da
  quello di reset e quindi impostato come chiusa. Il cappello
rimarrebbe rimosso.

- Riguardo ai trigger after_/close_ + open/close ho aggiunto un parametro
  aggiuntivo alla fine di tutti gli altri che serve solo nel qual caso che
  l'entità aperta o chiusa sia una porta.
  Il parametro rappresenta l'eventuale (non è detto che vi sia) porta dall'altra
  parte (visto che aarit supporta le doppie porte).
  Quindi l'interfacciamento al trigger diviene:
def <span style='color:royalblue;'>before_open</span>(entity, target,
reverse_target):<br>
def <span style='color:royalblue;'>after_open</span>(entity, target,
reverse_target):<br>
def <span style='color:royalblue;'>before_close</span>(entity, target,
reverse_target):<br>
def <span style='color:royalblue;'>after_close</span>(entity, target,
reverse_target):<br>
  In maniera simile vengono cambiati i trigger di bolt e unbolt, che diventano:
def <span style='color:royalblue;'>before_bolt</span>(entity, target,
reverse_target):<br>
def <span style='color:royalblue;'>after_bolt</span>(entity, target,
reverse_target):<br>
def <span style='color:royalblue;'>before_unbolt</span>(entity,
target, reverse_target):<br>
def <span style='color:royalblue;'>after_unbolt</span>(entity, target,
reverse_target):<br>
  (noto solo ora che nella documentazione mancano i trigger di bolt e unbolt)
  Altra modifica da effettuare è ai trigger di lock e unlock aggiungendo
  il parametro reserve_target PRIMA del parametro key, così:
def <span style='color:royalblue;'>before_lock</span>(entity, target,
reverse_target, key):<br>
def <span style='color:royalblue;'>after_lock</span>(entity, target,
reverse_target, key):<br>
  Bisogna fare attenzione alle dichiarazioni di trigger già esistenti nei
  gamescripts del mud ed aggiornarle al nuovo interfacciamento.

- Riguardo poi al problema delle ascii-art al file
citta-raminghe_item_registro-guardiano.dat
bisogna semplicemente aggiungervi dei punti ad inizio ogni riga

- Ho cambiato l'input esci (cioè il quit) in fine, questo perchè in futuro
  ci potrebbe essere il comando esci che servirà ad uscire da contenitori.
  Non credo che la cosa possa dare troppo fastidio ai giocatori immaginando
  che la maggiorparte di loro esca chiudendo la finestra, ma è solo un'ipotesi.

- Mi servirebbe un'entità bacheca e una foglio per il sistema delle auto-quest:
  il player guarda la bacheca e vi vede dei fogli, se li legge e li prende
  scatta per lui la quest.

- il fix per il no send inviato sulla wiki della 106 è l'ultima
  modifica che ho inserito nella 107


================================================================================
Rella 106
03/01/12

- Aggiunti i trigger
def before_get_from_location(entity, target, location):
def after_get_from_location(entity, target, location):
  Hanno lo stesso interfacciamento degli before_get e after_get ma vanno
  inseriti nell'entità rappresentante la location (cioè il contenitore o room
  chessia) da cui un giocatore o altra entità esegue il get.

- Aumentato il guadagno della life e degli altri punteggi nel tempo.
  Disattivato il guadagno di tali punteggi durante il combattimento.

- Corretto il problema del messaggio d'errore:
Il cadavere di una pixie mort$O giace qui.
  Ora il tag $O viene tradotto e non più visualizzato, tuttavia penso venga
  tradotto con il sesso del player che lo guarda, e non del sesso del morto.
  Se ciò accade bisogna convertire tutti i $O in $o dei cadaveri (le short)

- Bisogna cambiare tutte le occorrenze del tipo
if FLAG.EXTRACTED in egg.flags:
  in questo formato:
if egg.is_extracted():
  Ricordo che un'entità estratta è un mob, item o room che non è più in gioco,
  questo capita soprattutto quando l'entità viene uccisa; detto ciò tutti gli
  script che utilizzano una deferLater impostando nella funzione deferrata
  degli argomenti che sono delle entità abbisognano di questo check per
  controllare se siano o meno estratti.
  E' meglio ricordarsela bene questa cosa, magari inserendola nella
  documentazione relativa ai gamescripts.

- Corretto i social in maniera tale che ora i trigger sui mob si attivino.

- Ho inoltre fatto in modo che i trigger di social anche senza target valido
  si attivino su tutte le entità della stanza.
  Detto in altro modo in teoria solo il social:
  smile <nome_mob>
  attivava il trigger before_smile o after_smile sul mob, invece ora anche il
  semplice social:
  smile
  eseguito nella stanza del mob attiverà un qualsiasi trigger before_smile o
  after_smile presente su uno delle entità nella stanza (bisogna però
  ricordarsi che in questo caso il parametro dei trigger target è None).
  Aggiornare il manuale riguardo a questo punto, che è particolare.

- Riabilitato il who per i soli admin
  Aggiunto, nell'output del comando e per i soli admin, l'informazione del tipo
  di browser che utilizza il giocatore.

- Ho rimosso dal config.ini l'opzione periodical_check_time.

- Bisogna cancellare i file cpu_times.txt e connections.txt.txt nella cartella
  log, che d'ora in poi si chiameranno rispettivamente cpu_times.stats e
  connections.stats.

- Ho disattivato la rimozione-pulizia degli oggetti nei maze, per la pulizia
  della persistenza ci vuole proprio un sistema generale ad uopo che descriverò
  proprio qui sotto.

- Aggiunto il loop maintanance che in parte fa quello che faceva la game loop
  (log del file cpu_times.stat oltre che al backup giornaliero automatico)
  Oltre a queste cose ho aggiunto un sistema sperimentale di pulizia delle
  istanze degli oggetti (e solo gli oggetti per ora) del gioco, questo sarebbe
  il famoso sistema che dovrebbe far evitare di implodere la ram utilizzata
  dal mud tramite troppe persistenze.
  Praticamente ogni giorno alle 4 e 30 del mattino viene eseguito un ciclo e
  vengono controllate se le entità in gioco si trovano dove dovrebbero
  (informazione ricavata dai reset).

  Attualmente purtroppo non vi è ancora nesun check relativamente al numero,
  quindi se una spada dovrebbe resettare in quella locazione, anche se ve ne
  sono 9 non verranno rimosse le altre 8.
  Non vengono inoltre rimossi oggetti addosso ai giocatori o appartenenti ai
  giocatori (raccolti e poi droppati per esempio).

  Tuttavia nei miei test ho potuto constatare che tra tutte le entità
che vengono
  estratte dal gioco ci sono anche, per esempio, l'item foglia, che ha un
  behaviour wandering, non trovando l'oggetto dove dovrebbe questo viene
  rimosso... poco male, dovrebbe esservi il repop a fare il lavoro di rimessa
  in gioco, no?
  Altre entità che vengono rimosse e forse non si vorrebbero rimuovere sono
  quelle iniettate in gioco senza l'ausilio dei reset, ovvero tutte le entità
  iniettate tramite scripts (item di quest fra tutti).
  Presumendo che la quantità e l'esistenza di tali entità sia gestito dagli
  script stessi ho creato la flag FLAG.UNCLEANABLE per le entità, che indica
  appunto di non rimuovere alcuni oggetti istanziati particolari.

  Il sistema ad ogni pulizia crea un file con tutta la lista delle entità
  estratte e il relativo contained_by così da poter risalire come mai vengano
  estratte:
  il file si chiama clean_game_instances.txt e si trova nella cartella log.

  Se per caso, per dovere di testing, si voglia anticipare l'orario di
  cleaning basta andare al file maintenance.py e modificare la riga
        if now.hour == 4 and now.minute == 30:
  con quello che si vuole.

- Avevo accennato sul fatto che il nuovo loop, il maintenance, esegue ora il
  backup automatico, questi viene eseguito di fisso alle 4 del mattino
  (e non una volta al giorno chissà quando, prima difatti cercava
  autonomamente il momento giusto cercando di eseguirlo quando non vi erano
  giocatori, ma ritengo che sia un'esagerazione).

- Ho creato la nuova tipologia connessione per il gioco, ajax puro e non più
  solo comet-emulato, la tecnologia è più lenta e meno reattiva nel refresh
  dell'output, e bisognerà fare uno studio sull'usabilità/tempi di risposta vs
  numero di connessioni adebite al refresh.
  La connessione è già di default questa ajax nuova, c'è la possibilità tra
  le opzioni dell'account di spuntare l'opzione comet, che indica la tipologia
  vecchia (consigliabile a tutti quei giocatori che avranno problemi
con la ajax).
  Bisogna necessariamente fare un po' di test su questa nuova connessione ajax
  con vari browser (e magari OS anche se non dovrebbe cambiare molto) su pc
  con installazioni differenti, specie quando si testa internet explorer.
  [Penso che ora il kindle che si era provato a connettersi possa funzionare
  con questa nuova connessione, probabilmente il browser kindle esegue una
  connessione al massimo per volta, e poiché quella di refresh output era
  sempre attiva metteva in coda le connessioni di invio output senza
mai eseguirle]

- Ho aggiornato le librerie jquery di un paio di versioni major, per supportare
  i grafici di statistiche (trovate in link tra quelli degli admin se volete
  vederli) ciò comporta un necessario ritest della creazione dei personaggi
  sui vari browser principali (test che ho già fatto ma un'altro non guasta data
  la delicatezza della cosa, non possiamo permetterci di scoprire poi che la
  creazione del personaggio non funzioni)

- Ho corretto un baco relativo al modulo gamescript che inficiava sulla memoria
  utilizzata globalmente, ora in teoria aarit dovrebbe consumare meno memoria,
  ho già testato gli scripts e non dovrei aver aggiunto bachi con questo fix
  Se, Ale, percepisci una differenza d'utilizzo di ram fammi sapere.
  E' una differenza che si rivela subito dopo l'avvio di aarit, e anche con
  il tempo, ma non so se sia questa quella che infici maggiormente sulla ram,
  non credo.

- Ho implementato il reload automatico dei gamescript relativi al wumpus, trovi
  tutto nel mio file oni_wumpus.py i cui import, metodi e funzioni
devi travasare
  nel tuo file wumpus.py.
  Ho aggiunto anche le modifiche effettuate in area.py e AREA.py ma non quelle
  in engine.py.

- Bisogna ricordarsi una cosa relativa le specials: i valori inseriti devono
  essere sempre: stringhe, numeri o valori True/False, non altro.

  Quindi se vi viene la tentazione d'utilizzare la specials come magazzino per
  salvarvi un riferimento ad un mob o ad un pg, non fatelo! Utilizzate invece
  il codice identificativo del mob o del pg e poi ricavate il riferimento
  quando vi servirà.
  Quindi non:
  mob.specials["player_to_speak"] = player
  ma:
  mob.specials["player_to_speak"] = player.code
  questo perchè altrimenti durante il salvataggio delle persistenze
  il valore salterebbe e non si potrebbe utilizzare dopo il riavvio.
  (per dovere di cronaca: in realtà c'è la possibilità di salvare strutture
  complesse, ma bisogna utilizzare i trigger di on_booting e on_shutdown per
  la lettura e il save delle informazioni complesse; di solito il gioco non
  vale la candela, ma se servisse spiegherò come fare caso per caso)

  C'è inoltre da dire che tutti i valori numerici inseriti come stringa nelle
  specials, del tipo:
  entity.specials["counter"] = "0"
  verranno ricaricati come numeri al reboot e non più come stringa!
  verranno difatti considerati come se voi aveste inserito:
  entity.specials["counter"] = 0
  Quindi fate attenzione.

  Tutto queste cose penso che si debba inserire da qualche parte nella
documentazione.

- Corretto il sistema di risposta automatica dei social sui mob, prima
  relativamente ai social con intenzioni pacifiche o aggressive non veniva
  inviato nessuna risposta, ora invece sì, dopo un secondo, e con una
  probabilità del 33%.
  C'è inoltre da dire che il social automatico non viene inviato quando il mob
  ha dei trigger relativi al social utilizzato su di lui, così da non
  conflittare con i gamescripts.

- Ho creato il sistema per rendere non crashabili i loop, le informazioni di
  crash vengono comunque inviate sullo stdout.

- Aggiunti i trigger
before_outcoming: si attivano su tutte le entità che stanno per vedere
uscire un'altra entità
before_incoming: si attivano su tutte le entità che stanno per vedere
arrivare un'altra entità
after_outcoming: si attivano su tutte le entità che hanno visto uscire
un'altra entità
after_incoming: si attivano su tutte le entità che hanno visto
arrivare un'altra entità
  L'interfacciamento a tali trigger è identico a quelli del movimento.
  Questi sono i trigger che servono per il wumpus.
  E' probabile che, in mancanza di tali trigger, voi abbiate utilizzato gli
  after_move o trigger similari su alcune stanze, per controllare l'arrivo o la
  partenza di pg sotto quest o cose simili, quando invece sareste stati comodi
  averli inseriti nello script del mob; ecco, ora invece potete farlo
direttamente.
  Da aggiornare il manuale.

- Ho rinominato i seguenti metodi da/a:
from_entity -> from_location
to_entity -> to_location
add_number_argument -> get_numbered_argument
  La from_entity e la to_entity perché ormai ho abbandonato
l'improbabile sistema
  di entitizzazione delle room e quindi è meglio chiamare i metodi con un nome
  più consono visto che il più delle volte gli spostamenti si effettuato su room
  e non su entità.
  Colgo l'occasione per parlare anche della get_numbered_argument; questa
  serve a ritornare la keyword preceduta da un eventuale numero posizionale;
  ovvero se nella stanza ci sono:
Un mostro selvatico
Onirik
Un mostro selvaggio
  I due mostri hanno la stessa key, se nel codice vogliamo ottenere
correttamente
  l'argomento con cui interagire con il secondo mostro (ovvero 2.mostro) bisogna
  utilizzare proprio il metodo get_numbered_argument così:
  numbered_argument = monster2_entity.get_numbered_argument(looker=sulfrum).
  Se si può è sempre bene aggiungere il looker, cioè colui che interagisce e
  vede il mostro, in questo caso chi guarda la stanza è appunto Sulfrum.
  Tale metodo è molto utile quando negli script si utilizzino dei comandi
  su dei target che possono essere mob oltre che pg (sui pg è facile, basta
  un player.code)

- E' meglio cambiare, come interfacciamento ai vari trigger sensoriali,
  il nome del parametro from_where in detail, che mi pare più chiaro
  da
before_look(entity, target, from_where, descr):
  a
before_look(entity, target, detail, descr):
  Da modificare la documentazione.

- Aggiunta la flag DOOR.NO_PASSDOOR, che indica che una porta non è passabile
  magicamente, Aarit non avrà l'effetto costante pass_door classico dei mud,
  tuttavia ci saranno degli incantesimi utilizzabili per superare le porte
  (o mura sottili), ho inserito di già la flag cosicché venga utilizzata per
  segnalare per tempo le porte importanti che non si vogliono rendere passabili
  magicamente.

- Creato il comando flee, prende un'uscita (anche con porta chiusa) e prova ad
  uscire da essa, se la trova chiusa a chiave ci sbatte contro, altrimenti può
  riuscire ad aprire la porta e fuggire; in contenitori non room o in stanze
  senza uscita cerca eventuali portali (used_as, cioè portali ovvi all'occhio)
  e vi entra.
  I check sono gestiti in maniera casuale, un giorno questo comando diverrà
  invece una skill.
  Si può decidere dove fuggire passando come argomento la direzione:
  fuggi nord
  Il flee genera un wait di un secondo e mezzo rispetto a tutti gli altri
  comandi interattivi gdr.

- Aggiunta la flag EXIT.NO_FLEE, che indica se verso una determinata uscita
  sia possibile fuggire o no, il comando flee proverà comunque ad utilizzare
  quell'uscita, per poi scoprire che non è agibile fallendo la fuga.

- Aggiunta l'opzione di account AUTO_FLEE, serve a eseguire un flee tramite un
  comando di direzione durante un combattimento.

- Ho rimosso la pagina web remove npp ed inserito l'opzione di rimozione delle
  persistenze tranne quelle dei pg nella pagina di shutdown.


================================================================================
Rella 105
06/12/11

- Aggiunto il codice WEAPON.KNIFE, che c'era il pugnale e la daga ma mancava
  il coltello semplice

- Aggiunta l'etichetta Damage alla struttura WeaponType, se non la si inserisce
  il danno dell'arma viene ricavato automaticamente sulla base di una tabella
  oppure inserito personalizzandone il valore, e seguendo in linea di massima
  cmq i valori della tabella, in questa maniera, per esempio:
  1D6+1
  2D4-2
  6D10+33
  -2D2+1  (questo danno rigenererà l'avversario invece di ferirlo)

- All'avvio di Aarit verrà creata automaticamente la pagina di documentazione
  damages.htm, che contiene l'attuale lista di danno per livello preso
  automaticamente se non viene inserito nessun valore per l'etichetta Damage

- Adesso è possibile utilizzare le armi nel combattimento

- Ho dimezzato il danno effettuato a mani nude, è meno casuale e si basa tutto
  sulla propria forza
  C'è poi il danno di oggetti che non sono armi ma impugnati come armi, il loro
  danno deriva dal livello e dal peso dell'oggetto

- Aggiunta l'opzione OPTION.MAP da aggiungere a tutti i account nell'etichetta
 Options:

- Tolta la pagina relativa al who perché si sospetta che i giocatori non
  entrino neppure in gioco se non vedono nessuno online, quindi per un po' di
  tempo rimaniamo senza pagina who per vedere com'è l'andazzo.

- Come ho scritto nel wiki apposito ho inserito il wait, lo riscrivo qui tanto
  per avere doppio riferimento:
Il wait non stoppa solo il kick, ma tutti i comandi che hanno una
determinata interazione rpg e movimento.
Ciò significa che il wait non stoppa il comando score ma stoppa il
comando dig, che verrà inviato solo quando il wait scade.
Per inserire un wait negli script basterà fare una cosa del genere:
entity.wait(1.7)
dopo 1.7 sono i secondi

- I ReadableType ora sono leggibili anche se non sono in inventario

- Non l'abbiamo più testato, ma bisognerebbe provare ad inviare social della
  peggior specie su di un mob a vedere se questo attacca

- Ora il check del no_send sugli act è centralizzato, sta a dire che ora molto
  probabilmente inserendo come descrizione sensoriale no_send questa non
  venga letta

- Aggiunti i trigger before_ e after_ a tutti i social, per esempio il comando
bow
farà scattare gli eventuali trigger
before_bow(entity, argument, target):
after_bow(entity, argument, target):
in questo caso argument è una stringa vuota e target è None

mentre il comando
smile astroboy
farà scattare gli eventuali trigger
before_smile(entity, argument, target):
after_smile(entity, argument, target):
con argument uguale a "astroboy"
e target proprio astroboy se trovato nella locazione in cui è stato
eseguito il social.

Ritengo che nella documentazione sarà bene inserire una sezione generica che
spieghi che l'interfacciamente è uguale per tutti i social e non inserire tutti
i trigger dei social.

- bisogna convertire negli script qualsiasi occorrenza di
from.input import send_input
in
from.interpret import send_input

- Relativamente a:
(21:46:22) Sulfrum: script
(21:46:27) Sulfrum: before_touch
(21:46:33) Sulfrum: return True
(21:46:57) Sulfrum: il mob oggetto del touch se snoopato vede il
messaggio "tizio ti tocca"
(21:49:03) andrea.postal@gmail.com/409538C5: e non dovrebbe no? ma gli
altri vedono messaggi?
(21:49:20) Sulfrum: gli altri invece non vedono (giustamente i messaggi)
E' stato corretto

- Aggiunta l'immaginina che indica esplicitamente che aarit è in beta

- L'etichetta RemakeHour della struttura Maze può ora avere il valore di -1
  ad indicare un maze che non si ricostruisce ad una certa ora (ma che viene
  probabilmente ricostruito via gamescript oppure rimane così com'è).
  Da aggiungere nella documentazione.

- Se ora si vuole creare un labirinto via script bisogna seguire questi step
  minimali:
# Fermo restando che si ha già in mano l'area a cui associare il maze
# Il primo valore sarebbe l'etichetta Columns, il secondo Rows e il terzo
# CodePrefix della solita struttura Maze
from src.games.maze import Maze
maze = Maze(10, 5, "villaggio-zingaro-maze_room_grotte", False)
area.maze = maze
area.maze.create(area)
# et voilà, si dovrebbe avera il maze in game, se si vuole ricrearlo per
# qualche motivo bisogna fare:
area.maze.remake(area)


================================================================================
Rella 104
24/10/11

* Ora per le door servirà la flag CLOSABLE per indicare che la porta è
chiudibile

* Da rimuovere tutte le etichette WeakWay, StrengthWay e Way dai dat dei player

* Modificato l'ENTITYPE.BOOK in ENTITYPE.READABLE

* Potrebbe avvenire un errore per il caricamento delle persistenze, i cadaveri
 in particolare, visto che ho cambiato il nome dell'etichetta da
 DecompositionHours:
 in
 DecompositionRpgHours:

* Avverrà un errore all'avvio sull'etichetta LandfillCode, alla buona se si
  vuole correggerlo subito basta inserirvi il primo codice di stanza prototipo
  che venga in mente e che sia sempre in-game (non quindi resettata) per tutti
  i dati delle aree.
  Spiegherò meglio poi cosa sia.

* Aggiunta l'opzione di config
puritication_rpg_hours = 24
  alla sezione [GAME]
  viene spiegata sotto

- L'interfacciamento con il before_seed e l'after_seed è cambiato da
force_return = check_trigger(location, "before_seed", entity, target, location)
  in
force_return = check_trigger(location, "before_seed", entity, target,
location, ground)
  ground è il terreno in cui si sta seminando la pianta oppure quello trovato
  per primo nel vaso (la location).

- In questa release forse è possibile interagire con il contenuto delle piante
  anche se queste sono piantate in contenitori

- Evita di far attecchire piante in un terreno (inteso come entità ground)
  se questo ha già un seme o una pianta in crescita.
  Per le staze invece il massimo piantabile è il numero i metri quadri
  della stanza meno il numero di entità contenute (visivamente, quindi mucchi
  di più oggetti valgono uno)

- Aggiunta la label ReadableType, un'entitype.
  Vediamo come funziona questa label tramite un esempio:
ReadableType
    Title: L'avventura di gatto
    Author: Gatto
    Summary:
        Cemo chi legie
    Language: LANGUAGE.ELVEN
    Flags: READABLE.NUMBERS READABLE.CENTER
    NumberDecorationLeft: --
    NumberDecorationRight: --
    VisualWidth: 100px
    VisualHeight: 150px
    Padding: 15px
    BorderTop: 3px outset silver
    BorderRight: 3px outset silver
    BorderBottom: 3px outset silver
    BorderLeft: 3px outset silver
    BorderInside: 1px solid silver
    Pages:
        bla bla bla copertina
        bla bla bla copertina
    Pages:
        bla bla bla 1
        bla bla bla 1
    Pages:
        bla bla bla 2
        bla bla bla 2
    Pages:
        bla bla bla 3
        bla bla bla 3
    Pages:
        bla bla bla retrocopertina
        bla bla bla retrocopertina
End

Title: il titolo del libro, servirà ai mob bibliotecari in futuro per
catalogare i libri.
Obbligatoria

Author: è l'autore del libro, può essere una qualsiasi stringa ma se il libro
è stato scritto da un giocatore ed ha senso rpg che sia così bisogna inserirvi
il nome di quel pg (con prima lettera maiuscolo e senza eventuali colori).
Anche qui il valore servirà in una futura implementazione per i bibliotecari
mob per catalogare i libri e per gestire modifiche di editing ai libri di
un particolare pg.
(edizioni di uno stesso libro)
Obbligatoria

Summary: è una breve descrizione del libro che si carpisce esaminandolo, come
se lo si sfogliasse velocemente e se ne recepisse il contenuto in maniera
riassuntiva o si cogliessero le immagini principali.
Tale informazione la si carpisce tramite il comando esamina.
È interessante da usare per indicare punti interessanti o segreti del libro,
magari suggerendo delle extra invisibili ai 6 sensi.
Obbligatoria

Language: Lingua in cui è scritto il libro, ora come ora non c'è, ma in futuro
il contenuto verrà criptato per coloro che non conoscono la lingua
Facoltativa, se non è inserita viene considerata come lingua la COMMON

Flags: sono le flag READABLE del libro, ora come ora servono a gestire l'output
delle pagine
Facoltativa

NumberDecorationLeft: e NumberDecorationRight: servono a decorare i
numeri delle pagine.
Il left serve per le pagine a sinistra mentre l'altro per le pagine a destra.
Praticamente qualsiasi stringa di caratteri voi inseriate verrà spezzata a metà
ed inserita circondando il numero di pagina... si fa prima a vederne i risultati
che spiegarne il funzionamento...
Le etichette sono facoltative, perché la decorazione si visualizzi deve esservi
la flag apposita che visualizza i numeri di pagina, cmq all'avvio dovrebbe
avvertire di tale eventuale manchevolezza

VisualWidth: e VisualHeight: valore numerico in pixel che indica
quanto la pagina
del libro debba essere grande, sì purtroppo la pagina del libro non si adatta al
contenuto perché altrimenti sarebbe troppo complicato per me e rischieremmo di
avere pagine di libro differenti in grandezza tra di loro, quindi voi dovrete
avere un po' di pazienza e inserire un output adeguato per ogni pagina.
Quello che consiglio è di usare un'"area" di righe e colonne con il vostro
editor testuale e scrivere in essa, poi osservare nel mud come si visualizza
e scegliere la VisualWidth e VisualHeight adatte, con vari tentativi.
Indicativamente non superate i 400px di width e i 600px di height oppure
potete utilizzare il metodo di visualizzare il book con due pagine aperte
in uno screen a 1024*768 e vedere se il readable viene contenuto tutto nella
finestra di output.
Le etichette sono obbligatorie

Padding: il padding, sempre in pixel, è il margine vuoto tra l'output da
leggere e la cornice della pagina
L'etichetta è facoltativa, se non viene inserita il valore è 0px

Le varie etichette BorderXxx: è codice css che serve a gestire i vari bordi
del libro, per maggiori informazioni leggere il link:
http://www.w3schools.com/css/css_border.asp
in italiano c'è cmq sicuramente del materiale, basterà cercare 'bordi in css'
il bordo più semplice da fare è:
1px solid silver
un pixel di larghezza, con una linea semplice, e di colore argento
altrimenti potete utilizzare i bordi dell'esempio in alto che danno un
effetto 3D
al libro
L'etichetta BorderInside: è il bordo centrale che serve a dividere le due pagine
di solito è da farsi
1px solid silver
ma a voi la possibilità di smanettare.
L'etichette Border sono facoltative, si può, volendo creare una cornice
in ascii art direttamente nel contenuto delle pagine del libro e inserire
il Padding: 0px (che poi è il valore di default)

Pages:
Ed ecco infine il contenuto vero e proprio del libro.
Per ogni etichetta Pages che viene inserita viene aggiunta una pagina, partendo
dal numero di pagina 0 (la copertina) fino all'ultima, la retrocopertina.
Si può anche inserire una sola etichetta Pages ad rappresentare per esempio
una pergamena.
Due pagine invece potrebbero essere semplicemente il fronte e il retro di un
singolo foglio.
Si possono inserire pagine vuote semplicemente scrivendo così:
Pages: &nbsp;
Forse interessante sarebbe difatti creare libri pieni di pagine vuote tranne
qualcune, a numeri di pagina specifici, che alternativamente al cercarli a mano
sarebbe interessante scoprire tramite una quest.
Ricordo che potete inserire le ascii art con il solito metodo oppure delle
immagini tramite html in questa maniera:
<img src="url dell'immagine" />
(se c'è bisogno di aiuto chiedere al sottoscritto, nella documentazione cmq ci
vorrà almeno un esempio di inserimento immagine indicando che le immagini
dovranno essere passate e caricate sul server tramite amministratori).
Non è inoltre da scordare che si possono inserire i MIML.
Almeno un'etichetta Pages obbligatoria, altrimenti, che readable è?

Infine, come tutte le entitype, c'è l'etichetta Comment

- Aggiunto il comando read.

- Il comando examine di un readable_type visualizza il Summary: invece della
  descrizione normale del look

- Nella locazione in cui i pg vengono risorti, o in un'altro posto da adibire
  bisogna creare un oggetto "Menhir della Vita" che serve come segnaposto
  per i pg che verrebbero risorti.
  Ci può essere al massimo un Menhir della Vita per area, se un pg muore in un
  area con un menhir verrebbe risorto lì... cmq per ora il codice manca.
  Intanto cmq aggiunto l'ENTITYPE.MENHIR

- Ho cambiato il sistema del bianco/nero per il nero, ora non ha più il
  background bianco ma possiede una shadow sottostante di bianco che sfuma
  un po'.
  L'effetto non è dei migliori... ma non ho trovato di meglio.
  L'effetto non funziona sotto IE9 ma su tutti gli altri major browser sì.

- Cambiata la creazione dei pg rimuovendo le way (che verranno invece ricavate
  automaticamente a seconda delle abilità imparate)

- Aggiunto i tag di act $i e $I
  il primo serve ad elencare tutto il contenuto, in formato elenco, di target
  (ovvero $N)
  Il secondo invece stampa il nome dell'entità, con maggiore peso * quantità,
  contenuta in $N.
  Cosa servono queste cose?
  Ad emulare contenitori trasparenti.
  Il primo nel qual caso si voglia un contenitore che faccia vedere tutto.
  Nel secondo invece un contenitore che faccia vedere solo l'entità in
  maggiore quantità (il vino per esempio, o una sabbiolina)

- Controllato e ripulito il comando kick, già inviatoti

- Aggiunta l'etichetta
DecompositionRpgHours
  per le plant, facoltativa, con valore di default a 24 (intese ore rpg)
  Serve ad indicare in quante ore rpg il contenuto di tipo seme, fiori o frutti
  cadendo dalla pianta viene "purificato" dal gioco.
  Il conteggio viene fermato se un giocatore raccoglie uno di questi oggetti
  da terra o se cmq da script o in qualsiasi altro modo l'oggetto viene
  spostato.
  Poiché questo sistema porterebbe a far pensare a bachi se uno non si ricorda
  o non ha una visione generale di tutte le feature del codice ho deciso di
  inviare questa frase:
  "$n si decompone fino a diventare polvere"
  per ogni entità che viene estratta da gioco in questo modo.
  DA NOTARE che tutti gli oggetti in "purificazione" (questo è proprio il
  termine tecnico) durante il salvataggio delle persistenze vengono scartati.
  Da aggiornare il manuale del builder nella pagina delle piante.

- Aggiunte le etichette di Behaviour
GetPlayer
GetMob
GetItem
GetAtRaces
GetAtRacesFlags
GetAtEntitypes
GetAtEntitypesFlags
  funzionano (se funzionano, che le ho codate in maniera "sperimentale") come
  le etichette, con nome simile, dei 6 sensi.
  Da aggiornare il manuale del builder.

- Per ogni oggetto gettato in maniera behaviored, cioè con le etichette sopra
  descritte, c'è una possibilità che dopo 24 ore rpg se l'oggetto non è stato
  espressamente manipolato (spostato in qualsiasi modo o wieladato o wearato
  o holdato o eatato) questi venga "purificato" (verbo molto importante già
  utilizzato in precedenza)
  In pratica tutte le entità con le etichette behaviorose del get sono dei
  potenziali spazzini del mud.
  Dopo le 24 ore avverrà la magia e verrà inviato il messaggio:
  "$n si disgrega fino a diventare polvere"
  leggibile solo da quelli che si trovano nell'inventario dell'entità
  che ha gettato.

- Ma c'è di più, dopo le 24 ore l'oggetto che sta per essere purificato
  potrebbe cmq non esserlo se questi è di valore (per ora > 1000 danari) oppure
  c'è cmq una probabilità su 100 che non venga purificato, tuttavia l'oggetto
  non rimane dov'è ma viene teletrasportato in appositi luoghi: le landfill.
  Difatti ho aggiunto l'etichetta LandfillCode per le aree, bisogna inserirvi
  un codice di stanza prototipo da utilizzare come "discarica".
  Non è detto che sia poi una discarica vera e propria, per esempio in un'area
  in cui c'è un mob forte come un drago la si può utilizzare come scusa e si
  utilizza il suo covo come discarica, ovvero il luogo in cui ci sono tutti
  gli oggetti di valore che stavano per essere purificati di quell'area, come
  se il drago accumulasse un suo tesoro.
  Altro caso può essere che un'area in cui vi sono inondazioni fluviali porti
  via con sé gli oggetti in un luogo particolare grazie alla corrente.
  E così via, nella vecchia fantasia ia ia ohhh!
  Da notare che il codice può essere anche una stanza di un'altra area, ma
  dev'essere cmq una stanza che si trova sempre in-game (non resettata, o se
  resettata sempre con una con lo stesso codice di prototipo), e sarebbe meglio
  che sia unica come codice in tutto il mud, altrimenti gli oggetti verrebbero
  inviati in una stanza o nell'altra a caso ma questa a ben vedere sarebbe un
  baco-feature, no?
  Da aggiornare il manuale del builder nella pagina delle aree.

- Riassumendo il Sistema di Purificazione funziona in questa maniera:
  Ci sono dei casi in cui alcuni oggetti verrebbero accumulati troppo e quindi
  viene deciso di attivare il sistema di purificazione:
  semi che cadono dagli alberi, get casuale tramite behaviour...
  Gli oggetti dopo 24 ore se non sono stati manipolati in alcun modo vengono
  estratti dal gioco A MENO CHE non siano di valore (oppure a caso ogni tanto);
  verrebbero invece inviati in appositi luoghi di accumulo, dove sarà più facile
  gestirne l'eventuale grande quantità (e dove i giocatori che avranno mangiato
  la foglia andranno ciclicamente alla ricerca di sorpresine... per quello
  l'idea del drago che protegge il tesoro è un must!)

- Ho aggiunto l'opzione di config
puritication_rpg_hours = 24
  serve a indicare quante ore rpg si hanno di attesa prima che le entità
  prescelte dal sistema suddetto vengano estratte dal gioco.

- Ho aggiunto l'etichetta di entità (mob e item quindi)
PurificationMessage:
  che serve a personalizzare il messaggio di act a quelli della stanza:
$n si disgrega fino a diventare polvere
  il messaggio può essere quindi personalizzato, si può anche inserire il
  valore no_send per indicare di far scomparire gli oggetti purificati
  senza output.
  Deve avere il tag di act $n, e può avere anche altri tag di act anche
  se non quelli relativi a target $N e simili in maiuscolo.
  Da aggiornare il manuale a riguardo

- Aggiunte le etichette di Behaviour
LookInventory:
ListenInventory:
SmellInventory:
TouchInventory:
TasteInventory:
IntuitionInventory:
Funzioneranno solo sui container aperti

- Aggiunte le etichette di Behaviour:
GetPlayer:
GetMob:
GetItem:
GetAtRaces:
GetAtRacesFlags:
GetAtEntitypes:
GetAtEntitypesFlags:
Funzionano come ci si aspetta

- Aggiunte le etichette di Behaviour:
EatPlayer:
EatMob:
EatItem:
EatAtRaces:
EatAtRacesFlags:
EatAtEntitypes:
EatAtEntitypesFlags:
Funzionano come ci si aspetta

- Aggiunti i trigger di before_eat e after_eat, i trigger dovranno essere così:
def before_eat(target, entity):
def after_eat(target, entity):

- Aggiunti i trigger di before_kick e after_kick, i trigger dovranno
essere così:
def before_kick(entity, target, skill_result):
def after_kick(entity, target, skill_result):

- Aggiunto il comando admin extract che serve a rimuovere per sempre dal gioco
  entità come mob e item, non funziona sui player

- Aggiunta la pagina di admin global_quantity.html come da te richiesto

- Dovrebbe essere possibile, aggiungendo il nome di una pagina inaccessibile
  nell'etichetta Permissions renderla accessibile a coloro che non hanno i
  trust adatti, per esempio:
  Permissions: area_editor.html

- Aggiunti i settori:
SECTOR.TAVERN   (per taverne, ristoranti, alberghi etc)
SECTOR.BLACKSMITH  (per fabbri e armaioli)

- Creata una mini wild per le aree

- Aggiunta l'etichetta
Tile:
  alle room, essa serve ad inserire una tile graphic per la mini-wild differente
  da quella di default.
  Le tile devono essere delle png di 32x32 e devono essere inserite
nella cartella
  www/sector, eventualmente creando delle sottocartelle per meglio organizzare.
  Il tutto in sostanza funziona come l'etichetta Icon.
  Esempio:
Tile: sector/fountain.png
  Serve a personalizzare l'aspetto della mini-wild che a volte, se non spesso,
  come potrete vedere, non ha il settore adatto ad essere visualizzato.
  A volte è utile personalizzare il tile se quella stanza è importante.
  Magari sarà utile anche modificare anche solo un poco il tile del settore di
  default in cui si trovano alcune DT e inserirlo.

- Ho aggiunto al tastierino numerico la possibilità di andare in basso e in alto
  tramite i tasti . e *, ho notato difatti che non hanno il difetto del + e -,
  un grande salto di usabilità!
  *emote salta*

- Ho cambiato la scritta sotto le descrizioni delle stanze da
Uscite:
  in
Puoi andare verso:
  ritengo che sia migliore così, ma è da testarne
  l'usabilità/leggibilità/probabile impatto per i neofiti etc etc

- Ho modificato l'appeal dei bottoni donandogli un effetto 3D, fammi sapere
  cosa ne pensi, a volte mi pare che la scritta non sia del tutto leggibile
  (c'è della shadow)
  E' roba da testare sotto firefox, già sotto chrome è diverso (c'è più effetto)
  e sotto IE invece è il solito vecchio piatto bottone

- Nelle release precedenti solo le descrizioni delle stanze occupava il 66%
  della schermata di output le altre tipologie di descrizioni invece il 100%,
  l'ho corretto.


================================================================================
Rella 103
01/10/11

* Modificato il settore SCRUB in SHRUB, typo...
  Rimosso il settore INSIDE visto che era obsoleto, ci sono dei messaggi nel
  boot a riguardo da risolvere

* Rimossa la label Count per mob, item e personaggi (anche se forse in futuro
  servirà... ma speriamo di no)

- Aggiunto il nuovo loop al comando loop, quello che interessa i behaviour
  delle stanze, me n'ero dimenticato di farlo nella precedente versione

- Aggiunta la tipologia di entità money:
ENTITYPE.MONEY
Ed anche la sua bella struttura:
MoneyType:
    Coppers: 100
    Races: RACE.HUMAN
End
Ovviamente come ogni struttura di entitype ha anche la sua bella label Comment
non obbligatoria.
Coppers indica quanti "monete di rame umane" vale quella moneta
Praticamente 1 Copper (moneta di rame) è il valore minimo che si possa dare
ad una moneta.
Sarebbe bene creare:
una moneta di rame per gli umani del valore di Coppers: 1
una moneta di argento per gli umani del valore di Coppers: 10
una moneta d'oro per gli umani del valore di Coppers: 100
una moneta di platino per gli umani del valore di Coppers: 10000
Da notare che il platino vale 100 d'oro
Poi oltre a queste monete di default si possono creare varie altre monete,
stampate in periodi differenti, antiche, nuove, spiattellate, di una razza,
dell'altra etc etc, con il loro valore
Da notare che non necessariamente un'entità dev'essere rappresentata come una
moneta classica, la moneta di una particolare razza potrebbe essere un'oggetto
particolare, di comunque non comune fattura; inoltre per assurdo potrebbe
essere un piccolo mob di qualche tipo (dei bruchi rari per i pixie?).
L'altra etichetta di solito da impostare, comunque non obbligatoriamente, è
Races, ed indica quali razze utilizzano normalmente quelle monete e che quindi
la accetteranno nelle loro transizioni; se non viene utilizzata quest'etichetta
sarà come dire che quel tipo di moneta è utilizzato in tutto il mondo di Nakilen
(come di solito accade con le monete umane)
Da non confondersi invece la fattura della moneta, indicata dall'etichetta
dell'entità Race.
Date un peso di 1 grammo o poco più alle monete, visto che il giocatore di
solito ne porterà anche in gran quantità.

- Aggiunto un download alla rispettiva pagina

- Velocizzato il boot, ora è relativamente veloce il caricamento del mud anche
  con le persistenze

- Risolto il baco della pagina di distribuzione dei punti, ora si può avviare il
  mud con l'opzione reload_web_pages a True senza ulteriori problemi

- Aggiunte le flag DOOR.CLOSABLE, DOOR.OPEN_ONE_TIME e CONTAINER.OPEN_ONE_TIME
  esse servono principalmente per emulare l'open eseguibile solo una volta
  su oggetti come i frutti che contengono i semi, quindi oggetti con flag
  OPEN_ONE_TIME rimuoveranno la flag CLOSABLE all'open

- Implementato un sistema di inserimento dei semi dentro fiori o frutti o altro
  contenuto
  Praticamente mischiando nell'etichetta Contents di un PlantType
fiori e/o frutti
  e/o altro E anche dei semi questi ultimi non verranno inseriti
direttamente nella pianta
  ma verranno tenuti da parte ed inseriti nel resto del contenuto.
  Contents: seme1 10
  Contents: seme2 10
  Contents: frutto1 10
  Contents: fiore1 10
  verranno inseriti mediamente 10 frutti e 10 fiori che conterranno
mediamente 10
  semi di qualità pescata a caso.
  I frutti funzionano come dei contenitori con flag OPEN_ONE_TIME.
  Da aggiornare il manuale.

- Aggiungo, relativamente alla gestione dei cadaveri mob e player, che il
  comando get è impossibilitato a gettare da cadaveri di pg che non siano
  ormai decomposti totalmente (ovvero che se fossero dei cadaveri di mob
  sarebbero stati estratti) dopo quel tot di tempo è possibile loottarli.

- Aggiunta la flag ROOM.DEATH_TRAP


================================================================================
Rella 102
06/09/11

* Rimossa l'opzione behaviours_only_for_code del  file di config.ini,
  probabilmente non l'hai impostata nel file e quindi non devi fare nulla

* Convertiti i trigger da on_inject e da on_extract in before_inject e
  after_inject e in before_extract e after_extract; funzionano come ci si
  aspetta.

- Il problema della schermata nera non dovrebbe più presentarsi con tanta
  frequenza, per lo meno nei termini che ho percepito essere capitati
  ultimamente, sicché quando viene convertito un vecchio giocatore nella
  terza pagina di creazione questi si collega direttamente alla pagina di
  gioco e non in quella della lista dei giocatori.
  Unica eccezione l'abbiamo come al solito con IE.

- Inoltre con IE9 la pagina di gioco di aarit non funzionava, ora sì.

- Aggiornata la pagina Trusts con la visualizzazione dei Permissions.

- Aggiunta la variabile Backsteps, visualizzabile solo lato web nella tabella
  dei dati, essa permette di conoscere fino a 20 codici di locazione visitati
  precedentemente.
  Per i personaggi il numero di steps sono a 100.
  La variabile è volatile e quindi non viene salvata nei file della persistenza.

- Per snellire l'utilizzo della ram ho identificato due memory leak relativi
  alla variabile owner e a quella was_contained_by.
  Tali variabili salvano il riferimento ad un'entità, tale entità però poteva
  essere stata estratta precedentemente e quindi il riferimento non sarebbe
  dovuto essere più valido, nonostante ciò il valore di was_contained_by
  rimaneva imperterrito puntando ad un dato non più utile ed evitando così che
  il garbage collector del python facesse pulizia.
  Tale cosa l'ho scoperta mentre studiavo il baco delle entità seminate che
  avevano owner o was_contained_by errato, questo perchè l'entità che li
  conteneva precedentemente ormai era stata estratta, l'avvio li identificava
  come ERRORE CRITICO, in realtà è un falso errore.
  Ora invece owner e was_contained_by non utilizzano un riferimento normale
  ad un oggetto ma un riferimento debole, praticamente negli eventuali futuri
  script per accedere ad una di queste due variabili non bisogna più fare:
  entity.owner
  ma:
  entity.owner()
  inoltre per impostare tali variabili non bisogna più fare:
  entity.was_contained_y = target
  ma:
  import weakref  # se non già precedentemente importato in alto
  entity.was_contained_by = weakref.ref(target)
  Da notare che comunque quando bisogna impostare a None la sintassi non cambia:
  entity.owner = None
  Tutto questo ambaradam però non dovrebbe migliorare di molto il consumo di
  ram, ma è già qualche cosa.

- Smanettando per le modifiche del weakrefs ho trovato un bacone grosso come
  una casa riguardante la copia degli attributi di oggetti in altri oggetti
  simili (che serve ad esempio nel resetting da un proto-mob ad un mob normale).
  Ho scoperto che la copia di variabili con dei semplici riferimenti,
come owner,
  in realtà non venivano copiate come riferimento ad un dato in un'altra parte
  ma venivano copiate integralmente, il tutto consumando un bel po' di ram!
  Il fix di questo baco dovrebbe sì diminuire l'utilizzo di ram, poiché penso
  proprio che il baco si presentasse: inutili copie selvagge di oggetti
  simil-altri... facendo credere che si manipolava gli oggetti in riferimento...
  terribile... roba da bachi su bachi, altro che x-files!

- Bisogna aggiungere la struttura
Wild
    Height: 512
    Width: 1024
End
nel file nakilen.dat

- Ora il controllo dello spelling all'avvio non è più automatico ma deve
  essere richiamato dall'opzione -s o --spelling nella riga di comando
  d'avvio di aarit.
  Questo serve ad evitare lentezze bradipali nel controllo dello spelling delle
  persistenze, che tra l'altro non è utile al 99%.

- Ho aggiunto finalmente il calcolo della dimensione delle differenti tabelle
  del database nella pagina web apposita, il calcolo è approssimato ma non so
  bene di quanto, ma dovrebbe essere adeguatamente corretto.
  Per lo meno capiamo se ci sono dati ghost nella crescita di ram oppure se
  è il database stesso a crescere in maniera sproporzionata rispetto ai valori
  di partenza.
  Sotto alla solita tabella del database ve n'è un'altra, una volta calcolato,
  delle differenti aree con le loro belle entità, numero e dimensione in bytes,
  ho notato che se anche il numero di entità totali sia uguale a quello del
  database (un must per la correttezza dei riferimenti) la dimensione del
  calcolo è di un po' più grande; temo che sia un problema insito alle funzioni
  che utilizzo per il calcolo delle dimensioni.. difficile stabilirlo, visto
  che ho letto che eseguono un'approssimazione ma non so perché e di quanto.

- Convertita la duration delle PlantType da minuti rpg in ore rpg, per
  ricordare tale cose ho rinominato l'etichetta Duration in RpgHours

- Relativamente alle piante: ora solo l'used_as SEED può avere l'etichetta
  RemainingLife impostata.
  RemainingLife diminuisce di uno ogni volta che passa ad un stage di SEED
  (compreso il primo)
  La DeadEntity serve per indicare che il ciclo vitale era finito
  Quindi per seed con ReaminingLife a 0 non producono neppure la piantina
  Per test si vorrà diminuire il tempo di stage, per fare ciò bisogna andare
  nel file plant.py e cercare la riga:
  seconds = self.rpg_hours * (config.seconds_in_minute * config.minutes_in_hour)
  e modificarla in
  seconds = self.rpg_hours * config.seconds_in_minute
  per avere il vecchio sistema temporale

- Creata l'etichetta RoomBehaviour, essa ha una sola due sottoetichette
  (per ora) che fanno riferimento ad un comportamento di behavioru della stanza
  quello di visualizzare dei messaggi a tutti coloro che sono in essa.
  Le etichette sono:
  RoomBehaviour:
    RandomEcho: 300
    RandomEchoTexts: cade na goccia
    RandomEchoTexts: qualcuno sternuta
  End
  Dovrebbe essere autoesplicativa, assomiglia molto alla RandomDo e
  RandomDoInputs, solo che qui non vengono inviati dei comandi ma un messaggio
  di echo

- Da aggiungere un parametro dopo target per i trigger before_remove e
  after_remove e cioè from_where, indica da quale oggetto si sta rimuovendo
  il vestito

- Il comando remove dovrebbe rimuovere gli oggetti wearati da altri oggetti
  manichino like, la sintassi è intuitiva, gli oggetti rimossi vengono messi
  per terra, ho preferito così rispetto ad un autoget perchè il get è una azione
  complessa e preferisco atomizzare le azioni.


================================================================================
Rella 101
04/08/11

* Bisogna rimuovere tutti gli attributi Approved agli account e ai player

* Aggiunta l'opzione di config
starting_attrs = 30

- Questa release dovrebbe essere meno affamata di memoria, non so di quanto
  ma a parità di data DEVE consumare di meno.
  Per mera curiosità, così da poter in futuro avere un'idea per eventuali altre
  modifiche simili, sarebbe da lanciare una release precedente a questa e
  questa e vedere quanto le due, il più possibilmente a parità di data,
  consumino in ram.

- Ho aggiunto l'icona icon/equipment/ring_rune_of_return.png per l'apposito
  gift a cui mancava, bisogna aggiornare il relativo file dat.

- Ho notato una cosa nel codice attuale: ora come ora le sole entità nella
  stanza del reset vengono ricaricate del loro contenuto, le entità in
  wandering invece no.
  Questo capita sia nel reset che nel repop.
  Ci sarebbe da vedere se sarebbe auspicabile anche per le entità in wandering.
  E testare un po' se tutto quello che ho detto torna o sono io che leggo
  male il mio codice :P

- Avevo fatto un sistema interno di redirect, ma poi l'ho abbandonato perché
  alla lunga se lo avessi utilizzato sarebbe accaduto per esempio che la pagina
  account.html avrebbe ritornato il contenuto della pagina players.html, e ciò
  non va' bene perchè se la pagina è indicizzabile da motori di ricerca,
  questi potrebbero bastonarci.
  Quindi ho fatto un passo indietro rimettendo i request.finish() da te rimossi
  e modificando la riga di return sottostante come ho letto in giro in internet,
  speriamo bene stavolta.

- Implementato un sistema di spelling di tutte le descrizioni del mud,
  praticamente prende le parole dalla cartella dicts e controlla se quelle
  utilizzate nelle descrizioni ne hanno corrispondenza, tutte le parole
  non trovate vengono inserite nel file typos.result senza in quella cartella.
  Puoi inserire tutti i dizionari che vuoi, basta che abbiano l'estensione
  dict, ne ho già inseriti alcuni per variare un po'.
  NON toccare il dizionario grosso, le parole mancanti le preferisco inserite
  negli altri file, come per esempio "altre.dict".
  Se trovi altri dizionari giganti in internet da utilizzare per infarcire
  il grosso passameli che ci penso io.

  All'avvio troverai molti messaggi del tipo:
  Punteggiatura isolata per l'attributo bla bla bla
  significa che nel testo è stato scritto qualche cosa tipo:
  Oggi ha fatto bello . Domani sarà brutto.
  Il primo punto se noti ha una spaziatura antecedente.
  Probabilmente ti verranno fuori dei falsi positivi dentro delle ascii art..
  Ci devo ancora lavorare per quello.

- Avevo detto che avrei implementato i RoomBehaviour, falso, non ce l'ho fatta,
  devo ancora rifare un'altra volta tutto il sostrato dei behaviour (per fortuna
  non il nocciolo statistico ma "solo" le fondamenta)
  Tuttavia sono riuscito a implementare i miml per i RandomDo proprio come da
  idea postata sul wiki, cioè mimlati.

- Aggiunto il check di miml del tipo:
#self is not SECTOR.XXX#blabla1#blabla2#
#contained_by is SECTOR.XXX#blabla1#blabla2#
Stessa cosa per le flags ROOM di stanza
Stessa cosa per le flags di CONTAINER per i contenitori

- Probabilmente ora la decomposizione dei cadaveri funziona, ma se si riavvia
  a persistenze attive non va' più, c'è da testare se è veramente così, che poi
  correggo.

- Aggiunto il comando admin di restore, oltre a ripristinare i punti toglie
  fame, sete etc

- Inserita l'etichetta, solo per i player, dei permessi; essi servono a superare
  le normali trust applicate normalmente, per esempio:
Permissions: command_goto command_rgoto command_mgoto command_igoto
  ad un pg con TRUST.PLAYER farà in modo che un pg con trust normale possa
  utilizzare questi comandi da admin

- Dovrebbe essere impossibile creare nuovi giocatori con nome come:
altro
delle
etc
Mentre un account con nome Altro dovrebbe essere possibile
(viene utilizzata la stessa funzione per questo sono legate le due cose)

- Ora la flag d'opzione account AUTO_LOOT dovrebbe funzionare.

- Anche i giocatori che muoiono creano il loro bel cadavere spuzzolino.

- Personalizzati nel combattimento i messaggi di danno a seconda della quantità
  di danno, si basano sui messaggi del mud lands of darkness

- Ho debellato un baco particolare e non dovrebbe più capitare il baco
  dell'attributo _cached_behaviour_draw_attrs_ mancante

- Ora ci sono questi input per i comandi bolt e unbolt:
  command_bolt            sbarra sbarro sbarri sbarrare
= command_bolt            spranga sprango spranghi sprangare
  command_unbolt          spalanca spalanco spalanchi spalancare
= command_unbolt          svincola svincolo svincoli svincolare

  Ho sistemato inoltre il file  __init__py e door.py con le cose boltose e
  unlockose come dovrebbero essere, quindi ora dovrebbero funzionare.

- Aggiunto il messaggio della beta alla pagina dei personaggi, sarebbe da
  migliorare secondo me, è un po' troppo caustico(?) e non spiega cosa sia
  una beta

- Avendo creato la pagina per la ridistribuzione dei punti alla creazione del
  personaggio non serve più quella di randomizzazione delle stats e quindi
  l'ho rimosso.

- Detto questo, c'è da testare la creazione dei personaggi per la terza pagina

- Ho visto in un file html che viene utilizzata la riga
<meta http-equiv="Content-Style-Type" content="text/css" />
  l'ho aggiunta, magari serve a qualche cosa per sto css bianco

- Bisogna rimuovere il player dal nome Test2, che non ha un nome accettabile,
  per un baco ha accettato il numero fino ad ora.
  Inoltre ora come ora è impossibile per me capire facilmente se un parola
  inviata dal browser possiede degli accenti o meno, quindi niente, inseriranno
  i nomi lisci... bisogna aspettare python3 per questo. (buonanotte!)

- Adesso non c'è più la pagina di randomizzazione delle statistiche, questo
  perché ho creato la terza pagina di creazione del personaggio, che viene
  richiamata comunque quando un personaggio non "convertito" cerca di
  connettersi al gioco
  La pagina serve a ridistribuire i punti come uno vuole.
  Bisognerebbe inoltre passarsi tutti i mob e fare una personalizzazione delle
  statistiche a naso sulla scala 1-100


================================================================================
Rella 100
12/07/11

* Convertite le label X Y e Z della struttura RoomReset nella label Destination
  Quindi al posto di
RoomResets:
    ProtoRoom: home-batu_room_01-pentacolo
    X: 0
    Y: 0
    Z: 0
    [...]
  Si scriverà:
RoomResets:
    ProtoRoom: home-batu_room_01-pentacolo
    Destination: 0 0 0 home-batu
    [...]
  Da convertire quindi il tutto e aggiornare la documentazione a riguardo.
  Esiste già la pagina di destination, basterò creare un link ad essa, come
  nella pagina dei Portal mi pare.

* Rinominata l'etichetta da WalkerType a WalkerStruct
  In pratica tutte le strutture complesse relative alle entità che non hanno
  un riferimento nell'enumerazione ENTITYPE vengono chiamate Struct.
  C'è da aggiornare il cambio del nome della label nella documentazione.

* Aggiungere nella sezione [GAME] del file config.ini l'opzione
  max_behaviour_probability = 300

* Modificato il nome dell'opzione config.ini da
behaviours_only_for
a
behaviours_only_for_code

* Togliere tutte le etichette Deaths e Kills da tutti i file dat, ho cambiato
  i nomi dei contatori di morte e uccisione e questi non servono più.
  Probabilmente tutte le occorrenze saranno nei file dat dei player.

* Modificato il nome del metodo
get_keywords
in
get_keywords_attr
per non cadere nella tentazione di pensare che sia ritornata una lista
invece della stringa con le keywords, bisogna modificare tutti gli scripts
che lo utilizzano

* Tutte le etichette
FollowEntityMessage
  e
FollowOthersMessage
  Sono state spostate dal livello della stessa entità a quello del WalkerStruct
  (prima WalkerType come indicato sopra), ho aggiornato la documentazione a
  riguardo nella pagina walker.struct.htm.
  Inoltre le stesse le ho rispettivamente rinominate in
FollowEntityGoMessage
  e
FollowOthersGoMessage
  Come potrai vedere ho aggiunto la possibilità del messaggio no_send e un'altra
  etichetta:
FollowOthersComeMessage
  che serve per il messaggio di arrivo in una stanza, sempre descritta nella
  pagina htm.

- Questa versione è la famosa svolta di numerazione di versione, in cui la
  numerazione interna e quella esterna collimeranno con le effettive release.
  Sul sito si leggerà v1.0.0
  e per noi sarà la r100

- Aggiunta la struttura DeadTimeStruct, per le entità.
  Essà contiene le seguenti etichette:
DeadTimeStruct:
    Comment: commento
    Minutes: minuti rpg, la vecchia label DeadTime direttamente
accessibile nella precedente release
    EntityMessage: messaggio di act inviato all'entità da estrarre
    OthersMessage: messaggio di act inviato a tutti coloro che sono
nella locazione dell'entità quando viene estratta
End
  una delle due label EntityMessage e OthersMessage, o tutte e due, possono
  avere no_send come valore, ma si farebbe prima a non dichiararle in quel caso.
  Non ho inserito nessun tag $N, $a o simili, se dovesse servire qualcosa posso
  metterci mano perlopiù facilmente.
  Anche qui c'è un po' di documentazione da fare a riguardo.

- Ho aggiunto tra i soggetti checkabili nel MIML il
  contained_by
  da aggiungere al self e al looker.
  C'è da ricordarsi che un contained_by può essere sia stanza che entità.
  Ricapitolando si può fare per esempio:
  self is RACE.ELF
  looker is SEX.MALE
  contained_by is RACE.ELF
  C'è da ricordarsi che nei casi in cui contained_by sia una stanza il check
  ritorna sempre falso inviando al lettore la seconda parte del MIML.

- Aggiunto il MIML sulle uscite e sui wall, per esempio:
  contained_by[north] is Exit  --> vera se a nord c'è uscita
  contained_by[east] is Wall  --> vera se a est c'è un muro, e per
muro non si intende mancanza di uscita ma proprio una struttura di
etichetta Wall
  contained_by[northwest] is Door  --> vera se a nord ovest c'è una
porta (chiusa o aperta non importa, basta che sia sui cardini)
  contained_by[down] is EXIT.DIGGABLE  --> vera se l'uscita in basso è scavabile
  contained_by[up] is DOOR.CLOSED  --> vera se la porta in alto è chiusa
  Per tutti i check potete utilizzare sia is che is not a piacere, ovviamente
  is not ribalta la verità del check.
  Potete utilizzare qualsiasi flag di EXIT oppure qualsiasi flag di DOOR a
  piacere.
  Il tutto è nato pensando che sarebbe un lavoraccio fare tutte le combinazioni
  di uscite (diagonali, up e down) per il labirinto (visto che ora c'è questa
  possibilità grazie ai passage) e che questa potesse essere un'alternativa
  valida per le descrizioni di room già esistenti.
  Poi fate vobis, il sistema è cmq utile e andava sicuramente fatto prima o poi.

- Dovrebbero essere migliorate le prestazioni rimuovendo l'informazione relativa
  al nome della funzione riguardo ai messaggi di reset, repop e gamescripts

- Cambiato l'identificativo del funzionamento dei loop da {gl fl} / {GL FL} in
  una semplicissima {l} / {L} visto che tutti i loop sono sotto sotto legati in
  un unico.

- Ora quando si avvia il mud in official non verrà più inviato, nelle pagine
  web, l'informazione che evita di cacharle.
  Con questo, forse, non avremo più il problema della pagina bianca.

- Aggiunta l'etichetta WeekDay per la struttura Maze, indica in quale giorno
  della settimana rifare il labirinto, se utilizzata dev'esserci assieme anche
  l'etichetta RemakeHour definita.

- Aggiunta l'etichetta RemakeMessage per la struttura Maze, è un messaggio
  che viene inviato a tutte le entità del labirinto a stretto contatto con
  le stanze quando questo viene rifatto.
  L'etichetta è facoltativa, se non viene impostata il labirinto viene
  inviato il messaggio che già esiste.
  Può essere invece impostato il valore no_send per evitare un qualsiasi
  messaggio di remake.
  Da aggiornare nella documentazione.

- Aggiunte le etichette-struttura
BehaviourMob
BehaviourItem
  alle stanze.
  Hanno le stesse sotto-etichette dei behaviour dei mob e degli item.
  I mob in quella stanza invece di seguire i behaviour propri seguiranno quelli
  della stanza (BehaviourMob), mentre gli item invece di seguire i propri
  seguiranno quelli della stanza (BehaviourItem).
  I mob e gli item che seguono i behaviour di stanza sono sia quelli che hanno
  dei propri behaviour, sia quelli che non ne hanno.
  Si può dire ad un mob o ad un item di non seguire i behaviour di stanza
  tramite la flag NO_ROOM_BEHAVIOUR
  C'è da ritestare un po' il funzionamento grezzo dei behaviour, a vedere
  se tutto funzioni viste le modifiche apportate.

- Ora creando un nuovo account si può generarne il nome anche inserendo dei
  numeri oltre che delle lettere, accentate o meno.

- Ora a seconda del numero di morti il valore dei px persi varia.
  C'è un logaritmo di mezzo, con poche morti i punti persi saranno minori,
  mentre man mano il valore crescerà, per esempio a 100 morti il valore
  raddoppierà.
  Per ora non c'è modo di vedere il totale delle proprie morti, sorry.
  Volendo è possibile impostarle via script tramite l'attributo
  defeat_from_mob_counter.

- Ho reso i cadaveri meno anonimi donandogli la "short" nella long, praticamente
  ho fatto lato codice questo:
        corpse.keywords       = self.keywords + " cadavere"
        corpse.keywords_short = self.keywords_short + " cadavere"
        corpse.name           = self.name
        corpse.short          = self.short
        corpse.short_night    = self.short_night
  Ho pensato che fosse meglio che tu sapessi cosa vi fosse dietro alla modifica
  per poter pensare meglio in termini di keywords, su cui ho ancora qualche
  sospettosa incognita relativamente all'usabilità da parte del player.

- Ho creato un loop a parte, il decomposer, che serve a far marcire i cadaveri
  piano piano aggiungendo un'ora rpg alla struttura CorpseType e facendo
  cambiare automaticamente la long dei cadaveri.
  Ci sono 5 descrizioni, ognuna cambia ogni 24 ore rpg, ora più ora meno
  non importa.

- Ho creato la struttura entitype CorpseType, relativa ovviamente all'UsedAs
  CORPSE, essa contiene solo un'etichetta:
  DecompositionHours
  Che rappresenta il numero di ore rpg dalla morte del mob (o dell'item).
  Di solito questo valore viene automaticamente aggiornato partendo da zero,
  ma magari si vuole impostare via file dat un particolare cadavere con una
  certa... vita alle spalle!
  Ricordo che ad ogni 24 ore rpg la long visualizzata cambierà automaticamente
  per un massimo di 5 volte.
  Da aggiornare il manuale con la nuova tipologia.

- Implementato il sistema di repop, ad ogni reset di tipologia RESET.NONE,
  RESET.PUT, RESET.BURIED, RESET.PLANTING e RESET.ADD, verrà attivato un timer
  di repop pari al valore in minuti impostato nell'area: RepopTime, che
  rappresenta i minuti REALI (e ripeto reali!) di tempo che una entità
  ci mette a rinascere.
  Bisogna passarsi tutte le aree per dare dei valori RepopTime adeguati.
  Da precisare che tale valore varia casualmente tra un valore del meno
  10% o in più.
  Cosa curiosa il tempo di repop non parte dalla estrazione dell'entità
  quanto invece dalla sua nascita.. il sistema è così, se lo si vorrà
  diversamente dovrò rifarlo tutto (se ci si pensa attentamente anche
  il vecchio sistema nei mud classici è così, solo che funziona per tutte
  le entità in una volta sola).
  Da notare, cosa molto importante, che i repop avvengono solo per i reset
  che non hanno una data definita, cioè i reset di default.
  Se si vuole che un'entità non venga repoppata si può aggiungere la flag
  FLAG.NO_REPOP all'etichetta Flags dell'entità.
  Il sistema di repop ha il suo bel loop, impostabile con l'omonimo e ormai
  conosciutissimo comando.
  I messaggi di log relativi ai repop e quelli relativi ai reset sono uguali,
  l'unica differenza è la tipologia tra parentesi quadre stampata prima del
  messaggio e dopo la data di invio dello stesso.
  Forse ci sarà bisogno di diminuire le tipologie di RESET.XXX per il repop,
  da pensare.
  Nelle prossime release effettuerò anche un repop dello stato di chiusura
  o apertura delle porte e dei contenitori.

- Modificato il punto in cui si aggiorna il valore current_global_quantity
  prima era nei metodi from_entity e to_entity, ora è nei metodi inject
  ed extract.
  Questo dovrebbe diminuire casini di +1 -1 nelle varie manipolazioni
  delle entità, isolandoli al solo inserimento in game ed estrazione finale.
  Bisogna provare tutto ciò soprattutto per lo script della crisantema.

- Non stupirti se leggi meno messaggi di reset, ora i reset delle entity vengono
  stampati solo se effettivamente è stato resettato qualche cosa, è una cosa che
  risulta utile poi anche per i repop, altrimenti riempiva di messaggi inutili.
  Quindi può capitare un messaggio di reset di room senza successivi messaggi
  reset entity, tutto normale.
  Se vuoi poi per debug riottenere i messaggi mi fai un fischio che ti indico
  il codice da manipolare.

- Ora si può utilizzare l'etichetta Owner per indicare il codice del
  proprietario dell'entità.
  Il codice inserito, se non quello di un giocatore, è necessariamente quello
  di un'entità di prototipo, in quel caso qualsiasi mob o item derivante da
  quel prototipo è il proprietario di quell'entità.
  In futuro questo attiverà comportamenti specifici di possesso e quindi di
  attacco, per esempio se un giocatore raccoglie l'entità in possesso da un
  mob.

- Creata la pagina di admin remove_npp.html, serve a rimuovere tutte le
  persistenze tranne quelle relative ai personaggi.
  Il check è esteso, nel senso che non vengono rimossi non solo a mob e gli
  oggetti che si trovano nell'inventario o addosso al personaggio, ma anche
  le entità che si trovano per terra ma che hanno come owner un player.
  Questo significa che qualsiasi oggetto droppato da un player non viene
  rimosso dalla NPP.
  La sigla NPP significa: Not Player Persistence.
  È tutto da testare ed è una cosa delicata.


================================================================================
QUI C'E' UN GAP DI NUMERO DI RELEASE 94, CHE ERA LA VERSIONE V0.9U, E LA
RELEASE 100, CHE AVEVA COME VERSIONE V1.0.0, IN SOSTANZA SONO STATE ALLINEATI
IL NUMERO DI VERSIONE CON QUELLO DELLA RELEASE.
================================================================================


================================================================================
Rella 94
13/06/11

* Rinominata nel file di config la sezione [GENERAL] in [GAME].
  Spostati dalla ormai ex sezione [GENERAL] alla sezione [SERVER]
  le seguenti opzioni:
save_persistence
allow_player_gaming
max_google_translate
text_color
max_compatibility_msg_len
allow_multiplaying
compression_mode

Inoltre, sempre relativamente al config, rinominata l'opzione max_attr_value in
max_stat_value

Aggiunte le opzioni nella, ormai, sezione [GAME]:
max_skill_value = 100
clumsy_value = -100
failure_value = 50
success_value = 200
masterly_value = 250


* Fai attenzione alla cartella icon/gem, tra la tua e quella di questo
pacchetto,
  visto che io avevo un problema non vorrei che siano andate perdute delle
  immagini o chissà quali altri casini.
  In particolare guardando bene l'avvio del mud ho carpito codesto messaggio:
  01:56:52 [Booting] {gl fl}: File d'immagine inesistente per l'icon:
www/icon/gem/stones_quartz.png

- Aggiunte le flags:
NO_MOB
NO_ITEM
NO_ROOM
NO_PLAYER
  Sia per l'etichetta Flags delle Exits sia per l'etichetta Flags delle rooms.
  Se viene impostata in un'uscita si può eventualmente entrare da un'altra;
  mentre se la si imposta per la stanza allora è valida per tutte le
  exits che portano ad essa.
  NO_ROOM per ora è inutilizzabile, visto che le stanze non vengono ancora
  gestite come entità.
  Bisogna testare che funzionino e soprattutto che, come suggerito da te,
  i mob (o altra entità soggetta a FLAG.NO_xxx) riescano a entrare comunque
  se stanno seguendo qualche altra entità.
  I player invece NON possono entrare neppure se stanno followando se esiste
  la relativa flag NO_PLAYER.
  Ho immaginato come casistica una stanza con tutte le entrate NO_PLAYER ma
  che ha un'entrata portal utilizzabile (giusto un'idea per i builder insomma).


- Aggiunta l'etichetta Flags alla struttura PortalType e le relative flags:
NO_MOB
NO_ITEM
NO_ROOM
NO_PLAYER
ad uso e consumo oltre a quelle già elencate precedentemente.


- Aggiunta la ricerca delle flag CONTAINER, DOOR e PORTAL per il comando
  countflags


- I comandi command_countraces e command_usedexits non effettuano più controlli
  sulle entità propotipo.
  È una questione di concept, i comandi admin nel mud devono solo manipolare le
  istanze mentre per la manipolazione delle entità prototipo ci dovrebbero
  essere delle pagine admin a parte.


- Ho aggiunto un'iconcina di fianco al nome delle stanze visualizzabile quando
  si è all'esterno. Essa mostra un sole se giorno altrimenti la luna, è utile..
  però penso che bisognerebbe spostarla in altro punto, ma per ora non ho
  molta ispirazione.


- Ho inserito delle icone-bottoni nuove nell'interfaccia, non ho resistito per
  il taste non trovando altro, per un po' ci teniamo questo stile à la
  rolling stones :P
  Non c'è il senso dell'intuito per ora, dovrei creare un'altra colonna per
  aggiungerlo quindi aspetteremo.


- Creata la funzione di generazione dei cadaveri mob post combattimento
  (ho ucciso il mindf, è proprio brutto vedere un cadavere umano per un mindf
  ci vorrebbe un cadavere generico oppure proprio farli tutti mano a mano).


- Allora:
  Per le porte
  che non hanno una doppia porta
  che hanno behaviour sensoriale o RandomDo
  (quindi non i wander behaviour)
  il 50% delle volte verrà ad attivarsi il behaviour sull'altra stanza
  Mi pare di ricordarmi che i behaviour si attiverebbero sia che la porta
  sia aperta che chiusa, se si vuole che funzionino solo se chiusa, allora
  bisogna dirmelo.
  Se mi sfugge un caso REALE per i behaviour nel wander basta indicarmelo
  e poi ci penso, che è un po' un casino metterci le manine lì, è già tanto
  poi avere una porta camminante non penso che serva vederla camminare
  partendo da un lato specifico e basta.


- Aggiunto il comando destroy come sinonimo per l'attacco sugli oggetti
  invece dei soli comando kill o attacca.


- C'è poi una cosa da fare una tantum: dopo aver avviato il mud andare al link
  random stats che c'è nel menù degli amministratori e cliccare sul bottoncino
  magico che si trova in quella pagina.
  Così anche se non ho preparato nessuna pagina di personalizzazione del
  personaggio e non ci sta ancora il leveling, almeno abbiamo dei valori
  di statistiche più o meno congrui per tutti i personaggi.


- Modificato il nome delle etichette
WanderAtDirs
WanderAtDirsFlags
  rispettivamente in
WanderAtExits
WanderAtExitsFlags
  Funzionando ora non più alle direzioni qualsiasi, ma alle uscite reali come
  ne avevamo già parlato; così da avere mob più reattivi.


- Modificata come su richiesta la pagina dei crediti


- Le mail sulle note ora visualizzano anche il testo dei messaggi.
  C'è quindi da controllare se i messaggi di nota vengono inviati via mail
  o se ho rotto il flusso di qualche cosa.


- Implementata la skill di counter, è una skill che entra automaticamente
  ad inizio combattimento che permette al difensore di evitare il primo
  attacco e invece di attaccare per primo.
  In effetti mi sa che più che counter come nome dovrebbe averne un altro...


- Ho creato un sistema per inserire in maniera libera qualsiasi numero
  d'ingressi, uscite o nicchie ad un labirinto.
  Tali cose vengono chiamati Passages.
  La sintassi è la seguente:
  Maze:
    Columns: 3
    Rows: 3
    Passages: 0 0 1 maze_room_entrata_che_si_trova_in_alto
    Passages: 3 2 0 maze_room_uscita_che_si_trova_a_nord_est
    Passages: 1 1 -1 maze_room_nicchia_con_tesoro_in_basso
  End
  Ricordando che il conteggio parte da 0 fino a 2 per le stanze entro la
  griglia del maze.
  Se fai attenzione tutte le coordinate si trovano attorno all'anello di room
  esterno, il bordo, per coordinate con z uguale a 0, mentre per coordinate
  con z 1 o -1 si possono inserire Passages a qualsiasi coordinata x,y relativa
  alla superficie del labirinto.
  Sì immagino avrai altresì notato che si possano difatti inserire room in
  alto e basso (sempre più rogue-like!).
  Volendo puoi inserire un labirinto con 8 entrate e un portale in mezzo,
  facendo entrare 8 player, scannarsi tra di loro e poi poter uscire, una
  specie di labirinto arena scriptato... insomma tanto per far capire.

  Ho dei dubbi sulla correttezza del metodo get_error_message della classe
  MazePassage, magari dagli un occhio, così voi builder sareste a posto,
  in pratica lì vengono elencate le coordinate valide da inserire.

  Relativamente al maze ho modificato un po' il codice e visto che la paternità
  del codice è metà tua dovresti dargli un'occhio, qui e là l'ho un po'
  ribaltato ma direi non troppo.
  Da tener presente però che ho rimosso le etichette RoomInsideX e relativa Y
  e tutto il codice che ti sei sudato; ma penso non servirà più:
  già con il concetto di passage-nicchia siamo metà a posto, adesso il
  prossimo passo è quello di poter dare la possibilità d'inserire le dead-ends,
  cioè delle stanze con una sola uscita da inserire a caso ad un vicolo cieco
  già esistente nel labirinto.
  Le Dead End saranno delle stanze originariamente senza uscita, essa verrà
  creata durante l'inserimento casuale nel labirinto, mantenendo la stessa
  struttura delle uscite del labirinto, ciò significa che le descrizioni
  delle DeadEnd non dovranno avere dei riferimenti all'uscita, perché questa
  verrà inserita solo successivamente.
  Invece, da quel che ho capito, il tuo sistema di RoomInside era possibile
  puntare la direzione dell'uscita; non ho trovato reale utilizzo in ciò e
  preferirei la mia soluzione.
  Le dead end, verranno inserite casualmente in un qualsiasi vicolo cieco del
  labirinto che non tangi però una casella di un passaggio, in pratica non
  potrà essere una delle 6 caselle attorno ad un passaggio (4 direzioni
  cardinali + alto e basso). Questo per allontanare un po' le probabilità che
  stanze con il tesoro si trovino subito accanto ad entrate o uscite.
  Oltre alla stanza di DeadEnd da inserire ci sarà una eventuale porta da
  associargli, opzionale.
  Alla fin fine le DeadEnd vanno usate per stanze segrete o stanze del tesoro
  cui non interessa avere un'uscita specifica di una determinata direzione.
  Altrimenti si utilizza un Passage anche se non si può trovare ovviamente
  all'interno di un maze.

  Tutto quello che ho scritto relativamente (ma ti accorgi che la scrivo troppo
  spesso questa parola? miah...!) alle DeadEnds, nonostante non le abbia ancora
  implementate, è giusto per fare pulizia mentale di quello che ci sarà.
  Se ti sembra che vi siano dei leak nel mio pensiero poi fammi sapere, possiamo
  sempre tornare indietro con pezzi di codice relativi alla room inside con un
  file vecchio.

  Del Maze ho inoltre buttato via l'etichetta RoomSize e ovviamente
  InitialRoom, FinalRoom e MiddleRoom non l'ho neppure utilizzata.

  Se la room relativa al passaggio non possiede l'uscita per arrivare
  alla stanza del labirinto questa viene creata automaticamente.
  Questo significa che se non viene inserito un passaggio qualsiasi, anche
  in alto e in basso o tra i 4 angoli all'esterno al labirinto
  (direzioni diagonali),  questo viene creato automaticamente.

  Il brutto di tutto questo sistema (di uscite alto basso e diagonali) è il
  fatto che le descrizioni del labirinto sono pensate per le sole 4 direzioni
  e che quindi quando appaiono altre uscite queste non vengono indicate.
  Forse la soluzione del problema è solo quella di inserire tali uscite solo con
  delle porte segrete ma... mi sta venendo in mente un'idea MIMLOSA a riguardo..
  Aspettiamo a vedere cosa salterà fuori.
  L'alternativa è fare delle descrizioni per tutte le varianti :P
  Mi sa che arriviamo a.. 100?
  Cazzo, quanto piove stanotte... (come sono lesto a cambiare argomento...)

  Bisognerà anche aggiornare le pagine di documentazione.

  Ti inserisco di seguito quello che dovrebbe essere la nuova struct di maze
  e di villaggio-zingari-maze, ma controlla bene se è quello che veramente vuoi:
Maze:
    RemakeHour: 17
    Columns: 12
    Rows:    12
    CodePrefix: karpuram_room_bosco
    Passages: 12 12 0 maze_room_accesso-ne
    Passages: -1 -1 0 maze_room_accesso-sw
End

Maze:
        RemakeHour:     12
        Columns:        5
        Rows:   7
        CodePrefix:     villaggio-zingaro-maze_room_grotte
        Passages: 2 -1 0 villaggio-zingaro-maze_room_exit-sud
        Passages: 2 7 0 villaggio-zingaro-maze_room_exit-nord
End


- Non ho fatto nulla relativamente al discorso delle closed door (che in alcuni
  wander behaviour vengono considerate ed in altri no) e che ci sballa un po'
  le probabilità di wander e il comportamento.
  La modifica è complicata, non tanto tecnicamente, ma quanto alle varianti
  di implementazione possibili e devo ancora fare chiarezza di tante cose,
  magari ti romperò le balle per chiederti cosa ne pensi.


- Aggiunta la flag di entità, cioè sia per mob che per item, FLAG.RANDOMIZABLE.
  Tale semplice flag è una cosa che risulterà molto potente in futuro.
  Essa infatti indica se quell'oggetto è inseribile in un baule per la creazione
  casuale di un tesoro. (gemme, monete e quant'altro)
  Oppure se viene utilizzata sui mob indica che quel mob può essere utilizzato
  per il resetting casuale nella wild attorno a quell'area.
  E' sicuramente meglio inserirla sugli oggetti o mob che appaiono allo
  sguardo... generici, cioè senza che abbiano nelle descrizioni o tra le loro
  etichette alcune particolarità o proprietà che li legano all'area di origine.
  Insomma gli oggetti relativi alle quest NON sono randomizzabili.


- Ho fatto una modifica per cui in questa versione ci dovrebbe essere meno
  consumo di ram nel medio tempo, tali consumo avveniva con gruppi di tanti mob
  che behaviouravano (poteri della 2.6...)


================================================================================
Rella 93
15/05/11

* Aggiunta l'opzione di config.ini max_attr_value da impostare a 100
* Aggiunta l'opzione di config.ini max_level da impostare a 200
* Aggiunta l'opzione di config.ini output_end_tag da impostare a <e>

* Ho modificato il codice delle 4 razze ATRONACH in ELEMENTAL, quindi
  FIRE_ATRONACH diventa FIRE_ELEMENTAL etc etc

* Bisogna rimuovere tutte le opzioni di account:
OPTION.AUDIO
OPTION.AUTO_GET
  difatti ho rimosso per sempre l'autoget, mentre l'audio l'ho spezzato in
  sonoro e musicale, tuttavia ho fatto in maniera tale che le opzioni
  relative all'audio non vengano utilizzate nella pagina di account

* Relativamente alle icone la path non è più, per esempio:
icons/animals/cow.png
  ma
icon/animal/cow.png
  quindi in pratica a tutte le cartelle iconose ho tolto la esse finale, le path
  quindi devono essere aggiornate di conseguenza nei file dat

- Non ho ben capitoil perchè e se è effettivamente così, ma mi pare che l'avvio
  sia molto più lento rispetto alla release precedente..
  Me lo potresti confermare?

- Ora che il combattimento è in pista le seguenti etichette per mob (e pg)
  sono divenute obbligatorie:
  Strength:  Peso trasportato, potenza delle botte etc etc
  Endurance:  Recupero fatica, potenza contro i veleni e malattie
  Agility:  Agilità nello scansare i colpi, abilità del rubare e simili
  Speed:  Velocità nei turni di combattimento
  Intelligence:  casting degli incantesimi, se maggiore dà più punti di train
  Willpower:  mana per incantesimi o skill, potere contro attacchi mindflyosi
  Personality:  Fico!
  Luck:  Culo!

- Corretto un bachetto nel comando setrace

- Ho inserito nuove icone per gli amministratori, guguguguguugu!

- Creata una nuova pagina di login, più accattivante

- Ho aggiunto per ogni messaggio di log stampato lo stato dei due loop
  attualmente implementati
  {gl fl} quando tutti e due non sono attivi
  {GL FL} quando tutti e due lo sono
  {gl FL} quando la game loop non va' mentre la fight loop sì, è una caso
  particolare che non dovrebbe mai accadere se ho capito come funziona il
  codice, tuttavia se dovesse capitare bisogna avvertirmi; stesse
  considerazioni se {GL fl}

- Ho diviso in due la pagina di account per future modifiche d'interfaccia

- Implementata l'etichetta WanderAtSectors, una flag di SECTOR che permette
  di far wanderare i mob e/o gli item solo nei settori impostati, utile per
  esempio per far camminare i lupi solo nei settori boschivi, e così via.
  Da aggiornare il manuale.

- Migliorata l'usabilità della piazzetta

- Ho spezzato le notizie nella index.view in tanti piccoli dat nella cartella
  data/news, d'ora in poi bisognerà utilizzare quelli per creare delle nuove
  con numero crescente, il formato è auto esplicativo, direi che non vi sia
  bisogno di creare una pagina apposita di manuale, visto che non + una cosa
  relativa al building.

- Nel file RACE.py ho impostato a tutte le razze la possibilità di personalizare
  i verbo di movimento, ad esempio:
PIXIE.go_verb_you,           PIXIE.go_verb_it,
PIXIE.come_verb_it,           PIXIE.run_verb_you,
PIXIE.run_verb_it           = "guizzi", "guizza", "guizza", "sfrecci",
"sfreccia"

- Oltre a ciò che ho fatto sopra ho creato un altro Entitype:
WalkerType:
  che permette di personalizzare i verbi di movimento per entità che si muovono
  in maniera particolare (zoppicando), le etichette supportate sono:
GoVerbYou: Vai
GoVerbIt: va
ComeVerbIt: viene
RunVerbYou: Corri
RunVerbIt: corre
  Ho inserito come esempio i valori normali, da notare le maiuscole e minuscole

- Ora tutto le entità che si trovano sott'acqua nuotano.

- Ho fatto in modo che ora le descrizioni che vengono lette nel browser non
  siano quelle inserite nei file dat relativamente agli a capo, era una
  questione che avevamo discusso ancor prima dell'ultima apertura; adesso
  difatti l'andare a capo viene gestito da aarit.
  Ciò comporta che tutte quelle righe che sono state pensate invece con il
  vecchio sistema ora si leggono tutte attaccate (come i comandi nelle stanze
  iniziali) per ovviare a ciò ci sono due metodi, o inserirvi un punto a fine
  ogni comando, oppure un tag html <br> per forzare l'a capo.

- Il comando goto ora funziona solo con i giocatori, cmq ovviamente si
  può utilizzare il comando mgoto per puntare ai mob
  Purtroppo ho dovuto cambiare il nome del comando igoto in ogoto, cmq in
  realtà l'input igoto funziona perchè è un sinonimo nascosto.. quindi non è
  che cambi più di tanto

- Implementati i comandi invoke, minvoke e oinvoke
  il primo invoca i personaggi nel luogo dell'admin
  il secondo il primo mob che trova passato con argomento
  il terzo il primo item che trova passato con argomento

- Relativamente al reset day il problema mi attendo che non accada più.
  Ho spulciato il codice di twisted e da quel che ho capito la differenza
  tra la deferLater e la callLater (che usavamo per tutto) è che la prima
  esegue una cosa dopo x secondi.. ma potrebbe anche per qualche motivo
  eseguirla pochi secondi dopo (carico sul server, connessioni, resolving DNS
  etc etc); la seconda invece se gli dici di attivarla dopo x secondi lo fa
  dopo x secondi a meno di bachi o situazioni al limite dell'improbabile
  nella norma.
  Quindi noi usiamo sempre la deferLater che è più debuggabile, mentre la
  callLater torna a far capilino in quei punti in cui ci serve assolutamente
  un evento preciso dopo tot secondi, negli script puoi utilizzare senza
  problemi la deferLater direi.
  L'unico difetto della callLater è che i crash di stack avvengono solo nello
  shutdown (quando vengono fermati i vari loop) e non nel momento stesso di
  quando avvengono.
  Una cosa simile ti era capitata negli ultimi tempi, ricordi? Doveva essere
  un meccanismo loop-twisted simile che crashava tempo prima ma veniva
  visualizzato solo durante lo shutdown.

- Implementata la cosa della extra suggerita da batu e di cui ne abbiamo parlato

- Le etichette Life, MaxLife, Mana, MaxMana, Vigour, MaxVigour sono passate
  dall'essere solo mobbose ad esserlo anche itemose
  la life di un'oggetto è intesa come sua condizione; il mana per esempio di
  una bacchetta sarà inteso come quante cariche ancora può lanciare prima di
  dover essere ricaricato.
  Da aggiornare la documentazione a riguardo.
  Relativamente al vigour non ho in mente nulla al momento, suggerimenti sono
  ben accetti.

- Creati i comando create, ocreate e mcreate
  il primo crea un mob partendo da un pg
  il secondo create un oggetto partendo da un prototipo di oggetto
(insomma ne crea un'istanza come un reset)
  il terzo creare un mob partendo da un prototipo di mob (insomma ne
crea un'istanza come un reset)

- Ora si possono ri-mangiare entityà cibo senza danni, spero
  Si possono altresì senza danni droppare e wearare oggetti ingeriti e in
  digestione (tutto da testare)


================================================================================
Rella 92
24/04/2011

* Devi passarti tutti i gamescript e modificare tutte le occorrenze di
engine.db
in
database
poi devi cambiare tutte le occorrenze di
from src.engine import engine
in
from src.database import database
attento alle spaziature in "from src.engine import engine" che tra una keywords
ed un'altra potrebbe essere più di una.

* Attenzione che ho ricavato i dati da una versione di backup andando a
  cancellare lo script modificato che ti avevo fortunatamente però inviato.
  Comunque alla fin fine non ho modificato altro nei gamescript quindi puoi
  stare tranqui.

* Non preoccuparti all'avvio per gli errori della label EatenEntities, è
  relativo alla correzione del baco degli esserini mangiati

- Ora l'etichetta RandomDoInputs oltre ad inviare i comandi invia anche degli
  echo nella locazione, basta scrivere una etichetta RandomDoInputs che non sia
  un comando valido e questa verrà inviata come se fosse un'echo
  Quindi ocio a non sbagliare la sintassi dei comandi :P ricorda che vengono
  visti come validi solo i comandi in inglese.
  Da aggiungere nel manuale.

- Ho riordinato il menù a sinistra nel sito web degli admin alfabeticamente
  invece che per settori (master, builder e implementor) vedi un po' se ti
  ritrovi

- Aggiunta l'etichetta WeaponType che è una struttura di entitype di formata
  in questo modo:
WeaponType:
    Category: WEAPON.BASTARD
    Flags: WEAPONFLAG.ONE_HAND WEAPONFLAG.TWO_HANDS
End
  Come vedi l'arma sopra può essere sia ad una mano che a due mani, bisogna
  esplicitare per forza se bisogna utilizzarla con una mano o con due o tutte
  e due, in futuro nessuna flag farà in modo che l'arma non sia wieldabile.
  C'è da aggiornare la documentazione riguardo questa novità.

- Ho altresì aggiunto la tipologia d'enumerazione ENTITYPE.WEAPON per
  l'etichetta UsedAs

- Ho creato il comando countflags, esempi di sintassi:
  countflags no_look_list
  countflags FLAG.NO_GET
  countflags TWO hands
  etc etc

- Creato il comando setrace, molto semplice da utilizzare, fa quello che ci
  si aspetta

- Implementato il comando slay, finalmente possiamo sfogarci!
  Lo slay sui player è possibile solo dagli IMPLEMENTOR (più per test
che per altro)

- Ho implementato una possibile soluzione al problema delle porte che dovrebbero
  behaviourare anche sull'altra stanza, per ora funzionano solo sulle tipologie
  di behaviour relativo al sense-player, cioè LookPlayer, TouchPlayer etc etc..

- Ho modificato ancora il comando loop, da provare e tenere d'occhio
  con il fight bacato si farà in fretta a testarlo, il fight ora si trova in
  un loop separato

- Ti ricordo che ho modificato pesantemente il sistema di digestione e che ora
  e d'ora in poi richiamo di tanto in tanto di manipolare gli oggetti
  direttamente dallo stomaco come se fossero in inventario (in effetti è
  proprio così anche se sono nascosti il più delle volte!)

- Ho inserito l'etichetta DeadTime, questa si attiva solo nel metodo inject,
  ovvero quando si resetta o si inserisce un'entità nel gioco tramite questo
  metodo appunto.
  Si disattiva in qualsiasi momento l'entità entra nel metodo from_entity,
  un get, uno script, qualsiasi cosa che lo sposti da lì..
  C'è da aggiornare il manuale a riguardo, l'etchetta è sia per mob che per
  item.
  Per la natura oscura delle deferred è difficile conoscere quanti secondi
  sono passati da quando si è avviato il conto alla rovescia della morte
  comunque ho inserito tale valore nella tooltip del look perché
  ritengo che sia rilevante ricordarselo per i test.


================================================================================
Rella 91
13/04/2011

- Ho disattivato i behaviours a tutte le porte segrete e chiuse oppure già
  aperte. Bisogna provare un po' la cosa, se si vorrà diversamente se ne dovrà
  discutere un po'.

- Corretta la pagina config_options a cui mancava l'enumerazione TRUST

- C'era un baco sull'account che non confrontava correttamente le password.
  Penso che anche l'ultima apertura il baco vi fosse evitando allegramente
  nuove creazioni di giocatori

- C'era anche un baco sulla creazione del pg, questo però che lo portiamo
  dietro solo dalla release precedente

- Per motivi di comodità adesso l'avvio del mud si blocca se ha degli errori
  critici E se lo si sta avviando in modalità official

- Ho aggiunto la razza RACE.MIMIC che ti descriverò se mi contatti a riguardo.
  Ho rimosso la razza babbuino e aggiunta la RACE.MONKEY

- Ho rimosso il SECTOR.UNDERWATER e l'ho inserito come flag di stanza:
  ROOM.UNDERWATER Un po come ho fatto con l'INSIDE, ricordi?

- Aggiunta l'opzione text_color nel config.ini nella sezione [GENERAL], per
  ora dere rimanere così:
  text_color = silver

- Corretta una cosa relativa al sistema di raggruppamento oggetti uguali, in
  pratica se due oggetti con due long uguali ma icona differente venivano
  comunque raggruppati come uguali, bisogna testare che questa cosa funzioni
  ora.

- Ho migliorato il sistema di shutdown inserendo un'avviso sotto il menù per
  tutte le pagine (visualizzabile per ora solo agli admin, sarà il caso di
  farlo vedere a tutti i giocatori?)
  Inoltre ogni 15, 10, 5, 1 minuto e poi ancora un secondo verrà visualizzato
  un messaggio a tutti i giocatori dell'avvicinarsi dello shutdown.
  Ho testato tutto.

- Creata la pagina di admin del datatree, sarebbe stata la feature della release
  ma alcuni impedimenti (funziona solo sotto goggle chrome e abbisogna di python
  2.6 per un dialogo json-ready tra aarit e le librerie jquery che utilizzo per
  creare il tree (le jquery me le aveva suggerite una anno fa circa VV)).
  Comunque sia sarebbero il nuovo modo di vedere i dati, immaginati l'aggiunta
  delle labels con i valori et voilà. Manterrò cmq il sistema tabulare perché
  ha comunque ancora senso penso.
  (Poi ci ho messo un "po'" di lavoro…)

- Il sistema dei counter è stato rimaneggiato più o meno pesantemente, andando
  altresì a toccare il sistema di find_entity (che aveva inoltre un bachetto a
  meno che non abbia travisato quello che volevo fare tempo addietro).
  Ergo per cui se ci sono dei problemi di ricerca d'entità o che è colpa del
  nuovo sistema di counter.
  Ora funziona in maniera tale che quello che vedi e quello che raccogli sono
  ordinati nella stessa maniera (cioè il punto di vista relativo del pg).
  Adesso lo stesso sistema di counter e di icone l'ho implementato anche
  nell'inventario.

- Relativamente al problema delle entità NO_LOOK_LIST ho trovato come soluzione
  quella di inserire, nella lista delle entità "counterate", di inserire come
  ultime nella stessa lista le entità con tale flag, questo così serve ad
  evitare che un get 2.pomodoro, con due pomodori visibili a terra e uno in
  NO_LOOK_LIST, a raccogliere per sbaglio quello in NO_LOOK_LIST.
  Essendo ultimo nella lista dei counter significa che solo tramite un get
  3.pomodoro raccoglierà il pomodoro NO_LOOK_LIST.
  TUTTO DA TESTARE, NON CI METTO LA ZAMPA SUL FUOCO!


================================================================================
Rella 90
19/03/11

* Ho riconvertito le tre occorrenze di opzioni di config che iniziavano con
  disable_ in use_, pardon il casino ma è meglio così.
  Comunque stavolta non dovrei aver fatto casini nel codice, ho già
invertito
  la logica però anche tu dovrai invertirla nel file di config in maniera
tale
  che il tutto funzioni ad uopo.

* Aggiunto un sistema di resetting delle connessioni in IDLE che quitta i pg
  che stanno più di 15 minuti senza fare nulla, l'impostazione del tempo di
  sconnessione è impostabile tramite file di config con l'opzione, da
  aggiungere, max_idle_seconds, ora impostata a 900.

* Ho rinominato l'opzione di config periodical_check_time in
periodic_check_time

- Rimaneggiata la myrandint, prima eseguiva erroneamente un algoritmo di
  WichmannHill per la generazione dei numeri casuali, mentre la libreria
  ufficiale la utilizza solo in casi "disperati" (e non l'avevo capito) e
  quindi suppongo che non fosse un gran che come algoritmo rispetto a quello
  standard (quindi il fatto che ritornasse valori simili era normale).
  Adesso ho tagliato la testa al toro e viene utilizzata la funzione
originale,
  (proprio utilizzando il modulo random e la funzione randint, come ai tempi
  insomma) ciò significa un grosso peso prestazionale...
  Tuttavia ho poi risolto il problema alla radice utilizzando la libreria
  numpy per la gestione dei numeri casuali (è roba seriosa, scientifica e
  veloce) l'installazione della libreria è opzionale, se non esiste
  utilizzerà la versione lenta.
  In generale cmq ora si utilizza così:
  import random
  number = random.randint(1, 4)

- Aggiunta l'informazione tooltip comment per la pagina delle aree nella
  biblioteca ma visualizzabile solo per gli account con TRUST di admin

- Ho unito tutti i file di log relativi ai triggers e ai behaviours in
un'unico
  per non avere un'inutile pletora di files.

- Ho modificato il sistema di creazione dei personaggi in maniera tale che
ora
  non vi siano conflitti se esiste già un personaggio in gioco e se ne sta
  creando uno nuovo, c'è da testarlo un po', anche facendo cose bastarde
come
  saltando da un link ed un altro delle due pagine di create_player2.html,
  oppure andando direttamente alla seconda con o senza un altro personaggio
  online.
  Mi raccomando che anche tu sai che è una pagina critica, se non funziona
  quella non entrano giocatori e buonanotte.

- Adesso ci sarà un avviso nel qual caso che un builder si confonda e
inserisca
  una serie di elementi in un'etichetta pensando che sia una Flags, e che
invece
  è un Element.
  Il problema era nato nel caso che avevi scritto tempo fa:
  UsedAs: ENTITYPE.FOOD ENTITYPE.SEED
  che era ovviamente sbagliato.

- Pensare di unire la stanza degli oggetti nell'area dei newbie con la
stanza
  di benvenuto che è un po' ridondante, te l'avevo già accennato, non so se
  poi tu l'abbia già fatto.

- Ho reinserito il comando loop, che già esisteva nella release numero 80,
non
  chiedermi tanto il perché, mi son pentito di averlo rimosso e basta.

- Adesso se nel boot esistono errori di caricamento relativo i riferimenti
  (o altri errori critici) il boot del mud non verrà portato a termine,
questo
  per metterci nell'ottica che i riferimenti prima di un avvio del mud
devono
  essere a posto (cosa importante quando saremo un mud avviato, con pg
  persistenti e balle varie).
  Per evitare ciò, che in fase di test sennò sarebbe una palla, si può
avviare
  il mud con l'opzione -i, oppure --ignore.

- Ho aggiunto il sistema di AUTO_OPEN anche sul get di oggetti dentro
  contenitori chiusi, da testare se il concept non sia esageratamente comodo
  per i giocatori e una volta che è ok direi di indicarlo nell'opzione della
  pagina di account.

- Ora Aarit nel qual caso vi sia stata un'eccezione sconosciuta che blocca
il
  core di twisted (ovvero rischia di far crashare sul serio il mud) e che il
  gioco sia quello ufficiale (e quindi è sottinteso che debba sempre
rimanere
  up and running) allora tenta di riavviarlo con le stesse opzioni
utilizzate
  per l'attuale istanza di Aarit "morente".

- Ho aggiunto per la lista delle enumerazioni dei SECTOR della pagina html
  elements_list la visualizzazione dell'attributo fertile
  Posso con poco far visualizzare altri attributi se serve in una delle
  qualsiasi liste di enumerazione.

- Ho aggiunto nella pagina dei crediti la vittoria di Vilfredo riguardo la
gara
  segreta del labirinto.

- Ho implementato un sistema molto simpatico di persistenza dell'azione.
  Che significa?
  In pratica quando vengono inviati dei messaggi d'azione ad un'entità, ad
un
  target o a degli others questi messaggi rimangono leggibili al posto della
  long per un paio di secondi.
  E' una cosa particolare.. prova a fare igoto foglia e seguirla, ti
potrebbe
  dare un'idea vaga, in quel caso bisogna dire che il verbo non è del tutto
  esatto, e immagino che anche molti altri act il problema esista, comunque
  potrò sempre diminuire il tempo di persistenza dell'azione e vedere
  se il retrogusto dell'azione passata rimane o meno...
  Da provare tutto quanto con tante azioni e vedere cosa farne!
  Riassumentdo il tutto: significa che se un giocatore ride, e se un altro
  giocatore arriva nella stanza del primo entro due secondi, il secondo vede
  come long il primo giocatore ridere.

- Ho provato a fare il sistema di counter a livello "fisico" nel codice ma
  non ci sono riuscito adeguatamente, non senza sporcare del codice negli
  script. Allora ho lasciato perdere il (sicuro) guadagnato in termini di
RAM
  ed ho deciso di seguire la proposta relativa al counter "visivo",
funziona!

- Ho modificato dei gamescripts, ma forse ho avuto la fortuna di averli
  aggiornati dalle tue ultime modifiche relative agli act TO.ENTITY

- Aggiunti i trigger di before_enter e after_enter, già documentati nel file
  gamescript.htm


================================================================================
Rella 89
07/03/11

* Ignora gli errori riguardanti le etichette UserAgent per i giocatori

- Il problema dei reset relativo al maze dovrebbe essere risolto, non che credo
  ce ne fosse bisogno, ma nel qual caso si vengano a creare dei reset temporali
  allora è a posto.

- L'etichetta Short per le aree ora è diventata obbligatoria.

- Avvia un'istanza di questa release anche sulla 4000 ma con l'opzione di
  config disable_subsequent_resets a True, voglio vedere come si comporta
  nel lungo termine il consumo di RAM.

- Sai che alcuni comandi rpg se inviati senza argomento davano un messaggio di
  act sia a sé stessi che agli altri? Ora non più, solo un messaggio a sé
  stessi e poi, se uno ha l'opzione OPTION.NEWBIE attiva, anche la relativa
  sintassi del comando, penso che sia meglio così.

- Aggiunte le etichette delle descrizioni da poter modificare online con il
  comando di restring

- Aggiunto il comando repaint che funziona in maniera simile al comando restring
  tuttavia questo funziona solo per le stanze e precisamente nella stanza in cui
  ci si trova in quel momento

- Aggiunto nel comando who, per soli admin, il nome dell'account del personaggio

- Ho aggiunto i comando addexit e delexit, probabilmente in futuro servirà il
  comando modifyexit, ma per ora ci arrangiamo così

- Ho creato il comando countraces, te ne ho già parlato, è abbastanza semplice
  da utilizzare e carino

- Corretto il baco che non faceva visualizzare il codice dell'entità in
  gift_on_enter nella pagina web relativa alle opzioni di configurazione

- Se avrai bisogno della funzione myrandint negli script non dovrai più fare
from src.utility import myrandint
ma
from kadath.utility import myrandint

- Ho aggiunto le etichette alla struttura Maze di InitialRoom e FinalRoom,
  essere servono ad indicare il codice della stanza di prototipo esterne alla
  generazione automatica del labirinto
  Per ora mi servono per evitare di estrarle e non rendere più il labirinto
  accessibile, in futuro potrà servire per esempio a tracciare le entrate
  e le uscite dei giocatori

- C'era un baco nella visualizzazione della lista dati dell'area maze, questo
  perché le stanze utilizzate nel maze non avevano il codice che iniziava con
  il codice dell'area (karpuram invece che maze) e il sistema di filtraggio dei
  dati sbagliava, ora è tutto a posto (quindi alla fin fine le stanze c'erano!)

- Ora la tooltip relativa l'uscita fa visualizzare le descr e le flags della
  porta se ve n'è una ed è chiusa, altrimenti fa visualizzare come prima le
  descrizioni dell'uscita stessa e le relative flags

- Ho potenziato l'emote in maniera tale che sia possibile inserire il proprio
  nome dove si voglia, per esempio:
  Ora $n si sbatte
  verrà convertito in
  Ora Onirik si sbatte
  e non in
  Onirik ora Onirik si sbatte

- Ora la pagina di amministrazione show logs elenca tutti i file di log,
  cliccabili e visualizzabili, il caricamento di log anche di parecchi mega
  non dovrebbe inficiare sulla velocità del gioco

- Ora il goto dovrebbe cercare prima di tutto tra i giocatori online piuttosto
  che tra tutta la trafila di player, online o offline chessia

- Ho creato un sistema per intuire all'avvio eventuali etichette scritte
  erroneamente nei dati, per ora il sistema non l'ho attivato perchè ritorna
  molti falsi positivi, tuttavia ho potuto constatare un paio di errore
  potenzialmente interessanti che ti giro:
02:29:21 [Fread] (fread src\database.py 1122): Potenziale etichetta errata per la linea DestinationOpenMessage: $N viene apert$O dal lato opposto.
 letto nel file data/proto_items\mfdonald/mfdonald_item_strumenti-cembalo.dat con la label DestinationOpenMessage
02:29:21 [Fread] (fread src\database.py 1122): Potenziale etichetta errata per la linea DestinationCloseMessage: $N viene chius$O dal lato opposto.
 letto nel file data/proto_items\mfdonald/mfdonald_item_strumenti-cembalo.dat con la label DestinationCloseMessage
  Difatti il cembalo è un contenitore e le etichette DestinationOpenMessage
  e DestinationCloseMessage sono proprie delle porte (sia i contenitori che
  le porte fanno parte della famiglia degli "openable", è un errore da copia
  e incolla)

- Ho corretto lo script villaggio-zingaro_mob_esserini.py aggiungendo una FLAG,
  EXTRACTED, che serve a controllare se un'entità è stata già estratta, per
  qualsiasi motivo, durante l'attesa della callLater
  Forse non risolve il problema, ma almeno vediamo che succede.


================================================================================
Rella 88



================================================================================
Rella 87
14/01/11

- Ora si dovrebbero poter vedere tutte le secret, prima si vedevano solo quelle
  relative alle porte del proprio lato della stanza in cui ci si trovava

- Ricordo che hai dovuto utilizzare il command_remove ricavando la keyword da
  target anche se questo era già in canna nello script, ti avevo detto che
  avrei fatto qualcosa a riguardo, è la stessa cosa che ho fatto per il get:
  puoi utilizzare
  command_remove_concretly(entity, target)
  così da passare direttamente il target senza avere casini di conflitti di
  keywords
  L'unico "difetto" (o pregio, dipende) è che viene saltata tutta la trafila
  iniziale dei check relativi al remove (come dire che se target ha la flag di
  NO_REMOVE (quando esisterà) questa non viene controllata e target viene rimosso)
  Insomma bisogna utilizzarlo quando si è sicuri di voler rimuovere a tutti i
  costi target senza far danni

- Ho commentato un pezzo di codice in find_entity che mi dava fatidio, lo scrivo
  qui non tanto per fartelo sapere ma per ricordarmelo, visto che è un pezzo di
  codice che non ho capito come mai l'avevo scritto
  Il pezzo commentato potrebbe inficiare solo sul funzionamento della ricerca
  delle porte tramite comando look o altri sensoriali, utilizzare chiave di
  ricerca direzionale poteva cambiarne il comportamento, adesso non credo..
  Bho.

- Aggiunte le etichette sia per item che per mob FollowEntityMessage e
  FollowOthersMessage, il primo funziona così:
  Accetta tag $n e $N e tutti gli altri soliti, in più due tag di sostituzione
  stringa %s
  Sia per FollowEntityMessage che per FollowOthersMessage al primo %s viene
  sostituito il verbo di movimento, mentre al secondo %s viene sostituita la
  direzione verso cui si segue qualcuno o qualcosa.
  Bisogna aggiungere queste due etichette nella documentazione

- Corretto il problema del disable_behaviours la cui logica era al contrario

- Aggiunta l'etichetta RemakeHour nella struttura del maze, indica l'ora rpg
  in cui il maze viene rifatto, tutto da testare, se serve aggiungo altre
  etichette temporali


================================================================================
Rella 86
21/12/10

- Ora il comando enter sui portali dovrebbe portarsi dietro i giocatori in
  follow

- Ho inserito e migliorato i metodi close per tutti i file aperti e 
  potenzialmente non chiusi in tutto il codice del Mud.
  Il problema l'avevo indicato nel:  Crash on Ctrl+C  del google doc

- Spostata l'opzione di config enable_subsequent_resets dalla sezione GENERAL 
  alla sezione DEVELOPMENT e rinominata in disable_subsequent_resets

- Aggiunte le opzioni di config disable_mudscripts e disable_behaviours nella 
  sezione DEVELOPMENT, funzionano come da nome

- Ho cambiato un po' i riferimenti delle door, non so ancora bene cosa implichi 
  tutto ciò, ma dovrebbe essere meglio, per esempio ora sono gotizzabili, 
  dovrai indicarmi in maniera pusillanime tutte le variazioni di comportamento 
  riguardanti le porte
  In teoria ora si possono utilizzare i behaviours sulle door.
  Il sistema funzione così: le porte ora fanno parte degli oggetti della stanza
  a cui appartengono, per indicare che una porta è stata divelta dai cardini o
  meno c'è la flag (inserita automaticamente nel codice) DOOR.ON_HINGES

- Ho rimesso a posto la pagina web admin sugli test inputs, sono abbastanza
  utili perchè li può usare per vedere se ci sono comandi che fanno crashare.
  Praticamente vengono inviati dei comandi con argomenti casuali da tutte le
  entità in gioco e tutti i giocatori forzandoli ad entrare in gioco, il resto
  è scritto nella pagina web del test.

- Aggiunti i RESET.BURIED e il RESET.PLANTING che dovrebbero funzionare proprio
 come ti aspetti... spero

- L'etichetta Size ora indica il percentuale quanto un oggetto è grande rispetto
  ad un corpo umano di maschio adulto, so che è difficile da stimare..
  proviamoci, al limite la rimuoveremo se vediamo che non funziona (bisogna
  poi aggiungerla  nel manuale)
  Concettualmente possono esistere entità così leggere da non avere peso (0g)
  tuttavia è impossibile che non occupino un po' di spazio (almeno 1%), oppure
  viceversa si possono avere entità che non occupano spazio utile (1% di un
  maschio adulto è cmq un bel tocco) ed avere qualche peso in grammi.
  Ovviamente i casi meno particolari includono sia l'etichetta weight che size

- Adesso i log dovrebbero apparire anche in game nel qual caso che abbiano
  delle > o < nel messaggio o altri caratteri strani html-tag oriented

- Aggiunta la flag di CONTAINER.SECRET, ma non ancora funzionante


================================================================================
Rella 85
21/11/10

- Aggiunta l'opzione di config min_secret_arg_len nella sezione GENERAL che per
  ora deve essere sempre a 2, indica il numero minimo di caratteri accettabile
  per le extra e le door segrete

- Aggiunta l'opzione di config enable_subsequent_resets nella sezione GENERAL
  per disabilitare prima di un avvio i reset successivi al primo di default;
  praticamente è la stessa cosa che ti ho fatto fare commentando le due righe
  relative i reset nel file di area.py
  enable_subsequent_resets di base è a True, se vuoi disabilitare i reset
  devi inserire False

- Implementati i trigger temporali, nel documento di building apposito c'è
  scritto tutto


================================================================================
Rella 84
05/11/10

* La label incognito non serve più nelle persistenze, RIMUOVILE altrimenti ti
  darà errore nel check sull'esistenza della path delle icone

- Ho aggiunto l'opzione di account OPTION.NEWBIE, direi che sarebbe meglio
  aggiungerla a tutti gli account già creati, la label è Options
  Per ora di solito farebbe vedere sintassi dei comandi ma in futuro anche il
  link sull'help relativo

- Ora le variabili della tipologia plant_type:
  entity.plant_type.worse_counter
  entity.plant_type.normal_counter
  entity.plant_type.better_counter
  sono state attivate e utilizzabili per il trigger on_next_stage

- E' stata aggiunta l'etichetta DeadEntity nella tipologia PlantType e serve
  ad indicare che il prossimo stage è la fine di un ciclo.
  In pratica quando il mud si accorge che la pianta è arriva alla fine di un
  ciclo controlla i worse_counter rispetto al totale dei contatori e lancia
  un tiro salvezza alla pianta, se non lo supera carica quest'entità.
  NON BISOGNA utilizzare questa label se lo stadio di crescita non è quello
  della fine di un ciclo vitale (che nella nostra RL sarebbe l'anno);
  praticamente non è possibile che la pianta muoia prima della fine di un
  ciclo vitale, a meno di non piazzarci un gamescript.
  Oltre a questa label si possono usare le solite NormalEntity, WorseEntity e
  BetterEntity per far reiniziare o continuare un nuovo ciclo vitale.
  Oppure si può creare un ciclo one shot time in cui l'ultima entità non
  possiede nessun PlantType, cosa che immagino tu abbia già fatto.

- E' stata aggiunta l'etichetta RemainingLife alla tipolgia PlantType che
  indica quanti cicli vitali massimi la pianta resisterà prima di caricare
  la DeadEntity
  Impostando la RemainingLife a -1, come di default, i cicli vitali sono
  infiniti

- Ho aggiunto una cosa nella documentazione relativa al trigger on_next_stage:
  "Se si ritorna True nella funzione relativa al trigger allora il gioco eviterà
  di chiamare il prossimo stadio di crescita."

- Aggiunto il comando snoopers, serve a visualizzare tutti gli admin che
  snoopano qualcosa

- Non si potevano tellare pg in incognito, ora sì

- Ora giocatori che quittano (non quelli che perdono la connessione)
  disattiveranno l'eventuale incognito E tutti i giocatori eventualmente
  snoopati.

- Ho migliorato grammaticalmente la frase del drop, prima era così:
Entropy posa un puzzo di sudaticcio in La Stanza del Vestiario.
  ora:
Entropy puzza e posa un puzzo di sudaticcio nella Stanza del Vestiario.
Ora si che è corretta!

- Ora per il solo comando get c'è un sistema sperimentale per cui se uno
  inserisce il comando
prendi camicia a tunica cassa
almeno viene trovata la cassa, prima neppure quello

- Aggiunto il sinonimo di remove in italiano: togli

- Aggiunto il comando afk, lo stato di afk si vede anche nel who e nel tell
  non si vede navigando normalmente, per quello aspettiamo la mia implementazione
  dell'"andare in fissa" (di cui non ti ho detto ancora nulla) per vedere come
  sarà l'effetto e se servirà o meno

- Ho cambiato tutti i titoli delle pagine per avere, in teoria, un migliore
  posizionamento in google; inoltre anche il titolo funziona come contatore
  di who in questa maniera è facile notare cambiamenti di numero di giocatori
  anche mantenendo il browser ridotto ad icona nella barra di stato, sarà
  utile nella prossima apertura

- Ho creato il file chat_messages.list nella cartella di log, viene creato e
  riempito quando i giocatori chattano, cosicché si possa leggere e vedere che
  cappero dicono o linkano.
  L'idea sarà quella di guardarlo ogni tanto e di leggerlo fino ad un certo tot
  rimuovendo le linee fino a quel punto lette e sharando eventuali informazioni
  utili

- aggiunti i check di miml seguenti:
#self.inventory_qty == 1#bla bla vero# bla bla falso#
#self.equipment_qty == 1#bla bla vero# bla bla falso#
  come prima parte ci può essere self o looker
  poi il punto e inventory_qty o equipment_qty
  poi un operatore tra == != > >= < <=
  infine la quantità da 0 in sù
  Laddove ho inserito degli spazi questi servono, almeno uno.
  Tutto ciò alla fin fine serve a controllare se un contenitore è vuoto, come
  mi pare abbia chiesto Cello.
  Assolutamente non testato, un po' come i vini DOC italiani.

- Aggiunta l'etichetta IconNight per entità e stanze, stessa cosa dell'icona
  ma viene visualizzata di notte, verrà usata poco immagino e quelle volte
  penso sia meglio mantenere il disegno e cambiare solo i colori, cmq alla fin
  fine vedi tu, dipende molto dall'entità

- Aggiunto il campo Logged On nella pagina admin con tutte le connessioni

- Aggiunto il trigger on_inject che fa coppia con l'on_extract


================================================================================
Rella 83
23/10/10

- Aggiunto il trigger on_next_stage, che scatta quando una pianta sta crescendo
  Forse non si capisce bene ma il trigger è da inserire al prototipo della
  pianta d'origine dello stage e non il suo risultato, un po' come le etichette.
  (Lo so che il nome del trigger è un po' sibillino e potrebbe cambiare, ma
  fino a che non creerò il sistema di grown dei mob non so bene che nome
  mettergli per non creare conflitti e confusioni).
  Cmq il tutto è descritto nella solita pagina web di documentazione builder.

- Dovrei aver cambiato qualcosa dei reset, forse ora funzionano... tutti?
  Se ti dovesse capitare di percepire che un reset non funziona più, e poco
  prima sei sicuro che andasse, allora prova a controllare prima di tutto che
  il calendario rpg stia scorrendo e poi segnati la data rpg e postala sul
  google doc

- Ora viene inviata una mail agli admin se typo, bug o idea vengono inviati

- In aarit\www\icons\_archivio troverai un mucchio di iconcine nuove, alcune
  (poche) non sono 16x16 perché sono pensate da cuttare e spezzare in più
  piccoli oggetti (come quella con le 4 borse).
  Altre anche se sono 16x16 gli puoi dividere gli oggetti in più icone, come
  la bottiglia e il bicchiere.

- Stanza novizi_room_atrio ho letto:
desidera aprire specificando anche la direzione (Apri Sud oppure Opne porta Sud).

- Cambiata la nuova interfaccia, ora si possono fare i nuovi screenshots,
  gli ultimi erano venuti un po' sgranati, non è che fossero un gran ché,
  se vengono anche questi male faccio prima a togliere del tutto il link

- Poichè son già cotto: notizia, 2 bg e bigino te li passerò a parte poi


================================================================================
Rella 82
18/10/10

* Ci sono da cambiare tutte le etichette SeedType in PlantType

- Ora nella crescita la pianta risultante viene scelta casualmente tra quelle
  definite (worse, better o normal)

- Ora funziona l'etichetta Contents, per esempio ai germogli del mirtillo ho
  inserito (credendo di farlo fiorire):
PlantType:
    [...]
    Contents: karpuram_item_mirtillo-nero-04-fiore 4
End
  il primo valore dopo Contents è il codice prototipo dell'entità da inserire
  quando la pianta seminata cresce, 4 invece è il numero medio di frutti, fiori
  o altro che verranno inseriti nella pianta se questa cresce normalmente, il
  numero viene dimezzato se la pianta cresce worse, oppure raddoppiato per
  crescita better.
  Una volta che i frutti o che vengono creati la nuova entità crea
  automaticamente una struttura di container (sempre che questa non sia già
  esistente), questo serve a far interagire il giocatore per permetterli di
  raccogliere l'eventuale contenuto.
  Quindi alla fin fine una pianta cresciuta funzionerà come un contenitore e
  si potranno inserire gli addobbi natalizi.

- Inoltre:
  1] Ogni volta che la pianta cresce e quella precedente aveva dei fiori questi
  spariscono e nello stadio successivo vi sarà un numero massimo di frutti
  pari a quelli dei fiori che v'erano (in pratica la fruttificazione è legata
  anche alla qualità dello stadio precedente).
  2] Tutti i frutti che già esistevano nello stadio di crescita successivo
  cadranno a terra e non si troveranno più tra i rami della pianta.
  3] Tutti le altre tipologie d'oggetto verranno trasferiti dalla precedente
  entità in quella nuova; ciò significa che se ad un seme inserisci un oggetto,
  con un reset o con un gamescript, questo si troverà tra i rami (cioè al suo
  interno) delle piante degli stadi successivi.

- Aggiunto il log sui differenti stadi di crescita, viene printato solo su
  console

- Corretto l'errore:
09:31:08 [Fwrite] (fwrite src/database.py 1461): Tipologia di variabile <class 'src.item.Item'> passata tramite l'attributo guide non gestibile dalla fwrite al file data/players/Sulfrum/Rinaudo.dat
  anche l'etichetta Owner aveva questo errore e ciò mi fa pensare che tu non
  l'abbia mai utilizzata, nelle entità Owner serve ad indicare chi è il padrone
  di quella stessa entità, sarà utile per gestire comportamenti pseudo AI.
  Ora comunque dovrebbe essere salvati i riferimenti all'entità seguita anche
  tra un reboot ed un altro

- Ho commentato il codice relativo alla ricerca inversa degli argomenti dei 6
  comandi sensoriali (portava a troppa confusione), ora la sintassi funzionante
  è quella ufficiale e basta (guarda zampa onirik)

- Ho aggiunto i trigger before_open, after_open, before_close e after_close
  tutto nella pagina doc che sai

- Ho creato il mudscript carrozzone-zingaro_item_cassettiera.py, l'ho testato
  e funziona, non ho provato a vedere se tra boot continui a mantenere le
  persistenze dei cassetti in maniera corretta

- Aggiunta la possibilità di eseguire i 6 comandi sensoriali anche
  sull'inventario di contenitori aperti (prima era possibile solo
  sull'equipaggiamento)

- Ho raddoppiato la sazietà donata dal cibo, che giocherellando un po' mi
  capitava troppo spesso, poi ora come ora che non abbiamo il mud completo di
  negozi con cibo e quant'altro non mi sembrava il caso di stressare

- Zio bello che figata! Ora se per caso si fa crashare inviando un comando
  il client avvisa dell'errore con un messaggino user friendly (forse cmq è
  da cambiare) e inoltre il giocatore può continuare ad inviare lo stesso
  comando o un altro senza doversi riconnettere, finalmente ce l'ho fatta!

- Ok la situazione sui reset dovrebbe essere questa (prendi tutto con le pinze):
I reset non dovrebbero più bloccarsi dopo 10/11 ore, ora dovrebbero continuare all'infinito.
Un'altro problema separato è il fatto che tu dopo un po' non vedessi resettare alcune e/o
molte delle entità è dato dal fatto che un crash qualsiasi (che non inficia sulle deferred
dei reset ma sul ciclo loop del mud) bloccasse quest'ultimo.
Bloccando il loop cosa succede? Che la data rpg rimane ferma.. tuttavia le deferredLater
dei reset si basano sul tempo reale e quindi loro continuano.. e continuano a resettare
sempre controllando dalla stessa data rpg per la prossima data rpg dei reset.
Quindi finivano a resettare sempre e solo le stesse cose (che di solito non avranno bisogno
d'essere resettate e quindi non ci accorgiamo neppure di quello) il tutto quindi è molto
casuale perchè dipende dalla data rpg di quando il crash blocca il loop.
Mah.. è ancora una teoria, spero di non aver detto troppe cavolate.


================================================================================
Rella 81
12/10/10

* Sulla 4000 bisogna cambiare l'opzione site_address da
  http://eco.ilmale.it:4000 in http://www.aarit.it
  In tal modo le mail inviate avranno l'indirizzo giusto

* Rimossa per sempre l'opzione di config allow_player_getting, visto che dalla
  release scorsa c'è il controllo sul peso questo non serve più

- Aggiunto il messaggio di reset relativo alle porte, mancava; non che fosse
  estremamente necessario: se si resetta una stanza allora si resettano anche
  le porte; ma il gusto di riempire la console di messaggi che tu poi devi
  metterti a decifrare era troppo ghiotto.

- (Forse) adesso andando di goto si dovrebbero avere risultati simili anche
  tra due differenti sessioni di gioco (sempre però che siano facenti parte
  della stessa persistenza).
  Se te n'eri accorto, e mi pare che ne avessimo parlato tempo fa, se facevi
  goto '2.qualcosa'  una sessione di gioco ti portava da un 'qualcosa' mentre
  l'altra sessione da uno differente, perché l'ordine nel database delle entità
  era cambiato durante l'avvio.
  Questo non è solo per il comando goto in realtà, ma anche per tutti quei
  comandi di admin che eseguono uno scanning in tutto il mud di un'entità.

- Ho fatto in modo che alla sconnessione di un giocatore (quit o altro) venga
  bloccata l'eventuale azione in corso (come per esempio il dig) così da
  evitare eventuali giocatori che dopo un quit continuino a scavare finendo
  nel centro di Nakilen.

- Il comando eat aveva dei bachetti, prima di tutto il peso massimo morsicabile
  era sballato, adesso si aggira ad un chilo e mezzo di media (è proprozionale
  al peso di chi mangia).
  Mentre il guadagno della sazietà viene ora calcolato con un logaritmo:
entity.hunger -= int((math.log(bite_weight) * 1000 / eatable_weight) * 4)
  bite_weight, nonostante il nome sibillino, è il peso totale del cibo
  eatable_weight è quello che ho chiamato sopra come peso massimo morsicabile.
  E' una formula che ho sparato un po' lì, dipende tutto dal peso dei cibi in
  gioco: insomma è tutto da provare empiricamente.

- Ho inserito un supporto friendly per l'hold e il wield tramite il comando
  wear, quello che manca tuttavia è l'inserire questa struttura:
WearType:
    Modes: PART.HOLD
End
  oppure questa:
WearType:
    Modes: PART.WIELD
End
  nei dati che ne abbisognano, quindi ad armi il WIELD mentre a scudi e
  simili l'HOLD.
  Lo so che tutti gli oggetti sono holdabili, tuttavia bisogna inserire il
  wear_type a quegli oggetti che già comunemente o estensivamente vengono
  utilizzati come holdabili stringendone l'insieme il più possibile a quelli
  ovvi: scettro, scudo, forse ombrello... già la forchetta è in dubbio e
  potrebbe essere sia hold che wield.
  Vabbe' nel qual caso vi siano dei dubbi fammi sapere che decidiamo assieme
  se una entità lo abbisogni o meno.
  (Ho visto in uno dei precedenti backup che già qualcosa hai fatto)

- Aggiunto l'UsedAs ENTITYPE.INSTRUMENT, non esiste ancora nessuna etichetta
  InstrumentType, è giusto per aggiungere la tipologia di elemento che ci
  sarà sicuramente

- Ora è impossibile guardare dentro un contenitore chiuso (CONTAINER.CLOSED)

- Ora è impossibile gettare o puttare con un contenitore chiuso

- Aggiunta la flag CONTAINER.CLOSABLE per indicare eventuali contenitori
  che si possono chiudere, altrimenti vengono considerati già e sempre aperti.
  Sì, so che tu avresti forse preferito la flag CONTAINER.OPENABLE, ma alla
  fin fine ho preferito così.

- Ho rimosso il comando di admin loop che ormai non serviva più (e mi sa che
  non funzionava neppure)

- Sto chiudendo un cerchio di debug sui reset.. questa release dovrebbe printare
  realmente eventuali traceback di errore.
  Ti ricordo che potrebbero essere loggati eventuali messaggi di errore che
  iniziano con i caratteri ||| relativi ai reset, tali caratteri li avevo scelto
  per facilitare la ricerca nei log

  Se tutto andrà in porto allora in futuro bisognerà cambiare tutte le chiamate
  callLater utilizzate nei mudscript e nel resto del codice con delle deferLater,
  che sono simili ma daranno la possibilità di visualizzare il traceback in
  punti infidi degli script che apparentemente non danno errore senza tuttavia
  funzionare (e mi pare ci sia già capitato a tutti e due)

  Ad una prima impressione sembra che in realtà i reset non smettano di
  funzionare di botto dopo 10 ore e un quarto, ma che la loro disattivazione
  degeneri pian piano in maniera sistematica, cosicché nel tempo prima citato
  tutti i reset spariscono, ma è ancora solo un'ipotesi.

- Inserire questa release anche sulla 4000

- Avevo scritto questo messaggio sulla piazzetta della 4000:
Apriamo dal 25 al 31 di questo mese :)
  Solo che è un po' sibillino se letto nel futuro, quindi è meglio modificarlo in:
Apriamo dal 25 al 31 del mese di ottobre :)


================================================================================
Rella 80


================================================================================
Rella 79
27/09/10

* Ho rimosso opzione OPTION.LAST_INPUT, sarà da togliere in tutti i file dat
  degli account, l'ho fatto perché reputo pacifico che un giocatore alla
  riconnessione voglia riavere l'ultimo comando inviato, o no? Quindi l'ho
  considerata un'opzione inutile e potenzialmente confondibile

- Aggiunta la razza BUTTERFLY e la razza RACE.UNICORN (da considersi normalmente
  associabile con la flag FLAG.MAGICAL e non FLAG.MAMMAL, ma visto che la flag
  ancora non esiste uhm.. per ora facciamo finta di nulla)

- Ora per i mob è obbligatorio avere l'etichetta Race definita, cosa che hai
  già fatto di tua sponte nella release precedente

- Aggiunto un sistema che ogni mezz'ora si salva il consumo della cpu nel file
  log/cpu_times.log, serve a confrontare i valori con il top e vedere se tutto
  torna, ogni riavvio aggiunge un a capo per separare le statistiche, il primo
  numero è il tempo consumato dal python impiegato dalla cpu per far funzionare
  aarit nell'arco di un secondo; l'altro numero è la stessa cosa ma relativa
  al tempo consumato dal sistema (aprire e scrivere files, connessioni, etc...
  suppongo)

- Aggiunto finalmente il sistema di salvataggio giornaliero dei pg: ora come ora
  ogni 24 ore dall'avvio appena trova il mud vuoto da pg esegue il backup
  automatico del database, funziona come gli altri backup ma il file di *.bz
  viene chiamato in maniera differente

- Aggiunta l'opzione delete_pyc_files che se impostata a True, di default,
  cancella tutti i file pyc (e eventualmente anche i pyo) allo shutdown del
  mud (mi è utile per la ricerca dei file sorgenti durante il coding)
  L'opzione si trova nella sezione [DEVELOPMENT]

- Ora le platform infos vengono stampate tutte in un unico file separate da un
  a capo e con in testa la data di quando sono state ricavate

- Prima nel qual caso vi fosse un'uscita diggable ed anche la sua inversa il
  dig la apriva solo dal lato in cui si esegue il comando e non anche l'altro,
  ora ciò è stato corretto

- Corretto il timemachine per la questione dei reset, in pratica ora effettua
  una pulizia di tutti gli eventi reset ancora da scattare e poi li rinizializza
  da capo seguendo il nuovo corso temporale rpg impostato

- Ho cambiato nuovamente il guadagno passivo dei px, è logaritmico rispetto al
  livello e c'è un po' più di probabilità di assorbire px (1 su 5, invece di 1
  su 6), tuttavia ai primi 7 livelli non si guadagna nulla.
  dal   8 -> 1px
  dal  21 -> 2px
  dal  55 -> 3px
  dal 149 -> 4px
  fino al 200 livello

- Aggiunto l'interfacciamento ai trigger before_dig e after_dig, vedere la
  pagina di documentazione dei mudscript per carpirne l'interfacciamento.

- Ho spostato la richiesta di una delle due risorse (un file javascript per
  l'esattezza) per il bottone add this (quello sotto il menù) da remoto in
  locale, questo potrebbe diminuire il tempo di caricamento della pagine del
  mud quando questo viene testato offline, fammi sapere, che mi avevi detto
  che forse era quello il motivo per cui ti rallentava assai
  (non credo che risolverà però il problema)

- Da notare che nei log ho aggiunto, oltre all'ora e al minuto in cui viene
  stampato il messaggio, anche il secondo, ti potrebbe essere utile come lo è
  stato a me.
  Inoltre, come ti potrebbe essere capitato, sto migliorando i messaggi di
  controllo dei dati all'avvio del mud, in questa release c'è addirittura un
  controllo sui room reset che si oscurano a vicenda, cioè quelli erroneamente
  con medesima coord e medesimo data (ho visto qualche errore in arena-drago
  e uno in kirble a riguardo); be zamp!

- Ora con l'opzione check_References attiva ci sarà un controllo anche su
  possibili eventi di reset persi durante l'esecuzione del mud, il
  messaggio di errore sarà qualcosa tipo:
  room reset con data %d %d %d %s per la stanza %s senza evento

- C'era un baco che mi evitava il controllo di tutte le stringhe del database,
  ora il caricamento del mud è più lento in quel punto, viene controllata
  la validità dei colori e se questi vengono chiusi correttamente, oltre a ciò
  viene controllato se ci sono caratteri non validi (non stampabili) finiti
  nelle stringhe di descrizioni con copia e incolla selvaggi

- Ho aggiunto l'etichetta ContainerType, per adesso bisogna semplicemente
  inserirla così:
ContainerType
End
  per esplicitare che un oggetto, o mob (o giocatore) è un contenitore.
  Nella prossima release questo servirà a far visualizzare la lista del contenuto
  di tali oggetti, che mi pare di capire che ora non sia possibile carpirla
  nemmeno da parte degli admin nonostante tutti gli oggetti possano funzionare
  come dei contenitori


================================================================================
Rella 78
17/09/10

* Cambiata l'etichetta per le aree da Creator in Creators

- Ho fatto modifiche ai seguenti gamescript:
ikea_mob_gallina.py
torreelementi_item_spore-faura.py
  ed altri che contenevano l'obsoleto utilizzo di estrazione dal gioco delle entità:
target.from_entity()
del(database[target chiave])
  mentre invece bisogna utilizzare semplicemente
target.extract()
  potrebbe essermene sfuggito qualcuno o che, statte accuorto!

- Implementate le uscite DIGGABLE, inserendo questa flag nella struttura di una
Exits:
    Direction: DIR.UP
    Flags: EXIT.DIGGABLE
End
renderà l'uscita scavabile tramite il comando dig.
Le uscite diggable non dovrebbero essere visibili o passabili in alcun modo,
tranne dopo averle appunto scavate.

- Implementato il comando dig, per ora serve a dissotterrare oggetti inseriti
  nel terreno (come i semi tramite il comando seed) oppure scavare le uscite
  come sono state presentate prima.
  Se ci sono più oggetti interrati ne sceglie uno a caso e lo rende visibile.
  Il giocatore che scava ci potrà mettere più o meno tempo a seconda del
  settore in cui si trova.

- Dig è il primo comando che implementa un'azione progressiva, ovvero
  il comando avvia l'azione che prosegue dopo 3 secondi (c'è un messaggio
  apposito) e termina dopo altri 5 secondi.
  Il sistema è generico e sicuramente ci sarà in altri futuri comandi, come
  il suona o il leggi.
  Qualsiasi altro comando interattivo (cioè che comporta un'azione rpg) ferma
  l'azione del dig, c'è quindi da controllare se tutti i comandi interattivi
  lo blocchino e solo quelli; concettualmente bisogna immaginarsi l'azione e
  pensare se normalmente altri comandi possono bloccarla o meno, per esempio
  il parlare non blocca l'azione mentre cercare di dare qualcosa a qualcuno sì.

- Ho decretato come deprecato il settore SECTOR.INSIDE, esiste ancora ma non
  bisogna assolutamente usarlo, al contrario bisogna utilizzare la flag
  ROOM.INSIDE.
  Tutto ciò permette di personalizzare il settore chiuso come si vuole, se è
  caverna, casa, maniero, sottoterra o che.

- Da notare che ho aggiunto alcuni settori che possono servire a descrivere
  meglio le stanze con flag INSIDE: HOUSE, SHOP, VILLA, CASTLE
  Tra tot release il settore inside verrà rimosso, quindi prima o poi bisogna
  sostituirlo con uno di questi o altri eventualmente da suggerirmi.

- Ora se si pianta una pianta (huh? O_o) e si riavvia il gioco lo stadio
  raggiunto dalla pianta dovrebbe essere ripreso e continuato ma con counter
  del tempo resettato dall'inizio

- Ho cambiato la flag di entità FLAG.SOWN in FLAG.BURIED

- Corretto (pensavo di averlo già corretto) il problema dei goto su codici, tipo
  igoto karpuram_item_mirtillo-nero-01-frutto
  non funzionava

- Ora si vedrà la flag di BURIED correttamente:
C'è un mirtillo qui. {BURIED}

- Ok, ora si può seminare un po' più correttamente, il sistema è lungi
  dall'esser completo, ma le basi funzionano

- Ho rifatto tutto il sistema dei reset, l'ho convertito da ciclo continuo
  (venivano controllate tutte le entità del gioco per vedere se erano da
  resettare) in un sistema ad eventi (ora i reset si attivano solo quando è
  necessario ed in maniera concatenata, cioè quando un'entità viene resettata
  si va' a creare una callLater per il prossimo ri-reset dell'entità stessa,
  tutto questo discorso ovvio si rifà ai reset con delle etichette di data
  più o meno definite)
  Il sistema potrebbe avere delle pecche di base, e quindi è possibile che non
  riesca a resettare qualcosa, ma sono casi particolari, l'ho testato un po' e
  mi pare che regga, per ora..
  Mentre prima un crash in un reset freezava il loop e compagnia bella, adesso
  un crash in un reset inficerebbe sulla concatenazione dell'eventuale
  successivo medesimo reset temporale.
  Come noterai ho lasciato un messaggio di console aggiuntivo che indica quanti
  secondi ri-scatterà quel reset, non è raro trovare il valore 2878, difatti
  sono i secondi reali relativi ad un giorno rpg di aarit ((24 * 60) - 1) * 2)
  oppure inconterai valori relativi ad un'ora rpg: 118.
  Il sistema, molto ma molto probabilmente, ha migliorato le prestazioni del
  gioco, insomma ormai Aarit occupa uno sputo del processore, peccato che non
  si possa dire la stessa cosa del consumo relativo la RAM, gh :P
  In definitiva: dai un occhio a qualche reset tipico per controllare che
  funzioni ancora.

- Aggiunte le etichette Short e ShortNight al dato di tipo area, queste
  serviranno ai giocatori che entreranno in un'area che non conosceranno molto
  bene

- Aggiunta l'etichetta Year ai RoomReset, serve a creare dei reset che scattano
  solo quell'anno o solo una volta


================================================================================
Rella 77
07/09/10

- Ricordati che io non dovrei aver modificato i gamescript, mentre tu sì, cmq sta attento

- Modificato il nome dell'opzione first_destination in initial_destination

- l'extract ora non rimuove i personaggi dal database ma li fa uscire nella
  stanza dell'entità estratta, se non vi è più una locazione valida o se
  l'entità da estrarre originariamente era il pg stesso allora lo teletrasporta
  nella stanza di gioco iniziale

- Ora cliccando sul personaggio di un account per entrare in gioco non si
  aprirà la pagina di gioco in una nuova finestra ma utilizzerà la stessa,
  penso sia meglio così, in futuro tutto il sito sarà così, a parte il forum
  esterno fino a che non avremo quello interno

- C'era un baco nel tag di act $hands, quindi se mai è stato utilizzato veniva
  tampato come "manos" perchè riconosciuto come tag di act $hand.
  Stesso problema per il tag di act $HANDS

- Aggiunti i tag di act $hand1 e $hand2. Rispettivamente ritorneranno la
  mano principale e la mano secondaria dell'entità in questione, quindi se
  entity è mancina stamperà:
  $hand1: mano sinistra
  $hand2: mano destra
  Aggiunti ovviamente anche $HAND1 e $HAND2 per target, quindi se target è un
  felar destro verrà:
  $HAND1: zampa destra
  $HAND2: zampa sinistra
  bisognerebbe riguardare almeno alla buona le occorrenze di hand in tutto il
  gioco e vedere se abbia senso da rimpiazzare con queste due, non credo che ve
  ne siano molte, se non nessuna.

- Fatta la procedura che permette di rimuovere oggetti dallo stesso nome prima
  dal wield poi dall'hold e infine da tutte le altre parti, la ricerca tramite
  contatore dovrebbe funzionare correttamente (remove 2.calzino)

- Aggiunta l'opzione di config gift_on_enter nella sezione GENERAL, è un'opzione
  facoltativa e serve ad indicare quale entità (item o mob) si vuole donare al
  pg che entra, l'entità verrà donata una sola volta; se si vuole disattivare
  la donazione (perchè per esempio l'evento è terminato) bisogna riavviare il
  mud togliendo l'opzione.
  Come valore dell'opzione ci vuole il codice di un entità prototipo di item
  o di mob
  totally untested! huzza!

- Aggiunto il comand wield, visto che è stata una generalizzazione del comando
  hold ora bisogna ricontrollare anche l'hold

- Ho implementato la base del comando seed, permette di inserire nel terreno
  fertile un oggetto seed_type, gli admin nella stanza vedranno l'oggetto come
  se fosse nella stanza ma con flag {SOWN}, mentre i giocatori non vedranno
  l'oggetto

- Aumentata di un pochettino la probabilità di guadagnare i px muovendosi tra
  stanze diverse

- Ho implementato un po' alla buona e senza testare nulla il comando seed e le
  basi della struttura SeedType. esempio di seme:
SeedType:
    Sectors: SECTOR.PLAIN SECTOR.MOUNTAIN
    Duration: 60
    WorseEntity: codice_entità_prototipo_peggiore
    NormalEntity: codice_entità_prototipo_normale
    BetterEntity: codice_entità_prototipo_migliore
End
Ecco, quelle mostrate sono le etichette attualmente implementate, Sectors è una
Flags facoltativa, se omessa permette di far seminare nei settori fertili, per
sapere quali sono vai a guardarti il file src/enums/SECTOR.py verso la fine,
può essere che verranno cambiati a seconda di quanto considereremo fertile un
settore in generale.
Duration son i minuti rpg (quindi ognuno è pari a due secondi reali) prima che
quello stage si attivi, quindi tu semini, e dopo 60 minuti rpg si attiva la
prossima entità con il proprio SeedType
Poi ci sono i tre codici di entità per le tre entità da creare nei differenti
casi, per ora carica in maniera automatica solo l'entità normal, ovvero tramite
comando seed protrai (dovresti poter) seminare un seme, questo dopo tot chiama
l'entità normale, quella dopo un tot chiama anch'egli l'entità normale e così
via fino al termine di SeedType, quindi per ora non c'è nessun ciclo vero e
proprio.
Al comando seed mancano alcuni check tipo puoi tentare di seminare te stesso o
cose simili, li ho omessi perchè assomigliano a quelli nel comando give e devo
pensare un po' se tenerli separati o fare una funzione generica unica.
E' tutto da provare

- Questa versione è da inserire anche nella 4000, ricordati delle impostazioni
  official


================================================================================
Rella 76
20/08/10

- Ora il look fatto dentro l'inventario di un mob o pg dovrebbe far visualizzare
  appunto l'altrui inventario

- Ho rinominato tutte le occorrenze di mudscript in gamescript, difatti ora
  verranno chiamati così (sto generalizzando il concetto di mud a gioco
  generico per poter in un futuro inglobare parte del sistema in ocarina)

- Ho rinominato le opzioni di config reload_mudscripts in reload_gamescripts
  e ho rinominato anche da mud_name in game_name

- Ho corretto il fatto che utilizzando l'opzione log_player_output a True
  crashasse

- Ho creato le due tooltip per visualizzare eventuali gamescript definiti
  o eventuali variabili di specials impostate su valori di quest o simili
  L'ho testato su charlie.
  Ho altresì modificato un po' le tooltip in generale, potrebbero esservi
  dei problemi.

- Ho aggiunto i trigger on_booting e on_shutdown, essi servono rispettivamente
  per fare qualcosa al boot del mud e al suo shutdown.
  Ho altresì modificato lo script di charlie ripulendolo un pochetto ed
  aggiungendovi i due trigger sopra per gestire il reset_call tra i vari riavvii.
  Ora che ho implementato questi due trigger gli specials possono avere la
  persistenza tra differenti sessioni di gioco.

- Ho corretto il baco che non leggeva il ModTemperature come percentuale
  ora si può utilizzare 130% come si dovrebbe


================================================================================
Rella 75
13/08/10

E' una release molto tecnica e rimaneggiata, bisogna effettuare un po' di
replace che devono essere fatti nell'ordine in cui li espongo.

* Negli script cambiare tutte le occorrenze di
from src.game<uno o più spazi>import game
in
from kadath.engine import engine

* Negli script cambiare tutte le occorrenze di
from twisted.python<uno o più spazi>import log
in
from kadath.log import log

* Sostituisci tutte le occorrence di game (meglio essere sicuro di modificare
  la parola intera e non suffissi e prefissi) in engine

* Bisogna modificare tutte le occorrenze nei file dei player da:
Level:        0
a
Level:        1

* Aggiunta l'opzione di config use_google_analytics nella sezione SERVER,
  per il server di testing è da tenere assolutamente a False, mentre per il
  server ufficiale è da tenere a True (non ci dovrebbero essere problemi di
  impostazione se utilizzi la nuova opzione di avvio --mode che viene spiegato
  più sotto).
  Inoltre ho aggiunto l'opzione di configurazione google_analytics_ua, sempre
  nella sezione SERVER, bisogna impostarlo a UA-17735247-1
  Ho altresì spostato l'opzione allow_robots dalla sezione DEVELOPMENT alla
  sezione SERVER.

- Ho implementato una feature carina, ho aggiunto l'opzione di avvio -m (con
  valori possibili testing e official), essa serve ad avviare il mud o in
  modalità di testing o in modalità ufficiale, tale modalità andrà a controllare
  all'avvio se le impostazioni del file di config sono allineate con la modalità
  Quindi se tu imposti per sbaglio allow_robots a False per il mud pubblico
  e lanci python start.py -m official questo ti avverte che non verranno
  indicizzate le pagine e ti chiederà se vuoi modificare l'opzione.
  Di solito inviando tutti N non si fanno danni, se però si vogliono opzioni
  di config particolari allora bisogna scegliere.

- Ho finalmente ripreso il vecchio sistema di log, ora dovresti essere più
  felice, per ora non sarà più possibile però loggare le richieste http

- Ho cambiato un po' il comando score aggiungendo i punti e le condizioni di
  fame, sete etc etc

- Ora tutti i giocatori partono dal livello 1 e solo per quel livello nessuno
  di loro soffrirà la fame, la sete, il sonno etc etc

- Aggiunto il trigger on_extract che serve a fare qualcosa quando un'entità
  mob o item viene rimossa dal gioco, nel tuo caso la cosa potrebbe essere
  utile per attivare lo script di deposing egg quando un pulcino/pollastra (non
  ricordo più come funzionava) viene appunto estratta, così da riprovare solo
  in quel mentre se vi sia la possibilità di aggiungere un pulcino/uovo/altro
  senza fare un loop infinito nascosto dalle callLater.

- Ho rimosso il supporto al MIML per le icone e le sottolineature, non riesco
  proprio a immaginare un Mud con la lista degli oggetti integrata nella
  descrizione, rischia di diventare troppo libro (e fatto pure male) e poco
  gioco.
  Quindi, a meno di rivolte, il MIML rimane un sistema di creazione di
  descrizioni dinamiche e basta.

- Ho aggiunto codesti behaviour:
LookEquipment
ListenEquipment
SemmlEquipment
TouchEquipment
TasteEquipment
IntuitionEquipment
  Funzionano come i corrispetti LookExtra, ListenExtra etc etc
  In pratica quando un behaviour si attiva su di un'entità c'è una probabilità
  che invece di 'sensarla' direttamente venga 'sensato' una tra le entità
  indossate.
  Non l'ho testato per nulla.

- Ho creato il trigger before_try_to_get, che ha lo stesso interfacciamento
  del before_get, per poter far funzionare il mudscript della torba.
  Ho provato con il sistema before_command_get come pensavo ma non funzionerebbe..
  Questo invece dovrebbe funzionare con uno script che ti allego nella mail
  inserito nel file del mucchio.

- A parte la persistenza dello specials, le note riguardo l'interfaccia e i
  To Do a lungo termine mi pare di aver tappato tutti i bachi segnalati
  sul google doc


================================================================================
Rella 74
07/08/10

* Ho cambiato tutte le occorrenze di TRUST.GAME_MASTER in TRUST.MASTER nel
  codice, devi fare anche tu la stessa cosa nei file *.dat

* Devi cambiare tutte le occorrenze di get_entity in find_entity nei file di
  mudscript

* Ho rinominato la flag BEHAVIOUR.INHERIT_AREA in BEHAVIOUR.FORCE_INHERIT_AREA,
  non credo che la utilizzassi tra i file *.dat comunque

* Ho rimesso com'era prima il sistema dei punteggi, quindi al posto di due
  punteggi ora ce ne sono ancora tre: vita, mana e vigore.
  Ciò comporta la modifica di tutti i file di dat dei giocatori che hanno
  qualcosa tipo:
<un po' di etichette>
Energy:       100
<un altro po' di etichette>
MaxEnergy:    100
<il resto delle etichette>

  Quello che bisogna fare è convertirli così:
<un po' di etichette>
Mana:       100
Vigour:       100
<un altro po' di etichette>
MaxMana:    100
MaxVigour:    100
<il resto delle etichette>

  Gioca con il carattere \n così sostituirai una riga con due, ma dovresti
  cavartela con i tuo comandi aramaici antichi senza che io ti passi dei
  suggerimenti.
  Attenzione che non è detto che tutti i giocatori abbiano sempre a 100
  codesti punteggi.

- Ho rifatto il sistema dei behaviour, ora a livello di codice va' molto meglio,
  non ho idea a livello di gioco, ma penso che per lo meno funzionino, per lo
  meno l'altro giorno ho visto il mindflyier annusarmi.
  Adesso le probabilità dei behaviour funzionano così:
  Prima di tutto il check sui beaviour viene eseguito una volta ogni due
  secondi reali, cioè ogni minuto rpg.
  Vengono eseguiti behaviour di una metà delle aree del Mud scelte a caso.
  Viene scelto, sempre casualmente, uno tra i behaviour: ma solo quelli
  definiti con un valore maggiore di zero.
  Infine viene controllato, lanciando un dado da 300, se il behaviour impostato
  all'entità per quella particolare azione sia abbastanza per essere eseguito.
  Non modificare ancora le etichette di behaviour estensivamente per adattarti
  alla frequenza di attivazione del nuovo sistema, prima dobbiamo parlarne un
  po' e verificare le impressioni.

- Questa ti piacerà: ho aggiunto l'opzione di config behaviours_only_for;
  serve a indicare di tracciare le statistiche dei behaviour delle sole entità
  con quel codice di prototipo, quindi se si inserisce
behaviours_only_for = mfdonald_mob_tofano
  nel file di config allo shutdown del Mud nella cartella /log/ ci saranno
  i valori behaviours_<data>.txt di solo quel tipo di Mob.
  Se si vogliono invece tracciare nuovamene tutte le statistiche di behaviour
  allora basta cancellare la riga con quell'opzione dal file *.ini

- Ho cambiato il sistema di refresh dellle informazioni dinamiche del sito
  (quello che hai commentato per evitare di rendere il log ipertrofico),
  adesso quando Aarit si accorge che non gli stai guardando le pagine del sito
  allora smette di aggiornartele e rinizia solo se rinizia ad utilizzargliele.

- Ho rimosso l'opzione test_address dal file di config.ini, era inutile, il
  sistema di comunicazione inter-server l'ho abbandonato.

- Ho cambiato praticamente tutti i nomi alle pagine web, questo darà fastidio a
  quelle poche persone che avranno inserito nei segnalibri degli url particolari
  del sito; si dovranno cuccare un bell'errore 404, ma vabbe', dovevo farlo e
  non ho tempo nè voglia di fare un sistema di autoredirect retrocompatibile.
  Ho provato tutto il sito, ma potrebbe essermi sfuggito qualche broken link.

- Risolto il vecchio problema dell'rgoto su stanze con codice comprensivo di
  trattino, come rgoto ikea_room_store-000

- Spostato l'ordine d'interpretazione delle extra dagli argomenti passati con
  il comando del giocatore: invece di
look <entity> <extra>
  funziona
look <extra> <entity>. Stessa cosa per gli altri comandi sensoriali.
  Rimane comunque il vecchio metodo di ricerca ma con priorità minore.
  Bisogna vedere se tutto regge..

- Aggiunta la possibilità di guardare gli oggetti addosso alle entità tramite
  la sintassi
look <indossato> <entità>
  Stessa cosa per gli altri comandi sensoriali.
  Anche qui funziona anche il metodo di ricerca con parametri invertiti con
  priorità minore.

- Aggiunta l'opzione di config track_triggers nella sezione [LOG], funziona
  sostanzialmente come il tracking dei behaviours, solamente quando ti troverai
  la riga tipo
  before_look: 10/2000
  Il primo numero è relativo alle volte che il trigger ha fermato il flusso
  normale del comando (cioè il mudscript ha ritornato True)
  Il secondo numero invece è il totale delle attivazioni per quel trigger

- Aggiunta l'opzione allow_zero_behaviours, per ora non mi soffermerei più di
  tanto su quest'opzione; potrei buttarla via, per ora tienla sempre a True

- Ho spostato queste opzioni di config:
server_name
mud_name
engine_name
engine_version
staff_name
motto
  dalla sezione [CFG] alla sezione [SERVER], inoltre ho rinominato la sezione
  di config [CFG] in [GENERAL]

- Ho aggiunto, nell'interfaccia di gioco, dei bottoni per la navigazione
  direzionale di base, ne aggiungerò con il tempo degli altri.
  Mi domando: forse sono troppo azzurri?

- Ho inserito in fondo alla pagina di gioco la barra dell'esperienza, essa non
  si aggiorna ancora automaticamente con il tempo (bisogna refreshare la pagina
  per ciò); se vi passi il mouse sopra vedrai il numero preciso dei px che
  possiedi

- Avendo reinserito i tre punteggi ho cambiato il layout del prompt, che trovo
  più chiaro e pulito, ed ho aggiunto sotto l'output il prototipo delle barre
  in percentuale di tali tre punteggi

- C'era un baco che impediva il guadagno passivo dei px nell'ultima release e
  forse anche in quella precedente

- Dovrei essere riuscito a dare il supporto al look sottolineato all'equip
  altrui, quello che si vede con il comando look

- Ho aggiunto delle informazioni di velocità di creazione e peso delle pagine
  generate di volta in volta, ogni tanto dagli un occhio.. valori fuori dalla
  scala normale, i rallentamenti o size troppo grande potrebbe essere sintomo
  di qualche tipo..

- Adesso il danno relativo alla mancanza di cibo aumenta logaritmicamente a
  seconda del livello del pg, a livello 1 il danno è sempre 0

- Ho raddoppiato il fattore di sazietà dato dall'eat, tuttavia mi sa che in
  futuro cambierò le cose. Avevo creato di base il comando eat per mangiucchiare
  pezzi di cibo e non tutto in un boccone, ma ciò comporta codice corollario
  non indifferente (descrizioni dinamiche di log di cibo smangiucchiato,
  eventuali entità create apposta per il singolo boccone.. etc etc)
  Devo ripensare al sistema.

- Dovrei aver diminuito di almeno un poco il gain della rigenerazione, avevi
  detto che ha rigenerato 100 punti hp in 20 secondi, ora vediamo
  (è da considerare il fatto che la rigenerazione dipende anche dal livello del pg)

- Aggiunte le razze, la lista completa è visualizzabile nel file
  src/enums/RACE.py
  Ho anche cambiato un po' le carte in tavola con le razze giocabili

- Da quel che ho capito il tuo sistema di backup evita di salvarsi le immagini
  in www, penso che sia sbagliata come strategia, visto che dal backup totale
  che mi hai fatto ho appena copiato e incollato le icone, che io non avevo
  come aggiornate.
  Quello che puoi fare per rendere il backup meno ciccio è evitare di salvare
  le cartelle e i file, nella cartella www, che iniziano con _
  Difatti ci sono le cartelle _archivio che hanno la roba sfuffa che mi serve
  come risorse di riferimento e che a aarit in realtà non servono.

- Ho trovato un'icona puccettosa per l'unicorno, che ho messo nella cartella
  icons/mobs (se vuoi spostarlo in animals fa pure, ma fore no perchè non
  intende un animale generico ma un mob particolare), tuttavia bisognerebbe
  colorare le icone a seconda dei tre mob, bianco, rosa e azzurro..
  Se vuoi fallo tu, io con gimp non mi ci trovo e devo ancora recuperare
  photoshop, bisogna cambiare il colore in sostanza, ci sono dei metodi apposta.


================================================================================
Rella 73
31/07/10

- Aggiunto il miml check sulla sessualità, quindi per esempio:
#looker is SEX.MALE#sei un macho!#sei una macha!#

- Quando uno effettua un rgoto e un altro admin lo vede può cliccare sulla
  destinazione sottolineata che apparirà per eseguire un rgoto veloce

- Fatto un sistema di refresh automatico delle informazioni prettamente
  dinamiche del sito, in particolare per ora vengono aggiornati il numero
  accanto al who e i nuovi messaggi inviati nella Piazzetta. In pratica
  rimanendo sempre nella stessa pagina le informazioni si modificano
  automaticamente.
  Mi ucciderai per questa feature, per il fatto che il sistema di log
  è ancora molto invasivo al momento e quindi vengono loggate tutte le
  connessioni nascoste per controllare se vi siano informazioni da aggiornare.
  Una volta che hai testato queste features per disattivare la pletora di
  messaggi di log, disattivando anche così il sistema di refresh, devi andare
  al file www/site.js e cambiare la riga
  setTimeout(function () { refreshInfos(); }, 2000);
  in
  //setTimeout(function () { refreshInfos(); }, 2000);
  ovvero commentarla.

- Aggiunto il trigger on_init, nella documentazione mudscript.htm c'è tutto
  quanto, ti dovrebbe bastare per l'occhio di bue.

- Ho ulteriormente riunito alcune funzionalità dei sensi direzioniali, ora
  tutti i 6 sensi funzionano allo stesso modo, dovrai ripetere tutti i test
  che hai effettuato l'ultima volta e vedere come vanno le cose

- Ho aggiunto una pagina web accessibile dal footer del sito, serve a contattare
  lo staff del mud, tutti i messaggi vengono inviati sulla mail di horde
  info@aarit.it
  Se non hai più il login e la password per fare dei test a riguardo fammi
  sapere che te li passo.

- Ho implementato il comando hold.
  Ci sono anche i trigger before_hold e after_hold, il cui interfacciamento
  è documentato alla solita pagina.
  Per il comando wield attendo la correttezza del comando hold visto che sono
  molto simili.

- Ho aggiunto le seguenti flag:
  FLAG.NO_HOLD che evita di holdare l'entità
  ROOM.NO_HOLD evita di far holdare entità nella stanza con questa flag
  FLAG.TWO_HANDS che servirebbe a holdare l'entità con tutte e due le mani,
  non è ancora supportata a livello di codice ma la flag esiste per poter
  estendere l'area anzitempo
  FLAG.AMBIDESTROUS indica che l'entità è ambidestra, non è ancora supportata
  a livello di codice ma servirà a lenire malus sull'utilizzo di armi con la
  mano secondaria

- Per supportare il comando hold ho dovuto rifaricchiare i comandi inventory,
  equipment e remove, sono quindi da ritestare almeno un po'

- Ho aggiunto un sistema di recupero dei punti di vita e di mana (per ora
  funzionano allo stesso modo per tutte le razze e classi)

- Ho aggiunto il sistema di hunger, ovvero ora si può morire di fame, in
  realtà non avendo ancora implementato il tristo mietitore i giocatori
  arriveranno inesorabilmente a 0 di vita senza riuscire morire.
  Il check sulla fame viene effettuato una volta ogni mezz'ora rpg (cioè ogni
  minuto reale). Mi è difficile capire se è troppo veloce o troppo lento,
  sarebbe da stare lì a giocare un po' e vedere quando appaiono i messaggi di
  fame.
  Quando si ha fame la rigenerazione dei punti avviene più lentamente, se si
  sta morendo di fame la rigenerazione dei punti è azzerata.
  Ho testato l'appetito ma non il suo lenire tramite il cibo.

- Il mud genera un file platform_infos_<data>.log nella cartella log ogni giorno
  che viene avviato, contiene il resoconto che ancora viene anche stampato
  all'avvio del mud

- Ho fatto la pagina con i credits

- Come ho detto nel google doc il test sui behaviour si freezano fino a nuovo
  ordine, devo rifare il sistema

- Corretto il problema dell'asincronia delle porte (tramite reset come abbiam
  scoperto ieri)


================================================================================
Rella 72
24/07/2010

* Modificato l'interfacciamento con i trigger
before_give
after_giove
before_put
after_put
devono avere come ordine dei parametri:
colui che sta dando/mettendo.
colui che viene dato.
colui che riceve.

- Ok, ho messo a posto l'on_reset della gallina e con me funziona, se non
  funziona sul serVVer così com'è allora è colpa della python 2.5 e non posso
  (o meglio voglio) farci nulla, in quel caso si fa prima ad aspettare la 2.6
  e l'on_reset rimane in parcheggio
  ... mi ha riempito il mud di ovetti dopo poche ore... 10000 ovi e passa!

- C'era effettivamente un problema che inficiava sulla funzionalità della pagina
  di gioco con firefox 3.0, l'ho corretta, ora Shako non dovrebbe avere problemi
  di connessione se volesse utilizzare Firefox

- Ho aggiunto la possibilità di vedere le extra alle uscite, alle mura e alle
  porte, ho dato la stessa feature anche ai comandi sensoriali, anche se
  temo che questi possano comportarsi in maniera differente rispetto al look
  (escludendo i vari bachi di crash che forse incontreremo)

- All'avvio del mud dovresti trovare delle informazioni interessanti che ti
  chiedo di inviarmi, immagino che tutte queste informazioni si possano ricavare
  da vari comandi linux più o meno esoterici, non so quanto sia affidabile la
  descrizione del "(real) processor", nella documentazione del python viene
  proprio detto proprio così, parentesi comprese, bho; vediamo cosa esce fuori.
  Per ora le informazioni le stampo solo a console e non le scrivo su file,
  forse in futuro potrebbe essere utile stamparle su log per controllare
  che quelli del server cambino o meno qualche cosa?

- Ho cambiato LEFT_LEG e RIGHT_LEG in LEFT_TIBIA e RIGHT_TIBIA, anche tu dovrai
  modificare così nei dat.
  Stessa cosa per LEFT_ARM E RIGHT_ARM, li ho rinominati in LEFT_BICEPS e
  RIGHT_BICEPS.
  D'ora in poi "tutto il braccio" e "tutta la gamba" sarà semplicemente "il
  braccio" e "la gamba", mentre per inserire qualcosa sul braccio anatomico
  e gamba anatomica bisogna utilizzare bicipite e tibia.
  Meglio di così direi che non riesco a fare.

- Ho rifatto una parte del sistema di attivazione dei behaviour, si rinizia
  da zero con i test sulla frequenza degli stessi.
  Ricordavo che il massimo di percentuale behaviour fosse 400, invece ho visto
  che l'ho inserita a 300, a te torna?

- Ho creato le tooltip per tutte le tipologie di ENTITYPE attualmente definite
  le potrai vedere nel look di un'entità, potrebbero servire per capire meglio
  cosa funziona e cosa non funziona nelle porte a/sincrone (anche se non credo)

- Ho creato un sistema che permette di tracciare il numero di esecuzioni andate
  a buon fine rispetto al totale di esecuzioni dei differenti behaviour.
  Il sistema è attivabile con l'opzione track_behaviours sotto la sezione
  DEVELOPMENT del file di config.
  Il sistema alla chiusura del mud creerà un file nell cartella log, con la
  data dello shutdown, dovrebbe essere autoesplicativo, ma se non riesci a
  comprenderlo fammi un fischio.

- Ho spostato le seguenti opzioni nella sezione [LOG]:
log_player_output
track_behaviours
  Ho inoltre spostato le seguenti opzioni nella sezione [SQUARE]:
show_square
max_square_msg_len
max_square_msg_show

- Ho inserito l'ultima formula esponenziale da te suggerita per l'experience.
  Ho modificato altresì il gaining di un px per volta così:
  Se uno non ha cambiato di stanza guadagna un px per ogni secondo rpg con la
  probabilità di 1 su 200.
  Se uno si sta muovendo tra le stanze guadagna un px per ogni secondo rpg con
  la probabilità di 1 su 10.
  Ho rimosso dal calcolo delle probabilità il logaritmo visto che ora abbiamo
  già una roba non proporzionale.

- Ho modificato un po' le carte in tavola con i link della documentazione
(in
  vista di un futuro rifacimento del layout), sia quella del codice che quella
  del building, alcuni link potrebbero non funzionare più; anche l'aspetto
  potrebbe essere differente e se qualcosa ti sembra peggiore fammi sapere.

- Ho fatto la pagina di wear_type.htm nella documentazione di building
  aggiungendo alcune etichette.
  Seguendo la stesura della pagina ho effettuato delle modifiche ai comandi
  wear e remove, potrebbero avere degli scossoni.

- Corretto un bachetto nella scelta dei comandi da inviare dalla history tramite
  le freccine della tastiera alla pagina di gioco, se qualcosa non torna fammi
  sapere.

- Ho spostato di due pixel in basso le iconcine per farle sembrare più
  allineate alla sottolineatura, alla fin fine il problema era quello no?
  Pensi che ci voglia comunque una spaziatura poi?

- Ho effettuato una o due modifiche al comando look e varie modifiche ai
  comandi sensoriali; avendo unito in un'unico comando, basterà testarne uno
  per sapere se gli altri funzionino o meno.
  In particolare ho implementato un sistema personalizzabile di messaggi di act,
  detto in altre parole ora finalmente le azioni sui behaviour sensoriali che
  potranno quindi essere visti da terze parti.
  Aggiungo comunque che alcuni messaggi non vengono inviati alle terze parti
  come per esempio quelli relativi all'intuito.
  Bisognerà rieffettuare i test sensoriali che mi avevi fatto sulle
  direzioni/porta/maniglia, ti ricordi? Utilizza lo stesso approcio, era ottimo.


================================================================================
Rella 71
16/07/2010

- Corretto il problema che non faceva usare le scorciatoie CTRL+C e simili
  nella finestra di gioco del Mud

- Aggiunta l'etichetta Icon a stanze e entità (anche player), essa contiene
  la path ad una immaginetta partendo da www/
  Quindi se inserisci
  Icon: icons/gems/opale.png
  e inserisci la relativa immagine nella cartella www/icons/gems/opale.png
  nel mud quando vi sarà quell'entità per terra si vedrà accanto l'iconcina.
  Per le stanze l'iconcina si visualizzerà accanto al titolo, può essere utile
  identificare stanze importanti: come incroci, piazze, negozi o che.
  Si potranno vedere anche nell'output dell'equipment e dell'inventory.
  E' meglio che il nome delle immagini siano corti, basta che siano chari ed
  identificativi del loro contenuto.
  Le immagini devono essere 16x16, preferibilmente png (probabilmente nei
  prossimi mesi ciò diverrà un must) e preferibilmente con sfondo trasparente
  anziché nero.
  Le immagini di icona dovrebbero essere salvate tutte nella cartella
  icons, suddividendole per tipologia, weapons, foods, gems, helms etc etc; ogni
  tipologia è una sottocartella in icons. Non c'è bisogno che il nome delle
  sottocartelle sia pari pari agli ENTITYPE, basta che diano comunque un'idea
  catalogativa.
  C'è anche la possibilità di puntare ad un'immagine esterna ad Aarit se
  si inizia la path con http:// in quel caso l'icona verrà cercata esternamente;
  comunque per ora non abbiamo bisogno di questa feature.

- Per trovare delle icone adatte puoi utilizzare un metodo felino, bisogna
  prima di tutto andare qui:
  http://www.google.com/images?um=1&hl=it&tbs=isch%3A1%2Cisz%3Aex%2Ciszw%3A16%2Ciszh%3A16&sa=1&q=unicorn&aq=f&aqi=g10&aql=&oq=&gs_rfai=
  e cercare il nome di un'immagine di quello che si vorrebbe, in questo caso
  la parola chiave della ricerca è  unicorn  e le dimensioni sono 16x16.
  Quindi bisogna scorrersi un po' di iconcine fino a che non si trova quella
  che garba di più; ATTENZIONE bisogna aprire il sito in cui si trova per
  salvarla (probabilmente sarà una gif o una png) mentre invece le immagini
  che google elenca sono più sgranate perché jpg, NON bisogna salvare quelle!
  Se non si trova nulla di buono si può anche fare una ricerca sulle immagini
  17x17 o 18x18 etc etc, di solito infatti si può croppare l'eventuale
  spazio attorno l'immagine per renderla finalmente a 16x16 (il nostro must).
  Se serve inserire la trasparenza.
  E ricordo che è meglio png di una gif.

- Aggiunti i link cliccabili per le entità anche per il comando equipment

- Ho inserito il trigger di mudscript on_reset, si attiva in questi casi:
  * solo se l'entità o la stanza sono state appena resettate
  * quindi non quando ci sono delle persistenze già esistenti
  * solo dopo che la room o l'entità ha resettato anche tutto il suo contenuto
  Puoi utilizzare questo trigger per il mudscript della gallina in ikea, c'è un
  esempio funzionante all'oggetto limbo_item_random2, per raggiungerlo bisogna
  scrivere igoto casuale

- Ho rimosso le pagine di show notes, tanto non andavano, penso che le note
  siano gestibili anche così, tramite file, per un po' di tempo, anche se non
  sono visibili da tutti sul sito.
  Le note obsolete si possono cancellare senza timore, scanso bachi, che il
  counter delle note inviate di quella tipologia si sballi.

- Ho fatto i behaviour anche per gli altri sensi, non che la cosa sia molto
  visibile dagli altri nella stanza visto che non esistono i messaggi di act
  lato OTHERS, sarà una delle mie prossime modifiche.
  Le etichette sono tali quali a quelle del look, ovviamente al posto del look
  bisogna inserire uno degli altri comandi, quindi per esempio:
TouchPlayer
TouchMob
TouchItem
TouchSelf
TouchAtRaces
TouchAtRacesFlags
TouchAtEntitypes
TouchAtEntitypesFlags
TouchDirection
TouchExit
TouchWall
TouchClosedDoor
TouchExtra
  E' tutto da testare, per ora basterebbe controllare che i look behaviour
  funzionino, visto che la medesima funzione gestisce anche gli altri sensi;
  poi si potrà passare a controllare gli altri sensi qui e là tramite snoop,
  a caso, non serve controllare tutto quanto

- Mi grepperesti la parola timeout nei file di una specifica cartella della
  distribuzione python del serVVer? la path dovrebbe essere qualcosa del tipo:
???/Python25/Lib/site-packages/twisted/web

- Ma le uscite hanno le extra visualizzabili o no? prova a controllare per
  favore

- http://www.facebook.com/pages/Aarit/139362302748498

- Ho rifatto il sistema delle descrizioni dinamiche, ora si chiama miml
  Mud Internal Markup Language
  esempi di miml:
Se l'oggetto ocarina esiste nella stanza #ocarina_code#allora fa
leggere questo#altrimenti questo#. Capito?
  Se devi stampare il nome/short dell'oggetto nel ramo if allora devi
  utilizzare il simbolo @, esempio:
Se l'oggetto ocarina esiste nella stanza #ocarina_code#allora vedrai
proprio @#altrimenti nulla#. Capito?
  Altra feature del miml è quella di poter inserire dei check riguardo
  all'entità della descrizione oppure a chi la sta leggendo, esempio:
Siam tre piccoli porcellin#looker is RACE.FELAR#, tu invece sei un
felorin# e tu invece sei un porcon#.
  per ora di questo sistema di check scriptoso c'è solo il controllo della
  razza del looker, mano a mano aggiungerò feature dove possibile e su richiesta
  Per completezza c'è da indicare un ultimo esempio:
Siam tre piccoli porcellin#looker is not RACE.FELAR#, tu invece non
sei un felorin# e tu invece non sei un porcon#.
  Se vuoi evitare che uno dei due rami del check invii qualcosa allora
basta che sia vuoto:
Se l'oggetto ocarina esiste nella stanza #ocarina_code#allora vedrai
proprio @##.
  oppure caso contrario:
Se l'oggetto ocarina esiste nella stanza #ocarina_code##non saresti qui#.
  Tuttavia come vedi una volta che si vuole inserire un carattere # per fare un
  miml devono esistere anche gli altri, il conteggio rimane fisso
  Prova a giocarci e vedere cosa fare, ho già inserito il supporto al link
  cliccabile e l'eventuale icona accanto.

- Il sistema delle descrizioni dinamiche ora viene supportato anche dalle
  entità e non soltanto dalle room, ciò significa che si può far variare le
  descrizioni dinamiche a seconda di ciò che c'è di indossato. Tutto da testare.
  In questo caso il check di RACE può essere fatto a tutte e due, sia a self
  che a looker.

- Aggiunta la pagina web trusts che visualizza tutte le trust degli account e
  dei giocatori

- Non so neppure io quello che ho fatto, ma se uno inserisce il codice $N e
  simili, cioè quelli per il target, nella descrizione della stanza e
dell'entità
  allora $N dovrebbe far visualizzare il nome dell'entità descritta.
  L'idea è scaturita leggendo le descrizioni della casina di sophie, sarebbe
  bene utilizzare l'$N al posto di stringhe inserite così di grezzo.
  In generale comunque non bisognerebbe utilizzare frasi contenente concetti
  che il personaggio rpg potrebbe non conoscere ancora (anche se il giocatore
  off-rpg magari li conosce o li deduce facilmente).
  Tornando ai codicie $-maiuscoli, molti di essi non funzioneranno per la
  descrizione della stanza, poi ché la stanza è un'entità a parte differente
  dalle altre, e non possiede tutte le caratteristiche (tipo $HANDS).


================================================================================
Rella 70
10/07/2010

* ATTENZIONE! In questa release verranno zappate tutte le note dei giocatori,
  se vuoi fatti una copia grezza dalle pagine Show Typos, Show Idea e Show Bugs
  così da averceli in ogni caso.
  D'ora in poi le note avranno le cartelle apposite data/typos, data/bugs e
  data/ideas; i relativi dati verranno salvati durante l'invio della nota e non
  alla chiusura del Mud.
  Ho altresì seguito il tuo consiglio di migliorare l'indicazione da dove viene
  inviata la nota.
  Per evitare casini ti consigli di rimuovere "a manina" tutti i riferimenti
  alle tre strutture, perchè altrimenti le etichette zombie potrebbero andare
  ad associarsi con altre stringhe, per la natura non tildosa di Aarit.
  Per l'occasione ho modificato la gestione del codice dei tre comandi, che è
  unita ora in un'unica funzione, quindi se uno dei comandi ha un baco, anche
  gli altri due ce lo dovrebbero avere.
  Sicuramente non funzioneranno più le pagine per la visualizzazione delle note,
  non c'è bisogno di inviarmi bachi a riguardo, dovrò rifare la pagina html

* Ho modificato l'etichetta WearableType in WearType, dovrai modificarne le
  occorrenze tra i dati

* Ho cambiato il nome dell'etichetta Behaviour RandomDoCommands in
  RandomDoInputs, dovrai modificarne le occorrenze tra i dati

- Aumenta le opzioni di config max_account_typos, max_account_ideas e
  max_account_bugs da 100 a 1000

- Aggiunta l'opzione sending_interval con un valore in secondi che rappresenta
  l'intervallo minimo di attesa tra l'invio di una nota typo, bug o idea ed
  un'altra

- Ho unito il comando give e put, che avevo duplicato e separato erroneamente,
  ora c'è una gestione generica per tutti e due, ma potrei aver fatto casini,
  andrebbero provati un poco

- Ho aggiunto l'etichetta TargetCode per gestire i portali collegati ad
  un'entità precisa
  Se assieme a questa etichetta viene inizializzata anche Destination il portale
  funziona SOLO se Target si trova in Destination.
  Se esistono più istanze di target con quel codice di prototipo allora ne
  pesca una a caso.
  Ho scritto una pagina di documentazione portal_type.htm

- Ora il guadagno automatico di un px al secondo è legato anche allo spostamento
  del personaggio da una locazione ad un'altra, se rimane sempre nella stessa
  stanza non guadagna, quando Aarit vede che si trova in una stanza differente
  la probabilità di ricevere un px è identica a prima

- Mi ero dimenticato dell'ENTITYPE.WEAR per le entità che abbisognano di
  questo UsedAs, l'ho aggiunto

- C'era un baco nei Messages inviati durante il reset, funzionavano solo quelli
  che iniziavano senza asterisco, l'ho corretto

- Ho aggiunto nella struttura EntityResets l'etichetta Inputs, che
  funziona concettualmente come l'etichetta RandomDoInputs dei Behaviour:
  durante il reset viene eseguito a caso uno tra gli input dichiarati.
  Ho rivisto la documentazione sui reset delle entità: entity_resets.htm.

- Ho creato un abbozzo al sistema di descrizioni dinamiche per le sole stanze
  al momento, funziona così:

Bla bla bla bla bla descrizione della stanza bla bla bla bla;
#codice_prototipo_entità frase dipendente dall'esistenza dell'entità codice.
Resto della descrizione bla bla bla gne gne gne.

  A seconda dell'esistenza o meno di codice_prototipo_entità la relativa frase
  divisa da punteggiatura esiste o meno.
  #codice_prototipo_entità viene sostituito come se fosse un $N.
  Le frasi che contengono un codice di tag # sono separate da punto, virgola e
  punto e virgola. Purtroppo, ora come ora, non dalla congiunzione 'e' e dai
  due punti.
  Le descrizioni dinamiche sono supportate per tutte le 6 descrizioni sensoriali
  e le relative notturne.
  Il sistema per ora funziona solo con le descrizioni della room, niente extra.

  COSA FARE CON QUESTO SISTEMA:
  Il Mud rimarrà così com'è, la lista delle uscite e delle entità esisterà
  ancora, ci sarà solo l'ulteriore possibilità di far dipendere un pezzo della
  descrizione della stanza dall'esistenza o meno di particolari condizioni (che
  per ora è solo l'esistenza di una entità o meno, in futuro ci saranno altri
  tag # come quelli che indicano se si è a mezzogiorno o a mezzanotte).
  Abbandonerei il sistema di entità integrate nella descrizione perché come
  l'avevamo pensato non faceva conto delle entità spostate da una stanza ad
  un'altra, in quel caso sarebbero state delle long aggiunte come elenco nella
  descrizione, una cosa poco elegante, a questo punto facciamo prima a
  mantenere il sistema così com'è che salta meglio all'occhio e ne migliora la
  giocabilità, secondo me.
  In conclusione questo sistema serve a rendere dinamiche le parti di
  descrizione che sono dipendenti dall'esistenza o meno di un'entità spostabile
  nella stanza.

- Aggiunto il sistema di riconoscimento automatico degli url per la piazzetta;
  per ora funzionante solo se la si ricarica.

- Adesso se farai di nuovo l'errore
Exits:
  Direction: DIR.SOUTH
  Descr: altroquando
Exits:
  Direction: DIR.EAST
  Descr: altroquando
End
Aarit ti avvertirà, pasticcione!

- Ho aggiunto l'opzione di config allow_robots, quest'opzione è molto
  importante e se impostata a False serve ad evitare che i bot dei vari motori
  di ricerca indicizzino le pagine del sito di Aarit.
  Quindi bisogna impostare a False per l'aarit di test, mentre per quello sulla
  porta 4000 bisogna utilizzare True
  Non bisogna assolutamente sgarrare quest'opzione, altrimenti puoi immaginare.
  All'avvio del Mud, poco prima di dire su che porta gira, viene indicato che
  impostazione è stata conferita all'opzione.

- Ho inserito i seguenti trigger:
before_look e after_look
before_listen e after_listen
before_smell e after_smell
before_taste e after_taste
before_touch e after_touch
before_intuition e after_intuition
  Essi si attivano ai rispettivi comandi solo quando ritornano una valida
  descrizione sensoriale, extra o meno che sia.
  Per ulteriori info vedere la pagina di documentazione apposita: mudscript.htm
  L'interfacciamento ai mudscript è stato molto più complesso del previsto,
  potrebbero esservi dei bachi, forse il modo più veloce per testare il tutto
  sarà quando avrò implementato i behaviour sensoriali.

- Ho riunito nuovamente i comandi sensoriali in un'unica funzione che li
  gestisce tutti, era diventato difficile da manutenerli, ora andrà meglio, ma
  le modifiche potrebbero aver comportanto scompensi ormonali al loro
  funzionamento

- Modificato il comando coords per far visualizzare anche l'eventuale short
  notturna della stanza

- Nella cartella principale aarit/ troverai lo script che mi avevi chiesto
  per l'after_look:
  codice_stanza.py
  non l'ho testato

- Ho fatto una modifica allo script di charlie, che aveva un baco che avevamo
  lasciato indietro, ti ho laciato due righe anche nel google doc


================================================================================
Rella 69 (Release Open Source v0.8i)
03/07/2010

- Ho creato il comando links... so già che mi amerai

- Nel file di config ho modificato la voce max_square_msg_len da 64 a 100
 Ho altresì aggiunto la voce max_square_msg_show che indica il numero di
 messaggi della piazzetta visualizzabili sul sito

- Ho aggiunto il supporto per Firefox 2.0 (così da permettere la connessione
 tramite MacOs 10.3) e per Internet Explorer 7, può darsi che abbia risolto
 automaticamente anche il problema che avevi tu con Internet Explorer 8,
 quindi c'è da provare

- C'era un baco nella navigazione della history dei comandi di internet explorer
8, corretto!

- Nella pagina di gioco ora disattivo il check sui tasti, compresi quelli per
 la navigazione della history, se vengono utilizzati i tasti alt e ctrl

- Risolte le varie segnalazioni nel google doc di test come indicato lì

- Dovrei aver corretto il funzionamento del font courier, "ovviamente" non
 modifica dinamicamente il font courier una volta che clicchi e salvi l'opzione
 ma solo dopo aver ricaricato la pagina di gioco

- Ho aggiunto la pagina Aiuto con la lista dei browser compatibili con il gioco
 se hai tempo e possibilità mi premerebbe testare OPERA 10.0 e SAFARI 3.0
 perché se per caso non funzionano dovrei riuscire a farli andare con poco
 Ad Dante 10.54 sotto xp funzionava, a me sotto Windows / non funziona..
 ora l'ho fatto funzionare da me, ma magari a Dante ora non va' >_<
 bisognerà un po' vedere.

- Aggiunta l'etichetta WearMode agli EntityResets, funziona come il WearMode
 nell'entitype Wearable (anche le stanze possono essere wearate senza errore
 anche se non ha molto senso, vedremo se lo troveremo) si può inserire un
 wear mode differente da quello supportato dall'oggetto Wearable (in effetti
 l'oggetto vestito potrebbe non essere affatto un Wearable...) ma non so cosa
 accada in tal caso

- Avevi provato ad inserire una parte non umana come wear e provare? che ne
 sono.. le ali, per ora tutti quanti utilizzano le parti di wear degli umani

- Se si mette IE in modalità compatibile oppure se si aumenta la sicurezza
 allora smette di funzionare l'output, ora però dovrebbe andare


================================================================================
Rella 68
27/06/2010

* Ho modificato l'etichetta WearLocations in WearMode, quindi bisogna sostituire
 tutte le occorrenze tra i dati, specie tra i player anche se si tolgono le
 persistenze

- Aggiunti i trigger before_put e after_put

- Aggiunto il comando put

- nello script di charlie bisogna cambiare l'interfacciamento al trigger del
 give, la riga con:
def before_give(player, charlie, banana):
 bisogna cambiarla in:
def before_give(player, banana, charlie):

- Corretti vari problemi come indicato nel doc di test

- Dovrei aver migliorato l'output dell'equip e del wear relativamente
 al messaggio delle parti


================================================================================
Rella 67
27/06/2010

- Risolta la ricerca dell'entità anche nell'equip per i comandi give,
drop e eat.
 Ho risolto il problema alla radice quindi non vi saranno altri comandi con
 questo problema, c'è da vedere comunque se alcuni comandi non necessitino di
 una ricerca estesa anche all'equip invece del solo inventario.

- Corretto il salvataggio e il ricaricamento dell'etichetta Modes

- Ho spostato l'etichetta MaxQuantity per i proto_mobs e proto_items
 rinominandola in MaxGlobalQuantity, tutta da testare

- Nel comando equip ora non vengono visti gli organi interni nel qual caso
 venisse indossato loro qualcosa

- Aggiunti i mudscript before_remove, after_remove, before_wear e after_wear
 maggiori informazioni nella pagina di documentazione apposita

- Ho fatto il comando remove

- Non sono riuscito a trovare il baco delle coccarde e la cesta.. tuttavia ho
 modificato un po' di codice ripulendolo un po' ed aggiungendovi dei messaggi
 di debug del tipo
 ->RESET.PUT bla bla<- bla bla bla
 Forse le mie modifiche hanno già migliorato da sole, forse no.. vedremo

- Corretto il baco che bloccava la possibilità di utilizzare modalità di
 wear multiple: i Modes

- Ho inserito l'opzione autoget che serve a rendere opzionale il get automatico
 del comando give ed eat quando non si trovano oggetti nell'inventario

- Ho aggiunto la flag di opzione Courier che serve a visualizzare l'output
 come vorrebbero gli inguaribili nostalgici

- Fatta la pagina degli screenshots


================================================================================
Rella 66
26/06/2010

- Corretti i problemini al sistema di history dei comandi

- Aggiunta l'etichetta MaxQuantity agli EntityResets, indica il numero massimo
 di instanze in gioco creabili nel Mud, tramite reset o altro (è l'altro che
 porterà potenzialmente a bachi, tipo creazione di entità tramite script e
 relativo inserimento in gioco, sforando eventualmente il maxxaggio).
 Un valore uguale a zero, che è il valore di default, significa che non vi
 sono limiti nella creazione in gioco di quell'entità.
 Un valore uguale a 1 (o molto basso) significa che quell'oggetto è un Unico
 (o un Raro) ci sarà un'implementazione particolare per questi oggetti che
 sono di norma molto particolari e potenti

- Risolto il typo grugnisce/grugnisci degli orchi

- Fatto il wear
Prima di tutto bisogna creare un oggetto indossabile facendogli la struttura
di etichetta
WearableType:
   Modes: PART.qualcosa
End

al posto di qualcosaci si inserisce una delle parti del corpo presa dalla lista
apposita:
http://www.aarit.it/doc/builder_manual/elements_list.htm
in teoria, e non ho testato, se ne possono mettere di più (come si possono
inserire più modalità di wear per lo stesso oggetto), ma andiamo per gradi,
le cose semplici all'inizio.

Una volta inserito questo.. basta.. vai in game, raccogli l'oggetto, guarda
che ce l'hai inventario, controlla che non hai nulla nell'equip, indossa
l'oggetto, e ricontrolla inventory ed equip.

Non ho ancora implementato il comando remove per togliersi di dosso gli
oggetti indossati, conto di farlo oggi, ma vedremo.


================================================================================
Rella 65
19/06/2010

- Ho reso le porte sincrone, scanso apposita flag
 Sicuramente vi sono dei problemi, soprattutto riguardo i messaggi di output
 da un lato e dall'altro nei differenti casi.
 (Messaggi da non leggersi se una delle due porte è chiusa etc etc)

- Probabilmente non ci crederai.. ma son riuscito a far funziona la nuova
 interfaccia di gioco anche sotto internet explorer!!!
 Ha problemi a dire quando il pg si sconnette ed a riconnettersi mi pare, e
 penso che avrà anche i vecchi problemi dell'output che si incrica dopo un po'
 che avevamo nella vecchia pagina, ma vabbe', più di così per ora non si può
 fare..

- Relativamente alla voce Snooper del documento di test il problema è stato
 risolto

- Relativamente alla voce food del documento di test:
Normale per ora, i food hanno il riferimento contained_by ma poi non
si trovano dentro il riferimento stesso ma nel suo stomaco.
Nella prossima release eseguo un check migliore così da evitare questo
falso allarme.

- Relativamente alla voce Door del documento di test il problema non dovrebbe
 più sussistere

- Ho creato e/o modificato una serie di script che troverai nel pacchetto a
 a parte così da copiarli dopo che tu avrai pasticciato i tuoi personali dat

- I nuovi trigger sono spiegati, si fa per dire, nella pagina di documentazione
 apposita che già conosci

- Ho testato un po' lo script di charlie, ma non del tutto, è abbastanza
 complesso alla fin fine, con ste callback viene fuori molto spaghettoso

- Giusto per farti sapere per ora creo e inserisco i mudscript dentro mfdonald,
 non è solo per debugging, è che in futuro l'area verrà sempre rilasciata nel
 pacchetto open source, così da dare agli altri un esempio d'utilizzo

- Ho fatto un modifica per provare a correggere il problema che mi indicasti
 via SMS relativo agli oggetti visualizzati con Behaviour LookItem anche se
 hanno flag NO_LOOK_LIST, ho provato a mettere il cavatappi nella stanza dello
 gnomo aumentando il LookItem a 400 e togliendo vari oggetti, e non ha mai
 guardato il cavatappi..
 Tutta questa descrizione per dire che alla fin fine l'errore non ci sarebbe
 dovuto essere nonostante la modifica, quindi se il problema è capitato prima
 per un caso specifico ricapiterà ancora!

- Ho spostato la sottocartella views dalla cartella data alla cartella
 src/controllers che ha più senso che stia lì

- Fatto il sistema della history come la voleva Bardolfo, ha qualche
difetto cmq..
 lo dovrò rivedere appena ho un attimo

- C'era un baco che con etichette WanderClosedDoor i mob si muovevano cmq tra
 le uscite aperte, so che questa etichetta non ha molto senso ora, ma in futuro
 quando verrà aggiunta maggiore intelligenza artificiale ai mob
questi apriranno
 automaticamente le porte, quindi questa etichetta dev'essere vista come una
 volontà a far aprire le porte chiuse ad una entità.


================================================================================
Rella 64
12/06/2010

* Ho implementato il primo mudscript di aarit! Vero p0ww4 mao!
 Fermo lì! Non iniziare a cancellare tutti proto_items che c'è una cosa che ti
 serve!
 data/proto_items/mfdonald/mfdonald_item_cervello.py
 Esso contiene tutti i mudscript per l'oggetto prototipo
mfdonald_item_cervello.
 In questo caso ce ne sono due, uno che sia attiva poco prima aver posato
 il cervello e uno che si attiva poco dopo, il primo si attiva sempre al
 comando drop, mentre il secondo si attiva solamente se appoggi il cervello
 in una room con settore pianura o foresta.
 Quello che ti serve fare è copiare e incollare questo file nella tua directory
 data in cui c'è l'oggetto prototipo del cervello fritto (mfdonald).

 Se vuoi far funzionare il mudscript per qualsiasi altra entità (per ora mob
 e item, in futuro dovrei aggiungere il supporto anche per i mudscript ai
 personaggi e molto altro) devi rinominare il file di muscript *.py con il
 codice prototipo dell'entità voluta, inserire poi il file nella stessa
 cartella di quell'entità et voilà!
 Se invece non vuoi che i mudscript di quei file non vengano attivati aggiungi
 un carattere di underscore come prefisso al nome del file, così eviterà di
 caricarlo all'avvio.

 Dopo aver provato in game il mudscript sentiti libero di guardarne il codice,
 l'ho commentato un po' a tuo uso ed abuso.
 Come potrai notare dovresti riuscire ad aggiungere cosine copiando il codice
 già esistente, per esempio aggiungendo messaggi d'act durante l'after drop
 oppure aggiungere un'altra callLater, cmq se non ce la fai ti darò
una zampata,
 ehm.. una zampina volevo dire.

 Ho fatto un'aggiunta estemporanea e ora dovrebbero esservi anche i trigger di
 mudscript per il comando get. Quindi se per esempio rinomini la funzione
 before_drop in before_get il mudscript si attiverà poco prima dell'esecuzione
 dell'azione di get invece che quella del drop. (cmq non l'ho provato)

 In conclusione per ora abbiamo 4 trigger che attivano i mudscript:
 before_drop
 after_drop
 before_get
 after_get
 dovrebbero essere self esplicativi
 Da quel che sto immaginando possiamo aggiungere tutti i dannati trigger che
 vogliamo e spesso senza troppo sforzo (pena però l'aumento da parte del mud
 della cpu, ma chi se ne frega!!), li aggiungerò cmq mano a mano.

 Aggiunta estemporanea 2:
 To'! Per la tua felicità ho anche scritto due righe di documentazione nel file
 mudscripts.htm che espongono a grandi linee il sistema, vattelo a leggere
 altrimenti non capirai nulla di quello che ho scritto di seguito!
 Come leggerai viene detto che i mudscript possono bloccare il normale flusso
 del gioco, codesta feature è già implementata. Ha comunque più senso
 utilizzare questa feature con i trigger di tipo before_, perchè possono
 evitare un'azione, per testarlo(cosa che non ho opportunamente fatto) bisogna
 forzare un valore di ritorno positivo ai mudscript; vedi che nel codice ogni
 tanto ci sono dei return? Ecco al posto di quelli scrivere return True
 (per pulizia bisognerebbe scrivere return False agli altri, ma è facile
 dimenticarselo ed è la stessa cosa). Alla fine di ogni funzione di
 mudscript c'è un return implicito (se non esplicitato) anche questo si può
 convertire in return True ovviamente, per esempio prendiamo il mudscript che
 conosciamo:
def before_drop(entity, brain, room):
   # Se il giocatore cerca di abbandonare il cervello ne riceve un simpatico
   # tentacoloso messaggio
   entity.act("$N pulsa come se... come se... come se... volesse
conquistare il mondo!", TO.ENTITY, brain)
#- Fine Funzione -
 lo si può convertire in
def before_drop(entity, brain, room):
   # Se il giocatore cerca di abbandonare il cervello ne riceve un simpatico
   # tentacoloso messaggio
   entity.act("$N pulsa come se... come se... come se... volesse
conquistare il mondo!", TO.ENTITY, brain)
   return True
#- Fine Funzione -
 e vedere che subito prima del drop.. non dropperà nulla! (bloccando appunto
 il normale flusso del gioco per quel comando, i force daranno messaggio di
 fine NON avvenuta del comando)

 Dovrebbero funzionare anche i trigger di room, cioè se inserisci un file di
 mudscript nome_codice_stanza_prototipo.py e vi inserisce la funzione
 before_get questa dovrebbe attivarsi per ogni get che viene tentato... mbha
 vedremo se funzionerà.
 Per ora cmq non funziona il mudscript generico ad area.

 Altra feature da non sottovalutare è il ricaricamento automatico dei mudscript
 con l'opzione di config reload_mudscripts a True, ovvero uno può modificare lo
 script e ritestarlo senza dover chiudere e riavviare il Mud (attenzione che
 quest'opzione con molti mudscript in futuro rallenterà l'esecuzione del mud
 e quindi è da utilizzare solo quando si builda, debugga o testa)

- C'era un baco che sfalsava leggermente le probabilità di esecuzione di un
 behaviour: se l'entità non riusciva a utilizzare un beahviour di look
 provava comunque ad utilizzare un behaviour di wander e ciò non è voluto

- Implementato il behaviour random:
 Con l'etichetta RandomDo si indica la percentuale di attivazione da 0 a 400
 Con l'etichetta RandomDoCommands si indica uno o più comandi da scegliere
 nel momento in cui il RandomDo scatta.
 Per esempio:
Behaviour:
   RandomDo: 100
   RandomDoCommands: emote prova 1
   RandomDoCommands: emote prova 2
   RandomDoCommands: emote prova 3
End
 il portale in limbo ha questo behaviour e funziona
 C'è da dire che i comandi random vengono eseguiti solo se la categoria dei
 look behaviour e quella dei wander behaviour abbia fallito a scegliere
 casualmente un'azione

- Risolto il baco dei 900 secondi della digestione

- Ho cambiato il check per l'assegnazione casuale del px, ora è così:
       if myrandint(1, 16 + math.log(self.level+1)) == 1:
           self.experience += 1
 ciò avviene ogni secondo per tutti i pg, praticamente sceglie un numero a caso
 tra 1 e 16+il logaritmo dipendente dal livello, se il numero scelto è 1 allora
 incrementa l'esperienza

- Corretto il baco dell'esecuzione del comando aliases (non era nulla che
 inficiasse sul funzionamento in realtà, è un caso particolare di poca degna
 nota)

- Inserito un sistema di embedding dei caratteri runici tra i font del web, il
 sistema per ora purtroppo è misteriosamente funzionante solo sotto internet
 explorer, (oddio l'ho provato solo su IE e sotto FF).
 Lo si può notare in IE quando si clicca sui link e nel menù a sinistra,
 tenendo schiacciato appaiono delle rune che saranno le stesse che verranno
 utilizzate nel futuro sistema di magia del Mud.

- Dovrei aver corretto il sistema delle porte, per lo meno MI PARE che non
 vengano più duplicate. Il sistema è tuttavia una sorta di coperta corta:
 magari funziona una cosa ma non il resto, quindi bisogna controllare se ora
 vengono visualizzati i messaggi di open e close dei reset delle porte, sia
 quelli di default che quelli personalizzati.
 Ho fatto dei test veloci e sembra a posto.. uhm.. sarebbe un bel colpo!

- Visto che non riusciamo a tirarci fuori dai problemi dei riferimenti ho
 inserito un check di forza bruta che ogni secondo si scorre i dati della
 persistenza del database e ne controlla il riferimento che mi aspetto sia
 errato per quella storia del cavatappi, vediamo un po' quando salta fuori.
 Il log che invia è tutto CAPITALIZE ed è qualcosa tipo:
ERRORE DI RIFERIMENTO CONTAINED_BY %s MA %s NON SI TROVA LI' DENTRO
 Per attivare e disattivare questo controllo, che non è certo cpu friendly (ci
 servirà disattivato per la futura release in aarit.it), ho inserito l'opzione
 di config check_references (valore True o False).
 Se sto errore non capita quando digiti i comandi.. allora mi aspetto che
 capiti ad un reset; a questo punto potrebbe servire che i log dei RESET
 vengano scritti su file, così da sapere a che riga il messaggio CAPITALIZE
 sia avvenuto (prima o dopo che reset, tu capisciuto?) per fare ciò ti insegno
 un trucchetto: cerca il file LOG.py e cerca la riga
RESET.write_on_file = False
 in esso, se cambi il False in True tutti i log relativi ai reset verranno
 dirottati anche nel file di log riempiendo allegramente l'HD di giga e giga
 di roba inutile! Evviva!


================================================================================
Rella 63
05/06/2010

- Corretti i problemi di non supporto di alcuni caratteri nella piazzetta, il
 problema dei colori cmq permane e verrà risolto solo nel lungo termine

- Poiché il problema è simile a quello che abbiamo incontrato nella descrizioni
 dei personaggi mi sono messo a debuggare anche quella parte, e difatti mi
 sembra che ora siamo arrivati ad un livello accettabile, ma non sono ancora
 del tutto sicuro che funzioni (ricordi il problema degli accenti nelle
 descrizioni inserite nelle pagine web?)

- Aggiunto il tag $T che funziona come il tag $t, quest'ultimo però inserisce
 anche il colore identificativo del comando [limegreen], cosa non buona per
 l'invio dei comandi del bigino

- Ho fatto la tooltip auto-dimensionante (sostanzialmente giocando con un
 logaritmo sul numero dei caratteri), c'è da vedere come si comporta, mi
 interessa più che altro sulle tooltip visualizzabili dai giocatori, che
 dovrei aver già controllato tutte... ma... non si sa mai

- Aggiunta la tooltip relativa ai behaviour nel look delle entità e nella
 lista delle aree

Sono stati corretti altri bachi come segnato nel google doc di test
NON sono stati corretti i bachi relativi al reset delle porte e relativi al cibo


================================================================================
Rella 62
31/05/2010

- Corretto il problema del crash / 0 creando nuovi pg (testato)

- Corretto il baco del passaggio di livello, a quanto pare cercava di passare
 il livello dopo e quindi non gli bastavano mai i px (testato)

- Dimezzata la probabilità di recuperare 1px al secondo, ora dovrebbe essere un
 tempo più umano, ma forse son stato troppo buono (da ritestare)

- Alle varie aree manca l'etichetta Creator, (non ne ho mai parlato, in realtà
 tutti i dati hanno l'etichetta Creator, ma solo per le aree ora come ora è
 importante), è obbligatoria e all'avvio ti troverai dei messaggi d'errore,
 bisogna inserirvi il nome dell'account dell'autore dell'area (e non il nome
 del pg), in futuro sarà plurale permettendo di inserire più nomi.

- Per il resto andare a leggere il documento della release 61

- Il mana e il vigore non esistono più, al loro posto esiste l'energia, che fa
 sia stanchezza fisica che psicologico-magica (consumo mana), questo sistema è
 stato per bilanciare movimento nei pg piccoli e poco mana per i pg maghi
 all'inizio
 Questo significa che all'avvio del mud ti troverai con dei messaggi d'errore
 relativamente le etichette Vigour MaxVigour Mana e MaxMana, le prime due
 bisogna rimpiazzarle rispettivamente con Energy e MaxEnergy, le altre due
 da sostituire, si trovano tutte nei file dat dei mob della persistenza e dei
 giocatori, non mi pare da nessun'altra parte

- Ho aggiunto la tooltip con i riferimenti, così da poterli tenere sott'occhio,
 per poter debuggare le entità no look list ho fatto in modo di poter farli
 vedere cmq dagli admin, come anche le entità in incognito.
 Bisognerebbe controllare che pg con trust normale non abbiamo modo di
 vedere queste due tipologie di entità.

- Ho effettuato delle modifiche relativamente alle porte resettate migliaia di
 volte, quando le ho scritte ero convinto di aver tappato il problema (non ho
 testato) e poi mi era venuto il grosso dubbio che avessi fatto tutto
per nulla.
 C'è da controllare..


================================================================================
Rella 61
23/05/2010

* Corretto il dannato baco del menù, grazie a ciò si può mettere up questa
 versione anche nella 4000

* Se ti viene dato un errore di label Drunk non trovata nei file dei pg, rimuovi
 pure tutte le etichette Drunk, attenzione a non confonderti con l'etichetta
 Drunkness

- Aggiunto il file data/forbidden_names.list contenente una lista di nomi
 proibiti per la creazione di nuovi account e pg. (testato)

- Editato il documento google relativo alla release 60 con le correzioni
 effettuate e non.

- C'era un errore nel salvataggio del file di configurazione, corretto!

- Piazzetta funzionante, non come vorrei.. non ha l'aggiornamento automatico
 e il caricamento è lento, ma vabbe' per ora ci accontentiamo


================================================================================
Rella 60
21/05/2010

* Ho rimosso l'opzione di config use_proxy perchè mi sembrava ormai inutile.

* Ho aggiunto l'opzione di config server_name.

* Ho aggiunto l'opzione max_square_msg_len che serve a scegliere il limite del
 messaggio postabile nella piazzetta (una specie di chat nel sito)
 Aggiunta anche l'opzione show_square che serve a visualizzare o nascondere
 la piazzetta sul sito

* Alla struttura DoorType ho aggiunto due etichette:
 ResetOpenMessage
 ResetCloseMessage
 viene tutto descritto nel file di documentazione door_type.htm cosa servono.
 Come potrai altresì notare ho cambiato tutte le etichette che iniziano con
 'No' come prefisso, con invece un suffisso 'Difficulty', es.:
 NoPassDoor -> PassDoorDifficulty
 Ho inoltre aggiunto l'etichetta PickLockDifficulty, avevo atteso a
 farlo perché avrei voluto inserire un sistema di oggetto-serratura a parte
 ma poi ho pensato che avrei complicato inutilmente le cose ed ho lasciato
 perdere, utilizzeremo delle flag o altro quando miglioreremo il sistema
 del ladro.
 Troverai inoltre delle precisazioni a livello di tag di act che ti potrebbero
 essere utili (per le etichette dei messaggi di chiusura utilizzavo
 impropriamente il tag $a.. bho fammi sapere se tu l'avevi utilizzato per
 quelle etichette, magari avevo un motivo).
 Nelle note ho anticipato il futuro ipotetico sistema di sincronizzazione
 delle porte. (non ho testato praticamente nulla)

* Ho cambiato il nome degli effects in affects dapperttutto, se vedi che aarit
 ha degli scompensi ormonali causa qualche etichetta Effects cambiala in
 Affects

* Ignora qualsiasi eventuale messaggio d'errore relativamente all'etichetta
 KeywordsName per i file dat dei giocatori

* Questa versione è altresì da uppare anche nella preview, la porta 4000, con il
 config.ini appropriato, questo perchè ne ho cambiato il layout della homepage
 abbastanza da avvertire, finalmente, dell'esistenza del link aarit.it in giro
 Ricordati di impostare l'opzione show_square a False per la preview, poiché
 il codice è ancora instabile

- Ho aggiunto l'act tag $tongue e $TONGUE, per ora solo i thepa hanno una
 "lingua biforcuta"
 Bisogna cambiare la cosa in:
 opekus_mob_thepa-wa-f-strong.dat
 deadcity_room_strada-ew_01.dat
 deadcity_room_strada-ew_02.dat
 quest-accademia_room_003_arco-fluttuante.dat
 ma potrebbero esservene di più visto che ho i file dat leggermente obsoleti
 Ho già modificato comunque le occorrenze nei social e nel codice
 (testato con il social adore)

- Risolto il baco del loop freeze, ora si può effettuare il test sul tempo di
 level-up, ho modificato altresì anche il tempo di acquisizione passiva dei px
 mediamente ogni 15 secondi, mi sono accorto che prima per un baco non era
 mediamente ogni 10 secondi ma ogni 5 secondi.. vediamo un po' così cosa
 succede ora (bisogna ritestare ora in quanto tempo si livella)

- Aggiunti i comandi area, colors e aliases, sono dei semplici link a pagina
 conosciute (testati)

- Ora quando si sta restringando il nome di un pg il nome vecchio viene salvato
 nell'etichetta OldNames così da poter tener traccia di eventuali renaming
 (l'ho testato)

- (15.03.07) Sulfrum: entropy ha il portale addosso
 (15.03.17) Sulfrum: i mob ci entrano anche quando entropy è in incognito
 Dovrei aver corretto il baco di cui sopra (non testato)

- Ora le entità che hanno una struttura door hanno la possibilità di aprirsi
 da sole
 La stessa cosa relativamente ai portali: un'entità portale può entrare in sé
 stessa.
 Ho testato sui portali, e funziona, tuttavia sulle porte NON funziona, questo
 probabilmente perché mentre i portali sono oggetti che si trovano
 effettivamente nella stanza le porte sono oggetti che si trovano nelle uscite
 e quindi il comando non va' a buon fine, bisognerà aspettare il nuovo sistema
 delle porte superfuturo a vedere cosa accadrà.

- Al comando restring è stato aggiunto un check relativamente alla scelta del
 nome nuovo per i pg (prima si poteva inserire un nome uguale a quello di un
 altro pg, no good!) (testato)

- Aggiunto un abbozzo del comando score, il bello del comando è che lo si può
 usare su altri pg o su altri mob se vi si passa il nome dell'entità come
 argomento (niente supporto per gli oggetti, sono troppo differenti dai mob)
 (testato)

- Aggiunto il comando tell, non viene snoopato ne loggato, scanso bachi
 (l'ho testato un po', sembra andare)

- Non ci dovrebbe essere più il crash del up di livello.

- Dovrei aver corretto tutti i bachi relativi al goto descritti nel googledoc.

- Potrei, dico potrei, aver corretto il baco dei personaggi che rimangono nel
 who.

- Aggiunta la possibilità agli admin di mangiare tante entità senza che la
 panza si riempia.


================================================================================
Rella 59
10/05/2010

- Ora che ho corretto il baco crash dell'avanzamento di livello bisogna andare
 nei vari pg che hanno Level differente da 0 e aggiungere l'etichetta
 Practices: per ogni nuovo livello acquisito il valore di livello acquisito * 5

- Ho corretto vari bachi sorti dai tuoi test, tutto documentato nel file:
 https://docs.google.com/Doc?docid=0AYyV7e3ZH3R1ZGhkZnBmN3NfMTE0aHNqa25mZng&hl=en

- Ho spezzato il comando goto in mgoto, igoto e rgoto che vanno alla ricerca
 rispettivamente di player/mob, item e rooms.
 Il vecchio comando goto è stato convertito in un sinonimo di mgoto.

- Rimuovere dai file account *.dat l'opzione OLD_PAGE, ora viene gestita
 automaticamente a seconda del browser utilizzato (IE7 IE8 e opera9 utilizzano
 la vecchia)

- Ora dovrebbe dare un messaggio di errore se per caso uno inserisce una
 struttura Exits/End vuota oppure con la direzione a DIR.NONE

- A tutte le strutture-etichetta relative alle tipologie di entità ho aggiunto
 l'etichetta Comment

- Alleluja ho creato il file di documentazione relativo ai food ed ai drink
 non è linkato da nessuna parte, bisogna aprirlo come se fosse una pagina
 html, il file si chiama food_drink_type.htm
 Non tutto quello che è indicato nel file food_drink è funzionane lato codice
 cmq un giorno sarà così com'è scritto.


================================================================================
Rella 58
03/05/2010

- Nel file di config non ci sono più le opzioni in_memory_log e la sezione
 relativa ai tweaks

- Cambiare tutte le occorrenze di LOG.BOOT in LOG.BOOTING nei file *.dat

- Come ormai avrai leggermente intuito questa release è un grosso rifacimento
 di alcune parti concettuali del codice, si può dire tutto di aarit, ma certo
 il fatto che non dicesse né Aha né Bha quando inserivo le porte prototipo
 nelle uscite invece di quelle per la persistenza ne fa intuire la sua
 elasticità in situazione differenti (diciamo che è un modo per guardare
 positivo alla cosa.. -_-) cmq ho inserito i risultati dei miei test nel
 famoso file:
 https://docs.google.com/Doc?docid=0AYyV7e3ZH3R1ZGhkZnBmN3NfNDA4a3B0dzdkdg&hl=en&pli=1

- Il nuovo sistema di log del mud fa un po' schifino.. mi sa che rimetterò
 quello di prima, però sta release te lo cucchi così, poi dimmi se a te garbe
 o meno tanto per sapé

- Ora come ora le porte sono desincronizzate perchè non ho ancora implementato
 il sistema che avevamo discusso sulle porte autosincronizzate


================================================================================
Rella 57
24/04/210

* Ho convertito l'eticheta Coords relativa ai portali in Destination per essere
 più in linea con Aarit, bisogna quindi eseguire un replace di quest'etichetta
 a tutti i portali nella struttura PortalType

* Un disastro.. mi sono accorto che uppavo come porte delle entità prototipo
 invece di quelle adatte alla persistenza, ho dovuto cambiare mezzo codice del
 database e ancora non ci siamo..
 Niente, per ora bisogna tenercelo così, o mi viene in mente un'ideona è sarà
 almeno un mese speso a riscrivere il database che così com'è ora come ora è
 ingestibile.
 Adesso in pratica il mud funziona (forse) solo al PRIMO riavvio, cioè partendo
 da persistenze pulite bisogna avviarlo una volta, chiuderlo e riavviarlo per
 poterci lavorare, qualsiasi ulteriore riavvio fotte le persistenze e bisogna
 ricominciare il giro.
 E con tutto questo casino dovrei aver corretto il vecchio problema del
 "get porticina" e quello nuovo del crash sull'update:
 exceptions.AttributeError: 'ProtoItem' object has no attribute 'update'
 ahaha.. sai che consolazione -_-

- Un'altro baco che probabilmente ho corretto è questo che inviasti:
   "Se metto 2 istanze della stessa door nella stessa room ma su uscite diverse
   (-1 -1 -2 novizi)
   quando apro una si apre anche l'altra,
   quando chiudo idem"

- Un'altra feature aggiunta con tutto il casino sulle porte è quella di poter
 inserire dei mob nelle porte, non ho idea come questi si comporteranno, con
 o senza struttura DoorType.

- Ho cambiato una cosa che mi dava rogne in tutto il motore di aarit,
 praticamente prima c'erano due variabili che indicavano se un'entità si
 trovava dentro una stanza oppure dentro un'altra entità, queste variabili
 erano mutualmente esclusive ed in alcuni punti del codice dovevo utilizzarne
 una piuttosto che un'altra.
 Ora invece per ricavare colui che contiene un'entità si fa riferimento ad
 un'unica variabile, in questa maniera ho semplificato il codice qui e là
 dando maggiore spazio, soprattutto in futuro, per far funzionare i comandi
 sia dalla stanza che dentro un'altra entità.
 Ho cambiato molte piccole parti del codice, specie relativamente ai comandi
 probabilmente qualcosa è cambiato, sia in meglio che in peggio.
 Uno degli effetti è stato quello che, se uno si trova nell'inventario di
 un'altra entità e fa look, si veda l'inventario altrui e non la stanza che
 contiene tutte e due le entità.
 Questo sistema dovrebbe dare più respiro anche a bachi, probabilmente non
 ancora risolti, del get ballerino che avevi notato con il test sui goto.
 Con queste modifiche bisogna per forza ripulire la persistenza per iniziare
 da zero con i riferimenti.

- Sulla scia della modifica di cui sopra ho centralizzato la gestione dei
 riferimenti in due funzioni modificando i comandi get, give e drop.
 In teoria non dovrebbero aver cambiato comportamento, ed anzi dovrebbero
 funzionare meglio, ma tra dire e il fare c'è di mezzo aarit.
 Ci sono alcune feature di tali comandi che probabilmente non erano state
 testate, per esempio il dare un oggetto del proprio inventario ad un oggetto
 sempre del proprio inventario.

- Inseriti i link della short al posto di tutta la long nel look della stanza

- Modificato il restring per andare a cercare le entità prima nel proprio
 inventario, poi nella propria stanza ed infine in tutto il mud (non l'ho
 testato adeguatamente)

- Aggiunta l'opzione use_proxy, così da attivare o disattivare il codice
 relativo al proxy per ora il proxy rimane in ascolto di fisso sulla porta 80,
 bho bisogna vedere cosa succede secondo me mi manca del codice per gestire
 il passaggio dalla porta 80 alla porta del mud, ma non riesco bene a capire
 il giro ed ho bisogno di un test veloce su eco.ilmale così da avere un paio
 di conferme

- Ho reso cliccabili le tooltip in maniera tale da far visualizzarne il
 contenuto visto che ora come ora non riesco proprio a mostrarle nella
 posizione corretta

- Ovviamente dopo aver speso tempo per la feature sopra ho capito dov'era il
 baco del posizionamento errato delle tooltip e quindi l'ho corretto, e vabbé!

- Ho altresì aggiunto la tooltip di comment per stanze, entità guardate e uscite

- Ecco fatto! Nella pagina show socials, ti ho ordinato i social e pure le
 razze, sia a livello di input che a livello di output dei risultati.

- Ho corretto il problema del comando intuito eseguito sul cofanetto schiuma,
 lo stesso baco c'era anche negli altri comandi sensoriali (ormai dai pure per
 scontato che quando dico comandi sensoriali intento tutti quanti gli altri 5
 sensi escludendo quello della vista che ha un comando tutto suo)

- Corretto il problema della exit/door che ti era capitato dopo che hai fatto
 un goto e la cui correzione ti ho già inviato via mail con i due file DOOR.py
 e EXIT.py

- Dovrei aver corretto il baco della USE_NO_DIR relativamente al comando open
 e close, tuttavia non ho testato adeguatamente

- Ho corretto il comando get in maniera tale che prenda le porte "dell'altra
 stanza" senza duplicazioni

- Dovrei altresì aver corretto il baco del look nelle direzioni con la porta,
 in pratica però non l'ho testato

- Ho spostato alcune opzioni nella sezione SERVER, tra cui la nuova entry
 use_proxy

- Prova a vedere se ora, eseguendo un renaming di un pg, dia errore all'avvio
 e se con quel pg ci si possa connettere, è un test importante che ci serve
 per capire se possiamo usare il restring per rinominare i pg che si mettono
 il nome Berlusconi.

- Dovrei aver corretto l'impossibilità di utilizzare KeywordsShort invece di
 KeywordsShortNight nel comando restring


================================================================================
Rella 56
19/04/2010

- Corretto il crash dell'emote

- Corretto il problema degli alias (action con un solo argomento
faceva crashare)

- Ho potenziato e corretto il restring, non l'ho testato

- Ho potenziato il comando goto in maniera tale che potesse gotare anche su
 codici o nomi interi/prefisso/parziali di stanze, l'ho testato poco

- Corretto il baco del loop freezato nel cambio del mese rpg, è una correzione
 che poi ti avevo passato via chat

- Corretto il problema del click sulle long del comando look, help e simili

- Aggiunta la pagina per gli admin Show Socials che dovrebbe aiutare a debuggare
 meglio i messaggi dei sociali, specie quelli relativi agli Others

- Corretto i comandi sensoriali per un baco che avevano con le extra

- Nella console vedrai printati i secondi dall'avvio del mud, oppure un sacco
 di zeri, vedremo.. servono a capire come mai quel date non funziona

- Rimosse le flag di EXIT.SECRET e EXIT.HIDDEN che avevamo visto l'altra volta;
 aggiunta la flag di uscita EXIT.NO_LOOK_LIST che evita di far vedere l'uscita
 ad occhi altrui ma per il resto non cambia altro.
 Aggiunta la flag per le door DOOR.SECRET nell'etichetta Flags per la struttura
 DoorType. Serve a non far visualizzare un'uscita con la porta solo se questa
 è chiusa.
 In ultimo esisteva già la flag di door DOOR.NO_USE_DIR che evita l'utilizzo
 delle parole chiavi direzionali sulle porte.
 Il mischione di queste flags generano delle uscite/porte più o meno nascoste.
 Tutto implementato molto alla buona, potrebbero esservi dei problemi.

- Ho rifatto il ciclo di loop riguardante i behaviour. In pratica ora prima di
 eseguire i behaviour sceglie un tot di aree casuale, pari a metà di quelle
 attualmente online (per difetto), e ne esegue i behaviour.
 Questo avviene sia per mob che per item in maniera separata.
 Quindi i comportamenti non saranno più a scatti, come avevamo visto con
 percentuali alte di behaviours, ma a moto più ondulatorio, realistico e
 casuale.
 C'è da dire che tutto questo viene fatto ogni secondo reale e non più ogni
 secondo rpg (cioè due secondi reali), quindi in soldoni statisticamente non
 dovrebbe essere cambiato troppo.


================================================================================ 
Rella 55
15/04/2010

* Prima di tutto devo annunciarti che, con tempismo perfetto rispetto al parsing
 da te effettuato per l'area accademia, non esiste più l'etichetta Status ma
 al suo posto ci sono queste due:
Long:
LongNight:
 Per convertire senza troppi problemi la Status in Long basta eseguire un
 replace di
'Status:*'
 in
'Long:*$N '
 Dove * sono un numero imprecisato di spazi e tabulazioni (a te la regex..)
 ed evitando ovviamente le virgolette, le ho inserite per darti un'indicazione
 degli spazi necessari. In questa maniera si ha la stessa situazione attuale
 la cui visualizzazione nella stanza non è altro che un short/name + status,
 proprio come ora funziona la long, inoltre così si ha la possibilità
 d'inserire qualcosa anche prima del $N, esempio:
LongNight: Nel buio $N dormicchia con mezzo $eye aperto
 Sì, in questo caso ci vuole la prima lettera maiuscola, almeno sarebbe meglio.
 Mi pare che questa tua necessità fosse derivata dai 'ciottoli dappertutto'.
 Fa attenzione a non inserire $n al posto di $N altrimenti verrebbe letto il
 nome del pg che guarda, penso
 Come noteria una conseguenza di questa modifica sarà che tutta la long
 visualizzata con il comando look sarà sottolineata con il link, la cosa non
 mi piace e probabilmente la cambierò, cmq fammi sapere cosa ne pensi tu

* Ho cambiato il nome alla label ResetTime in RepopTime, al caso tu l'abbia
 utilizzata

- Cancella il file /log/huh.lst, ne ho ricavato un po' di info e lo resettiamo
 per la prossima apertura

- Sistemato il problema delle maiuscole per nomi di stanza o altre
parti colorate

- Risolto l'invio dei caratteri  +  &  ;  nel canale say

- Ho velocizzato molto la pagina di gioco.. adesso dopo i 10 minuti di gioco
 dovrebbe reggere ancora, a livello di processore, a livello di memoria è
 un'altro conto che non ho ancora monitorato.. Bisognerebbe ps -ux il client
 di browser di volta in volta e vedere se ciuccia notevolmente o solo
 relativamente (di questa modifica ti ho già inviato una patch parziale)

- Aggiunta l'opzione di config max_google_translate che ci servirà in futuro
 per il sistema di translate automatico

- Ho aggiunto un supporto ai link inviati dai giocatori tramite canali offgdr
 ovvero se uno chatta un url di un sito questo viene convertito in link
 cliccabile

- Ho ulteriormente velocizzato tutto il Mud! Quanta fatica... (sapere a che
 servirà poi... mah!)
 Ho creato per l'occasione un'altra sezione di config:
 [TWEAKS]
 In essa vi saranno d'ora in poi delle opzioni da mantenere sempre disattive,
 cioè a False.
 In pratica queste opzioni attiverebbero versioni di funzioni più prestanti
 rispetto a quelle di normale utilizzo.
 Tali funzioni sono relative ai colli di bottiglia di Aarit, per quello sono
 così importanti da migliorare.
 Purtroppo la velocità si paga, le funzioni migliorate mancano di un
 qualsiasi controllo sui valori ed è quindi per ora cosa poco saggia
 l'utilizzarle.
 Ma magari un giorno.. tra 150 anni... quando sarà tutto più stabile....
 (Come se ora crashasse! Manco a pregarlo in Uzbeco!)

- Visto che Jaroddd sta lavorando sugli help ho iniziato il sistema degli help
 caricamento helps *.dat e comando help per ora pare che vadano (sull'unico
 file help che per ora ho)

- Basandomi sul file huh.list ho notato che i giocatori hanno digitato alcuni
 comandi inesistenti ma che per me sono di facile implementazione:
 * Aggiunto il comando esamina, è sfuffo per ora, funziona come il look
 * Aggiunto il sinonimo chatta e simili, a quanto pare viene naturale
   utilizzarlo da alcuni rispetto al chat
 * Ho cambiato il comando italiano per il 'quit' ed ora utilizzo 'esci',
   'fine' invece rimane come sinonimo
 * I comandi esclama e domanda sono dei wrapper al say che aggiungono un
   punto esclamativo o un punto interrogativo nel qual caso non vi sia già

- Dovrei aver risolto il problema del get cavatappi NO_LOOK_LISToso
 in realtà era tutto un altro problema che andava ad intaccare anche il goto
 ora mi aspetto che il goto funzioni un po' meglio, anche se non credo che
 abbia risolto tutto

- Ora evita di aprire e chiudere porte fuori da cardini, i messaggi appositi
 sono orribili, cioè van bene per le porte, ma per entità non esattamente
 porte (cioè un barile che fa da porta per esempio) gettabili il messaggio
 fa un po' cagare.. vedremo che fare...

- Okkei, ho risolto anche il problema del get porta con una porta nel proprio
 inventario

- Ho cambiato le sole direzioni del look da Northeast a NorthEast etc etc
 come da te suggerito, non credevo vi sarebbe stata una differenza tangibile,
 e invece un po' si nota

- Ho corretto il problema dei colori negli aliases, ora dovrebbe essere più
 umana come cosa

- Il problema del Drinking 0% non centra nulla con l'utf8, ricordi
quella caterva
 di etichette abbandonate che erano un prototipo vecchio dei behaviour che
 ormai ho abbandonato?
 Ecco, aarit mentre sta leggendo una stringa multilinea se trovauna linea che
 non inizia per una label conosciuta allora la considera una linea da
aggiungere
 E' entrato in un caso specifico, perchè subito dopo la label Description c'è,
 alfabeticamente, Drinking, e avendo rimosso la variabile relativa non esisteva
 più quindi è entrata a far parte della descrizione!
 Long story short: fai un replace di tutte le linee contenenti Drinking: da
 tutti i file di player

- Ho aggiunto l'opzione allow_player_gaming che evita o permette di far entrare
 giocatori (o account) con trust non adeguata nella pagina di gioco.
 Per la precisione:
 un pg con trust PLAYER potrà giocare solo se il suo account non ha
trust PLAYER
 un account con trust PLAYER potrà giocare solo se la trust del pg non è PLAYER
 E con questo possiamo uppare un'istanza di aarit e puntarla all'80 con il
 proxy che c'è, no?

- Corretto il problema del tastierino numerico indicato da Cello

- Non ho ancora scritto la benedetta documentazione riguardo i FoodType..
 quindi se vuoi testare ora l'eat fallo con oggetto non eatosi.. per quello
 che si può fare e qualcosa hai già fatto


================================================================================
Rella 54
10/04/2010

- Aggiunta l'opzione motto, staff_name, engine_name, engine_version nel file di
 config tutta sfuffa che a te non serve se non a confermare che siamo dei fighi

- Rimossa la voce di config use_behaviours (capirai il perché con la voce sotto)

- Aggiunto il comando loop, questo serve a mettere in pausa tutto il loop, e
 quindi anche i behaviour, oltre che i futuri update di condizione del
 personaggio (fame, sete etc)

- Non spaventarti se troverai diversi messaggi di label non trovate: Sleeping,
 Eating, Cleaning... etc etc
 Erano variabili vecchie inserite per un prototipo di sistema di behaviour
 che ormai non utilizzo più.
 Lasciando andare il booting, chiudendo il Mud, salvando le persistenze e
 riavviandolo non dovrebbero esservi più

- Corretti i problemini del get:
 Sarcoma cerca di prenderti qualcosa, tuttavia si ferma prima di
compiere un furto.
 Un elefante giallo prende @)}--^----  da una frana.
  (da provare)

- Ho aggiunto le uscite delle room in inglese per coloro che utilizzano i
 comandi in inglese

- Corretti i bachi del famigerato get sfera, cmq è testare quando capita
 (da provare)

- Rimosso lo status di chiusa/aperta agli oggetti porta che si trovano per terra

- Risolto un problema nel look direzione: le stanze di destinazione venivano
 viste anche se non c'erano delle uscite comunicanti (praticamente si guardava
 attraverso le mura.. fico.. tipico baco feature!)

- Risolto un altro problema delle porte, quando erano aperte non permettevano
 di vedere al di là ma facevano vedere cmq l'entità porta anche se l'uscita
 veniva guardata con una chiave di direzione

- Implementato la pagina per aggiungere o modificare gli alias, si trova tra
 i link di account

- Implementata la pagina per modificare le descrizioni dei personaggi, si trova
 tra i link di account

- Rifatto il sistema di creazione delle pagine del sito, ora parte del codice
 html si trova nella cartella data/views.
 E' utile saperlo perché in futuro si avrà più o meno la possibilità di
 modificare le pagine html senza andare a toccare codice python.
 Potrebbero esservi problemi nella navigazione al sito viste le modifiche,
 ma fino ad ora non ne ho riscontrati.

- Ho unito le due sezioni del comando who in un'unica così da (provare?) a
 diminuire l'impatto psicologico del: "Io Admin Pisellone, tu
giocatore pisellino!"
 Ora gli admin sono identificati da una graziosa immagine celticosa, il tri...
 il tricera... il triskele!

- Implementato il comando eat, per ulteriori informazioni fai prima a provarlo
 o a guardare il codice che, come di sicuro sai, è sempre molto
 autoesplicativo! (o 'parlante' come diceva un coreano a cui avevo fatto mezzo
 colloquio).
 A parte gli scherzi, se te la senti il file è command_eat.py e dovrei avervi
 inserito abbastanza commenti da farti capire qualcosa, non cercare di capire
 quello che non sai, leggi e fatti un'idea, anche vaga, poi al caso te ne
 parlerò meglio.
 I commenti che iniziano con (TD) sono relativi alle cose da fare (TD = TO DO)
 I commenti che iniziano con (TT) sono relativi alle cose da testare
(TT = TO TEST)

- Inserite le flag di entità (etichetta Flags)
 FLAG.HERBIVORE
 FLAG.CARNIVOROUS
 Penso che siano abbastanza descrittive, e sono flag da inserire principalmente
 ai mob, per indicare quale dieta preferiscono, il resto viene spiegato nella
 alla voce subito sotto

- Aggiunta l'etichetta FoodType, nell'ottica di ristrutturare il manuale di
 building l'ho descritta nella pagina apposita che ti troverai qui:
 http://eco.ilmale.it:25442/doc/builder_manual/food_type.htm

- Aggiunta l'opzione di config digestion_time espressa in secondi reali che
 serve a indicare quanto tempo in secondi reali le entità mangiate rimangono
 nello stomaco prima che scompaiano

- Mi servirebbe il social vomito/puke, per estendere alcune funzionalità del
 comando eat, quando e se hai un attimo di tempo, altrimenti me lo dici che
 provo a buttare giù qualcosa io

- Ricordati sempre che le etichette short iniziano con la minuscola, ogni tanto
 me le trovo con la maiuscola e la relativa sistemazione complicherebbe un po'
 il codice qui e là relativamente alla concatenazione delle stringhe.

- Ehi! Son riuscito a superare uno dei muri del suono di Aarit! Ora andrà ancora
 più veloce! swooosh! swooosh! fhtagn! fhtagn!
 Il top info relativo al processore saliva di circa 0.36%~ ogni 4h, vedremo ora

- Aggiunto l'argomento stop al comando snoop, così da fermare tutti i propri
 snoop in un botto solo

- Cercando di migliorare ulteriormente le prestazioni (è un ginepraio..) ho
 dovuto riscrivere il sistema di gestione dei css, ora i colori inseriti
 come [red] non possono essere scritti [Red] o [RED] non verrebbero
riconosciuti
 difatti fino ad ora ho trovato un giocatore con un colore sballato:
 [Gold]Vilfredo
 Cambialo così non avrai errori durante il caricamento.
 Quando ti troverai nell'output di gioco dei colori con delle maiuscole sappi
 che appunto per quello i colori non verranno convertiti.
 Il sistema dei colori ora potrebbe instabile per le modifiche apportate.


================================================================================ 
Rella 53
02/04/2010

- Messa una pezza al baco del goto, è ancora da indagare

- Ho risolto il problema dell'enter sotto internet explorer

- Forse risolto il problema delle disconnessioni premature

- Ho risolto il problema del get descritto qui:
(15.33.12) Sulfrum: give coccarda vetrinetta
(15.33.19) Sulfrum: get coccarda vetrinetta
(15.33.25) Sulfrum: il get cerca nella room
(15.33.32) Sulfrum: non cerca più nella vetrinetta
tuttavia potrei aver inserito delle fallacità, bisognerebbe testare un po'
meglio il comando get in tutte le sue combinazioni prima di darlo in pasto
ai pg


================================================================================
Rella 52
02/04/2010

- Ho cambiato il contenuto della home e della finestrella a destra
- Ho risolto il problema dell'html esploso! c'è niente da dire..
chrome è un gran furbastro..
- uppa pure sta versione sulle due porte, apriamo in anticipo, cmq io
domani dico che saremo aperti dalle 18 anche se poi in realtà chi
arriva prima meglio alloggia


================================================================================
Rella 51
01/04/2010

- Risolto il problema del goto

- Dovrei aver convertito tutti i file ascii in utf-8 relativamente a tutte le
 cartelle tranne la cartella data, che lascio come al solito a te, almeno per
 ora

- Ho modificato il testo della pagina principale e il testo nella finestrella a
 destra, guarda un po' se ti garba

- Ora dovrebbero esserci meno problemi riguardo al codice esploso scritto come
 output, come chrome non si sono mai problemi, con altri browser sì.. eh


================================================================================
Rella 50
01/04/2010

- Selezione dell'ultimo comando inviato con la nuova interfaccia

- Opzione ultimocomando funzionante con la nuova interfaccia

- link cliccabili di look automatico funzionanti

- Corretto il messaggio che indicava una porta chiusa genericamente "laggiù"

- I mob dovrebbero ora wanderare automaticamente tra le porte chiuse aprendole
 e chiudendole al loro passaggio

- Aggiunto il comando restring

- Cambiare un po' di codifiche, anche ai javascript, mi mancano altri file ma
 ho gli occhi che mi bruciano.. e quando è così non c'è gatto che tenga,
 devo andare a nanna, mra'!

- in questa rella ho cancellato il mio file di config.ini, così che
puoi usare il tuo senza remore, tanto non ho aggiunto nessun nuovo
campo


Non ho convertito nessun file nella cartella data relativo alla
codifica utf-8, te la lascio a te quella, puoi evitare di convertire i
file *.py nella cartella data (penso) se ti è un lavoro rompipalloso
(se è un comando, che comando utilizzi?).

Prima che fai test a vuoto sto convertendo a utf-8 con BOM e non
senza, se non hai capito questa frase è molto probabile che tu stia
convertendo a utf-8 con BOM come me.


================================================================================
Rella 49 (fix della 48)
28/03/2010

- Dovrei aver corretto il problema delle ascii art che iniziano con = o con :

- Ho corretto l'open (che mi ero perso) e il close (che ho aggiunto)
 relativamente al behaviour dei wander

- Ho convertito altri file da ascii a utf-8, se trovi accenti strani devi dirmi
 in che pagina li ha visti e copiarmi il testo cosicché io riesca a recuperare
 il file non allineato e convertirlo


================================================================================
Rella 48
28/03/2010

- Inserite le correzioni che ti ho inviato via chat

- Ho corretto il baco del get di una porta inserita in un'uscita
 (testato)

- Corretto il WanderExit (correzione  già inviata)

- Ho corretto il WanderDirection che non funziona con il DIR.NORD
 (correzione  già inviata)

- Ho corretto un baco relativo al close e open door su direzioni illogiche,
 tuttavia penso che la cosa non funzioni ancora, ci vogliono ulteriori test
 (da testare)

- Ho aggiunto dei check sull'incognito e sul FLAG.NO_LOOK_LIST nel behaviour
 del look (da testare)

- Corretto il baco della sequenza get -> drop -> errore su entità che hanno un
 behaviour wander (da testare)

- Dovrei aver corretto il crash sul comando goto ma non credo di averne corretto
 la logica, se testerai la stessa cosa che avevi fatto (goto su cavatappi su
 shandalar ormai offline) dovrebbe venirti un messaggio del tipo:
 "Per qualche strano motivo bacoso l'entità %s (contenuta o meno) non
si trova in una stanza." % target.get_name(entity))
 Se succede quella cosa non so ancora bene come risolvere la cosa.


================================================================================
Rella 47
27/03/2010

- Dovrei essere riuscito ad evitare di stampare il messaggio remoto, relativo
 all'apertura e chiusura delle porte, alle stanze che non possono più far
 tornare indietro nella direzione originale

- Dovrei aver aggiunto anche dei messaggi descrittivi lo status della porta
 sia per le porte a terra, sia per le porte nelle exit, sia guardando
 specificatamente una porta

- Dovrei aver corretto la scritta errata riguardo le direzioni in alto e in
 basso, era:
 cerca di aprire un  pietrone a Alto

- C'era una doppia implementazione della logica del wander_closed_door,
 funzionava sia indipendentemente da wander_exit sia dipendentemente
 ora funziona solo indipendentemente, come wander_exit insomma
 Inoltre wander_exit ora funziona solo sulle uscite aperte (cioè uscite senza
 porta e uscite con porte aperte) e non anche sulle porte chiuse, c'è mutua
 esclusività quindi

- Mancava totalmente l'implementazione del look_closed_door.
 Anche qui, come per il wander_exit, il look_exit ora funziona solo sulle
 uscite aperte

- Ho migliorato ulteriormente la velocità del mud, urge nuovo profiler


================================================================================
Rella 46
20/03/2010

- Aggiunta l'opzione use_profiler nella sezione DEVELOPMENT in config.ini
 ti servirà per attivare o disattivare il profiler come vuoi tu,
 parapunzipunzipu.

- Ho corretto il link Admin, mi pare di non averti inviato il fix via mail,
 quindi te lo rimembro qui.
 Stessa cosa riguardo quel baco del quit.

- Allora... fammi fare mente locale di quello che ho implementato per le door
 che non ricordo neppure io
 ...
 Niente! non me lo ricordo.. dovremmo riscoprirlo poco a poco.
 Innanzi tutto per inserire una door bisogna aggiungere l'entitype apposito nel
 file di prototipo dell'oggetto, quello che ho utilizzato io è:
DoorType:
   Flags: DOOR.CLOSED
End
 Che come test base può andare.
 Grazie a questo potrai poi utilizzare l'oggetto inserendolo nella Exit di
 una room di prototipo, esempio:
Exit
   Direction: DIR.NORTH
   Description: finchè la barca va'...
   Door: codice_dell_oggetto_porta_di_
cui_sopra
End
 In questa maniera si potrà aprire e chiudere una porta in-game.
 Come noterai dopo un po' di smangruppamenti il sistema è abbastanza limitato
 perché si basa tutto sui prototipi e non sui reset, quindi se si vuole usare
 la stessa porta aperta e chiusa bisogna duplicarne il prototipo...
 How dommage! Ma per ora è così, tira innanzi finché puoi...
 Inoltre ho implementato ulteriori messaggi di open e close, questa volta
 relativamente agli della porta che il resto della gente dall'altra parte
 della porta vede, e questo non è solo relativamente ad apertura ma anche a
 tentativi di apertura comunque non riusciti (se è chiusa a chiave dall'altra
 parte uno se ne accorge, come se si stesse muovendo la maniglia)
 Le etichetta per gestire questi nuovi messaggi di open e close sono:
DestinationOpenMessage:
DestinationCloseMessage:
 Funzionano tali quali alle etichette others_open_message e
others_close_message
 ma si intendono che sono dei messaggi per "l'altra parte" della
porta, e quindi
 $n verrà letto come "Qualcuno"

- Ho altresì migliorato una parte del codice che faceva da collo di bottiglia
 mi attendo dei profiler interessanti, per fare un test accurato bisognerà
 mettere in piedi le due versione, questa e quella precedente, farle partire
 con gli stessi data ed allo stesso tempo e (possibilmente) con le stesse
 config.ini così da avere un check scientifico della differenza tra le due
 relle ed il guadagno effettivo.

- Ho inserito un'implementazione sperimentale del comando intuition, potrebbe
 non funzionare, agli effetti del funzionamento corretto non dovrebbero notarsi
 differenze dal precedente comunque.

- Esteso il comando coords inserendovi anche la short name di ogni stanza

- Bisognerà testare anche il behaviour wander_closed_door ora che le porte ci
 sono

- Non so se te l'abbia mai detto, ma fai attenzione quando viene salvato il
 database allo shutdown, se aarit crasha a metà potrebbe corrompere il dato
 che stava scrivendo (scrivendolo solo per metà)
 In futuro irribusterò il sistema ma per ora, attenzione! Zamp! Zamp!

- Ho corretto il baco del look_at_entitypes, c'è da vedere se dopo questa
 modifica il look_at_races funzioni ancora

- Niente da fare per il baco del maze, speravo fosse solo un problema di
 coordinate (lo 0x0 per me è in basso a sinistra mentre per il creatore del
 javascript è in alto a sinistra) e invece a quanto pare c'è un altro problema
 probabilmente un mio errore di conversione da javascript a python, devo
 riguardare tutto lo script da capo.
 Quindi per ora ti becchi il maze così com'è (che è cmq differente
 dall'ultimo che hai ricevuto a volet ho avuto dei buoni risultati, altre
 volte errori su errori)

attento che ho smangruppato sui data, per esempio sulle forchette per
dei test personali


================================================================================
Rella 45
13/03/2010

- Ora il print_entity_inputs esegue solo il print a console dei comandi e non
 la scrittura su file, questo solo per le entità, gli input dei giocatori
 vengono sempre scritti su file

- Corretto il baco che salvava cmq il log in memoria anche se c'era opzione
 per disattivarlo attiva

- Ho modificato il config.ini: aggiunta una nuova sezione [LOG]
 e spostate le due opzioni relative all'smtp nella sezione [MAIL]

- Plego conveltile tutte le flag INERITH_AREA in INHERIT_AREA per avele aalit
 con l'inglese scollengiuto, plego

- Corretto il baco relativo al look_self del coso peloso (NON TESTATO)

- Doppio baco per il LookAtRaces, quello del non funzionamento non ho l'esatta
 idea di cosa fosse ma dovrei aver risolto, inoltre mi dimenticai di farlo
 funzionare anche sui player oltre che sui mob  (NON TESTATO)

- Ho creato una cosa che ti piacerà e cambierà completamente la visione di
 aarit (come sono altisonante.. come se avessi fatto chissà che cosa..)
 Quando ti colleghi al sito clicca al link del menù di sinistra Admin e
 scoprirai l'arcano.
 PeVò a me il tanto tanto Vosa piaceva..

- Ho cambiato un po' lo stile delle pagine html, integrando quello che mi sono
 inventato per la pagina di welcome

- Corretto il baco relativo al salvataggio della struttura-etichetta behaviour
 per i personaggi. A riguardo la prima volta che avvierai il mud ti troverai
 una spatafiata più o meno infinita di errori. Lascia fare, che si fixxa
 (ogni riferimento a esserini fastidiosi è puramente casuale) tutto da solo.
 Per esserne sicuro comunque puoi, dopo aver atteso tutto il boot del mud,
 chiuderlo, attendere il salvataggio e rebootarlo, non dovrebbero esservi
 più quegli errori.

- Corretto il baco della creazione di un nuovo personaggio dopo aver giocato
 con un'altro, ora quittando con l'altro si può ricrearne uno nuovo.

- In questa release c'è ancora attivo il sistema di profiling, me ne servirebbe
 difatti uno fresco fresco relativo a questa rella, quindi avvia il mud con
 il profiler attivo e quando l'avrai shutdownato inviami il file relativo
 (profiler.results mi pare) cerca di darmi un file profiler relativo ad una
 sessione di aarit lunga almeno un pomeriggio e che non abbia avuto bachi
 di freeze del loop o che.
 Ogni volta che ti darò una nuova rella dovrai fare così come ti sto dicendo
 una volta acquisito un profiler decente puoi disattivare il profiling
 switchando il commento nelle righe di codice che conosci, vicino al reattore.
 Ricordatelo! Perché questo messaggio si autodistruggerà tra
4294967295 secondi.


================================================================================
Rella 44
06/03/2010

- Corretti tutti i punti della mail che mi avevi inviato relativa alla rella 43
 Dovrebbe essere anche a posto il problema relativo agli item gettati
 (che forse è il baco che aumentava la % di processore piano piano)

- Mi sono accorto di una cosa !!!
 Mettiamo caso che tu abbia creato un mob che segue le regole behaviour
 relative ad un'area, questo mob le seguirà solo fino a quando si troverà
 in quell'area (in cui è nato-resettato) ma appena cambierà un area tramite
 portale o wandering seguirà le regole di behaviour relative a quell'area.
 E' un baco interessante, perchè nonostante non sia voluto si potrebbe volerlo.
 Al che ho modificato un po' le cose, impostando alla sottoetichetta
 Flags:
 per le etichette
 Behaviour: / BehaviourMob: / BehaviourItem:
 l'elemento
 BEHAVIOUR.INERITH_AREA
 il comportamente cambierà a seconda dell'area in cui ci si trova, mentre
 invece normalmente utilizzerebbe quello dell'are di origine.
 La questione è un po' più complessa di così, dipende difatti dove inserisci
 la flags impostata così.. ma per quello che ti serve ti basta sapere questo
 mi pare.
 (NON TESTATO)

- Modificato il sistema di behaviour per l'etichette:
LookAtRaces:
LookAtRacesFlags:
LookAtEntitypes:
LookAtEntitypesFlags:
WanderAtDirs:
WanderAtDirsFlags:
Le prime due funzionano cercano la razza solo sui mob.
Le seconde due funzionano cercano la tipologia solo sugli oggetti.
Per ora è così, poi vedremo se c'è bisogno di allargare il concept.
Per tutte quante è stato modificato il sistema, nel senso che ora non sono più
dipendenti da altre percentuali ma funzionano separatamente dal resto (come da
richiesta e relativa discussione passata) (NON TESTATO)

- Potrebbero esservi degli errori di lettura e scrittura sui file dat dei
 giocatori poiché io erroneamente scrivo i behaviour anche ai giocatori
 ignora la cosa per ora


Come vedi anche questa release è behaviour oriented, il sistema mi
sembra così buono che ci sto puntando in continuazione, comunque nella
prossima versione ci dovrebbe essere qualcosa relativamente alle
porte, spero.


================================================================================
Rella 43
28/02/2010

- Ho disattivato alcuni log relativi a uscite che non portano a nulla quando
 delle entità non giocatrici si muovono o guardano codeste uscite, in questa
 maniera c'è meno log-spam.

- Bisogna fare un replace di tutte le strutture di etichetta
Door:
Portal:
Container:
 in
DoorType:
PortalType:
ContainerType:

Attento che ci sono etichette 'Door:' dentro le etichette 'Exit:' che non
centrano nulla con le etichette sopra, ma non penso che tu abbia inserito degli
oggetti porta nelle uscite, quindi il problema del replace all non dovrebbe
porsi

- Corretto il baco del look.. sempre che esistesse, bho!
 Insomma a me con questa versione va'

- Aggiunto il comando coords, ne avevo proprio bisogno, stavo sclerando...

- Ho aggiunto l'opzione di config use_behaviours True/False, come da te
 suggeritomi

- Aggiunte le etichette di area MobBehaviour e ItemBehaviour, in pratica sono
 delle strutture uguali all'etichetta Behaviour per le entità.
 Queste servono a dare delle regole generali a tutte le entità dell'area,
 anche se queste non sono state inserite nel file *.dat
 In pratica se hai impostato i behaviour nel file dat delle entità utilizza
 quello, altrimenti quello dell'area, se impostato.
 Non esiste più il comportamento generico per tutti i mob che non hanno
 impostata l'etichetta behaviour (né file dat dell'entità, né quello
 dell'area), in quest'ultimo caso l'entità non fa nulla.

- Cambiare le etichette
LookAtRaces:
LookAtEntitypes:
WanderAtDirs:
in
LookAtRacesFlags:
LookAtEntitypesFlags:
WanderAtDirsFlags:
e funzioneranno come ora (RACE, DIR, e ENTITYPE).
Mentre le etichette
LookAtRaces
LookAtEntitypes
WanderAtDirs
indicheranno il valore in percentuale, per ora queste ultime tre non sono state
ancora implementate.

- Aggiunta l'opzione di config che permette di visualizzare i comandi inviati
 dalle entità, l'opzione si chiama
 print_entity_inputs
 ed ha valori True o False


================================================================================
Rella 42
20/02/2010

- Ho risolto il bug della direzione errata che avevamo notato, cioè se uno
 arrivava da est veniva letto che arrivava da ovest (testato)

- Ho implementato i messaggi di reset.
 L'etichetta è Messages, utilizzata in questo modo:
RoomReset:
   ...
   Messages: messaggio 1
   Messages: messaggio 2
   Messages: messaggio 3
End

EntityReset
   ...
   Messages: *messaggio 1
   Messages: messaggio 2
   Messages: *messaggio 3
End

 Il messaggio inviato viene pescato casualmente tra quelli definiti.
 Per la room reset invia una echo a tutte le entità contenute.

 Per le entity reset ci sono due tipologie di messaggi, quelli che iniziano con
 asterisco e quelli senza.

 Quelli con * vengono inviati una sola volta quando il reset scatta anche se le
 entità da resettare sono più d'una.

 Quelli senza asterisco vengono inviati una volta per ogni entità che viene
 resettata (etichetta Quantity meno eventuali entità resettate, dipende dalla
 tipologia di reset).
 Se durante l'invio del messaggio senza asterisco, cioè per ogni singola entità
 viene pescato casualmente un messaggio con l'asterisco, allora evita di
 inviare il messaggio.
 Stesse considerazioni, ma al contrario, anche per l'invio del messaggio
 una tantum.
 Per gli entity reset inviati senza asterisco $N indica l'entità resettata
 mentre $n il suo contenitore (room o entità chessia)

- Il ricaricamento del mud ti darà errori nell'inesistenza delle etichette
 beahviour nei file dat relativi ai giocatori in cui venivano erroneamente
 salvate, tuttavia oltre a loro ci sono anche altre etichette behaviour che
 non esistono più e/o che hanno cambiato nome tra i file dat dei mob e degli
 item

- Ho modificato il sistema dei behaviour, ti spiego meglio come funzionano:
 in pratica ogni entità ad ogni secondo rpg ha la possibilità di eseguire
 un'azione, quest'azione viene pescata da una lista con priorità prestabilita
 per tutti.
 Nella versione precedente l'ordine delle azioni era move, look; mentre in
 questa l'ordine delle azioni è look, move, hearing, smell, touch, taste,
 sixth.
 Il sistema funziona così: prima ancora di controllare la percentuale di look
 esegue un "lancio di dado" con tante facce quante è il numero delle azioni
 meno 1, se esce 1 da questo lancio allora esegue quell'azione e salta le
 successive; altrimenti esce e prova l'azione successiva (nel nostro caso è
 il move) e riesegue il lancio di dado, esce fuori l'1 e quindi esegue il check
 relativamente al move (muoversi alla direzione, al portale o al contenitore)
 eccetera eccetera eccetera...
 Le azioni aggiuntive relative ai sensi funzionano tali quali al look, ho
 preferito spostare il look come priorità più alta perchè la ritengo un'azione
 più normale rispetto ad un move, tuttavia forse per gli oggetti ne cambierò
 l'ordine visto che per loro il look è più strano rispetto ad un move.
<IMPLEMENTAZIONE ACT SENSORIALI CHE NON HO ANCORA FATTO MA CHE
FUNZIONERANNO CON IL LOOK>
 Ho modificato i valori di default dei comportamenti dei mob, se ricordi
 guardavano tutti, ora il comportamento è questo:

       self.look_player            = 1
       self.look_mob               = 1
       self.look_item              = 1
       self.look_self              = 1
       self.look_at_races          = Flags(RACE.NONE)
       self.look_at_entitypes      = Flags(ENTITYPE.NONE)
       self.look_direction         = 1
       self.look_exit              = 0
       self.look_wall              = 0
       self.look_closed_door       = 0
       self.look_extra             = 1
       self.wander_direction       = 1
       self.wander_exit            = 0
       self.wander_wall            = 0
       self.wander_closed_door     = 0
       self.wander_area            = 0
       self.wander_at_dirs         = Flags(DIR.NONE)
       self.wander_portal          = 0
       self.wander_enter_container = 0
       self.wander_exit_container  = 0
       self.wander_self            = 0

 Altre modifica è relativa alla scelta casuale della direzione, prima sceglieva
 tra tutte e 10 le direzioni anche se non ne esisteva l'uscita, ora invece
 quasi sempre tra le direzioni conosciute cosicché la percentuale d'utilizzo
 del movimento aumenta e diventa reale rispetto a quella impostata.
Rielenco le etichette e le descrivo:
LookPlayer           # Percentuale di look sui pg
LookMob              # Percentuale di look sui mob
LookItem             # Percentuale di look sugli oggetti
LookAtRaces          # Flags con le tipologie di razze che guarderà
relativamente alle percentuali sopra
LookAtEntitypes      # Flags con le tipologie di entitypes che
guarderà relativamente alle percentuali sopra
LookSelf             # Percentuale di look su sé stessi, entità vanitose!
LookDirection        # Percentuale di look su una qualsiasi direzione
LookExit             # Percentuale di look sulle uscite reali e aperte
LookWall             # Guarda i muri esistenti
LookClosedDoor       # Percentuale di look sulle porte chiuse (non
funzionante visto che non si possono ancora resettare le porte)
LookExtra            # Percentuale di look sulle extra di uno dei look
di cui sopra
WanderDirection      # Percentuale di movimento in una direzione
qualsiasi (uscita esistente o meno)
WanderExit           # Percentuale di movimento in un'uscita reale
WanderWall           # Percentuale di movimento tra mura esistenti
WanderClosedDoor     # Percentuale di movimento tra le porte apribili
dal mob (se ha una chiave valida nell'inventario anche tra quelle
chiuse) (non funzionante per i motivi del LookClosedDoor)
WanderAtDirs         # Flags con le direzioni in cui andrà muovendosi
con le percentuali sopra
WanderArea           # Percentuale di movimento tra aree
WanderPortal         # Percentuale di movimento nei portali
WanderEnterContainer # Percentuale di movimento di entrata nei contenitori
WanderExitContainer  # Percentuale di movimento di uscita dai contenitori
WanderSelf           # Percentuale di enter/exit su sé stessi se si è
un portale o un contenitore (non molto utile visto che per ora c'è un
blocco sull'enter self dei portali)

- Riguardo a quella cosa per cui mi hai aiutato, entra in baso profilo
(casini) niente messaggi a riguardo, un giorno ne riparleremo a 4
occhi che è una cosa complessa, avevi fatto quella cosa da un posto
pubblico? Si/No. Scusa se ho scritto poca documentazione a riguardo ma
non sono riuscito ad implementarla neppure in tempo. Non penso accadrà
nulla, però ora come ora le possibilità ci sono.

- Ho corretto il baco del get di entità che hai nell'inventario e non vi sono
 più nella stanza

- Non dovrebbe esserci più il baco del wandering degli item come ti ho detto
 nella mail, ma sono possibili altri bachi nel nuovo sistema di behaviour,
 statte accuorto bro!


================================================================================
Rella 41
07/02/2010

- Ora guardando un oggetto di tipo porta (o contenitore) si vedrà se è questo
 è chiuso o meno

- Inserito il comando shut/richiudere per chiudere i soli i contenitori

- Ho modificato i comando get, drop, look riguardo ai messaggi visti da altri.

- Oggi ho chiesto ad aarit se avesse qualche flag di tipo STAY_IN_AREA, WANDERER
 e cose così per emulare il movimento dei mob.
 Lui se l'è presa per la mia bassa capacità immaginativa del suo "Sistema
 P0ww4!"(c) che conosce solo lui (andiamo bene, siamo in una botte di ferro!)
 e per un po' non mi ha detto rivolto la parola, poi alla fin fine tra un avvio
 ed un'altro si è allargato e mi ha fatto vedere cosa bolliva in pentola:
 Etichetta Behaviour per entità item e mob (ma non per i giocatori), è una
 struttura con altre sottoetichette:
Behaviour:
   LookPlayer: 20
   LookMob: 20
   LookItem: 20
   LookExtra: 5
   LookExit: 10
   Wander: 0
   WanderExitArea: 0
   WanderAtDir: DIR.NONE
   WanderAtPercent: 0
   WanderPortal: 0
   WanderEnterContainer: 0
   WanderExitContainer: 0
End

Spiegazione di ognuna delle etichette:
LookPlayer:Percentuale di looking su entità personaggio
LookMob:   Percentuale di looking su entità mob
LookItem:  Percentuale di looking su entità item
LookExtra: Percentuale di look sulle extra invece che sulla descr nel qual caso
          che di uno dei look di cui sopra vada a buon fine
LookExit:  Percentuale di look sulle direzioni

Wander:          Percentuale di movimento in una direzione casuale
WanderExitArea:  Percentuale di movimento tra aree nel qual caso l'etichetta
                Wander sia andata a buon fine e si stia andando in una nuova
                area
WanderAtDir:     Direzione in cui andrà con più probabilità nel qual caso
                il check su Wander sia andato a buon fine
WanderAtPercent: Percentuale di movimento in una determinata direzione
                questa etichetta deve essere in coppia con WanderAtDir
WanderPortal:    Percentuale di movimento nei portali
WanderEnterContainer: Percentuale di movimento di entrata nei contenitori
                     Poiché i contenitori sono ancora indietro questa etichetta
                     e quella dopo per ora rimane non del tutto funzionante
WanderExitContainer:  Opposta a WanderEnterContainer.
       L'etichetta WanderExitContainer non funziona perchè non esiste ancora
       il comando di exit per uscire da contenitori o da inventari altrui,
       cmq può essere impostata per il futuro, in teoria di solito la si
       imposta con il valore di WanderEnterContainer per avere un movimento
       entra/esci equilibrato.
       Ovviamente appena il comando exit esisterà ci sarà il comportamento.

I valori da dare alle etichette sono tutti da 0 a 300 tranne per l'etichetta
WanderAtDir che abbisogna di un elemento DIR (quello usato per le exit).
Il limite di 300 potrei anche alzarlo.. sembra già tanto ma.. uhm

Valori a zero significa disattivare quel comportamento, altri valori sono
la probabilità che quel comportamento avvenga, per esempio un valore 1 farà
scattare l'azione una volta su 300, mentre un valore 300 la farà scattare
sempre.
Mi pare che i valori sensati siano tra il 10 e il 20 circa..
Bho, è un sistema ancora tutto da provare!

Oltre al controllo sulla percentuale 1/300 c'è a priori un check sulla
probabilità che un'azione simile avvenga piuttosto che un'altra, per esempio:
   LookPlayer: 100
   LookMob: 30
   LookItem: 0
   LookExit: 10
La somma di questi valori viene convertita proporzionalmente in valori
percentuali, quindi LookPlayer ha la probabilità di uscita di più del 50%
rispetto agli altri due (difatti LookItem non si attiverà mai).
L'altro gruppetto di comportamenti similari è:
   Wander
   WanderPortal
   WanderEnterContainer
   WanderExitContainer
Mentre le altre etichette sono delle particolarità legate ad una o più etichette
del proprio gruppetto.
Ci sono poi altri check che aumentano l'aletoreità dell'esecuzione delle azioni,
te ne accorgerai appena proverai un po' i valori dandoti l'impressione che vi
sia un baco.
Che è possibilissimo...
Cmq ti parlerò meglio del resto del giro del fumo appena digerisci tutto questo.

I valori che ho inserito nell'etichette nell'esempio copia e incolla per le aree
sono quelli di default per i mob, per gli item invece è tutto a zero.

Se scopri che il calendario non si aggiorna più significa che una parte relativa
al codice loop di update del comportamento delle entità è crashata.

Esempi di utilizzo reali:
Un mob con valori di look alti sarà l'impressione di fare la guardia a qualcosa
o di essere nevrotico e guardarsi sempre attorno..
Un mob con valori di wandering alti darà l'impressione di cercare qualcosa, o
di avere la moglie che sta partorendo..
Scoiattolini del futuro boscetto micetto con wanderEnterContainer che entrano
per smangiucchiare le crocchette, mra'! mra'!
Un elefante con solo WanderPortal impostata passerà tra un portale ed
un'altro di due stanze a far guardia ai suoi preziosissimi modem.

Tutti questi esempi sono relativi a dei mob, ma la stessa cosa si possono fare
agli oggetti, immaginati un modem giallo cosa non farebbe...

L'ultimo test che ho fatto è stato quello di far entrare vari oggetti in un
portale è stato divertentissimo vederli sparire, e c'era pure il portale che
cercava di entrare in se stesso :P

Comunque fa conto che in futuro ci saranno sempre più tot di behaviour per ogni
comando e altro ancora.
Ovviamente dovrai impararteli tutti a memoria.
Insomma, ci sarà da divertirsi! zamp! zamp!

- ... Ma perchè mi è impossibile copiare e incollare testo nei google wave??
 Vabbe' te lo sorbisci con sta mail, tiè:
 Nell'ottica di fare, prima o poi (molto più poi che prima) una rella del
 codice Aarit (la release candidate ora sarebbe quella di gennaio utilizzata
 per l'apertura) sto pensando cosa inserire nella cartella data e penso che
 un'area utile (o forse l'unica) a ciò sia quella su cui fai tutti i test:
 mfdonald.
 Secondo te la mfdonald di quella rella andava bene da dare al pubblico?
 Se mi dici di no utilizzerò un surrogato di limbo.
 Non so se poi in quest'ottica tu voglia modificare qualcosa nell'area futura
 per eventuali relle future.

 
================================================================================
Rella 40
31/01/2010

- Implementato il comando disclose, che funziona come un open ma solo sui
 contenitori, al comando open però rimane la doppia funzione di open + open
 come avevo descritto, poi decideremo cosa fare a seconda di come ci troviamo
 o come si trovano i giocatori, mi sa che sarà un test sul ungo periodo..

- C'era un grosso baco nel replace dei tag act $O, $GLI e $LE, prendeva il sex
 dell'entità $n invece di quella $N, strano che non ce ne fossimo ancora
 accorti.

- Aggiunti i tag di act $c, $C, $w e $W
 $c nome della stanza o del contenitore in cui l'entità $n si trova
 $C nome della stanza o del contenitore in cui l'entità $N si trova
 $w nome della stanza o del contenitore in cui l'entità $n si trovava l'ultima
    volta (di solito da comando di movimento)
 $W nome della stanza o del contenitore in cui l'entità $N si trovava l'ultima
    volta (di solito da comando di movimento)
 la lettera c/C del tag sta per 'contained by'
 la lettera w/W del tag star 'was contained by'
 Esempio:
 $N arriva da $W mentre $n gli dà un calcio.
 Carletto arriva da una pozza insanguinata mentre Luigino gli dà un calcio

- Modificati i tag $t e $T ora sono diventati i tag $a e $A che sta per
 auxiliary argument e che può avere un differente significato act per act
 come ho già descritto mi pare per portali e porte.
 Mi pare che tu abbia utilizzato dei tag $t e $T nei messaggi portalosi, è
 meglio sostituirli con i tag precedentemente descritti ($c, $C, $w e $W).

- Invece i tag $t e $T sono diventati i tag di translate di un comando.
 Esempio d'utilizzo:
 Non devi usare il comando $Tlook ma il comando $tlook!
 Se il giocatore che leggerà questo messaggio possiede i comandi in italiano
 leggerà:
 Non devi usare il comando look ma il comando guarda!
 Quindi $t con il comando in inglese appiccicato ritorna il comando nella
 lingua del giocatore.
 Mentre $T, sempre con il comando in inglese appiccicato, ritorna il comando
 opposto alla lingua del giocatore.
 C'è da notare una chiccha, se uno vuole che il comando venga scritto con
 le lettere maiuscole obbligatoriamente bisogna scrivere così:
 $tLOOK
 Se uno vuole che solo la prima lettera sia maiuscola forzatamente:
 $tLook
 Non esiste, perchè abbastanza inutile, $tlOOK.
 Quando uno utilizza $look la prima lettera maiuscola viene modificata a
 seconda della punteggiatura precedente al comando, se questa è esistente.
 Il comando tradotto viene colorato con il colore di default che identifica
 appunti i comandi, non è possibile inserire dei colori all'interno del tag
 di act.
 So che farai buon utilizzo di tutto ciò nell'area dei niubbi.

- Implementati anche i tag di act $hand, $hands, $foot e $foots, funzionano
 come c'eravamo detti e come te lo aspetti, ho modificato già i riferimenti
 nei social e mi sono accorto che è utile utilizzare comunque questi tag
 anche quando è pacifico che la razza abbia la mano, cosicché se in futuro
 cambiamo idea e, per esempio, per i drow facciamo leggere 'mano violacea'
 al poosto di 'mano' cambiamo tutto on the fly.
 Le stringhe razziali per questi tag si trovano nel file src/enums/RACE.py.
 Ovviamente ci sono i rispettivi $HAND, $HANDS, $FOOT E $FOOTS quando si
 fa riferimento alle parti del corpo di $N
 Ho già eseguito una controllata ai social, le aree a te!
 Ho notato che cmq vi saranno discrepanze di articolo, ovvero:
 un $foot -> un piede/un zoccolo
 eh... devo ragionarci su, ma per ora teniamo così.

- Non ho implementato il $season+1... te lo scordi! :D
 Che già con tutto quello che ho inserito mi sa che la act inizierà a
 pesucchiare un po' a livello di prestazioni...
Rella 39b (Fix della 39)
23/01/2010

Come installarla: questa release contiene solo le cartelle con le
modifiche, e non tutto, shutdowna il mud, scompatta e copia
sovrascrivendo i files in aarit di test.

- Corretti dei typo nei social

- Corretti i comandi sensoriali

- Corretto un baco sul look degli oggetti (facevano riferimento al vecchio
 attributo type invece che all'used_as)

- Correzione di tutto il sistema delle door


================================================================================
Rella 39
23/010/2010

- All'avvio del Mud avrai una pletora di errori riguardanti l'etichetta Type.
 Per correggerli prima di tutto rimuovi la persistenza, poi devi convertire
 tutte le etichette Type: con valore ENTITYPE.NONE (penso che ve ne siano
 solo con il .NONE) e con spazio e/o tabulazione variabile tra l'etichetta e
 il valore. Al suo posto devi scrivere:
UsedAs: ENTITYPE.NONE
 So che ti divertirai con i tuoi comandini arabi... (TESTATO)

- Risolto finalmente il problema della macro key, ora si può navigare
 tranquillamente (CON il blok num attivo, da ricordarsi se c'è bisogno di
 dirlo ai giocatori). (TESTATO)

- Ho aggiunto un'opzione di account che permette di scegliere se visualizzare
 il comando inviato nel field apposito, oppure no.
 Quando implementerò la nuova pagina di gioco disattiverò questa feature nella
 vecchia, poiché dava problemi con lo scrolling che non andava, e la inserirò
 nella nuova. (TESTATO)

- Ho aggiunto un'opzione di account che permette di navigare nella vecchia
 pagina al posto di quella nuova; ora come ora visto che non ho ancora
 provato ad implementare quella nuova bisogna connettersi clickando per forza
 su questa opzione. (TESTATO)

- Ho corretto il problema che faceva crashare la pagina delle connessioni, a
 quanto pare c'era una connessione senza l'user-agent, strano...
 Vi ho inserito un log [Conn] se dovesse ricapitare (NON TESTATO perché
 non mi è mai riaccaduto, usandolo in locale direi che è ovvio)

- Aggiunta la tipologia di RESET.ADD. E cosa fa questo reset tu ti chiederai?
 Esso esegue quello che ora fa il RESET.PUT, ovvero aggiunge senza controllare
 se la Quantity impostata sia già esistente nella room (o nell'entità) in cui
 si resetta.
 Di contro il RESET.PUT ora resetta ma senza sforare la quantità impostata.
 Se si resettano 10 coccarde come Quantity, e ce ne sono già 6, ne aggiungerà
 solo 4.
 Insomma funziona come un repop, attenzione però che non deve sostituire il
 sistema di repop, poiché quest'ultimo devo ancora implementarlo!
 Comunque ho modificato in maniera più o meno ampia il sistema centrale di
 resetting, se ci fossero problemi non ci sarebbe da stupirsi...
 (NON TESTATO)

- La Door questa sconosciuta, che tra poco conoscerai, ecco le etichette:
Flags:   Per la lista delle flags... arrangiati! :D
        Apri il file src/enums/DOOR.py e leggitelo.
        Insomma per una porta chiusa devi scrivere una cosa tipo:
        Flags: DOOR.CLOSED
        Altrimenti di default una porta resettata è una porta aperta
KeyCode: Codice identitificativo dell'entità che può essere utilizzata per
        aprire questa porta.
Bolt:    Codice relativo all'entità che fa da catenaccio (o spranga) alla porta

Ecco le altre etichette messaggio-like, funzionano come quelle del portale,
compreso il no_send, a parte il tag act $T che per ora non è impostato, ma sarà
la stanza di destinazione relativa all'uscita della porta (se serve la
implementerò su richiesta):
EntityOpenMessage:  Messaggio d'apertura stile act all'entità che apre
TargetOpenMessage:  Messaggio d'apertura stile act all'entità door
OthersOpenMessage:  Messaggio d'apertura stile act a tutti gli altri
EntityCloseMessage: Messaggio di chiusura stile act all'entità che apre
TargetCloseMessage: Messaggio di chiusura stile act all'entità door
OthersCloseMessage: Messaggio di chiusura stile act a tutti gli altri

Per presa visione ti indico che esistono/esisteranno anche queste etichette:
NoPassDoor: Livello di difficoltà per il pass door
NoBash:     Livello di difficoltà per il bash
NoPickLock: Livello di difficoltà per il pick lock

Ma passiamo a come resettare ste benedette porte:

Come ultime note: il sistema delle chiavi ancora non va', funzionano solo i
comandi di open e close lisci lisci, inoltre non funziona ancora il sistema
del secret e hide dell'uscita (che non so se spostare nella struttura della
porta o tenerle nell'uscita... bho!)

- Ho separato il codice dei 5 sensi (inteso come tutti i sensi tranne il look)
 che ora come ora facevano riferimento ad un'unica parte di codice, questo per
 prepararli alla futura modifica dei messaggi di act che mi avevi suggerito
 tempo fa, purtroppo tutto questo giro potrebbe aver generato qualche baco e
 quindi magari un comando sensoriale funziona mentre un altro no, sarebbero da
 tenere sotto osservazione per un po' (DA MONITORARE POCO A POCO)

- Ho aggiunto il SEX.NEUTRAL, in omaggio ad alcuni mud classici... inoltre avevo
 timore che l'arcigay mi volesse fare il sederino codoso evitando di inserire
 cose "diverse"..
 Grammaticalmente funziona come un SEX.MALE

- Ho ripulito l'header di tutte le pagine web, ora dovrebbero essere
più corrette
 e magari (MAGARI EH!) la pagina di gioco classica si blocca di meno
(DA PROVARE)


================================================================================
Rella 38
16/01/2010

- Ti avevo promesso un'implementazione succosa a livello di gioco, eccola qui:
 Implementato il Portal e il comando enter per entrare negli stessi, per il
 portale ti spiego qui:
 Si può aggiungere, sia ad item che a mob, questa struttura di etichetta:

 Portal
   Coords: 6 7 -4 torreelementi
   EntityEnterMessage: Entri dentro $N e bla bla bla.
   TargetEnterMessage: $n entra dentro di te e bla bla bla.
   OtherEnterMessage: $n entra dentro $N e bla bla bla.
   EntityExitMessage: Arrivi uscendo da qualche cosa e bla bla bla.
   TargetExitMessage: Sai che $n è arrivato in $t uscendo da te e bla bla bla.
   OtherExitMessage: Arriva uscendo da qualche cosa e bla bla bla.
 End

 Etichetta obbligatoria è Coords, che è una Destination.
 Gli altri messaggi sono facoltativi, anche tra di loro (cioè ne puoi mettere
 uno a caso, o tre o tutti), sono messaggi inviati tramite la act, e quindi con
 tag act (vedi social); se non vengono inseriti verranno inviati quelli di
 default.

 E' possibile decidere di inserire un messaggio con la parola speciale no_send;
 questa (similmente ai social) evita di inviare il messaggio di default:
 per esempio quindi si può rendere esplicito l'entrata in un portale alla sola
 entity e al target ma non agli altri nella stanza.

 EntityEnterMessage: messaggio che viene letto da chi sta entrando nel portale
 TargetEnterMessage: messaggio che viene letto da chi subisce
l'enter, cioè il portale
 OtherEnterMessage: messaggio che viene letto da tutti gli altri nella stanza
 Gli altri tre messaggi sono relativi all'uscita di Entity, qui
OtherExitMessage
 verranno letti da tutti gli altri che si trovano nella stanza
d'uscita, escluso
 entity e target (se questo si trova in quella stanza, ovvero se le coordinate
 di arrivo sono uguali a quelle di entrata).
 Forse non ha molto senso completare anche i messaggi per il target, ma per
 completezza sarebbe il caso.

 Riassummo qui i vari tag di act utilizzabili per questi messaggi:
 $n nome/short dell'entità che entra nel portale
 $N nome/short dell'entità portale
 $o, $O o/a grammaticale dell'entità e del portale come sai già
 $t nome/short stanza attuale
 $T nome/short stanza precedente (qui al posto di questo si può avere un'altra
 informazione, cmq una volta deciso rimarrà sempre quella)

 Ho notato che il comando enter esteso alle entità mob prende una nota sessuale
 e/o sconcia difficile da lenire... vabbe'.
 Ci tengo a far notare che un portal è possibile scriverlo anche in un file
 player (visto che di base un player è un mob) creando cose abbastanza buffe.
 No! So già cosa vuoi farmi.. Tu la suppostina la puoi forzare ad entrare nel
 TUO di portale... Gnè! Gnè!
 (Testato l'enter con le feature di base, non testati i messaggi personalizzati
 e il no_send, leggere attentamente le avvertenze, in caso di bachi consultare
 il Gatto)

- Ho reinserito il goto precedente col baco vecchio, ma per lo meno usabile.
 (Testato)

- Ho corretto il problema della razza mob che veniva impostata a NONE
 sovrascrivendo quello che veniva letto da file *.dat, nel nostro caso era il
 nano. (Testato con l'accuse)

- C'era un bachetto nella creazione delle tooltip relative alla descrizione
 della stanza, tuttavia non credo che ciò cambi di molto il problema dello
 scroll (relativamente agli admin per lo meno), ma chissà..

- Corretto, sul serio stavolta, il messaggio "non andato a buon fine" ai
 comando di thunder forzati sui nani (Testato)

- Implementando il no_send per le entità portale ho trovato un baco nei no_send
 dei social, probabilmente non te ne eri accorto visto l'uso parco della
 feature tra i sociali, era giusto per farti sapere nel qual caso notassi
 eventuali differenze.
 E possibile che i player che avessero utilizzato i social basati leggessero
 pari pari la stringa "no_send"
 (Non testato)

- C'era un problema nell'utilizzo delle macro key direzionali relative al
 tastierino numerico, se nel ricaricamento della parte in basso relativa
 all'invio degli input il focus veniva preso dall'input text relativo
 allora al posto di spostarsi venivano scritti i numeri, ora dovrebbe essere
 a posto (non testato, sul netboot non si può...)


================================================================================
Rella 37
11/01/2010

Anche se non ho terminato questa versione visto che inizio la
settimana lavorativa preferisco passartela poiché durante la settimana
utilizzerò il netbook per eseguire modifiche, e non voglio
pasticciare.

La parte non terminata, ma cmq funzionante, è quella relativa al
rifacimento del link dello shutdown.

Ti scrivo qui di seguito le modifiche apportate, non le inserisco in
google wave, sai tu meglio di me poi come e dove copiare e incollare.

- Ho spostato le cartelle rooms, items e mobs nella cartella persistence
 invece che in quella di data, in questa maniera dovrebbero esservi meno
 pericoli (Testato)

- Ho cambiato il nome al parametro di config use_persistence in
 save_persistence (Testato)

- Ora utilizzando il force con il thunder non dovrebbe dare messaggi di
 "non andato a buon fine" quando sembra invece andare (Non testato)

- Ho altresì spostato le due variabili position e knowledges dai mob alle
 entità generiche, cosicché anche gli item possano thunderizzare.
 (Non testato)

- Ho provato a modificare il goto per quel problema degli oggetti in inventario
 di pg quittanti, è tutto da provare.
 Temo che invece di aver corretto ho fatto pasticci, e mi sono accorto che
 è inutile correggere una cosa che devo rifare (non il goto ma il sistema di
 puntamento dell'entità contenuta e entità contenitrice) (Non testato e
 probabilmente inutile testare)

- Per un baco nella lista dei dati persistenti nel link del database non faceva
 vedere tutte la variabili, ora le fa vedere... anche troppo... cioè anche
 quelle relative al proprio prototipo, ma per ora va bene così (anche se
 bisogna ricordarsi che non sono esattamente variabili relative a quell'entità)
 (Testato)

- Migliorata la gestione del Backup DB, del Save The World, dello Shutdown ed
 aggiunto il link alla pagina Rm Persistence (ogni riferimento al nome del
 link è puramente casuale) (Testato)


================================================================================
Rella 36
08/01/2010

- Corretto il thunder forzato sugli oggetti (Testato)

- Ora il check sulle parolacce viene fatto solo ai player (Testato)

- Corretto il problema del goto che faceva crashare quando entrava
  in errore, ora dovrebbe "entrare in errore corettamente" e far visualizzare
  il messaggio:
  "L'entità, di tipo sconosciuto, X esiste ma non è raggiungibile perché non
  ha né in_room né contained_by validi."
  Per entrare in errore correttamente significa inviare il messaggio
  d'errore (relativo alla connessione non pulira correttamente) che
  prima non riusciva ad inviare. (Testato)

- Altra buona notizia è quella che ho risolto proprio quel problema
  della connessione, quella che capitava facendo questo:
  (18.50.22) Sulfrum: entrato con zork
  (18.50.26) Sulfrum: poi fatto quit
  (18.50.32) Sulfrum: entrato con entropy
  (18.50.34) Sulfrum: goto zork
  Quindi ora come ora che io sappia non vi sono bachi relativi alla
  connessione, cmq non durerà molto temo.. (Testato)

- Ho attivato il log anche su file dei comandi inviati dai player, così
  da vederne il comportamento e capire che han fatto in caso di errore.
  Vedi per esempio il problema delle direzioni casuali di jumping jack
  che ti ho inviato via mail.
  Il log è comprensivo anche dell'argomento.
  (Testato)

- Ho disattivato il writing su file di log dei reset, lo ingrandiva troppo
  ora che attivo la registrazione degli input mandati dall'utente, e poi
  testiamo i reset online e non offline, no? (Testato)

- Ho inserito un sistema di comunicazione tra più seb server aarit,
  sostanzialmente il server ufficiale avvisa il server di test se un pg si
  è appena connesso, con un tipico messaggi di log (blinkante sotto firefox)
  Per attivare il sistema bisogna un po' ravanare nel file di config.ini, le
  due voci che ci interessanto sono site_address e test_address

- site_address del config dell'aarit ufficiale è quello della 400

- site_address del config dell'aarit di test è quello della 25442

- copia e incolla in tutti e due i config il site_address di testing nella
  voce test_address.
  Non preoccuparti, non ci sono conflitti anche se inserisci nel site_address
  test_address nel file config dell'aarit di test.
  Così a questo punto possiamo testare in tutta tranquillità nella release
  di test sapendo che ci arriveranno messaggi di "incoming alien fighter!".
  (Testato)

- Ho convertito le liste dei colori da bianche in colorate per l'appunto, si
  vedono nella creazione del personaggio (Testati)

- Commentati e non più utilizzabili i comandi gtell, equipment e flee, che
  per ora non facevano nulla. (Testato)

- Aggiunta l'opzione di config use_in_memory_log che permette di salvare
  il log in memoria e successivamente visualizzarlo nella link alla pagina
  Show Log (Testato)


- Aggiunta l'opzione di config mail_on_enter_in_game nella sezione [MAIL]
   Se attivata serve ad avvertire se qualche giocatore non admin entra in gioco,
  proprio come fa ora.
  (Testato)

- Ho aggiunto l'informazione UserAgent per tutti i player, in pratica così
  sapremo con che browser un giocatore è entrato nel Mud.
  Per conoscere l'informazione basta andare al link nel Database relativo ai
  giocatori e cercare la colonna UserAgent per l'appunto. (Testato)

- Copiata la tooltip da lol, carina.. ora non abbiamo più scuse, questa non deve
  bloccare lo scrolling, il testo esce dalla tooltip con parole molto lunghe,
  ma vabbe', per ora faccio finta di nulla (Testato)


================================================================================
Rella 35 (RELEASE v0.6u open source)
04/01/2010

- Le note di rilascio della release 35 dovrebbero essere da qualche parte in
  google wave

- Ho fatto un passo indietro riguardo ad una pulizia invasiva delle connessioni
  ritornando a come era la --r32-- E' tutto un mondo ancora aperto cmq..
  (da provare)

- Corretto il who, me n'ero dimenticato, l'ho letto in google wave, rimanevano
  nel who i pg anche se erano usciti (da provare)

- Corretto il problema del say :-) che funziona

- Ho implementato il comando snoop! succoso...
  L'ho usato per testare il movimento forzato sugli oggetti
  L'ho anche testato, per esempio, snoopando contemporaneamente la tecia e il
  mindflayer, per vedere come leggessero gli output a seconda se eseguivo un
  certo comando ad uno dei due.
  (da provare)

- il RESET funziona (al prox boot put+reset riavvicinati)

- da provare correzione (dovrebbe sistemarsi da solo il problema monete
  [riunificare pt e remove su same reset], giocare con matita anello in
  mfdonald transport [1default+3room]

- I pg con trust normale ora non vedranno e non potranno più usare il
  timemachine (da provare)


================================================================================
Rella 34
03/01/2010

- Ora i log violetti si rileggono nel mud

- Corretto il social dance

- Ho modificato il messaggio "$n rientra in gioco dopo un crash" con
"$n si riconnette al gioco"
questo perché ci sono dei casi non bacosi in cui un pg si riconnette al gioco
cioè si riconnette non solo quando ha avuto un crash, ma anche, per esempio
quando utilizza un browser al posto di un'altro con già la connessione alla
pagina di gioco.
Si riconnette appunto.

- Quando un pg si riconnette non avvisa via mail, perché appunto è una
connessione e non una riconnessione

- Ho risolto un baco riguardante la riconnessione tramite un altro browser
se ricordi dava un certo errore tipo:
"$n non si trova nè in una stanza nè in un'altra entità."

- Ho rimosso la pulizia delle connessioni alla chiusura del Mud, mi davano
problemi e basta e son adeguatamente convinto che cmq allo shutdown vengano
uccise

- Altri due bachi che non hai incontrato e che non incontrerai se utilizzerai
questa rella al posto della vecchia

- Ricordi la frase di log:
"Non è stato trovato nessun riferimento a %r, con primary_key %r, nel (o nei) database %r alla path %r."
?
Ecco d'ora in avanti non ci sarà più bisogno di avviare, shutdownare e
riavviare ancora per avere i riferimenti ripuliti a codici ormai cancellati
o rinominati, lo faccio in quel punto, durante il caricamento.

- Ho testato un po' il RESET.REMOVE con quantity a 2, mi ha funzionato senza
problemi ma ho fatto un test semplice, e non con più entity reset differenti
nello stesso roomreset.
Ho migliorato inoltre il print-console relativo al RESET.REMOVE dovrebbe
essere intelleggibile ora.
Oltre a quello ti dovrebbe cmq venire fuori un log violetto del tipo:
(reset src\area.py 516): 3007-3-12 19:1: RESET.REMOVE dell'entità
limbo_item_random#27322640 dal contenitore limbo_room_void_1#27322512
(quantità rimosse: 2).

- Il maze deve aspettare, anche se penso di sapere cosa possa essere, in
pratica io ho invertito le ordinate dall'alto mettendole in basso, però mi
sono dimenticato bellamente di scambiare anche le uscite nord e sud..
In pratica sarebbe come far ruotare il labirinto lungo la mediana
orizzontale..
Non son sicuro ancora, ma penso sia quello.. Il bello è che ogni tanto il
labirinto esce fuori giusto, ma per culo!
Lascia quindi perdere qualsiasi test sul maze.

- Potresti avere bachi nella exit_from_game, non ho avuto le forze di
testare ulteriormente il logout dal gioco dopo i 15 minuti


================================================================================
Rella 33
02/01/2010

!!! Attenzione! Ho modificato i social duplicando i social felar per i gatti e
 modificandoli ad uopo, quindi nella migrazione del codice ricordati dei
 social (non testato)

- Corretto il goto su oggetti in inventario (testato)

- Corretta e migliorata la visualizzazione dei dati nel link web del database
(testato)

- Aggiunto il log del force, che non va a scrivere sul file di log (testato)

- Aggiunta la possibilità di inserire in incognito mob e oggetti, riscritto
il comando incognito (testato)

- Cazzo ci sono riuscito! Ho implementato il maze!
Funziona così:
vai nell'area maze.dat e modifica
 Columns: 3
 Rows:    3
come vuoi tu, vabbe' superiore a 0 per lo meno
Poi vai in rooms/maze e cancella tutti i file relativi alle rooms, così che
il mud al'avvio le possa rigenerare.
Una volta avviato digita con il goto una coordinata nel range scelto
(nel caso di sopra le coordinate andrebbero tra 0 0 0 maze e 2 2 0 maze)
L'entrata (o l'uscita a seconda di come la si vede) si trova in alto a
sinistra mentre l'uscita (o l'entrata) si trova in basso a destra, se
ci passerai riconoscerai le coordinate perché esce un errore di log visto che
non esiste nessun collegamento reale alla stanza di entrata e di uscita.
Have a nice trip!
(testato su labirintini 3x3)

- Corretto l'admtalk, ora non si fa leggere dagli altri player (testato)

- Corretto il force su oggetti e mob, ora si può far sorridere gli oggetti o
cose così (testato)

- Corretto il messaggio di log di quando un giocatore entra in gioco quando la
WasInRoom si corrompe, veniva detto che entrava in gioco per la prima volta
ma non era vero (testato)

- Tappato il baco delle doppie connessioni, non l'ho corretto alla radice,
c'è sempre purtroppo, tuttavia nell'invio dei chat, admintalk e log scorro
tra i player invece che tra le connessioni, cossiché non dovrebbero esserci
più problemi visibili (NON testato)

- Non è più possibile inviare dei force forzosi.. eh lo so lo so... su non
piangere.. lo so che il giochino era bello (testato)
Tuttavia ora se l'admin non è in incognito la vittima vedrà un messaggio
che X sta cercando di forzargli a fare qualcosa (testato)

- Aggiunte le pagine di visualizzazione dei bugs, ideas e typos tra i link
degli admin del sito (testata)

- C'è anche una bella pagina con la lista delle connessioni al sito con
informazioni succose, ora finalmente potremo utilizzare questa pagina per
sapere quante connessioni doppie esistono o meno (testata)

- Corretto il say . (testato)

- Ho inserito il sistema di invio delle mail, se il config.ini di aarit è stato
configurato correttamente e il server pure dovrebbe andare (l'ho testato sotto
windows con il mio smtp address).
Devi avere un email valido nell'account Sulfrum, altrimenti non riceverai
mail.
E' da notare che non verranno inviate mail quando entra un pg relativi ad un
account con trust superiore a TRUST.PLAYER o che nell'account ha almeno un pg
admin.
Sarebbe meglio anche togliere tutte le mail sfuffe a tutti gli account con
Trust maggiore di TRUST.PLAYER, attualmente cerco di inviare 4 mail, una a me
e altre tre a mail mail@sfuffa.like
Tanto le email che ricordi sono opzionali

- Ti ho messo dei print nella cosa dei reset.remove così da essere certi di
alcune cosette, tali log non vengono visti lato mud (log viola) e neppure
scritti su file di log ma vengono visualizzati solo tramite console
ricordatelo quando li ritesti con questa versione per avere tali informazioni
(che solo io posso decifrare :P)
iniziano per "-->>"

- Alcune correzioni qui e là (alcune delle quali ti passai via mail o via IM)


================================================================================
Rella 32
30/12/2009

- Ecco fatto, ho rimaneggiato ancora il thunder

- Ho cambiato il testo nella homepage, vedi se ti piace, consiglia di meglio
se ti pare.

- Ho modificato tutti i codici di colore [grey] in [gray], e simili ([dimgrey],
[lightgrey], etc etc..)
Questo perché grey è un sinonimo che però ho scoperto non viene supportato
per Internet Explorer 6.0.
Non so se tu avessi utilizzato dei [grey] nei vari *.dat, se sì sarebbe il
caso di effettuare una ricerca per controllare le varie occorrenze di grey
e poi pensare a replace mirati (non seddare troppo..)

- Ho corretto il problema dell'incognito, l'avevo proprio fatta grossa..

- Ho rimosso il codice che mi manteneva il contenuto della WasInRoom, così
il test boot+shutdown+boot dovrebbe far tornare i file dei pg puliti

tutto quando non testato :(


================================================================================
Rella 31
29/12/2009

- Ho implementato il comando incognito, tuttavia c'è da dire che in alcuni punti
del codice manca ancora il controllo sull'incognito e quindi alcune azioni
del personaggio in incognito vengono comunque viste.
Lì c'è poco da fare, caso per caso bisogna segnalarle in maniera tale che io
possa inserirne il controllo.
(abbastanza testato)

- Aggiunto il sinonimo metti/put per il comando give, visto che quest'ultimo
alla fin fine funziona proprio come il put, o no?
(testato)

- Ho aggiunto un log per l'errore
AttributeError: 'str' object has no attribute '_primary_key'
qualcosa di questo tipo:
Inaspettato raggiungimento del codice, var %r per la label %s al
dato %r verrà scritta come la stringa '%s'
così sai che se ti capita è in realtà qualcosa relativo all'errore del
_primary_key precedente.
Cmq con il nuovo sistema dovrebbe essere tutto più stabile, anche se non so
se ho corretto realmente il problema del tutto.
(più che testare bisogna vedere se questa parte di codice abbia stabilizzato
meglio il codice, quindi vedremo)

- E riproviamo con il thunder!
(untestato :)

- Non ho corretto la bastardata del goto perchè il problema non è lì ma a priori
probabilmente nel resetting delle stanze laddove non c'è nulla in quelle
coordinate.
Difatti invece quella parte dovrei averla corretta, ma è tutta da testare
Anche il problema del movimento nelle stanze resettate partendo da una
coordinata vuota era, molto probabilmente, relativo a quel problema
(untestata)

- Ho aggiunto i messaggi relativi al get che mi hai chiesto, cioè i pg che si
vedono beccare un oggetto leggono anche loro qualcosa
(untestata)

- Aggiunto il messaggio di enter_in_game


================================================================================
Rella 30
29/12/2009

   - D'ora in poi cercherò di ricordarmi di segnarti se una feature che ho
implementato l'ho testata oppure no.
Attenzione che io come mio solito testo le cose poco (sono la nostra
maledizione in sostanza) quindi anche se dico testata significa averla vista
funzionare una volta senza controllare che il resto delle feature attorno a
quella implementazione continuino a funzionare.
Insomma, va' a culo!

- E riproviamo con il thunder va'.. (l'ho testato, ma facciamo che non l'abbia
testato, come da tradizione)

- Corretto il get riguardo al crash della TRUST, cioè il get dei player
(testato)

- In effetti non poteva andare il reset di room in coordinate non ancora
occupate, fortunatamente era un baco semplice semplice da correggere
(non testato)

- Ora dovrebbe essere possibile gettare qualcosa da un'entità nel proprio
inventario (testato)

- Ecco fatto, ora ho evitato anche il get-steal sui player (testato)

- Non ho effettuato nessun'altra modifica per lenire il problema delle
connessioni doppie, in effetti qualcosa potrei fare, ma un po' mi piglia male
inserire del codice per tappare un baco che in realtà è una manifestazione
di un baco precedente.
Quindi riassumendo: quando ci sono dei pg raddoppiati in giro è perchè c'è
stato un crash di connessione (solito traceback nella pagina web che ormai
conosci e relativo pezzo nel file di log) quindi bisogna andare a scovarlo
e correggerlo.
Vediamo come va' a finire in questi gg per decidere..


================================================================================
Rella 29
28/12/2009

Ecco qui, alcune correzioni e un check aggiuntivo quando il pg rientra
in gioco, ovvero se trova che è già in gioco rientra ma non si
sdoppia.

Non sono riuscito a provarlo, oppure ci sono riuscito e il problema è
stato effettivamente corretto.
E' un problema che può capitare ad ogni crash di connessione: quando
ciò accade la connessione non viene chiusa e il pg rimane in gioco,
questo implica che quando prov a rientrare con lo stesso pg (senza
aver shutdownato) questo si sdoppia.

Insomma finalmente abbiamo capito come mai sti pg si sdoppiano, almeno
per ora, con questo particolare problema.


================================================================================
Rella 28
28/12/2009

- Un minimo di test l'ho fatto, quindi il tutto dovrebbe essere abb indolore,
la cosa più importante da controllare e testare è la persistenza dei player

- Mi ero dimenticato di dirti che nella rella precedente avevo rimosso un
controllo relativo alla game loop, ricordi quando il calendario rpg del mud
rimaneva freezato e non andava più avanti? Ecco potrebbe ricapitare ancora
proprio perchè ho rimosso questo controllo, che mi avrebbe nascosto alcuni
crash e relativi traceback.. (in alcuni casi avrebbe anche fatto evitare
l'esecuzione della persistenza una volta che il mud veniva chiuso)

- Dovrei aver corretto il problema delle tabulazioni iniziali in alcune
descrizioni
Ed anche quello relativo alle extra formate da due righe la cui seconda
non andava a capo (baco storico..)
Qualsiasi altro problema relativo alla spaziatura o a capo deve essere
segnalato, perchè ciò che ho fatto potrebbe averli corretti tutti come averne
inseriti dei nuovi

- Corretto i problemi relativi al who che mi hai segnalato

- Corretto il crash del thunder, forse è finita?

- L'opzione in config.ini che si chiamava use_log_html l'ho rinominata in
log_player_output, tienne conto quano dovrai fare le tue cose sul config.ini

- Risolto il problema del pixie ciccioni, il problema era relativo solo alla
loro razza

- Ho disattivato la creazione della razza pixie e della razza minotauro, che è
tutta da pensare

- Corretto il problema che non mi salvava la data di logout del pg ed ho
corretto anche il calcolo sul tempo giocato dal pg (l'ultima colonna della
tabella relativa all'elenco dei personaggi)

- Ora non ci sono più i messaggi di mancanza della Descr per i giocatori appena
creati

- Ho riempito la pagina links con i link ai portali principali italiani, se
pensi che ne abbia dimenticato qualcuno fammi un fischio (nessun link ai mud
italiani per ora)

- Ho altresì nascosto alcuni link a pagine mezze fatte o senza contenuto utile;
quindi non spaventarti se troverai il menù a destra nella pagina del sito
relativamente vuoto

- Ho aggiunto la voce in config.ini allow_player_getting
ora è a False, cioè evita di far gettare giocatori, per tornare a come era
prima bisogna impostare il valore True

- Ok, ho creato la persistenza anche per il salvataggio della stanza in cui il
pg si trovava quittando, pensavo fosse più semplice ma ho già visto che tutto
ciò porterà a potenziali bachi in futuro, soprattutto quando creerò il
RESET.REMOVE anche per le stanze

- Nella mail "il coder micioso non ha voglia d'implementarle" mi indicasti un
paio di bachi del goto penso di averli corretti, tuttavia penso anche di aver
ribaltato così tanto il codice che siamo più o meno al punto del thunder di
due mesi fa :D
no beh esagero, cmq non so.. vista la relativa importanza del goto in questo
momento lo lascio a te eventualmente da testare

- Il problema descritto nella mail "force conteiner" dovrei averlo corretto
assieme alla persistenza del riferimento della stanza-quit al giocatore
Quindi non dovrebbe più sbucare l'errore:
19:04 [Fwrite] (__getattr__ src/item.py 118): Attributo
fwrite_the_line inesistente nel ProtoItem novizi_item_coccarda_03 che
serve all'Item novizi_item_coccarda_03#170795692

- Ho notato che la "Una fiamma azzurra si muove irrequieta." è troppo poca
azzurra di colore, voluto o è meglio in-cyanarla un po'?

- Ok dovrei aver corretto anche il baco spiegato nella mail:
"in aggiunta al coder micioso (oggetti spariti per un misterioso baco)"
oltre a quel baco mi è capitato sotto mano un altro baco (le entità
player non salvano la propria area, cioè l'etichetta Area: mentre i
mob e gli item sì) cmq per come vengono caricati i player per ora non
è un problema, ma magari ci sono altri bachetti relativi a questo
problema

- Mi manca da correggere il get-ruboso, ma ora temo di aver terminato le forze
mentali e voglio mantenermi un attimo sveglio mentre ti faccio il pacchetto


================================================================================
Rella 27
20/12/2009

- Fatto il comando force, testato un po' ma non troppo..
E' utile eseguire il force su se stessi per vedere il funzionamento base.
Probabilmente se forzerai dei comandi su oggetti, anche solo un drop per
vedere se un oggetto ha realmente in inventario un altro oggetto dato con
un tuo give, crasharà, quei bachi sono roba che dovrò digerire poco a poco.
Se vuoi o ti capita raccoglibili poco a poco in un file e dammelo almeno tra
un mese.
Altrimenti si fa prima a slittare il testing per altri tempi (servirà
soprattutto quando si potrà eseguire uno switch in un'altra entità, tipo un
oggetto, e fargli fare comandi da mob-player, crasha a gogo).

- Ho utilizzato la nostra timemachine, e sono andato a fine gennaio 2010 per
vedere come avevo implementato il RESET.REMOVE per i ResetEntity
e l'ho copiato e incollato in questa release, il tutto rigorosamente senza
testare come da buon coder dall'istinto felino, mra'!

- Dovrei aver aggiunto la possibilità di poter resettare in una coordinata
in cui precedentemente non vi era una stanza anche durante il gioco,
ovviamente
è una cosa untestatissima

- Implementata anche la persistenza dei giocatori

- Implementato il comando who, differenziandolo tra admin e player

- Corretto ancora il thundering, pronto per il prossimo baco!

- Aggiunta la data reale ai comandi but, idea e typo

- Forse ho corretto il problema dei pg che rimangono nel who anche dopo lungo
tempo che sono stati sconnessi, il problema non si poneva sotto windows,
quindi a te il test

- Aggiunto un check che evita di andare di goto negli oggetti del proprio
inventario

- Forse forse ho corretto anche il baco relativo al get di pg che avevano
perso il link, ma avendo cambiato un po' la tecnica di contenimento delle
entità nelle aree potrei aver inserito altri bachi in realtà

- Il livello minimo rimane ancora lo zero, devo pensarci bene se modificarlo o
meno, non dovrebbero esservi più il messaggio di errore

- wow! forse ho corretto anche il baco del timemachine
perlomeno il comando timemachine 55 23 30 9
non fa passare dopo pochi secondi al primo dell'anno ma al primo del 10° mese

- Ho creato dei log appositi per i reset come da te suggerito


================================================================================
Rella 26
09/12/2009

Ti invio la sulfrum version allo stato di ieri perchè per un po' non
so quanto me ne potrò occupare ed è meglio che ti passi i fix di cui
mi sono attualmente occupato.

- Ho provato a diminuire ulteriormente il tempo di esecuzione del goto, ma ho
visto che non cambiava molto, quindi mi sono per ora arreso, prima o poi
dovremo fare del profiling al codice per vedere dov'è il collo di bottiglia

- Ora il goto dovrebbe funzionare correttamente

- Ho corretto dei bachi che riguardavano i tre comandi idea, bug e typo, ora
dovrebbero poter essere utilizzabili e i messaggi vengono salvati nell'account
fa un po' schifo come vengono salvati.. ma vabbe', ce li abbiamo

- Visto che so che ti diverti con il sed, ho provveduto a rallegrarti la
giornata dandoti per compito questa modifichina:
OPTION.AUTO -> OPTION.AUTO_
per tutti gli account

- Corretto il baco del month nella timemachine, ti avevo già passato
il fix on the fly

- Aggiunti i colori ai nomi delle aree nella pagina delle aree sul sito

- Corretto il thunder, ma potrebbe crashare in altri casi

- Il look sui novizi ora darà una blanda frase descrittiva, la odierai, la odio

- Rimossa la razza Cat dalla pagina delle razze

- E' da provare il problema del loop/23, ora dovrei poter gestire i bachi che
forse lo bloccavano, ma è cmq da testare, ricordo che avevi già il
reset pronto in canna

- Corretto il baco per cui non si potevano leggere le extra sensoriali negli
oggetti dello zaino, yuppi!

- Corretto il problema dei reset stagionali, erano due bachi che si
intrecciavano tra di loro, peggio dei serpenti nel bastone di
Esculapio

Al lavoro sono alla frutta.. ovvero il mio capo, secondo me, ha tutta
l'intenzione di buttarmi fuori e non portarmi Inisvizzera, provvedendo
a non pagarmi dei 5000 euri netti che mi spettano.
Ho deciso cmq di dare il massimo e sto usando il mio tempo libero, si
solito dedicato ad Aarit, al coding per il lavoro.
Inoltre sono appena passato dallo sfiorare una crisi depressiva, ormai
le conosco dal 2002 e riesco a schivarle, almeno per ora.
Quindi mi sto divertendo a vedere quando l'animo umano possa
sopportare, io penso che i miei limiti siamo ben lontani, al caso
finisco come mio padre che si è suicidato in una non ben chiara
maniera (nessuno dei miei parenti alla fin fine ha mai avuto il
coraggio di dirmelo).
A parte questo sfogo sono fiducioso di riuscire a farmi ulteriore male
e continuare anche con Aarit e darti qualche fix in più entro il 25.
Non allarmarti cmq se non mi vedrai nei prossimi gg, potrei volermi
chiudere per concentarmi al meglio.
Ti esorto inoltre, caro gentilissimo Area Builder, a rompermi le palle
inviandomi i risultati di eventuali test che effettuerai sulla rella
che ti sto attualmente inviando.


================================================================================
Rella 25
07/12/2009

Ho corretto il problema del goto e ne ho migliorato l'output

- Ho migliorato le prestazioni del codice che viene chiamato dal goto, dovrebbe
andare meglio, ma potrei avervi inserito alcuni bachi, tipo quello del
contatore 2.<oggetto> 3.<oggetto> etc etc
c'è un po' da provarlo insomma
Oddio ho fatto due test.. non è che sia poi così convinto di averlo accelerato
così tanto sarebbe il caso di fare un test con il codice vecchio sul server e
poi con questo nuovo e vedere cosa succede

- Aggiunta l'opzione use_persistence nel file di config, di default a True,
non cambiarla per ora, visto che stiamo testando la persistenza appunto,
cmq tanto per fartelo sapere, se la imposti a False ritorniamo ai vecchi
tempi in cui la persistenza non esisteva.

- Aggiunta l'opzione compression_mode nel file di config, valori possibili:
tar
gz
bz2
Serve ad indicare con quale metodologia salvare i file che aarit comprime, nel
nostro caso per ora esegue una compressione prima di salvare i dati di tutta
la cartella /data in maniera di eseguire un backup della situazione precedente
prima di procedere ad eventuali armageddon.
Ora come ora è impostato a bz2.

- Dopo aver eseguito il backup dei dati (quando si esegue uno shutdown
o un kill)
tutti i dati rooms, mobs e items vengono cancellati per poi essere riscritti
da zero.
Mentre invece i dati account e player non vengono mai cancellati.
Difatti tali dati nella loro esistenza non vengono mai e poi mai cancellati
da parte del mud o del player, se si vuole rimuovere un account o un giocatore
bisogna farlo a mano, quindi il salvataggio di dati si limita ad un'aggiunta
o ad una sovrascrittura.
Ciò è un bene, anche perché sono dati abbastanza sensibili per il gioco.
Il backup te lo ritroverai nella cartella /backup di aarit.
Non inserirvi i tuoi backup lì dentro, teniamo separato il sistema di backup
automatici del Mud da quello del server.

- Ho aggiunto un link nel menù per gli admin che serve ad eseguire un backup in
qualsiasi momento.
Il sistema di backup è separato da quello di reset e save dei dati persistenti
quindi questo link esegue il solo backup.

- Ovviamente a questo punto ho implementato il link di Save nel menù web per
gli admin, così da poter effettura un save dei dati persistenti in qualsiasi
momento.

- Attento a non doppio/triplo-clicckare sui link Backup DB e Save The World
perché effettuerai per l'appunto quell'azione due o tre volte di fila, con
risultati non esattamente miciosi.
In futuro permetterò un solo click per volta e correggerò la cosa.

- Ho modificato il messaggio NO_GET, non è esattamente quello che mi avevi
suggerito, ma siamo lì.

- Corretto il problema descritto nella mail che iniziava con:
'Gentilissimo Coder'
... Non scrivere mai più una mail così! Ebbi un brivido d'orrore ...
;P

- Ho cambiato nome a tutti gli Element OPTION.AUTODIR in OPTION.AUTOOPEN
Tale Element veniva utilizzato nella Flags delle opzioni degli account.
Se al caricamento avrai errori che ti ricordino questa nota prova a
convertire tutti gli OPTION.AUTODIR in OPTION.AUTOOPEN nei soli file *.dat
degli account.

- Problema del Track nella fwrite della persistenza risolto alla radice:
ho commentato quella parte di codice :P

- Aggiunta la label Descr per le aree, che verrà visualizzata poi nella pagina
areas del sito
Ovviamente come noterai all'avvio del Mud ci saranno un po' di messaggi di
errore perchè Aarit già si attende che le descr siano riempite.
E' sempre il solito, gli dai un dito e si prende tutto il braccio!

- Corretto il problema della grandezza del carattere per il nome della stanza.

- Ho scoperto un baco per cui un minuto rpg durava un secondo reale.
In realtà Aarit vorrebbe che durasse due secondi reali, quindi ho corretto di
conseguenza.

- Corretto il comando timemachine

- Ho trovato il baco che crea istanze di dati persistenti con il nome del file
senza la #, g0tch4!

- Corretto il baco delle 23 ore
probabilmente era quello che non eseguiva il reset continuo degli
oggetti (problema coccarde spostate se ricordi)

- Ho attivato la persistenza per gli account, non ancora per i player,
so già che per loro avremo cattive sorprese, un passo per volta.


================================================================================
Rella 24
05/12/2009

- Convertito il comando eat in comando taste come da te suggeritomi, per ora
quindi il comando eat non esiste più.

- Dovrei essere riuscito a disabilitare l'history per l'input dell'invio dei
comandi al Mud, tuttavia la cosa non credo che funzioni su tutti i browser,
comunque per ora con le ultime versioni di FF e IE la cosa regge.

- Cancella pure le cartelle languages e books nella cartella /data, visto che
le gestisco (o gestirò) in maniera differente.

- Diviso l'ex comando calendar in due: la parte per i pg è diventata date
con calendar come sinonimo, mentre la parte admin si chiama timemachine
(per gli amici time)

- Per qualsiasi problema se devi azzerare la persistenza del mondo allora
cancella le cartelle rooms, items e mobs (MI RACCOMANDO non confonderti con
proto_rooms, proto_mobs e proto_items) al limite creati uno script apposito
Ogni volta che testi la persistenza dei dati del mud dovrai:
- Toccare ferro quando inivii il comando di start del mud
- Incrociare le dita durante il boot
- Durante il boot fare moltissima attenzione a messaggi che iniziano per "??"
- Incrociare le dita dei piedi durante la connessione del pg
- Dovrai altresì indicarmi altre tipologie di messaggi d'errore a te aliene
specie durante il caricamento delle aree e durante la loro scrittura
- A quel punto dovresti essere nel Mud.. più o meno vivo.. modifica qualcosa
nel mondo del Mud, killalo (oppure utilizza lo shutdown dal sito)
- Riavvia il Mud e controlla che la modifica al mondo sia stata
effettivamente mantenuta e caricata
- Ovviamente me ne accorgo se ad ogni riavvio non incroci le dita dei piedi..
Quindi non fare il furbo! ;P

Attenzione che attualmente funziona la persistenza delle sole stanze,
oggetti e mob ma non player e account, questo per debuggare un po' il sistema
prima di fare allegri casini nel resto.

Attualmente ho provato il sistema solo gettando e/o droppando oggetti in
luoghi differenti, sembra che regga per ora.. ma bisogna vedere nel
lungo tempo.


================================================================================
Rella 23
15/11/2009

Ecco, le correzioni e piccole richieste effettuate ieri dovrei averle
corrette tutte

- corretto thundering
- corretti spazi mangiati su asciiart
- risolto bug comandi sensoriali oltre al look lanciabili con argomento


C'è ancora il problema del doppio Entropy

Il problema dell'output spezzato con tante entità nella stanza
dovrebbe non sussistere più.. quello per le tooltip dell'admin c'è
ancora... eh

Zamp!


================================================================================
Rella 22
14/11/2009

- Ho implementato una cosa orribile!! Ma so che a te piacerà..
digita start.py -h
L'uscita dal boot non salverà mai dei file ne ora ne quando ci sarà la fwrite
(cioè la persistenza).
Vi ho aggiunto anche l'opzione -u tutta da (ri)testare.. (impostazione della
umask) dovrebbe fare la stessa cosa delle precedenti versioni, ora un po'
"più in basso" nell'esecuzione dello script di start.. ti lascio a te il test
a vedere se la cosa funzioni ancora o meno sotto linux
Ah, bisogna passare -u 2, per farlo andare come andava prima, oppure puoi
anche scrivere -u 0002

- Ti avevo scritto che l'etichetta per impostare le keywords relative al nome
di un'entità era la label Keywords, in realtà è la label KeywordsName

- Corretto hissing e thunder come già ti indicai in una mail

- Ho aggiunto delle opzioni in config.ini:
reload_commands = True
reload_web_pages = True
use_log_html = False
Questi tre sono una granularità della vecchia opzione development
allow_multiplaying = False
Quest'ultimo impostato a True potrebbe farti quello scherzetto del quit
anche se si è in game, di sicuro fa quello scherzo dei messaggi di log
duplicati-triplicati etc ect se ti ricordi
Ho aggiunto anche queste altre opzioni di configurazione:
max_account_bugs
max_account_typos
max_account_ideas

- Risolto il problema delle ascii art, ora per usarle bisogna scrivere così:
<pre class="asciiart">
CONTENUTO ASCII ART
</pre>
prova con 42 42 42 opekus, poi controllo e ti do il voto.

- Supportate le extra per il look e per i vari comandi che ritornano le extra
sensoriali, ho provato solo il look

- Ho aggiunto le extra alle Exit, che ancora però non funzionano, ed ho scoperto
che avevo già implementato le extra per le direzioni... peccato che non le
supporto per nulla, in compenso tu non le usi i Wall da nessuna parte, quindi
è tutto ok :P

- In questa versione puoi testare la storia delle connessioni chiuse e quella
relativa all'output spezzato, dovrebbe andare meglio

- Aggiunti i comandi typo, bug e idea, purtroppo non essendoci ancora
la persistenza dei dati non servono a molto.. ma li ho implementati in
vista dell'apertura


================================================================================
Rella 21
07/11/2009

- Ho creato un sistema di macro integrate dei comandi più comuni tramite
javascript, per ora i comandi inviabili sono tutti nel tastierino numerico
(con block num attivo, alcuni comandi anche con block num disattivo).

- Ho creato un sistema di invio messaggi nella Exit, ti rimando alla relativa
pagina di documentazione building aggiornata e allegata in questa versione.
Fanne un utilizzo parco perché dovrò cambiare il sistema, te la espongo
comunque, tanto per sperimentare.

- Ho finalmente corretto la funzione che crea le keywords, così ora si possono
utilizzare senza remore le etichette relative che ti spiegai a suo tempore.
Per esempio all'oggetto ghe xe una tecia, rimuove solo la parola una, ma 'ghe'
e 'xe' non li gestisce e non li gestirà mai.. quindi potrebbe essere il caso
di forzare una sola keywords: tecia.
Attualmente stampo per debug il risultato della creazione delle keywords per
vedere se la rimozione delle particelle-articolose funziona.

- Ho spostato il primo argomento del comando calendar, non è più l'ora ma i
minuti, questo in vista di una delle modifiche future del Reset in cui ci
sarà probabilmente un'unica etichetta con la data su una riga partendo
dall'unità di misura temporale più bassa a quella più alta.

- Bisognerebbe testare, anche semplicemente digitandoli una sola volta, tutti
i comandi, li ho refactorizzati e potrei avervi inserito degli errori.

- Ho aggiunto il canale chat, similmente dovrebbe funzionare anche il canale
admtalk, visto che è la stessa funzione che lo gestisce (mai provato cmq).

- Dovrei aver risolto il problema del 3.corda, a me funzia, prova a metterlo
sotto stress.

- Attento che non ho ancora risolto il problema del doppio entropy.


================================================================================
Rella 20
01/11/2009

- Giusto per farti sapere, quando avremo una versione da utilizzare per gioco
vero e proprio e non solo sviluppo sarebbe il caso di andare a cambiare
l'opzione in config.ini
development
da True a False
in maniera tale che le pagine web e i moduli py relativi ai comandi non
vengano ricaricati da HD ad ogni richiesta (sì, ora come ora se tu fai delle
modifiche ad un file nella cartella src\commands o src\webpages questa
dovrebbe, non sempre capita e non so perché visualizzarsi al prossimo invio
di comando oppure alla prossima richiesta della pagina, senza dover riavviare
il server)
Nonostante sia una feature comoda, nel momento in cui avremo tanti giocatori
in game la scalabilità andrà a male..

- Ho visto il messaggio mezzogiornoso, potrebbe anche andare bene.. anche se
alla fine fine serve ad un'area di "piccolo respiro", nel senso che tutte
le stanze all'aperto devono avere piante e semine al vento come descrizione
e non solo come oggetti.
Tra l'altro i messaggi mezzogiornosi potrei, in futuro, non farli vedere
se il tempo è brutto, perché si riferiscono più spesso alla luce, naturale
e non, diurna in condizioni di tempo "bello".
Quei messaggi sono più da oggetti che inviano a random dei messaggi
(mudscripts).
Però è cmq accettabile, solo che appunto bisogna fare attenzione e non
esagerare pensando anche ad eventuali utilizzi futuri dell'area.

- Ho inserito l'opzione DOUBLE_LANG per evitare o consentire, a scelta, la
ricerca dei comandi ingle/ita, già testata

- Se ti trovi dei file di log che non ti tornano nella cartella log, ignorali
o cancellali, è una cosa ancora immatura e servirà a loggare gli errori html.

- Ti ho aggiunto il link per shutdownare il mud, contento?
Ovviamente trovatelo da solo. Zamp! Zamp!
Immagino che invierà lo stesso output (o errore) del CTRL-C
E' giusto che non ritorni una pagina valida.. dopotutto lo shutdowno prima di
poterla generare e ritornare

E poi ovviamente varie correzioni qui e là, bisognerà riprovare un po' i comandi
specie il give entro entro dovrebbe essere a posto ma altri inloopamenti, bho


================================================================================
Rella 19
1/11/2009

- Implementato il sistema delle keywords che ti ho descritto nella mail
precedente, che ti ricordo qui di seguito.
Tre nuove label:
Keywords
KeywordsShort
KeywordsShortNight
Ognuna delle quali fa riferimento alle label:
Name
Short
ShortNight
Sono facoltative, e sarebbe concettualmente meglio non inserirle (anche se non
v'è una reale ragione per non utilizzarle se non quella di rendere la vita più
facile al builder).
Se le parole chiave non vengono inserite dal builder allora vengono create
automaticamente al caricamento del Mud, altrimenti vengono prese quelle
impostate dal Builder.
Al sistema per ora manca il filtering delle parole chiave inutili (come gli
articoli per esempio) v'è un baco che mi tronca le parole e quindi
lascio quella funzione a dopo.

- Corretto il baco del reset delle matite, quindi se uno inseririsce come reset
hour le 2 e nulla come label minuti dovrebbe cmq impostare i minuti a 0, così
da attivare il reset SOLO alle 2
In realtà ora che ci penso forse era meglio il sistema precedente.. non si sa
mai che si volesse fare qualcosa di strano..
Però in quel caso dovrei spiegare meglio nel manuale cosa bisogna fare..
Mumble mumble..
Cmq in generale sarà meglio indicare la data precisa, nel senso che se si
setta una delle label della data impostare anche quelle con unità temporale
minore (se per esempio si imposta il day, impostare anche hour e minute)
Ci sono cmq altri bachi, il resetting è cmq infinitamente-ciclico, ovvero
ogni volta che scatta il reset vengono aggiunti oggetti anche se questi
esistono di già..
Il resto dei bachi è relativo al repop.. che non è ancora implementato.
Il reset è l'inserimento di un'entità in un luogo, il repop è il rinnovo
continuo se questo viene tolto o ucciso, sono due cose distinte.

- Ho reso la descrizione dell'uscita opzionale, se non si inserisce nulla fa
visualizzare il nome della stanza proprio come nella lista delle uscite
nel look della stanza

- Una domanda: cosa succede quando killi Aarit? nella console in cui lo hai
avviato in cui vedi l'output di log esce qualche messaggio d'errore?
In teoria Aarit dovrebbe poter gestire il signal kill perché lo vede come
un'eccezione ma sotto windows mi è impossibile capire che output esca in quel
momento, e qualcosa di sicuro esce..

- Ho creato il comando di give.
Ho maturato un certo "concetto di comando aaritesco" mentre lo scrivevo e
ho cercato di implementarlo.
Sostanzialmente qualsiasi situazione in cui, nei vecchi comandi mud, veniva
inviato un output all'utente (dicendo per esempio: non trovi l'oggetto) in
Aarit si trasforma in messaggi tipo social: al giocatore, all'oggetto e
a tutti gli altri.
Questo non solo per dare un tocco di originalità in più (anche se si perde
forse in realismo, te ne accorgerai con alcune tipologie di messaggi, in
cui sarebbe difficile che "gli altri" capiscano esattamente cosa stia facendo
il giocatore che ha inviato il comando, eppure ci riescono :P) ma anche per
dare una visione esterna di quello che un giocatore (possibile niubbo) stia
digitando, cosicché il pg bravo ed esperto (admin e non) possa aiutarlo
quando ne intuisce l'erronea sintassi.
Ci tengo a far presente che tutti i messaggi che mi invento per Aarit sono
discutibili (quando codo utilizzo la parte logica e meno quella creativa)
quindi se hai output alternativi sei libero di proporli (tanto poi ti dico
di no!).
Ci sono anche dei messaggi e casistiche abb buffe.. es:
give <nome di se stessi> <nome di se stessi>
give <nome item> <nome di se stessi>
Il comando è abb potenziato: se non trova l'oggetto nell'inventario allora
prova ad eseguire un get nella stanza; se non trova nessuno a cui darlo nella
stanza allora cerca tale entità nell'inventario. E' una cosa sperimentale e
tutta da provare.
Ah ora che mi ricordo.. c'è la flag NO_GIVE sia per room che per entità..
a riguardo ti ho lasciato i commenti nel codice, dovresti riuscire a masticare
le differenti casistiche, che sono più sottili rispetto alla gestione della
NO_GET.
Il comando è da considerare in fase sperimentale, se piacerà la cosa lo
terremo così e mi muoverò pian pianino a convertire gli altri con lo stesso
concept (non per l'apertura, quello che abbiamo abbiamo, anche il give ce
lo terremo così per ora anche se non ci andrà, bachi eslusi).
Il testing completo del comando è abb difficile.. l'ho testato solo "su di me"
cioè ho letto tutti i messaggi diretti a me, ma non so se i messaggi diretti
ai vari target e agli altri siano corretti.. tutto da scoprire.
E' uno dei tipici lavoretti in cui Sharas era adattassima, al caso tu voglia
concentrarti sulle aree invece di testare, aspettiamo a vedere se si
riesce a contattare ed ad una sua eventuale disponibilità.


================================================================================
Rella 18
22/10/2009

- Ho cambiato la FLAG.NO_LOOK in FLAG.NO_LOOK_LIST, mi pare di avertelo
accennato. Sostanzialmente tutti le flag NO_NOMECOMANDO fanno evitare di
poter utilizzare un comando su di una determinata entità, invece quello che
si vuole con FLAG.NO_LOOK_LIST è evitare che certe entità si vedano tramite
il comando look e non evitare di utilizzarlo su di esse.

- Implementato l'etichetta Status, te ne avevo parlato chiamandolo Action, ho
cambiato il nome visto che ora lo uso anche per gli oggetti
Concettualmente: name (o short) + status = long

- Potenziato il comando goto in maniera tale da raggiungere una generica entità
se al comando si passa come prima argomento una keywords relativa ad essa
es: goto onirik
il comando per ora non funziona se ci si trova in inventario, crasherebbe

- Ho aggiunto l'etichetta Size come già accennato: a 1000 intende lo spazio
volumetrico occupato da un corpo umano medio, per valori più grandi o meno
bisogna giocarsela un po' ed immaginarsi lo spazio occupato dall'oggetto,
cavo o meno che sia.

- Ho aggiunto la gestione delle flag NO_GET e NO_DROP sia per le
entità che per le room, tutte da testare, le ho scritte così di getto

E infine c'è quella cosa che ha dato il titolo a questa release, e che
è solo un abbozzo di un sistema futuro più ampio.


================================================================================
Rella 17
09/10/2009

- Comando get semplice semplice, infatti se l'oggetto è invisibile o pesa tanto
viene raccolto lo stesso
- Migliorati o aggiunti messaggi di log su errori di building come da te
suggerito
- Corretto il baco look 1.oggetto 2.oggetto, stessa cosa dovrebbe capitare
con il get
- Fatto il comando inventario
- Fatto il comando exitused, a te serve usarlo così:
roomexitused 0 proto
così da elencare le stanze che "utilizzano" 0 uscite
senza l'argomento proto la ricerca avverà nelle stanze resettate e non quelle
buildate, ora come ora ti dovrebbero dare risultati identici non essendoci
mudscript che rimuovono/aggiungono uscite o che
- Fatto il comando roomused, a te serve principalmente così:
usedrooms 0
questo comando cerca solo tra le room prototipo
- Comando drop