AOJava

Corregí el paquete PlayWave, que le falta enviar las posiciones (x, y).
Corregí el decodeData(), que estaba todo mal , y adapté el generador de paquetes para que lo genere.

Pendientes:
Arreglar el encoding de los .dat, tal vez falta especificar el encoding al abrir el archivo, o esté en utf-8.
El comerciar con NPC falla. Revisar ChangeNPCInventorySlot, ChangeInventorySlot, UpdateUserStats, CommerceInit.

Actualización 23:57:
Ya está incorporado el módulo de Areas, y parece funcionar bastante bien. Hay algunos bugs, pero ahora se puede caminar (con algunos tropiezos) por el mundo nuevamente!

Hacía mucho que no comentaba nada, así que haré un rejunte un poco extenso.

Hoy se actualizó el protocolo a 0.12.1b, el actual en el trunk del AO oficial. Con esto, nos ponemos al día, y permite usar el cliente de AO para realizar pruebas y verificar la compatibilidad... o por los menos un poquito

El servidor ahora está muy inestable, y algunos paquetes estén fallando y hace falta revisarlos. Por el momento se puede conectar, crear usuarios (aunque falla la conexión luego de crearlos), pedir estadísticas, ver el mapa, etc.

Gran pendiente: desarrollar el manejo de áreas de forma equivalente al oficial, y resolver todos los cuelgues.

Hace un par de semanas estuve viendo alternativas para el cliente. Hace un par de años hice un rendering en Java2D, usando FSEM (full-screen exclusive mode) y "active rendering". Volví sobre este diseño para ver cómo había quedado, y si había posibilidades de resucitarlo. Si bien el código estaba bastante bien, recordaba muy bien las dificultades al tratar de integrar los controles de Swing con el Active Rendering, o mejor dicho, este último y el EDT (Event Dispatcher Thread).

Buscando otras alternativas, llegué a Slick: es una API para desarrollar juegos 2D en Java usando OpenGL. La verdad que me impresionó, por lo sencilla que es, y la calidad prometedora de los juegos realizados por su comunidad. Muchos son muy entretenidos, y se pueden jugar desde la web gracias al JWS (Java Web Start). Con un par de horas nomás, ya había portado mi viejo rendering desde Java2D a Slick, y un funcionamiento impresionante comparándolo a Java2D.

Slick trae librerías para el manejo de tilesets, mapas, gestión de las imágenes, fonts, sistema de partículas, sistema de sonido 3D, sistema de física, y mucho más. Para la GUI, por lo que estuve viendo, la que más me gustó fue Thingle, que está basada en Thinlet, y a su vez está basado en XUL. Es muy intuitivo, aunque al comienzo no veía ni cómo empezar . Pero apenas vi un par de ejemplos, fue muy fácil agregar algo de GUI al cliente de AO.

Por el momento, el nuevo cliente solo realiza rendering y poco más. No tiene nada de red.

Volviendo al tema servidor, necesita urgente un refactoring total, y reescribir gran parte. Hay cosas que son un asco, y que ni siquiera me gustaría reconocer que alguna vez fueron escritas por mi . Es una tarea pendiente desde que comencé con él, porque inicialmente traté de mantener cierta similitud con el fuente y rutinas del AO, facilitándo mucho el port. Sin embargo, esto llevó a una implementación lejos de un buen diseño OO, y ahora se hace más que evidente la necesidad de replantearlo. Con el conocimiento y experiencia adquirida, ahora me encuentro en una mejor posición para llevarlo a cabo.

La elección de usar NIO allá en sus comienzos, ha sido un gran acierto, pero el diseño no resultó tan limpio como quisiera. Me gustaría migrar todo el manejo de red al framework Apache MINA. Por lo que vi, no sería complicado, y resultaría en un diseño claro, intuitivo, y extensible, con muchos extras: compresión de datos, encriptación (SSL/TLS), logging y gestión por JMX, etc.

Hoy agradecí haber usado el generador de paquetes del servidor y cliente con metaprogramación. Cuando porté AOJava al protocolo binario, AlejoLP me dió un script php y unos archivos de definición, que él había usado para generar los paquetes del protocolo para Python. Yo lo había adaptado para generar paquetes para Java, tratando de mantener actualizados los archivos de definición de tanto en tanto. Hoy encontré algunas diferencias con respecto al protocolo actual, el 0.12.1b, así que una vez detectados los cambios y corregidos los archivos con la descripción, regenerarlos fue unos segundos. Me puso muy contento eso

Hace un tiempo que recolecto info técnica de AO cuando encuentro algo sobre formatos de archivos, o especificaciones y explicaciones sobre algoritmos usados, y cosas así. Sinceramente es muy poco lo que hay o lo que se encuentra, y está todo muy desperdigado. Intentaré juntar lo que pueda, para subirlo en algún momento a una wiki o algo similar, para consolidarlo, y que quede disponible como biblioteca técnica siempre a mano.

Bueno, esto es todo por ahora. Cualquier cosa, el último código fuente del servidor está en el CVS. Si alguien se anima a probar algo, no dejen de comentarme cómo les fue. Probablemente migre el repositorio a Subversion en alguna oportunidad, pero ya habrá tiempo para eso.

Hasta la próxima.

Se encuentra funcionando el protocolo binario de AO 0.12 en AOJava :relol: . La primera prueba ha sido usando el cliente multiplataforma AONX con gran éxito, corriendo cliente y servidor en GNU/Linux !!
Seguramente habrá mucho para corregir y mejorar, pero es un avance importantísimo. Con esto se cumple uno de mis objetivos propuestos hace un par de meses.
Les dejo una imagen del momento:

Con esto inicia una nueva etapa del proyecto AOJava. Esperen noticias en el futuro.
Saludos,
Gorlok

Subí la última versión 0.8.5-ALPHA del servidor AOJava a SF.net. Probablemente será la última versión 100% compatible con el viejo protocolo ASCII. La próxima versión usará el nuevo protocolo binario (ya en desarrollo en el CVS) que es compatible con AO 0.12+

Requerimientos de esta versión:
* Java 5 o 6 (para correr el servidor solo el JRE, si desean compilar desde los fuentes necesitan el JDK completo)
* Ant 1.6.5 o posterior (solo si van a compilar)
* Cliente de Argentum Online 0.9.9z (no incluído)

Por favor notar que las versiones pasadas (hasta 0.6.5) requerían java 1.4.2. Ahora es necesario java 5.

Hasta pronto,
Gorlok

Ya tengo implementado y funcionando el nuevo algoritmo de PF, hecho con una conocida implementación de A* en java. Estoy muy contento, porque realmente salió bastante rápido y casi sin problemas.
Lo probé con los Leviatanes y parece funcionar bien.
En el futuro habrá que optimizarlo, pero vale como primera implementación real de PF.
Tarea cumplida. Una cosa menos