eufora

há duas opções: 1. vai aparecer pra selecionar 3 canais, selecione o ultimo e clique em conectar. ou 2. corrija o serverlist.bin, trocando o http/site dele pra um que esteja online.

As funções que eu puxei estão funcionais e não puxei devido a problemas, foi só por facilitar a personalização pra cada um que usar destes arquivos na hora de abrir um servidor próprio. Quanto a essa vulnerabilidade é real, bem lembrado, está ali no processattack. Parece que ignora algumas verificações quando o pacote recebido vem com o skipcheck EDIT: link da tm.map atualizado

Explicando melhor o conteudo: São os arquivos-server files originais do wyd br (já tinham postado aqui no fórum a um tempo atrás) até aí nada de novo. Não achei o tópico pra dar creditos aqui a quem compartilhou. O que temos de diferente então? A tmsrvin vinha com a dll Core injetada, a source dela não havia sido compartilhada, então fiz uma dll para substituir e fiz algumas descompilações da tmsrvin migrando algumas funções essenciais como SendScore, GetCurrentScore, CloseUser, ProcessAttack, ProcessAffect, GetScoreBonus, CreateSummon, GridMulticast, StandingByProcessor, UseItem, GetAction, MobKilled, algumas relacionadas ao Kefra, ClientMessageChat, packet control e entre outros. A source está bem desorganizada e o objetivo real era tentar manter a originalidade da versão, descompilando as funções principais pra dentro da dll pra ter um gerenciamento/flexibilidade em pequenos ajustes Para quem busca um servidor completo, sem bugs loucos ou crash's (isso pode existir dentro das descompilações que fiz, então retire o naked, que tudo volta ao original ou corrija). [Hidden Content] Pode ser que existam algumas divergencias no codigo fonte original do arquivo map pro convertido pra dentro da dll, utilizei o codex e fiz alguns testes. Edit:: Para ativar o uso dos comandos de GM, vá em ClientCommand.cpp -> procure por "gm" ou "GM" -> aidicone isso: if (strcmp(command->Cmd, "GM") == 0 || strcmp(command->Cmd, "gm") == 0) { //pula verificação na dbsrv // p295h packetOut; packetOut.header.PacketId = 0x295; packetOut.header.ClientId = clientId; memcpy(packetOut.Name, mob->Mob.Name, 0x10); memcpy(packetOut.Comand, command->Msg, 0x60); ProcessClientMessage(clientId, (char*)&packetOut); return false;

época que o limite de player por canal eram 100 kkkkkk

ei saudade que da kkkk quanto a falta de tempo que você comentou, hoje tá fácil demais, pessoal com sistema até de reconnect….

eu talvez partiria mais pro lado da originalidade, sem areas vip de up/drop, faria um drop mais hard, tentar uma economia mais baixa, itens com alta refinação e bons add bem valorizados... facilitaria mesmo o up. Acho que quanto a versão, apesar de ser fã da 748, quando se fala em reset's, teria que ter limites de status bem altos. Posso estar bem enganado, até porque fazem bons anos que não jogo, mas depois que o cara atinge level maximo, itens bons no servidor, tipo um global, não tem mais logica ficar on o dia todo, no maximo colocar um despertadorzinho ali só pra ir participar das guerras e pvp, fora isso não tem muito mais o que se fazer no jogo, coisa que com o reset talvez resolveria manda o video ai pra nós matar saudade tb

Sim lembro bem, as vezes tinha até um e-mail onde eram feitas as solicitações de reset. Cheguei conhecer o star destiny a +\- 5 anos atrás, não lembro se já tinha reset naquela época. Quanto ao brazuka nunca joguei, mas tenho certa admiração da trajetória que cheguei conhecer, pelas dificuldades que passou e mesmo assim manteve o servidor de pé por todos esses anos.

Lembro que antigamente, em versões iniciais do wyd pirata 6.13 ou 6.56, era mais comum ver sistema de reset. Exemplo, ao atingir level 355 (naquela época travava nesse level), o jogador digitava /reset ou talvez usava algum item e voltava level 1, exp zerado e ganhava score points (pontos pra distribuir em FOR, INT, DEX e CON). Esses reset eram acumulativos e eram necessários pra passar pra próxima evolução. Na época com o limite de status em 32.000, então com uma boa quantia de resets, logo chegava lá. PvPs eram quase intermináveis, bonitos de assistir. O UP era rápido, EXP ficava normalmente em 200 a 300k por monstro, dependo da evolução. Mas enfim, além de trazer essas lembranças pra quem viveu essa época, tenho uma curiosidade em porque não se vê nenhum servidor com resets, hoje com esses limites de status altíssimos e evoluções limitadas. O exp alto torna a jogabilidade rápida e às vezes, ter os melhores itens nem sempre vai garantir que seja o mais forte, porque a quantia de resets acumulados as vezes fala mais alto. Concordo com muitos de que isso foge da originalidade do WYD, mas por outro lado, você tem sempre jogadores upando, não tem level máximo ou evolução máxima, então os grupos de UP ficam contínuos no jogo e o PvP fica ainda melhor.

o trn é o 3131

certo, vou experimentar aqui

o cliente que tu usava pra logar nela, poderia compartilhar?

Como que ele está identificando se está na lan? você poderia mandar as imagens da pasta template aqui talvez

O post tem quase um ano, acredito que o sistema de auto drop ainda funcione, porém deve ter sido atualizado o python que os comandos nao estao mais funcionando [Hidden Content] Edit: Joguei no gemini pra pegar uma ajudinha e resolvi aqui. Funciona muito bem, obrigado por compartilhar

Isso mesmo, no attributemap você tem que alterar a posição do portal também. Para que quando o jogador vá até a coordenada indicada, apareça a janela do “deseja teleportar”.

Parabéns pela ideia e agradecemos por não levar junto pra gaveta, olhando por este ponto de vista vejo bastante logica. Fica ainda mais interessante se restringir acesso a outras contas (multi janelas).