Gabriel

Opa, O barra /make seria interessante Start eventos

É interessante com discord direto, porem para usuários que nao tem discord limitaria e teria que automaticamente obrigar os players a usarem o discord para conseguir usar o voip, não seu se isso seria bacana, até os problemas judiciais no Brasil com esse poder... podem do nada desabilitar o serviço hoje esta Suspenso: Transmissão ao vivo, compartilhamento de tela e chamadas de vídeo (incluindo DMs e canais de voz com vídeo) por agora, do nada os supremos podem simplesmente desabilitar tudo

Bom dia, Estava fazendo um script aqui para s6 plus, pensei em compartilhar a ideia para ver se conseguimos agregar aos sistemas extra no gs assim como é feito com o discord O sistema seria para uso de voz por PT, Guild e Proximidade. Ideia, por pt e guild deve ficar otimo para organizar estratégias etc... Já por proximidades acho que cidades lotadas deve ficar uma zona. Já fiz os testes aqui esta funcionando via um servidor aberto por cmd na vps deu tudo certinho, mais se conseguir agregar isso aos sistemas da Genesys com a assinatura visual e qualidade seria muito interessante Não esta 100% necessita de ajustes. VoicePartyChannelIntegration-Source.zip

A taxa José esta sendo aplicada por item postado? Por exemplo, 10 Cash para colocar um item no leilão, para não haver players colocando itens inúteis ou floodando no Marketplace Poderia limitar tambem a quantidade de item que pode ser postado por nivel de conta tipo Free posta 5 itens por vez, Vip posta 10 itens por vez. etc... Prazo de X dias para o item ficar ativo no leilão, após precisa renovar etc.. Taxa pós venda % em cima do valor da venda.

A Web da Genesys vai ser paga ? Poderia dar uma explicação de como ela irá funcionar ?

Olá Opção para mudar a Start Position da camera, ele inicia atualmente assim : Gostaria de ter a possibilidade de alterar esse zoom de entrada padrão para conseguir deixar a visão mais ampla já iniciando com zoom aplicado, exemplo :

Gostaria de compartilhar uma ideia aqui com vocês, fazer um minimap no lado do GS podendo ver todos os Spots, Invasões, Npc e Players em tempo real, assim podendo acompanhar o que se passa em cada mapa.

Perfeito obrigado man !

Olá José. Analisando melhor a documentação e os arquivos do servidor, encontrei o arquivo CustomInstance.txt. Pelo que entendi, ele indica que já existe um sistema de instâncias na source, com configurações como: MaxActiveInstance MaxPlayersPerInstance MaxActiveMapsPerInstance DurationMinutes MaxMonsterUse Além disso, é possível definir quais mapas aceitam instâncias privadas. Minha dúvida é: esse sistema já está totalmente implementado na source? A ideia que tenho é desenvolver dungeons totalmente em Lua, por exemplo: Cada party entra em sua própria instância. Cada instância possui monstros, boss, progresso e cronômetro independentes. Uma party não interfere na outra, mesmo utilizando o mesmo mapa base. Ao finalizar ou expirar o tempo, a instância é destruída automaticamente. Gostaria de saber se atualmente existe alguma forma de acessar esse sistema pelo Lua ou se ele é utilizado apenas internamente pela source. Caso ainda não exista uma API para isso, acredito que algumas funções como estas seriam suficientes para permitir a criação de sistemas bastante avançados: Instance.Create(map) Instance.Destroy(instanceId) player:getInstance() player:setInstance(instanceId) Instance.AddPlayer(instanceId, player) Instance.RemovePlayer(instanceId, player) Instance.SpawnMonster(instanceId, monsterClass, x, y) Instance.GetPlayers(instanceId)Com isso seria possível desenvolver dungeons, raids, torres, eventos PvE e outros sistemas praticamente apenas em Lua, aproveitando um recurso que aparentemente a source já possui. O que você acha? O sistema do CustomInstance já suporta esse tipo de utilização ou ainda seria necessário expandi-lo? O sistema que eu estava desenvolvendo aqui era justamente uma dungeon/raid em Lua. A solução que encontrei, sem um sistema de instâncias, seria criar várias cópias do mesmo mapa. Por exemplo, quando uma party tenta iniciar a dungeon, o servidor verifica: Se o mapa X estiver ocupado, tenta o mapa Y. Se o mapa Y estiver ocupado, tenta o mapa Z. E assim sucessivamente até encontrar um mapa livre. O problema dessa abordagem é que ela possui algumas limitações importantes. Primeiro, é necessário duplicar os arquivos do mapa World e Object para cada slot da dungeon. Se eu quiser permitir 10 execuções simultâneas da mesma raid, precisarei manter 10 cópias desses arquivos, aumentando o tamanho do cliente e tornando a manutenção muito mais trabalhosa. Qualquer alteração no mapa precisa ser replicada em todas as cópias. Além disso, vi que o sistema de CustomInstance está configurado para suportar até 10 instâncias. Na prática, esse limite pode acabar sendo baixo dependendo do conteúdo do servidor. Por exemplo, imagine uma única raid com três dificuldades: Easy Medium Hard Se houver 10 players ou 10 parties executando essas variações ao mesmo tempo, todas as instâncias disponíveis já estariam ocupadas. Isso impediria que outros jogadores participassem de outras dungeons ou raids que também utilizassem o sistema de instâncias. Minha dúvida é: Esse limite de 10 instâncias é apenas uma configuração do CustomInstance.txt ou é uma limitação da própria source? O sistema foi desenvolvido para suportar um número maior de instâncias simultâneas? Existe alguma forma de acessar esse sistema via Lua, ou a intenção é que ele seja utilizado apenas internamente? Acredito que um sistema de instâncias mais flexível abriria muitas possibilidades para criação de conteúdo PvE, como dungeons, raids, torres, campanhas e eventos, sem a necessidade de duplicar mapas e mantendo um consumo muito menor de recursos no cliente.

Sugestão de implementação de suporte a Mapa por Instância (Dungeon Instance) Olá! Gostaria de sugerir a implementação de um sistema de Map Instance (Instância de Mapa) no emulador. Hoje, quando vários jogadores entram em uma dungeon, todos utilizam o mesmo mapa físico, compartilhando monstros, NPCs e progresso. Isso limita bastante a criação de sistemas PvE modernos. A ideia seria permitir que o servidor criasse várias cópias independentes de um mesmo mapa. ExemploExiste apenas um mapa: Mapa 70Hoje: Party A Party B Party C ↓ Mapa 70Resultado: todos veem os mesmos monstros; todos atacam o mesmo boss; progresso compartilhado; uma party pode atrapalhar a outra. A proposta seria: Party A ↓ Mapa 70 (Instância 1) ------------------------ Party B ↓ Mapa 70 (Instância 2) ------------------------ Party C ↓ Mapa 70 (Instância 3)Visualmente o mapa é exatamente o mesmo. Porém cada instância possui: monstros próprios; NPCs próprios; progresso próprio; cronômetro próprio; boss próprio; eventos próprios. Nenhuma party interfere na outra. Exemplo práticoParty A mata o Boss. Somente a Party A recebe: Etapa concluídaEnquanto isso, a Party B continua normalmente na primeira etapa. Nenhum monstro desaparece da outra instância. O que seria interessante existir na SourceAlgo semelhante a: int CreateMapInstance(int map);Retorno: InstanceIDDepois: MoveUserToInstance(Index, InstanceID);ou MoveUser( Index, Map, InstanceID, X, Y );Para monstros: CreateMonster( MonsterClass, InstanceID, X, Y );Ou Monster.Instance = InstanceID;Assim cada instância teria seus próprios monstros. ConsultasTambém seria interessante: GetUserInstance(Index); GetMonsterInstance(Index); DestroyInstance(InstanceID); GetPlayersInInstance(InstanceID);Eventos LuaSeria excelente disponibilizar nas bridges Lua algo como: User.GetInstance(aIndex) User.SetInstance(aIndex, instance) Monster.GetInstance(monster) Instance.Create(map) Instance.Destroy(id) Instance.GetPlayers(id)Ou funções equivalentes. BenefíciosCom esse recurso seria possível desenvolver: Dungeons por Party Dungeons Solo Boss exclusivos Sistema de Andares Torre Infinita Survival Raid Castle PvE Eventos temporários Missões por instância Campanhas Labirintos Challenge Mode Speed Run Ranking por tempo Tudo sem conflito entre jogadores. Consumo de memóriaNão seria necessário duplicar arquivos do mapa. Uma instância utilizaria os mesmos recursos carregados: Terrain Objects Textures BMD Mudaria apenas o estado da execução: Jogadores Monstros NPCs Drops Objetos temporários Cronômetros EventosOu seja, várias instâncias utilizariam o mesmo mapa carregado em memória, alterando apenas os dados dinâmicos. Exemplo de usoint instance = CreateMapInstance(70); MoveUserToInstance(player1, instance); MoveUserToInstance(player2, instance); CreateMonster(BudgeDragon, instance, 120, 85); CreateMonster(BudgeDragon, instance, 125, 90); CreateMonster(Boss, instance, 150, 150);Quando todos saírem: DestroyInstance(instance);Toda a memória utilizada pela dungeon seria liberada automaticamente. Considerações finaisA implementação desse recurso abriria possibilidades para sistemas PvE muito mais avançados no emulador, sem a necessidade de criar dezenas de mapas duplicados apenas para simular instâncias. Além de simplificar o desenvolvimento, manteria um consumo de recursos mais eficiente e permitiria que múltiplas parties utilizassem a mesma dungeon simultaneamente, cada uma com sua própria execução independente. Isso aproximaria o emulador do funcionamento adotado por MMORPGs modernos e facilitaria a criação de conteúdos escaláveis, como raids, campanhas, dungeons por dificuldade e eventos cooperativos.

É exatamente isso José, assim da para montar a janela e mesmo que seja resoluções diferentes com janelas em variados tamanhos o layout fica sempre bem feito, obrigado.

Exemplo de janelas com esse auto tratamento, não importa o tanto que redimensiona ela se auto monta laterais fixas e apenas os meios e fundo se adaptam. Auto se adapta

Boa tarde ! Ideia para sistema de Skin na parte de Custommonster, temos as opções : // Type = 0: NPC // Type = 1: Monster Acrescentar uma opção tipo : // Type = 2: Skin Para subir 660 1 1.00 "vegeta" "Custom\\Monster\\" "vegeta" Para subir a skin seja em sistema de skin ou mesmo como /skin xxxxx 660. Obrigado.

Boa tarde ! Há emuladores que tratam o render id para montagem de janelas, que torna-se muito prático para montar as janelas padrão no cliente, tornando a vida muito mais fácil para criação de sistemas de interface, por exemplo, a criação de uma janela sem esse tratamento: Então, notei o seguinte, Para manter o padrão das janelas do cliente é necessário criar novas partes recortadas e subir com novos ID, até ai tudo bem, porém todas vez que você faz o acerto e erro para conseguir montar e deixar no mesmo tamanho e forma das janelas do cliente, quando é feito o redimensionamento da janela do cliente, por exemplo de 1366x768 para 1440x900 ele já distorce o que foi feito, ou seja tendo que fazer no arquivo provavelmente uma configuração de montagem de janela para cada resolução "coisa que não fiz, apenas notei" Tem sistemas em emuladores que já fazem esse processo todo de forma automática, por exemplo, montar uma janela 700x300 ele fixa o topo-esquerdo/direito, baixo-esquerdo/direito e estica o topo-centro/baixo e o meio-esquerdo/direito, exemplo: Assim, facilitaria muito a criação de janelas para sistemas com o padrão de interface do Mu. Obrigado.