Esa brecha es la razón de ser de esta organización.

Qué hacemos en realidad​

ReHLDS es una versión del Half-Life Dedicated Server de Valve obtenida mediante ingeniería inversa y reconstruida a partir de la build 6153, con los fallos corregidos, los agujeros de seguridad cerrados y los límites ampliados. A su alrededor hay una familia de proyectos que resuelven, cada uno, un problema concreto que un administrador tiene de verdad:

• ReGameDLL_CS: un sustituto estable y ampliado de la biblioteca de juego de Counter-Strike 1.6 y Condition Zero.
• Metamod-r: un gestor de plugins optimizado, con un núcleo compilado mediante JIT.
• ReAPI: las interioridades del motor y de la GameDLL expuestas a los plugins de Pawn como nativas normales, para que sus autores dejen de parchear desplazamientos de memoria.
• ReUnion, ReChecker, ReSemiclip, ReFreeLook: compatibilidad de clientes, verificación de archivos, colisión entre jugadores y control de la cámara de espectador.

Nada de esto es reescribir por reescribir. Cada uno de estos proyectos empezó porque alguien chocó contra un muro en un servidor real y decidió arreglar el motor en lugar de esquivar el problema.

Qué se ha publicado últimamente​

Los proyectos principales se mueven. ReHLDS, ReGameDLL_CS y ReAPI publicaron versión el mismo día el pasado mayo —3.15.0.896, 5.30.0.814 y 5.29.0.358, respectivamente— y tanto ReHLDS como ReGameDLL_CS han recibido cada uno alrededor de treinta commits en el último año. Esto no es un museo.

Merece mención aparte: en julio de 2025 ReHLDS pasó de GPLv3 a la licencia MIT, con el consentimiento explícito de sus principales colaboradores. Fue una decisión deliberada para que resulte más fácil construir sobre el motor, no un trámite.

La documentación por fin es real​

Durante mucho tiempo, la respuesta honesta a «¿dónde está la documentación?» era encogerse de hombros y enlazar un hilo de foro de 2017. Eso ya no es así.

Todos los proyectos de la lista anterior tienen ahora un conjunto completo de documentación: qué son, cómo instalarlos, cada ajuste que ofrecen, cómo compilarlos desde el código fuente y quién los escribió. Y existe en cinco idiomas: inglés, ruso, español, portugués de Brasil y chino simplificado, con 84 páginas cada uno.

La versión china, en particular, valía la pena terminarla bien. Los sitios de documentación recurren al inglés en silencio, página a página, así que un sitio traducido a medias no parece estar a medias: parece roto de una forma que nadie llega a reportar. Ahora ya no lo está.

Junto a eso se publicaron tres secciones nuevas:

• Proyectos de terceros: plugins escritos por miembros de la comunidad fuera de esta organización, Hitbox Fixer y SafeNameAndChat. Se despliegan mucho junto a ReHLDS y merecen poder encontrarse, claramente señalados como ajenos a nosotros.
• Proyectos obsoletos: cuatro proyectos realmente muertos: hitboxtracker, ReAMXModX, ReLocalizeBugFix y LocalizeBugFix. Cada página dice sin rodeos qué fue, por qué se detuvo y qué usar en su lugar. Una página ausente no le dice nada a quien busca; una que dice «esto es incompatible con el ReHLDS actual, usa aquello» le ahorra una tarde.
• Comunidad: herramientas de terceros construidas en torno a ReHLDS, listadas con sus salvedades declaradas abiertamente. Aparecer ahí no es un respaldo, y la página lo dice.

Qué viene ahora​

Los tableros del proyecto son públicos. Si quieres saber en qué se está trabajando de verdad, y no lo que suena bien en un anuncio, ahí es donde hay que mirar.

En cuanto a la documentación, la pregunta evidente es qué idioma añadir. Mirando dónde están realmente los servidores de CS 1.6 en activo, y no dónde suponemos que están, los siguientes candidatos son el rumano y el polaco. Aquí no se promete nada: una traducción solo sigue siendo útil mientras alguien la mantenga al día, y una localización desactualizada es peor que no tenerla.

Cómo ayudar​

Lo más útil que puedes hacer no cuesta nada: ejecuta la versión actual y cuenta qué se rompe.

Un buen informe incluye la build de ReHLDS, tu plataforma, el mod y su versión, la lista de plugins y la salida de consola o el volcado del fallo. En Solución de problemas se explica cómo obtener todo eso. Informes como esos son la razón de que el motor esté donde está: la lista entera de correcciones vino de gente que administra servidores, no de un laboratorio de pruebas.

Más allá de eso, la documentación es un repositorio como cualquier otro. Si una página está mal, no se entiende o le falta algo que tú averiguaste por las malas, una pull request que lo corrija es sinceramente bienvenida, traducciones incluidas.

Y si estás dudando entre preguntar por privado o en público: pregunta en público. La respuesta también le servirá a quien venga detrás.

Nos encontrarás en GitHub, Discord y Telegram. Gracias por mantener estos servidores vivos.

Cuando escribes por privado, el problema se queda «en la sombra»: solo tú y esa persona sabéis que existe. Publicar una pregunta o un fallo en GitHub Issues o en GitHub Discussions permite que no solo el desarrollador, sino también otros miembros de la comunidad, te ayuden a encontrar una solución. Al fin y al cabo, la comunidad del software libre funciona sobre la ayuda mutua y el intercambio de conocimiento. Cuanta más gente participe en resolver algo, antes se resolverá.

¿Por qué publicar en GitHub y no escribir por privado?​

Los desarrolladores son gente ocupada. Cada respuesta a un mensaje privado resta tiempo a tareas como corregir fallos, añadir funciones o optimizar el rendimiento. Mientras el desarrollador dedica tiempo a reunir información sobre tu problema, otros usuarios podrían estar ya ofreciéndote una solución.

¿Por qué importa esto?

1. Debates abiertos: cuando una cuestión o un problema se hace público, otros usuarios pueden aportar sus soluciones o sugerencias. Eso fomenta un ambiente de colaboración activa.

2. Visibilidad pública: cualquiera puede ver tu pregunta y ayudarte a encontrar una solución, lo que aumenta mucho las probabilidades de resolverla pronto.

3. Ahorro de recursos: el tiempo de los desarrolladores es limitado y debería centrarse en problemas mayores y más complejos, no en casos sencillos que podrían resolverse en espacios públicos.

La eficacia de la comunicación en el código abierto​

Plataformas como GitHub Issues o Discussions están pensadas precisamente para que usuarios y desarrolladores debatan los proyectos y sus problemas. Conviene entender que quien usa el software no siempre puede juzgar con objetividad la magnitud de un problema. A veces, lo que parece un fallo crítico resulta ser un simple malentendido o un error de instalación. Por eso los debates abiertos ayudan a todos los participantes del proyecto a valorar la importancia real de una cuestión y a resolverla cuanto antes.

Cómo preguntar en GitHub​

1. Sé concreto: describe los pasos que llevaron al error.
2. Aporta contexto: indica el sistema que usas y las versiones implicadas.
3. Adjunta registros: eso acelera muchísimo el diagnóstico y la resolución.

En lugar de escribir por privado, crea una issue con una descripción detallada del problema. No solo acelerará la solución, sino que te ahorrará esperas e incertidumbre innecesarias.

Contribuir al proyecto​

Recuerda que cada pregunta o mensaje en un canal público, ya sea un debate en GitHub o un chat, es una contribución al desarrollo del proyecto. Se valora mucho más que la comunicación por privado. Los canales públicos ayudan a crear una comunidad en la que el conocimiento y las ideas circulan más rápido de lo que lo harían en mensajes privados.

Recursos​

• GitHub Issues
• GitHub Discussions
• Comunidad de Discord
• Tableros de GitHub

Al crear issues, enviar pull requests o simplemente participar en los debates, ya estás haciendo una aportación importante al desarrollo del proyecto. Todos los debates, fallos y sugerencias no solo te ayudan a ti, sino también al resto de la comunidad, y mejoran el proyecto para todo el mundo.

¿Por qué unirte?​

Como gestor de comunidad tendrás un papel decisivo en la experiencia de usuarios y desarrolladores. Desde moderar debates y ayudar a los recién llegados hasta organizar recursos y apoyar la creación de contenido, encontrarás muchas formas distintas de aportar algo de valor.

Qué harás​

Tenemos un tablero de 🤝 Community & UX Initiatives con la lista de tareas y prioridades de la comunidad en las que se va a centrar el equipo. Te animamos a elegir las tareas que más te interesen o a proponer ideas que encajen con nuestros objetivos.

Responsabilidades principales:

• Participar con los miembros de la comunidad para mantener un ambiente cercano y solidario.
• Ayudar a organizar, etiquetar y gestionar issues y pull requests.
• Colaborar en la recogida de comentarios de la comunidad y en la mejora de nuestros recursos.
• Trabajar junto a otros colaboradores en las iniciativas de la comunidad.

Una colaboración flexible​

Aunque hay un plan de tareas definido, valoramos la flexibilidad. Si hay un área que te interesa especialmente, también son bienvenidas tus ideas y tu apoyo en ella.

Cómo apuntarte​

Si te interesa unirte, rellena este formulario de Google con algunos datos básicos sobre tu experiencia, tu contacto y tus intereses. ¡Nos encantará saber más de ti!

¡Construyamos juntos una comunidad de ReHLDS más acogedora y con más vida!