Jump to content
UnitySpain

lightbug

Registrados
  • Content Count

    2,296
  • Joined

  • Last visited

  • Days Won

    190

Everything posted by lightbug

  1. Yo tampoco tengo en claro como haría algo así. Se me ocurre recorrer toda la escena (o por lo menos lo relevante) e ir sampleando normales mediante algun cast. Puede parecer una locura pero no, no es tan demandante, sobretodo si se hace una sola vez (además de que se puede hacer en el mismo editor ). El tema de los colliders puede ser algo pesado de hacer, pero poder se puede. Ya que está dejo un video que encontré recientemente donde el autor dice como hizo lo que hizo (no se si es 100% lo que querés pero puede sumar): Y él/ella dice: " I do a raycast from the player to the center of each gravity body collider in the scene, check for which raycasthit point is the nearest, then use the normal to determine the gravity direction each timestep. Hope that gives you an idea! "
  2. HOla, Sumando a lo que dijo @Igor, fijate que en las líneas de RB en una estás agregando fuerzas, todo bien, pero después estás pisando la velocidad directamente (anulando lo anterior). Está bien eso? El efecto está muy bueno, lo quiero implementar para mi asset, para mi este efecto siempre funcionó de manera algo predictiva o usando un campo vectorial (no solo es un cast y listo. Fijate que cuando salta hacia un muro recto, lentamente va cambiando la gravedad). Predictiva: Una posibilidad puede ser que (por ej) cuando mario salta mientras corre tenés el típico caso del tiro oblicuo (caso general), con eso podés detectar en el aire si va a colisionar con una pared varios frames antes (simplemente mediante la velocidad que tiene), de esta forma podés ir rotando a mario antes de que toque la superficie. Con planetas super suavizados no te das cuenta, pero con superficies más abruptas es útil. Campo vectorial (y para mi la que usó nintendo): es calcular disponer de un campo vectorial, cuyos vectores sean los valores de gravedad (o también funciona con los "up"). Sería como un bake. Eso sí, si el objeto es dinámico no se, quizás se pueda calcular frame a frame para resoluciones bajas.
  3. Excelente! Le quería entrar a los stencil hace rato, quizás ahora sea el momento. Gracias!!
  4. Está en el post de más arriba. FixedUpdate, por las razones que mencioné antes. Velocidad = Δ desplazamiento / Δ tiempo Δ desplazamiento es la cantidad de desplazamiento que le tenés que agregar a tu objeto, es decir sería tu " + transform.forward * Velocidad * Time.deltatime ": Despejando: Δ desplazamiento = Velocidad * Δ tiempo De ahí sale la forma esta (que se llama de "Euler"). Todo en realidad parte desde las derivadas, pero acá te manejas con pequeños incrementos, osea el tiempo de frame a frame (no el frame count). En el mundo Unity sería: Δ desplazamiento = Velocidad * dt Y cual es el dt que debés usar? bueno, eso depende (y no tanto, ahora vas a ver) del método que uses: Si es Update Time.deltaTime te da el tiempo que tardó el último frame. Si es FixedUpdate (<--- es este) Time.fixedDeltaTime te da el tiempo que pasó en FIxedUpdates (generalmente coincide con "Project Settings/Time/Fixed step" (creo)) Pero, y si estás en FixedUpdate y llamás a Time.deltaTIme ¿que pasa?, nada, te devuelve lo mismo que Time.fixedDeltaTime ... yo siempre uso Time.deltaTime para todo y listo. frameCount devuelte la cantidad de frames que pasaron, osea que no es un dt, no sirve. Eso habría que ver el código, osea con "tener dos fuerzas programadas" no se entiende demasiado. Lo que sí se sabe es que se debe hacer una sola llamada a MovePosition por frame físico. --> https://docs.unity3d.com/ScriptReference/Rigidbody2D.MovePosition.html It is important to understand that the actual position change will only occur during the next physics update therefore calling this method repeatedly without waiting for the next physics update will result in the last call being used. For this reason, it is recommended that it is called during the FixedUpdate callback. Note: MovePosition is intended for use with kinematic rigidbodies.
  5. Hola, no soy un experto ni nada y además hace 1 año casi exacto que vendo assets, así que lo que digo agárralo con pinzas. Lo primero que sí tenés que hacer (fuera del tema del precio) es unirte en el foro de Publishers del foro oficial. No recuerdo si necesitas publicar primero o solo con registrarte como publisher te dan el pase. La cuestión es que ahí se discuten este tipo de temas y más. Un topic estaba orientado exactamente a esto, y un developer de Unity dejó este video: En definitiva no existe una respuesta 100% clara. El precio de algo (dentro de un contexto) acarrea la información de tu producto. Entra la cuestión de que somos seres caóticos y emocionales, y estamos dispuestos a comprar algo, no solo para usarlo, sino también para lucir y refregar en la cara lo que pagamos (o al menos creérnosla de que fue bueno, lo sea o no tanto). Es difícil decirte $ X estando muy seguro (esto debido a que internamente no conozco tu asset, y creas o no, todo vale, no solo los features) pero puedo plantear algunas cuestiones que para mi son importantes (mmm ya me veo escribiendo un post largo ): 1 - Oferta/Demada + Tu toque: El primer error es suponer que el precio representa el esfuerzo detras. Si esto fuera así un asset complejo saldría un ojo de la cara. Como todo, es un balance entre oferta y demanda, pero también podés meter el "factor humano" en el medio. Esto va de la mano con el punto 2 (casi el método clásico de elección en el Asset store) ---> 2 - Buscar assets similares: Esto puede ser beneficioso o no. A veces tenés que hacer la tuya y sobresalir con el precio. Basicamente le decís a quien te compra el producto "Soy mejor que el resto" (que dicho sea de paso es alguien que probablemente no tenga conocimiento del "resto"). Esto lo podés asociar a una "etiqueta" de precio (creo que así las llaman). Por ej, para el mundo de los juegos, si compras algo de $60 es un juego AAA (esto ya es como cultura general ya), entonces vos esperas un producto así. Buscá un asset similar y (como estás arrancando) cobralo (no se) 5 dolares menos ... esto va al punto 3 ---> 3 - Futuros incrementos: ¿Cual es tu plan a futuro con el precio? pensas poner el asset a un precio final de entrada? o ir incrementando poco a poco? (una o dos veces el primer año). Quizás esto pueda usarse como estrategia también. El comprador solo se da cuenta de esto, no es necesario hacer un aviso. 4 - Más allá del contenido del asset, muchas veces lo que vale (y mucho) es: 4.1 Soporte: Responder mails, resolver bugs, etc. Atención en general, ser "profesional", saludar formalmente. Basicamente transmitir al cliente y al resto que están lidiando con alguien que se preocupa por ellos, no solo alguien que junto código y lo subió a la store para ganar dinerillo. 4.2 Documentación, manuales, referencias de API, todo esto te da un colchón impresionante. Evitar word, bloc de notas, y todas esas cosas medias cutres. Es muy útil saber redactar tu documentación y además presentarla bien. 4.3 Extras de todo tipo: página web propia, demos, redes sociales, contactos, en redes sociales y en el mismo foro de Unity. 5 - Código "PRO" (al menos a la vista jaja): Esto puede o no aplicarse a tu caso, si tenés código está bueno diseñarlo usando ciertos estándares, sobretodo para extenderlo, mejorarlo vos mismo y además brindar documentación de la API. No solo algo que haga un tarea y listo. EJ: Esto mueve a un objecto 5 unidades por segundo en una dirección: Esto hace exactamente lo mismo, y además explica bien de que va cada campo y método, además de que permite personalizar el método (en esta caso una pavada) con una implementación propia haciendole un override: 6 - Metadata: A lo último pero muy importante también. Que és esto? videos, imagenes, Logos, etc. Tampoco es necesario pegar altas ediciones de video, ni ser un experto de Ilustrator, simplemente tener algo de gusto y un poco de sentido común. En resumen, te sugiero que te vayas al punto 2. Empezá a buscar asset similares. Si pensas que a futuro lo vas a dejar mejor que no te importe cobrar más incluso si a la primera no vendés nada. Tené cuidado con poner algo a un precio y bajarlo porque no se vende, esto lo que transmite es falta de confianza. Tampoco pongas un precio exageradamente bajo porque lo vas a terminar subiendo mucho seguramente. Tu asset se ve muy prometedor! La verdad que por lo técnico soy un queso diciendote vale tanto. También te diría que mantengas ese "look Unity" y no metas demasiados colores y cosas a la UI , basicamente usá estilos compatibles con Unity (Button, Box, HelpBox, etc). No hagas lo que hizo el autor de Aura2 (En las reviews lo matan con esto). Otra, andate a los UI Element si podés, este año va a ser el año del pase, más de la mitad de la gente que usa el Asset store está en 2019! (está en el foro de publishers). Y además 2020 trae (supuestamente) el nuevo Input System. Así que para nosotros que vendemos assets es un momento clave de transición. (jaja terminó el magapost y no te dije ni un valor ... ponele $15 dolares a ver que pasa , de última le subís) Saludos
  6. En general no existen reglas, podés hacer lo que quieras, todo dependerá del tipo de resultado deseado. "Si se mueve y te gusta el resultado, está bien" - Lightbug, enero de 2020. Por ejemplo: asignando la velocidad de manera absoluta te da algo super exacto, basicamente querés que el cuerpo vaya a tal lugar y lo tenés. Todavía tenés alguna que otra cosita que te puede modificar el comportamiento (drag, angular drag, materiales físicos, etc) pero tenés trucos para todo esto. Si por el contrario querés que la simulación sea 100% real life no fake entonces asignar la velocidad de manera absoluta (lo remarco de nuevo) es lo peor que podés hacer. En este mundo tenés similaridades con el cálculo diferencial. Disponés de "órdenes de control" sobre la posición y rotación: orden 0: (sin derivar): Posición y rotación -> basicamente personajes kinemáticos order 1: (derivando lo anterior) -> velocidad lineal y velocidad angular -> rigidbodies dinámicos orden 2: (resultado de derivando lo anterior) -> Fuerza y Torque. -> rigidbodies dinámicos Mientras mayor es el orden tenés menor control. Notá que para el orden 2 no podés anular la velocidad de golpe, vas a obtener un resultado más realista (no necesariamente un mejor resultado). ──────────────────────────────────────────────────────────────────────────── Por ej para el orden 2 es muy útil utilizar controladores PID para realizar movimientos algo precisos empleando fuerzas. En resumen, tenés una entrada de referencia con velocidad = v (puede ser cualquier valor), esta señal pasa por unos bloques de compensación (el PID) luego la velocidad de salida se realimenta a la entrada y se calcula la diferencia entre este resultado y la velocidad de set v. Esto finalmente reingresa al loop y así forever. La velocidad de salida tenderá al valor de set, esto por las características del PID, también dependerá mucho de la elección de los parámetros Kp Ki y Kd. Aca un vid con un ejemplo de posición: Todo esto es teoría de control, el tema es bastante complejo como para entenderlo en un post. Hay mucho material muy interesante.
  7. Ah lindo método, no lo conocía, me sirve! jaja La fórmula esa te devuelve un valor entre 0 a 1, pero debés asignar ese valor a algo, por si sola no hace nada: public float valor; //... // si el valor es <0 => Mathf.Clamp =0 // si es >max => Mathf.Clamp = max // Se le asigna el valor limitado a "valorClampeado" float valorClampeado = Mathf.Clamp( valor , 0 , max ); // si el valorClampeado es max => valorNormalizado = 1f // si el valorClampeado es 0 => valorNormalizado = 0f float valorNormalizado = valorClampeado / max;
  8. hombre actualiza, esa la usaba yo en 2012 creo jajaj No, bump mapping y normal mapping producen algo muy parecido, ambos son efectos "fake" que no modifican la geometría. La diferencia es que los Normal maps usan RGB (3 Bytes por pixel) para representar una normal (Vector3), cuando el bump usa escala de grises (1 Byte por pixel) para esto. Con el normal podés meter una normal inclinada vs una normal perpendicular del bumb (o por lo menos así lo entendí toda la vida). Hoy en día casi que se usa Normal maps o por lo menos es lo que más se ve, estos al estar representados en 3 canales podés expresar 3 componentes <x,y,z>. Probablemente te hayas confundido con height maps vs normal maps (?). No estoy 100% seguro, pero en su momento recuerdo que debías tener hardware compatible con DX11, habilitar tesselation, usar un material con "height map" y meterle el "height map" deseado. Aca te dejo un vid con Unity 4 + tesselation; https://www.youtube.com/watch?v=YlR69pXb0oY Saludos
  9. Jajaja, bueno me imagino que estás haciendo esto dentro de una corrutina. Quizás podrías subir el código entero así se ve mejor la cosa.
  10. Estás usando el Input.GetMouseButton( 1 ) no??
  11. No, debería ir todo super fluido. Cómo es que estás moviendo el objeto?, necesitamos código para poder contestarte con certeza, sobretodo con estos temas que son extremadamente delicados. Siempre ojo con una alpha. Dicho esto, te tiro algunos datos sueltos que quizás te ayuden a entender un poco más este mundo. Dos mundos: Transform: transform.position, transform.Translate, transform.Rotate , etc... Físicas: rb.position, rb.MovePosition(...), rb.velocity, rb.AddForce( .. ) , etc ... Nunca nunca nunca mezclar estos mundos, por ej teniendo un Rb dinámico y moverlo usarlo Transflate. Existen casos y casos, en general no es recomendado. Yo me manejo 100% con rigibody en FixedUpdate, para mi Transform se usa para leer cosas muy específicas, o para cuestiones de Gizmos y demás, para el resto lo elimino de mis scripts (por lo menos los evito si necesito un comportamiento físico). Funcionamiento de las físicas (muy por arriba): El truco está en entender cuando las físicas hacen lo suyo y qué es lo que hacen. Basicamente cuando se da un step de simulación se realizan dos cosas (muy resumido): los physics queries (raycast, spherecast, etc) se determinan las velocidades de los rigidbodies en base a choques, materiales, etc. Una vez que esto termina se hace un "Sync", esto basicamente actualiza el componente Transform (RB -> T), que determinara visualmente donde estará el objecto. Gracias a esto es que sin tocar el Transform vos podés ver los resultados en pantalla. Que dicho sea de paso, el motor lee el componente Transform para mostrar las cosas en pantalla, todo lo visual está directamente relacionado a este (las físicas pueden recalcular todo de arriba a abajo y nada se va a actualizar en pantalla). AutoSync: Si tu objeto es kinematico y lo movés usando Transform es probable que para versiones viejas de Unity no hayas notado la diferencia con moverlo "legalmente" usando físicas. Probablemente todo haya resultado fluido, esto es porque antes se usaba "autoSync" por defecto. Este autoSync lo que hacía era detectar un cambio en un transform y recalcular toda la parte de las físicas, actualizando el Collider, la pos y rot del rigidbody. Osea que estaba todo perfectamente sincronizado (T -> RB). Desde ya que esto demandaba mayor procesamiento. Hoy en día este autoSync está desactivado por defecto, demandando mayor preocupación por parte del programador a la hora de mover un rigidbody, o de realizar simples queries. Interpolación: Un poco más complicado de entender, pero similar a lo anterior. Por qué usar interpolación? si movés un rigidbody usando FixedUpdate (como debe de ser) vas a notar que los cambios pasan a 50 fps por defecto (probablemente no tan notable,). Si esta tasa de refresco fuera cada vez menor los cambios se harían más y más notables. Como se soluciona? interpolando estos valores, ya que el Transform está más al pedo que bocina de avión, se lo usa para generar visualmente (recordar lo que dije más arriba) un resultado, mientras las físicas laburan. En el mundo transform se van a generar posiciones y/o rotaciones intermedias, es decir, va a interpolar las pos y rots para generar visualmente un resultado.Con velocity pasa lo mismo si tenés interpolación activada. MovePosition sirve si tenés un RB Kinemático con interpolación activada. Un dato extra: Si llamás a MovePosition estando en la pos A, y le decís "movete a B" ( rb.MovePosition(posB) ), vas a notar que la rb.position no se actualiza para nada (es igual a posA). Esto es porque MovePosition se actualiza después del step físico. FixedUpdate: El step físico (que hace todo lo de arriba y más) ocurre después de cada FixedUpdate, entonces si vas a mover algo usando físicas (ya sea un Rb dinámico o kinemático) lo lógico es hacerlo en FixedUpdate y no en Update. Espero que sirva de algo, quizás estás metiendo la pata en alguno de esos puntos, o quizás en alguno que no mencioné. De todos modos sería útil si subieras el código que utilizas. Saludos
  12. Jaja posta, yo dije exactamente lo mismo. Jajaja firme aquí: De nada!
  13. No creo que la idea del autor del topic sea mostrar algo totalmente nuevo, si vamos al caso no existe nada 100% nuevo. Igual, debo decir que muchos de esos prototipos son portales o directamente juegan con la escala del objeto. Lo del video del topic no son portales, lo que hace es clonar la geometría (exacta) de un lugar a otro. El de Prey muy bien hecho, es un portal, quizás de los primeros (?). El de Valve es el más simplón de todos, lo único que hace es copiar/escalar el rigidbody, casi que la cámara está de al cuete. En cambio en el video del topic la cámara es clave para la mecánica. El del museo está muy bueno. En el de Witcher no encontré la mecánica, en qué parte está?
  14. Si estás constantemente acortando la diferencia de ángulos en algún momento se va a dar que esta diferencia será menor, incluso si pegás el giro de 180. Primero y principal, con respecto al tema del giro, no hace la diferencia, podés usar cualquiera de los dos. En el video no se usa CharacterController, ese fue el nombre del asset que escogí. El personaje del video es un rigidbody dinámico con rotación bloqueada (físicamente hablando), el cual fue programado casi meticulosamente para que se mueva así (sobretodo para los benditos steps). Podría ser tranquilamente un rigidbody kinemático también (totalmente controlado por un script). ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- El personaje kinemático usa un rigidbody en modo kinemático. El CharacterController es una implementación de Unity de un kinemático, copiando la implementación de Nvidia. En internet existe un guerra, a ver quién puede hacer esto o aquello, el Kinemático es mejor, el dinámico es mejor, y así hasta el fin de los tiempos. Este CC es muy preciso, vos le decís "movete de la pos A a la B" y el personaje (basado en sus reglas internas de slope, steps y collide&slide) se moverá colisionando con el mundo de manera continua (no discreta) hasta llegar a B o C (nueva pos resultante). En la sig imagen, discreto arriba, continuo abajo: Super improtante: la detección de colisiones se debe implementar de cero usando Raycast, spherecast,capsulecast, etc ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Por otro lado el dinámico usa un rigidobdy dinámico con rotación bloqueada (usualmente). Hay formas y formas de usar un RB dinámico. Muchas veces te van a decir que ni se te ocurra cambiar la velocidad directamente de un rigidbody porque estás pisando su comportamiento base, y es cierto. En este caso es conveniente usar Fuerzas, estas se traducen a velocidades y estas últimas finalmente a posición, así las físicas se encargan de determinar todo por vos. Además tenés detección de colisión "gratis", tu único trabajo es mover el rigidbody. El personaje del video no hace esto último, hace rb.vel = Valor , y yo de fondo modifico este valor según mi propia gravedad, velocidad de movimiento, impacto externo (de otros rigidbodies), etc. Por esta razón se ve "snappy" y super preciso. En resumen es un dinámico que se mueve como un kinemático ;) (o también un kinemático con detección de colisiones y físicas gratis). Saludos
  15. Wooow, muy bueno, el ejercicio está en decir como ha hecho eso. Tengo una pequeña idea pero no estoy seguro. Cuando saca la foto lo que hace es ubicar un prisma donde se proyecta la foto (2D). Con esto crea un nuevo modelo 3D basado en la intersección de este prisma con la geometría del nivel (si intercepta un rigidbody supongo que lo guardará entero o con un meshCollider resultado de la intersección(?)). Finalmente lo ubica en el mundo. Obviamente más allá de la técnología de fondo la idea está genial.
  16. Veo 3 formas: Por código: simplemente midiendo el angulo de diferencia entre el ángulo "forward" del modelo (o ficticio puede ser también) y el vector de dirección de movimiento. El truco está en que la rotación se ejecute siempre, pero no el movimiento. Este último solamente se ejecutará cuando el ángulo entre forward y dir sea menor a X. Por estados del animator + root motion: basicamente los giros de personaje y los desplazamientos son animaciones que pueden o no estar "centradas" (me refiero a que el modelo puede moverse hacia cualquier lado --> https://kybernetikgames.github.io/animancer/docs/examples/locomotion/root-motion/root-motion.gif)). Dependiendo del ángulo del punto 1 se dará un estado u otro (generalmente se suele enviar este ángulo como una variable a un Blend tree, de acá se determina el clip resultante). Entonces si el angulo es menor a un valor se dará el clip de movimiento, si no se dará el giro. No haciendo nada ;) : Muchas veces queda bien y pro no hacer nada, en mi caso juego con la velocidad del Slerp para ver como queda (esto junto a la velocidad de caminar/correr). Ej: En caso de estar corriendo o incluso caminando vas a tener que reducir la diferencia max o directamente incrementar la velocidad de giro. Este giro que querés hacer se suele usar mucho más de "Idle" y no tanto en "Walk", "Run" etc. O por lo menos usarlo más en idle e ir reduciendo su influencia en estados más "dinámicos" (se me ocurre Assassins creed como ej).
  17. Me too :) No, estos locos de la guerra suelen hacer todo por sí mismos (implementar gráficos, render, físicas y demás), ya que les da más libertad. En el FAQ del juego dice: What game engine are you using? The game uses a custom physics and graphics engine built for this game specifically. It uses raytracing for lighting, but does not require an RTX GPU.
  18. Acá les dejo el twitter de este señor: https://twitter.com/tuxedolabs?lang=es Sus videos y artículos son muy buenos, 100% recomendado. Tiene proyectos que integran: Geometría compleja basada en mini voxels (más tirando a átomos que al cubo de minecraft). Físicas rígidas, blandas, flexibles y de flotabilidad. Partículas, Iluminación completamente dinámica. Destrucción. Audio (para manejar todo el tema de las físicas + destrucción). Shaders. Efectos volumétricos. y más :) ... Realmente impresionante, se me hace que este tipo va a quebrar la internet en unos años. Les dejo algunos tweets: El juego que está creando (muy linda idea): Esas partículas :P
  19. Jajaj ya es todo una joda. A eso que dije no le des mucha bola, sería algo así: los circulos rojos (los colliders) no se tocan, pero la suma de los contactOffsets de los circulos es menor que la distancia "d". Con una layermask podés ser selectivo a la hora de hacer un cast, es decir, tenes en cuenta ciertas layers y otras no. El ejemplo más claro es en un shooter, en la escena tenés triggers que activan ciertas cosas, health packs y enemigos, ponele (además de otras cosas). Cuando disparás no querés que el raycast que usas tome en cuenta al health pack o al trigger. Entonces, en el campo LayerMask sacás "Triggers" y "Health Pack" (suponiendo que fueron previamente asignados a estas capas).
  20. No, porque los mensajes de collision se disparan cuando los objetos colisionan, en este caso cuando "entra" en una colisión. Creo que se dan cuando la distancia entre los puntos más cercanos es menor a la suma de los contact offset de los dos colliders (ProjectSettings/Physics(o Physics2D)). Con raycast, spherecast, y demás vos estás "prediciendo" el futuro choque (dependiendo de las características del "cast" obviamente). La desventaja es que necesitas "castear" (ya que estamos vamos a cagarnos en la RAE xD) todo el tiempo, y el cast necesita ser fiel a la forma del collider (si usas una caja será un boxcast, si es una capsula un capsuleCast, etc). En 2D (no se en 3D) tenés Rigidbody.Sweep, es más caro pero hace el cast con toda laforma del collider2D. Lo que sí podés hacer con los "cast" es filtrar por capas usando LayerMasks, y posteriormente usando tags.
  21. Para sumar a lo ya muy bien explicado por los compañeros. == significa que la expresión es "true" si el miembro izquierdo es igual que el derecho (false caso contrario). != significa lo opuesto. Viéndolo así podés convertir cosas como estas: if( golesEquipoLocal == golesEquipoVisitante ) empataron = true; else empataron = false; En algo así: empataron = golesEquipoLocal == golesEquipoVisitante;
  22. Si estás generando un quaternion a partir de por ej LookRotation y le estás pasando un vector nulo, te va a salir este mensaje. Asegurandote que el vector no sea nulo, por ej: if( vector != Vector3.zero ) { tuRotation = Quaternion.LookRotation( vector , transform.up ); } No te preocupes por el operador "==" para vectores, si la diferencia es menor o igual a la mínima te va a dar cero. https://docs.unity3d.com/ScriptReference/Vector3-operator_eq.html "To allow for floating point inaccuracies, the two vectors are considered equal if the magnitude of their difference is less than 1e-5." Saludos
  23. xD no entendí absolutamente nada de lo que dijo pero me mantuvo pegado a la pantalla todo el tiempo. Si un gameplay de estos llega a pewdiepie o markiplier andá agrandando tu casa, para que entren los dólares jaja.
  24. Muy buenas. Yo dejé de usar keycodes, por temas del asset store me preguntaban X asset funcionaba con Rewired (la típica), mi respuesta era "Ni idea". Averiguando Rewired puede reemplazar los típicos GetButton("Key") con su propia implementación, así que ahora todo lo hago por las dudas usando el Unity InputManager y listo. Para lo personal, recuerdo que (usando Keycodes) si quería la tecla "C" la presionaba y me mandaba a elementos con C, no era super rápido para definir de una a la KeyCode deseada, pero teniendo en cuenta que asignaba este campo 1 vez cada tres meses no era "él" problema. El problema básico de esto es que usando Keycodes estás trabajando sobre el binding y no sobre la acción, pero bueno para cosas rápidas va bien. A claro, el componente con el script debe estar en el elemento. La cosa es que de ahí se puede redisparar algun evento que actualice algún contexto maestro, algun manager, o quién quiera recibir el evento (un evetn delegate por ej). // en piojScript.cs -------------------------------------------------------------------------------------- // con un event delegate public event System.Action< piojScript , AxisEventData > OnUIMove; public void OnMove(AxisEventData eventData) { if( OnUIMove != null ) OnUIMove( this , eventData ); } //UIMaster.cs ---------------------------------------------------------------------------------------------------- //El manager (UIMaster) debe "escuchar" este event, esto lo hacés para todos los elementos involucrados void OnEnable(){ scriptA.OnUIMove += OnUIMove; } void OnDisable(){ scriptA.OnUIMove -= OnUIMove; } void OnUIMove( piojScript script , AxisEventData eventData ) { // Suponiendo que Name devuelve algún nombre específico Debug.Log( "El script " + script.Name + " provocó un Move, con dirección " + eventData.MoveDir ); } No se si es lo ideal, pero si querés hacer algo así usando el EventSystem actual (con OnMove por ej) no le veo otra, o al menos no conozco otra forma.
  25. pregunto, una muy tonta que me pasó una vez, tenés activado los Logs de consola no? (al lado de warnings y errores). Se que suena tonto pero una vez estuve todo un día con ese problema. El código está bien. Si estás disparando correctamente los events debería dar el print. EDIT: Pensé que el post se iba a unir al anterior Otras veces a pasado, me disculpo.
×
×
  • Create New...