DelayedAction

🕒 Resumen

El framework DelayedAction (acción retrasada) es un sistema que permite encolar y ejecutar acciones basadas en eventos (así como acciones personalizadas) en un momento posterior si se cumple una condición.

Warning

Esto NO reemplaza la verificación condicional de eventos. Está más enfocado en ejecutar código que depende de variables del sistema o condiciones iniciales.

🧩 Componentes

El framework DelayedAction consta de lo siguiente:

• La clase MASDelayedAction
• El store mas_delact

MASDelayedAction

Esta clase contiene varias propiedades, pero las principales son (todas requeridas en el constructor):

• id: el identificador único para este DelayedAction.
• ev: el evento (Event) con el cual está asociado este DelayedAction.
• conditional: condición evaluada (mediante eval) que controla cuándo se ejecuta el DelayedAction.
• action: una constante EV_ACTION o un elemento ejecutable (callable) que realiza la acción.
• flowcheck: constante MAS_FC que controla cuándo se verifica la condicional.

Esta clase también contiene el método estático makeWithLabel, el cual puede crear una instancia de DelayedAction usando un eventlabel en lugar del event real. Esto asume que mas_getEV está disponible, así que asegúrate de usar el nivel de init correcto.

Los DelayedActions están diseñados para actuar como envoltorios (wrappers) de acciones comunes que permiten ejecutarlas de forma perezosa (lazy), una vez que se cumple la conditional y en ciertos momentos durante el tiempo de init, de ejecución o incluso en sesiones posteriores.

Cuando se cumple la condicional de un DelayedAction, se ejecuta la acción. Si la acción se ejecuta con éxito, se elimina del mapa de DelayedAction y de la lista de acciones retrasadas en persistent.

Las acciones que sean ejecutables (callables) deben retornar True si tienen éxito y False en caso contrario para notificar el estado al framework. Las acciones ejecutables se invocan pasando el objeto Event mediante el argumento clave ev.

Flowcheck está diseñado para funcionar utilizando comprobaciones a nivel de bits (bitwise), por lo que un DelayedAction se puede verificar en múltiples ubicaciones realizando una operación OR a nivel de bits con las constantes MAS_FC.

mas_delact

Este store contiene las funciones de carga y guardado para el mapa de DelayedAction, así como el diccionario MAP que relaciona los IDs de DelayedAction con sus funciones constructoras.

⚙️ Configuración

Para configurar un DelayedAction, necesitarás lo siguiente:

1. Una función constructora que pueda compilar un DelayedAction en el nivel de init 994.
2. Un evento (Event) sobre el cual realizar el DelayedAction.

🛠️ Pasos para crearlo:

1. Crear función constructora: Crea una función constructora para compilar el DelayedAction. Esta función debe estar precedida por un solo guión bajo y definirse en el store mas_delact. Este store tendrá acceso a la importación de store, por lo que podrás recuperar todas las demás variables desde allí. Debes crear esta función en un nivel de init anterior a 994. Esta función no debe aceptar parámetros y debe retornar un objeto MASDelayedAction.
2. Añadir al mapa: Añade esa función al diccionario mas_delact.MAP ubicado en event-handler. Asegúrate de que tu ID sea único y coincida con el que utilizaste al crear el objeto MASDelayedAction. Se recomienda usar un número para el ID.
3. Encolar: Llama a mas_addDelayedAction pasando el ID de tu DelayedAction cuando necesites encolarlo.

🚀 Ejecución

Así es como funciona la ejecución de los DelayedActions:

1. En el nivel de init 994, todos los IDs de DelayedAction guardados en persistent._mas_delayed_action_list se convierten en instancias de DelayedAction y se almacenan en mas_delayed_action_map. Ten en cuenta que esta variable de ejecución es un diccionario, mientras que la variable en persistent es una lista.
2. En el nivel de init 995, todos los DelayedActions con un flowcheck que contenga MAS_FC_INIT son verificados y ejecutados si la condicional se cumple.
3. Los DelayedActions con un flowcheck que contenga MAS_FC_START se verifican durante el tiempo de ejecución en la pantalla de carga (splash).
4. Los DelayedActions con un flowcheck que contenga MAS_FC_IDLE_ONCE se verifican durante el tiempo de ejecución en ch30_preloop.
5. Los DelayedActions con un flowcheck que contenga MAS_FC_IDLE_ROUTINE se verifican aproximadamente una vez por minuto en ch30_loop.
6. Los DelayedActions con un flowcheck que contenga MAS_FC_END se verifican durante el tiempo de ejecución al cerrar el juego (quit).
7. Los IDs de los DelayedActions que no se ejecutaron en esta sesión se guardan en persistent._mas_delayed_action_list.

Note

Esta lista siempre se regenera (no se le añade información) al finalizar la sesión.

📝 Adicional:

• Todo el código de DelayedAction se encuentra en event-handler.
• El primer evento en usar DelayedActions es el evento de las islas (islands event). Este se utilizó para manejar los casos en que las imágenes no se decodificaban correctamente, lo que significaba que el evento debía permanecer bloqueado hasta que las imágenes se analizaran con éxito.