Me estoy volviendo locooooo con tanto Bennu!!!! Y ya solo me queda un mes para entregar el proyecto, y voy bastante retrasado, pero me atasco con algunas cosa, que alomejor son tonterias, pero no las soluciono.
Dudas:
1ª Tengo mi personaje y dispara, quiero que si choca contra alguna pared el disparo desaparezca, muera ese proceso. Todo ejemplo que encuentro es con el (collision) pero esto es el choque con una dureza. Si voy buscando el pixel de la dureza como cuando ando, tendria que ir avanzando la bala de 1 en 1 (x+=1) lo cual iría muy lenta, y si voy a velocidad por ejemplo x+=10, no vale la comprobacion de 1 en 1 pixel porque va de 10 en 10.
Al poner:
REPEAT
x+=10;
color=map_get_pixel(0,16,x+10,y);
FRAME;
if(graph!=15)
graph+=1;
end
UNTIL ((x>x+240) OR (color==colorObstaculo))
Los primeros 10 pixeles se los pasa por la piedra, entonces yo quiero avanzar a la velocidad de 10 pixeles pero que si encuentra tal y como disparo a los 5 pixeles la pared que "explote".
La 2ª duda, es que mi personaje, al cambiar de grafico al chocarse contra una pared tambien, ese grafico es mas grande, es decir, es el mismo muñeco pero con la escopeta al hombro, lo que le hace "más alto" el sprite, y al cambiar del sprite de movimiento al de choque, el sprite baja, como si bajara un escalón, y no se como hacer para que se mantenga a la misma altura.
Gracias de antemano!
Saludos!!!.
P.D.:He usado un post anterior para no llenar el foro de post mio con mis torpezas xD
;D
EStudiate el codigo de Castle of dr malvado.
maneja las plataformas como un personaje mas
process plataforma(x,y,graph)
begin
loop
//verificas colision con protagonista con x, y
// codigo para mover plataforma y prota al tiempo - si aplica
// etc
frame;
end;
end;
FreeYourMind:
No consigo pasarme de la primera fase... vamos del principio... no sabia que en el juego las había xD
l1nk3rn3l:
Había pensado eso, pero no estaba seguro si era la manera mas correcta de afrontar una dureza
Graciasss
Ese juego te enseña todo lo que necesitas para hacer un juego de plataformas, es el ejemplo que venia con div.
Nunca hay la forma correcta, hay multiples formas de hacer lo mismo en programación, es esa la magia de este mundillo.
Leer primer post
:D
tendras que hacer tantos get_pixel+if, como sea necesario... hay otra solucion mas compleja, que seria colisionar contra la dureza, pero no tengo tiempo de explicarla, si te revisar el codigo ejemplo que yo hice del sabrewulf, lo vas a ver, pero no voy a poder explicarlo.
Quote from: ErPera on April 06, 2011, 03:02:56 PMSi voy buscando el pixel de la dureza como cuando ando, tendria que ir avanzando la bala de 1 en 1 (x+=1) lo cual iría muy lenta
Haz la comprobación avanzando pixel a pixel, pero "fuera de frame", con un bucle for por ejemplo, vas pixel a pixel comprobando pero
sin llamar a frame, hasta que lo hayas movido los pixeles que quieres que se mueva por fotograma o te topes con un muro, en cuyo caso rompes el bucle....
Quote from: SplinterGU on May 03, 2011, 05:06:44 PM
tendras que hacer tantos get_pixel+if, como sea necesario... hay otra solucion mas compleja, que seria colisionar contra la dureza, pero no tengo tiempo de explicarla, si te revisar el codigo ejemplo que yo hice del sabrewulf, lo vas a ver, pero no voy a poder explicarlo.
Así lo hice, vamos, lo tengo como comentario, pero lo borre al poner el código, ya que creía que no sería la solución mas eficiente... con 10 get_pixel+if
Quote from: La momia que fuma on May 03, 2011, 06:11:41 PM
Quote from: ErPera on April 06, 2011, 03:02:56 PMSi voy buscando el pixel de la dureza como cuando ando, tendria que ir avanzando la bala de 1 en 1 (x+=1) lo cual iría muy lenta
Haz la comprobación avanzando pixel a pixel, pero "fuera de frame", con un bucle for por ejemplo, vas pixel a pixel comprobando pero sin llamar a frame, hasta que lo hayas movido los pixeles que quieres que se mueva por fotograma o te topes con un muro, en cuyo caso rompes el bucle....
Le echaré un ojo a este también, a ver que tal, pero tal y como me ha dicho Splinter ya lo tengo resuelto.
lo que dije yo o lo que dijo momia es basicamente lo mismo, repetir get_pixel e ifs dentro del mismo frame.
Creo que tengo una situación similar, os cuento, mi problema es que tengo un processo en el cual compruebo colision con otro proceso, el objetivo es que al colidir uno con otro estos se paren y queden pegados uno al otro (sus graficos claro), lo que pasa es que utilizo un frame(200) y algunas veces la colision no queda precisa y ambos graficos entran uno dentro del otro, me imagino que es por el frame(200) ya que hace la comprobación de forma mas lenta.
Alguna forma de comprobar la colision dentro del proceso, pero sin alterar el valor del frame y que esta sea siempre precisa ?
Me funcionó lo que decís, solo que me pasa una dudilla, que probablemente sea una tonteria.
REPEAT
while(cont<10)
IF(map_get_pixel(0,16,x+1,y)==colorObstaculo)
[b]ID_disp=get_id(type disparo);
signal(ID_disp,s_kill);[/b]
break;
else
x+=1;
end
cont++;
end
cont=0;
FRAME;
if(graph!=15)
graph+=1;
end
UNTIL (x>x+240)
El signal se carga todos los disparos, es decir el get_id está mal... he probado poniendo (son) en ves de (type disparo) pero nada, ¿Cómo recogo bien el ID?
Y aquí termina mi primera duda de las 2 planteadas ;D
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!
Quote from: Drumpi on May 04, 2011, 07:11:02 PM
...
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
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.
Quote from: Drumpi on May 04, 2011, 07:11:02 PM
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!
Quote from: ErPera on May 05, 2011, 03:15:27 PM
Quote from: Drumpi on May 04, 2011, 07:11:02 PM
...
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.
Quote from: FreeYourMind on May 05, 2011, 03:49:54 PM
Quote from: Drumpi on May 04, 2011, 07:11:02 PM
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...
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...
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.
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).
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...
Quote from: SplinterGU on May 05, 2011, 03:30:30 PM
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.
Quote from: Drumpi on May 05, 2011, 04:51:08 PM
Quote from: ErPera on May 05, 2011, 03:15:27 PM
Quote from: Drumpi on May 04, 2011, 07:11:02 PM
...
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
Quote from: FreeYourMind on May 05, 2011, 10:55:41 PM
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.
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.
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.
Quote from: SplinterGU on May 06, 2011, 01:57:59 PM
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.
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
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.
Quote from: SplinterGU on May 07, 2011, 03:04:52 PM
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
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.
Quote from: SplinterGU on May 09, 2011, 01:29:36 PM
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
si quieres poner un codigo completo, compilable con rescursos para probar, algo simple donde podamos tocar el codigo y mostrarte que estas haciendo mal, no dudes en hacerlo.
Quote from: ErPera on May 04, 2011, 04:52:53 PM
Me funcionó lo que decís, solo que me pasa una dudilla, que probablemente sea una tonteria.
REPEAT
while(cont<10)
IF(map_get_pixel(0,16,x+1,y)==colorObstaculo)
[b]ID_disp=get_id(type disparo);
signal(ID_disp,s_kill);[/b]
break;
else
x+=1;
end
cont++;
end
cont=0;
FRAME;
if(graph!=15)
graph+=1;
end
UNTIL (x>x+240)
El signal se carga todos los disparos, es decir el get_id está mal... he probado poniendo (son) en ves de (type disparo) pero nada, ¿Cómo recogo bien el ID?
Y aquí termina mi primera duda de las 2 planteadas ;D
El problema que yo veo aqui es que estas intentado usar el s_kill cuando en realidad no lo necesitas para nada.
El codigo que pones aqui es el que hace la comprobación de la colisión con la pared... y lo estas haciendo dentro del proceso disparo que esta colisionando, por tanto poniendo dentro del IF que te confirma que ha colisionado cualquier instrucción que te haga salir del repeat solucionara tu problema:
heChocado=false;
REPEAT
while(cont<10)
IF(map_get_pixel(0,16,x+1,y)==colorObstaculo)
heChocado=true;
break;
else
x+=1;
end
cont++;
end
cont=0;
FRAME;
if(graph!=15)
graph+=1;
end
UNTIL (heChocado || x>x+240)
Quote from: gukan on May 11, 2011, 08:19:06 AM
heChocado=false;
REPEAT
while(cont<10)
IF(map_get_pixel(0,16,x+1,y)==colorObstaculo)
heChocado=true;
break;
else
x+=1;
end
cont++;
end
cont=0;
FRAME;
if(graph!=15)
graph+=1;
end
UNTIL (heChocado || x>x+240)
Gracias Gukan!!!!!
Una tontería así de siemple, y le estamos dando vueltas aquí todos como locos, y no era más que eso.
Me a funcionado perfectamente!!!
Un peso de encima que me has quitado, porque llevaba cierto tiempo estancado ahí
-----------------------------------------------------------------------------------------------------------
Mi segunda duda, que puse, más o menos la resolví, pero de modo parcheado, tenía una imagen, y como la que ponia cuando chocara era más alta, pues mi muñeco bajaba, y quería saber, si hay forma de que aunque la imagen de otro movimiento sea más alta que las demás, hay forma de que no coja el centro de la imagen.
Es decir, yo ponía mi personaje corriendo y iba perfecto, pero en el momento que se paraba con la pistola y la ponia por encima d su cabeza, la imagen era mas grande y claro, se ponen los pies bajo tierra.
Supongo que para solucionar eso, tendría que poner a todas las imagenes el mismo alto, aunque sea vacío. Pero ya que puse la duda y el post, pues me aseguro.
Me queda un mes para el proyecto, y puede que esté algo pesado por aquí preguntando las dudas que no encuentre por los manuales y me vayan surgiendo.
La verdad es que se os agradece la ayuda a todos, porque echais bastante el cable.
Quote from: ErPera on May 11, 2011, 03:15:05 PM
Mi segunda duda, que puse, más o menos la resolví, pero de modo parcheado, tenía una imagen, y como la que ponia cuando chocara era más alta, pues mi muñeco bajaba, y quería saber, si hay forma de que aunque la imagen de otro movimiento sea más alta que las demás, hay forma de que no coja el centro de la imagen.
Es decir, yo ponía mi personaje corriendo y iba perfecto, pero en el momento que se paraba con la pistola y la ponia por encima d su cabeza, la imagen era mas grande y claro, se ponen los pies bajo tierra.
Supongo que para solucionar eso, tendría que poner a todas las imagenes el mismo alto, aunque sea vacío. Pero ya que puse la duda y el post, pues me aseguro.
Me queda un mes para el proyecto, y puede que esté algo pesado por aquí preguntando las dudas que no encuentre por los manuales y me vayan surgiendo.
La verdad es que se os agradece la ayuda a todos, porque echais bastante el cable.
Una solucion es esa de crear todal las imagenes iguales, seguramente la solución más facil.
En Div/Div2 (y seguramente tambien en Bennu) tenias la opción de poner puntos de control en la imagen, el punto de control 0 creo que representaba el centro de la imagen y donde se situaba la x,y del proceso. Asi que un punto de control 0 bien situado te permitiria solucionar eso... aunque para esto mejor esperar a alguien que lo confirme y que te diga como se puede hacer en Bennu!
Tal como dice Gukan, cambia el punto de control 0 de la imagen:
-Usando FPGEdit, FPG point edit o cualquier otro programa externo con soporte para cambiarlos.
-Usando SET_CENTER desde el código, esto no modifica el FPG que tengas en disco.
-Usando SET_POINT con el punto 0.
Alternativas no faltan, lo complicado es dar con la posición correcta de dicho punto ^^U
Vale vale gracias.
La verdad es que si... es forma de complicarse lo del punto de control, porque a ver como atino para ponerla en la posición correcta. Así que lo que tendré que hacer será aumentar el tamaño de las imágenes y ya está.
Graciasss!!!!! =)
Pronto volveré para seguir dando el coñazo ;D
Lo normal es cambiar el punto de control, y si estás haciendo un plataformas, ponerlo en el centro, pero a los pies, es una referencia más sencilla de ajustar.
Quote from: Drumpi on May 12, 2011, 07:20:30 PM
Lo normal es cambiar el punto de control, y si estás haciendo un plataformas, ponerlo en el centro, pero a los pies, es una referencia más sencilla de ajustar.
Cierto. La verdad que antes no tenia ni idea para que sirven los puntos de control ni como se usaban. Sabía que se podían poner desde el FPG Edit pero no sabía para que usarlos.
Gracias por la idea!