WIF - La Community Italiana di The Battle for Wesnoth

Wesnoth Italian Forum
La Community Italiana di The Battle for Wesnoth uno dei migliori giochi multiplayer online gratis open source, a turni di ambientazione fantasy. Iscriviti a wifper partecipare ai tornei online, allo sviluppo di nuove estensioni (campagne, mappe, ere, scenari, fazioni) e a tutte le iniziative di w.i.f. per questo meraviglioso gioco strategia . Giocare gratis on line non è mai stato più facile.

Se stai cercando giochi multiplayer online, giochi di strategia, giochi a turni, giochi open source, giochi gratuiti o giochi fantasy, vieni a giocare online in multiplayer con noi! Questo è il forum che cercavi.
20 Agosto 2017, 12:49:13 *
Benvenuto! Accedi o registrati.
Hai dimenticato l'e-mail di attivazione?

Accesso con nome utente, password e durata della sessione
 Notizia
VENITE A TROVARCI NELLA CHAT DI W.I.F.
- per organizzare partite ed incontri Ghigno  -
Ti aspettiamo!
Ricerca avanzata  
Pagine: [1]   Vai giù
  Stampa  
Autore Discussione: ENTER_HEX questo sconosciuto  (Letto 972 volte)
0 utenti e 1 Utente non registrato stanno visualizzando questa discussione.
Argesilao
Veterano delle Grandi Guerre
***
Scollegato Scollegato

Messaggi: 142



« inserita:: 16 Dicembre 2016, 20:43:25 »

Dunque, tutto nasce dall'idea di permettere a delle specifiche unità di piazzare delle trappole in un settore della mappa; quando una unità non appartenente al side che ha piazzato la trappola transita su quel settore si verifica un determinato accadimento; ora, il mio problema è il seguente:
Supponiamo che a una unità venga comandato di muoversi da un settore iniziale A ad un settore finale C, e che per eseguire questo comando transiti in un settore intermedio B con trappola;
codificando un evento in questa maniera:

[event]
    name=enter_hex
    first_time_only=no
    [allow_undo][/allow_undo]

    {verifica che l'unità transiti su un settore con trappola}

    {azione conseguente al passaggio dell'unità sulla trappola}

[/event]

succede che l'azione predisposta viene eseguita correttamente, quindi l'unità, continua a muoversi verso la destinazione finale.
Il mio problema consiste nell'evitare che questo avvenga, e che il transito dell'unità sulla trappola comporti anche l'annullamento dei movimenti successivi già predisposti.

Devo ora spiegare che una delle trappole ideate prevede che l'unità che vi transita sopra perda, per il turno corrente, la possibilità di compiere altre mosse e/o di attaccare, cosa che si ottiene facilmente modificando l'unità settando a 0 sia moves che attacks_left. Tutto avviene come previsto, ma quando inizia il turno successivo, e l'unità riacquista movimenti e attacchi, per prima cosa l'unità completa il comando di movimento che gli era stato impartito il turno precedente, cioè raggiunge il settore finale C.

Pietrificare l'unità al passaggio sulla trappola, e spietrificarla all'inizio del side turn successivo, potrebbe essere un'idea ed un ottimo sostituto, ma non sarebbe la stessa cosa perchè in questo caso l'unità non potrebbe difendersi dagli attacchi, e comunque non mi risolverebbe il problema nel caso la trappola preveda un altro tipo di azione, per esempio un bel fulmine che colpisse l'unità transitante sulla trappola; in questo caso, a seconda dell'entità dei danni subiti dall'unità, chi controlla il side potrebbe ritenere di non volere che quella unità completi il movimento che gli era stato comandato.

In pratica, c'è qualcuno che, nell'ambito di un event enter_hex sa come annullare parte del percorso predisposto per una unità (magari anche al di fuori di un evento enter_hex)?

Potrei usare un event moveto, ma non sarebbe la stessa cosa, anche se sarebbe una buona approssimazione.
Ho fatto una ricerca nella cartella delle campagne ufficiali di BfW 1.12.6, e ho trovato un solo scenario in cui era presente un event enter_hex, e non mi è stato di aiuto per questo problema specifico che potrebbe anche non avere una soluzione in linguaggio WML

Ringrazio fin da subito chi potrà darmi una dritta al riguardo, anche se il problema è più estetico che pratico avere la soluzione potrebbe aprirmi molte interessanti possibilità.
« Ultima modifica: 21 Dicembre 2016, 18:28:04 da Argesilao » Registrato

Quello che non ti uccide ti rende più menomato

Il caso non esiste, esiste solo l'inevitabile
(Yuko Ichihara)

Sai tu qual sia in questa nera valle la risultanza ed il premio di ogni sacrifizio umano? Calci nel deretano!
(Brancaleone da Norcia)
Elvish_Hunter
Moderatore globale
*****
Scollegato Scollegato

Messaggi: 673


Lo sviluppator cortese


« Risposta #1 inserita:: 19 Dicembre 2016, 17:40:17 »

Quando un'unità si muove la sua destinazione viene impostata nelle variabili $unit.goto_x e $unit.goto_y. Per verificarlo puoi semplicemente usare un tag [message] nell'evento, oppure puoi richiamare la finestra d'ispezione con [inspect][/inspect], per poter vedere tutte le variabili dell'unità. Così, basterà impostare a zero quelle due variabili, che sia tramite [modify_unit] o con un buon vecchio ciclo store_unit/set_variable/unstore_unit.
Dalla wiki:
Citazione
goto_x:, goto_y: the unit's current movement destination. Default is 0,0 i.e. the unit is not on a course.
Registrato

Manutentore corrente di The Sojournings of Grog, Children of Dragons, A Rough Life e Wesnoth Lua Pack.
The White Troll - topic ufficiale
Argesilao
Veterano delle Grandi Guerre
***
Scollegato Scollegato

Messaggi: 142



« Risposta #2 inserita:: 19 Dicembre 2016, 20:33:30 »

Quando un'unità si muove la sua destinazione viene impostata nelle variabili $unit.goto_x e $unit.goto_y. Per verificarlo puoi semplicemente usare un tag [message] nell'evento, oppure puoi richiamare la finestra d'ispezione con [inspect][/inspect], per poter vedere tutte le variabili dell'unità. Così, basterà impostare a zero quelle due variabili, che sia tramite [modify_unit] o con un buon vecchio ciclo store_unit/set_variable/unstore_unit.
Dalla wiki:
Citazione
goto_x:, goto_y: the unit's current movement destination. Default is 0,0 i.e. the unit is not on a course.

HO VISTO LA LUCE!  Sorriso

E avrei potuto vederla prima se non fossi stato così pigro da fermarmi agli UNIT DATA e avessi consultato anche gli UNIT STATE  Pianto

Per fortuna che Elvish Hunter è molto meno pigro di me  Ghigno

P.S. Bisognerebbe mettere a disposizione degli utenti più pigri l'emoticon adorante, oppure dedicare a Elvish Hunter una via o una piazza a Wesnoth, ma anche ad Elensefar potrebbe andare (niente monumenti però, costano!).


Registrato

Quello che non ti uccide ti rende più menomato

Il caso non esiste, esiste solo l'inevitabile
(Yuko Ichihara)

Sai tu qual sia in questa nera valle la risultanza ed il premio di ogni sacrifizio umano? Calci nel deretano!
(Brancaleone da Norcia)
Argesilao
Veterano delle Grandi Guerre
***
Scollegato Scollegato

Messaggi: 142



« Risposta #3 inserita:: 21 Dicembre 2016, 18:27:31 »

Ahimé, credevo fosse la luce, ma era solo una lucciola. Pianto

Il settaggio a 0 delle variabili goto_x e goto_y dell'unita funziona solo nel caso della trappola che azzera il movimento, cioè se viene settato a 0 anche il valore moves dell'unità che transita nel settore con trappola; nel suo turno successivo l'unità non riparte cercando di completare il comando di movimento impartitogli il turno in cui è incappata nella trappola; e fin qui è tutto nella logica.

Quello che non è nella logica è che se il valore moves non viene settato a 0 non c'è santo che tenga, niente, a parte la morte, pare impedire all'unità di compiere il proprio dovere, neppure il ciclo store_unit(con kill incluso)/set_variable(con settaggio a 0 dei valori goto_x e goto_y della variabile di stoccaggio)/unstore_unit; e questo, lasciatemelo dire, è decisamente sconcertante.

Per il momento modificherò il funzionamento della trappola fulminante con il settaggio a 0 dei movimenti rimasti, in fondo è ragionevole che un'unità fulminata da 50.000 volt non abbia tanta voglia di andare avanti  Occhi al cielo, ed avevo già pensato di modificare anche il funzionamento della trappola che azzera il movimento, anche se quella funziona come dovrebbe, per renderla più useful; ma il problema di fondo, seppure puramente intellettuale, rimane, insieme con le grandi domande dell'esistenza:
Come si fa a fermare un'unità senza necessariamente azzerare il valore moves?
Perchè l'azzeramento di goto_x e goto_y non è sufficiente?
Quali diaboliche forze ostili al progredire della conoscenza si aggirano nei meandri nascosti del WML, o più probabilmente del lua?
Dov'è che stò Argesilao ha fatto la ######## e perchè non si dedica all'allevamento dei canarini come passatempo?

Intanto che cerco dove ho messo la gabbia dei canarini allego, per il piacere dei più curiosi, o dei più masochisti, il frammento di codice incriminato.

Citazione
   [event]
      name=enter_hex
      first_time_only=no

               # in questa macros si definisce il valore di other_side_number, che è uguale a 1 se $side_number=2 ed è uguale a 2 se $side_number=1;
               # ciò serve ad impedire che un'unità subisca conseguenze dal passaggio su di una trappola disposta dal suo stesso side
      
      {OTHER_SIDE_VALUE}

      
      [allow_undo]
      [/allow_undo]

                # la variabile artifacts_list contiene tutti gli artifatti (trappole ed altro) che vengono creati; contiene tre valori: x, y e type
      
      {FOREACH artifacts_list i}
         [if]
            [variable]
               name=artifacts_list[$i].x
               equals=$x1
            [/variable]
            [and]
               [variable]
                  name=artifacts_list[$i].y
                  equals=$y1
               [/variable]
            [/and]
            [and]   
               [have_unit]
                  x,y=$artifacts_list[$i].x,$artifacts_list[$i].y
                  side=$side_number
               [/have_unit]
            [/and]
            [then]
               [switch]
                  variable=artifacts_list[$i].type
                  
                  # *** Entangle trap action ***
                  
                  [case]
                          value=$entangletrap_code[$other_side_number]

                     # visual and sound effects
                     
   
                     [sound]
                        name=entangle.wav
                     [/sound]
                     {PLACE_HALO $x1 $y1 "halo/elven/nature-halo[1~8].png:125"}
                     
                     # unit effects            
                     
                     {MODIFY_UNIT (x,y=$x1,$y1) moves 0}
                     {MODIFY_UNIT (x,y=$x1,$y1) attacks_left 0}
                     {MODIFY_UNIT (x,y=$x1,$y1) goto_x 0}
                     {MODIFY_UNIT (x,y=$x1,$y1) goto_y 0}
                     
                     {REMOVE_HALO $x1 $y1 "halo/elven/nature-halo[1~8].png:125"}
                     {PLACE_ITEM $x1 $y1 $entangletrap_image[$other_side_number]}
                  [/case]
                  
                  # *** Tunder trap action ***
                  
                  [case]
                     value=$thundertrap_code[$other_side_number]
                     
                     # visual and sound effects
                     
                     [sound]
                        name=lightning.ogg
                     [/sound]
                     {PLACE_HALO $x1 $y1 "halo/lightning-bolt-1-[1~4].png:150"}
                     
                     # damage effects
                     
                     {VARIABLE_OP damage rand "1..$thundertrap_damage"}
                     {REPEAT $thundertrap_attacks (
                        {VARIABLE_OP damage_add rand "1..$thundertrap_damage"}
                        {VARIABLE_OP damage add $damage_add}
                     )}
                     [harm_unit]
                        [filter]
                           x,y=$x1,$y1
                        [/filter]
                        amount=$damage
                        fire_event=yes
                        animate=yes
                        damage_type=fire
                     [/harm_unit]
                          {MODIFY_UNIT (x,y=$x1,$y1) moves 0} # aggiunta dopo, senza questa macro l'unità continua imperterrita la sua corsa
                     {MODIFY_UNIT (x,y=$x1,$y1) goto_x 0}
                     {MODIFY_UNIT (x,y=$x1,$y1) goto_y 0}
   
                     {REMOVE_HALO $x1 $y1 "halo/lightning-bolt-1-[1~4].png:150"}
                     {PLACE_ITEM $x1 $y1 $thundertrap_image[$other_side_number]}
                     
                  [/case]
                  
               [/switch]   
            [/then]   
         [/if]   
      {NEXT i}
      {CLEAR_VARIABLE i}
   [/event]

Domanda esistenziale aggiuntiva: visto che l'enter_hex è diventato marginale nella sostanza del problema, o almeno credo, forse sarebbe opportuno creare un'altra discussione del tipo: goto_x e goto_Y questi sconosciuti?

Caro Elvish Hunter, niente viale o piazza a tuo nome, dovrai accontentarti di un vicolo cieco  Ghigno
Registrato

Quello che non ti uccide ti rende più menomato

Il caso non esiste, esiste solo l'inevitabile
(Yuko Ichihara)

Sai tu qual sia in questa nera valle la risultanza ed il premio di ogni sacrifizio umano? Calci nel deretano!
(Brancaleone da Norcia)
Nicodema
Maestro di Battaglia
****
Scollegato Scollegato

Messaggi: 358


GRRRRRRRRRRRRR


« Risposta #4 inserita:: 22 Dicembre 2016, 08:02:13 »

Premetto che non so niente di WML.
Mi è venuta questa idea, magari sai come tradurla in codice.

Quando c'è la nebbia di guerra una unità si ferma quando "vede" nemici o alleati (compare anche un messaggio per avvisare il giocatore) e non perde il turno, ma restano i punti movimento che aveva ancora al momento dell'evento.

Se lo stesso riuscissi a fare quando l'unità finisce sulla trappola dovresti aver risolto...

Auguri
Registrato
Argesilao
Veterano delle Grandi Guerre
***
Scollegato Scollegato

Messaggi: 142



« Risposta #5 inserita:: 22 Dicembre 2016, 13:42:52 »

L'affare si complica.

Innanzi tutto ho scoperto che non è affatto necessario settare a 0 il valore moves dell'unità per ottenere il settaggio a 0 dei valori goto_x e goto_y
Nel momento in cui l'unità entra nella trappola i valori goto_x e goto_y risultano essere, per motivi sconosciuti al sottoscritto, -999 e -999

dopo le seguenti righe di codice (notare l'assenza di {MODIFY_UNIT (id=$unit.id) moves 0} )

   {MODIFY_UNIT (id=$unit.id) goto_x 0}
   {MODIFY_UNIT (id=$unit.id) goto_y 0}

   
il valore di moves, goto_x e goto_y risultano essere effettivamente il valore corretto delle mosse rimanenti, 0, 0   
 
Curiosità: se cercavo di ottenere queste informazioni con un messaggio di questo tipo (è lo stesso che ho usato per ricavare le informazioni iniziali dianzi dette, cioè quelle immediatamente successive all'entrata dell'unità nel settore con trappola e precedenti a qualunque effetto prodotto dalla trappola stessa)

messagio tipo A:

   [message]
      speaker=narrator
      message= _ " goto_x="+$unit.goto_x+" goto_y="+$unit.goto_y+" moves="+$unit.moves
   [/message]


mi dava, per goto_x,goto_y e moves gli stessi valori precedenti, cioè -999,-999, valore corretto delle mosse rimanenti

quando ho sostituito il messaggio tipo A con la procedura seguente

messaggio tipo B:

   [store_unit]
      [filter]
         x,y=$x1,$y1
      [/filter]
      variable=su   
   [/store_unit]
   [message]
      speaker=narrator
      message= _ " goto_x="+$su.goto_x+" goto_y="+$su.goto_y+" moves="+$su.moves
   [/message]
   {CLEAR_VARIABLE su}

   
mi ha dato, per goto_x, goto_y e moves, i valori 0, 0 e il valore corretto delle mosse rimanenti.
Aggiungo che quando ho sostituito il messaggio tipo A con il messaggio tipo B anche nella fase iniziale, cioè prima che la trappola esperisca qualunque effetto, i valori che ottenevo erano perfettamente identici.
Fine della curiosità.

Poichè $x1 e $y1 indicano la posizione sia della trappola che dell'unità che ci finisce sopra, l'unità stoccata in su è effettivamente quella finita nella trappola
Malgrado il settaggio a 0 di goto_x e goto_y l'unità, quando sparisce il messaggio, continua indifferente il suo movimento predisposto.
Per qualche oscuro motivo l'azzeramento della destinazione pare avere effetto solo nel turno successivo del side a cui l'unità appartiene.

A titolo di cronaca comunico che non ha sortito nessun effetto neppure settare goto_x e goto_y ai valori $x1 e $y1, cioè dire all'unità di raggiungere il settore in cui già si trova.

Parimenti inutili sono stati questi due tentativi:

   {MODIFY_UNIT (x,y=$x1,$y1) goto_x 0}
   {MODIFY_UNIT (x,y=$x1,$y1) goto_y 0}
   [store_unit]
      [filter]
         x,y=$x1,$y1
      [/filter]
      variable=stored_unit
      kill=yes      
   [/store_unit]
   [unstore_unit]
      variable=stored_unit
   [/unstore_unit]
   {CLEAR_VARIABLE stored_unit}

   
   [store_unit]
      [filter]
         x,y=$x1,$y1
      [/filter]
      variable=stored_unit
      kill=yes      
   [/store_unit]
   {VARIABLE stored_unit.goto_x 0}
   {VARIABLE stored_unit.goto_y 0}
   [unstore_unit]
      variable=stored_unit
   [/unstore_unit]
   {CLEAR_VARIABLE stored_unit}

   
Nulla pare scalfire la determinazione dell'unità a raggiungere l'obiettivo comandatogli, a parte la fine degli hp e dei movimenti consentitegli:
   
Nicodema, molto opportunamente, mi ha consigliato di andare a vedere come viene gestita questa cosa quando una unità ne vede un'altra di un'altro side spuntare dalla nebbia;
in quel caso, infatti, l'unità si arresta senza perdere tutti le sue mosse rimanenti. Purtroppo la cosa pare non essere gestita in wml, e quindi è al di fuori delle mie possibilità,
a meno che la mia infruttuosa ricerca non sia stata deficente in qualche modo.

Mi sorgono una serie di dubbi:
- Il punto del problema non è nei valori goto_x e goto_y dell'unità, ma allora dov'e?
- E se c'è è accessibile via WML?
- Mi sta sfuggendo qualcosa di banalissimo e semplicissimo (non sarebbe la prima volta)
- E' meglio allevare canarini da canto o di colore?
Registrato

Quello che non ti uccide ti rende più menomato

Il caso non esiste, esiste solo l'inevitabile
(Yuko Ichihara)

Sai tu qual sia in questa nera valle la risultanza ed il premio di ogni sacrifizio umano? Calci nel deretano!
(Brancaleone da Norcia)
Elvish_Hunter
Moderatore globale
*****
Scollegato Scollegato

Messaggi: 673


Lo sviluppator cortese


« Risposta #6 inserita:: 22 Dicembre 2016, 22:39:05 »

Codice:
[event]
name=enter_hex
first_time_only=no

               ...

{MODIFY_UNIT (x,y=$x1,$y1) moves 0}
{MODIFY_UNIT (x,y=$x1,$y1) attacks_left 0}
{MODIFY_UNIT (x,y=$x1,$y1) goto_x 0}
{MODIFY_UNIT (x,y=$x1,$y1) goto_y 0}
Tanto per iniziare, usare $x1 e $y1 in un evento enter_hex è una pessima idea: e se l'esagono fosse già occupato, che accade? Ce lo spiega la wiki:
Citazione
Note: This event behaves a bit unusually if the hex is occupied (and the moving unit is simply passing through). When this happens, $x1,$y1 is still the hex where the event was triggered, but the moving unit (stored in $unit) will be located somewhere earlier in the route (the most recent unoccupied hex). That is, $x1,$y1 will not equal $unit.x,$unit.y (a condition that can be used to detect when the entered hex is occupied). The moving unit will have already spent its movement points to enter the event's hex even though it is has not actually moved from the most recent unoccupied hex.
Quindi in questo evento bisogna sempre fare riferimento a $.unit.x e $unit.y, oppure - per evitare ogni tipo di confusione - a $unit.id.
Citazione
Nel momento in cui l'unità entra nella trappola i valori goto_x e goto_y risultano essere, per motivi sconosciuti al sottoscritto, -999 e -999
Di solito, mi ritrovavo -999, -999 nel file stderr quando un qualche filtro non riusciva a trovare un'unità: se riesci ad accedere all'stderr e ci trovi qualche messaggio anomalo, potrebbe essere utile.
Ad ogni modo, questo evento estremamente basilare funziona: l'ho testato poco fa  Occhiolino
Codice:
[event]
name=enter_hex
first_time_only=no

[filter]
x,y=18,18 # l'esagono dov'è la trappola
[/filter]

[modify_unit]
[filter]
id=$unit.id
[/filter]
goto_x,goto_y=0,0
[/modify_unit]
[/event]
Registrato

Manutentore corrente di The Sojournings of Grog, Children of Dragons, A Rough Life e Wesnoth Lua Pack.
The White Troll - topic ufficiale
Argesilao
Veterano delle Grandi Guerre
***
Scollegato Scollegato

Messaggi: 142



« Risposta #7 inserita:: 23 Dicembre 2016, 18:00:47 »

Cominciamo con le buone notizie:
   L'azzeramento dei valori goto_x e goto_y, in seguito all'attivazione di un evento enter_hex, per arrestare il movimento di una unità effettivamente funziona come ci si dovrebbe aspettare!
E questa è una buona notizia perchè è uno strumento che può risultare molto utile ai programmatori wml. Sorriso

Continuiamo con le cattive notizie:
   Nel mio specifico evento enter_hex l'azzeramento dei valori goto_x e goto_y non ha l'effetto sperato. Imbarazzato

Così mi sono domandato:
   Cosa ha di sostanzialmente differente l'evento basilare fornito da Elvish Hunter rispetto al mio, una volta sfrondato quest'ultimo degli orpelli e degli effetti speciali? Che?!?
In sostanza c'era ben poco, e tra quel poco l'occhio è subito caduto su: [allow_undo][/allow_undo]
Infatti inserendo il tag allow_undo nell'evento di Elvish Hunter pure in questo l'azzeramento di goto_x e goto_y non arresta il movimento dell'unità.
Dov'è il problema? Si chiedera qualcuno, levalo anche tu!
Il problema è che il tag allow_undo ho dovuto inserirlo per evitare che il movimento delle unità venisse interrotto ogni volta che una di queste entrava in un qualunque settore, e questo lo spiega anche la wiki

Citazione
    If this event is handled without using [allow_undo], then movement is interrupted, stopping the unit where it is.

in sostanza le unità si muovevano di un settore alla volta, perchè ogni qualvolta entravano in un settore partiva il controllo che nel settore non fosse presente una trappola, e questo controllo, per qualche motivo,
cancellava il movimento successivo predisposto per l'unità (paradossalmente era una specie di azzeramento non voluto delle variabili goto_x e goto_y dell'unità); da qui la necessità di inserire il tag allow_undo.

Da quanto ho capito, sempre consultando la wiki, il tag allow_undo impedisce la cancellazione delle azioni precedenti l'attivazione di un evento,
sicchè, quando è mancante, settando a zero goto_x e goto_y e mancando la memoria delle istruzioni precedentemente compiute l'unità si adegua all'azzeramento della destinazione, e si arresta.
richiamando il tag allow_undo all'interno dell'evento, invece, rimane la memoria delle istruzioni precedentemente impartite, e l'unità le esegue malgrado l'aggiornamento di goto_x e goto_y.

Finiamo con le buone notizie:
   Quindi, per poter eliminare il tag allow_undo senza avere movimenti a un passo alla volta ho provato ad aggiungere un filtro all'inizio dell'evento, così strutturato, che, oltretutto, mi permette di eliminare alcuni controlli all'interno dell'evento, attenendomi al processo logico per il quale cui tentare non costa nulla

   [filter]
      [filter_location]
         find_in=artifacts_list
      [/filter_location]   
   [/filter]

   
(Per la cronaca artifacts_list sarebbe il contenitore di tutti gli artefatti, e qindi anche delle trappole, che vengono create sulla mappa, ed è caratterizzato da tre indici: x,y,type)

E tutto funziona come dovrebbe! Cinque righe di codice che potevano risparmiarmi cinque ore di tribolazioni! E le avevo anche pensate fin dall'inizio, ma non ero sicuro che il find_in avrebbe funzionato con un contenitore che conteneva altri indici oltre a x e y, e così preferii andare sul sicuro (sic) e gestire la cosa con un abominevole controllo (vedere post precedenti) Scioccato
   
Alla fine il problema non stava nell'evento enter_hex, né nelle variabili goto_x,goto_y   e neppure nel tag allow_undo, ma nella maniera perversa in cui il sottoscritto aveva combinato le tre cose.

Ringrazio tutti coloro che hanno contribuito alla discussione guidandomi verso il felice compimento dell'impresa, e l'ente anonimo amici del canarino insiste per unirsi ai ringraziamenti.
Alcune questioncelle rimangono insolute (vedi caso curioso post precedente), ed a dire la verità non ho nemmeno capito perfettamente perchè adesso funziona tutto, ma poichè tutto funziona (insomma), poichè si tratta di argomenti che non hanno rilevanza pratica (speriamo) ed i misteri aggiungono sale alla vita (anche se troppo sale fa male alla pressione), meglio lasciarle così.

Elvish Hunter ti meriteresti il monumento, ma ho speso tutto per i regali di natale!  Ghigno
Registrato

Quello che non ti uccide ti rende più menomato

Il caso non esiste, esiste solo l'inevitabile
(Yuko Ichihara)

Sai tu qual sia in questa nera valle la risultanza ed il premio di ogni sacrifizio umano? Calci nel deretano!
(Brancaleone da Norcia)
Elvish_Hunter
Moderatore globale
*****
Scollegato Scollegato

Messaggi: 673


Lo sviluppator cortese


« Risposta #8 inserita:: 27 Dicembre 2016, 23:39:24 »

Elvish Hunter ti meriteresti il monumento, ma ho speso tutto per i regali di natale!  Ghigno
Se proprio ci tieni, puoi sempre farmi un monumento virtuale, inserendo da qualche parte nello scenario un Elfo Cacciatore pietrificato, proprio come nello scenario multiplayer Caves of the Basilisk Ghigno
Scherzi a parte, sono contento che ora funzioni tutto Fico
Registrato

Manutentore corrente di The Sojournings of Grog, Children of Dragons, A Rough Life e Wesnoth Lua Pack.
The White Troll - topic ufficiale
Pagine: [1]   Vai su
  Stampa  
 
Vai a: