Dudas Sobre Dead Reckoning

[ethernet]

 Yo solo entro aquí para añadir datos que nublen la cabeza a trancos. Los programas que usan las posiciones de un GPS, los cuales normalmente dan una posición cada segundo (eso sí que es lag), usan un algoritmo de extrapolación basado en un filtro llamado kalman, además de otros sistemas.

En mi PFC yo he usado el extrapolar usando los 3 últimos valores de posición y dirección, con esos el error de predicción es bajo.

[Lord Trancos 2]

 ethernet, lo de extrapolar usando los ultimos valores suena interesante. Yo actualmente solo uso el ultimo que hay llegado.

vicho, lo que queria decir con que no comprendo el codigo de la funcion clientCorrection y el buffer circular de ultimos movimientos, sigo sin comprenderlo. He mirado el codigo que me pasaste y en la clase Client tienes un array llamado Movement que parece ser eso mismo. Pero no se que uso le das.  (nooo)

AK47, respecto a los disparos, lo cierto es que todavia no tengo nada claro si quiero realizarlos en el cliente o en el servidor. Ciertamente si lo hago en el cliente no tendre problemas de latencia, pero tengo el problema de que alguien podria (dudo que pase pero bueno) "cheatear" y realizar disparos perfectos (directos a la cabeza del enemigo). Lo de enviar mensajes seguros mediante reenvio... intente implementarlo pero me salio mal y al final lo quite. Asi que preferiria intentar evitar ese tipo de mecanismos si es posible. Respecto a la integridad de los paquetes UDP, me suena que en el codigo del quake 2 vi algo de que se comprobaba su CRC (no me preguntes donde pq ahora no lo encuentro, ¿lo habre soñado?), asi que por mi parte voy a hacer lo mismo.

senior wapo, a ver si lo he entendido... para los otros objetos predigo su posicion basado en su ultimo estado e input conocido enviado por el servidor, menos para el jugador que lo hago en los datos de su input real (fisico), ¿no? (todo esto desde el lado cliente)

[ethernet]

vicho, lo que queria decir con que no comprendo el codigo de la funcion clientCorrection y el buffer circular de ultimos movimientos, sigo sin comprenderlo. He mirado el codigo que me pasaste y en la clase Client tienes un array llamado Movement que parece ser eso mismo. Pero no se que uso le das.  (nooo)

AK47, respecto a los disparos, lo cierto es que todavia no tengo nada claro si quiero realizarlos en el cliente o en el servidor. Ciertamente si lo hago en el cliente no tendre problemas de latencia, pero tengo el problema de que alguien podria (dudo que pase pero bueno) "cheatear" y realizar disparos perfectos (directos a la cabeza del enemigo). Lo de enviar mensajes seguros mediante reenvio... intente implementarlo pero me salio mal y al final lo quite. Asi que preferiria intentar evitar ese tipo de mecanismos si es posible. Respecto a la integridad de los paquetes UDP, me suena que en el codigo del quake 2 vi algo de que se comprobaba su CRC (no me preguntes donde pq ahora no lo encuentro, ¿lo habre soñado?), asi que por mi parte voy a hacer lo mismo.

Guarda lo últimos valores para volver atrás cuando llega la carrección y después aplicar de nuevo todos los movimientos de usuario: Imaginate que el sistema ha recogido movimientos del usuario hasta el segundo 2.0. El servidor envía una corección para el segundo 1.5. El sistema lo que hace es volver hasta el segundo 1.5, aplica la posición del servidor, y después aplica los movimientos que el usuario hizo desde el segundo 1.5 hasta el 2.0.

Sí, el quake hace un CRC, cosa curiosa porque UDP e IP (y posiblemente los protocolos que van por debajo) ya tienen sus mecanismos de CRC.

[Lord Trancos 2]

 

Guarda lo últimos valores para volver atrás cuando llega la carrección y después aplicar de nuevo todos los movimientos de usuario: Imaginate que el sistema ha recogido movimientos del usuario hasta el segundo 2.0. El servidor envía una corección para el segundo 1.5. El sistema lo que hace es volver hasta el segundo 1.5, aplica la posición del servidor, y después aplica los movimientos que el usuario hizo desde el segundo 1.5 hasta el 2.0.

Pensaba que los paquetes en el pasado se solian ignorar y "yasta". Mientras que el dead reckoing ya se encargaba de solucionar ese tipo de desajustes.

Sí, el quake hace un CRC, cosa curiosa porque UDP e IP (y posiblemente los protocolos que van por debajo) ya tienen sus mecanismos de CRC.

Osea, que realmente no seria necesario que implemente algo asi, no?

[ethernet]

 Yo tb lo he debido de soñar porque no encuentro la parte del código donde hace el CRC. XD

Con respecto a IP solo tiene CRC de la cabecera (me he colado de nuevo, http://www.erg.abdn.ac.uk/users/gorry/cour.../ip-packet.html ), sin embargo UDP si aporta CRC sobre los datos (http://www.networksorcery.com/enp/protocol/udp.htm#Checksum)  

[vicho]

 basicamente el buffer circular es un historial de movimientos la idea detras de eso es que imaginate que tu en el lado del cliente predices en cada step donde deberias estar con tu input de teclado. el servidor cada tantos milisegundos te enviara posiciones de correccion bueno la idea del buffer circular es buscar donde estabas en tal tiempo y si te llega que estabas en un tiempo tanto en tal posicion y tu estabas muy cerca de ese lugar segun tu historial pues ignoras la correccion. esa es la utilidad de ese buffer ;)

[senior wapo]

 

senior wapo, a ver si lo he entendido... para los otros objetos predigo su posicion basado en su ultimo estado e input conocido enviado por el servidor, menos para el jugador que lo hago en los datos de su input real (fisico), ¿no? (todo esto desde el lado cliente)

Si.

El jugador sabe que movimiento quería hacer y cuando lo hizo, por lo que si usas los datos del servidor notaría enseguida el lag y discrepancias de posición (ajustes). En cambio, no tiene manera de saber si los comportamientos de los otros jugadores son recientes y precisos o sólo una aproximación ( a menos que tenga su PC al lado).

No se puede hacer más si hay lag. Milagros no hacemos :)

[Lord Trancos 2]

 Ok. gracias gente. Creo que por fin comprendo lo del buffer circular.  :rolleyes: