Los programadores estarian dispuestos a dar una mano al Ao a cambio de nada?

[Luke]

Los cheats son inyectores, no clientes editados.

[Manu.-]

Los cheats son inyectores, no clientes editados.

Ah oka, me quede en la era de los clientes editados jaja

[niKen]

afloja con la soberbia pendejin, cada vez q te leo certifico lo pelotudo q sos

Y vos sos un boludo

Buena capo, seguro sos alto virgo q esta las 24hrs frente a la pc. No me respondiste porque no funcionaria capo.

Atiendo boludos, no te das cuenta q atiendo boludos? Desde que abrió el foro, tengo q trabajar horas extra para dar abasto con el servicio.

[alejolp]

Una traducción literal del programa en otro lenguaje no corrige ningún problema.

Hay una página de Wikipedia que habla exactamente del tema, deberían todos leerla:

https://en.wikipedia.org/wiki/Software_modernization

El problema del Argentum, y ya me estoy pudriendo de escribirlo en cuanto thread se cruza el tema, es que esta PENSADO para funcionar de una forma X. Esa forma X implica que todo funciona en las limitaciones que tiene vb6.

Ahora, TRADUCIR el código de VB6 a C++/Java corrige eso? NO.
Una traducción literal del código, en otro lenguaje va a tener LAS MISMAS limitaciones que hoy ya tiene.

Que se necesita para corregir eso?Sentar el culo en la silla y re-hacer todo el juego de 0 ya pensandolo para que funcione de otra forma(en multithreading, ordenando el código de la manera apropiada, etc).

Eso intentaron hacer en AOXP hace unos años, en el 2009. Todo el staff de programación de AO, tiraron todo al tacho y quisieron rediseñar el juego. Quisieron innovar haciendo un revolucionario sistema de threading, que era horrible: querían usar System.identityHashCode sobre cada objeto del mundo para sincronizar threads. EL HORROR. Si mirás la lista de nombres de personas vas a ver que son todos grosos. ONCE PERSONAS trabajaron en AOXP, acá está la lista, hacían reuniones, se juntaban un fin de semana en las oficinas de la empresa a codear el server.

¿En qué quedó eso? En nada. Pecaron de sobre diseñar el juego, quisieron hacer un EVE Online o WoW en un fin de semana. Hace un par de años hablando con uno de los chicos que más laburó en el server de VB6 me dice por privado "ya me había desencantando con aoxp..".

PROGRAMAR TIENE QUE SER FÁCIL. El resultado final debe ser que cada vez es más fácil, no más difíil. No se trata de una cuestión de egos de ver quien es más groso, quien puede entender el código más difícil. Trabajé lo suficiente como programador como para entender esto.

Traducir el codigo a otro lenguaje corrige dos problemas muy importantes: la falta de herramientas, y la dificultad para mejorar el código. No existen las herramientas mágicas que te resuelvan todos tus problemas, hay que ir mejorandolos de a poco con los recursos limitados que tenemos. Tirar todo al tacho y empezar de nuevo significa tirar todo ese esfuerzo que mucha gente le dedicó al código. Hoy el servidor de Dakara está disponible para que todos los problemas que tiene puedan ser arreglados más facilmente.

Tenemos DOS herramientas de CI que compilan en codigo en tres compiladores diferentes: CLang, GCC, y MSVC++, en Linux, Windows 32 y Windows 64. Estoy usando Coverity para detectar errores frecuentes en el código de forma automática. Coverity, al igual que Viva64, es una de las grandes maravillas modernas de la programación.

La gran ventaja que tiene Dakara sobre las demás alternativas es que hoy me puedo enfocar en agregarle cosas nuevas al juego, y no perder el tiempo pensando cómo hacer lo que ya está hecho solo porque estoy usando demasiados ifs.

Justificá tu respuesta o no mandés fruta.
Boludeces como esa confunden a la gente que no sabe y se agarra de algo que "leyó por ahí", como incluso aparenta ser tu caso.

Una traducción literal a nivel funcional no cambia absolutamente nada.

Esa es tu opinión. No tenés ni idea de lo que estás hablando, el que está mandando fruta acá sos vos. Las migraciones automáticas de código son poderosas herramientas para ahorrar tiempo y esfuerzo, mirá acá por ejemplo me llevo 10 segundos buscarlo en Google. No tenés evidencia de lo contrario.

Si en vez de elegir C++ hubiese elegido Java para generar la traducción automática, muchos servers hoy estarían usando mi código. El Ofi estaría usando mi nuevo código.

Distinto es armar un proyecto de 0 en otro lenguaje, ya pensando como estructurarlo para que tenga mejor escalabilidad, etc. Como sería AOC, el proyecto en .net de culd o tantos otros proyectos que lo han intentado pero nunca salieron 100% andando.

Mi proyecto es el único que salió 100% andando, y me llevó un mes de trabajo. Si taanta idea tenés y tan groso sos mostrame cómo se hace. A mi me llevó 13 años llegar hasta acá, hace 13 años que estoy codeando para el AO.

- - - Updated - - -

No soy muy amante del refactoring de código. Soy de la escuela de que "si anda no se toca más". Por ende... supondrás que tiro mugre por doquier.

Si no te gusta el refactoring y "si anda no se toca" entonces también supongo que tu opinión empezar de cero. Es una muy mala idea.

[Hiux]

Justificá tu respuesta o no mandés fruta.
Boludeces como esa confunden a la gente que no sabe y se agarra de algo que "leyó por ahí", como incluso aparenta ser tu caso.

Una traducción literal a nivel funcional no cambia absolutamente nada.

Distinto es armar un proyecto de 0 en otro lenguaje, ya pensando como estructurarlo para que tenga mejor escalabilidad, etc. Como sería AOC, el proyecto en .net de culd o tantos otros proyectos que lo han intentado pero nunca salieron 100% andando.

Pero le estás diciendo a HunT que no mande fruta y el frutero acá sos vos :/ Java > C ++ para migraciones, hacerlo manual sería un suicidio.

[alejolp]

Pero le estás diciendo a HunT que no mande fruta y el frutero acá sos vos :/ Java > C ++ para migraciones, hacerlo manual sería un suicidio.

Hay que poner las cosas en la perspectiva correcta: hoy nadie puede programar por su cuenta como un cowboy del oeste. Todos los proyectos de software son en grupo, y hacen falta herramientas de trabajo adecuadas: control de versiones, IDEs, compiladores, herramientas automáticas para hacer refactoring del codigo, Integracion Continua, análisis estático de código, testing de unidad, cobertura de código en los tests, poder compilar el codigo y ejecutarlo en diferentes ambientes para garantizar la compatibilidad de versiones; si es Java ejecutar los tests en diferentes versiones de la JDK, seguimiento de proyectos, manejo de bugs, coordinacion de testing, documentacion.

Acá en el thread alguien dijo que no le gusta el refactoring: mal gusto. Si te querés dedicar profesionalmente a la programación, te tenés que hacer amigo del refactoring o estás frito. Para eso existen herramientas automáticas, en Java hay de a docenas.

Pocas herramientas hoy en dia ofrecen todas estas ventajas. Java es una de ellas. .Net es tambien otra. C++ es un poco más áspero pero ofrece cosas que Java ni Net te dan. No se trata solamente del lenguaje, sino de todo el ecosistema de cosas que uno hace desde que alguien te dice "che necesito que el programa haga unicornios" hasta que tengas el unicornio en tus manos.

Además, hay que laburar con más gente. Hay que ponerse de acuerdo en qué trabajar, de que manera, que dos personas no hagan lo mismo, y que ninguno rompa o vuelva hacia atrás el trabajo de otro. Además hace falta encontrar gente que esté dispuesta a trabajar, que sea copada, que tire para adelante y que su ego y su orgullo no se pongan en el camino del futuro del proyecto.

El lenguaje de programación no es una elección técnica, es un problema humano. El lenguaje elegido es simplemente lo que la mayoria de la gente que puedas encontrar sepa usar. Empesas como Google y Microsoft usan C++ porque pueden darse el lujo de conseguir empleados que sepan programar C++.

Todos tenemos gustos. A mi no me gusta Java, y mi tiempo libre lo prefiero dedicar a C++. ¿Por qué? No se, que se yo, es lo que siento. Sin embargo Java está re bueno, y Eclipse es genial. Todos deberían usarlo. Como herramienta automática para encontrar bugs en el código Java existe FindBugs, acá un compañero de la oficina me lo recomendó, pero nunca lo usé. Usamos Coverity, que es parecido para C++, es muy genial. En Dakara estoy usando la versión gratuita de Coverity, me ayudó a encontrar un monton de bugs.

[Luke]

Hay una página de Wikipedia que habla exactamente del tema, deberían todos leerla:

https://en.wikipedia.org/wiki/Software_modernization



Eso intentaron hacer en AOXP hace unos años, en el 2009. Todo el staff de programación de AO, tiraron todo al tacho y quisieron rediseñar el juego. Quisieron innovar haciendo un revolucionario sistema de threading, que era horrible: querían usar System.identityHashCode sobre cada objeto del mundo para sincronizar threads. EL HORROR. Si mirás la lista de nombres de personas vas a ver que son todos grosos. ONCE PERSONAS trabajaron en AOXP, acá está la lista, hacían reuniones, se juntaban un fin de semana en las oficinas de la empresa a codear el server.

¿En qué quedó eso? En nada. Pecaron de sobre diseñar el juego, quisieron hacer un EVE Online o WoW en un fin de semana. Hace un par de años hablando con uno de los chicos que más laburó en el server de VB6 me dice por privado "ya me había desencantando con aoxp..".

PROGRAMAR TIENE QUE SER FÁCIL. El resultado final debe ser que cada vez es más fácil, no más difíil. No se trata de una cuestión de egos de ver quien es más groso, quien puede entender el código más difícil. Trabajé lo suficiente como programador como para entender esto.

Traducir el codigo a otro lenguaje corrige dos problemas muy importantes: la falta de herramientas, y la dificultad para mejorar el código. No existen las herramientas mágicas que te resuelvan todos tus problemas, hay que ir mejorandolos de a poco con los recursos limitados que tenemos. Tirar todo al tacho y empezar de nuevo significa tirar todo ese esfuerzo que mucha gente le dedicó al código. Hoy el servidor de Dakara está disponible para que todos los problemas que tiene puedan ser arreglados más facilmente.

Tenemos DOS herramientas de CI que compilan en codigo en tres compiladores diferentes: CLang, GCC, y MSVC++, en Linux, Windows 32 y Windows 64. Estoy usando Coverity para detectar errores frecuentes en el código de forma automática. Coverity, al igual que Viva64, es una de las grandes maravillas modernas de la programación.

La gran ventaja que tiene Dakara sobre las demás alternativas es que hoy me puedo enfocar en agregarle cosas nuevas al juego, y no perder el tiempo pensando cómo hacer lo que ya está hecho solo porque estoy usando demasiados ifs.



Esa es tu opinión. No tenés ni idea de lo que estás hablando, el que está mandando fruta acá sos vos. Las migraciones automáticas de código son poderosas herramientas para ahorrar tiempo y esfuerzo, mirá acá por ejemplo me llevo 10 segundos buscarlo en Google. No tenés evidencia de lo contrario.

Si en vez de elegir C++ hubiese elegido Java para generar la traducción automática, muchos servers hoy estarían usando mi código. El Ofi estaría usando mi nuevo código.



Mi proyecto es el único que salió 100% andando, y me llevó un mes de trabajo. Si taanta idea tenés y tan groso sos mostrame cómo se hace. A mi me llevó 13 años llegar hasta acá, hace 13 años que estoy codeando para el AO.

- - - Updated - - -



Si no te gusta el refactoring y "si anda no se toca" entonces también supongo que tu opinión empezar de cero. Es una muy mala idea.

Dejame ver si entiendo. Por que hace casi 7 años un grupo haya tomado malas decisiones en la planificación de la arquitectura(que en mi opinion es el 50% de un proyecto) de AOXP de golpe hacer replataforming de software de 0 es una mala idea?
Los links que me pasás están orientados a aplicaciones bussiness que tienen simplemente limitaciones técnicas, dicho en los propios ejemplos que cita el artículo: necesidad de actualizar aplicaciones legacy.
Ahora, aplica alguna de todos esos concepto al PROBLEMA DE CONCEPCIÓN del Argentum? No, o al menos a mi entender no.

Desde que laburo en desarrollo lo que más he hecho justamente(y con mucho gusto, xq me encanta) es agarrar software obsoleto y re-hacerlo en una mejor tecnología.

Me parece perfecto que pretendas o quieras nublar el hecho de que los beneficios que te aportan hoy tener Dakara en c++(del cual tengo el código por git desde que lo subiste) no resuelven más problemas que los que le cité a hunt(creo) que son la portabilidad para hostear la aplicación, y si querés y te lo doy como válido, facilitar el entorno de desarrollo.

Lo mío no fue en ningún momento mandar fruta. Si así fuese, lo mismo podría decir de tu aparente nulo conocimiento de software replataforming, pero se que no es una cuestión de conocimiento sino de subjetividad: preferís la traducción y hacer pequeños refactors. Distinto es que yo discuta con vos aspectos técnicos y otra distinta es el caso del otro zapato que dice "no se nada de programación" y acto seguido empieza a escupir verdades.

En mi opinión(y mi subjetividad tmb seguramente) el refactor de pequeños sectores de código, son soluciones de síntoma, sobretodo en un código como el del Argentum.

No necesitás 13 años programando en el AO para forjarte una postura de cual es el problema del juegoy cuales serían las potenciales soluciones, pero me da la impresión de que ver lo que pasó con viejos proyectos de hace casi 10 años te dejaron una horrenda idea de "si se hace replataforming va a salir todo mal".

[culd]

A dakara le sacas 2 timers asquerosos del servidor de vb6 y queda alto servidor. Le sacas el timer de buffer de paquetes, y repleanteas el envio de paquete por accion realizada y tenes mejor simultaneidad. Le sacas el timer de proceso de PJs y NPC, le pones un thread de control individual y tenes un servidor que te aguanta facil 5000 usuarios simultaneos. Si tocar mas codigo.

Luke, junta 100 tipos en ulla y que miren el ping que tienen, despues lleva a uno solo a cualquier mapa vacio y que vuelva a mirar el ping y contame la diferencia. Si no entendes el problema te hago un diagrama explicando el cueyo de botella que tiene el servidor de vb6

[Luke]

A dakara le sacas 2 timers asquerosos del servidor de vb6 y queda alto servidor. Le sacas el timer de buffer de paquetes, y repleanteas el envio de paquete por accion realizada y tenes mejor simultaneidad. Le sacas el timer de proceso de PJs y NPC, le pones un thread de control individual y tenes un servidor que te aguanta facil 5000 usuarios simultaneos. Si tocar mas codigo.

Luke, junta 100 tipos en ulla y que miren el ping que tienen, despues lleva a uno solo a cualquier mapa vacio y que vuelva a mirar el ping y contame la diferencia. Si no entendes el problema te hago un diagrama explicando el cueyo de botella que tiene el servidor de vb6

Creme que se los problemas de bottleneck que tiene vb6 culd, pero la mera traducción del juego no cambia eso. Ahí tenés que empezar a hacer lo que Alejo apoya, que es pasarlo de lenguaje y empezar a hacer pequeños arreglos o refactoring de problemas como los que citás, pero cambiar el lenguaje del juego magicamente no te soluciona nada, como parecen creer muchos por acá.

A fin de cuentas seguís teniendo después un código horrendo y estructurado como el culo. Vas a lograr que ande mejor? Si, seguramente lo vas a lograr(y acá es donde creo que radica nuestra diferencia de eprspectiva, yo veo el proyecto mas allá de hacerlo funcionar bien hoy). Pero para fines de desarrollo a largo plazo, el código del juego va a seguir siendo una basura por como está concebido.

Laburo le vas a tener que imprimir, sea por una vía o por otra. Una vía es mucho más rápida obviamente, la que propone Alejo, por el hecho de que no tirás todo a la mierda, pero a la alrga siemrpe vas a tener código sucio, en menor o mayor medida. La otra implica un desarrollo mucho más prolongado(tampoco soy un negado, se que los tiempos se estiran), pero el resultado a largo plazo es ampliamente superior.

[alejolp]

Dejame ver si entiendo. Por que hace casi 7 años un grupo haya tomado malas decisiones en la planificación de la arquitectura(que en mi opinion es el 50% de un proyecto) de AOXP de golpe hacer replataforming de software de 0 es una mala idea?

Dale, seguí mandando fruta. Te encanta.

Los links que me pasás están orientados a aplicaciones bussiness que tienen simplemente limitaciones técnicas, dicho en los propios ejemplos que cita el artículo: necesidad de actualizar aplicaciones legacy.

El Argentum es una aplicación legacy. Si no querés entenderlo es tu problema.

Ahora, aplica alguna de todos esos concepto al PROBLEMA DE CONCEPCIÓN del Argentum? No, o al menos a mi entender no.

Ese es un problema que vos mismo te inventaste y existe solo en tu propia imaginación. La gente sigue jugando al Argentum más que nunca, y vos como staff de Programación deberías ver que el juego, así como está, te guste o no, es divertido. Cambiar el diseño del código manteniendo las mismas condiciones del juego es una masturbación mental innecesaria. Es un problema que solamente a vos te molesta, a los jugadores no les hace ninguna diferencia si el código del juego está hecho en VB6, C++, o Pascal. El problema de CONCEPCION del Argentum del que hablás está en tu imaginación.

Desde que laburo en desarrollo lo que más he hecho justamente(y con mucho gusto, xq me encanta) es agarrar software obsoleto y re-hacerlo en una mejor tecnología.

Me parece bien, te felicito y me alegro que hayas encontrado tu camino. Me alegro que te guste programar por programar. A mi me gusta programar para tener cosas que funcionan, no me interesa andar haciendome la paja con la belleza del codigo fuente.

Me parece perfecto que pretendas o quieras nublar el hecho de que los beneficios que te aportan hoy tener Dakara en c++(del cual tengo el código por git desde que lo subiste) no resuelven más problemas que los que le cité a hunt(creo) que son la portabilidad para hostear la aplicación, y si querés y te lo doy como válido, facilitar el entorno de desarrollo.

Decidiste ignorar el hecho de que podría haberlo traducido a Java. Felicitaciones por seguir mandando fruta.

Lo mío no fue en ningún momento mandar fruta. Si así fuese, lo mismo podría decir de tu aparente nulo conocimiento de software replataforming, pero se que no es una cuestión de conocimiento sino de subjetividad: preferís la traducción y hacer pequeños refactors. Distinto es que yo discuta con vos aspectos técnicos y otra distinta es el caso del otro zapato que dice "no se nada de programación" y acto seguido empieza a escupir verdades.

Lo que decís no tiene sentido: presentás tu opinión como un hecho. No es blanco o negro, no se trata de solo dos opciones y nada más. No se trata de REFACTORING vs EMPEZAR DE CERO. Hay que elegir en cada caso lo que mejor conviene.

Argumentás que reescribir la aplicación (usando palabras elegantes como software replataforming) es mejor que hacer pequeños refactorings. La industria profesional del software está en completo desacuerdo con tu opinión. Agarrá cualquier libro de ingeniería de software y vas a leer que el refactoring es la mejor forma de resolver problemas de diseño de cualquier software.

Por supuesto que cada tanto hay que reescribir partes específicas: por ejemplo en Dakara tuve que reescribir los sockets.

En mi opinión(y mi subjetividad tmb seguramente) el refactor de pequeños sectores de código, son soluciones de síntoma, sobretodo en un código como el del Argentum.

Te estás olvidando de un problema fundamental: lo que hay, funciona. A nadie le importa que el codigo esté hecho con un diseño de arquitectura revolucionario. Lo que importa es que ande, y que sea económico agregarle nuevas features al juego.

Nadie programa al Argentum como su trabajo de dia y noche, todos tenemos una vida, y el tiempo libre que tenemos es nuestro recurso más limitado y preciado. Ahorrar tiempo es la clave del exito. Resolver problemas que a nadie le importa resolver, y que no aportan al futuro del proyecto, es una perdida de tiempo.

No necesitás 13 años programando en el AO para forjarte una postura de cual es el problema del juegoy cuales serían las potenciales soluciones, pero me da la impresión de que ver lo que pasó con viejos proyectos de hace casi 10 años te dejaron una horrenda idea de "si se hace replataforming va a salir todo mal".

Otra vez mandando fruta.

- - - Updated - - -

Creme que se los problemas de bottleneck que tiene vb6 culd, pero la mera traducción del juego no cambia eso. Ahí tenés que empezar a hacer lo que Alejo apoya, que es pasarlo de lenguaje y empezar a hacer pequeños arreglos o refactoring de problemas como los que citás, pero cambiar el lenguaje del juego magicamente no te soluciona nada, como parecen creer muchos por acá.

A fin de cuentas seguís teniendo después un código horrendo y estructurado como el culo. Vas a lograr que ande mejor? Si, seguramente lo vas a lograr(y acá es donde creo que radica nuestra diferencia de eprspectiva, yo veo el proyecto mas allá de hacerlo funcionar bien hoy). Pero para fines de desarrollo a largo plazo, el código del juego va a seguir siendo una basura por como está concebido.

Laburo le vas a tener que imprimir, sea por una vía o por otra. Una vía es mucho más rápida obviamente, la que propone Alejo, por el hecho de que no tirás todo a la mierda, pero a la alrga siemrpe vas a tener código sucio, en menor o mayor medida. La otra implica un desarrollo mucho más prolongado(tampoco soy un negado, se que los tiempos se estiran), pero el resultado a largo plazo es ampliamente superior.

Si esta discusión la hubiesemos tenido hace dos años, tus palabras hubiesen tenido sentido: la traducción no es perfecta.

La diferencia es que hoy Dakara es una realidad, la traducción ya fue hecha y funciona.

Ahora te toca a vos reescribir el juego desde cero, con un diseño de arquitectura bien hecho. Y mas te vale que esté bien hecho de entrada, no vaya a ser cosa que tengas que cambiar cosas sobre la marcha y hacer refactorings.