Diogo

Caralho vei.

No XTibia, a cocotinha cata VOCÊ!

O gordinho tá afim da magricela. FATO!

Nem Einstein conseguiria enfiar uma semana em um dia, teoria da relatividade é fichinha perto do que você faz.

Como assim, se fosse outro avatar você daria?

Eu acho uma boa, mas para tutoriais deveria haver uma tolerância maior, tipo uns 3 meses ou mais, ou ainda nem serem fechados. Tutoriais bons são úteis por muito tempo, e dúvidas podem surgir sempre.

Conheço menos da metade da equipe, mas essa pequena parcela considero muito boa e bem estruturada. Obviamente de tempos em tempos surge um membro inútil ou péssimo, que passa pelo processo de seleção por oportunismo e sorte, mas não podemos basear o conceito em cima desses errantes. OFF: E a pior coisa que tem na vida é trabalhar de manhã; o SOL foi feito para nascer antes da gente acordar, não vice-versa. --- De um VaL morto de sono.

Que sem graça pra eles, catar level 100 e ter um monte de hotkeys prontas pra se salvar... Lord'Paulistinha só morreu level 400 e poucos de burrice mesmo. Qual a meta deles depois de catarem level? Catar mais level? O que fazem pra se divertir? Nem Deus sabe...

Oi colega, Seu sistema está bem feito, mas pensa comigo: Sistema de login serve pra que? Fazer login, né!? Esse seu script não efetua login em lugar algum... Apenas exibe uma mensagem se dois dados diferentes digitados correpondem a alguma de duas combinações diferentes. Então talvez devesse mudar o nome para "sistema de checagem" ou "validação de campos usando javascript".

Onde o Personagem está: Numa boca de fumo, e me fala o que ele usou que esse é dos bons. Personagem do Tibia: Valzinho

1º - Qualquer um pode traduzir os itens, isso não seria cópia já que não tem nenhuma lei universal que diga que só você pode ter essa idéia ou que só você pode trabalhá-la. 2º - Remere's Map Editor é um projeto sob a GNU General Public License (GPL). Portanto, copiar o que você fez e distribuir NÃO É ILEGAL, desde que sejam mantidos os créditos e a licença GPL. A propósito, se qualquer infeliz te pedir as sources, você é obrigado a dá-las. 3º - Parabéns pelo trabalho =]

Como alguns sabem, estou desenvolvendo um website (OTW), que terá algumas features novas (ao menos no universo de websites de OTServ). Entre eles está um sistema de cache de dados, que será útil para evitar desperdício de processamento pelo PHP, processamento esse que poderia estar sendo utilizado somente no OTServ (se ambos hospedados na mesma máquina). Além disso esse sistema também faria o site ser mais rápido, já que evitaria ou diminuiria buscas ao disco rígido, que é o principal fator de lentidão dos sites de OTServ. A dúvida é: você acha que vale a pena sacrificar memória RAM para economizar processamento do servidor? Se sua resposta for não, peço para justificar o motivo. Se quiser expor sua opinião, qualquer que seja, o tópico lhe considera muito bem vindo.

Really very very good! Continue assim \o/

Apache x PHP Antes de entrar na questão linguagem de script ou não, deixa eu explicar a relação Apache x PHP. O Apache é meramente um servidor web (normalmente HTTP). O PHP é uma linguagem de programação. O que o faz rodar é o interpretador do PHP, não o Apache. O que o Apache faz é usar o PHP como um módulo (tanto que carrega uma dll [no caso do Windows] do PHP para reconhecê-lo) enquanto age como o servidor web propriamente dito. Apache roda sem PHP, assim como PHP roda sem Apache. Para o PHP enviar informações para um navegador por via cliente/servidor ele NÃO PRECISA OBRIGATORIAMENTE de um servidor web. Suas funções de socket permitem que ele faça isso, então respondendo ao seu "desafio", é possível sim utilizar PHP sem um servidor web para que ele aja como o próprio. Entretanto, o PHP não possui suporte a (multi) threads, o que o torna inviável para construir aplicações que ajam como servidor, motivo pelo qual usamos o Apache ou Microsoft IIS (outro servidor web normalmente HTTP) ou qualquer outro servidor que alguém tenha criado uma extensão para que os dados gerados pelo PHP e enviados para a saída padrão vão para o navegador do cliente. Se você interpretar qualquer código PHP direto do interpretador, a menos que ele use da API do Apache ou IIS, ele mostra a saída sim. E nisso que eu disse eu aposto dinheiro como está certo; de PHP eu entendo, colega. Script, o que é? Fonte: http://www.baixaki.com.br/info/1185-o-que-e-script-.htm Ou seja: todo e qualquer código desenvolvido em toda e qualquer linguagem de programação é um script. Linguagens de script, o que são? Mas se o que você disse acima é verdade, então o que diferencia uma linguagem de script de uma linguagem de programação? Simples: Linguagem de script é toda a linguagem na qual não há interação direta entre o usuário e os programas por ela criados ou que necessitam de um ambiente/programa externo (que não seja compilador/interpretador/linkeditor da própria linguagem) para rodar. Pesquisei um pouco na internet antes de desenvolver essa definição, e creio que ela seja a melhor possível. Mas veja bem, não há diferença entre linguagem de programação e linguagem de script. Toda linguagem de script é uma linguagem de programação, mas linguagens de script são um subconjunto do conjunto linguagens de programação, aquelas que batem com a definição acima. Ou seja, há a divisão linguagem de script X não-linguagem de script, não a divisão linguagem de script X linguagem de programação. Sim, eu disse antes que PHP não era uma linguagem de script, mas agora queimei minha língua. Em ambiente windows não há nenhuma extensão que permita o PHP se conformar como uma não-linguagem de script, já em alguns outros ambientes tais extensões existem. Erros do tópico Definição incompleta, nela o PHP não está incluso. Sim! Errado. Exemplo: Python. E é só. Peço desculpas por em um primeiro momento ter sido um tanto arrogante. E não estava sendo irônico (como pareceu quando li) quando disse que tinha sido uma boa iniciativa seu tópico. Gostei mesmo, só encontrei alguns errinhos. =P

Broken links colega. Só porque fiquei curioso ='[

Para esclarecer, o termpo "scripter" surgiu da burrice do brasileiro que quando viu alguém disponibilizar um script em LUA que faz uma merda qualquer no OTServ, usou o "er" e inventou a palavra "scripter". Sim, isso só existe no OTServ, e no brasileiro. Ou seja, scripters são aqueles que utilizam a API disponibilizada pelo OTServ para programar em LUA. Programadores são os scripters mais qualquer um que saiba programar em alguma Linguagem de Programação. Um programa é um conjunto de instruções não ambíguas que dizem ao computador o que fazer, portanto qualquer linguagem que faça isso, seja usando um interpretador ou compilador, é uma linguagem de programação. Isso é definição em Tecnologia/Ciência da Computação, IMUTÁVEL e INDISCUTÍVEL. E PHP não é linguagem de script, é uma linguagem de programação; muito robusta e poderosa diga-se de passagem. Tirando o que já esclareci aqui que talvez vá contra o que o Arkilus disse (estou sem paciência pra reler), concordo incondicionalmente com todas as palavras dele. Mas boa tentativa de tópico, de qualquer forma =]

Qual linguagem? Lua? Que tipos de script? Fazer NPC? Ações?

Mais por que as pessoas não criam otservs sérios? Seria a falta de mão-de-obra? Medo de entrar em um negocio que aparentemente não dá lucros? Falta de seriedade? Dinheiro. Me financie e eu te dou o OTServ mais famoso, 100% garantido. Me dê seis meses me financiando e te dou o OTServ mais famoso e com os melhores sistemas funcionando 100%. Me dê mais um ano e garanto que terei no mínimo dois "mundos", com no mínimo 200 jogadores cada, rodando perfeitamente e um negócio rentável. Ou seja: O problema é não ter dinheiro para investir em um negócio que demora tempo considerável para dar um retorno com o qual você possa parar e dizer: "Eu vivo de OTServ, eu sou foda." Administrar um OTServ como atividade secundária não só não vale a pena pelo cansaço causado, como também é inviável por falta de tempo adequado para se dedicar. ... Se você fosse um programador você ingressaria em uma equipe de otserv somente por diversão? Apenas iniciantes ou grandes entusiastas fazem isso, quem sabe normalmente quer que seu trabalho seja sério e tenha uma verdadeira utilidade, não brincar de criar OTServ.

LoL, isso não é uma matéria, é só sua opinião. by Wikipedia.

Dois bugs detectedos: http://blogs.xtibia.com/otw/ Se eu acesso por esse endereço: 1. O sistema não me reconhece como logado no XTibia. 2. Dá erro 404 ao clicar no link "Portal".

blogs.xtibia.com/otw Que biito *-* Muito bom voltarem as atenções pros blogs, é um serviço ótimo, pena quase ninguém utilizar.

Realmente, substituir TOTALMENTE é algo bem difícil, talvez num futuro distante. Agora sobre não ser viável entrar em um site toda vez que quiser usar um programa, veja a própria microsoft que já está criando uma versão "online" do office (ou algo do tipo) para bater de frente com a concorrente Google (com o Google Docs, que eu uso e acho MARA). Quando mais dados por segundo formos capaz de transferir, mais vamos deixar o desktop para trás. O sistema operacional do seu computador vai ser enxuto o suficiente para que você apenas se conecte à internet, ele será como um navegador. Ok, pode ser um pouco forçado pensar nisso agora, mas veja só: quando, há poucos anos atrás, você pensava que existiria um lugar para você fazer upload de vídeos e compartilhar com todos? Aos poucos a internet vem ocupando o espaço de coisas tradicionais como o bom e velho álbum de fotos (qualquer um mostra as fotos diretamente na máquina digital ou passa para amigos pela internet). Quem hoje em dia baixa e-mails para ler quando se é possível ter uma ferramenta extremamente melhor que o Outlook em um ambiente online (GMail)? Daqui dez anos, quando celular for coisa do passado e os aparelhos 3G já estiverem sendo ultrapassados, você vai querer poder ver seus e-mails tanto no seu 4/5G na escola, quanto em casa. Você vai querer poder ver as fotos que estariam no seu PC em casa também no seu 5G, sem precisar copiar seus arquivos. É óbvio que eles estariam na rede. No máximo você teria a opção de realizar backup para visualização offline, como já existe essa opção no GMail (em conjunto com Google Labs) MSN Messenger vai desaparecer por causa do seu peso excessivo. Aplicativos web como Meebo (ou algo desenvolvido pela própria Microsoft) vão substitui-lo, e ele será muito melhor. Visualizar a mesma situação com jogos pode ser complicado com a tecnologia que temos hoje, mas algo do tipo virá, quer a gente queira, quer não. Ao menos é assim que penso ---- Edit: Como um upgrade para meu ponto de vista: http://www.eyeos.info/ -- "Sistema operacional" por navegador Mais sobre o conceito: http://www.eyeos.org/ http://www.conexaovip.com/blog/tecnologia/...-dados-na-nuvem

Posto aqui um artigo criado por mim para um conhecido que estava interessado no assunto. --- Browse Games - Uma realidade? Com o uso cada vez maior da internet e o surgimento da web 2.0, não precisa-se ser muito esperto para prever um futuro onde todas as aplicações rodarão em grandes servidores e ao usuário comum caberá apenas se conectar a um website quando quiser editar uma foto, criar uma planilha ou usar um editor de textos. Há alguns grandes empecilhos óbvios a essa tendência: limite da velocidade de conexão e... jogos eletrônicos. Os grandes jogos de hoje em dia são tão avançados, possuem tantas leis da física embutidos e gráficos tão realistas, que os navegadores web atuais simplesmente não conseguiriam suportar. Eles não foram feitos para isso. Porém, esses mesmos navegadores web, apesar de não conseguirem rodar aplicações tão robustas sem comprometer seriamente o desempenho da aplicação se comparada a uma escrita em C, por exemplo, estão também cada vez mais avançados. Renderizadores mais rápidos, quer sejam de javascript, quer sejam de css, permitem que verdadeiras "maravilhas" sejam feitas com toolkits como Dojo, cuja seção de exemplos do website oficial é incrível. Entretanto, há ainda outro grande empecilho, nesse caso para jogos online, que claramente seriam o verdadeiro objetivo de desenvolver um jogo num browse: o protocolo HTTP. Jogos online como os conhecemos utilizam conexões socket que permanecem ativas enquanto o servidor e cliente se comunicam. Mas o protocolo HTTP não permite isso. Ou melhor, permite em meio termo: Um servidor pode criar uma "conexão eterna" com o cliente simplesmente se recusando a encerrá-la e utilizá-la como uma via única de comunicação. Um exemplo de como isso poderia ser utilizado: http://www.ueboo.com/files/741852/index.php_369258.php Obs.: A diretiva output_buffering do php.ini precisa estar definida para o valor "0". Obs.2: Só roda em Internet Explorer (no caso utilizei o 7). O cliente, entretanto, não tem possibilidades de fazer o mesmo apenas com javacript ou css. Há, porém, no ActionScript 3.0, os sockets xml e os sockets binários. Mas nesse caso caberia ao desenvolvedor criar uma aplicação server/client padrão, utilizando a linguagem que quiser como servidor. Um exemplo utilizando Java e socket XML pode ser encontrado aqui: http://help.adobe.com/pt_BR/ActionScript/3...90204-7cfb.html Mais informações podem ser encontradas aqui: http://help.adobe.com/pt_BR/AS3LCR/Flash_1...net/Socket.html Mas não é esse o universo (que conta ainda com Java applets) o qual contemplarei nesse artigo, por não haver nenhuma inovação sobre o que é feito normalmente. O que fazer quando queremos tratar de um cliente que utiliza o protocolo HTTP, que a única conexão possível com o servidor é através do próprio navegador e não há como o cliente criar uma conexão permanente com o servidor que permaneça ativa? Bom, consigo ver duas maneiras distintas de realizar isso: 1 - Servidor totalmente multi-thread (Java/C++) Utilizando algo semelhante ao exemplo dado em PHP de conexão servidor/cliente sempre ativa, o servidor nesse aspecto agiria como qualquer servidor de jogo, mandando dados atualizados constantemente. O cliente, entretanto, utilizaria AJAX (ou xmlHttpRequest, para ser mais exato) para mandar informações para o servidor. A validação de identidade seria feita por session + ip e, além disso, o servidor poderia mandar uma nova chave para o cliente a cada N segundos/minutos, que deveria ser utilizada em cada requisição do cliente com o servidor. O servidor passaria apenas dados, que o cliente transformaria em informação; ainda utilizando o exemplo dado em PHP, isso seria feito em algo como: 12:3:4:5;23:Lala; Quando o servidor mandasse esses dados, o cliente decodificaria: 12 - Movimentação 3 - ID do personagem para ser movimentado 4 - Posição X 5 - Posição Y ; - Fim do comando 23 - Mensagem do servidor Lala - A mensagem a ser exibida Logo após usar os dados para mostrar o que deve, o cliente os exclui para que não haja sobrecarga de informações no código fonte .HTML. 2 - Servidor não multi-thread (ambiente web) Esse seria um ambiente web típico: um servidor apache usando scripts PHP ou coisa semelhante. Nesse caso o PHP precisaria salvar dados de posicionamento e afins em um banco de dados, com o tempo de adição daqueles dados. Uma session seria responsável por determinar a última atualização dos dados do determinado cliente e, a cada atualização, o servidor mandaria todos os dados e/ou informações atualizados para o cliente, priorizando dados (no estilo do proposto para servidores multi-thread) para economizar tráfego e tempo de resposta. No caso, o cliente utilizaria xmlHttpRequest para pedir atualizações a cada X segundos e enviaria dados também por xmlHttpRequest. A grande desvantagem desse método é o excesso de requisições HTTP enviadas e processamento. Entretanto, a grande vantagem é poder utilizar um simples webhosting como servidor para o jogo. Vale lembrar que mesmo servidores multi-threads podem utilizar método semelhante (chamadas do cliente pedindo atualização) se acharem que devem por algum motivo (incompatiblidade de navegador e etc), ainda que não seja aconselhável. Como acréscimo, vale dizer que plugins como o Greasemonkey para o navegador Firefox poderiam permitir o desenvolvimento de um cliente muito melhor. A conclusão é: A menos que utilizemos ActionScript, a realidade dos jogos online utilizando o navegador como cliente é precária e exige adaptação por parte do desenvolvedor. Vale a pena? Talvez. Pode ser que esse seja o momento de surgirem pioneiros nos browse games (de verdade, e não meras aplicações usando uma linguagem de script e banco de dados), mas também pode ser que seja muito cedo. Quem sabe o que o futuro próximo reserva? Meu conselho? Tente; e divirta-se tentando. Diogo Dias Barreiros --- Gostaria de opiniões e afins para discutirmos esse assunto que pode vir a se tornar uma realidade num futuro bem próximo.

Ripper TOTAL e INEGÁVEL. Não mudou nem as palavras-chave dos goto. A cara de pau pra dizer que foi ele quem fez que é incrível.

Orientação a Objetos é uma metodologia (ou um paradigma) alheio à linguagem de programação (não totalmente, a linguagem precisa dar suporte a essa metodologia...) Quando entrarmos na parte da programação (e não apenas conceito da OO), entretanto, usarei Java para me auxiliar a ensinar. Então sim, quem fizer essas aulas aprenderá a programar o básico do básico em Java (já que Java é totalmente orientado a objetos).