Una traduccion mas del tuto de winter: http://forums.taleworlds.com/index.php/topic,14272.0.html?PHPSESSID=hg2d05qg3d6mtdhhp327tmjlo5 , solo quedara la ultima parte!
Ahora que hemos ganado algo de experiencia trabajando con el module system, podemos dirigir nuestras manos a un de los componentes mas complejos; Triggers. Los triggers son bloques de operaciones basados en tiempo que se activan a intervalos regulares o en ocasiones especificas. Todas las operaciones en el bloque de operaciones del trigger en ese momento se ejecutaran.
8.1 – Analisis de Module_Simple_Triggers
Actualmente, module_simple_triggers solo tiene una función: direccionar al jugador al menú apropiado cuando se encuentra con otra party en el mapa. A este efecto, la lista Python contiene solo un tuple bastante largo.
(ti_on_party_encounter,
[
(store_encountered_party, reg(1)),
(store_encountered_party2,reg(2)), # encountered_party2 is set when we come across a battle or siege, otherwise it's a minus value
(try_begin),
(lt, reg(2),0), #Normal encounter. Not battle or siege.
(try_begin),
(ge, reg(1), towns_begin),
(lt, reg(1), towns_end),
(jump_to_menu, "mnu_town"),
(else_try),
(else_try),
(ge, reg(1), castles_begin),
(lt, reg(1), castles_end),
(jump_to_menu, "mnu_castle"),
(else_try),
(eq, reg(1), "p_zendar"),
(jump_to_menu, "mnu_zendar"),
(else_try),
(eq, reg(1), "p_salt_mine"),
(jump_to_menu, "mnu_salt_mine"),
(else_try),
(eq, reg(1), "p_four_ways_inn"),
(jump_to_menu, "mnu_four_ways_inn"),
(else_try),
(eq, reg(1), "p_dhorak_keep"),
(jump_to_menu, "mnu_dhorak_keep"),
(else_try),
(eq, reg(1), "p_training_ground"),
(jump_to_menu, "mnu_training_ground"),
(else_try),
(store_current_hours, reg(7)),
(le, reg(7), "$defended_until_time"),
(assign, "$defended_until_time", 0),
(jump_to_menu, "mnu_in_castle_under_attack"),
(end_try),
(else_try), #Battle or siege
(try_end)
]),
Este es el primer y único trigger en la lista. Tienes una construcción muy simple, contiene únicamente dos campos separados.
Desglose de los campos del tuple:
1 ) Intervalo de comprobación: Cuando o con que frecuencia será comprobado este trigger
2 ) Bloque de operación: Esto debe ser un bloque de operación valido. Mira el archivo header_operationes.py para ver la lista de posibles operaciones.
Analisis del tuple:
1 ) Intervalo de comprobación = ti_on_party_encounter.
2 ) Bloque de operación. El análisis del bloque de operación vendrá a continuación.
Como podemos ver por ti_on_party_encounter, este trigger es comprobado siempre que el jugador se encuentra una party en el mapa. Ahora veremos en detalle cada sección del tuple para analizar que es lo que hace cada una de ellas.
Sección 1:
(store_encountered_party, reg(1)),
(store_encountered_party2,reg(2)), # encountered_party2 is set when we come across a battle or siege, otherwise it's a minus value
1 ) "store_encountered_party" encuentra cualquier party que el jugador ha encontrado y almacena la identidad de esa party en el registro “reg(1)”.
2 ) "store_encountered_party2" hace lo mismo, almacenando la segunda party encontrada en el “reg(2)”. Obviamente esto solo ocurre si el jugador se encuentra con una batalla o asedio en curso. Si no hay una segunda party, “reg(2)” contendrá un valor por debajo de 0.
Sección 2:
(try_begin),
(lt, reg(2),0), #Normal encounter. Not battle or siege.
La condición (lt, reg(2),0) La condición (lt, reg(2),0) requiere que “reg(2)” sea inferior a 0. Ya que “reg(2)” es siempre inferior a 0 a no ser que el jugador se encuentre una batalla en curso, el bloque de operaciones continuara a la sección 3.
Lo mas interesante a anotar de esta sección es la operación (try_begin). Esta operación abre una try operation, la cual funciona como un bloque de operaciones normal, excepto por una diferencia. Si una try operation contiene una condición en la que los requerimientos no se cumplen, esto no cancela el resto del bloque de operaciones; solo cancela lo que hay hasta (try_end). Todo lo que hay después de (try_end) actua normalmente. En esencia, un try operation funciona como un bloque de operaciones aislado dentro de otro bloque de operaciones.
Allí esta también el try operation adicional (else_try), el cual puede ser insertado en un try operation activo tal como el de module_simple_triggers. El contenido de un else_try block solo será tomado en cuenta para su ejecución si todos los try operations activos anteriores al (else_try) (incluidos otros else_trys) no han cumplido las condiciones.
Sección 3:
(try_begin),
(ge, reg(1), towns_begin),
(lt, reg(1), towns_end),
(jump_to_menu, "mnu_town"),
Esta sección comienza un try operation dentro de un try operation. Esta sección se cumplirá si “reg(1)” – el encuentro con la party – esta entre la constante towns_begin ("p_town_1" en module_parties.py) y towns_end ("p_salt_mine" en module_parties). Si esta condición se cumple, el jugador será dirigido al menú “mnu_town”. Si esto no se cumple, el bloque continuara a la sección 4.
Sección 4:
(else_try),
(ge, reg(1), castles_begin),
(lt, reg(1), castles_end),
(jump_to_menu, "mnu_castle"),
Esta sección solo será tenida en cuenta si el try operation anterior ha fallado; por lo tanto, esto solo será tomado en cuenta si la party encontrada no es un town(pueblo). Asi habiendo concluido que el party encontrado no es un town, esta sección comoprobara si esta entre castles_begin ("p_castle_1") y castles_end ("p_river_pirate_spawn_point"). Si esta operación tiene éxito, se cumple la condición, el jugador es dirigido a “mnu_castle”. Si no se cumple, el bloque continuara a la sección 5.
Sección 5:
(else_try),
(eq, reg(1), "p_zendar"),
(jump_to_menu, "mnu_zendar"),
Habiendo concluido que la party encontrada no es ni un town ni un castle(castillo), esta try operation comprobara si la party encontrada es “p_zendar”. Si se cumple, esta try operation llevara al jugador al “mnu_zendar”. Si no se cumple como es costumbre continuara a la siguiente sección, a la sección 6.
Sección 6:
(else_try),
(eq, reg(1), "p_salt_mine"),
(jump_to_menu, "mnu_salt_mine"),
Si la party encontrada es “p_salt_mine”, esta try operation llevara al jugador al “mnu_salt_mine”.
Sección 7:
(else_try),
(eq, reg(1), "p_four_ways_inn"),
(jump_to_menu, "mnu_four_ways_inn"),
Si la party encontrada es “p_four_ways_inn”, esta sección llevara al jugador al “mnu_four_ways_inn”.
Sección 8:
(else_try),
(eq, reg(1), "p_dhorak_keep"),
(jump_to_menu, "mnu_dhorak_keep"),
Si la party encontrada es “p_dhorak_keep”, esta sección llevara al jugador al “mnu_dhorak_keep”.
Sección 9:
(else_try),
(eq, reg(1), "p_training_ground"),
(jump_to_menu, "mnu_training_ground"),
Si la party encontrada es “p_training_ground”, esta sección llevara al jugador al “mnu_training_ground”.
Sección 10:
(else_try),
(store_current_hours, reg(7)),
(le, reg(7), "$defended_until_time"),
(assign, "$defended_until_time", 0),
(jump_to_menu, "mnu_in_castle_under_attack"),
Esta sección almacena el número de horas que han pasado desde el comienzo del juego en “reg(7)”, y entonces comprueba si “reg(7)” es menor o igual(le) que la variable "$defended_until_time". Si se cumple, esta fijara "$defended_until_time" a 0 y llevara al jugador al “mnu_in_castle_under_attack”. En caso de que no se cumpla, nos llevara a la sección 11.
Sección 11:
(end_try),
Esto significa el final de la segunda try operation. La primera try operation continua normalmente, sin tener en cuenta que ha ocurrido en la segunda try operation.
Sección 12:
(else_try), #Battle or siege
(try_end)
Este else_try cubre cualquier encuentro con una party que se encuentra en batalla con otra party. Ya que actualmente no contiene otras operaciones, esto resultara en el encuentro de una batalla – igual que el “new_town” que creamos en la parte 2 de este tutorial, la cual todavía no tiene operaciones enlazadas a un menú y no se le ha asignado la flag pf_auto_start_dialog. Rectificaremos esto en el siguiente segmento.
8.2 – Editando el trigger party encounters
Tenemos que asegurarnos que cualquier encuentro con esta town dirija al jugador al menú apropiado. Esto nos deja con dos posibilidades; una es usar en nuestra nueva party un menú del Native, como mnu_town, u otra que es crear un nuevo menú.
Para nuestro new_town, crearemos un menú personalizado, pero después examinaremos que requerimos para usar un menú del Native en una town creada por nosotros.
Primero, cualquier entrada adicional en el trigger party encounters deberá ser añadida antes de la Seccion 10:
(else_try),
(store_current_hours, reg(7)),
(le, reg(7), "$defended_until_time"),
(assign, "$defended_until_time", 0),
(jump_to_menu, "mnu_in_castle_under_attack"),
Si añades alguna entrada después de esta, esto creara problemas cuando te encuentres tus nuevas parties a medianoche. Para asegurarnos que esto no ocurra, pondremos nuestra nueva entrada justo encima de ella y justo debajo de la Seccion 9:
(else_try),
(eq, reg(1), "p_training_ground"),
(jump_to_menu, "mnu_training_ground"),
Crea un espacio entre la sección 9 y la sección 10. Una vez hecho esto, podemos empezar a crear nuestra nueva entrada.
Cualquier nueva entrada en este trigger debe comenzar con un else_try. Despues del else_try, podemos añadir operaciones condicionales para especificar cuando esta entrada debe y no se debe activar. Después, una vez que todas las condiciones estén en su sitio, podemos añadir las consecuencias, tales como mostrar al jugador un menú de juego. Estas consecuencias pueden ser muy variadas, ellas no están limitadas simplemente a jump_to_menu, pero deben ser operaciones válidas.
Copia y pega la Sección 9 (la entrada training_ground) en nuestro espacio creado entre la sección 9 y la 10. Cuando hayas hecho esto, reemplaza la nueva entrada "p_training_ground" por "p_new_town" y "mnu_training_ground" por "mnu_new_town".
Ahora la única cosa que queda por hacer para hacer nuestra town operacional es crear un menú para ella. Sin embargo antes de pasar a module_game_menus, hay muchas mas funcionalidades esperando ser exploradas en triggers. Abre module_triggers.py ahora y pasa al siguiente segmento.
8.3 – Desglose, Module_Triggers
Hay dos tipos de triggers en el module system: simple triggers y expanded triggers. Los expanded triggers están contenidos en module_triggers.py. Ellos trabajan mediante la misma teoría que los simple triggers, pero tienen algunas opciones más.
(0.1, 0, ti_once, [(map_free,0)], [(tutorial_box,"str_tutorial_map1")]),
El primer trigger en este archivo es fácil y sencillo. Este es el trigger que muestra el tutorial del mapa cuando el jugador aparece por primera vez en el mapa.
Desglose de los campos del tuple:
1) Intervalo de comprobación: Con que frecuencia es comprobado este trigger.
2) Intervalo de demora: Cuanto espera antes de aplicar las consecuencias del trigger después de que las condiciones se hayan cumplido. 3) Intervalo de reactivación: Cuanto tiempo ha de pasar después de haber aplicado las consecuencias del trigger antes de volver a estar activas de nuevo.
4) Bloque de condiciones: Esto debe ser un bloque de operación valido. Si el bloque de condiciones esta vacio, esto siempre se cumplirá, por lo tanto el trigger siempre se activara.
5) Bloque de consecuencias: esto debe ser un bloque de consecuencias válido.
Análisis del tuple:
1) Intervalo de comprobación = 0.1
2)Intervalo de demora: = 0
3) Intervalo de reactivación: = ti_once
4) Bloque de condiciones: = (map_free,0)
5) Bloque de consecuencias =(tutorial_box,”str_tutorial_map1”)
Como podemos ver en este análisis, este trigger es comprobado cada 0.1 horas de tiempo de juego; no tiene intervalo de demora; nunca se reactivara debido a ti_once. Esto significa que, si las condiciones en el bloque de condiciones del trigger se cumplen, el trigger se activara una vez y nunca mas volver a activarse. En este caso, el trigger será activado si el jugador esta colocado en cualquier lugar del mapa.
Ahora podemos comenzar a hacer nuestro propio trigger. Copia el trigger del tutorial y pegalo al final de la lista Python de module_triggers.py.
Lo que vamos a hacer con este nuevo trigger es generar otra party en el mapa; Geoffrey’s party. Reemplaza (map_free,0) en el bloque de condiciones del trigger por las siguientes operaciones:
(eq,"$geoffrey_duel",1),
(store_time_of_day,reg(1)),
(gt,reg(1),19),
Si recuerdas que hicimos en la parte 7 de este tutorial, nosotros asignamos la variable "$geoffrey_duel" a 1 despues de que Geoffrey te retara a un duelo. Por lo tanto, (eq,"$geoffrey_duel",1) comprobara si Geoffrey te ha retado o no. Si no te ha retado el bloque de condiciones fallara, no se cumplirá.
Las siguientes dos operaciones almacenan la hora del dia en el reg(1), y entonces comprueban si reg(1) es mas grande que 19; esencialmente, si la hora del dia es mayor que las 19:00. Si esto es asi, el bloque de condiciones se cumplirá y permitirá al trigger activarse.
Ahora, reemplaza (tutorial_box,"str_tutorial_map1") en el bloque de consecuencias por las siguientes operaciones:
(set_spawn_radius,0),
(spawn_around_party,"p_zendar","pt_new_template"),
(assign,"$geoffrey_party_id",reg(0)),
(party_set_ai_behavior,"$geoffrey_party_id",ai_bhvr_track_party),
(party_set_ai_object,"$geoffrey_party_id","p_main_party"),
La primera operación define el radio de generación; tu debes hacer esto cada vez que quieras generar una party, o que la party sea generada en el radio definido mas recientemente, lo cual puede ser muy impredecible.
La segunda operación genera un party template ("pt_new_template") cerca de una party ("p_zendar"). Esta operación también sacara el identificador de la party generada y lo introducirá en reg(0). Luego asignamos el identificador a una variable por lo que este no se perderá cuando reg(0) sea sobreescrito.
Finalmente, definiremos el comportamiento y el propósito de la IA. Estas operaciones son bastante sencillas. Le estamos diciendo a "$geoffrey_party_id" que siga a "p_main_party". Cuando defines que una party siga a otra party, esto hara que inexorablemente atrapen a la otra party y entonces la ataquen, sin tener en cuenta la facción u otras consideraciones.
Guarda tu progreso. No podemos compilar todavía pues aun no hemos creado un menú para el encuentro de la party creado en el segmento 8.2. Nosotros lo haremos en el siguiente. Ahora estas preparado para ir a la parte 9 de este tutorial.
Ahora que hemos ganado algo de experiencia trabajando con el module system, podemos dirigir nuestras manos a un de los componentes mas complejos; Triggers. Los triggers son bloques de operaciones basados en tiempo que se activan a intervalos regulares o en ocasiones especificas. Todas las operaciones en el bloque de operaciones del trigger en ese momento se ejecutaran.
8.1 – Analisis de Module_Simple_Triggers
Actualmente, module_simple_triggers solo tiene una función: direccionar al jugador al menú apropiado cuando se encuentra con otra party en el mapa. A este efecto, la lista Python contiene solo un tuple bastante largo.
(ti_on_party_encounter,
[
(store_encountered_party, reg(1)),
(store_encountered_party2,reg(2)), # encountered_party2 is set when we come across a battle or siege, otherwise it's a minus value
(try_begin),
(lt, reg(2),0), #Normal encounter. Not battle or siege.
(try_begin),
(ge, reg(1), towns_begin),
(lt, reg(1), towns_end),
(jump_to_menu, "mnu_town"),
(else_try),
(else_try),
(ge, reg(1), castles_begin),
(lt, reg(1), castles_end),
(jump_to_menu, "mnu_castle"),
(else_try),
(eq, reg(1), "p_zendar"),
(jump_to_menu, "mnu_zendar"),
(else_try),
(eq, reg(1), "p_salt_mine"),
(jump_to_menu, "mnu_salt_mine"),
(else_try),
(eq, reg(1), "p_four_ways_inn"),
(jump_to_menu, "mnu_four_ways_inn"),
(else_try),
(eq, reg(1), "p_dhorak_keep"),
(jump_to_menu, "mnu_dhorak_keep"),
(else_try),
(eq, reg(1), "p_training_ground"),
(jump_to_menu, "mnu_training_ground"),
(else_try),
(store_current_hours, reg(7)),
(le, reg(7), "$defended_until_time"),
(assign, "$defended_until_time", 0),
(jump_to_menu, "mnu_in_castle_under_attack"),
(end_try),
(else_try), #Battle or siege
(try_end)
]),
Este es el primer y único trigger en la lista. Tienes una construcción muy simple, contiene únicamente dos campos separados.
Desglose de los campos del tuple:
1 ) Intervalo de comprobación: Cuando o con que frecuencia será comprobado este trigger
2 ) Bloque de operación: Esto debe ser un bloque de operación valido. Mira el archivo header_operationes.py para ver la lista de posibles operaciones.
Analisis del tuple:
1 ) Intervalo de comprobación = ti_on_party_encounter.
2 ) Bloque de operación. El análisis del bloque de operación vendrá a continuación.
Como podemos ver por ti_on_party_encounter, este trigger es comprobado siempre que el jugador se encuentra una party en el mapa. Ahora veremos en detalle cada sección del tuple para analizar que es lo que hace cada una de ellas.
Sección 1:
(store_encountered_party, reg(1)),
(store_encountered_party2,reg(2)), # encountered_party2 is set when we come across a battle or siege, otherwise it's a minus value
1 ) "store_encountered_party" encuentra cualquier party que el jugador ha encontrado y almacena la identidad de esa party en el registro “reg(1)”.
2 ) "store_encountered_party2" hace lo mismo, almacenando la segunda party encontrada en el “reg(2)”. Obviamente esto solo ocurre si el jugador se encuentra con una batalla o asedio en curso. Si no hay una segunda party, “reg(2)” contendrá un valor por debajo de 0.
Sección 2:
(try_begin),
(lt, reg(2),0), #Normal encounter. Not battle or siege.
La condición (lt, reg(2),0) La condición (lt, reg(2),0) requiere que “reg(2)” sea inferior a 0. Ya que “reg(2)” es siempre inferior a 0 a no ser que el jugador se encuentre una batalla en curso, el bloque de operaciones continuara a la sección 3.
Lo mas interesante a anotar de esta sección es la operación (try_begin). Esta operación abre una try operation, la cual funciona como un bloque de operaciones normal, excepto por una diferencia. Si una try operation contiene una condición en la que los requerimientos no se cumplen, esto no cancela el resto del bloque de operaciones; solo cancela lo que hay hasta (try_end). Todo lo que hay después de (try_end) actua normalmente. En esencia, un try operation funciona como un bloque de operaciones aislado dentro de otro bloque de operaciones.
Allí esta también el try operation adicional (else_try), el cual puede ser insertado en un try operation activo tal como el de module_simple_triggers. El contenido de un else_try block solo será tomado en cuenta para su ejecución si todos los try operations activos anteriores al (else_try) (incluidos otros else_trys) no han cumplido las condiciones.
Sección 3:
(try_begin),
(ge, reg(1), towns_begin),
(lt, reg(1), towns_end),
(jump_to_menu, "mnu_town"),
Esta sección comienza un try operation dentro de un try operation. Esta sección se cumplirá si “reg(1)” – el encuentro con la party – esta entre la constante towns_begin ("p_town_1" en module_parties.py) y towns_end ("p_salt_mine" en module_parties). Si esta condición se cumple, el jugador será dirigido al menú “mnu_town”. Si esto no se cumple, el bloque continuara a la sección 4.
Sección 4:
(else_try),
(ge, reg(1), castles_begin),
(lt, reg(1), castles_end),
(jump_to_menu, "mnu_castle"),
Esta sección solo será tenida en cuenta si el try operation anterior ha fallado; por lo tanto, esto solo será tomado en cuenta si la party encontrada no es un town(pueblo). Asi habiendo concluido que el party encontrado no es un town, esta sección comoprobara si esta entre castles_begin ("p_castle_1") y castles_end ("p_river_pirate_spawn_point"). Si esta operación tiene éxito, se cumple la condición, el jugador es dirigido a “mnu_castle”. Si no se cumple, el bloque continuara a la sección 5.
Sección 5:
(else_try),
(eq, reg(1), "p_zendar"),
(jump_to_menu, "mnu_zendar"),
Habiendo concluido que la party encontrada no es ni un town ni un castle(castillo), esta try operation comprobara si la party encontrada es “p_zendar”. Si se cumple, esta try operation llevara al jugador al “mnu_zendar”. Si no se cumple como es costumbre continuara a la siguiente sección, a la sección 6.
Sección 6:
(else_try),
(eq, reg(1), "p_salt_mine"),
(jump_to_menu, "mnu_salt_mine"),
Si la party encontrada es “p_salt_mine”, esta try operation llevara al jugador al “mnu_salt_mine”.
Sección 7:
(else_try),
(eq, reg(1), "p_four_ways_inn"),
(jump_to_menu, "mnu_four_ways_inn"),
Si la party encontrada es “p_four_ways_inn”, esta sección llevara al jugador al “mnu_four_ways_inn”.
Sección 8:
(else_try),
(eq, reg(1), "p_dhorak_keep"),
(jump_to_menu, "mnu_dhorak_keep"),
Si la party encontrada es “p_dhorak_keep”, esta sección llevara al jugador al “mnu_dhorak_keep”.
Sección 9:
(else_try),
(eq, reg(1), "p_training_ground"),
(jump_to_menu, "mnu_training_ground"),
Si la party encontrada es “p_training_ground”, esta sección llevara al jugador al “mnu_training_ground”.
Sección 10:
(else_try),
(store_current_hours, reg(7)),
(le, reg(7), "$defended_until_time"),
(assign, "$defended_until_time", 0),
(jump_to_menu, "mnu_in_castle_under_attack"),
Esta sección almacena el número de horas que han pasado desde el comienzo del juego en “reg(7)”, y entonces comprueba si “reg(7)” es menor o igual(le) que la variable "$defended_until_time". Si se cumple, esta fijara "$defended_until_time" a 0 y llevara al jugador al “mnu_in_castle_under_attack”. En caso de que no se cumpla, nos llevara a la sección 11.
Sección 11:
(end_try),
Esto significa el final de la segunda try operation. La primera try operation continua normalmente, sin tener en cuenta que ha ocurrido en la segunda try operation.
Sección 12:
(else_try), #Battle or siege
(try_end)
Este else_try cubre cualquier encuentro con una party que se encuentra en batalla con otra party. Ya que actualmente no contiene otras operaciones, esto resultara en el encuentro de una batalla – igual que el “new_town” que creamos en la parte 2 de este tutorial, la cual todavía no tiene operaciones enlazadas a un menú y no se le ha asignado la flag pf_auto_start_dialog. Rectificaremos esto en el siguiente segmento.
8.2 – Editando el trigger party encounters
Tenemos que asegurarnos que cualquier encuentro con esta town dirija al jugador al menú apropiado. Esto nos deja con dos posibilidades; una es usar en nuestra nueva party un menú del Native, como mnu_town, u otra que es crear un nuevo menú.
Para nuestro new_town, crearemos un menú personalizado, pero después examinaremos que requerimos para usar un menú del Native en una town creada por nosotros.
Primero, cualquier entrada adicional en el trigger party encounters deberá ser añadida antes de la Seccion 10:
(else_try),
(store_current_hours, reg(7)),
(le, reg(7), "$defended_until_time"),
(assign, "$defended_until_time", 0),
(jump_to_menu, "mnu_in_castle_under_attack"),
Si añades alguna entrada después de esta, esto creara problemas cuando te encuentres tus nuevas parties a medianoche. Para asegurarnos que esto no ocurra, pondremos nuestra nueva entrada justo encima de ella y justo debajo de la Seccion 9:
(else_try),
(eq, reg(1), "p_training_ground"),
(jump_to_menu, "mnu_training_ground"),
Crea un espacio entre la sección 9 y la sección 10. Una vez hecho esto, podemos empezar a crear nuestra nueva entrada.
Cualquier nueva entrada en este trigger debe comenzar con un else_try. Despues del else_try, podemos añadir operaciones condicionales para especificar cuando esta entrada debe y no se debe activar. Después, una vez que todas las condiciones estén en su sitio, podemos añadir las consecuencias, tales como mostrar al jugador un menú de juego. Estas consecuencias pueden ser muy variadas, ellas no están limitadas simplemente a jump_to_menu, pero deben ser operaciones válidas.
Copia y pega la Sección 9 (la entrada training_ground) en nuestro espacio creado entre la sección 9 y la 10. Cuando hayas hecho esto, reemplaza la nueva entrada "p_training_ground" por "p_new_town" y "mnu_training_ground" por "mnu_new_town".
Ahora la única cosa que queda por hacer para hacer nuestra town operacional es crear un menú para ella. Sin embargo antes de pasar a module_game_menus, hay muchas mas funcionalidades esperando ser exploradas en triggers. Abre module_triggers.py ahora y pasa al siguiente segmento.
8.3 – Desglose, Module_Triggers
Hay dos tipos de triggers en el module system: simple triggers y expanded triggers. Los expanded triggers están contenidos en module_triggers.py. Ellos trabajan mediante la misma teoría que los simple triggers, pero tienen algunas opciones más.
(0.1, 0, ti_once, [(map_free,0)], [(tutorial_box,"str_tutorial_map1")]),
El primer trigger en este archivo es fácil y sencillo. Este es el trigger que muestra el tutorial del mapa cuando el jugador aparece por primera vez en el mapa.
Desglose de los campos del tuple:
1) Intervalo de comprobación: Con que frecuencia es comprobado este trigger.
2) Intervalo de demora: Cuanto espera antes de aplicar las consecuencias del trigger después de que las condiciones se hayan cumplido. 3) Intervalo de reactivación: Cuanto tiempo ha de pasar después de haber aplicado las consecuencias del trigger antes de volver a estar activas de nuevo.
4) Bloque de condiciones: Esto debe ser un bloque de operación valido. Si el bloque de condiciones esta vacio, esto siempre se cumplirá, por lo tanto el trigger siempre se activara.
5) Bloque de consecuencias: esto debe ser un bloque de consecuencias válido.
Análisis del tuple:
1) Intervalo de comprobación = 0.1
2)Intervalo de demora: = 0
3) Intervalo de reactivación: = ti_once
4) Bloque de condiciones: = (map_free,0)
5) Bloque de consecuencias =(tutorial_box,”str_tutorial_map1”)
Como podemos ver en este análisis, este trigger es comprobado cada 0.1 horas de tiempo de juego; no tiene intervalo de demora; nunca se reactivara debido a ti_once. Esto significa que, si las condiciones en el bloque de condiciones del trigger se cumplen, el trigger se activara una vez y nunca mas volver a activarse. En este caso, el trigger será activado si el jugador esta colocado en cualquier lugar del mapa.
Ahora podemos comenzar a hacer nuestro propio trigger. Copia el trigger del tutorial y pegalo al final de la lista Python de module_triggers.py.
Lo que vamos a hacer con este nuevo trigger es generar otra party en el mapa; Geoffrey’s party. Reemplaza (map_free,0) en el bloque de condiciones del trigger por las siguientes operaciones:
(eq,"$geoffrey_duel",1),
(store_time_of_day,reg(1)),
(gt,reg(1),19),
Si recuerdas que hicimos en la parte 7 de este tutorial, nosotros asignamos la variable "$geoffrey_duel" a 1 despues de que Geoffrey te retara a un duelo. Por lo tanto, (eq,"$geoffrey_duel",1) comprobara si Geoffrey te ha retado o no. Si no te ha retado el bloque de condiciones fallara, no se cumplirá.
Las siguientes dos operaciones almacenan la hora del dia en el reg(1), y entonces comprueban si reg(1) es mas grande que 19; esencialmente, si la hora del dia es mayor que las 19:00. Si esto es asi, el bloque de condiciones se cumplirá y permitirá al trigger activarse.
Ahora, reemplaza (tutorial_box,"str_tutorial_map1") en el bloque de consecuencias por las siguientes operaciones:
(set_spawn_radius,0),
(spawn_around_party,"p_zendar","pt_new_template"),
(assign,"$geoffrey_party_id",reg(0)),
(party_set_ai_behavior,"$geoffrey_party_id",ai_bhvr_track_party),
(party_set_ai_object,"$geoffrey_party_id","p_main_party"),
La primera operación define el radio de generación; tu debes hacer esto cada vez que quieras generar una party, o que la party sea generada en el radio definido mas recientemente, lo cual puede ser muy impredecible.
La segunda operación genera un party template ("pt_new_template") cerca de una party ("p_zendar"). Esta operación también sacara el identificador de la party generada y lo introducirá en reg(0). Luego asignamos el identificador a una variable por lo que este no se perderá cuando reg(0) sea sobreescrito.
Finalmente, definiremos el comportamiento y el propósito de la IA. Estas operaciones son bastante sencillas. Le estamos diciendo a "$geoffrey_party_id" que siga a "p_main_party". Cuando defines que una party siga a otra party, esto hara que inexorablemente atrapen a la otra party y entonces la ataquen, sin tener en cuenta la facción u otras consideraciones.
Guarda tu progreso. No podemos compilar todavía pues aun no hemos creado un menú para el encuentro de la party creado en el segmento 8.2. Nosotros lo haremos en el siguiente. Ahora estas preparado para ir a la parte 9 de este tutorial.
Última edición por blancire el Sáb Feb 23, 2013 7:24 pm, editado 1 vez
