[resolu] Temps réél et mise à jours

[Zamentur]

Bon je pense cerner un peu plus la chose...
En m'appuyant sur ce qui vient d'être dit sur le message précédent, voici ce que je ferais:

Je considère que le perso va à une vitesse constante connue, du coup comme l'a dit barst on peut oublier d'enregistrer l'heure d'arriver .

donc je créerais une table position:
id_perso, pos_actuel, cap, date
id_perso étant l'identifiant du perso
pos_actuel étant en fait 2 colonnes faisant référence à la position actuelle (à la date indiqué "date")
cap une position d'arrivée en 2 colonne
date la date de l'Update

Je pars du principe que tu ne souhaite pas conserver le trajet complet effectué (qui serait de toute façon à mettre dans une table Archive et non MyISAM)

Tu peux grâce à cette table décrire le mouvement d'un perso, et même "les mouvements fixes" je veux dire que cap=pos_actuel

Pour déterminer si 2 personnes se sont rencontré (passé très proche) il te suffit alors de chercher l'intersection de droite entre le chemin du joueur et celui de tout les autres joueurs et de les sortir par ordre chronologique

Mais comme tu souhaites le faire si les perso sont à une distance définie le cas est un peu plus complexe...

Donc si tu fait "un peu" de math il n'est pas très complexe de définir la formule de math qu'il te faudra rentrer dans ta requête sql pour sortir dans l'ordre les combat qui auront eu lieu... (pour la formule de math j'ai déjà mis dans un autre message une solution qui y ressemble, mais si tu vois pas demande)
Sachant que le trucs doit être récursif dans le sens, ou si le joueur 1 se connecte on vérifie si dans son trajet précédent il n'y a pas eu de combat si il y en a eu on est obligé de regarder si les opposants n'ont pas eu avant la rencontre d'autre combat
On remonte ainsi en mettant à jour tout ces combats de personnes qui n'était pas connecté...

Tu peux aussi mettre à jour toute les 5 minutes en cherchant toute les rencontre de tout le monde, ou en approximant: tu met à jour toute les 5 minutes la position de chacun et tu regarde qui est très proche...


Bon mais comme je ne suis pas certains d'avoir compris le sujet, je vais pas développer plus au cas ou je me plante complètement!

[barst]

Remarque :
La propriété `end_date' ne devrait pas être enregistrée dans la table. C'est une donnée calculable donc c'est superficiel de l'enregistrer.

Je dois dire que je l'aurais comme même stocké rien que pour n'avoir à le calculer qu'une seule fois.
Car à chaque fois que l'on va tester si une rencontre/intersection a eu lieu, on a besoin de connaître la période complète et donc je ne souhaites pas refaire le calcul à chaque fois même si le calcul peut-être inclus dans la requête.

[Plume]

Question optimisation. Et surtout , SGBD relationnel , y a des règles à appliquer qui sont pas inutiles. Voir Merise

[NicoMSEvent]

je vais mettre mon grain de sel...

Je crois qu'avec une table :
id_vaisseau,
moment_depart,
case_depart,
case_arrivee

on a tout ce qu'il nous faut.
Il ne reste plus qu'a lancer une procédure qui va calculer a l'avance les routes coupées, et les heures auquelles elle seront coupées.
On mettrait dans une table combat (par exemple) toutes les rencontres (vaisseaux mobiles, et immobiles => simple equation de math avec des vecteurs).
Si le vaisseau est détruit, on supprime tous les combats a venir pour ce vaisseau.

Le probleme : pour qu'un vaisseau fasse réellement le combat a telle ou telle heure, il y a 36 solutions, mais peu qui ne consomment rien et ont un semblant de temps réel. L'idéal serait de lancer les combats dès que le mouvement (et le calcul des rencontre) est lancé, et n'afficher les résultats que lorsque le combat a effectivement eu lieu (champ heure_de_rencontre>= sysdate dans la table combat).
Et si un vaisseau part après le notre? justement, il lance un nouveau combat pour notre vaisseau.
Et si il détruit mon vaisseau alors que j'ai encore des combats a faire? Je l'ai dit quelques ligne plus hauts, les combats qui n'ont pas encore eu lieu sont suprpimés.

J'espere avoir fait avancer le schmilblik...