Buenas, staff de Librecraft. Quisiera proponer la posibilidad de reimplantar la obtención de heads de jugadores, ya sea mediante el comando /skull u obtenerla de manera directa en el inventario, pero de forma controlada y equilibrada para evitar los problemas que existían antes. Una idea sería habilitarlo solo en fechas especiales o eventos del servidor, para que mantenga su valor y no se vuelva algo abusivo. Por ejemplo: 1. Permitir el uso de /skull (nombre del jugador) por un precio alto dentro del juego, por ejemplo 6,500,000 de dinero. Limitar su uso a eventos especiales (aniversario del servidor, Navidad, Halloween, etc.). Colocar límites por jugador para evitar granjas o abuso (por ejemplo, cierta cantidad por evento). Mantenerlo como un objeto principalmente decorativo, para parcelas, bases o colecciones. 2. Obtener la HEAD de manera directa a su inventario por un precio alto dentro del juego, por ejemplo 6,500,000 de dinero. Limitar su uso a eventos especiales (aniversario del servidor, Navidad, Halloween, etc.). Colocar límites por jugador para evitar granjas o abuso (por ejemplo, cierta cantidad por evento). Mantenerlo como un objeto principalmente decorativo, para parcelas, bases o colecciones. Muchos jugadores antiguos recuerdan que las heads eran parte de la esencia del survival de Librecraft, ya que permitían decorar, coleccionar cabezas de amigos o de jugadores conocidos del servidor, y le daban un toque más personal a las construcciones. Además, al tener un precio alto, se convierte también en un buen sink de economía, ayudando a retirar dinero del servidor y manteniendo el valor de la moneda. Creo que, implementado de forma limitada y controlada, no generaría los problemas del pasado y al mismo tiempo devolvería una característica que muchos jugadores recuerdan con nostalgia.
Tema repetitivo, no se volverá a agregar la posibilidad de obtener cabezas porque se pierden las texturas de las mismas, además, el comando fue removido debido a los trolleos masivos que hacian a los usuarios con zonas de lag. Si bien se puedan obtener por una cifra alta de dinero, el problema es, como te mencionaba antes, que se pierden las texturas.
Sé que suena repetitivo pero no lo es, ya que yo estoy dando la posibilidad alguna de obtenerla sin Exageraciones, Ni bugs, Ni errores. Suena a que estás desinteresado en esto y dando la misma respuesta que todos los temas de foro que he leído (Añadiendo que no he leído ningun otro post de foro que haya dado la misma idea) Entiendo el punto sobre los trolleos y el lag que se generaba antes, sin embargo, actualmente en el servidor ya existen muchas heads antiguas colocadas por los jugadores, y estas siguen generando exactamente el mismo efecto visual o de carga. además, si se implementa con límites, costo alto o solo en eventos, ese problema podría evitarse. La posibilidad de mi sugerencia sigue activa. La solución hacia el problema de Heads resuelta. Ahora sobre lo de las texturas lo daré en el tema de abajo, es un tema algo más técnico y eso llevaría más a que lo piensen los ADMINS Entiendo el punto sobre que las heads pueden perder sus texturas con el tiempo. Sin embargo, según tengo entendido, actualmente muchos servidores evitan ese problema guardando la textura directamente en el NBT de la cabeza (texture value / base64) en lugar de depender únicamente de la skin actual del jugador. De esa forma la textura queda almacenada dentro del ítem, por lo que no cambia si el jugador modifica su skin, cambia de nombre o si el sistema de skins de Mojang se actualiza. Básicamente la cabeza conserva permanentemente la textura que tenía al momento de ser generada. Por eso pensaba que quizá podría evaluarse una implementación similar o algún plugin que guarde la textura de esa manera, lo que evitaría el problema de pérdida de skins que ocurría antes.
El tema es repetitivo en general, siempre son las mismas propuestas, ya sea que se pueda adquirir por dinero, mediante llaves, etc. Hace unos meses se añadió a la llave vote con un 1% de probabilidad de que saliera, y como te comentaba antes, por temas de carga en las texturas se decidió eliminar también esa función. De todos modos, espera la respuesta de leo, pero no tengas muchas esperanzas.
Aunque las heads fueron usadas en su mayoría para trollear, no creo que devolverlas sea una mala idea, es verdad que es una sugerencia repetitiva pero deberían hacer un comando diferente, como por ejemplo, apartir del vip+ para arriba, puedes hacer /head (nick) 1 vez cada mes, así como el comando /miatajo, para mantener el valor de estas, o si no, /head y te proporcionaría la head de la skin que tienes en el momento de ejecutar el comando.
es raro que hace años se obtenia con facilidad y aun así en stacks (ni stacks, Cofres dobles) y ahora tengan el error de texturas con solo la UNIDAD de la head de otro usuario. Como dije si eso es posible, es un tema complicado y es ya más temas mayores Es buena idea y sugerencia el tuyo, te apoyo en eso VIP+: Obtener la capacidad del comando /Head con tu Skin y Nombre 1 vez al mes, en cada compra (COMO /MIATAJO) SVIP: Obtener la capacidad del comando /Head con tu Skin y Nombre 1 vez al mes, en cada compra (COMO /MIATAJO) (SVIP lo mismo ya que, ya tiene otra ventaja mejor que el vip+, la cual es el /god) +1
El problema no es ni de las texturas, ni las zonas de lag; el problema es el desinterés y la falta de devs activos. Las texturas rotativas que ven como problema, sucede porque tienen esas texturas cacheadas en el servidor. Los usuarios no premium por default no tienen skins a menos que la asignes con /skin nickpremium. El problema se solucionaría borrando las texturas cacheadas viejas y dejando solo una, que se asigne al momento de hacer el /skin update. Y sobre las zonas de lag (que incluso he escuchado que han borrado zonas debido a esto), va ligado, todas esas texturas las tiene que descargar el cliente individual de cada usuario y si no es lo suficiente potente su pc, peta. La solución sería o implementar un límite de heads x chunk, o hacer un fix con ProtocolLib para que cada usuario tenga preferencias de render de heads a x distancia, empezando por default a 0 bloques, pudiéndola actualizar quizá con /renderheads 10 o yo qué sé, pero esto ya está en sus manos, no es problema del juego, sino que durante años han hecho lo mismo, prefieren simplemente eliminar la función y decir "está bugeado".
Se hizo una prueba piloto en 2025 y las cabezas perdían las texturas. Si pongo las cabezas habrá todos los días temas diciendo: Pague 20000 por una cabeza y desapareció. Devuelvanme el dinero. Le compré una cabeza a un jugador y perdió la textura. Me estafaron. Tenía mi parcela muy bonita y ahora ya no tienen texturas. La skin de mi cabeza no se actualiza.
Si hubiera desinterés en el servidor te aseguro que no tendría un uptime de 99,95 y que ya estaría clausurado. El servidor se mantiene funcionado gracias al trabajo voluntario que hacen tanto los staffs como las personas que llevamos la parte técnica. Ya me gustaría ver a mi servidores con 11 años, que tengan todo pegado con cintas y cuerdas pero que estén funcionando. Para mi desde luego que muchas veces lo más fácil sería coger y borrar todo y olvidarme de los problemas. El servidor sólo cachea las skins que carga desde que inicia hasta el próximo reinicio. Es decir, un máximo de 24 horas. El problema con las cabezas son varios y distintos. Una cabeza puede renderizar la skin de dos maneras (*1): En base al nombre de usuario. En base al enlace a la textura que está almacenada dentro de la propia cabeza. Las cabezas antiguas del servidor creo que se generaron por el primero de los métodos (en base al nombre del usuario). Aquí antiguamente había dos formas de recuperar las skins: Un endpoint directo que simplemente era algo como http://skins.minecraft.net/MinecraftSkins/<usuario>.png. (*2) Y otro endpoint que implica obtener primero la UUID de la cuenta en base al nombre y posteriormente preguntar la skin para esa UUID (*3). En la versión de Minecraft 1.7 (que por cierto es donde empezó el survival en 2015 para ponernos en perspectiva) se utilizaba el primero de los métodos. Sospecho que con la introducción de las UUID en la 1.7.7 (creo) y su consolidación en la 1.8 se pasa al otro método pero no sabría decir cual de ellos es el que usa realmente el servidor. De todas formas los 2 tienen problemas: El primero de los métodos (*2) fue deshabilitado ya en 2018 (la versión 1.8 es de 2013 para seguir ubicados en el espacio-tiempo). Y como te indica la wiki el segundo es inestable y no es fiable porque falla (*3) y muchas veces no devuelve correctamente las skins. Por tanto, ya tenemos el primer problema y es que todas las cabezas viejas si están generadas por nombre de usuario (y no tienen la textura almacenada) no se van a poder cargar. El problema es que esas cabezas siguen haciendo la solicitud a los servidores de Mojang y sospecho que en ciertos momentos podrían saturarlo y bloquear, por lo que no renderiza ninguna cabeza durante ese periodo. Sobre las segundas ("enlace" a textura guardada en la propia cabeza), en principio no debería haber problema (siempre que no se solicite a Mojang la textura estando limitados). El problema es que esas cabezas tienen una textura fija entonces no es "cabeza de jugador" si no "cabeza de jugador en el momento xxx que es cuando se generó en base a la skin que tenían". Los dos sistemas que utilizamos en su día (soltar cabeza al morir y /skull) no sé como sacaban las cabezas, pero me parece que a los usuarios NO premium aunque tuvieran una skin en el servidor no les funcionaba correctamente ya que se obtenía la skin en base al nombre y ya. Por tanto, como no funcionaba se optó por quitarlas y ya. Hace 1 año hice una prueba de poner unas cabezas en la llave de votar, a través de un sistema que usaba la skin del momento pero que obtenía la que estaba obteniendo en el servidor (premium si eras premium o la skin que tuvieras puesta en el serivdor si eras no premium). Por algún motivo (los reportes del bug están en el foro), las cabezas no cargaban correctamente, por lo que desistí completamente. Es un error que no voy a perder más tiempo en localizar. En los minijuegos donde hay tops cargan correctamente, auqnue a veces fallan. En creativo 1.12 cargan correctamente (supongo que porque son "enlaces a texturas" almacenadas en la cabeza) y porque es una versión más moderna. En un modo donde se pierde tiempo, recursos y esfuerzos en obtener algo que no funciona, como comprenderás, directamente desactivo la característica si no funciona para no generar espectativas ni tener que dedicar tiempo a responder que existe un problema. Esta es nuetsra experiencia en este servidor. Hay muchas cosas que podrían influir (no lo creo) y desde el punto de vista de experiencia y tiempos de desarrollo no merece la pena perder el tiempo en idetnifciar un problema que no parece tener solución ya que no depende de un plugin si no del propio software del servidor -------------------------- Referencias: *1 https://minecraft.wiki/w/Player_Head#Item_data *2 https://www.reddit.com/r/Minecraft/comments/7x8m60/psa_all_skin_based_websites_programs_apis_etc/ *3 https://minecraft.wiki/w/Mojang_API#Query_player's_username
anteriormente vi un evento que hicieron algunos staffs haciendo /skull o dando de premio la head del jugador ganador, aunque acepto esa respuesta
Sin duda es cuestión de cómo el plugin maneja los datos, desconozco su configuración, pero no es un callejón sin salida Justamente es eso, si un usuario se acerca a una zona con muchas heads, saturará el rate limit de Mojang porque por cada nick sea o no premium, hará una petición. La solución en servidores que siguen en la 1.8.x es inyectar el valor Base64 de la textura directamente en el GameProfile mediante NBT tags o reflection (que te lo recomiendo porque es mucho más limpio al sobrescribir directamente el GameProfile interno del SkullMeta con tu Base64), usando async para no tener bajones deTPS. Esto pasa porque el plugin depende que el bloque se actualice solo, para que no sea dinámico, debe interceptarlo y leer los datos actualizados cacheados (por ejemplo al abrir el GUI o al cargar un chunk), así evitamos las texturas rotativas entre nuevas y viejas quedándonos con la más nueva. Aquí está la raíz del fallo de los no premium, si el código usa métodos como SkullMeta.setOwner("usuario"), la API de Spigot 1.8.8 fuerza al servidor a buscar ese nombre en los servidores de Mojang, como Mojang no tiene registro de los no premium, rechaza la petición, la cabeza no carga y se satura el rate limit a lo tonto. Para que funcione sin bugs, jamás se le pregunta a Mojang. El Base64 se obtiene localmente: Si el usuario está online: El plugin de skins ya le asignó la textura, solo hay que extraer el Base64 de la propiedad textures de su GameProfile directamente desde la memoria y se refleja instantáneamente. Si el usuario está offline: El plugin consulta la base de datos local para obtener la última textura guardada, e inyecta ese Base64 en el ítem. He testeado un tiempo con la API de Spigot en la 1.8.8 y sé de primera mano lo restrictivo que es, pero es un problema que un plugin puede interceptar y solucionar modificando el perfil del bloque. Precisamente para que no tengas que destinar más tiempo ni recursos a algo que ya descartaste, si quieres pásame el plugin que usas o el código que usaste en la prueba de las keys para revisarlo, ya ni he jugado pero me gustaría tener algunas por nostalgia, y de paso se podría agregar el /skull a las ventajas.
Te invito a coger el base64 de una textura y decodearlo. Es un json con enlaces a las texturas. Siempre es un enlace.
Correcto, ese enlace apunta al CDN de texturas (textures.minecraft.net), que es un CDN sin rate limit restrictivo. El rate limit que satura las heads y las deja en steve está en la API de sesión (sessionserver.mojang.com), que es a donde spigot llama cuando se usa setOwner("usuario") para resolver nombre > UUID > perfil, son 2 sistemas distintos. Inyectando el Base64 cacheado directo en el GameProfile del ítem, el servidor hace 0 peticiones a Mojang. Para no premium igual, el plugin de skins ya tiene esa textura en su DB local, se lee de ahí y listo. Ahora, hay un segundo problema, si un jugador entra a una zona con muchas heads colocadas como bloques, el servidor le manda todos los paquetes NBT con texturas de golpe al cargar el chunk y eso crashea al cliente del usuario, la solución es un lazy load para que el plugin deje que las heads carguen inicialmente como steve (ultra ligero), y después va inyectando las texturas de forma escalonada con un BukkitRunnable async, por ejemplo 5 heads cada 10 ticks. Así el usuario sólo ve cómo van cargando progresivamente, sin bajones de FPS ni crasheos
Debes utilizar el formulario especial para alguno de estos problemas:Cerrar notificación