Spero che troviate presto la soluzione


Ottima idea quella di unificare il codice uguale e simile.


Ho capito. In realtà l'idea mi piace, solo che non mi piace l'idea di dover usare il cursore dell'indirizzo per entrare. Sarebbe bello se se si fa clic al di fuori del riquadro di uscita, l'eroe girasse intorno al riquadro di uscita e quando si fa clic sul riquadro, uscisse.

L'idea di utilizzare i cursori per l'output non mi dispiace affatto, ma un semplice clic del mouse sarebbe perfetto.



Sì, lo sapevo, per questo ho proposto un codice per renderlo solo visivo. Il vero utilizzo sarebbe quello di dare effetti ladder nelle missioni, come avviene nell'espansione kellar tower.

Credo che tu abbia dimenticato di inserire il codice per il test.


Non uso affatto le frecce direzionali, tranne che per la missione del castello misterioso.

neanch'io troppo ma sono utili per capire dove puoi andare quando usi "attraversa la roccia"


Credevo usassi l'exe dentro al mio pacchetto. Oppure vuoi modificare il tuo?


Lo so. vero.
ma il pathfinding verifica prima i click del mouse, perché se il punto è un oggetto impassabile come mobili o mostri allora salta tutto il calcolo di ricerca percorso (sarebbe inutile, tanto non potrebbe arrivarci). Dopo di che fa lo stesso controllo ma pert TUTTE le caselle possibili su cui l'eroe può camminare (comprese le scale).
Ricordi il trucco del click sulla trappola che non faceva partire il pathfinding? Era qui in questo codice.
Quindi le scale possono essere:
1- sempre cliccabili e calpestabili dal patfinding (come ora)
2- Non cliccabili ma calpestabili dal patfinding (come erano le trappole)
3- Sempre calpestabili con le frecce (perché ti ricordo che sono due codici separati).



La realtà è che mi diverte tantissimo ottimizzare il codice, e poi ho tanta paura di finire lo spazio nella zona grossa che ho trovato tempo fa.

Una ottimizzazione che faccio spesso è questa: i programmatori spesso usano questa logica condizionale (semplifico: in assembly se un Controllo non viene soddisfatto, semplicemente il codice passa alla riga dopo):



quello che faccio io è ribaltare la logica condizionale, risparmiando spesso dai 3 ai 4 byte ad ogni Controllo:




Il vantaggio della prima logica è la flessibilità, perché permette una gestione più complessa dei casi, mentre la mia versione è più restrittiva. Ma di solito posso permettermelo.

Mira que guapo.

 ezgif_1_9695ff1164.gif ( 667.51k ) Numero di download: 1


Se vuoi provarlo (sul mio QUEST.EXE): 0x333D 40 --> 37

Oppure provare il pathfinding 1/3 sul tuo exe:


guarda quanti bei 90...

Naturalmente, in questo modo posso approfittare dell'opportunità di testare la mia versione spagnola.


Questo è il codice della prima fase di 3?

Messaggio modificato da raul il 26 Nov 2024, 21:03

no, solo il modo per aggirare le scale.
ho editato il messaggio sopra con tutto il codice.

Come ho detto prima, ho sentimenti contrastanti riguardo a questo codice: da un lato mi va bene aggirare la tessera di uscita cliccando su una tessera all'interno della stanza, ma dall'altro trovo poco intuitivo usare le frecce direzionali per uscire.

In realtà, non sarebbe una cattiva idea usare di più le frecce direzionali, ma mi piace e preferisco la comodità di cliccare sulla tessera di uscita per uscire dal dungeon.

Un codice perfetto sarebbe quello di poter cliccare con il mouse su una tessera e, a seconda della destinazione, effettuare o meno la deviazione verso la tessera di uscita.

Messaggio modificato da raul il 27 Nov 2024, 06:24

Ok, implementerò il codice nella mia versione spagnola e lo testerò. Devo solo verificare che il comportamento di movimento degli eroi sia quello normale, compreso l'incantesimo di attraversamento delle pareti.


Non ti capisco.

Messaggio modificato da raul il 27 Nov 2024, 06:24

è esattamente quello che ho pensato io. Difatti meglio non implementarlo.
Del resto ho già messo lo scroll di conferma in uscita.

non si può, a meno di stravolgere ancora di più quello attuale. Non ne vale la pena.

Esattamente.

90 è l'opcode per nop (no operation), il codice che uso quando voglio liberare lo spazio. Come vedi nel codice sopra gli ultimi 62 byte sono nop. E' lo spazio che ho liberato a seguito dell'ottimizzazione del pathfinding, per aggiungere in futuro nuovo codice.

Ho definitivamente risolto la ricerca nei corridoi quando i mostri cambiano stanza nativa. Ho posizionato la scrittura della stanza nel punto in cui si trova effettivamente il mostro.




Non ti spaventare sulla quantità di byte da cambiare. La ragione è che ho sposstato codice di tre byte indietro e quindi cambianotutti i riferimenti:

Per quanto ho potuto giocare questa mattina tutto era perfetto, non ho notato alcun cambiamento, continuerò con i test.


Ok, ora ha senso. Il traduttore l'aveva interpretato come anni '90.


Sei il migliore... E lo sai.

Ottimo, fantastico.

Non mi sono scordato del tuo punto 20. E' solo più complicato di quanto pensassimo.

Non preoccupatevi, fate quello che ritenete più opportuno, non voglio che vi bruciate con così tanto codice da ammalarvi alla fine.
È vero che vorrei finire di sistemare i testi nel file .bin.

Nel frattempo, continuo a testare il nuovo codice e tutto funziona bene, non ci sono cambiamenti nei movimenti degli eroi. Continuerò a giocare finché non avrò completato tutte le missioni.

Dovrei avere terminato anche le fasi 2/3 e 3/3 per l'attraversamento dei mostri con "veil of mist".
Forse entro oggi riesco a mettere insieme le istruzioni per fartelo provare, raul.

Ho un solo problema da risolvere: devo fare in modo che l'effetto di veil of mist non si resetti alla fine del turno dei mostri, altrimenti un barbaro o un nano non potranno mai ottenere il movimento furtivo, ma solo l'invisibilità per un turno.

Bene bene, quando sarà pronto, tornerò a fare altri test, come al solito.
Puoi usare parte del codice per migliorare il movimento dei nemici in modo che non si blocchino a vicenda?

Messaggio modificato da raul il 30 Nov 2024, 10:56

No, non c'entra quella parte. Ho modificato solo il movimento dell'eroe.

Sto però convincendomi che quel comportamento mi piace. Anche Nyerguds suggeriva che in fondo è bello che non tutti i mostri inseguano, e che alcuni rimangano a pattugliare i corridoi.
Del resto, il treno di mostri non è così tatticamente divertente.

Per carità, ho visto un utente blu, come è possibile?

Il problema non è il comportamento nel corridoio, il problema è nelle stanze, che rimangono ferme e non attaccano.

Messaggio modificato da raul il 30 Nov 2024, 13:17

quello sarà difficile. Molto difficile.

Quello blu è il gruppo UST, un vecchio gruppo di traduzioni di cui gharlic fa parte.

Per questo ho detto che se riusciamo a far passare i mostri l'uno attraverso l'altro, si spera che quando si avvicinano all'eroe e non sono bloccati da un altro mostro, non rimangano così statici nelle stanze.

Quando e se il movimento mostri verrà completamente cambiato si può pensare di implementarlo. Al momento non è possibile perché non c'è motivo
Tutto sommato come ho già detto mi piace che i mostri rimangano nelle stanze a presidio. Se il mostro non si sposta verso l'eroe che si posiziona sulla porta, il giocatore non ha la possibilità di scambiarsi di posto con un altro eroe e attaccare quindi il mostro due volte, impedendo a Morcar di entrare nella stanza o attaccare con più di un mostro.
Se invece il mostro rimane nella stanza quel trucco odioso non si può attuare.

Non devi vederli "statici", ma "stragegici". A me piace molto.

Ho messo a punto il codice che permette agli eroi di attraversare i mostri quando sotto l'effetto di "Velo di Nebbia" (Veil of Mist).

Il codice ha richiesto la rielaborazione di 3 blocchi per l'aggiunta del controllo dell'incantesimo e dell'eliminazione del suo effetto. Oltre alla verifica di tutte le caselle calpestabili dall'eroe in due modalità, pathfinding (click col mouse) e passo-passo (frecce direzionali)

I blocchi:
1- patfinding dell'eroe, aggiunta caselle mostro nel calcolo del percorso possibile
2- accensione e spegnimento delle frecce di movimento in base alle condizioni
3- animazione ed effettivo spostamento dell'eroe

tutti questi codici li ho dovuti ripetere x4, ma ho colto l'occasione per compattarli ed unificarli in un'unica call 2f8e

esempio abilitazione freccia direzionale LEFT


esempio nuovo codice per solo animazione LEFT


call 2f8e unica:

questa è stata simpatica perché per variare le condizioni di salto indietro (ret) diversa per le due routine (frecce e animazione) ho dovuto manipolare lo stack (l'ultima operazione dove aggiungo 16 byte alla memoria puntata dallo stack pointer) per farla ritornare al punto in cui dovevo.

 Screenshot_2024_11_30_185238.png ( 32.85k ) Numero di download: 0




codice frecce direzionali:
 ezgif_6_fb2347b97a.gif ( 1.68mb ) Numero di download: 3

Beh, questo è un argomento molto diverso da quello di cui sto parlando, e possiamo discuterne quando volete, anche se vi sto dicendo che quello che vorrei è che i nemici entrino nelle stanze e non che ne escano.

Quello di cui parlo è quando si è già in una stanza. Vi faccio un esempio.

Nella stanza in cui si raccoglie la lama dello spirito, se l'eroe si trova in un angolo, ci sono nemici che non si avvicineranno all'eroe anche se hanno abbastanza movimento e un posto dove attaccare. Probabilmente è perché un altro mostro “blocca” l'accesso, per questo dico che se si fa in modo che i mostri si superino a vicenda, è possibile che questa “IA” venga migliorata.

Messaggio modificato da raul il 30 Nov 2024, 19:10

In origine era già così, non è stato necessario apportare modifiche.

Messaggio modificato da raul il 30 Nov 2024, 19:46