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 è:
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:
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:
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.
Commenti recenti