É essa lacuna que esta organização existe para preencher.

O que nós fazemos, de fato​

O ReHLDS é uma versão reformulada do Half-Life Dedicated Server da Valve, obtida por engenharia reversa e reconstruída a partir da build 6153, com os bugs corrigidos, as falhas de segurança fechadas e os limites ampliados. Em torno dele existe uma família de projetos, cada um resolvendo um problema específico que um administrador realmente tem:

• ReGameDLL_CS — um substituto estável e ampliado da biblioteca de jogo do Counter-Strike 1.6 e do Condition Zero.
• Metamod-r — um gerenciador de plugins otimizado, com núcleo compilado por JIT.
• ReAPI — as entranhas do motor e da GameDLL expostas aos plugins em Pawn como natives comuns, para que os autores de plugins parem de aplicar patches em offsets de memória.
• ReUnion, ReChecker, ReSemiclip, ReFreeLook — compatibilidade de clientes, verificação de arquivos, colisão entre jogadores e controle da câmera do espectador.

Nada disso é reescrita por esporte. Cada um desses projetos começou porque alguém bateu numa parede em um servidor ao vivo e decidiu consertar o motor em vez de contorná-lo.

O que foi lançado recentemente​

Os projetos principais estão em movimento. ReHLDS, ReGameDLL_CS e ReAPI lançaram versões no mesmo dia em maio deste ano — 3.15.0.896, 5.30.0.814 e 5.29.0.358, respectivamente — e o ReHLDS e o ReGameDLL_CS receberam cerca de trinta commits cada um no último ano. Isto aqui não é um museu.

Vale destacar à parte: em julho de 2025 o ReHLDS migrou da GPLv3 para a licença MIT, com o consentimento explícito dos seus principais colaboradores. Foi uma decisão deliberada para facilitar construir coisas sobre o motor, e não uma formalidade.

A documentação finalmente existe de verdade​

Por muito tempo, a resposta honesta para "cadê a documentação?" era dar de ombros e mandar o link de um tópico de fórum de 2017. Isso deixou de ser verdade.

Todos os projetos listados acima agora têm um conjunto completo de documentação — o que é, como instalar, todas as configurações que oferece, como compilar a partir do código-fonte e quem o escreveu. E tudo isso existe em cinco idiomas: inglês, russo, espanhol, português do Brasil e chinês simplificado, com 84 páginas cada.

O idioma chinês, em especial, valeu a pena terminar direito. Sites de documentação recorrem ao inglês em silêncio, página por página, então um site parcialmente traduzido não parece parcial — parece quebrado de um jeito que ninguém relata. Agora não parece mais.

Três seções novas subiram junto:

• Projetos de terceiros — plugins escritos por membros da comunidade fora desta organização, o Hitbox Fixer e o SafeNameAndChat. Eles são muito usados junto do ReHLDS e merecem ser encontráveis, com a etiqueta clara de que não são nossos.
• Projetos descontinuados — quatro projetos genuinamente mortos: hitboxtracker, ReAMXModX, ReLocalizeBugFix e LocalizeBugFix. Cada página diz de forma direta o que aquilo era, por que parou e o que usar no lugar. Uma página ausente não diz nada a um administrador que está procurando; uma página que diz "isto é incompatível com o ReHLDS moderno, use aquilo" poupa a noite dele.
• Comunidade — ferramentas de terceiros construídas em torno do ReHLDS, listadas com as ressalvas declaradas abertamente. Estar na lista não é um endosso, e a página diz isso.

O que vem a seguir​

Os quadros do projeto são públicos. Se você quer saber o que está sendo realmente trabalhado, em vez do que soa bem em um post de anúncio, é lá que se olha.

Do lado da documentação, a pergunta óbvia seguinte é qual idioma acrescentar. Olhando para onde os servidores ativos de CS 1.6 de fato estão, e não para onde supomos que estejam, os próximos candidatos são o romeno e o polonês. Nada é prometido aqui: uma tradução só continua útil enquanto alguém a mantém em dia, e um idioma desatualizado é pior do que nenhum.

Como ajudar​

A coisa mais útil que você pode fazer não custa nada: rode a versão atual e relate o que quebrar.

Um bom relato inclui a build do ReHLDS, a sua plataforma, o mod e a versão dele, a sua lista de plugins e a saída do console ou o dump do travamento. A Solução de problemas explica como capturar tudo isso. Relatos assim são como o motor chegou onde está — toda a lista de correções veio de gente rodando servidores, não de um laboratório de testes.

Além disso: a documentação é um repositório como outro qualquer. Se uma página está errada, confusa ou não traz algo que você teve de descobrir na marra, um pull request corrigindo isso é sinceramente bem-vindo — traduções incluídas.

E se você está decidindo entre perguntar por mensagem privada ou em público: pergunte em público. A resposta ajuda a próxima pessoa também.

Encontre a gente no GitHub, no Discord e no Telegram. Obrigado por manter esses servidores vivos.

Quando você manda uma DM, o problema fica "nas sombras". Só você e o desenvolvedor sabem dele. Publicar uma pergunta ou um bug nas GitHub Issues ou nas GitHub Discussions permite que não apenas o desenvolvedor, mas também outros membros da comunidade, ajudem você a encontrar uma solução. Afinal, a comunidade de código aberto funciona com base na ajuda mútua e na troca de conhecimento. Quanto mais gente envolvida na solução do problema, mais rápido ele será resolvido.

Por que publicar no GitHub em vez de mandar DM?​

Desenvolvedores são pessoas ocupadas. Cada resposta a uma mensagem direta tira tempo de tarefas como corrigir bugs, acrescentar recursos ou otimizar o desempenho. Enquanto o desenvolvedor gasta tempo reunindo informações sobre o seu problema, outros usuários poderiam estar oferecendo uma solução.

Por que isso importa?

1. Discussões abertas: quando um problema ou uma pergunta se torna público, outros usuários podem compartilhar soluções ou sugestões. Isso cultiva um clima ativo de colaboração.

2. Visibilidade pública: todos podem ver a sua pergunta e ajudar você a encontrar uma solução, o que aumenta bastante a chance de uma resolução rápida.

3. Economia de recursos: o tempo dos desenvolvedores é limitado e deve se concentrar em questões maiores e mais complexas, e não em resolver casos simples que poderiam ser tratados em espaços públicos.

A eficácia da comunicação no código aberto​

Plataformas como as GitHub Issues ou as Discussions existem para que usuários e desenvolvedores discutam os projetos e os problemas deles. É importante entender que os usuários finais nem sempre conseguem avaliar objetivamente a dimensão de um problema. Às vezes, o que parece um bug crítico é, na verdade, um simples mal-entendido ou um erro de instalação. Por isso, as discussões abertas ajudam todos os participantes do projeto a avaliar a real importância de um problema e a resolvê-lo o mais rápido possível.

Como fazer perguntas no GitHub​

1. Seja específico: descreva os passos que levaram ao erro.
2. Dê contexto: informe o sistema que você usa e as versões envolvidas.
3. Anexe os logs: isso acelera bastante o diagnóstico e a resolução do problema.

Em vez de mandar uma DM, abra uma issue com uma descrição detalhada do problema. Isso não só acelera a resolução, como também poupa você de esperas e incertezas desnecessárias.

Contribuindo com o projeto​

Lembre-se: toda pergunta ou mensagem em canais públicos, seja em uma discussão no GitHub ou em um bate-papo, é uma contribuição ao desenvolvimento do projeto. Isso é muito mais valorizado do que uma conversa por DM. Os canais públicos ajudam a criar uma comunidade em que o conhecimento e as ideias circulam mais rápido do que circulariam em mensagens privadas.

Recursos​

• GitHub Issues
• GitHub Discussions
• Comunidade no Discord
• Quadros no GitHub

Ao abrir issues, enviar pull requests ou simplesmente participar das discussões, você já está dando uma contribuição importante ao desenvolvimento do projeto. Todas as discussões, bugs e sugestões ajudam não só você, mas também os outros membros da comunidade, e melhoram o projeto para todo mundo.

Por que se juntar a nós?​

Como Community Manager, você terá um papel decisivo em moldar a experiência dos usuários e desenvolvedores da nossa comunidade. De moderar discussões e ajudar recém-chegados a organizar recursos e apoiar a criação de conteúdo, você terá várias oportunidades de contribuir de forma significativa.

O que você vai fazer​

Temos um quadro de 🤝 Iniciativas de Comunidade e UX com uma lista de tarefas e prioridades da comunidade nas quais a nossa equipe vai se concentrar. Você poderá escolher as tarefas que mais lhe interessarem ou propor ideias alinhadas aos nossos objetivos.

Principais responsabilidades:

• Interagir com os membros da comunidade para cultivar um ambiente amigável e acolhedor.
• Ajudar a organizar, etiquetar e administrar issues e pull requests.
• Auxiliar na coleta de retorno da comunidade e na melhoria dos nossos recursos.
• Trabalhar em conjunto com outros colaboradores nas iniciativas da comunidade.

Contribuição flexível​

Ainda que tenhamos um plano definido de tarefas, valorizamos a flexibilidade. Se existe uma área específica pela qual você se interessa, as suas ideias e o seu apoio nessa área também são muito bem-vindos.

Como se candidatar​

Se você tem interesse em participar, preencha este formulário do Google com algumas informações básicas sobre a sua experiência, os seus contatos e os seus interesses. Mal podemos esperar para conhecer você melhor!

Vamos trabalhar juntos para construir uma comunidade do ReHLDS mais acolhedora e vibrante!