Abro este ilo para organizarnos un poco.
La idea es tener un sitio del cual tirar para enterarnos de cómo hacer cosas con el código de EVM. colaborar, crear forcs, preguntar dudas de código... Es recomendable saber un poco de inglés.
cómo ayudar:
Lo primero es crear una cuenta en github.com. una vez hecha, tenemos que instalar git, asegurándonos de poder ejecutar los comandos de git y unix desde la consola de windows, marca la casilla adecuada en el instalador para ello.
Lo segundo es configurar git. ejecuta estos comandos con tus datos:
git config --global user.name "pepito pérez"
git config --global user.email "pepito@gmail.com"
Ya tenemos Git listo para la acción! De hecho, podríamos descargar repositorios públicos sin ningún problema por http.
Lo siguiente es hacer un forc del repositorio original del juego. Importante que sea el original:
https://github.com/jmdaweb/EVM
Este y solo este es el repositorio original del proyecto en el cual se reflejarán los últimos cambios y actualizaciones.
una vez tengamos el forc hecho nos aparecerá en nuestra cuenta de github un repositorio con el mismo nombre que deberemos clonar y añadirle la URL del repositorio original para mantenerlo actualizado.
git clone https://github.com/tu_usuario/EVM
cd EVM
git remote add upstream https://github.com/jmdaweb/EVM
Y ahora podemos empezar a trabajar.
Actualizando el repositorio:
si el repositorio original se actualiza tenemos que actualizar nuestro repositorio local y el que tenemos en github. Vamos a ello: Desde la carpeta local de nuestro repositorio tecleamos
git checkout master
git pull upstream master
y listo... en la mayoría de casos.
Subiendo un cambio
Imaginad que habeis hecho un cambio en algún (o en varios) archivos del juego y quereis compartirlo porque habeis arreglado un bug o solucionado una tarea pendiente de las que aparecen en el readme.
Tras irnos a la carpeta del nuestro reprositorio clonado hacemos:

1. Creamos una rama para subir nuestros cambios y que no se líen con los oficiales
git checkout -b miscambios

2. añadimos archivos.
git add .

3. Hacemos un commit y subimos.
git commit -m "Mensaje explicando los cambios."
git push origin miscambios

4. hacemos un pull request.
Desde el navegador accedemos a la url del repositorio oficial del proyecto. allí pulsamos new pull request y seguimos las instrucciones, seleccionando en un lado la rama que hemos creado nosotros que está en nuestro repositorio y en el otro la rama master del repositorio oficial.
Pero ¿para qué sirven las ramas?
Gracias a las ramas podemos hacer cambios y en cualquier momento hacer un git checkout master y volver a los archivos originales.
Pronto más si hay interés.
Por cierto, estoy trasteando con el lag, a ver si lo corrijo. He montado un servidor para ir haciendo pruebas, si consigo reducirlo intentaré hacer un Pull Request.
si quereis meterle caña teneis el cliente compilado para jugar en https://jesuspavonabian.es/evm.zip
si quereis armas de la virtual pedidlas, la idea es ausar lag para ver por dónde meterle mano, aunque ya creo tener una ligera idea de por donde empezar a romper cosas. y si quereis ayudar con código no seré yo quien os diga que no, así acabamos antes.

hola. pues el lag viene por la parte de sonidos más que nada, creo yo. porque al darle muchas órdenes al servidor estando muchos jugadores en un solo mapa como disparar con ak 48, sublaser u otra arma repetitiba, este s elaguea. entonces, pienso que va más por el tema de la transferencia de datos entre el servidor y los jugadores, devido a que tiene que transferir lo que pasa en el mapa sin parar y más cuando son sonidos casi sin pausa como los de las armas, y el qué pasa cuando el arma acierta en un mob npc. eso no pasa cuando un jugador está solo en un mapa, suele pasar cuando hay muchos.

Realmente da igual. Una de las cosas que más lag da es la recarga de armas. Cada vez que pulsais la r se envía el inventario entero al cliente. Hay que toquetear mucho el tema de la comunicación entre cliente y servidor.

posteo para que @BOFH pueda postear.

En un par de horas cgracias a Jamespotter he sacado en claro que...

• cuando disparas el juego te devuelve tu propio disparo, en lugar de gestionarlo el cliente. Esto es un pelín absurdo y genera lag individual. Hay que rehacer la gestión de envío de sonidos, es una chapuza.
• Cuando recargas armas se envía innecesariamente todo el inventario al cliente, se envía el sonido a todos los jugadores (esto es innecesario), se recarga el arma y luego el cliente envía al servidor otra vez el inventario si no he comprendido yo mal el horror de código.
• Existen muchísimos paquetes enormes que pueden y deben reducirse para agilizar y eliminar bucles. El de los mensajes de chats, por poner un ejemplo.
• hay comandos sin documentar.
• Los comandos que añadieron los programadores de EVM no tienen control de administración, hay que añadírselo.
• El constructor de mapas crashea si no se usa bien, y es muy fácil usarlo mal. Habría que documentarlo.

Eso demuestra que los programadores han intentado replicar la realidad tal y como es, sin abstraerla. Y eso, en el mundo de los juegos, necesitaría máquinas potentísimas que hoy en día no tenemos.

está bien el sonido de disparos, pero se puede obiar la recarga de armas. por que claramente no es interesante para la jugabilidad. y no otro lag si se embía todo el imbentario al juego cada que recargues. es innesesario pero no se si será util para el juego o el programa.

Hola, un saludo. Ya tengo cuenta en gitub, el repositorio clonado, he hecho pequeños cambios, pero con algunos detalles de git estaba lieado, y gracias a @BOFH y a @el_pichon ya me he aclarado. Algo similar de los disparos intentaba explicarle a @BOFH, pero la verdad en el code que tengo no me he puesto a trabajar en ello.
Es verdad, el inventario se envía completo entre ambos, servidor y cliente y de manera demaciado constante, eso genera demaciado tráfico. La cosa de los disparos va mas o menos así: disparas, el servidor resive tu disparo, lo procesa, y reenvía todos en el cliente incluyéndote, la explosión de las balas, si inpactaste y el paquete del inpacto, etc.
Respecto al constructor de mapas, lo he mejorado, voy a añadirlo para subir los cambios, ahora el que tenemos nosotros crashea con menos facilidad, aunque por cosas de tiempo no e terminado de trabajarlo, me falta un pelín para dar a la luz algo un poco mejor. Los chats, no necesitan de mucho bucle, pero si otro tipo de mensajes, es obligatorio, ya que si no se hace así, las traducciones no funcionarán.

A continuación, pego un fragmento de código para ilustrar un poco el tema.
// Imaginamos que hacemos lo siguiente en el cliente para enviar regalos a todos los conectados:
if(m.get_item_name(mres)=="gifts") // en caso de haber invocado dynamic_menu como m, y usar como variable run del menú, mres
{
string giftname=v.input(pu.get_value("Escriva el item que dará a los jugadores, tenga cuidado al escrivir:"));
string giftquantity=v.input("Inserte el número de itens, aviso, solo números:");
int quantity;
quantity=string_to_number(giftquantity);
send_reliable(1, "/gift "+giftname+" "+quantity, 1);
}

// server:
else if(parsed[0]=="/gift" && parsed.length()>1)
{
gifts=parsed[1];
string delimiter=parsed[1];
if(string_contains(delimiter, "=",1)!=-1)
{
send_reliable(players[index].peer_id, "Sintaxis inválida.", 0);
}
if(parsed.length() <3)
{
send_reliable(players[index].peer_id, "Sintaxis inválida, por favor expecifique la cantidad de " +gifts+".", 0);
return;
}
else
{
send_reliable(0, "ps notify_woosh.ogg", 0);
send_reliable(players[index].peer_id, "msgift Has dado " +parsed[2] +" "+gifts, 0);
send_reliable(0, "msgift Has resivido " +parsed[2] +" "+gifts +" "+"de regalo.", 0);
for(uint n=0; n<players.length; n++)
{
players[n].inv_add_item(gifts,string_to_number(parsed[2]));
}
}
} // fin de verificación en servidor

// verificaciones en cliente

else if(parsed[0]=="msgift")
{
string a =pegar_mensagem();
a =string_replace(a, parsed[0]+" ", "", true); // eliminamos msgift, que es el identificador de mensaje.
string m;
string[]pars =string_split(a, " ", true); troceamos el mensaje en parte ceparándolo por los espacios, para luego componerlo y añadir la traducción
for(int i=0; i<pars.length(); i++) // mediante for reccorremos el array, para ir añadiendo las partes de nuevo, ceparando por un espacio al final cada una
{
m+=pu.get_value(pars[i])+" "; // añadimos de nuevo cada parte, y a su vez estas estarán afectadas por la traducción, si es que hubiera alguna para alguna palabra. Añadimo a su vez un espacio al final a cada una para ceparar.
}
m.resize(m.length()-1); // eliminamos el espacio del final producto de la adición
add_add_item("notificaciones", m); // ponemos los mensajes en el bufer correspondiente
}

Hola chicos, saludos a todos!

Vengo por aquí para comentar y no dejar que el hilo muera y al mismo tiempo en reconocimiento al trabajo de todos ustedes.

Ya me he descargado el cliente que BOFH dejó más arriba, y si bien no sé programar ni madres, si puedo ayudar con el testeo.

Así que por ahí nos vemos.

Vamos hilo, sube!

suvee xd, porcierto chicos, yo ise modificasiones no son tan grandes pero bueno, mejoré para que al recargar las balas no se emvíe todo el inv si no solo la cantidad de municiones de ddicha arma, como ago aora?

Ve al primer post del ilo y podrás hacer pull request.

Yo cada que soluciono algún detalle con git me sale algo más, ahora parece que no me deja hacer pull request, eso me desmotiva, pero bueno a seguir.

Por qué no te deja?

No sale la rama que he creado en la página, y me dice que la comparación de master de jmdaweb y la rama master mía son idénticas. Puede ser porquetrasteando me dió por darle
git pull master, o no sé, pero puedo hacer git add, git push, eeen fin.

Asegúrate de hacer un git push a tu rama. Si no no saldrá.

mi rama creada se llama changes-builder, y ya he hecho varias veces git push origin changes-builder y no pasa nada

define no pasa nada. ¿qué mensaje da?

Pero si tu rama master es igual a la rama master de jmdaweb y las modificaciones las aplicaste sobre tu rama master... ¿no será que hiciste un pull antes de hacer el commit?

Ala, no se que sería, ya no entiendo nada, eeeen fin, como vuelvo atrás entodo y vuelvo a comenzar? mi solución es
anotar mis cambios en algún lugar para no perderlos al deshacer todo, y luego volver a clonar el repo, y ahí si hacer lascosas mas consientemente.

borra tu repo local y vuelve a clonar y haz un git log. Luego muéstranos qué arroja.

Perfecto, pull request creado! solo era hacer las cosas mejor aunque no tanto... y listo.

Primero voy a revisar y mezclar la de BOFH. Es posible que descuadre totalmente la tuya y no se pueda hacer merge, pero ya te diré.

Yo no he tocado archivos .bgt. A saber cómo podría descuadrar nada.

Confirmo, tu pull request da conflicto con la de @MRCobra. Felicidades @MRCobra, buen trabajo. He corregido un par de cosas que te habías dejado:
-Servidor.configs: eliminadas las referencias a votos2d y votos3d.
-Client.bgt: todas las referencias a "*" se sustituyen por SOUND_STORAGE. Tal y como especifica la documentación de BGT, "*" se utiliza cuando el pack de sonidos está incrustado en el archivo exe.

De hecho, en mi trabajo puce todas las referencias hacia el pack de sonidos como SOUND_STORAGE, eso unifica la gestión, así si cambia SOUND_STORAGE cambiarán todas sus referencias / dependencias y eso agiliza y organiza el proceso.
Téngace en cuenta que para que el pack de sonidos esté dentro del ejecutable, hay que poner el paquete .dat como una inclusión dentro de client.bgt, o dentro del archivo de includes.bgt, el cual en mi otro trabajo he eliminado, para restar tiempo de carga y reducir KB al paquete ejecutable.

Pues lamento decirte que no has reducido nada. Es el compilador el que se encarga de reducir y optimizar el código. Nosotros debemos garantizar que el código sea modular, legible, eficiente y actúe correctamente. El ejecutable que se crea si quitas includes.bgt y mueves las líneas a otro lugar es exactamente el mismo que se crea si includes.bgt sigue ahí. En cuanto a empaquetar sounds.dat en el ejecutable, tiene la ventaja de que todo carga más rápido porque el exe completo está en ram, y la desventaja de que la carga inicial dura más tiempo... porque hay que cargar todo en ram.

Perfecto, comprenddido, se aprende mucho de estas cosas. Cabe anotar que lo de includes lo mofiqué en otro código que ando trabajando, no para EVM.

tiene que tener atención en la ultima función del cliente.bgt. Esta tambien usas * y no es con sounds.dat, ella cambia palavras agrecivas por *.

Perfecto, solucionados losconflictos, y comentario añadido al pull request, ahora solo toca esperar a que @el_pichon lo revice.
Próximamente crearé la documentación para el constructor, así como tengo planeadas algunas cosas nuevas para él, pero ya llegarán con algunos días.