Comunidad Game Maker

Sí, un triángulo es una figura convexa, entonces el error se produce porque los vértices están en sentido anti-horario; deben colocarse en el sentido de las manecillas del reloj.

Un ejemplo: http://www.comunidadgm.org/preguntas-y-respuestas/problema-con-fisicas/msg110555/#msg110555

Hola The_Aesir

Estaba practicando con SolidWorks y decidí hacer un modelo 3D de Abos.


De repente se me ocurrieron unas teorías sobre su funcionamiento:

No tiene tornillos visibles porque están ocultos bajo las partes rojas, que son tapas, y se abren con una instrucción del software, pero en caso de falla, también se pueden abrir con una llave que se introduce en la parte trasera de de la carcasa.


Cuando las tapas están abiertas es posible ver los tornillos y además unos puertos de conexión que sirven para dar mantenimiento o para comunicaciones.

En el orificio exterior también se puede conectar un cargador para la batería, pero la principal fuente de alimentación son unos vórtices de energía que se forman en la atmósfera (los puntos rojos y verdes), esos vórtices se producen por un contaminante que fué lanzado en épocas pasadas.

Abos tiene unos ojos especialmente diseñados para detectar los vórtices, cada ojo expulsa un tipo de radiación que la da su color, la radiación sirve para detectar varias cosas.

Los ojos están incrustados en una membrana, parecida a un músculo, que se contrae y se expande con pulsos eléctricos lo que permite su movilidad.

La carcasa está hecha de una nano-estructura de aluminio, su sistema computacional es óptico (fotónico), y tiene una cápsula de vacio en el interior que también sirve como antena, por todo eso Abos es es muy ligero y tiene baja densidad, puede volar gastando poca energía.

Entre todas las tecnologías sorprendentes de Abos, la más avanzada es la que le permite volar; es un sistema de ionización de aire extremadamente preciso, Abos se eleva por fuerzas electrostáticas que a su vez generan corrientes de aire alrededor.

No se me ocurre un modo llamativo para explicar el rayo con el que ataca. Y el modo en el que se transforma es más inexplicable, tal vez se transforma usando tecnología "brit", que para un humano es muy difícil entender.

Espero que estas ideas te motiven para crear el segundo episodio. Hasta luego.

Pues hay muchos problemas con el código:

• El objeto no se detecta porque en la línea if instance_exists(a2), a2 es una cadena, pero se requiere un índice para que funcione.
• Otro detalle es que primero "a" se define como cadena y después como índice.
• Además el ciclo puede hacer más repeticiones de las necesarias porque se crea una instancia de "a" sólo cuando "a2" no existe, y tampoco se verifica que "a" existe.
• Y por último a.verdadero = true sólo funcionará con la primera instancia creada y no con la que se acaba de crear.

En los objetos A, B y C, en el evento "(Mouse) Left Pressed", escribe esto:
[gml]with( objeto1 ) sprite_index = spriteX;[/gml]
sólo cambia spriteX por el correspondiente a cada caso.

Es porque keyboard_key_press no se puede evaluar en el if, no devuelve un valor, lo que hace es simular la presión de un botón aunque el botón no se toque. La función correcta es keyboard_check_pressed.

No estoy seguro si show_question funciona en android, tal vez debas usar show_question_async, pero su funcionamiento es diferente. http://docs.yoyogames.com/index.html?page=source%2Fdadiospice%2F002_reference%2Fasynchronous%20functions%2Fshow_question_async.html

El ciclo es el while que penumbra dejó como ejemplo.

No encuentro errores en el algoritmo, sólo se me ocurre que el error es porque las imágenes tienen algún dato corrupto, o el error está en otra parte del código.

En el evento Step, no entiendo porqué comparas el valor de "fps", yo lo cambiaría de esta forma y debería funcionar igual:
[gml]
if( global.enableEffects[0] or global.enableEffects[1] or global.enableEffects[2] )
{
    if instance_exists( dn_controller ) image_blend = draw_get_color();
    else image_blend = c_white;
}
[/gml]

Si, ese suele ser un problema. Las figuras grandes deben dividirse en fragmentos más pequeños. Y hay otro detalle, las figuras deben ser convexas, aunque se pudieran colocar más vértices, esa distribución no va a funcionar.

En las versiones 1.2 y anteriores se instala donde le indicas, a partir de la versión 1.3, aunque se puede introducir una ruta de instalación, los archivos importantes se instalan en ...\nombredeusuario\AppData\Roaming\GameMaker-Studio.

Se pueden instalar 2 versiones sin problemas siempre que una versión sea menor a 1.3, por ejemplo: "1.1 y 1.2" o "1.2 y 1.3". Si vas a instalar 2 versiones nuevas (1.3 o mayores) se deben instalar usando nombre de usuario diferentes, si no los archivos, de la ruta que mencioné, se sobrescriben.

No he probado con la versión "Early Access" (1.99), tal vez funciona diferente.

El problema es que la función instance_create no toma como argumento el nombre del objeto que es una cadena, sino su índice (o puntero) que es un número. Para comprobarlo escribe el nombre de un objeto en el debugger y te dará un número como resultado.

En  :GM8:, la mejor forma de manejar los recursos por medio de sus nombre (como cadenas de texto) es usando ds_maps, aquí está un ejemplo: http://yal.cc/gamemaker-finding-resources-by-name/, y aquí un script para mapear: http://www.gmlscripts.com/script/map_objects.

En  :GMS: buscar por nombre es mucho más fácil; sólo se usa la función asset_get_index http://docs.yoyogames.com/index.html?page=source%2Fdadiospice%2F002_reference%2Fgame%20assets%2Fasset_get_index.html

La expresión más apropiada para terminar un ciclo es break, usa exit cuando estés seguro de que no hay código posterior que deba ejecutarse.

Y random(x) si devuelve 0, pero es muy poco probable y depende mucho de la semilla que está asignada.

Por fin tuve tiempo de implementar la idea que tenía, pero en vez de usar listas usé paths, ya que permiten guardar parejas de valores.

Adjunto el editable, funciona, pero aún se puede optimizar bastante, el principal defecto es que la colisión se detecta en el evento Draw, eso no es recomendable, lo hice así para aprovechar el mismo ciclo "for".

La verdad es que éste problema me dio muchas ideas, por ejemplo, hacer un sistema de plataformas con terreno irregular sin usar objetos para ello ,sólo se usarían tiles y paths, presiento que será un sistema altamente optimizado. También mejoraré el script collision_path para que se pueda usar con paths suavizadas.

Espero que continúes con tu proyecto.
Hasta luego.

Ya lo probé, parece que la solución es aumentar el depth de las puertas para que su evento Room End se ejecute antes que el de la rana. Además recomiendo no crear objetos puerta para cada habitación, mejor crea un sólo objeto puerta y en el editor de rooms asigna un "Creation Code" diferente para cada instancia (click derecho), y las puertas no deben ser persistentes.

En el evento Create, define una variable para la transparencia del texto y otra para indicar que se haga transparente, por ejemplo:
[gml]
alfa_score = 1;
desvanecer = false;
[/gml]
Cuando las ocurran las condiciones que necesitas haz desvanecer = true.
Y en el evento Draw cambia la transparecncia
[gml]
draw_set_alpha( 1 );
//Aquí se dibuja todo lo demás

if( desvanecer and alfa_score > 0 ) alfa_score -= 0.01;
draw_set_alpha( alfa_score );
draw_text( x,y, string(score) );
[/gml]

Olvidé que la nueva posición se define en el evento Room End. Se me ocurren 2 causas para ese error, la primera es que la nueva posición asignada no es la correcta, y la otra es que en el evento Create se asigne una posición diferente, se puede depurar colocando éstas líneas de código al final de los eventos correspondientes:
[gml]
show_debug_message( "Room End: "+string(x)+" "+string(y) );
[/gml]
[gml]
show_debug_message( "Room Start: "+string(x)+" "+string(y) );
[/gml]
Los mensajes aparecerán en la ventana "CompileForm" (en la parte de abajo de GMS), observa que los valores coinciden y que son los correctos.