Jump to content

lightbug

Registrados
  • Content Count

    2,422
  • Joined

  • Last visited

  • Days Won

    210

lightbug last won the day on January 6

lightbug had the most liked content!

Community Reputation

832 Excellent

About lightbug

  • Rank
    Leyenda

Profile Information

  • Especialidad
    Coder

Recent Profile Visitors

3,282 profile views
  1. Usar una maquina de estados, quizás separando la lógica por estados puedas habilitar/bloquear diferentes funcionalidades dependiendo del estado del personaje o juego en general. Por ejemplo, separando el clásico "Locomotion" (movimiento básico) del "ataque especial", de esta menera usar uno no influye en el otro.
  2. Es probable que puedas "engañar" al sistema creando events por código. https://docs.unity3d.com/Packages/com.unity.inputsystem@1.0/manual/Events.html El ejemplo de la página (necesitas usar el namespace InputSystem.LowLevel) // Send event to update leftStick on the gamepad. InputSystem.QueueDeltaStateEvent(Gamepad.current.leftStick, new Vector2(0.123f, 0.234f) ); Quizás puedas reemplazar esto por Mouse.current, recuerdo que lo hice en su momento. De argumento le pasas la posición actual. No se si sea la mejor solución, es probable que si necesitas actualizar frame a frame UI no sea lo más efectivo, no lo se.
  3. Muy buena atmósfera! Hay demo??? 😬
  4. Tenes que usar "root motion", nada mejor que la documentación de Unity Unreal para explicar esto (mirá los videos de abajo): https://docs.unrealengine.com/en-US/AnimatingObjects/SkeletalMeshAnimation/RootMotion/index.html No es tan fácil, tenés que usar un hueso raíz (de ahí el root) que será el padre de los demas huesos (los deformables, no los de ayuda como pueden ser los IK) y además deberá contener la información del desplazamiento lineal/angular, es decir, tendrás que animar este hueso de tal manera de que represente el movimiento/rotación de tu personaje. En unity root motion se usa de dos maneras: Dándole a "Apply root motion" en el Animator. El Animator mueve a tu transform/rigidbody automaticamente. Extrayendo los datos del desplazamiento y re-aplicandolos (si fuera necesario) usando OnAnimatorMove. El animator, en este caso, te marca "handled by script". Aclaro: Root motion no es algo que debas hacer, como dijo @Igor probablemente con animaciones in-place sea más que suficiente (y procesar el desplazamiento/rotación dentro de un script). No se qué es realmente lo que intentas hacer.
  5. Amén🙌, por el tema de mis assets recibo muchos mensajes diciendo que 2020.1.x (en particular esta horrible versión) anda mal, que el editor muestra cosas que no debería, que se imprimen errores de todo tipo relacionados a Unity, que los blend trees no aparecen (increible que hayan lanzado la versión con este epic fail), etc etc etc. Mi respuesta es simple: "Hay una sola 'versión oficial' de Unity y es la LTS, todo lo demás son betas y alfas ... aunque ellos no te lo quieran decir". No digo que tenga que ver con este inconveniente en particular, pero visto que a veces existen errores que están fuera de nuestro alcance, lo mejor es empezar con la versión más estable de todas.
  6. @francoe1 él sapeee 🧙‍♂️🙌
  7. Solamente preguntaba si esta era la primera vez que hacías la build (android o no). Si así lo fuera (y te siguiera dando error), probablemente el problema no estaba en la build ni en la configuración, sino en el código (ej: no te la hace ni para desktop). Ahora, si ya has hecho varias builds en el pasado esto claramente no es el problema.
  8. Creo que te dice IL2CPP por Mono PD: ¿Intentaste compilar para otra plataforma? porque Unity es medio malo comunicando errores de build de forma directa, en mi caso tenía código de Editor que estaba "saliendo a la build" y claro me daba error (solo pasaba al hacer la build).
  9. O se detectan entre ellos o simplemente detectan otros objetos, como dicen arriba seguramente te pase esto ya que (asumo) no los estás filtrando. 1. Si usas tags, es basicamente lo que ya postearon arriba, aunque prefiero usar CompareTag (y no "== string"). if (other.gameObject.CompareTag( "Player" )) SonidoAusar.Play(); 2. Si usas layers debes clasificar a los objetos involucrados, y además habilitar o no las colisiones en la matrix de colisión (Physics Settings). Además, haciendo esto podés reducir los cálculos muchísimo si tuvieras gran cantidad de objetos interactuando entre sí (https://learn.unity.com/tutorial/physics-best-practices#5c7f8528edbc2a002053b5b4) Por ej: Los triggers van en la capa "Trigger" (inventada) el resto va en "Default" y el personaje va en "Player" (inventada). En la matriz de colisión le ponés que "Trigger" considere solo a "Player" (ni a default ni a trigger). Con esto el OnTriggerXXX no necesita filtrar el resultado (como en el caso del tag). Yo prefiero trabajar con capas (en este caso en particular) ya que usando triggers siempre se va a dar que tenés (ponele) 1000 objetos dando vueltas, donde 20 son triggers , 1 es un personaje, y los 979 restantes no aportan nada (dinámicos y/o estáticos). Entonces, para no cargar a las físicas al cuete simplemente los filtras con las capas y la matrix de colisiones. Probablemente en tu caso y en el de muchos esto no sea la gran cosa, pero igual está bien usar este tipo de cosas desde el principio cosa de ir amigandose con este tipo de prácticas.
  10. También podrías ponerlo kinemático (rigidbody) al momento de morir.
  11. Chequea el modificador decimate (creo que significa diezmar):
  12. No que yo conozca, pero podés hacer otras cosas. ¿Hay necesidad de que las flechas sean hijos de los botones? Si no es así podés usar un simple script (para las flechas) que se apliquen transform.parent = null y que luego sigan el movimiento de los supuestos padres (botones) y listo. Podés usar transform en UI si lo deseas (más cómodo supongo) o directamente usar RectTransform. Otra quizás más fácil es organizar la jerarquía de otra forma: Root (padre, objecto vacío) --- Botón (tiene la animación) ---- Flecha Todavía no me queda en claro qué es lo que estoy viendo en las imágenes, ¿Por qué necesitas botones? Saludos.
  13. 😂 Me rio porque tenía un asset llamado Kinematic 2D y el 90% de los usuarios me decian "Muy bueno el kinetic" ajjaja. La pelota debería rebotar bien ya que OnCollisionEnter/Exit/Stay ocurren luego de la simulación, es decir que las velocidades ya fueron calculadas (el rebote en este caso). Es decir que el bloque se elimina de manera segura con Destroy. Quizás el problema no sea de OnCollisionEnter (bueno, no lo es ya que lo mencionas en el post), puede ser que las físicas estén haciendo su trabajo bien. ¿Estás seguro que tu collider es rectangular? La esfera al colisionar te devuelve una normal "interpolada" (no se si es el término correcto): Pobrá con reemplazar el collider de la bola de un circulo (asumo que estás usando esto) por una caja. Recorda freezar la rotación Z (en Rigidbody). Saludos
  14. Sí, es normal, me he peleado con esto mucho tiempo. Mi solución (no digo que sea lo ideal) fue modelar paredes y techos con volumen distinto de cero (cajas, no planos) y santo remedio. A veces podés fakear el volumen añadiendo geometría extra en las uniones, en ciertas situaciones podría funcionar de 10. Por ej, si tu juego transcurre en el interior de una casa, ponés un gran plano afuera (bien puesto obviamente) que cubra las uniones. Podrías poner objetos más pequeños en los lugares problemáticos. La desventaja es que depende (no siempre) del ángulo de inicidencia de la luz. Volviendo al problema inicial, con el tema de las luces tenés el bias (nunca recuerdo cual es cual, tenés la doc para más info) que te ayuda a combatir el problema, el tema es que muchas veces no alcanza, o puede que te también te produzca ciertos "artifacts" relacionado a las sombras. Todo nace de la técnica usada para generar sombras (shadow mapping), si usaras raytracing creo que nada de esto pasa (pixel-perfect shadows). Saludos.
×
×
  • Create New...