Warning: Creating default object from empty value in /membri/bancaldo/wp-content/plugins/paged-comments/paged-comments.php on line 31
bancaldo™ » VideoGames

Archivio

Archivio per la categoria ‘VideoGames’

NDS: Kernel e MoonShell per R4 Revolution

16 aprile 2009 Commenti chiusi

SOFTWARE

Scaricare il Kernel R4 da qui.

KERNEL per SD High Capacity, qui.

Scaricare il MoonShell da qui.

Kernel R4

All’interno dell’archivio appena scaricato, ci sono 2 files e 2 directories:

Copiarli dentro la SD.

Fatto!

MOONSHELL

all’interno dell’archivio, ci sarà anche il dpgtools che contiene il convertitore di file.avi (dpgenc.exe).

Per aggiornare il moonshell, o reinstallarlo da capo, bisogna eliminare dalla SD, il file

_DS_MSHL.NDS

e la cartella

MOONSHL

Dopodichè, una volta scompattato l’archivio precedentemente scaricato, lanciare il SETUP.exe

– Scegliere ENGLISH

– Puntare al dispositivo SD in questione (quindi attenzione se si hanno più dispositivi collegati)

– Lasciare le impostazioni di default, premere ALL CLEAR e selezionare solo R4TF R4.

Premere Setup.

Nella SD troveremo un file R4TF R4(DS) – Revolution for DS.nds, che rinomineremo _DS_MSHL.nds e la solita directory moonshl.

Fatto!

DPGENCODER

lanciare il tool (dpgenc.exe)

Con Opzioni, si possono modificare alcuni parametri:

Con sfoglia si sceglie il percorso di destinazione.

Con un drag&drop, trascinare il file.avi da convertire.

Al termine della codifica, nel percorso precedentemente scelto, si otterrà un file.dpg che basterà inserire nella SD come una comune ROM.

Per poter vedere il frutto della conversione si usa dpgshow.exe

Per aver informazioni sul file: dpginfo.exe

Categorie:VideoGames Tag:

TFC > FoxBot scripting

28 settembre 2007 Commenti chiusi

Questa guida, trae spunto dal Foxbot Scripting Tutorial.
(Originale reperibile su Foxbot.net, sito al momento non attivo)

INTRODUZIONE
Lo scripting è fondamentale quando all’interno della mappa, ci sono obbiettivi multipli.
Un esempio pratico lo si ha caricando la mappa OPENFIRE.
Il bot non può sapere che prima di recarsi nella FlagRoom, deve disabilitare i laser.
Se si esegue un waypoint classico, il bor andrà dritto alla bandiera, morendo ogni volta sui laser che la proteggono.
Per questo sono stati implementati i Point1, Point2 da associare al waypoint.
Questi Point, vengono gestiti da un file script, che viene caricato insieme alla mappa.
Sempre riferendoci ad Openfire, potremo così associare al waypoint situato sul pulsante che disabilita il laser, il Point1, mentre al waypoint che sta nella flagroom nemica, il Point2.
Lo script conterrà questo tipo di informazioni:

1. Ad inizio mappa, mantieni attivo il Point1 e non attivare il Point2
2. Quando il laser è disattivato, attiva il Point2 e disattiva il Point1.

Così facendo, ad inizio mappa, tutti i bot si recheranno a disattivare i laser, quando questi saranno “giù”, andranno a prendere la bandiera.
Questo vale per ogni obbiettivo multiplo (l’esempio dei laser, mi sembrava calzante).

Fondamentale per poter usare gli script, è che all’interno della mappa, l’evento che scatena una successiva azione (deattivazione dei laser), sia messaggiato (triggering).
Questo per poter associare a tale messaggio, una successiva azione.

Esempi di trigger, possono essere, sia i messaggi a video, tipo “ Blue grate destroyed”, sia suoni successivi ad azioni (WAV di deattivazione allarmi, leser ecc.)

Per poter intercettare tali trigger, è bene lavorare in modalità DEBUG, quindi per prima cosa, da console:

bot_debug on

attivato il debugging, appariranno a video una miriade di messaggi.
Si tratta di captare quello che ci serve.
Nel nostro caso specifico, la deattivazione dei laser.

Per comodità, è bene catturare alcuni screenshot dell’evento, questo perchè quando creeremo lo script dell’evento, dovremo fare attenzione a richiamare esattamente il trigger, facendo attenzione a minuscole e maiuscole, essendo lo script case-sensitive.

bind f12 screenshot

CATTURA DELL’EVENTO
Per semplificare la cattura dell’evento, non ci devono essere bot nella mappa e possibilmente in modalità waypointing OFF (ovvero non caricare il file waypoints.cfg).
Questo per non riempire la console di messaggistica inultile al nostro scopo.

1. SETUP
La mappa deve avere già il waypoint impostato e sopratutto i command point assegnati nei punti critici, che riguardano lo script.
I tags Commandpoint, sono la parte fondamentale dello scripting.

Regola fondamentale.
UN WAYPOINT SENZA COMMANDPOINT ASSOCIATO, DAL BOT E’ SEMPRE CONSIDERATO ATTIVO.
Così possiamo associare un commandpoint ad ogni waypoint, che vogliamo rendere non attivo, nella mappa stessa. I Waypoint che sono sempre attivi, non devono avere nessun commandpoint associato.

2. Sezione on_startla prima parte di uno script, è la sezione on_start
Questa sezione è attiva appena la mappa viene caricata ed è utilizzata per inizializzare tutti i commandpoint assegnati.

Vediamo ora i comandi essenziali dello scripting

color_available_pointx

pointx disponibile per la squadra specifica (color: Blue o Red)

color_notavailable_pointx

pointx non disponibile per la squadra specifica (color: Blue o Red)

color_available_only_pointx

pointx disponibile per la squadra specifica e tutti gli altri commandpoint non disponibili.

Esempio

on_start
{
blue_available_point1
red_available_point2
}

Questo script, significa che alla partenza della mappa, il commandpoint 1 per i BLU e il commandpoint 2 per i RED, saranno attivi.

Regola fondamentale
DI DEFAULT, TUTTI I COMMANDPOINTS SONO DISATTIVATI, PERTANTO NON OCCORRE DICHIARARLI TALI.
3. AGGIUNGERE UN TRIGGER
il “on_msg triggers” è la parte principale dello script.

un esempio di script, legato ad un msg_trigger è:

6.jpg

on_msg(#cz_bcap1)
{
blue_notavailable_point1
red_available_point1
}

Le istruzioni vanno sempre inserite all’interno delle parentesi graffe.
L’es. Riguardava le istruzioni che vengono eseguite quando i blu segnano il punto, nella mappa CZ2.

Per rintracciare il messaggio che ci serve, aprire la console, e:

bot_debug on

I messaggi che appaiono tra parentesi, sono quelli che posso utilizzare per lo scripting.

Es. Relativo alla mappa WELL:

Se vogliamo che succeda qualcosa, quando la grata viene abbattuta, in modalità debug, devo andare ad abbattere la grata con il demolitore piazzando il detpack, e fare attenzione al messaggio che appare alla fine del conto alla rovescia e subito dopo la deflagrazione.

Nel nostro caso, il messaggio è:
#well_bgrate_destroyed
Nota:
i messaggi che hanno davanti #, sono reperibili nel file titles.txt.
Cercando la voce “well_bgrate_destroyed” vediamo che coincide con l’evento “Blue’s GRATE has been destroyed.”. Questo fa si che il messaggio in console, appaia solo al verificarsi di quel dato evento.
Una volta trovato il messaggio univoco, possiamo decidere che accada quello che vogliamo, ad es. Rendere attivo un altro command point.

NOTA: non tutte le mappe hanno messaggi scriptabili. Ci sono mappe che usano lo stesso messaggio per più azioni differenti, come passaggi che si aprono e chiudono ripetutamente. In questo caso il messaggio non può essere utilizzato. Per queste situazioni ci si appoggia allo scripting avanzato (scripting system expands).

SCRIPTING DI BOTTONI
È’ l’esempio già citato di OPENFIRE, voglio vedere innanzitutto se il trigger del pulsante, e scriptabile.
In modalità debug, quando premo il pulsante, vedrò il seguente messaggio:

4.jpg
Il messaggio, appare appena premuto il pulsante.
Devo controllare però, che ci sia un messaggio diverso, quando il pulsante torna alla posizione originale, ovvero quando i laser tornano attivi.

In molti casi (WELL: la porta che entra nella base avversaria) quando premi il pulsante, lo stesso torna immediatamente nella posizione originale, ma la commutazione non coincide con la reale apertura della porta.
In questo caso non posso rendere quel trigger scriptabile, inquanto il messaggio di commutazione OFF del pulsante, non rappresenta accuratamente l’azione di chiusura dellaporta.
Per accertare questo, in open fire, premo il pulsante per abbassare i laser, mi dirigo alla flag room e osservo l’istante in cui tornano i laser attivi. Se questo momento coincide con il messaggio di commutazione del trigger-pulsante, allora questa azione è scriptabile.

Questo è ciò che accade in openfire:

5.jpg
Le prime righe mostrano il messaggio di quando ho premuto il pusante.

msg (target rtrigger2, toggle 0)
Quando i laser ritornano attivi ricevo il messaggio
(target rtrigger2, toggle 1)
il quale mi dice che i laser si sono riattivati proprio mentre il trigger-pulsante commutava.
Perfetto! Posso creare lo script dove avrò all’ avvio della mappa, attivo solo il cpoint del pulsante, e non attivo il cpoint della bandiera. Una volta premuto il pulsante, i due cpoint si invertiranno di stato e lo rifaranno quando i laser-pulsante, ricommuteranno a loro volta.

SCRIPTING SOUNDS
Si può utilizzare come evento, anche l’esecuzione di un file sonoro.
Anche se con più difficoltà, inquanto di solito, un file sonoro, viene utilizzato per distinguere un evento indistintamente dalla squadra (cattura della bandiera).
Es.
on_msg(buttons/spark3,wav)
meglio utilizzarli come ultima spiaggia.

ALTRI COMANDI DI SCRIPT
Ci sono parecchi comandi utilizzabili per il controllo dei triggers:

If_color_pointx
Esempio

if_blue_point7
{
red_notavailable_point6
blue_available_point6
}

in questo caso, controlla se il point7 e attualmente disponibile per la squadra blue. In tal caso esegue i comandi specificati. Altrimenti non succede niente.

NOTA:
Tutti i comandi devono essere all’interno dell’argomento on_msg

on_msg(#italy_you_secure_cp3)
{
blue_notavailable_point1
blue_notavailable_point2
blue_notavailable_point3
blue_available_point4
red_notavailable_point1
red_notavailable_point2
red_notavailable_point3
red_available_point4
if_blue_point7
{
red_notavailable_point6
blue_available_point6
}
}

Notare come tutto sia all’interno delle parentesi. Notare anche come ci sia, solo un operatore IF e come sia posizionato alla fine dell’argomento on_msg, prima della parentesi di chiusura.
Il fatto che l’operatore IF si possa mettere SOLO in fondo, determina anche che se ne possa usare solo uno, all’interno dell’on_msg.
Nel caso venga eseguito lìIF, dopo di esso non ci saranno più comandi, comunque!

TESTARE LO SCRIPT
Ci sono un paio di cose da usare per testare il proprio script.
Digitando

Available

Vedremo una lista di tutti i command point e del loro stato, in quel momento.
Altro cosa da notare: in modalità DEBUG, se i messaggi sono seguiti da ***, vuol dire che lo script è stato caricato correttamente.

Notare nella figura precedente, la linea:

no if target rtrigger2, toggle 1 *** target rtrigger2 toggle 1
si notano due comandi separati dai ***. Vuol dire che lo script ha intercettato il trigger, e messo in azione il codice dello script stesso.

Se notiamo solo un messaggio, e non ***, significa che lo script contiene delle imperfezioni.

ATTENZIONE, lo script è CASE SENSITIVE!Ricordarsi di scrivere il messaggio all’interno dello script, esattamente come appare in console. Per questo è comodo l’utilizzo degli screenshots.

Quando si testa lo script, per prima cosa è bene accertarsi che lo stesso, intercetti il trigger che vogliamo utilizzare.
Poi inseguito, metteremo tra parentesi, i comandi che vorremo eseguire.

FAQ
D: Lo script non viene caricato!R: se durante l’intro della mappa, notiamo un messaggio che dice: “your script isn’t loading”:
1) Assicurarsi che lo script si trovi nella giusta directory: /half-life/foxbot/tfc/scripts2) Manca all’interno dello script, nua parentesi, oppure ce ne sono troppe
3) Nello script, non ci vogliono SPAZI dopo on_msg.
4) All’inizio dello script, non dimenticare la sezione on_start.
5) Controllare la sintassi dei comandi
6) Assicurarsi di aver salvato lo script, e di aver rilanciato la mappa!
7) Il file di script deve avere il suffisso “_fb” ad es. la mappa casbah avrà lo script casbah_fb.cfg.

D: Lo script non intercetta il messaggio!R: Ricordarsi di mettere il messaggio all’interno dello script, esattamente come appariva in console. Compreso andare a capo!

Es. Di script di Shutdown2

//shutdown2 script

on_start
{
blue_attack
red_attack
blue_available_only_point3
red_available_only_point1
}
on_msg(RED SECURITY IS DOWN

ACCESS TO RED FLAG IS AVAILABLE!)
{
blue_available_only_point4
}
on_msg(BLUE SECURITY IS DOWN

ACCESS TO BLUE FLAG IS AVAILABLE!)
{
red_available_only_point2
}
on_msg(RED FLAG ACCESS:

DENIED!)
{
blue_available_only_point3
}

on_msg(BLUE FLAG ACCESS:

DENIED!)
{
red_available_only_point1
}

on_msg(RED FLAG ACCESS:

10 SECONDS REMAINING...)
{
blue_available_point3
}

on_msg(BLUE FLAG ACCESS:

10 SECONDS REMAINING...)
{
red_available_point1
}

è buona abitudine trarre spunto dagli script già esistenti e sicuramente funzionanti.

Bancaldo.

Categorie:VideoGames Tag:

TFC > FoxBot waypointing

27 settembre 2007 Commenti chiusi

NOZIONI DI BASE PER IL WAYPOINTING
Questa guida, trae spunto dal Waypoint Tutorial 2.5.
(Originale reperibile su Foxbot.net, sito al momento non attivo)

INSTALLAZIONE FOXBOT e COMANDI
io ho installato il FoxBot v0.697
Possiamo trovare quello che ci serve qui.

Diamo per scontata la conoscenza dei bots e dei waypoint.
Iniziamo con l’installazione del magico Foxbot.
Durante l’installazione, scegliere come percorso /Half-Life.
Riassumiamo i comandi fondamentali di FoxBot da console (attivabile premendo | “pipe”)

Addbot 1 1

aggiunge un Bot nella squadra BLU categoria SCOUT

Addbot 1 2

aggiunge un Bot nella squadra BLU categoria SNIPER

Addbot 2 3

aggiunge un Bot nella squadra ROSSA categoria SOLDIER
…..
numericamente parlando, le categorie sono:

1.scout
2.sniper
3.soldier
4.demoman
5.medic
6.HWGuy (cannoniere)
7.Piro
8.Spy/Agent
9.Engineer

volendo aggiungere Nome e Skill (livello di abilità) al bot:

addbot 1 1 Pirla 1

aggiungeremo il Bot “Pirla” nella squadra BLU con abilità al massimo (1 massimo, 5 minimo)

per eliminare i bot:

kick pirla

quando si vuole eliminare un bot specifico

kickall

quando si vogliono eliminare tutti.

Altri comandi

Botskill 1

Setta il valore “skill” (abilità) a 1 di default

Botsdontshoot 1

il bot non spara, utile per il test del waypoint.
Con valore 2 si riporta il bot alla normale funzione.

WAYPOINTING
Per creare un WP, dobbiamo attivare da console il tool di waypointing.
Nella directory Half-life/Tfc, creiamo un file di testo Waypoints.cfg dove all’interno, incolleremo le seguenti istruzioni:

bind "INS" "waypoint add"
bind "DEL" "waypoint delete"
bind "END" "waypoint save"
bind "HOME" "waypoint load"
bind "i" "waypoint info"
bind "m" "waypoint menu"
bind "PGUP" "pathwaypoint_connect on"
bind "PGDN" "pathwaypoint_connect off"
bind "5" "pathwaypoint create1"
bind "6" "pathwaypoint create2"
bind "7" "pathwaypoint remove1"
bind "8" "pathwaypoint remove2"

pathwaypoint_connect off
waypoint on
pathwaypoint on

bot_debug on

come si deduce:

per inserire un waypoint premere INSper eliminare un waypoint premere DELper salvare il WAYPOINT (inteso come file) FINE….
pathwaypoint_connect on/off per abilitare/evitare l’auto-collegamento tra waypoint, percorrendoli.

ovviamente essendo un binding di tasti, può essere personalizzato facendo attenzione però a non andare in conflitto con i comandi di gioco.

Ora lanciamo TFC, Multiplayer, partita via Lan, e lanciamo la mappa sulla quale vogliamo creare il WP.
Nel mio caso BIGDEE, mappa della quale ho cercato disperatamente il WP, fino a che non mi sono arreso e ho deciso di crearmelo da solo.
Per comodità, cominceremo creando il percorso della squadra blu.
Apriamo la console e lanciamo il cfg prima creato con:

exec waypoints.cfg

Entriamo come scout blu.

Ora non ci sono molte regole da seguire, bisogna solamente creare i percorsi, una squadra alla volta, il più puliti possibile. Infine si testano.
E’ importante non piazzare numerosi waypoints (le tappe del percorso), laddove si possono semplificare le cose. Più semplice è il percorso del bot, e meno problemi avrà lo stesso, a percorrerlo.
Quando testeremo la mappa con i bot, ci annoteremo i problemi ed in seguito li correggeremo.

Vediamo altre regole e nozioni fondamentali del Waypointing.

28.jpg
Questo è il percorso tra 2 waypoints.
La riga bianca indica il percorso dal waypoint in cui mi trovo a quell’altro.
La riga gialla, indica la connessione dall’altro waypoint a quello in cui mi trovo.

A tal proposito esiste una funzione che ci permette di connettere automaticamente 2 waypoint.

Pathrun_twoway on

A volte ci sono zone della mappa, dove non si deve avere un percorso bidirezionale tra 2 wp, quindi si utilizza

Pathrun_oneway on

Così facendo si attiverrà la connessione tra due waypoints, a seconda della direzione in cui vado.
Per avere l’effetto della figura (che con il twoway on è automatico), dovrò percorrere il tragitto avanti e indietro.

Quindi la coppia di comandi da tenere a mente è:

Pathrun_oneway on/off
Pathrun_twoway on/off

Esempio di utilizzo del Oneway ON

29.jpg
Si nota che la riga bianca dice al bot di andare sul lift e da lì non tornerà indietro, poi si intravede una connessione gialla che porterà il bot dalla posizione lontana, fino a quella che gli consentirà poi di salire sull’ascensore.

A tal proposito si nota che il waypoint sull’ascensore ha un’indicazione particolare (tag).

WAYPOINT TAGS
Servono a distinguere con speciali funzioni, il waypoint appena creato.
Questi tags si attivano portandosi sul waypoint e premendo la “m”.
Apparirà il seguente menù:

m.jpg
Queste le scelte:

1. Team Specific Only
26.jpg
Serve a contraddistinguere un waypoint, in modo da associarlo solo ad una squadra specifica.
Es. Un geniere che deve costruire una SG in base, avrà un waypoint associato in modo che non venga confuso dai genieri dell’altra squadra, che altrimenti stupidamente, tenterebbero di raggiungerlo.

2. wait for lift
24.jpg
È il way point più delicato nel waypointing.
Vanno messi nel punto giusto, all’inizio e alla fine del percorso dell’ascensore.
Questo perchè, il waipoint alla base dell’ascensore, dice al bot di fermarsi.Giunto al termine del percorso SULL’ascensore, il bot giungerà al secondo waypoint (Wait for a lift) e da lì, potrà procedere verso il successivo waypoint.

3. DoorUsato raramente. Dice al bot di camminare. Serve dove ci sono porte che si aprono dopo qualche istante e creerebbero qualche problema al bot stesso.

4. Sniper Spot
25.jpgWaypoint specifico per lo sniper. Associarlo alla squadra di appartenenza (Team Specific).. Si deve piazzare in direzione di dove il cecchino, punterà il fucile.
Cioè direzione sguardo in soggettiva.

la piccola linea davanti al fucile, indica dove lo sniper punterà lo stesso.

5. More….Si suddivide nelle seguenti sottoclassi:

m_more.jpg
5.1 Flag locationPosto sul waypoint della bandiera nemica, associare alla squadra di appartenenza

5.2 Flag Goal LocationPosto sul Capture Point, associare alla squadra di appartenenza
Un es. Dei Flag e Flag goal waypoint, sono:

21.jpg
5.3 i Tag Health, Ammo e Armor
vanno piazzati sui rispettivi oggetti. Ricordarsi di associarli alla squadra di appartenenza, nel caso siano situati in zone inaccessibili alle altre squadre

47.jpg
5.4 Defend(sg)
27.jpg
Per il geniere, da associare alla squadra di appartenenza.
Va posizionato come durante il gioco, ovvero il geniere deve porsi frontalmente a dove vorrà che la sentinella, punti.

5.5 Jump
Jump waypoint va situato in una zona dove il bot dovrà saltare.
Deve essere posizionato a mezz’aria.

34.jpg
5.6 Detpack
In questo waypoint, il Demolitore piazzerà un detpack di 5 secondi.
Associabile a script-point (che vedremo più avanti) nel caso si voglia far aprire brecce al demo-bot.

6 point1, point2…utilizzabili tramite script (…)

Solo per la versione 698
7 RocketJump
79.jpg
Il RJ wayponit, rappresenta l’obbiettivo di atteraggio di un Rocket Jump.
Importantissimo! Il RJ waypoint, non va connesso ad altri RJ, inquanto tutti i bot, tenderebbero ad utilizzarlo, venendo così sviati dalla loro effettiva traccia.
È cmq difficile da utilizzare. Se il wayponit non sarà alla distanza giusta, il soldato non salterà.

8 Concussion Jumping (solo versione 698)
Come il RJ.

NOTE COSTRUTTIVE:
Waypoints su ascensore.Posizionarne uno al centro della pedana dell’ascensore quando è a terra (con noi sopra).
Alla posizione più alta dell’ascensore (piano alto) posizionarne un altro.
Mettere un terzo waypoint per fare uscire il bot dalla pedana.
Se ci fossero difficoltà di funzionamento, attivare il TeamSpecific

Waypoints su scalePiazzare un waypoint alla base della scala
Piazzare un waypoint alla sommità della scala
Connettere manualmente i due waypoints

BOT DEBUG
Fondamentale per correggere il WP.
Alla comparsa dei bot, appariranno delle linee di proiezione di diverso colore, dal seguente significato

botdebug.jpg
Verde: segnala il bot verso il quale il bot è diretto
Blu: mostra la destinazione finale del bot (es. flag o CP)
Azzurro: mostra l’oggetto obbiettivo del bot (es ammo, health, lift)
Rosso: obbiettivo momentaneo del bot.

WP TESTING
Prima cosa, testare i percorsi verso la bandiera ed il ritorno al Capture Point.
Aggiungere uno scout blu:

Riassumendo, le linee blu indicano la meta finale del bot, le linee verdi indicano il waypoint successivo al quale il bot è diretto.

Ottimizzare i waypoint
Eliminare i waypoint inutili
Le traiettorie tra waypoints non devono tagliare gli angoli
Il percorso dalla bandiera al capturepoint, deve viaggiare in entrambi i sensi (meglio con twoway ON).
Mettere waypoints su ammo health e armor.

addbot 1 1

Entrare come spettatore e controllare che il bot prenda la bandiera e faccia punto facilmente.
Appuntarsi dove il bot ha difficoltà a passare ed in seguito correggere.
Se il bot, gira su se stesso, vuol dire che siamo in presenza di un percorso interrotto ed il bot non può andare ad obbiettivo. In tal caso ricontrollare il percorso.

Una volta accertata la correttezza del percorso flag-CP eliminare il bot blu e testare il percorso rosso.

kickall
addbot 2 1

Verificato questo, eliminare i bot e testare gli eventuali ENG e sniper. Una classe alla volta, una squadra alla volta.
Se ci sono più di un waypoint specifici per sniper/eng aggiungere 2-3 sniper/eng alla volta e controllare che non si incasinino sullo stesso waypoint.

Quindi per testare gli sniper blu

kickall
addbot 1 2
addbot 1 2
addbot 1 2

per testare più di in ENG rosso

kickall
addbot 2 9
addbot 2 9
addbot 2 9

ecc. Ecc.

IMPORTANTE.Ogni volta che si corregge un problema, salvare con il tasto END e rilanciare la mappa con:

restart

Prestare attenzione a:

1. il bot sembra appeso al muro
assicurarsi che il wp non tagli l’angolo del muro o non sia un percorso troppo vicino al muro stesso.
2. il bot ruota attorno ad un wp.
Attivare il bot debug, se non lo è già

bot_debug on

assicurarsi tramite le linee di debug, che il bot non cerchi di andare ad un wp irraggiungibile.
Assicurarsi che tutto il percorso abbia abilitata la direzione cercata dal bot.
In un percorso Flag-CP tutto il tragitto deve essere TWOWAY altrimenti il bot si pianta non potendo tornare da dove è venuto.
Se si è sicuri che il percorso è intatto in entrambe le direzioni, forse un tratto tra due waypoints, è troppo lungo, per sicurezza conviene mettere un wp intermedio.
Due wp a grande distanza, possono risultare come interrotti!

Non creare o eliminare wp con i bot in gioco, si rischia il crasc.
Salvare sempre la modifica effettuata e rilanciare la mappa.

3. Non avere percorsi ridondanti.
Se colleghiamo 3 punti x,y,z, creare connessione x>y e y>z. Evitare connessioni z>x
4. Assegnare sempre il Team Specific ai waypoint con Tag Ammo, armor, health, SG, sniper

ALTRI COMANDI UTILI

locate_waypoint on/off

abilita la locazione dei waypoints

locate_waypoint 

viene generato un fascio che mi permette di identificare la posizione del wp

una volta finito il lavoro, salvare e giocare.

Dimenticavo, per firmare il waypoint:

waypoint_author Bancaldo

Bancaldo.

Categorie:VideoGames Tag: