#1350 cierto, mañana le daré una vuelta a ver
#1345AikonCWD:Pues eso, que llevo 7 horas programando esto de nuevo y estoy enfadado por no haberlo previsto antes.
Es normal que te frustres con esto, pero aunque ahora te parezca que lo deberías haber previsto, en la práctica muchas veces van a surgir cosas que no habrías podido saber antes. Es normal, tampoco te fustigues
#1350 El tema es que tal y como lo tengo implementado, uso tweens para crear el efecto.
Es un nodo que me permite interpolar cosas, en mi caso la propiedad "rotation" de un objeto:
$tween.interpolate_property(self, "rotation", deg2rad(90), deg2rad(-90), speed, Tween.TRANS_SINE, Tween.EASE_IN_OUT)La gracia del tween es que te deja de una forma muy abstracta las cosas. Estoy diciendo que vaya de 90 grados a -90, de forma sinusoide. Por eso el hacha hacer este movimiento de péndulo:
Si cambio el tween a una transición linear quedaría así:
Problemas que veo a esto? El tema de la sincro. Este código no está ni dentro del _physics_process(delta) y por tanto no tengo ni delta ni nada. Quizás me rente más pasar el tween y codear el movimiento a mano y dentro del _physics_process(delta) para que esté "protegido"? En ese caso necesitaría tu ayuda xD
Edit: A quién le mole el tema de la interpolación y transiciones, dejo esta web que muestra las más típicas. Es interactiva: https://easings.net/
Y también una chuleta:
EDIT 2: Veo que puedo hacer trabajar al tween dentro de los callbacks de physics_process(): https://docs.godotengine.org/es/stable/classes/class_tween.html#enum-tween-tweenprocessmode
Voy a probar y te digo algo 
Comprobado. Con el cambio del checkpoint sin PackedScene y con el Tween corriendo bajo physics_process(), el péndulo está sincronizado.
Pero claro, yo lo veo bien en mi PC y con 4 pruebas de stress que acabo de hacer. Sé que me estoy marcando un "it works on my machine" de manual, pero whatever. Paso página con el tema a no ser que alguien con potato-pc me lo reporte
#1353 da igual si actualiza desde _process (a cada frame) o desde _physics_process (a tiempo/paso fijo).
El problema sigue estando presente si usas un delay para iniciar eventos.
No hay garantía alguna de que la máquina esté disponible en el milisegundo exacto. Diseñar evitando este tipo de "conflicto" es algo que te servirá para futuros problemas.
Veo en la docu de tweens que permite setear el tiempo con el método seek.
En vez de usar delays para iniciar de uno en uno cada péndulo... setea con seek diferentes tiempos a cada uno de ellos y después inicia todos a la vez en la misma llamada (sería el equivalente a asignar un valor inicial de ángulo diferente para cada uno).
#1355 hummm, vale. Dejo este cambio del processmode en physics y quito el delay inicial por un seek, me espero a que estén "ready" todas las instancias de las hachas y luego con un "for" les meto start() a todos, no? O mejor hago que cada hacha compruebe un flag y en el momento que esté true se llame a start() ? Llamar a start() a varios objectos dentro de un bucle puede provocar delay?
Osea imagina que tengo 10.000 objetos y hago:
for x in objects:
x.startpuede que entre el objeto 1 y el objeto 10.00 haya algún delay?
#1356 no conozco cómo gestiona Godot internamente esto, pero vamos, ambas opciones no deberían presentar delay, en teoría el engine debería checkar todos los objetos en cada frame.
Aunque, la opción más óptima (y para mí la correcta) es la primera. Cuando tengas el ready usa el for para iniciar todos.
#1357 El lunes me pongo a ello, lo dejo en la sección de bugs de mi trello: https://trello.com/b/j0WscllA/cursed-gem
Gracias por la ayuda.
edot: @dKode done y funciona bien. He tenido que ajustar los valores ya que no es lo mismo el valor que estaba usando para el delay que el valor que he de usar para setear la animación, pero ya funciona bien y creo que no se debería desincronizar.
'Synthwave' nuevo para el boss a ver como queda...
https://drive.google.com/file/d/1xGClBXS35C34GzhXMmV_irC0ykd5u64Y/view?usp=sharing
#1359 bastante wapa, me falta un poco más de algo, en plan se avecina lo bueno o lo malo, pero muy wapa gz
#1360 a ver q se puede hacer por ahora esa es la base luego haré cambios.
Gracias a todos por escuchar
Bueno bueno bueno.
Han sido casi 2 años... pero todo principio tiene un final.
Si todo va bien. Cursed Gem verá la luz en 1 mes. Por el momento os dejo la demo oficial para que podáis testear y jugar:
https://aikoncwd.ovh/cursedgem_demo/
Cualquier feedback será bien recibido. Todavía estoy a tiempo de cambiar algunas cosillas.
edit: Recordad meter en vuestra lista de deseados el juego, aunque no tengáis intención de comprarlo
#1370 Conozco al "dev". Y lo pongo entrecomillas porque realmente es un excelente pixel-artist. He traído alguno de sus tutoriales por aquí, como el de la bola de
pinchos.
La verdad que le ha quedado un juego muy pulido y vistoso. Seguramente me lo pille mañana para ver qué tal va. Por lo que he visto es una sucesión de niveles, en plan N++
LVL9 terminado al 100%, decoración incluida. He solucionado algunos bugs y añadido mejoras en la interfaz, etc...
Mañana empiezo con el nivel10 (final boss). Tengo muchas ideas para los patrones pero todavía no sé como quedarán in-game.
Se viene tremendo churro o tremendo goty.
#1373 Es un crack del pixelart xd.
Estoy probando su juego. Precioso a nivel estético. Muy divertido de jugar. Calcado a la filosofía de N++
A nivel de programación tiene menos cosillas, cosa normal sabiendo que el chaval es pixelartist y ha aprendido GameMaker viendo tutoriales de Youtube (lo pone en los créditos xd).
El movimiento del personaje no me termina de agradar, tiene los saltos scripteados. Un simple toquecito de stick mueve de forma fija al personaje, cosa que hace complicados muchos saltos. No tiene pantalla de opciones, no se puede personalizar el volumen de la música, los niveles son de una habitación. No hay mecánicas de agarre, agua, cajas, botones, puertas, etc... Se parece mucho al CursedGem pero en el momento que lo juegas ves que son juegos muy diferentes.
Por cierto, a quien le molen los plataformas tipo N++ se lo recomiendo.
