Voodoo Radek
-
Posts
126 -
Joined
-
Last visited
Content Type
Forums
Blogs
Knowledge Base
Posts posted by Voodoo Radek
-
-
La versión gratuita del cuerpo está limitada para ser poco más que una demo sin carteles con la que solo podrás usar ropa de la tienda oficial o ropa que no necesite del hud de alphas. Ninguna de las versiones de pago del cuerpo es compatible con los applies Omega que son los más universales, solo con los appliers oficiales.
A la versión gratuita no se le pueden poner appliers ni transparencias:
-
Esta web está en ingles, pero aparecen los cuerpos y cabezas mesh más comprados. En el menu superior hay un desplegable para acceder a ellos:
-
Esta web está en ingles, pero quizás te sirva para ver las fotos de los diferentes cuerpos y cabezas, y para saber los precios y conseguir la SLURL de las tiendas. En el menu superior hay un desplegable para acceder a ellos:
-
Cambia el evento de on_rez por el de tocar. Con esta condición en el run_time me funciona con mi avatar y con los demas. Además con la función llAttachToAvatarTemp no se crea objeto alguno en el inventario, así que menos basura.
key avatar;default{
touch_start(integer total_number){ avatar=llGetOwner(); llRequestPermissions(avatar, PERMISSION_ATTACH); } run_time_permissions(integer perm){ if (avatar==llGetPermissionsKey()) llAttachToAvatarTemp(ATTACH_HUD_CENTER_1); } }Siento no haber respondido antes.
Edit: me he dado cuenta de que tenia un error en el codigo de mi anterior post, ahora deberían funcionar ambos.
-
Quizas el problema sea este:
- If PERMISSION_ATTACH is granted by anyone other than the owner, then when the function is called an error will be shouted on DEBUG_CHANNEL.
http://wiki.secondlife.com/wiki/LlAttachToAvatar
Con esta condición funciona:
key avatar;default{ on_rez(integer start_param){ avatar=llGetOwner(); llRequestPermissions(avatar, PERMISSION_ATTACH); } run_time_permissions(integer perm){ if (avatar==llGetPermissionsKey()) llAttachToAvatarTemp(ATTACH_RHAND); } } -
Hace un par de años google cambio la API de su servicio de traducción para convertirlo a servicio de pago, dejando unicamente un periodo de prueba gratuito. Parece que algunos huds de traducción que funcionan a través de google usaron esta característica para seguir explotando el servicio indefinidamente, pero no es algo fiable y suelen dejar de funcionar.
Ha salido uno gratuito recientemente que por ahora va:
https://marketplace.secondlife.com/p/Translator-All-google-languages/7076496?
Más info:
http://blog.nalates.net/2015/04/13/second-life-free-language-translator-2/
http://blog.nalates.net/2015/03/16/second-life-update-on-metanomics-translator/
-
Linden Labs está desarrollando ambas plataformas a la vez, destinando personal a una o a otra según necesidad, así que los equipos de ambas no son cerrados. Si algún dia la nueva plataforma llegase a reemplazar a SL por completo, supongo que todos los lindens pasarían a trabajar en la nueva.
Hace pocos días, el otro mundo virtual del momento, high fidelity, pasó a alpha. Este ya permite tracking facial y otras tecnologías.
-
Tienes que fijarte en el tipo de prenda que sea el tatuaje, ya que estas siguen una jerarquia de capas. Esto quiere decir van unas sobre otras en el siguiente orden si no estoy equivocado:
- Chaqueta
- Falda
- Camiseta
- Pantalones
- Camiseta interior
- Ropa interior
- Calcetines
- Tatuaje
- skin
Algunos tatuajes más antiguos van pintados sobre capa de ropa y no sobre una capa de tatuaje. Si tu tatuaje esta pintado sobre una prenda de tipo chaqueta, se verá por encima de las otras capas. Si es camiseta, se verá por encima de una camiseta interior. Si es camiseta interior, se verá por encima del tipo tatuaje.
-
Saludos o/
- Ctrl + alt + d para habilitar el menu advanced en la parte superior del visor.
- Dentro de advanced , clickar en la opcion Mostrar menu develop.
- Dentro del menu develop character test/appereance to XML
Puedes importar este fichero de texto XML a avastar y obtener tu shape. El antiguo visor Phoenix 1185 tenía una opcion para exportar el cuerpo a objeto 3d (formato .obj) pero hasta donde yo se no se ha vuelto a introducir en el visor.
Más info en ingles:
http://blog.nalates.net/2013/04/23/second-life-shape-export/
http://blog.machinimatrix.org/avastar-vs-workbench-skeleton/
-
Saludos
Hace unos minutos publicaron el siguiente post.
http://community.secondlife.com/t5/Featured-News/Recent-Inventory-Issues/ba-p/2876369
El hecho de que sea un mensaje en el foro y no una noticia de mantenimiento puede que signifique que el problema afecta a mucha gente. En cualquier caso, puedes poner un ticket para intentar obtener más información de tu caso concreto, y si eres premium, acudir al chat de soporte.
-
Saludos Outback
Si usas win te recomiendo este gadget.
http://addgadgets.com/network_meter/
Es muy útil para monitorizar consumos y otros datos. El ancho de banda que consuma SL es muy relativo.. depende muchisimo de lo que te muevas. Me atreveria a decir que lo que más consume es cargar regiones en las que nunca hayas estado, puesto que no habrá nada de ellas guardadas en la cache de tu ordenador y deberás descargarlas enteras. He reseteado el contador de mi gadget y he medido el uso con SL unas tres horas, haciendo algunos tps a sitios con tráfico y muchos objetos, también he usado el navegador un poco. El consumo ha sido de 1.2gb.
-
Saludos Damian
Coincido en resaltar la diferencia entre compatibilidad y migración. No sé por qué escribí que una posible migración lastraría a la nueva plataforma. En verdad no tiene porque ser así. Además, esta es precisamente es una de las ventajas con respecto a su competencia, LL puede partir de una pequeña cantidad de usuarios y cuenta con una gran cantidad de contenido. Así, coincido contigo en que es un tema necesario, pero a la par considero que también es extremadamente delicado.
Siguiendo un poco tu comentario sobre las texturas. No sé si sabrás en que hubo un dia en que era posible importar texturas de 2048*2048 px a SL. Duró poco tiempo, pero aún hay en circulación texturas de paisajes y cielos muy bonitos a gran resolución. Y duró poco, porque como es habitual, los usuarios abusamos (siendo conscientes o no) de este recurso. En cualquier juego es raro encontrar texturas mayores de 1024. ¿Por qué doy este dato? porque quiero señalar SL es un plaga en cuanto a contenido ineficiente. El abuso de las texturas es sólo un ejemplo de muchos... pondría la mano en el fuego al decir que es de los que tienen más consecuencias negativas (congelamiento, shuttering, carga infinita, cosas borrosas, FPS irregulares etc etc...). Es el precio a pagar porque la plataforma ofrezca tanta libertad, es un precio caro para una mala práctica extendida... porque no nos engañemos, todos esos problemas y algunos más no están causados porque SL sea viejo, sino por la ineficiencia de su contenido.
La gran pregunta es, ¿Desea LL arreglar este tipo problemas generados por contenido ineficiente, a costa de imponer límites más estrictos a los creadores?
Cuando Ebbe habla de lastre, además de los problemas de bugs y de diseño, creo que también se refiere a este tipo de cosas. Aunque suponga un retroceso en cuanto a libertad creativa, espero que la nueva plataforma imponga ciertos limites para prevenir los problemas que presenta SL. Limites razonables y razonados, que se complementen con una mejor información para construir eficientemente. Sé que posiblemente la mayoría de los usuarios vean esto como un paso atrás, bajo mi punto de vista no lo es. Una de las paradojas de SL es que presenta límites un tanto exagerados para cosas como las físicas... que practicamente sólo influirá en la tecnología Pathfinding que casi no es usado. Sin embargo apenas hay limites en cuanto a texturas y detallado de las prendas de vestir o avatares. La nueva plataforma debería corregir esto, y premiar las buenas prácticas. En este escenario... no tiene mucho sentido migrar tal cuál el contenido de SL, mayoritariamente problemático.
Hay además otro factor muy importante que como usuarios y compradores quizas no estamos teniendo muy en cuenta. ¿Qué pasa con la licencia? migrar texturas, sonidos.. o incluso meshes estáticas quizás sea viable tecnológicamente, ¿Pero es recomendable legalmente y éticamente? ¿Qué pasa si el creador no quiere que su contenido esté en la nueva plataforma? Esta responsabilidad recae en LL y en sus abogados, migrar todo, sin permiso, podría traerles problemas no sólo por parte de los creadores de second life, sino por entidades como cgtextures que tras el tristemente famoso cambio de ToS, han prohibido explicitamente que los recursos que ofrece se vuelvan a subir a SL. Migrar todas las texturas ya que se han subido con anterioridad podría traerles problemas legales.
Mi posición al respecto:
Sobre migrar nombres, grupos, y contactos: genial, ninguna pega. Espero que Ebbe se refiera a estas cosas cuando habla de portar 'nuestra identidad'.
Sobre migrar contenido, sí... pero con muchos matices, yo apostaría por la siguiente fórmula. Desarrollaría un programa en el que los creadores de contenido de SL bien puedan inscribirse o bien sean elegidos (siguiendo un criterio abierto). Les daría acceso a SL2 antes de abrirlo al público, para que volvieran a subir su contenido adecuandose a los filtros y límites de la nueva plataforma. No sólo dejaría que subiesen todo gratis, creo que además sería buena idea pagarles o motivarles de otra forma. Cuando más contenido tenga la nueva plataforma al abrir, más gente atraerá y mejor posicionado estará con respecto a la competencia. Problema de licencia resuelto. Problema de eficiencia resuelto. Menos contenido que importarlo todo a lo bestia.. sí, pero más depurado.
Si por el contrario LL no tiene pensado hacer la nueva plataforma más restrictiva para incrementar su eficiencia... bien, entonces si tendría sentido importar todo lo que sus abogados y la nueva arquitectura le permita sin ningún tipo de filtro. Pero mucho me temo que volveriamos a ver cierto problemilla que comunmente llamamos lag... en varias de sus formas y colores.
-
Damian Zhaoying wrote:El gran problema que parece plantearse es que, por ahora, por todo lo dicho por Ebbe Altberg, mas que llevar a Second Life a nuevo nivel tecnológico, lo que Linden Lab busca es crear un nuevo mundo separado e independiente de Second Life, lo que significaría, por mas buena voluntada que se ponga, que o nos quedamos en SL o nos mudamos al nuevo mundo virtual para empezar de cero (Si aún ni siquiera han pensado si vale la pena transferir lo mas importante para muchos usuarios -me incluyo-: el nombre)..
Saludos
Creo que la idea de partir de 0 es su principal premisa, así como no arrastrar la carga que supone ofrecer compatibilidad o migración... y como programador, considero que es el movimiento más acertado dadas las circunstancias, me explico:
SL cumple 11 años. Se dice rápido, pero es algo que no se suele ver, los entretenimientos virtuales no suelen captar la atención de la gente durante tantos tiempo. Por esto considero que SL ha marcado un hito no sólo en cuando a mundos virtuales se refiere. Pero desde el punto de vista técnico.. también es un problema. ¿Cuantos ejemplos de software conoces que se actualicen semana tras semana parche tras parche, durante tanto tiempo? pocos, muy pocos. A mi sólo se me viene a la cabeza los sistemas operativos, los programas de banca y quizás algún proyecto de software libre, pero en menor escala. E incluso los sistemas operativos hacen borrón y cuenta nueva de cuando en cuando. Esto tiene una explicación, y es que el software da igual del tipo que sea, tiene un ciclo de vida que pasa por diferentes fases. La fase más importante de este ciclo es la fase de diseño, puesto que ella estableceras el esbozo de lo que tu programa va a ser, así como cierto límites que posteriormente no podrás cambiar. Esto es así da igual el programa que sea, has de tomar unas decisiones de diseño que luego va a ser muy caro, o simplemente inviable cambiar. Aún peor si tu programa se ha de actualizar a menudo.
Haré unas comparaciones donde esto se ve muy claro. ¿Conoces Cloud Party? era otro mundo virtual basado en tecnología web, cuyo equipo ha sido fichado recientemente por yahoo. Esta plataforma nació y evolucionó rápido. Implementaban tecnologías en semanas, cuando SL tardaba años (mesh, materiales etc) a pesar de que cuenta con un equipo y una financiación infinitamente mayor. Además lo hacian de una forma mucho más limpia, sin apenas tener que depurar bugs, y con tecnologías completas y no a medio implementar. Construir en Cloud Party era mucho más intuitivo, y no estaba basado en workarounds como en SL. La razónes de porque esto es así son varias, una es que Cloud Party no tenía que lidiar con contenido antiguo, no tenía que preocuparse por romper nada. No es menos cierto que además ellos se podían permitir el lujo de volver atrás en el diseño, y cambiar radicalmente alguna parte, puesto que estaban en Beta. Hay otra razón, y es que la manera de programar a cambiado mucho estos 11 años. Aunque haya a quien le sorprenda leer esto, hoy día no prima la brillantez en el código, es decir, la eficiencia. Hoy lo que prima es la modularidad, la escalabilidad y la posibilidad de reutilizar. Hace 11 años no era así y la consecuencia en SL es clara: es realmente complicado implementar cosas nuevas, además SL nació para cumplir objetivos bien distintos a los que cumple hoy día. He observado que cuando contratan algún nuevo linden para picar código, casi siempre tarda meses en ponerse al día... sólo revisando y entendiendo las partes a las que afectará la nueva característica que debe desarrollar. Por ejemplo, una de las últimas cosas implementadas es la posibilidad de bannear individuos de grupos, a cargo de Baker Linden. Ha tardado 2 años en ver la luz, tuviendo que pasar por una reconstrucción completa. Estamos hablando de añadir unos cuantos botones y un textbox a la ventana de grupo, y hacer cambios en la parte del servidor, no estamos hablando de un cambio mayor como el projecto shining o el proyecto interesting. Al margen de que Baker sea una de las últimas incorporaciones, y por tanto haya tenido que aprender la forma de trabajar en LL... esto es una autentica barbaridad, y no precisamente porque Baker sea mal programador.
Con todo lo dicho quiero reflejar el porqué de la premisa de LL, porqué partir de 0: el software tiene un ciclo de vida, y más allá de este es inviable evolucionarlo y complicado mantenerlo. Me parece muy loable la forma en la que Ebbe maneja este asunto, de mostrarse abierto a discutir cierta portabilidad, y apostar por continuar desarrollando SL en tanto en cuanto sea rentable para ellos. Pero llegados a este punto, volver a partir de un lienzo en blanco es algo completamente necesario y beneficioso, mal que nos duela a los usuarios. Yo espero con impaciencia poder darme una vuelta por este nuevo mundo vacío y verlo evolucionar sin ningún lastre. Espero que la comunicación siga fluyendo y se desvelen más cosas de cuando en cuando, y sobre todo espero que Ebbe cumpla su promesa de que será como SL pero mejor. También considero que hay que reconocer el trabajo de los Lindens programadores durante todos estos años... en más de una ocasión ha debido ser una auténtica pesadilla para ellos.
En cuanto a lo de que no han pensado transferir los nombres:
Bueno.. parece un comienzo.
-
Viviana Baguier wrote:Lo malo es que habra SL 2 y High Fidelity, deberían unir esfuerzos y hace un solo gran proyecto.
Saludos
Por lo que he leido sobre HiFi va a seguir un planteamiento diferente a SL. No va a ser un universo virtual en sí, sino un "framework": un conjunto de herramientas, tecnologías y procedimientos para construir mundos virtuales más o menos individuales, pero que compartirán cosas entre sí. Es un concepto mucho más cercano al metaverso que lo que es SL. Creo que es lo que le rondaba originalmente por la cabeza a Philip Rosedale cuando fundó Linden World. Pero los cambios propuestos por los beta testers, y la idea de atraer a las grandes marcas de RL, derivó en el SL que tanta expectación creó en 2006, a la vez que se alejaba del proyecto que Philip tenía en mente.
Por otro lado, Ebbe ha señalado en varias ocasiones que SL2 va a ser como SL pero mejor ^^'. No construido a partir de HiFi
-
"Before an issue is triaged, everyone can comment to help isolate and describe the issue more clearly. [...] Once an issue is Accepted and imported by Linden Lab’s QA team, the original reporter will still be able to comment, as will Lindens and a small team of community triagers - a group that includes some third party Viewer developers and others selected by Linden Lab for having demonstrated skills in this area."
Are normal users being able to comment when the bug is being triaged. Thats the stage between Awaiting Review and Accepted if i am not wrong. When the bug is being triaged is maybe the stage that more info and feedback needs... Not be able to comment here is a handicap ~~ In any case i dont wanna be ungrateful:
-
Es posible que ese avatar lleve vestido un crasher que haga que tu tarjeta gráfica desfallezca.
-
Puedo poner un ejemplo, pero ha de ser en blender porque es el único programa de diseño 3D con el que me manejo.
En la imagen veras que las dos caras tienen distinto color, es porque a cada una le he asignado un material. Si importo este cubo a SL, cada color será una cara diferente. Es el mecanismo que tiene SL para interpretar las diferentes caras texturizables. Imagino que valdrá para todos los programas de diseño 3d, pero no lo puedo afirmar porque solo he trabajado en este.
Así pues como indiqué en mi anterior post, cada LoD debe conservar las mismas caras que el modelo original. Por el error que muestras, he imaginado que este es tu problema, pero igual me equivoco.
-
Todos los LoDs necesitan tener el mismo número de caras (materiales en blender) que el modelo principal para que el validador de mesh de SL lo de por bueno.
-
Me temo que lo que has comprado no sean brush para photoshop, si no simples texturas. No obstante, tienes la opción de descargarlas y transformarlas en brochas de fotoshop, pero deberás seguir algún tutorial. El primero que he encontrado e este:
Puedes guardar las imagenes con este botón:
Las brochas de photoshop tienen formato propio y se guardan aquí:
C:\Program Files\Adobe\Adobe Photoshop CSx\Presets\Brushes\
-
Disculpa.. mi respuesta ha sido un poco ambigua y es normal que te confunda. Lo que quería decir es que no es normal que un owner pueda acceder al resto de tu inventario fuera de la carpeta #RLV, y que no estoy al tanto de tal fallo en ningún visor con RLV. Coincido con Damian, lo más seguro es que sea un problema de cache de inventario. Sus consejos podrían resolver tu problema. Suerte!
-
A no ser que haya un problema con tu visor, o alguna vulnerabilidad con RLV, la gente a la que permisos de owner solo puede acceder a tu carpeta #RLV.
Eso no quita que debas tener precaución en elegir a quién das dichos permisos, puesto que esto implica un control sobre otros aspectos de tu avatar que puede ser preligroso: como impedir que puedas mandar conversaciones, que te teletransportes, que vistas o desvistas ropa u objetos etc. Todo ello sin ningún tipo de confirmación. Para más información consulta esta guía en español.
-
1
-
-
Worked! thank you so much
-
As i suspected when i started planning the scripting phase of my car, i am having some issues calculating rotations for the doors and stuffs, and moving them with llSetLinkPrimitiveParamsFast.
I elaborate a bit. The doors works fine... as long the script is reset having the root prim facing north->south direction. If, that's not the case, the doors mess up when i open or close them. I am having the same issue using llGetLocalRot() and llGetRootRotation().
This is the code i suspect responsible of the mess:
rotation drOpen; drOpen=(llEuler2Rot(<0.0, 0.0, 50.0>*DEG_TO_RAD))/llGetLocalRot(); llSetLinkPrimitiveParamsFast(rDoor,[PRIM_ROT_LOCAL,drOpen]);
On a sidenote: I modelled doors and stuffs taking into the account the pivot point to make LSL calculations easier, so they actually just need to rotate on the Z axis and dont need extra movements... that didn't prevented the issues.
-
As i suspected when i started planning the scripting phase of my car, i am having some issues calculating rotations for the doors and stuffs, and moving them with llSetLinkPrimitiveParamsFast.
I elaborate a bit. The doors works fine... as long the script is reset having the root prim facing north->south direction. If, that's not the case, the doors mess up when i open or close them. I am having the same issue using llGetLocalRot() and llGetRootRotation().
This is the code i suspect responsible of the mess:
rotation drOpen; drOpen=(llEuler2Rot(<0.0, 0.0, 50.0>*DEG_TO_RAD))/llGetLocalRot(); llSetLinkPrimitiveParamsFast(rDoor,[PRIM_ROT_LOCAL,drOpen]);
On a sidenote: I modelled doors and stuffs taking into the account the pivot point to make LSL calculations easier, so they actually just need to rotate on the Z axis and dont need extra movements... that didn't prevented the issues.
Facebook
Instagram
Twitter
YouTube
Flickr
Bakes On Mesh - Releasing Soon!
in Bakes on Mesh
Posted
Is the support planed after the release?