Noticias

¡RECUERDA QUE SI ERES UN NUEVO USUARIO, DEBES PRESENTARTE PARA PODER PUBLICAR MENSAJES! | TENEMOS CANAL OFICIAL DE TELEGRAM: t.me/unity3dspain

reiniciar un script desde otro que acabo de instanciar

Iniciado por Ness, Noviembre 10, 2015, 05:05:20 AM

Tema anterior - Siguiente tema
[quote author=Quel date=1447190258" data-ipsquote="" data-cite="Quel" class="ipsQuote">1) Pues te haces una función que se llame Inicializar. En ella asignas todas las variables que se tengan que asignar, llamas todas las funciones que se tengan que llamar y realizas todas las tareas que sea necesario llevar a cabo.2) En en Start o en el Awake, ejecutas tu función Inicializar.
3) Cuando vuelvas hacerle un reset a tu script, vuelves a llamar tu función Inicializar.Asi de simple.


Noviembre 16, 2015, 09:35:48 AM #16 Ultima modificación: Noviembre 16, 2015, 09:36:30 AM por Quel
[quote author=Final Level" data-ipsquote-contapp="forums" data-ipsquote-contenttype="forums" data-ipsquote-contentclass="forums_Topic" data-ipsquote-contentid="34389" data-ipsquote-contentcommentid="123552">dsde cuándo reasignar un objeto es matar moscas a cañonazos? jaja[/quote]Desde siempre. Te cuento, porque veo que vas un poco desorientado.Destruir y crear objetos es mas costoso que coger un objeto ya existente en la escena y redefinir sus valores. En realidad, esa es una de las principales razones por las que existen y son tan recomendadas el uso de los Object Pool en todos aquellos objetos que deben de ser destruidos y credos con frecuencia.
Si no sabes que es una Objecto Pool, puedes mirar un hilo que hay en este mismo foro, donde cuenta un poco al respecto (http://unityspain.com/topic/9608-aporte-object-pool/)De nada.

Noviembre 16, 2015, 11:10:46 PM #17 Ultima modificación: Noviembre 16, 2015, 11:13:19 PM por Final Level
[quote author=Quel date=1447662948" data-ipsquote="" data-cite="Quel" class="ipsQuote">Desde siempre. Te cuento, porque veo que vas un poco desorientado.Destruir y crear objetos es mas costoso que coger un objeto ya existente en la escena y redefinir sus valores. En realidad, esa es una de las principales razones por las que existen y son tan recomendadas el uso de los Object Pool en todos aquellos objetos que deben de ser destruidos y credos con frecuencia.
Si no sabes que es una Objecto Pool, puedes mirar un hilo que hay en este mismo foro, donde cuenta un poco al respecto (http://unityspain.com/topic/9608-aporte-object-pool/)De nada.[/quote]Reinstanciar un objeto y asignarlo en un puntero es matar moscas a cañonazos "desde siempre"? De dónde has salido tú, criatura de la naturaleza? ¿Hablamos de objetos como GameObjects con componentes incluidos o hablamos de instancias de clases que, por lo general, suelen ser estructuras de datos livianas, dado que suelen ser scripts que controlan una pequeña parte del comportamiento de un GameObject? Me parece que el que estás desorientado eres tú, amigo. Es normal que constantemente se instancien objetos(instancias de clase. Aunque dependiendo del tamaño no es recomendable en bucles del hilo principal), y estoy bastante acostumbrado a hacer esto en software con lenguajes nativos por ejemplo, y con objetos más pesados de lo que  suele ser un script. Es decir, es algo bastante corriente y no llevo dos días en esto para llegar a un foro de Unity y que un "escupe código" que ha medio aprendido con un engine WYSIWYG, te diga que estás desorientado. Obviamente se puede hacer uso de técnicas como el pool(que pareciera que lo has descubierto ahora, por cierto), pero estas cosas se suelen utilizar para objetos pesados; sobretodo que requieran asignación en memoria con una alta frecuencia. Como uses pool para cada clase que tengas que reinstanciar, tus proyectos tienen que dar un poco de grima. Esa obsesión por el rendimiento en cuestiones casi insignificantes, no hacen más que delatar tu limitado conocimiento sobre el tema, además de tener una capacidad lógica casi nula a la hora de estructurar un programa, al recomendar usar valores fijos para reestablecer variables que pueden cambiar en diferentes instancias del mismo tipo. Lo que yo proponía es una solución simple y rápida. Pues lo que le interesaba era reniciar las variables y que los métodos de inicialización se invocaran de nuevo. Por tanto, supongo que le sirve reiniciar solo ese script y no el GO completo, el cual, no tiene porqué eliminar. En la mayoría de los casos, esto será lo más optimo y ni siquiera va a haber cuelgue con una simple estructura de datos. Ni que estuviéramos en al era de Spectrum. No sé qué tengo que agradecerte para que me digas "De nada".Perdona por el pergamino, señor Spaghetti Code, pero no vengo mucho por aquí.

Cita de: Final Level date=1447711846" data-ipsquote="" data-cite="Final Level" class="ipsQuote¿Hablamos de objetos como GameObjects con componentes incluidos o hablamos de instancias de clases que, por lo general, suelen ser estructuras de datos livianas, dado que suelen ser scripts que controlan una pequeña parte del comportamiento de un GameObject?
Pues si al final los dos teneis razon, solo que estais hablando de cosas diferentes ... aunque habria que hacer dos observaciones:Quel la caga un poco al decir "desde siempre"; segun si se considera que enginees como unity existen desde siempre donde crear objetos (no instancias) tiene un coste elevado si necesitas crearlo muy frecuentemente. Pero programando en nativo, la verdad es que el pool puede ser necesario para una cosa muuuuuy puntual pero es muy raro tener que utilizarlo.Es como decir que, porque en unity tener 150.000 objetos (gameobjects) en pantalla te consumiria mucho ... no puedes tener 250.000 objetos (instancias de clase) y mas si lo necesitas en una aplicacion programada como de toda la vida, es decir en nativo. El "de siempre" no pega mucho en programacion cuando te estas refiriendo a una cuestion de Unity.Por otra parte, Final Level no te pegues esos piques ... la mitad (en realidad muchos mas) del foro, que no es lo mismo que decir todos, solo han programado en Unity y siguiendo videotutoriales por lo que no saben ni lo mas basico de programacion; si te das una vuelta por el foro, encontraras mucha gente que dice directamente no saber que es una clase o un objeto ... lo se, pero se meten a programar un videojuego xDPara leer mucho de lo que se dice en este foro debes cambiar el chip, y pensar que el Unity es la programacion (olvidarte de todo lo anterior), y asi cuando leas cosas como "objeto" no entenderas una instancia de clase (que en programacion es lo que es) si no un GameObject (que es a lo que se refieren aunque no sea un objeto hablando en programacion y encima luego te vayan algunos de listos queriendote enseñar)

Cita de: Arthure date=1447714358" data-ipsquote="" data-cite="Arthure" class="ipsQuote Pues si al final los dos teneis razon, solo que estais hablando de cosas diferentes ... aunque habria que hacer dos observaciones:Quel la caga un poco al decir "desde siempre"; segun si se considera que enginees como unity existen desde siempre donde crear objetos (no instancias) tiene un coste elevado si necesitas crearlo muy frecuentemente. Pero programando en nativo, la verdad es que el pool puede ser necesario para una cosa muuuuuy puntual pero es muy raro tener que utilizarlo.Es como decir que, porque en unity tener 150.000 objetos (gameobjects) en pantalla te consumiria mucho ... no puedes tener 250.000 objetos (instancias de clase) y mas si lo necesitas en una aplicacion programada como de toda la vida, es decir en nativo. El "de siempre" no pega mucho en programacion cuando te estas refiriendo a una cuestion de Unity.Por otra parte, Final Level no te pegues esos piques ... la mitad (en realidad muchos mas) del foro, que no es lo mismo que decir todos, solo han programado en Unity y siguiendo videotutoriales por lo que no saben ni lo mas basico de programacion; si te das una vuelta por el foro, encontraras mucha gente que dice directamente no saber que es una clase o un objeto ... lo se, pero se meten a programar un videojuego xDPara leer mucho de lo que se dice en este foro debes cambiar el chip, y pensar que el Unity es la programacion (olvidarte de todo lo anterior), y asi cuando leas cosas como "objeto" no entenderas una instancia de clase (que en programacion es lo que es) si no un GameObject (que es a lo que se refieren aunque no sea un objeto hablando en programacion y encima luego te vayan algunos de listos queriendote enseñar)
No he dicho todos. Sé que aquí hay gente que controla del tema. Aunque había más antes y por algún motivo, ya no veo a algunos.

Aun t preguntas x k no ves tantos?  Respondiendo a Yokulo ya sabes el x k...
8=========D

Etiquetas: