Dudas diversas!!

[FreeYourMind]

Free: si tienes FRAME(200) y quieres hacer sólo la comprobación de colisión cada frame, puedes "dividir" el frame(200) y copiar dicho código de colisión en medio. Algo así:

(... tu codigo)
frame(100);
(código de colisión)
frame(100);
(... lo que vaya después de frame(200))

ErPera: get_id te puede devolver el id de un disparo, o cero si no hay ninguno ¡controla ese cero!

Y eso no me va cambiar lo demas en el proceso, digo animaciones, fluides, velocidad, etc ?
Si fucniona te doy un karma maestro!

[Drumpi]

...

ErPera: get_id te puede devolver el id de un disparo, o cero si no hay ninguno ¡controla ese cero!

¿Cómo? Es que es eso... como controlar cada ID del disparo... si hay 2 disparos diferentes... y al pillar la ID del tipo disparo pilla la id de los 2 disparos, y mata todos los procesos disparo, y yo solo quiero matar al que choca, como he puesto en el código

Porque si haces un signal(0,s_kill) puedes provocar comportamientos raros (no recuerdo si mataba a todos los procesos o directamente era un error). Por eso, si usas get_id, antes de hacer el signal, asegúrate de que no vale cero con un if.

Free: si tienes FRAME(200) y quieres hacer sólo la comprobación de colisión cada frame, puedes "dividir" el frame(200) y copiar dicho código de colisión en medio. Algo así:

(... tu codigo)
frame(100);
(código de colisión)
frame(100);
(... lo que vaya después de frame(200))

ErPera: get_id te puede devolver el id de un disparo, o cero si no hay ninguno ¡controla ese cero!

Y eso no me va cambiar lo demas en el proceso, digo animaciones, fluides, velocidad, etc ?
Si fucniona te doy un karma maestro!

Lo demás te va a funcionar exactamente igual que antes: si antes no iba tan fluido, ahora tampoco, sólo va a afectar a lo que haya dentro de los dos frames.
Por cosas como esta se desaconseja el uso de frame(200) en favor de los contadores (sobre todo en las animaciones). Tiene sus usos, pero no como retardo en procesos con cosas que deben comprobarse a cada frame, como colisiones, control por teclado, comunicación con otros procesos, comunicación por red...

[FreeYourMind]

No surje efecto Drumpi, creo que el problema esta en esto:

y = y + 1;

IF (key(_down))
    y = y + 3;
END


Me ocurre si le doy para abajo, la caja que muevo se queda como un pixel por dentro de la que esta debajo al ocurrir la colision, y si dentro de los dos frames pongo

IF (key(_down))
    y = y + 2;
END

o

IF (key(_down))
y = y - 1;
END


igual resuelvo el problema...

[FreeYourMind]

Lo dejó, estoy hasta los huevetes, no tiene nada que ver con frame, con frame(100) ocurre lo mismo, me pasa que a veces las cajas entran una dentro de otra en la colisión 1 pixel y otras veces no ocurre, y esto siempre que le doy a la key(_down), aumentando la velocidad en el eje Y.

[Drumpi]

Ese problema es distinto al que preguntabas (que era cómo hacer collision a cada frame sin modificar el resto del código).
Si no te he entendido mal, tienes el problema de que te colisionan y se solapan demasiado ¿no? Obviamente necesitas que se solapen para que haya colisión, pero ten en cuenta que dada elemento se mueve una determinada distancia (no me queda claro, creo que es 1 pixel por cada dos frames, o 4 si pulsas abajo ¿no?) Si la caja de abajo se mueve, ya no son 4, son más.
¿Estás haciendo un tetris? en ese caso, si usas collision para detectar que ha llegado abajo, después tienes que subir la pieza que cae hasta que deje de colisionar o se te seguirá solapando (tendrías que hacer un loop sin frame, subiendo 1 pixel hasta que deje de colisionar), pero en este caso, la mejor política es preveer si colisionará en el siguiente movimiento midiendo las distancias y la velocidad de movimiento (la distancia entre las Y y la velocidad de caida).

[FreeYourMind]

Bueno, disparo ya, es un columns, en realidad uso dos ciclos loop, yo me refiero al primero en los ejemplos, ya que lo que hago es que al colisionar hago un break con lo cual la caja queda encima de la de abajo y esta entra en el segundo loop en el cual ya no se mueve ni hay control en ella, solo es animada por el loop nada mas.

Pues no entiendo, la caja va siempre con movimiento y = y + 1, si le doy key(_down) le incremento y = y + 3 , que son los 4 que dicen ya que ambos estan en el primer loop, pero si lo hago desde que la pieza aparece en escena esta se solapa siempre, las veces que queda bien es cuando de doy al key(_down) alternadamente de forma no continua desde que aparece la caja hasta que esta sale del loop de movimiento...

[ErPera]

el que colisiona no sale con get_id, sino con collision.

get_id nunca te retorna id de 2 procesos a la vez, eso es imposible retornar en un unico valor de retorno.

Claro, pero ahora mismo no puedo usar esa función, porque lo que colisiona es con la pared, y simplemente hago la comprobación de si choca con ella desaparezca ese disparo. Pero claro, veo que con el get_id no sirve porque el signal se carga todos los disparos.

...

ErPera: get_id te puede devolver el id de un disparo, o cero si no hay ninguno ¡controla ese cero!

¿Cómo? Es que es eso... como controlar cada ID del disparo... si hay 2 disparos diferentes... y al pillar la ID del tipo disparo pilla la id de los 2 disparos, y mata todos los procesos disparo, y yo solo quiero matar al que choca, como he puesto en el código

Porque si haces un signal(0,s_kill) puedes provocar comportamientos raros (no recuerdo si mataba a todos los procesos o directamente era un error). Por eso, si usas get_id, antes de hacer el signal, asegúrate de que no vale cero con un if.

Hago la comprobación y nada... mueren todos los disparos. Me está dejando la cabeza los putos disparitos...
Lo de la imagen que pregunte lo dejé de momento... mientras que no solucione esto, no hay nada que hacer con la otra duda xD

[Drumpi]

Bueno, disparo ya, es un columns, en realidad uso dos ciclos loop, yo me refiero al primero en los ejemplos, ya que lo que hago es que al colisionar hago un break con lo cual la caja queda encima de la de abajo y esta entra en el segundo loop en el cual ya no se mueve ni hay control en ella, solo es animada por el loop nada mas.

Pues no entiendo, la caja va siempre con movimiento y = y + 1, si le doy key(_down) le incremento y = y + 3 , que son los 4 que dicen ya que ambos estan en el primer loop, pero si lo hago desde que la pieza aparece en escena esta se solapa siempre, las veces que queda bien es cuando de doy al key(_down) alternadamente de forma no continua desde que aparece la caja hasta que esta sale del loop de movimiento...

Y si lo dejas caer, seguro que siempre se coloca bien, porque desciende de 1 en 1. El lo que te digo, o subes la pieza, o haces el colisión por cada pixel que avance... o como se ha hecho toda la vida de dios: teniendo un array bidimensional sabes en qué posiciones hay una ficha, y sólo tienes que hacer que desciendan las nuevas hasta que ocupen la siguiente posición superior libre, mirando coordenadas.

[FreeYourMind]

La segunda opcion es la que voy a utilizar y es la que se ve en los otros juegos del mismo estilo en los div-like, porque la primera no me sirve ya que si a veces se queda un pixel abajo y otras un pixel arriba no hay forma de controlarlo.

[SplinterGU]

no, el signal no se carga todos los disparos, no tenes que usar signal(type disparo, s_kill) sino sinal(id_disparo_a_matar, s_kill)

si usas type o 0, mata a todos, evidentemente tenes que controlar que el id que queres killear no sea 0.

[ErPera]

no, el signal no se carga todos los disparos, no tenes que usar signal(type disparo, s_kill) sino sinal(id_disparo_a_matar, s_kill)

si usas type o 0, mata a todos, evidentemente tenes que controlar que el id que queres killear no sea 0.

Yo creo que lo que hago es eso xD, perdonar mi torpeza, pero a lo mejor es al recuperar el ID lo que fallo tontamente.

Code Select Expand


IF(map_get_pixel(0,402,x+1,y)==colorObstaculo)
ID_disp=get_id(type disparo);
if (ID_disp!=0)
signal(ID_disp,s_kill);
end
break;


A lo mejor el fallo es el get_id y recojo el del tipo disparo y no el del disparo en concreto, no se, yo esto lo realizo al llamar al proceso disparo y va contando los pixeles para ver si no hay un obstaculo por delante

[SplinterGU]

si get_id te da 0, es que no encontro procesos de ese tipo o llego al final de la lista de archivos.

pero en ese codigo no estas matando al que toca la pared, sino a todos los procesos disparo.

meter un get_id dentro de un if no hara que la condicion del if aplique al disparo, no tiene sentido ese codigo que has puesto.

deberias una vez obtenido el id del proceso disparo (de cada proceso disparo) comparar un get pixel de id_disparo.x y id_disparo.y.

[ErPera]

si get_id te da 0, es que no encontro procesos de ese tipo o llego al final de la lista de archivos.

pero en ese codigo no estas matando al que toca la pared, sino a todos los procesos disparo.

meter un get_id dentro de un if no hara que la condicion del if aplique al disparo, no tiene sentido ese codigo que has puesto.

deberias una vez obtenido el id del proceso disparo (de cada proceso disparo) comparar un get pixel de id_disparo.x y id_disparo.y.

Creo que te entiendo... no lo sé xD

Poner un get_id(son.x) y otro get_id (son.y) vamos, son es el disparo, y calcular la X y la Y de ese proceso.
Voy mejor encaminado o sigo igual de tieso? xD

[SplinterGU]

no, get_id(son.x) y get_id(son.y) no tienen sentido, ademas de que antes de hacer una operacion sobre un son o cualquier proceso, debes comprobar que el proceso exista con exist a menos que ese id haya sido devuelto por un collision o un get_id.

veo que estamos un poco complicados con todo esto, no se como explicarlo, pero id es el identificados uno de un proceso, get_id devuelve ese id, get_id solo tiene sentido para usarlo con type o un get_id(0) para obtener la lista completa de procesos, get_id(son.x) no tiene sentido e incluso puede dar comportamientos no esperados, ya que estas queriendo obtener el id de procesos cuyo tipo se correspondan con el valor que tiene la variable x del proceso son (hijo).

no se si en el libro de osk o en los tutoriales de windgate abordan estos temas, imagino que si, yo te recomiendo leas dichos textos.

[ErPera]

no, get_id(son.x) y get_id(son.y) no tienen sentido, ademas de que antes de hacer una operacion sobre un son o cualquier proceso, debes comprobar que el proceso exista con exist a menos que ese id haya sido devuelto por un collision o un get_id.

veo que estamos un poco complicados con todo esto, no se como explicarlo, pero id es el identificados uno de un proceso, get_id devuelve ese id, get_id solo tiene sentido para usarlo con type o un get_id(0) para obtener la lista completa de procesos, get_id(son.x) no tiene sentido e incluso puede dar comportamientos no esperados, ya que estas queriendo obtener el id de procesos cuyo tipo se correspondan con el valor que tiene la variable x del proceso son (hijo).

no se si en el libro de osk o en los tutoriales de windgate abordan estos temas, imagino que si, yo te recomiendo leas dichos textos.

Vale vale, de acuerdo. Es que en todo lo que encuentro por los diferentes manuales, los procesos se matan con un collision y claro, al chocar contra una pared o dureza, pues no me vale, es mediante el map_get... pero el error está ahi.. que si en el get_id pongo (type disparo) logicamente se carga todos los disparos que haya, lo cual me rompe los esquemas.
Pues bueno, seguiré indagando que se puede hacer, porque no puedo dejar que las balar atraviesen paredes (sería muy facil matar a los enemigos) ni perder varias balas porque choque una... la forma más parcheada que se me ocurre es mientras que no muera una bala, no puede dispararse otra