Acabamos de comprobar que S_KILL_TREE mata procesos recorriendo el árbol en profundidad. ¿Hay alguna forma de especificar que queremos matar recorriendo el árbol en anchura? ¿O el comportamiento es siempre el mismo?
Asias!
tree es un tree... no entiendo a que llamas anchura...
Desde tiempos de DIV, s_kill_tree mata a un proceso, a sus hijos, a los hijos de susu hijos, a los hijos de los hijos de sus hijos y así en bucle loop.
¿Matar en anchura significa matar a sus hermanos?
Me refiero al orden de muerte, y lo pregunto por simple curiosidad.
Supongamos un padre A con 2 hijos B y C.
B tiene un hijo llamado X y C tiene un hijo llamado Z.
Si matamos en profundidad vamos de cada raiz hacia arriba, morirían en este orden:
X - B - Z - C - A
En cambio si matamos en anchura vamos subiendo niveles desde la raiz, moriría en este orden:
X - Z - B - C - A
La teoría de árboles nos dice que para recorrer un árbol se pueden seguir varios métodos, los más fáciles de implementar son profundidad y anchura, pero había unos cuantos más.
Esta tarde haciendo unas pruebas hemos descubierto que la muerte en árbol iba en profundidad, es complicado de explicar... Es como si en el caso anterior el proceso X invocase un proceso A... X mandaba una señal a A y moría X, luego B, luego A y ya no se podía seguir matando a C y Z porque quedaban huérfanos...
En anchura no hubiese pasado eso... Me ha parecido curioso y he concluido que Bennu mata un árbol recorriéndolo en profundidad.
PD: Siento machacaros el cerebro con una cosa tan rara, al final evitando que el proceso X invocase un proceso A convirtiendo el árbol en un grafo se ha solucionado todo el problema, el árbol moría sin que sucediese nada "raro".
no, imposible, son ramas de arboles diferentes... eso no suena logico para nada.
podes matar hermanos, recorriendolos desde un nodo...
¿Quieres decir entonces que la muerte en anchura es imposible, verdad? (Al menos sin complicar excesivamente la cosa...)
Ciertamente la Jerarquía Bennu (father, son) está hecha para recorrerse en profundidad, no en anchura :P
Aclaración resuelta y las S_XXX_TREE actuan en profundidad.
Gracias.
Hombre, más que nada creo que es porque estas funciones funcionan por recursividad, algo así como:
process matar(id_proceso)
hijo=id_proceso.son;
while (hijo!=0)
matar(hijo);
hijo=id_proceso.son;
end
signal (id_proceso,s_kill);
end
Obviamente, cada vez que se invoca al proceso matar, el primero espera a que se ejecute el recién creado, por eso funciona como funciona. Te lo he puesto en código PseudoBennu para que lo analices tranquilamente.
Hacerlo en anchura, como dices, es mucho más complejo, y dado que todo el arbol va a morir en el mismo frame (incluso no va a dar tiempo a ejecutar otros procesos), debería dar igual el orden en que desaparezcan ¿no?
Drumpi, entiendo tu código, ¿Entonces se mata desde el padre hacia los hijos? Eso había pensado que era al revés por cómo había programado en su día recorridos de árbol... Pero para el caso tanto da.
No hay problema en casos normales, pero nosotros teníamos una jerarquía de procesos que no era un árbol, era un grafo, me explico a groso modo:
Teníamos un proceso crear_escenario que primero mataba a todo bicho viviente con S_KILL_TREE y luego invocaba toda la fauna y flora del juego.
El problema era que uno de los personajitos era el encargado de volver a invocar a crear_escenario, por lo que teníamos un "bucle", la señal de muerte perseguía a los procesos por el grafo y terminaba matando al propio proceso crear_escenario, y a sus hijos, y...
Hemos observado que cuando ocurría eso algunos procesos quedaban vivos, y hemos concluído en que la señal avanzaba en profundidad, "se saltaba algunas ramas" porque se quedaba en ese bucle del grafo, nada más.
Como he dicho (No sé si me he explicado todo lo bien que debía), después de evitar el grafo todo iba bien y no importaba en absoluto el orden de muertes, como debe ser.
Con esto quiero decir que todo está en orden y la duda resuelta, se puede cerrar el hilo si queréis, como siempre un placer dialogar con ustedes, thanks.
No, no, lo has entendido al revés: va matando de los hijos al padre, pero se distribuye desde el padre a los hijos. Fíkate que se llama a sí mismo, un hijo más abajo ANTES de ejecutar el signal, así que el signal sólo se ejecuta cuando no tiene hijos o los procesos muerte que invoca han terminado.
Es como los procesos: al llamar a un proceso, este no se ejecuta al llegar al frame, interrumpe al padre y se ejecuta hasta su propio frame, y luego el padre sigue su ejecución normal.
Oh, es recursivo, que no me había fijado, entonces es como lo que programé sobre árboles en su día, se llegaba al nodo sin hijos y desde ahí se "trabajaba la estructura".
Ok, todo claro, dejemos la conclusión para cerrar el hilo:
S_XXX_TREE recorre el árbol de procesos en profundidad y afecta desde los hijos (Nodos hoja) hacia la raiz.
Reabro.
No me esta funcionando el s_kill_tree....
Ejemplo, en el main:
Pinto una imagen en pantalla llamando a a(), que dentro de si pinta la imagen llamando a b() (es b() quien pinta la imagen con un loop frame; end), pues sólo desaparece la imagen si mato directamente a b(), si mato a a() no desaparece y si mato a a() con kill_tree tampoco...
signal(type a, s_kill); // a() muere (eso creo) pero su hijo b() se mantiene
signal(type b, s_kill); // Funciona, b() muere, a() se mantiene vivo (eso creo)
signal(type a, s_kill_tree); // --> Error: a() muere (eso creo), pero b() que es su hijo se mantiene vivo
Humm, ¿crees o estas seguro?,yo hecho miles de pruebas y todos los signal me funciona bien,hacen lo que espero que haga, ¿Seguro que b() se crea dentro de a()?
No estaria mal que pusieras el codigo ^^
Has probado signal(id, s_kill_tree); / signal(id_proceso, s_kill_tree); ?
Es que no se el id del proceso, por eso pongo type, en realidad son muchos iguales que quiero matar.
Bueno, ya he asignado el id y tampoco funciona:
PRIVATE
ft;
BEGIN
LOOP
say(ft);
IF (ft != 0)
signal(ft, s_kill_tree);
END
ft = a();
FRAME;
END
Esto tampoco mata los hijos de a(), que son los procesos b().
Prueba esto...[code language="bennu"]program skilltree;
import "mod_proc";
import "mod_grproc";
import "mod_say";
private
int ft;
int estadob;
end
process a()
begin
b();
loop
frame;
end
end
process b()
begin
say("b creado "+id);
loop
frame;
end
end
begin
ft = a();
loop
say(ft);
if ( ft!=0 )
signal(ft, s_kill_tree);
// signal(ft, s_kill); //alternar con la sentencia de arriba para ver los cambio
say("muerte de a");
estadob=get_id(type b);
if ( estadob!=0 )
say("b esta vivo "+estadob);
else
say("b tambien a muerto "+estadob);
end
end
estadob=0;
ft = a();
frame;
end
end[/code]
Antes de probar un reparo, el proceso a(), seria así:
process a()
begin
b();
end
Tu ejemplo de debug comprueba mis resultados:
Esto ocurre siempre:
"muerte de a"
"b esta vivo"
o sea, b nunca muere y deberia.
Pero si lo haces asi,eso quedaria asi ....
Creo el proceso "A" ,el proceso "A" crea el proceso "B", el proceoso "A" llega a su fin y desaparece , y el proceso "B" queda huerfano... con lo que no puedes enviar una señal a "A" porque ya no existe en el siguiente FRAME...
aun asi, S_kill_tree, ya no te funcionaria puesto que "B" ya no tiene madre/padre como lo querais llamar...
Grácias ya me has resuelto las dudas, entonces como ya no tengo a() (tampoco necesito mantenerlo vivo con el loop frame) pues entonces lo correcto es matar el hijo huerfano b() con s_kill.
Karma Up.
:P
free, siempre es importante poner el codigo de prueba que confirme lo que vos decis no esta funcionando, asi nos evitamos paginas de respuestas y vos (y todos nosotros) tambien evitamos perder tiempo valioso.
si hubieses puesto ese codigo, e incluso el que mata, se te hubiese respondido mas rapido.
Lo se, pero si decia que el a() sólo creaba el proceso b(), logicamente con esto digo, que en a() no hago nada más que esto. :D
cuando decis eso, suponemos que a() hace otras cosas y estas en un loop con frame, o sea, la logica no esta en lo que decis, la logica esta en que nunca podemos imaginar (por lo menos yo) que se te ocurriria hacer un kill a un proceso que murio, por eso puse el avatar con lengua, puff; un error de novatos, y vos no sos novato en esto.
DjSonyk, karma para ti.
Naa Splinter ultimamente me aburro que no se habla mucho por aqui,y entre desesperación y pegandome con los dichos graficos de las narices,pues hacer algo util me relaja,con todas las cosillas que tengo en mente por hacer y atascado por no saber pintar ,en fin,por cierto me alegro que te sacara la duda Free... ^^
Quote from: SplinterGU on July 22, 2010, 03:43:58 PM
cuando decis eso, suponemos que a() hace otras cosas y estas en un loop con frame
(http://4.bp.blogspot.com/_6s_tDzAFKh0/RlYABkgtBsI/AAAAAAAAADk/fQEaiy6GVh0/s400/lo+que+no+debes+decir.jpg)
si, yo he estado desaparecido un tiempo, me estoy recuperando de una operacion de hemorroides que me hicieron este sabado pasado, y aun no fui al servicio, y entre los calmantes que me dejan palmado, me tiene un poco molesto eso.
free, quizas no me supe explicar, disculpame... lo que digo es que no es logico que quieras matar un proceso que no existe, si vos decis que mandas una señal kill_tree a a() para que mate a el y a su hijo, es porque vos (free) ya sabes que ambos estan vivos, sino no tiene logica.
Joer, es que te tienes que disculpar por todo ;D
Sobre lo de suponer, ni te digo los ojos que me echaba mi jefe cada vez que le decia "supongo" sobre algo del proyecto, heheehh ;D
Sobre el proceso, pues ya ni me acordaba que estos morian al final, así de sencillo ;)
je... todo bien... :)
Yo lo que veo es un error garrafal el hacer:
signal(type a,s_kill_tree);
No tiene sentido: type a tendrá un valor que no tiene nada que ver con la ID de un proceso, sino un valor interno del planificador que lo cataloga como tipo de proceso.
Para obtener la ID de un proceso se usa get_id(type a), así sí, máxime si sólo existe un proceso a (porque nos devolverá su ID). Si hay más de un proceso a, o b, tendrás que identificar el que buscas mediante una de sus variables locales o públicas.
puede tener sentido, imaginate que tengo un proceso entidad, dicho proceso tiene varios miembros que le pertenecen, es util poder querer matar al proceso tipo entidad y a todos los miembros del mismo, pensa, personaje, que tiene brazos, piernas, cabeza, pies, manos, yo quiero matar todos los tipo personaje y que se vaya todo, yo cuando cree el proceso cree el proceso "personaje" y no se, ni tengo que saber, si personaje es 1 solo proceso o son muchos, a mi no me interesa, a mi solo me interesa que muera, entonces el kill type con tree es lo que se debe hacer, tambien podemos usar el metodo onexit y hacer que personaje mate a todos, eso es mas correcto, pero pensa que eso no existia antes.
Yo estoy viendo que os liais mucho con algunas sentencias,pensais que hacen otra cosa a la que estan destinada o no se...
Pero signal(type a,s_kill_tree) significa "Mata todos los procesos A y a sus descendientes..." mas exactamente,"Mata todos los procesos "A" QUE ESTEN VIVOS y a sus descendientes...",esta señales para los descendientes de A,que su madre (A) halla muerto no les dice nada,vamos no les matan...
Evidentemente querer mata a un tipo de proceso A especifico no se puede hacer con Type,pues mata a todos los procesos de ese tipo y si te las arreglaras para enviar solo un signal(type a,s_kill_tree) podrias destruir cualquier proceso A y seguramente no el que quisieras, para eso hay que hacerlo de otra forma, ya sea poniendole un identificador al crearle,pasarle un parametro al crearlo ,ect..
Aun me queda por decir, que todas las sentencias que he usado en Bennugd,no todas pero muchisimas,hacen exactamente lo que tiene que hacer o hacen lo que hacian en DIV ,el usarlas bien o mal ya solo depende del propio programador...
¿Pero signal no requiere como primer parámetro el ID de un proceso? yo no he leido en ninguna parte que se pueda especificar un TIPO DE PROCESO, que son cosas muy distintas.
Yo, cuando quiero matar todos los procesos de un tipo uso un loop así:
temp=get_id(type mi_proceso);
while (temp)
signal(temp,s_kill);
temp=get_id(type mi_proceso);
end
Eso es perder tiempo, si ya te han dicho que lo otro es lo que hace.
Yo lo utilizo para matarlos todos del mismo tipo y funciona de perlas.
claro, estabas codificando demas... un simple signal( type mi_proceso, s_kill ) es suficiente
lo mismo si haces un signal(0, s_kill) mata todos los procesos.
Quote from: SplinterGU on July 25, 2010, 05:13:56 AM
claro, estabas codificando demas... un simple signal( type mi_proceso, s_kill ) es suficiente
lo mismo si haces un signal(0, s_kill) mata todos los procesos.
let_me_alone();
Drumpi: temp=get_id(type mi_proceso) y signal(type mi_proceso,s_kill) son anologas,salvando la diferencia que con la primera se coge el identificardor de los procesos para por ejemplo poder manejarles , temp.x=10, consultarles ,dame_x=temp.x, matarles signal(temp,s_kill),ect y la segunda coge los identificadores del proceso especificado para mandarles directamente la señal...
Leer por lo que veo que lees poco, (es de coña ;P),porque viene en el manual de DIV y DIV2,no se si en alguno otro mas manual mas vendra ,seguro que si,como en la wikipedia...
La incoveniente,si esque lo es, de signal(type mi_proceso,s_kill) es que con una sentencia destruyes todos los procesos del tipo especificado,con lo que si solo quisieras destruir alguno de ellos esta sentencia no te valdria.
Quote from: FreeYourMind on July 25, 2010, 12:38:05 PM
Quote from: SplinterGU on July 25, 2010, 05:13:56 AM
claro, estabas codificando demas... un simple signal( type mi_proceso, s_kill ) es suficiente
lo mismo si haces un signal(0, s_kill) mata todos los procesos.
let_me_alone();
si y no, no es exactamente lo mismo, let_me_alone fuerza la muerte de todos los procesos sin importarle nada, en cambio, signal( ALL_PROCESSS, ...), o sea, signal( 0, ... ), mata todos los procesos pero tiene en cuenta los signal_actions.
Quote from: DjSonyk on July 25, 2010, 01:35:35 PM
Drumpi: temp=get_id(type mi_proceso) y signal(type mi_proceso,s_kill) son anologas,salvando la diferencia que con la primera se coge el identificardor de los procesos para por ejemplo poder manejarles , temp.x=10, consultarles ,dame_x=temp.x, matarles signal(temp,s_kill),ect y la segunda coge los identificadores del proceso especificado para mandarles directamente la señal...
Leer por lo que veo que lees poco, (es de coña ;P),porque viene en el manual de DIV y DIV2,no se si en alguno otro mas manual mas vendra ,seguro que si,como en la wikipedia...
La incoveniente,si esque lo es, de signal(type mi_proceso,s_kill) es que con una sentencia destruyes todos los procesos del tipo especificado,con lo que si solo quisieras destruir alguno de ellos esta sentencia no te valdria.
pero el caso es que se quiere destruir procesos type, no entiendo para que drumpi menciona de matar uno individual.
Por desgracia, carezco del manual de DIV (y el DIV no me funciona en el SO que suelo usar), el 80% de las veces que busco en la wiki (tanto la de aqui como la de Fenixworld, porque la de divsite y la de jlceb están caidas) me dice que no existe.
La ayuda que uso es la que tengo a mano: un archivo .hlp de Fenix 083b y que dice:
QuoteINT SIGNAL ( INT proceso, INT señal )
Esta función cambia el estado de un proceso o, si recibe como parámetro una de las constantes acabadas en _TREE, de un proceso y de todos sus hijos y descendientes.
Existen cuatro posibles estados para un proceso: WAKEUP: el estado por defecto. El proceso se ejecuta normalmente cada frame, y si su variable GRAPH contiene algún valor, se dibuja un gráfico en pantalla en las coordenadas especificadas por sus variables locales x e y. FREEZE: el proceso está detenido, de manera que su código no se ejecuta cada frame, Sin embargo, su gráfico sí que se dibuja normalmente. SLEEP: el proceso está durmiente. Su código no se ejecuta, ni tampoco se dibuja su gráfico en pantalla. KILL: el proceso está marcado para morir. Si este frame todavía no se ha ejecutado, no se ejecutará ni se mostrará en pantalla. Antes de comenzar el siguiente frame, la memoria ocupada por el proceso será liberada y el proceso desaparecerá de la lista interna.
La función SIGNAL puede cambiar en cualquier momento el estado de un proceso o de sus hijos. Los cambios no afectan al proceso actual hasta que su ejecución termine por llegar a la sentencia FRAME. De la misma manera, el proceso padre (y el resto de antecesores) no se verán afectados por los cambios hasta la sentencia FRAME.
Parámetros:
INT proceso: Identificador de un proceso
INT señal: Tipo de señal a enviar al proceso. Puede ser una de las siguientes constantes predefinidas: S_KILL S_WAKEUP S_SLEEP S_FREEZE S_KILL_TREE S_WAKEUP_TREE S_SLEEP_TREE S_FREEZE_TREE
Ejemplo:
PROGRAM mi_juego;
PRIVATE id2;
BEGIN
id2=mi_proceso();
// ...
signal(id2, s_kill);
END
PROCESS mi_proceso()
BEGIN
// ...
LOOP
FRAME;
END
END
VER TAMBIÉN:
GET_ID
Pues nada, ya lo se para otra vez, y me ahorro bucles.
nah, drumpi, aceptalo, no excuses...
http://wiki.bennugd.org/index.php?title=Signal
La función SIGNAL puede cambiar en cualquier momento el estado de un proceso o de sus hijos. Los cambios no afectan al proceso actual hasta que su ejecución termine por llegar a la sentencia FRAME. De la misma manera, el proceso padre (y el resto de antecesores) no se verán afectados por los cambios hasta la sentencia FRAME.
Cambios en BennuGD con respecto a tu cita Drumpi:
En BennuGd la sentencia SIGNAL se ejecuta al instante no al llegar al siguiente FRAME,acausa de eso,es lo que mas me a tocado corregir al hacer las portaciones de mis "juegos"de DIV a Bennu,para que nadie se confunda con la cita :P.
Ya que estamos tengo un error con freeze, no me congela el proceso que quiero, este proceso hace una animacion y coloca el gráfico en distintas posiciones durante un tiempo, pues bien, si llamo el proceso espera(), quiero que este congele el proceso anim() durante otro cierto tiempo, pero no esta funcionando, pongo el ejemplo:
PROCESS espera()
PRIVATE
t = 0;
BEGIN
LOOP
t++;
SWITCH (t)
CASE 0:
signal(type anima, s_freeze); // No funciona, la animación random sigue ocurriendo!
CASE 18:
signal(type anima, s_wakeup);
END
END
FRAME;
END
END
PROCESS anima()
PRIVATE
Vel;
BEGIN
graph = 350;
x = 91;
y = 182;
z = -1;
LOOP
FROM Vel = 1 TO 100;
// Random
IF (1 == rand(1, 3))
graph = 350;
x = 91;
y = 182;
ELSE
IF (1 == rand(1, 3))
graph = 351;
x = 132;
y = 182;
ELSE
graph = 353;
x = 132;
y = 194;
END
END
FRAME(Vel);
END
FRAME;
END
END
¿Has probado a subir el tiempo de t a un numero mucho mas alto? 18 me parece poco y mas si tienes los FPS bastantes altos ,date cuenta que si por ejemplo lo tienes a 60 FPS , el tiempo que va a estar congelado es mas o menos , 60/18*procesos activos...es menos de 1 segundo lo que estara congelado...
Lo tengo a 24fps, el problema es que sólo lo necesito congelado ese pequeño instante, porque es en el cual hago otras animaciones que no he puesto por simplificar, y esto tiene que congelarse sólo este instante si o si, ya que es mi objetivo.
Deverias subir el case a por ejemplo 5000; para ver si realmente no te funciona y mirartelo mas despacio,te lo digo porque a simple vista creo que es por eso,y si ves que no se te congela mirartelo tranquilamente,y si te funciona y reduciendolo hasta que quedes sastisfecho ^^
Es lo que voy hacer. Pero date cuenta que en ese pequeño tiempo hago 3 animaciones que son crear/destruir 3 veces un proceso con una imagen, así que si tengo tiempo para eso (el cual se tiene tiempo de visualizarse) tambien deberia tener tiempo para que este proceso se congele.
No puedo cambiar el tiempo en la version final, porque estoy imitando el juego original que hace las animaciones exactamente en ese periodo de tiempo. Tendria que hacerlo de otra forma, porque aumentar el tiempo seria lo mismo que quedar en la mierda y no poder imitar el original, que es justo mi objetivo ;)
Bueno, no hay que comerse mucho el coco, he quitado el wakeup, o sea, tenia que quedarse congelado para siempe y no lo hace...
Free solo te digo que el case 18 lo cambies por case 18000 ,por ejemplo,para que puedas ver si realmente se congela el proceso o tienes algun error por ahi,si ves que se congela ,vamos que funciona correctamente todo ajustes el case al tiempo que quieres que este congelado, o cambie el case por un temporizador y le congelas en milisegundos,no te digo que cambies el tiempo para que lo dejes cambiado sino para ver si realmente se congela...
Ok,pues hay algo que anda mal..voy a mirartelo..
Si te he dicho que le he quitado el wakeup, olvidate del valor del case, porque lo congelo al case 0 y así deberia quedarse eternamente :D
Esos case les falta el end, ¿eso es aqui en el codigo que as puesto de ejemplo o tambien les falta en tu codigo?
Ains.... Free te digo porque no se congela,o mejor te dejo que lo veas.... es un fallo tonto.... :P
pon t++ antes del frame o despues del case 0 o CASE 1: signal(type anima, s_freeze); // No funciona, la animación random sigue ocurriendo!
te explico el porque , ¬¬
Joer, te lo juro estaba pensando que el case 0 igual no ocurria, he puesto case 1 y se ha arreglado :)
Grácias :-*
Funciona de maravilla, se congela sólo el tiempo que quiero ;)
Te lo explico entoces:Case 0 funciona se puede usar,pero haces un preincremento de "t" antes del swicth con lo que t valdra como minimo 1 ,y nunca se cumplira el case 0 ... lo dicho un fallo tonto que puede volver loco a cualquiera hasta el programador mas experto... Me alegro que te funcione de maravilla...
No necesitabas decirmelo heheheh, si lo he visto, un fallo super tonto :)
Curiosamente las cosas que hacia en case 0 era matar procesos que la mayoria podria no existir todavia, por eso no me habia fijado que no funcionaba, ya que lo de freeze sólo lo puse en los ultimos cambios del procedimiento.
Quote from: FreeYourMind on July 25, 2010, 11:52:28 PM
Joer, te lo juro estaba pensando que el case 0 igual no ocurria, he puesto case 1 y se ha arreglado :)
Grácias :-*
Funciona de maravilla, se congela sólo el tiempo que quiero ;)
Entoces no entendi lo que querias decir...bueno animo con el proyecto que tengo ganas de jugar con el... :P
Quote from: DjSonyk on July 25, 2010, 08:35:40 PM
La función SIGNAL puede cambiar en cualquier momento el estado de un proceso o de sus hijos. Los cambios no afectan al proceso actual hasta que su ejecución termine por llegar a la sentencia FRAME. De la misma manera, el proceso padre (y el resto de antecesores) no se verán afectados por los cambios hasta la sentencia FRAME.
Cambios en BennuGD con respecto a tu cita Drumpi:
En BennuGd la sentencia SIGNAL se ejecuta al instante no al llegar al siguiente FRAME,acausa de eso,es lo que mas me a tocado corregir al hacer las portaciones de mis "juegos"de DIV a Bennu,para que nadie se confunda con la cita :P.
Quote from: FreeYourMind on July 25, 2010, 10:41:53 PM
Ya que estamos tengo un error con freeze, no me congela el proceso que quiero, este proceso hace una animacion y coloca el gráfico en distintas posiciones durante un tiempo, pues bien, si llamo el proceso espera(), quiero que este congele el proceso anim() durante otro cierto tiempo, pero no esta funcionando, pongo el ejemplo:
PROCESS espera()
PRIVATE
t = 0;
BEGIN
LOOP
t++;
SWITCH (t)
CASE 0:
signal(type anima, s_freeze); // No funciona, la animación random sigue ocurriendo!
CASE 18:
signal(type anima, s_wakeup);
END
END
FRAME;
END
END
PROCESS anima()
PRIVATE
Vel;
BEGIN
graph = 350;
x = 91;
y = 182;
z = -1;
LOOP
FROM Vel = 1 TO 100;
// Random
IF (1 == rand(1, 3))
graph = 350;
x = 91;
y = 182;
ELSE
IF (1 == rand(1, 3))
graph = 351;
x = 132;
y = 182;
ELSE
graph = 353;
x = 132;
y = 194;
END
END
FRAME(Vel);
END
FRAME;
END
END
ay muchacho, lo tuyo es mortal! el t++ antes del switch hace que nunca la funcion entre en el "case 0:" ya que 0++ = 1
ya veo que en la pagina 4 te dijeron cual era el error...
esto no es un fallo tonto que le pasa a cualquier programador experto, hay que usar el debug y/o el comando say, si hubieses puesto un say dentro del case hubieses visto que nunca entra, y si hubieses puesto un say antes del switch de la variable t, te hubieses dado cuenta.
se que te reto constantemente, pero no quiero que se mal interprete, es para que te mejores a ti mismo.
tenemos que tener cuidado cuando decimos, tengo un error en tal funcion, sin hacer un analisis correcto, con debug, says y todo lo posible para confirmar que el error se encuentra ahi.
con 2 simples say, tu problema se hubiese resuelto.
Lo que has dicho sobraba, hehehehehehehh ;D
si, lo se, pero es que tambien me siento incomodo corrigiendote todo el tiempo.
Pues yo creo que no sobra, de hecho, es el mejor consejo sobre debug que existe, al que añado, además de "show" (debug) y "say" el comando "write_int" y un proceso que cambie los FPS usando F1 para "slow motion" y F2 para "normal motion".
buena idea la del cambio de fps in-game... la anoto :)