Visita la carpeta maps y reconstruye los que se han corrompido. Siento haber rechazado las 2 pull requests, un error de cálculo que ha sido completamente culpa mía.

Bueno, no pasa nada hombre, se vuelve a hacer. Ya tengo los cambios, resolví conflictos, y me pondré con indentNav que imagino debe ser un juguetito genial

Sigo indentando a mano, y aprendiendo de esta peculiar forma de programar. Los loops tienen salidas, es probable que las funciones sí deban llamarlos en vez de llamar a return. Creo que será mejor entender bien cómo funciona este código antes de cambiarlo. Me quedan ahora mismo 3 archivos para acabar de indentar el cliente.

Lo ideal con los mapas sería hacer unos para estas pruebas y cepillarse los de otros juegos.

A mí me tocó volver añadir de nuevo en el constructor algunas llamadas a mainloop, reconozco que no logro entender bien que hace esa función, y si no llamo a ella en algunas cosas es como si se paralizara el juego: si chatean no suena, no se leen mensajes, y cuando
das enter para subir un cambio a un mapa, o cuando das escape para cancelar la operación llega todo de golpe, lo expliqué en un commit. Ya he corregido los mapas corruptos, voy a hacer pull en breve.

¿si en lugar de llamar a esa función haces return; no ocurre nada?

Si en lugar de llamar a mainloop hago return, el juego se queda muerto, sin sonidos, nada funciona, todo se va al carajo. Return solo funciona en muchos casos, menos en el constructor, por ejemplo en adminmenu si que funciona.
creo que usaré una herramienta muy buena del propio bgt, se llama generate_profile, lo que hace es hacer un registro de las funciones que se ejecutan, y cuanto tarda en ejecutarse cada una. Si bien sirve para rendimiento se podría no solo saber si no que al
hacer un registro, pues ves que funciones se ejecutan durante un tiempo, y así ver un poco mas a detalle que ocurre.

mainloop es el loo principald el juego, es a donde queda la conección con internet y varias teclas que funcionan en todos los loops

Nunca entendí muy bien lo que era, pero ahora con esa explicación, le daré un vistaso para tratar de entenderla mejor, te lo agradesco mucho mi hermano

Pero tiene que haber una forma más eficiente que llamarla infinitamente.

Perdonad la pregunta entre los mensajes tan técnicos... Qué juego es EVM? Está en el aire? Es que me he puesto a leer los mensajes y no sé cuál es.
Gracias.

EVM es entre a vida e a morte, o entre la vida y la muerte, un amasijo de código que es clon+clon+clon

Cuando una función lleva la palabra "loop" en su nombre, significa que está destinada a ejecutarse en bucle infinito hasta que se produzca alguna condición de salida, o al menos yo lo entiendo así. Claramente, visto lo visto, no es así. Algunos loops no tienen while o for alguno, tan sólo algunos if dentro. Otros tienen uno o varios for anidados que acaban cuando el contador alcanza su límite. Hasta el mainloop, que debería ejecutarse infinitamente hasta que se pulse escape o la opción salir, parece tener salidas que nadie se espera, de ahí que algunas funciones internas lo llamen. O mucho me equivoco, o hace falta una buena reforma aquí. Ya sólo me queda indentar el client.bgt, ¡casi estamos!

Se está intentando optimizarlo para hacer una base de la cual partir para hacer juegos, pero tiene más miga de lo que parece. Está en el aire para probar cosas, pero avisaré cuando esté actualizado.

Y tanto. Quitar los mapas es imposible, el código es muy dependiente de ellos.

ni tanto, de 100 los mapas que son necesarios son, si hablamos 10 ya son muchos.

No debería ser necesario ninguno salvo el inicial y otro más donde enviarte tras aceptar las reglas. el resto debería ser personalizable y conectable desde los propios mapas. El código debería leerlos y ya está.

El unico mapa que es necesario es el apresentação.map.
mainloop es el nombre de la función, no tiene nada de infinito aí es apenas un void a donde tienen varias funciones que tienen de ser llamadas em varios loops.
Creo yo que no tiene de cambiar nada en mainloop. Cuando llama otra función por mainloop, aún que no tenga return, no va cambiar nada en la memoria porque las variables san globales.

El asunto es que hay verificaciones. Por ejemplo los mapas de los aeropuertos. Si no existen cuando los uses te dejará en áreas desconocidas.
También hay algo que no es del todo un problema, hablo de los objetos que se ponen en los mapas tales, como animales, paredes vivas, etc. Si bien aunque los mapas no estén pareciera no importar, yo prefiero no forzar nada y cuando tengo objetos en ciertos mapas no los elimino hasta que no desactivo los objetos.

Bueno verifica se los mapas existen antes de poner los objectos, asi esto está resuelto. En server/includes/item.bgt, void spawn_obj
if(!file_exists("maps/"+map+".map"))return;
Claro que esto no es la manera correcta pero... Se quieren borrar los mapas esto ayuda.

Más bien boolean que devuelva true o false pasándole el string del mapa. aunque lo ideal sería que los objetos estuvieran incluídos en los archivos de mapa.

y la máquina personage nesesita tener todos los animales del juego y ne el perro está aí.

Los mapas deberían definir objetos y comportamientos de los mismos. Como bgt no permite algo así, tal vez sería buena idea programar un módulo por mapa. Yo por mi parte ya he indentado todo el cliente, todo se compila bien y funciona... como funcionaba antes, así que acepto pull requests a partir de este código, bien indentadas y explicadas. Eso sí, durante las próximas semanas no voy a modificar nada, tengo que dedicarme a otros proyectos y descansar un poco.

El tema de incluír los objetos en los archivos de mapa si es posible, así como otras cosas, pero toca modificar todo el sistema del juego.
Un módulo por mapa, anda es mucho enredo me lo parece a mí. Vale ya mismo hago pull y merge local de los cambios

Cuidado con el merge, el indentado suele romper archivos enteros. Suerte con eso.

Dios, lo estoy intentando hacer, que dolor de cabeza.

Posteo para que @Sol-Dorado pueda.

Hola un saludo, y creo que esto también lo escribiré en aprendiendo y debatiendo sobre bgt.
Muchos quienes utilizamos o reutilizamos código para nuestros desarrollos hacemos todo muy tranquilos, porque al compilar o al simplemente abrir el script principal funciona y no tira error de compilación, pues grave error pensarlo, ya que en realidad algo está mal, o muy mal.
@el_pichon incluyó en el server la línea set_error_output("log.md"); la cual lo que hace es guardar una especie de log de errores. Como caso que me dejó atónito, el servidor me creó en pocos minutos
un archivo con un tamaño de 94 mb. También lo apliqué en un archivo de otro proyecto en el que ando trabajando, y encontré unas cosas que dan orror, así como también llego a la conclución de que o la documentación de bgt es inpresisa, y por eso haces cosas que crees que están bien, o simplemente todo lo hemos estado haciendo mal pasando por alto detalles de la documentación que no están de forma explísita.
pero luego este truquito te dice, oye compadre nó, que algo no está bien, esto me recordó a los scripts de php que pareciera que funcionan, pero luego vas al log y nó, alguna cosa está fallando.
Les animo a depurar sus scripts de esta manera, se encontrarán con errores muy curiosos.
Curiosamente el archivo client/includes/sp.bgt está lleno de errores. Es es en parte la razón del mal rendimiento, de la compilación lenta,
y aunque al compilar todo paresca ir bien, ya no estoy tan seguro de eso.
Las líneas que tienen la sentencia string_contains también tienen problema, porque aunque la documentación no lo detalle al pié de la letra, la función es de tipo int, aunque maneja strings, supongo que es así porque retorna códigos de error.
en mi caso, la línea: open_sound_device(numero_dispositivo); tira error, porque dice que ya está avierto. Chicos esto es un desastre aunque funcione.
Si logramos un server y cliente libre de errores el rendimiento en la ejecución podría ser mayor.

Varias funciones que aparecen como error en output_log son precisas y sus errores tienen sentido. Por ejemplo, cuando pones
file_delete("C:/jkaffklsjflw/UnArchivoqueNoExiste.txt");
, dará un error, porque antes de esta comprobación, debería haberse llamado a file_exists. Tiene un nombre correcto para este tipo de función, pero no lo recuerdo ahora.

he actualizado el código del servidor. Lamentablemente me he llevado por medio todos los personajes al borrar demasiado y me ha fallado el script de backup. De todos modos tampoco es que hubiera algo interesante.
jesuspavonabian.es/evm.zip por si quereis hacer el burro un rato. si teneis el ejecutable se debería actualizar solo.
Faltan mapas que no tengan que ver con ningún juego, estaría bien sustituirlos todos y hacer algo con la dependencia de mapas en el código.
¿Hay alguien intentando hacer algo? Lo digo para no ponerme yo a tocar y liarla parda con los pull requests.