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.
22 Agosto 2017, 23:24:56 *
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 [2]   Vai giù
  Stampa  
Autore Discussione: Mappa torneo 2014  (Letto 3278 volte)
0 utenti e 1 Utente non registrato stanno visualizzando questa discussione.
Uesmae
Eroe del Reame
*****
Scollegato Scollegato

Messaggi: 1418


Fu Bardo...è Vagabondo. Tituli:Vinto1torneo(n.u).


« Risposta #15 inserita:: 08 Novembre 2014, 01:34:21 »

nessun frequentatore del forum è in grado di realizzare mappe adeguate
Uesmae, ovviamente questa è solo una mia opinione personale.

Tranquillo Mich! Io infatti avevo cercato di "specificare" che "a prima vista" la tua poteva apparire un'affermazione più che personale..."presuntuosa"! Ma col presupposto che in realtà non era così. 

forse l'ha scritto più per una questione di "voler essere modesto" che altro e senza volere mancare di rispetto alla comunità...

Più che per intendersi io e te, era "per gli altri". Non me ne frega di fare battibecchi per sugo di nulla...e poi oh, se ti mandiamo in esaurimento qui è un casino...sicchè è preferibile di preservarti in salute!  Ghigno  Stò a scherzà...  Occhiolino

Ritengo comunque che l'unica differenza nei nostri punti di vista sia solo il livello di qualità richiesto. Sebbene creare una mappa sia una "cosa per tutti", e che può anche regalare soddisfazioni e divertimento al creatore, ritengo che crearne una per una partita multigiocatore (per era standard) con un buon bilanciamento sia molto più impegnativo e complicato che realizzare campagne, ere o cose strane. Ma alla fine sono solo punti di vista.

Nel merito della qualità richiesta, ciascuno di noi ha un personale metro di giudizio. Non è facile per gli utenti "mettersi in gioco" (soprattutto quelli "inesperti") e oltretutto farlo con una mappa con la quale potrebbero non avere "affinità" (pure alcuni di quelli "esperti"). La sua prerogativa più importante ritengo debba essere che gli utenti siano "contenti" di giocarci...  Sorriso  ...ma io sono "contento" indipendentemente dalla mappa!  Ghigno  Per il resto oh, è capace nemmeno il Padreterno sia in grado d'accontentare tutti, sicchè...
 
Per come la vedo io...

Citazione di: opinioni personali
- La mappa standard nella sua "semplicità" è complicata perchè va bilanciata perbene in quanto deve possedere un equilibrio e all'occorrenza una certa "velocità", inoltre va strutturata per 2 o più giocatori umani con (di solito) le 6 le fazioni default e i dettagli c'hanno un loro peso. Ipotizzando già da prima le "situazioni" che potrebbero verificarsi in battaglia, c'è da posizionare i territori e in seguito fare dei tests per "ritoccare" qua e là! Un pochino alla volta, finchè ce n'è di bisogno...

- La campagna va calibrata su livelli di difficoltà differenti ma le mappe è pure possibile di "raffazzonarle" un pò, perchè tanto vengono giocate contro l'ai...però c'è dietro tutto un "lavoro" di trama, wml (ed eventualmente "scenografico" se viene aggiunto qualche disegnino) che tarabaralla la "fatiga" è la stessa (anzi, alla fine dei conti...risulta essere di più! E' un pò meno difficoltoso il bilanciamento, ma c'è da considerare tutto il resto e comunque a bilanciare una campagna di "lavoro" ce ne vuole).

- L'era è il "lavoro" che si mangia più tempo in assoluto, perchè oltre al bilanciamento c'è la parte grafica che sembra una "bischerata" e invece non lo è...poi ogni unità della fazione ha da venire "concepita" da zero, non solo coi disegnini ma altresì col wml e le fazioni vanno bilanciate fra loro (dunque è il "lavoro" più impegnativo e soprattutto per quanto concerne il bilanciamento).

- Gli "scenari strani" dipende da quanto è strana la stranezza delle "dinamiche" degli stessi e quindi dalle "meccaniche" (più o meno particolari) che ci stanno per lo mezzo (e il bilanciamento diciamo "classico" va in un certo senso "adattato" o addirittura "reinterpretato", perchè la "mappa strana" per risultare giocabile va impostata tramite delle modalità "non convenzionali").

...sono delle mie opinioni personali eh!  Sorriso  Non equivochiamo...perlopiù che la questione a seconda delle proprie "attitudini" potrebbe rivelarsi persino soggettiva. 

La proposta falchi è molto interessante se il torneo dovesse giocarsi sulla 1.12, e probabilmente sarebbe anche l'unità più adatta.
Nel caso 1.12 inoltre bisogna valutare l'integrazione delle nuove unità del califfato tra le unità reclutabili.
Nel caso di giocare il torneo su 1.10 credo sia meglio restare su unità mainline. Quindi dal mio punto di vista tutto dipende dalla data di uscita della 1.12.

Tenete presente che il "nostro" server potrebbe funzionare con la 1.10 e non con la 1.12 (a meno che non venga fatto un aggiornamento), quindi per giocare col falco artigliato su un braccio si dovrebbe poi andare a giocare sul server internazionale...per me è uguale, vedete un pò voi.

Anzi, già che avete "degli spunti tecnici" per migliorare ulteriormente lo scenario vi lascio più volentieri "lavorare"...se e quando avrete a disposizione un'altra versione della mappa "messa a punto", ci sarà quella lì per fare i tests.  Sorriso  Altrimenti c'è questa qui.

Mi faccio un "giretto" in un altro topico!  Sorriso  Buon proseguimento...
« Ultima modifica: 08 Novembre 2014, 17:00:09 da Uesmae » Registrato

Il potere asserve i suoi servi, non mi serve...abbisogno d'una visione comune d'insieme.
ego potest non summa "Chi ha troppa fretta e poco tempo farebbe meglio a non leggere quel che scrissi."
Nobun
Moderatore Globale e Vincitore Torneo di Singolare 2011
*
Scollegato Scollegato

Messaggi: 692


Negromante elementale del Vento


« Risposta #16 inserita:: 08 Novembre 2014, 21:02:37 »

Intervengo su alcuni punti della discussione (come vedrete io concordo pienamente con mich)

Con riguardo alla difficoltà di sviluppare mappe MP bilanciate.
Sono d'accordo con quello che ha detto mich. Ma, onde evitare fraintendimenti, quello che si vuole dire è che creare una buona mappa multiplayer bilanciata per tutte le fazioni è qualcosa di molto molto arduo, forse la cosa più difficile da fare.
Ci sono tante di quelle cose da considerare (ad esempio una mappa molto piccola favorirebbe alcune fazioni, una molto grande ne favorirebbe altre) che è una impresa a dir poco titanica da intraprendere. Quindi il fatto è che non è tanto una questione di capacità degli utenti, quanto proprio una questione di difficoltà intrinseca che rende estremamente estremamente difficile PER CHIUNQUE riuscire a creare una mappa multiplayer bilanciata. Io non ci proverei nemmeno a svilupparne una Felice

Con riguarda al filtraggio delle unità.
Come dice mich (ma come ha anche detto Elvish) credo che l'unico metodo per ottenere una cosa simile è utilizzare il menù del tasto destro, con combinazioni di abilitazioni/disabilitazioni di reclutamenti.
Io come unica soluzione possibile (e abbastanza gestibile) vedrei l'aggiunta di un menù contestuale (id est, utilizzabile cliccando il tasto destro del mouse) "filter recruits" ("filtra i reclutamenti") con i seguenti sottomenu:
"tutte le unità"
"lealisti"
"nani e fuorilegge"
"non-morti"
"orchi, trolls e ogre"
"pesci"
"elfi"

Da questa bozza, però, mancherebbe dove collocare l'unità "sauro incursore" (che non saprei bene dove inserire, visto che sarebbe nella fazione "draghi" e non ha elementi che lo assocerebbe ad una delle altre categorie da me individuate).
Potrebbe interessare anche inserire la possibilità di reclutare il clasher, l'unico drago che non vola (e quindi... perché escluderlo? xD)
Eventualmente vagliare la possibilità di inserire anche "Khalifate" (non che mi entusiasmi l'idea, visto che sono eticamente contrario a quella fazione xD) in un menù apposito (esclusi eventuali volanti, salvo il "reclutamento speciale").

Ovviamente potrebbe essere interessante anche un diverso tipo di differenziazione da questa da me ora ipotizzate.
Fatemi sapere cosa ne pensate.
Registrato



A VOLTE ATTIVO, A VOLTE NO
mich
Moderatore globale
*****
Scollegato Scollegato

Messaggi: 921



« Risposta #17 inserita:: 03 Aprile 2015, 07:28:23 »

Ho aggiornato la mappa nell'area download. Ora funziona su wesnoth 1.12 (in realtà funzionava anche prima).
Sono state effettuate un paio di modifiche rispetto alla versione precedente, in particolare è stata ridimensionata l'area chat e l'unità volante reclutabile è ora il falcone.
Inoltre è stato risolto un bug riguardante l'unità volante aggiuntiva (se ne poteva reclutare una seconda se la prima avanzava di livello).

Testate e commentate.
Registrato
Elvish_Hunter
Moderatore globale
*****
Scollegato Scollegato

Messaggi: 674


Lo sviluppator cortese


« Risposta #18 inserita:: 07 Maggio 2015, 10:50:44 »

Finalmente ho avuto la possibilità di fare qualche test sulla mappa, e mi sono accorto di alcune cose da sistemare.
1) wmlscope si lamenta del fatto che alcune macro siano definite più volte. Si può risolvere in due modi: o spostando le macro comuni alle due varianti dello scenario in un file a parte, oppure rendendo le macro locali ai file tramite la direttiva #undef.
2) Il codice della macro WIF_MAGIC_SOURCE può essere aggiornato per utilizzare la sintassi compatta delle animazioni:
Codice:
#define WIF_MAGIC_SOURCE X Y
    [item]
        x={X}
        y={Y}
        halo=halo/illuminates-aura.png
        centered=yes
    [/item]

    [item]
        x={X}
        y={Y}
        centered=yes
        halo="halo/elven/ice-halo[1~9].png:150"
    [/item]

    {WIF_SET_LABEL (_"Magic Source") {X} {Y}}
#enddef
3) Visto che il tag [item], quando usato in un evento, supporta pienamente lo StandardUnitFilter, invece di usare ripetutamente la macro PLACE_IMAGE e permettere che il preprocessor infarcisca il codice di tag [item], si può aggiornare la macro WIF_PLACE_MAP_ITEMS così (almeno nella nuova versione dello scenario):
Codice:
#define WIF_PLACE_MAP_ITEMS
    [item]
        x=10,10,14,14,10,10,14,14,28,28,32,32,28,28,32,32
        y= 5, 7, 5, 7,22,24,22,24, 5, 7, 5, 7,22,24,22,24
        image=scenery/monolith3.png
    [/item]
    [item]
        x= 1, 1,41,41
        y=14,16,14,16
        image=scenery/nest-empty.png
    [/item]

    {WIF_MAGIC_SOURCE 3 6}
    {WIF_MAGIC_SOURCE 3 24}
    {WIF_MAGIC_SOURCE 17 15}
    {WIF_MAGIC_SOURCE 25 15}
    {WIF_MAGIC_SOURCE 39 6}
    {WIF_MAGIC_SOURCE 39 24}
#enddef
4) Esiste un motivo per cui usiamo la macro WIF_LIMIT_FALCONS_RECRUITS invece della macro di mainline LIMIT_CONTEMPORANEOUS_RECRUITS o LIMIT_RECRUITS?
5) Una cosa di cui non mi ero accorto quando avevo aggiornato la mappa qualche anno fa, era che nell'evento della vittoria tattica non servono sei tag [have_unit], ma ne basta uno solo:
Codice:
   [event]
        name=moveto

        [filter]
            x=3,3,25,39,17,39
            y=6,24,15,6,15,24
        [/filter]

        [filter_condition]
            [have_unit]
                x=3, 3,25,39,17,39
                y=6,24,15, 6,15,24
                side=$unit.side
                count=6
            [/have_unit]
        [/filter_condition]

        {WIF_ANNOUNCE_TACTICAL_WINNER $unit.side}

        [endlevel]
            save=yes
            carryover_report=no
        [/endlevel]
    [/event]
6) Bug: così com'è strutturata, la macro WIF_TELEPORT_ACTION non permette ai giocatori di teletrasportare accidentalmente le proprie unità nel vuoto: qualora non sia specificata nel tag [store_unit], la chiave check_passability è automaticamente impostata su yes, il che impedisce di perdere le unità.
7) Pensando di alleggerire il carico di lavoro del gioco (impilare una lunga serie di macro VARIABLE_OP è un ottimo modo per aumentare le dimensioni dei salvataggi e di rallentare Wesnoth), ho provato a convertire in Lua il codice per il calcolo dell'esagono preciso dove teletrasportare l'unita. Facendo questo, mi sono accorto che con la nuova mappa gli offset non corrispondono più ai vortici, quindi vanno corretti. Inoltre, ho capito bene che l'idea alla base è che le caselle vengano analizzate in senso orario per due vortici, e in senso antiorario per gli altri due? E da quali esagoni si dovrebbe partire esattamente per analizzarli?

PS: ho approfittato dell'occasione per fare un po' di pulizia degli sticky, rimuovendo quelli relativi al Torneo 2013/2014 (tutti i thread hanno comunque un link nel topic relativo ai tornei passati), così il forum è già pronto per ospitare quelli nuovi relativi al Torneo 2015.
« Ultima modifica: 07 Maggio 2015, 11:00:34 da Elvish_Hunter » Registrato

Manutentore corrente di The Sojournings of Grog, Children of Dragons, A Rough Life e Wesnoth Lua Pack.
The White Troll - topic ufficiale
mich
Moderatore globale
*****
Scollegato Scollegato

Messaggi: 921



« Risposta #19 inserita:: 07 Maggio 2015, 16:47:36 »

Ciao Elvish.
Rispondo brevemente ad alcuni punti.
1)Hai ragione. Le macro sono praticamente tutte doppie. Colpa mia, ho volto mettere nella stessa estensione anche la vecchia versione dello scenario, senza pensare alle conseguenze....
2), 3), 5). Lo scenario è passato per molte mani, e molte versioni di wesnoth. In passato avrei voluto cambiarne alcune parti per rendere il codice più leggibile/migliore, ma ho sempre preferito lasciare quello che già esisteva (e funzionava) com'era. Inoltre anche per quanto ho aggiunto io negli anni sicuramente avrò usato codici migliorabili, specie per le ultime cose inserite. Considera che la prima versione dello scenario è stata realizzata da Dret per 1.2 se ben ricordo. Oggi ci portiamo ancora dietro alcune parti di codice realizzate allora. Credo che l'unico che abbia tentato di rendere leggermente più leggibile il codice sia stato Nobun qualche anno fa quando è stato reimplementato il codice per i vortici.
4) Si. La versione passata usava una di quelle due macro, ma questa non era adeguata allo scopo. So bene che quella macro è penosa, scritta velocemente e male, ma dovrebbe funzionare a dovere. Se comunque trovi il modo per fare la stessa cosa in maniera più semplice sentiti libero di modificare. Le macro menzionate non vanno bene perché purtroppo non è possibile filtrare sulla razza o su più unità. Quando il falcone evolve poi se ne può reclutare un altro, e questo non è adeguato a quanto volevo realizzare. Inoltre è stata aggiunta la parte con l'evento die che non è presente per qualche motivo nelle macro menzionate.
6) Ai tempi Nobun aveva riscritto il codice per i vortici e sembrava tutto funzionasse a dovere. Su 1.12 sinceramente non ho provato.
7) È possibile abbia sbagliato qualche coordinata quando ho ridimensionato la mappa. Per il resto puoi partire dall'esagono che vuoi per il calcolo, l'importante è che i due giocatori si trovino nella stessa condizione (per questo due vortici "girano" in un senso e gli altri due nell'altro).
Se ben ricordo il codice attuale parte sempre dall'esagono sopra a quello del vortice, ma potrei sbagliare.

Grazie per i test e per le eventuali modifiche.
Registrato
Elvish_Hunter
Moderatore globale
*****
Scollegato Scollegato

Messaggi: 674


Lo sviluppator cortese


« Risposta #20 inserita:: 07 Maggio 2015, 20:06:41 »

4) Si. La versione passata usava una di quelle due macro, ma questa non era adeguata allo scopo. So bene che quella macro è penosa, scritta velocemente e male, ma dovrebbe funzionare a dovere. Se comunque trovi il modo per fare la stessa cosa in maniera più semplice sentiti libero di modificare. Le macro menzionate non vanno bene perché purtroppo non è possibile filtrare sulla razza o su più unità. Quando il falcone evolve poi se ne può reclutare un altro, e questo non è adeguato a quanto volevo realizzare. Inoltre è stata aggiunta la parte con l'evento die che non è presente per qualche motivo nelle macro menzionate.
Meno male che ho chiesto Fico Non ero proprio a conoscenza di questo comportamento (che in una campagna normale di solito non viene notato).
6) Ai tempi Nobun aveva riscritto il codice per i vortici e sembrava tutto funzionasse a dovere. Su 1.12 sinceramente non ho provato.
Non so su che versione abbia provato Nobun, ma è anche possibile che il problema fosse semplicemente passato inosservato: infatti si verifica solo quando tutti gli esagoni nelle vicinanze del vortice sono pieni, quindi una situazione che in una partita normale non accade praticamente mai. Fino alla 1.8 (mi pare) check_passability non esisteva, quindi il problema è sulle versioni dalla 1.10 in poi.
7) È possibile abbia sbagliato qualche coordinata quando ho ridimensionato la mappa. Per il resto puoi partire dall'esagono che vuoi per il calcolo, l'importante è che i due giocatori si trovino nella stessa condizione (per questo due vortici "girano" in un senso e gli altri due nell'altro).
Se ben ricordo il codice attuale parte sempre dall'esagono sopra a quello del vortice, ma potrei sbagliare.

Grazie per i test e per le eventuali modifiche.
Un errore capita a tutti Sorriso Comunque, per queste ed eventuali altre modifiche future, cosa ne dite (e qui mi rivolgo anche a Nobun e a chiunque altro voglia mettere mano allo scenario) se creo una repository su GitHub o BitBucket, in modo da poter finalmente gestire gli aggiornamenti con un sistema di controllo versione?
Registrato

Manutentore corrente di The Sojournings of Grog, Children of Dragons, A Rough Life e Wesnoth Lua Pack.
The White Troll - topic ufficiale
Nobun
Moderatore Globale e Vincitore Torneo di Singolare 2011
*
Scollegato Scollegato

Messaggi: 692


Negromante elementale del Vento


« Risposta #21 inserita:: 09 Maggio 2015, 07:05:47 »

Posso rispondere solo relativamente alle osservazioni sul teletrasporto, tra quelle emerse.

Il codice "madre" l'avevo scritto io, ed è poi stato rivisitato da mich e da me onde effettuarne alcuni miglioramenti... la versione "madre" era stata testata da me (nella 1.8, se non ricordo male) anche con l'evento "caduta nel vuoto", e mi pareva che l'evento funzionasse. Però non escludo di aver fatto un test fallace, perché all'epoca la maggior parte dei test la feci coi grifoni e solo sporadicamente con unità non volanti (quindi è possibile che la versione madre definitiva già contenesse quel problema).... anche se onestamente mi ricordavo di aver usato un tag [have_unit] sulle coordinate poi valutate tra CETL_CHECK e non un check_passability per verificare se le caselle fossero piene o vuote, però ci sta che ricordi male Linguaccia

Devo fare alcune precisazioni, però:
1) nel codice madre, di locazioni nel vuoto CETL_CHECK ce ne erano 3 piazzate male (solo ai fini di testing) mentre mich ha provveduto a specificare delle locazioni più coerenti nel gioco
2) I test più massivi li ho fatti coi grifoni (mea culpa) quindi ci sta che, nelle varie modifiche che abbiamo fatto al codice "madre" (che non è mai stato giocato nel torneo ufficiale) sia stato modificato qualcosa che ha fatto sì che l'evento "caduta nel vuoto" non funzionasse più a dovere
3) l'altra modifica che sicuramente ha fatto mich da solo (e che è impossibile che sia la causa del problema) è aggiungere un prefisso "WIF_" a tutto il sistema di macro che avevo creato (principalmente per il riprogrammato evento di teletrasporto... per renderlo più leggibile, visto l'ammontare di codice)

Sul punto 7 sollevato da Elvish, agganciandomi alla risposta di mich, confermo che l'ordine delle apparizioni è quello descritto da mich... si parte dall'alto (in tutti i casi) e poi si ruota nella direzione più vicina alle fonti del lato in questione. Quindi se si passa da un vortice collocato a sinistra per arrivare ad un vortice collocato a destra -> si parte dall'alto e si ruota in senso orario
Nel caso contrario si parte dall'alto e si ruota in senso antiorario

NOTA: ovviamente le coordinate CETL_CHECK vengono specificate in ordine INVERSO rispetto all'ordine in cui devono funzionare

Personalmente mi trovi favorevole all'idea di usare un sistema di controllo versione... ci sta che sia la buona volta che impari ad usarne uno Felice
anche se, realisticamente, è difficile che vi possa dare una mano
« Ultima modifica: 09 Maggio 2015, 07:11:46 da Nobun » Registrato



A VOLTE ATTIVO, A VOLTE NO
Elvish_Hunter
Moderatore globale
*****
Scollegato Scollegato

Messaggi: 674


Lo sviluppator cortese


« Risposta #22 inserita:: 09 Maggio 2015, 10:44:02 »

Il codice "madre" l'avevo scritto io, ed è poi stato rivisitato da mich e da me onde effettuarne alcuni miglioramenti... la versione "madre" era stata testata da me (nella 1.8, se non ricordo male) anche con l'evento "caduta nel vuoto", e mi pareva che l'evento funzionasse.
Ecco dove sta l'inghippo Linguaccia Dal changelog:
Codice:
Version 1.9.5:
 * WML engine:
   * [unstore_unit] now accepts a fire_event= key to control firing of
     (post) advance events and a check_passability= (default yes, previously
     it was always no/non-existent) key controlling whether to check for
     suitable terrain when placing units
Se il codice funzionava bene sulla 1.8, questa modifica intervenuta nel ciclo di sviluppo 1.9 ha fatto sì che il comportamento del codice fosse alterato sulla 1.10 - cosa che era sfuggita anche a me. Dovrò aggiungere check_passability=no, tutto qua. Era impossibile usare questa chiave sulla 1.8, semplicemente perché non esisteva ancora Occhiolino
Citazione di: Nobun
3) l'altra modifica che sicuramente ha fatto mich da solo (e che è impossibile che sia la causa del problema) è aggiungere un prefisso "WIF_" a tutto il sistema di macro che avevo creato (principalmente per il riprogrammato evento di teletrasporto... per renderlo più leggibile, visto l'ammontare di codice)
Pensavo che il prefisso fosse stato aggiunto perché, visto che tutti gli add-on multiplayer condividono lo stesso #ifdef MULTIPLAYER, esiste il rischio concreto che un altro add-on, il quale abbia delle macro denominate allo stesso modo, possa sovrascrivere le nostre macro.
Citazione di: Nobun
Sul punto 7 sollevato da Elvish, agganciandomi alla risposta di mich, confermo che l'ordine delle apparizioni è quello descritto da mich... si parte dall'alto (in tutti i casi) e poi si ruota nella direzione più vicina alle fonti del lato in questione. Quindi se si passa da un vortice collocato a sinistra per arrivare ad un vortice collocato a destra -> si parte dall'alto e si ruota in senso orario
Nel caso contrario si parte dall'alto e si ruota in senso antiorario

NOTA: ovviamente le coordinate CETL_CHECK vengono specificate in ordine INVERSO rispetto all'ordine in cui devono funzionare
Bene, grazie delle conferme Sorriso . Ora potrò provare a revisionare il codice.
Citazione di: Nobun
Personalmente mi trovi favorevole all'idea di usare un sistema di controllo versione... ci sta che sia la buona volta che impari ad usarne uno Felice
anche se, realisticamente, è difficile che vi possa dare una mano
Il sistema di controllo che useremo sarà Git, visto che creerò la repository su GitHub - avrei potuto crearla anche su BitBucket, ma la differenza è che su BitBucket le repo con più di cinque utenti sono a pagamento, mentre su GitHub sono a pagamento le repo private. Il nostro codice non ha bisogno di essere privato, quindi la scelta è ovvia Ghigno
Appena l'avrò creata e avrò inserito le mie modifiche, vi informerò, in modo da potervi aggiungere come collaboratori.
Registrato

Manutentore corrente di The Sojournings of Grog, Children of Dragons, A Rough Life e Wesnoth Lua Pack.
The White Troll - topic ufficiale
Nobun
Moderatore Globale e Vincitore Torneo di Singolare 2011
*
Scollegato Scollegato

Messaggi: 692


Negromante elementale del Vento


« Risposta #23 inserita:: 09 Maggio 2015, 12:22:38 »

Citazione
Pensavo che il prefisso fosse stato aggiunto perché, visto che tutti gli add-on multiplayer condividono lo stesso #ifdef MULTIPLAYER, esiste il rischio concreto che un altro add-on, il quale abbia delle macro denominate allo stesso modo, possa sovrascrivere le nostre macro.
Il motivo è stato effettivamente quello. Solo che nella primissima versione il prefisso non c'era (non almeno sulle mie macro) e mich ha sottolineato l'opportunità di aggiungere il prefisso per evitare il rischio da te sottolineato Occhiolino [io invece non avevo proprio pensato a tale eventualità]

Ok rimaniamo in attesa di tue indicazioni, allora. Immagino ci si debba iscrivere a github... xD
Poi ti chiederò delle delucidazioni su come si lavora correttamente con github (i tool da usare, e le buone pratiche).... non ho mai usato questi sistemi, essendo abituato da solo... è una buona occasione per imparare Occhiolino
« Ultima modifica: 09 Maggio 2015, 12:24:10 da Nobun » Registrato



A VOLTE ATTIVO, A VOLTE NO
Elvish_Hunter
Moderatore globale
*****
Scollegato Scollegato

Messaggi: 674


Lo sviluppator cortese


« Risposta #24 inserita:: 10 Maggio 2015, 10:53:39 »

Ok rimaniamo in attesa di tue indicazioni, allora. Immagino ci si debba iscrivere a github... xD
Ovviamente Occhiolino La repository si trova qui: https://github.com/Elvish-Hunter/WIF-Tournament. Ho provveduto a inserire tutte le modifiche che avevo proposto, quindi testate anche voi e fatemi sapere Fico
Chi volesse l'accesso in scrittura (penso te, mich e Dret), dopo essersi registrato mi faccia sapere il suo nome utente su GitHub, così posso aggiungerlo all'elenco dei collaboratori.
Poi ti chiederò delle delucidazioni su come si lavora correttamente con github (i tool da usare, e le buone pratiche).... non ho mai usato questi sistemi, essendo abituato da solo... è una buona occasione per imparare Occhiolino
Io uso git da riga di comando, ma qualche volta uso anche l'interfaccia grafica gitk. Come su SVN, bisogna cercare di mantenere i commit piccoli e relativi ad un solo argomento; ma con git è più facile, perché il commit e il push si fanno in due fasi diverse, mentre su SVN il commit invia immediatamente i dati al server.
Esattamente come su SVN, per apportare modifiche bisogna clonare la repository in locale (comando git clone - funziona sia tramite HTTPS che SSH, ma in questo caso dovrete crearvi una chiave RSA), poi si usano git add per aggiungere nuovi file, git rm per cancellare file e git commit -m per confermare le modifiche allegando un messaggio di commit. git push infine invia i dati al server, mentre git pull recupera gli ultimi aggiornamenti dalla repo (questo a sua volta è una combinazione dei comandi git fetch e git merge).
Inoltre, chi non avesse l'accesso in scrittura, o chi l'avesse ma non fosse sicuro delle modifiche, oltre che scrivere sul forum può anche effettuare una pull request, ovvero clonare la repo nel proprio account GitHub, modificarla e usare il comando pull request dal sito web: in questo modo, chi ha l'accesso in scrittura può decidere se unirla al codice principale o richiedere altre modifiche.
Infine, è anche possibile avere diversi branch (rami) del codice, ma per ora ne abbiamo uno solo (master). Si possono anche creare dei tag corrispondenti alle versioni con il comando git tag.

EDIT: con i commit odierni (http://git.io/vUBcL e http://git.io/vUBcz) ho convertito il codice per il calcolo delle coordinate del teletrasporto al Lua, soltanto nella nuova versione dello scenario. Non ho ancora provveduto a correggere le eventuali caselle sbagliate (è intenzionale che il codice non teletrasporti unità dove ci sono i monoliti?), ma si vede a occhio nudo che è molto più rapido; non solo, anche l'intero scenario sembra molto più rapido. Magari è solo una mia impressione... Linguaccia
« Ultima modifica: 11 Maggio 2015, 16:58:39 da Elvish_Hunter » Registrato

Manutentore corrente di The Sojournings of Grog, Children of Dragons, A Rough Life e Wesnoth Lua Pack.
The White Troll - topic ufficiale
Dret
L'Occhio sopra di Voi!
Amministratore
*****
Scollegato Scollegato

Messaggi: 1288



« Risposta #25 inserita:: 21 Maggio 2015, 18:58:21 »

Ragazzi non entro in merito alla discussione tecnica che lascio a voi.

Vi sottolineo però che al momento non ci sono stati test per la versione nuova dello scenario.

Ergo, se entro la fine di Maggio le cose rimangono in questo stato, dovremmo usare lo scenario classico.

Quindi magari conviene prevedere questa eventualità.

Registrato

Non fatevi prendere dal Panico!!
Ghigno
Nobun
Moderatore Globale e Vincitore Torneo di Singolare 2011
*
Scollegato Scollegato

Messaggi: 692


Negromante elementale del Vento


« Risposta #26 inserita:: 22 Maggio 2015, 08:33:13 »

Citazione
EDIT: con i commit odierni (http://git.io/vUBcL e http://git.io/vUBcz) ho convertito il codice per il calcolo delle coordinate del teletrasporto al Lua, soltanto nella nuova versione dello scenario. Non ho ancora provveduto a correggere le eventuali caselle sbagliate (è intenzionale che il codice non teletrasporti unità dove ci sono i monoliti?), ma si vede a occhio nudo che è molto più rapido; non solo, anche l'intero scenario sembra molto più rapido. Magari è solo una mia impressione...
Avevo intenzione, se avessi trovato il tempo di farlo, di provare a fare io lo stesso lavoro, proprio pensando al fatto che il codice lua (che supporta le funzioni) sarebbe stato più veloce rispetto all'attuale sistema di macro (che ingrossa molto il codice) anche se, all'epoca, inevitabile.
Ottimo il fatto che ci abbia pensato tu (una garanzia)... ne approfitterò per vedere come hai implementato il codice lua Felice
Comunque sì, la scelta di non usare gli spuntoni è intenzionale (è stata una scelta mia) che è stata dovuta essenzialmente a tre ragioni.
1) avendo riguardo all'ordine di apparizione "ufficiale". Le unità normalmente appaiono in un certo ordine (intendo... quando non c'era il codice apposito che correggesse l'ordine di rotazione in modo da non essere impari) e, secondo quell'ordine, la prima casella utile utilizzata a caselle di terreno piene (esclusi i 4 spuntoni) era una casella vuota. Quindi ho semplicemente voluto assicurare che, una volta piene le 7 caselle di base (Quella di vortice più le 6 attorno), le unità terrestri cadessero nel vuoto
2) diversamente facendo le caselle terreno prima della "caduta nel vuoto" da 7 passerebbero ad 11. Già con 7 caselle è un fatto piuttosto improbabile che si arrivi a riempirle tutte ed attivare la caduta nel vuoto. Se si passasse ad 11 caselle l'evento diventerebbe una probabilità troppo infima per aver senso ed essere mantenuta a livello di codice
3) per una questione di "impatto grafico". A me quei monoliti danno l'idea di spuntono (quasi delle stalagmiti) difficilmente raggiungibili se non arrivandoci "fisicamente", e non tramite un evento di teletrasporto. Non so se sono riuscito a spiegare, ma questa terza è più forse legata al mio gusto personale.

Citazione
Ragazzi non entro in merito alla discussione tecnica che lascio a voi.

Vi sottolineo però che al momento non ci sono stati test per la versione nuova dello scenario.

Ergo, se entro la fine di Maggio le cose rimangono in questo stato, dovremmo usare lo scenario classico.

Quindi magari conviene prevedere questa eventualità.
In realtà qualche test fu fatto, al di fuori del torneo ufficiale, lo scorso anno.
Io stesso feci una o due partite (quando però l'evento del reclutamento aereo prevedeva il pipistrello ed era ancora da sistemare) però non avrei modo di recuperare i replay perché ci giocai quando avevo il vecchio pc (quello con windows xp) che ormai è stato formattato (ci ho messo su un lubuntu sperando di renderlo utilizzabile in caso di necessità.... ormai con XP si impallava anche a pc appena formattato).

Non so se mich sarebbe in grado di recuperare i replay delle partite che aveva giocato.
Temo che in questo periodo si trovano a fatica i volontari per i test. Io stesso fino a luglio sono troppo inguaiato per fare test di sorta.
Registrato



A VOLTE ATTIVO, A VOLTE NO
Elvish_Hunter
Moderatore globale
*****
Scollegato Scollegato

Messaggi: 674


Lo sviluppator cortese


« Risposta #27 inserita:: 24 Maggio 2015, 21:16:59 »

Citazione di: Nobun
Comunque sì, la scelta di non usare gli spuntoni è intenzionale (è stata una scelta mia) che è stata dovuta essenzialmente a tre ragioni.
Bene. Per evitare futuri equivoci, aggiungerò un commento all'interno dello scenario, in modo che chi lo dovesse modificare in futuro sappia che non è un errore Occhiolino
Citazione
Temo che in questo periodo si trovano a fatica i volontari per i test. Io stesso fino a luglio sono troppo inguaiato per fare test di sorta.
Non posso garantire nulla, ma se riesco a trovare il tempo cercherò di testare le modifiche presenti su GitHub in qualche partita MP (finora le ho testate sia in partita locale, sia con due istanze di Wesnoth, ma sempre sullo stesso computer).
Inoltre, mi sono appena accorto che sulla 1.12 anche gli eventi prestart e start sono sincronizzati, non è quindi più necessario usare l'evento side 1 turn 1: ecco un'altra modifica che dovrò aggiungere Linguaccia

EDIT: ho sostituito l'evento turn 1 con prestart e start: http://git.io/vkadN
« Ultima modifica: 30 Maggio 2015, 20:37:29 da Elvish_Hunter » 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 [2]   Vai su
  Stampa  
 
Vai a: