Home > VideoGames > TFC > FoxBot scripting

TFC > FoxBot scripting

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_start
la 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/scripts
2) 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
  1. Non c'è ancora nessun commento.
  1. No trackbacks yet.

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

%d blogger cliccano Mi Piace per questo: