ambar-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Mine-dev] Re: [Mine] Temporización en guiones


From: Andres Moya
Subject: Re: [Mine-dev] Re: [Mine] Temporización en guiones
Date: Tue, 12 Oct 2004 16:56:46 +0200

El dom, 10-10-2004 a las 12:55, address@hidden escribió:
> ----- Original Message -----
> From: Andres Moya <address@hidden>
> Date: Sat, 09 Oct 2004 17:50:04 +0200
> To: Minë <address@hidden>
> Subject: [Mine] Temporización en guiones
> 
> ?Este mensaje no debería ir por la lista de desarrolladores mine_developers? 
> 8-P

Efestivamente, es mi manía de poner varias cosas en un mismo mensaje,
que algunas son para developers y otras no.


> > Me gustaría que alguien se lo leyera y diera alguna opinión, si nada lo
> > impide voy a empezar a implementarlo la semana que viene.
>
> Parece una buena idea para simplificar la implementación de los
> guiones temporizados. Sin embargo, pienso que añade trabajo
> innecesario para el escritor de guiones en el caso (frecuente) de que
> se ejecuten juntas varias acciones, pero no instantáneamente sino una
> detrás de otra con una pausa. Con tu propuesta, ese caso requiere la
> creación de un suceso_programado para cada acción sucesiva.

¿Y qué tal quedaría si nos podemos evitar totalmente la sección
sucesos_programados? Lo tengo que confirmar cuando me ponga con más
detalle, pero me parece que simplemente con definir una acción
programar_guion (en vez de programar_suceso) se puede hacer que el
sistema calcule automáticamente todo lo que he metido en la sección
ésta.

Así, para cada bloque de acciones se crearía un guión, que al final
contenga una acción programar_guion que apunte al siguiente. Y no hace
falta subir a la entidad contenedora a añadir cosas.

De todas formas, yo no veo tan clara la necesidad de muchas acciones
seguidas con pausas intermedias. Ponme algunos ejemplos, si se te
ocurren, pero en los casos que se me han ocurrido a mí, no es tan grave
si se cambia a que sean todos inmediatos, haciendo alguna pausa sólo en
momentos significativos. Pero no, por ejemplo, entre cada frase y frase
de un PNJ.


> Sigo creyendo que es necesario un bloque tipo <secuencia> que
> simplifique ese caso. El lenguaje de markup SMIL para sincronización
> de multimedia ha llegado a esa misma solución: tiene etiquetas <seq> y
> <par> para la ejecución sucesiva y simultánea de acciones,
> respectivamente.
> (Ver  http://www.helio.org/products/smil/tutorial/chapter4/6.html  ).

Bueno, pero es que la programación de guiones en tiempo real y con
threads paralelos produce unos problemas de sincronización y demás que
son muy complicados incluso para un programador experto, imagínate para
los escritores de salas de Minë. Pienso que debemos reducir la
temporización de cosas a un mínimo, de lo contrario se nos puede ir de
las manos.

Imagínate que para hacer los guiones haya que empezar a tener en cuenta
cosas como inanición, interbloqueos y cosas de esas. A mí este tema me
está dando un poco de dolor de cabeza.


> Por supuesto, la implementación de <secuencia> puede hacerse creando
> un suceso_programado para cada una de las acciones de la secuencia
> posteriores a la primera. Pero queda la duda de cómo cancelar toda la
> secuencia, ¿suceso por suceso?

Pues yo le he dado unas cuantas vueltas y no se me ocurre una manera
genérica y sencilla de gestionar lo de las cancelaciones.

Con el sistema que propongo, aparte de que hay menos secuencias, la
cancelación es muy sencilla: basta con que al principio del guión
programado, se ponga un requisito que pregunte si debe seguir. Por
ejemplo, si nuestro interlocutor aún sigue en la sala, seguimos
hablando; si no, el guión no hace nada más y no llama al siguiente de la
cadena.

P.D. Esto lo suyo sería quedar un día en persona y hablarlo con unos
papeles delante...
-- 

Andrés Moya <address@hidden>

Batman va a la sala para matar a la gran malvada Marta, ya la mata, 
mas la malvada saca la manta para atrapar a Batman, ¿la matará 
Batman... o no? 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]