Bien évidemment que tu ne fais pas un calcul continu de la construction d'un bâtiment jusqu'à sa fin et que tu ne le fais qu'à la fin de l'exécution effective. Donc oui, si tu lances à 2h et que ça prend 4h, tu ne fais le calcul qu'à 6h, c'est évident ça. Tu ne vas pas le mettre à jour en continu. Donc non, tu n'as aucun espèce de compteur en bdd, juste une date. On est sur la même longueur d'onde à ce sujet.
La tâche cron n'est pas là pour faire un calcul continu de chaque opération, elle est là pour faire les calculs des opérations qui se terminent dans le laps de temps passé. Je ne dis rien de contraire à toi sur ce point.
Ce que je te dis, c'est que si tu fais des calculs qu'à la fin des événements, tu auras forcément un décalage pour quelqu'un qui est là. Donc oui, pourquoi pas en effet résoudre les conflits liés au joueur espionné. Il n'empêche que si tu te contentes de ça, ton joueur qui aura résolu ces conflits n'aura un retour qu'au moment de l'exécution du cron, soit potentiellement près d'une minute après la fin théorique effective pour lui. En cela, la tâche cron est nécessaire mais non suffisante.
Cette résolution, le joueur qui est là doit pouvoir la "forcer" pour que tout ce qui le concerne soit à jour au moment où ça doit l'être. Il peut donc mettre à jour cette liste d'événements qui se terminent. C'est bien sûr une solution de facilité qui ne peut pas fonctionner sur un nombre très important d'utilisateurs pour les raisons que tu évoques et qui seront que tu auras forcément des erreurs ici et là. Sur une population active restreinte en un temps t, si tu as une temporalité bien assez fine, le risque est assez mineur. Mais j'ai vu ce genre de problèmes sur des jeux fournis par des entreprises et non pas amateurs, il est vrai.
Si ton combat prend 5 minutes à se calculer, avec 2 joueurs seulement, tu as un grave problème d'optimisation. Mais on est d'accord qu'on suppose là que les traitements à effectuer sont sur des temps très brefs et qu'évidemment tu les calcules dans l'ordre chronologique, sans quoi tu auras un calcul fini avant un autre.
Quant à savoir si le cron est une merde ou non, c'est un autre sujet. Ca reste la solution la plus accessible et la moins impropre pour ce genre de problématiques dans les dimensions et besoins qui nous concernent et qui ne sont pas ceux des banques ou entreprises critiques.
La tâche cron n'est pas là pour faire un calcul continu de chaque opération, elle est là pour faire les calculs des opérations qui se terminent dans le laps de temps passé. Je ne dis rien de contraire à toi sur ce point.
Ce que je te dis, c'est que si tu fais des calculs qu'à la fin des événements, tu auras forcément un décalage pour quelqu'un qui est là. Donc oui, pourquoi pas en effet résoudre les conflits liés au joueur espionné. Il n'empêche que si tu te contentes de ça, ton joueur qui aura résolu ces conflits n'aura un retour qu'au moment de l'exécution du cron, soit potentiellement près d'une minute après la fin théorique effective pour lui. En cela, la tâche cron est nécessaire mais non suffisante.
Cette résolution, le joueur qui est là doit pouvoir la "forcer" pour que tout ce qui le concerne soit à jour au moment où ça doit l'être. Il peut donc mettre à jour cette liste d'événements qui se terminent. C'est bien sûr une solution de facilité qui ne peut pas fonctionner sur un nombre très important d'utilisateurs pour les raisons que tu évoques et qui seront que tu auras forcément des erreurs ici et là. Sur une population active restreinte en un temps t, si tu as une temporalité bien assez fine, le risque est assez mineur. Mais j'ai vu ce genre de problèmes sur des jeux fournis par des entreprises et non pas amateurs, il est vrai.
Si ton combat prend 5 minutes à se calculer, avec 2 joueurs seulement, tu as un grave problème d'optimisation. Mais on est d'accord qu'on suppose là que les traitements à effectuer sont sur des temps très brefs et qu'évidemment tu les calcules dans l'ordre chronologique, sans quoi tu auras un calcul fini avant un autre.
Quant à savoir si le cron est une merde ou non, c'est un autre sujet. Ca reste la solution la plus accessible et la moins impropre pour ce genre de problématiques dans les dimensions et besoins qui nous concernent et qui ne sont pas ceux des banques ou entreprises critiques.