Réunion du 09-07-2024 - Historique des versions

Acryline : /* Rappel */

2024-07-12T16:55:49Z

Rappel

← Version précédente		Version du 12 juillet 2024 à 18:55
Ligne 53 :		Ligne 53 :
	** '''Nécessite un serveur Web protocole HTTPS''' (important! ne pas utiliser sans TLS/SSL). En raison de la suppression des fonctions xmlrpc dans PHP 8, la version de PHP la plus compatible est la dernière '''PHP 7.4'''. La partie PHP ne fonctionne pas avec PHP 8.		** '''Nécessite un serveur Web protocole HTTPS''' (important! ne pas utiliser sans TLS/SSL). En raison de la suppression des fonctions xmlrpc dans PHP 8, la version de PHP la plus compatible est la dernière '''PHP 7.4'''. La partie PHP ne fonctionne pas avec PHP 8.
	=== Rappel ===		=== Rappel ===
	* Ubit Umarov souligne qu'OpenSim ne touche pas aux modules d'argent et encore moins aux <del>systèmes pyramidaux</del> choses ~~cryto~~.		* Ubit Umarov souligne qu'OpenSim ne touche pas aux modules d'argent et encore moins aux <del>systèmes pyramidaux</del> choses crypto.
	* À la remarque "C'est peut-être pour cela que la caisse d'opensin se retrouve vide", il répond : " Oui, vide mais pas en prison." {{NDLR\|fond=white \|bord=green\|message = J'ai bien ri, donc je vous en fais profiter.}}		* À la remarque "C'est peut-être pour cela que la caisse d'opensin se retrouve vide", il répond : " Oui, vide mais pas en prison." {{NDLR\|fond=white \|bord=green\|message = J'ai bien ri, donc je vous en fais profiter.}}

Acryline : /* Limitation des mises à jours des agents */

2024-07-12T15:36:00Z

Limitation des mises à jours des agents

← Version précédente		Version du 12 juillet 2024 à 17:36
Ligne 17 :		Ligne 17 :
	* 125 mises à jour c'est une mise à jour toutes les 8ms, qui doit être traitée et transformée en données pour la frame suivante, ce pour quoi on ne dispose que de 16ms de manière réaliste. De plus avec le viewer Firestorm PBR actuel la plupart des utilisateurs n'ont même pas 25 fps.		* 125 mises à jour c'est une mise à jour toutes les 8ms, qui doit être traitée et transformée en données pour la frame suivante, ce pour quoi on ne dispose que de 16ms de manière réaliste. De plus avec le viewer Firestorm PBR actuel la plupart des utilisateurs n'ont même pas 25 fps.
	* '''Informations complémentaires en anglais''' : [https://jira.firestormviewer.org/browse/FIRE-34171][https://feedback.secondlife.com/bug-reports/p/directional-input-delays-with-latest-pbr-capable-viewers]		* '''Informations complémentaires en anglais''' : [https://jira.firestormviewer.org/browse/FIRE-34171][https://feedback.secondlife.com/bug-reports/p/directional-input-delays-with-latest-pbr-capable-viewers]
	* [[Réunion_du_16-04-2024#Problème_de_la_course_à_l’œuf \|Sujet proche : ~~Problème_de_la_course_à_l’œuf~~]]		* [[Réunion_du_16-04-2024#Problème_de_la_course_à_l’œuf \|Sujet proche : Problème de la course à l’œuf]]

	= Avertissement =		= Avertissement =

Acryline : /* Limitation des mises à jours des agents */

2024-07-12T15:35:37Z

Limitation des mises à jours des agents

← Version précédente		Version du 12 juillet 2024 à 17:35
Ligne 17 :		Ligne 17 :
	* 125 mises à jour c'est une mise à jour toutes les 8ms, qui doit être traitée et transformée en données pour la frame suivante, ce pour quoi on ne dispose que de 16ms de manière réaliste. De plus avec le viewer Firestorm PBR actuel la plupart des utilisateurs n'ont même pas 25 fps.		* 125 mises à jour c'est une mise à jour toutes les 8ms, qui doit être traitée et transformée en données pour la frame suivante, ce pour quoi on ne dispose que de 16ms de manière réaliste. De plus avec le viewer Firestorm PBR actuel la plupart des utilisateurs n'ont même pas 25 fps.
	* '''Informations complémentaires en anglais''' : [https://jira.firestormviewer.org/browse/FIRE-34171][https://feedback.secondlife.com/bug-reports/p/directional-input-delays-with-latest-pbr-capable-viewers]		* '''Informations complémentaires en anglais''' : [https://jira.firestormviewer.org/browse/FIRE-34171][https://feedback.secondlife.com/bug-reports/p/directional-input-delays-with-latest-pbr-capable-viewers]
			* [[Réunion_du_16-04-2024#Problème_de_la_course_à_l’œuf \|Sujet proche : Problème_de_la_course_à_l’œuf]]

	= Avertissement =		= Avertissement =

Acryline : /* Limitation des mises à jours des agents */

2024-07-12T15:21:51Z

Limitation des mises à jours des agents

← Version précédente		Version du 12 juillet 2024 à 17:21
Ligne 13 :		Ligne 13 :
	* [http://opensimulator.org/viewgit/?a=commit&p=opensim&h=b06ecf801469f966705a17f8b5323c1741f23168 Commit b06ecf] : Maintenant, les agents envoient des '''demandes de non-actualisation aux viewers''' pour en ignorer certaines.		* [http://opensimulator.org/viewgit/?a=commit&p=opensim&h=b06ecf801469f966705a17f8b5323c1741f23168 Commit b06ecf] : Maintenant, les agents envoient des '''demandes de non-actualisation aux viewers''' pour en ignorer certaines.
	* '''Le code de gestion des périphériques (souris et clavier)''' du viewer semble être inefficace. Cela peut entraîner des problèmes de réactivité ou de fluidité dans l'interaction avec le monde virtuel. Pour pallier à ces problèmes, augmenter les mises à jour des agents peut être une solution pour améliorer la synchronisation et la réponse aux actions des utilisateurs, même si cela peut entraîner d'autres défis en termes de charge de traitement et de bande passante.		* '''Le code de gestion des périphériques (souris et clavier)''' du viewer semble être inefficace. Cela peut entraîner des problèmes de réactivité ou de fluidité dans l'interaction avec le monde virtuel. Pour pallier à ces problèmes, augmenter les mises à jour des agents peut être une solution pour améliorer la synchronisation et la réponse aux actions des utilisateurs, même si cela peut entraîner d'autres défis en termes de charge de traitement et de bande passante.
	* Les viewers peuvent envoyer davantage de demandes de mises à jour lorsque le '''GPU''' est capable de traiter un plus grand nombre d'images par seconde et qu'il a un taux de rafraîchissement élevé. S'il fait 400fps (frame par seconde), il envoie environ 300 mises à jour par seconde. Cela peut entraîner des '''pertes de paquets de données'''. En réponse à cela, Linden Lab a réduit le nombre de mises à jour à 10 par seconde, ce qui a affecté négativement l'expérience des utilisateurs en termes de fluidité, entraînant des plaintes. Les scripts de véhicules de Second Life ~~demande~~ 45 mises à jour par seconde. Actuellement, les serveurs de Second Life ignorent tous les événements plus rapides que 45 mises à jour par seconde.		* Les viewers peuvent envoyer davantage de demandes de mises à jour lorsque le '''GPU''' est capable de traiter un plus grand nombre d'images par seconde et qu'il a un taux de rafraîchissement élevé. S'il fait 400fps (frame par seconde), il envoie environ 300 mises à jour par seconde. Cela peut entraîner des '''pertes de paquets de données'''. En réponse à cela, Linden Lab a réduit le nombre de mises à jour à 10 par seconde, ce qui a affecté négativement l'expérience des utilisateurs en termes de fluidité, entraînant des plaintes. Les scripts de véhicules de Second Life demandent 45 mises à jour par seconde. Actuellement, les serveurs de Second Life ignorent tous les événements plus rapides que 45 mises à jour par seconde.
	* '''Firestorm permet 125 mises à jour par seconde.''' Peut-être pour les combats ? '''Ubit Umarov a ajouté du code pour ignorer ce qui va au delà de 45 mises à jour par secondes '''. OpenSim n'envoie que 10 mises à jour de mouvement par seconde avec les réglages par défaut ce qui est correct pour une région sociale.		* '''Firestorm permet 125 mises à jour par seconde.''' Peut-être pour les combats ? '''Ubit Umarov a ajouté du code pour ignorer ce qui va au delà de 45 mises à jour par secondes '''. OpenSim n'envoie que 10 mises à jour de mouvement par seconde avec les réglages par défaut ce qui est correct pour une région sociale.
	* 125 mises à jour c'est une mise à jour toutes les 8ms, qui doit être traitée et transformée en données pour la frame suivante, ce pour quoi on ne dispose que de 16ms de manière réaliste. De plus avec le viewer Firestorm PBR actuel la plupart des utilisateurs n'ont même pas 25 fps.		* 125 mises à jour c'est une mise à jour toutes les 8ms, qui doit être traitée et transformée en données pour la frame suivante, ce pour quoi on ne dispose que de 16ms de manière réaliste. De plus avec le viewer Firestorm PBR actuel la plupart des utilisateurs n'ont même pas 25 fps.

Acryline le 12 juillet 2024 à 15:18

2024-07-12T15:18:18Z

Acryline : /* Réponses */

2024-07-12T14:25:36Z

Réponses

← Version précédente		Version du 12 juillet 2024 à 16:25
Ligne 97 :		Ligne 97 :
	Il semblerait que pour des régions de taille égale ou inférieure à 1024, le système n'ait pas besoin de créer de nouvelles boîtes de délimitation car la taille de la boîte de délimitation existante est suffisante pour couvrir ces régions.		Il semblerait que pour des régions de taille égale ou inférieure à 1024, le système n'ait pas besoin de créer de nouvelles boîtes de délimitation car la taille de la boîte de délimitation existante est suffisante pour couvrir ces régions.
	}}		}}
	* 🏗️		* Il est possible, via la console, de lister tous les objets connus de la région, ce qui devrait être similaire à ce qui est enregistré dans la base de données. Cela permet de vérifier s'il reste un objet fantôme ou si le problème se situe plus en profondeur dans le moteur physique. Le débogage du moteur physique peut être plus complexe, mais il est probable qu'il existe un moyen d'ajouter une commande pour lister les objets qu'il a actuellement en "cache".

	=== [[Réunion_du_30-04-2024#Problème_de_précision_des_grandes_régions \| '''Problème de précision des grandes régions -- réunion du 30-04-2024''' ]]===		=== [[Réunion_du_30-04-2024#Problème_de_précision_des_grandes_régions \| '''Problème de précision des grandes régions -- réunion du 30-04-2024''' ]]===

Acryline : /* Réponses */

2024-07-12T14:19:29Z

Réponses

← Version précédente		Version du 12 juillet 2024 à 16:19
Ligne 93 :		Ligne 93 :
	* Il faudrait répéter la situation sur une simulation de taille standard (256x256). Tester au coin 0,0 et au coin opposé.		* Il faudrait répéter la situation sur une simulation de taille standard (256x256). Tester au coin 0,0 et au coin opposé.
	* Le problème 2 ne semble pas lié à un problème de précision. La suppression d'objets est asynchrone et peut prendre du temps.		* Le problème 2 ne semble pas lié à un problème de précision. La suppression d'objets est asynchrone et peut prendre du temps.
	* Vincent Sylvester explique que la boîte de délimitation (bouding box)[https://uboopenfactory.univ-brest.fr/wiki/index.php?title=Boite_englobante] activée par la physique pour la physique dans OpenSim est de taille 1024x1024, pour le moteur physique BulletSim. Sur des régions plus grande que cela, lorsqu'on se connecte à la région une nouvelle boîte est créée e ne sera jamais supprimée. Cela ne pose pas de problème, elle reste là et consomme des ressources. Cugo Raja pense que c'est probablement la raison car il doit redémarrer OpenSim pour résoudre le problème.		* Vincent Sylvester explique que la boîte de délimitation (bouding box)[https://uboopenfactory.univ-brest.fr/wiki/index.php?title=Boite_englobante] activée par la physique pour la physique dans OpenSim est de taille 1024x1024, pour le moteur physique BulletSim. Sur des régions plus grande que cela, lorsqu'on se connecte à la région une nouvelle boîte est créée et ne sera jamais supprimée. Cela ne pose pas de problème, elle reste là et consomme des ressources. Cugo Raja pense que c'est probablement la raison car il doit redémarrer OpenSim pour résoudre le problème.
	{{NDLR\|fond=white \|bord=green\|message =		{{NDLR\|fond=white \|bord=green\|message =
	Il semblerait que pour des régions de taille égale ou inférieure à 1024, le système n'ait pas besoin de créer de nouvelles boîtes de délimitation car la taille de la boîte de délimitation existante est suffisante pour couvrir ces régions.		Il semblerait que pour des régions de taille égale ou inférieure à 1024, le système n'ait pas besoin de créer de nouvelles boîtes de délimitation car la taille de la boîte de délimitation existante est suffisante pour couvrir ces régions.

Acryline : /* Problème de précision et problème physique */

2024-07-12T14:18:36Z

Problème de précision et problème physique

← Version précédente		Version du 12 juillet 2024 à 16:18
Ligne 75 :		Ligne 75 :
	* '''Tests supplémentaires''' : réseau, moteur physique.		* '''Tests supplémentaires''' : réseau, moteur physique.

	== ~~Problème de précision~~ et ~~problème physique~~ ==		== Physique et varregions ==
	=== Conditions ===		=== Conditions ===
	* Grille OpenSim 0.9.3,		* Grille OpenSim 0.9.3,
Ligne 82 :		Ligne 82 :
	=== Problèmes rencontrés ===		=== Problèmes rencontrés ===
	# le mouvement du '''véhicule est très saccadé''' pendant environ 30 secondes		# le mouvement du '''véhicule est très saccadé''' pendant environ 30 secondes
	# Quand le simulateur est démarré depuis un certain temps, il y a des zones ou le moteur physique détecte un objet physique alors qu'il n'y a rien. L'objet a été déplacé ou supprimé mais, le moteur physique agit comme s'il était toujours là. On peut se tenir debout sur "l'objet". L'objet invisible bloque le mouvement des véhicules. Rien ne s'affiche avec la visualisation des invisibles activée. Le redémarrage du simulateur corrige le problème.		# Quand le simulateur est démarré depuis un certain temps, il y a des zones ou le moteur physique détecte un objet physique alors qu'il n'y a rien. L'objet a été déplacé ou supprimé mais, le moteur physique agit comme s'il était toujours là. On peut se tenir debout sur "l'objet". L'objet invisible bloque le mouvement des véhicules. Rien ne s'affiche avec la visualisation des invisibles activée. Le redémarrage du simulateur corrige le problème. Cela arrive avec n'importe quel objet ou primitive quand on fait passer un véhicule de physique on à off et que ce commutateur échoue. Il n'est pas possible de prévoir quand cela se produira. C'est probablement un échec spécifique à BulletSim. Un mauvais maillage peut causer une tonne de choses, y compris cela.

	=== '''Questions''' de Cuga Rajal ===		=== '''Questions''' de Cuga Rajal ===

Acryline : /* Problèmes rencontrés */

2024-07-12T14:01:32Z

Problèmes rencontrés

← Version précédente		Version du 12 juillet 2024 à 16:01
Ligne 82 :		Ligne 82 :
	=== Problèmes rencontrés ===		=== Problèmes rencontrés ===
	# le mouvement du '''véhicule est très saccadé''' pendant environ 30 secondes		# le mouvement du '''véhicule est très saccadé''' pendant environ 30 secondes
	# Quand le simulateur est démarré depuis un certain temps, il y a des zones ou le moteur physique détecte un objet physique alors qu'il n'y a rien. L'objet a été déplacé ou supprimé mais, le moteur physique agit comme s'il était toujours là. On peut se tenir debout sur "l'objet". Rien ne s'affiche avec la visualisation des invisibles activée. Le redémarrage du simulateur corrige le problème.		# Quand le simulateur est démarré depuis un certain temps, il y a des zones ou le moteur physique détecte un objet physique alors qu'il n'y a rien. L'objet a été déplacé ou supprimé mais, le moteur physique agit comme s'il était toujours là. On peut se tenir debout sur "l'objet". L'objet invisible bloque le mouvement des véhicules. Rien ne s'affiche avec la visualisation des invisibles activée. Le redémarrage du simulateur corrige le problème.

	=== '''Questions''' de Cuga Rajal ===		=== '''Questions''' de Cuga Rajal ===

Acryline : /* Réponses */

2024-07-12T14:01:00Z

Réponses

← Version précédente		Version du 12 juillet 2024 à 16:01
Ligne 93 :		Ligne 93 :
	* Il faudrait répéter la situation sur une simulation de taille standard (256x256). Tester au coin 0,0 et au coin opposé.		* Il faudrait répéter la situation sur une simulation de taille standard (256x256). Tester au coin 0,0 et au coin opposé.
	* Le problème 2 ne semble pas lié à un problème de précision. La suppression d'objets est asynchrone et peut prendre du temps.		* Le problème 2 ne semble pas lié à un problème de précision. La suppression d'objets est asynchrone et peut prendre du temps.
	* La boîte de délimitation (bouding box)[https://uboopenfactory.univ-brest.fr/wiki/index.php?title=Boite_englobante] activée par la physique pour la physique dans OpenSim est de taille 1024x1024, pour le moteur physique BulletSim. Sur des régions plus grande que cela, lorsqu'on se connecte à la région une nouvelle boîte est créée e ne sera jamais supprimée. Cela ne pose pas de problème, elle reste là et consomme des ressources.		* Vincent Sylvester explique que la boîte de délimitation (bouding box)[https://uboopenfactory.univ-brest.fr/wiki/index.php?title=Boite_englobante] activée par la physique pour la physique dans OpenSim est de taille 1024x1024, pour le moteur physique BulletSim. Sur des régions plus grande que cela, lorsqu'on se connecte à la région une nouvelle boîte est créée e ne sera jamais supprimée. Cela ne pose pas de problème, elle reste là et consomme des ressources. Cugo Raja pense que c'est probablement la raison car il doit redémarrer OpenSim pour résoudre le problème.
	{{NDLR\|fond=white \|bord=green\|message =		{{NDLR\|fond=white \|bord=green\|message =
	Il semblerait que pour des régions de taille égale ou inférieure à 1024, le système n'ait pas besoin de créer de nouvelles boîtes de délimitation car la taille de la boîte de délimitation existante est suffisante pour couvrir ces régions		Il semblerait que pour des régions de taille égale ou inférieure à 1024, le système n'ait pas besoin de créer de nouvelles boîtes de délimitation car la taille de la boîte de délimitation existante est suffisante pour couvrir ces régions.
	}}		}}
	* 🏗️		* 🏗️

← Version précédente		Version du 12 juillet 2024 à 17:18
Ligne 23 :		Ligne 23 :
	== Génération des niveaux de zoom de maptile en parallèle ==		== Génération des niveaux de zoom de maptile en parallèle ==
	=== Situation ===		=== Situation ===
	* Régénération des maptiles d'une grille : suppression des anciennes cartes du disque pour que Robust les régénère . Robust démarre un thread de rendu et au bout d'un moment, toutes les maptiles sont à nouveau ~~disponible~~. C'est un processus assez long.		* Régénération des maptiles d'une grille : suppression des anciennes cartes du disque pour que Robust les régénère . Robust démarre un thread de rendu et au bout d'un moment, toutes les maptiles sont à nouveau disponibles. C'est un processus assez long.
	=== Projet ===		=== Projet ===
	* Vincent Sylvester réfléchit à une solution pour créer les différents niveaux de zoom de maptile en parallèle pour accélérer leur génération mais, il est confronté à des problèmes de verrouillage.		* Vincent Sylvester réfléchit à une solution pour créer les différents niveaux de zoom de maptile en parallèle pour accélérer leur génération mais, il est confronté à des problèmes de verrouillage.
Ligne 33 :		Ligne 33 :
	===Problèmes ===		===Problèmes ===
	* La '''dépendance entre les niveaux de zoom''' peut poser problème : une solution proposée par Vincent Sylvester consisterait à générer chaque niveau de zoom de manière indépendante, en ajoutant progressivement les carreaux aux niveaux supérieurs.		* La '''dépendance entre les niveaux de zoom''' peut poser problème : une solution proposée par Vincent Sylvester consisterait à générer chaque niveau de zoom de manière indépendante, en ajoutant progressivement les carreaux aux niveaux supérieurs.
	* OpenSim ne peut pas prendre ~~toute~~ les ressources d'une machine comme un jeu PC.		* OpenSim ne peut pas prendre toutes les ressources d'une machine comme un jeu PC.
	* Il semble qu'actuellement Robust puisse générer 13000 maptile en 10 minutes. L'assemblée a l'air de penser que ce n'est déjà pas si mal.		* Il semble qu'actuellement Robust puisse générer 13000 maptile en 10 minutes. L'assemblée a l'air de penser que ce n'est déjà pas si mal.

Ligne 53 :		Ligne 53 :
	=== Rappel ===		=== Rappel ===
	* Ubit Umarov souligne qu'OpenSim ne touche pas aux modules d'argent et encore moins aux <del>systèmes pyramidaux</del> choses cryto.		* Ubit Umarov souligne qu'OpenSim ne touche pas aux modules d'argent et encore moins aux <del>systèmes pyramidaux</del> choses cryto.
	* À la remarque "C'est peut-être pour cela que la caisse d'opensin se retrouve vide", il répond : " Oui, vide mais pas en prison." {{NDLR\|fond=white \|bord=green\|message = J'ai bien ri, donc je vous en ~~fait~~ profiter.}}		* À la remarque "C'est peut-être pour cela que la caisse d'opensin se retrouve vide", il répond : " Oui, vide mais pas en prison." {{NDLR\|fond=white \|bord=green\|message = J'ai bien ri, donc je vous en fais profiter.}}

	= Divers=		= Divers=
	==Réflexions sur la vitesse des NPC ==		==Réflexions sur la vitesse des NPC ==
	=== Le problème ===		=== Le problème ===
	* Vincent.Sylvester a remarqué que '''les NPC semblent se déplacer plus lentement que les avatars normaux''' ce qui est ennuyeux quand on essaie de les suivre. ~~Leur~~ mouvements sont contrôlés par du code. Il a fait des '''tests asynchrones''' pour isoler le NPC des autres éléments du simulateur et des '''tests simfps''' (simulated frames per second) pour évaluer les performances du simulateur. Cela n'a rien donné.		* Vincent.Sylvester a remarqué que '''les NPC semblent se déplacer plus lentement que les avatars normaux''' ce qui est ennuyeux quand on essaie de les suivre. Leurs mouvements sont contrôlés par du code. Il a fait des '''tests asynchrones''' pour isoler le NPC des autres éléments du simulateur et des '''tests simfps''' (simulated frames per second) pour évaluer les performances du simulateur. Cela n'a rien donné.
	* Les NPC et les avatars utilisent le '''même code de déplacement "moveto"'''.		* Les NPC et les avatars utilisent le '''même code de déplacement "moveto"'''.
	{{NDLR\|fond=white \|bord=green\|message =		{{NDLR\|fond=white \|bord=green\|message =
Ligne 93 :		Ligne 93 :
	* Il faudrait répéter la situation sur une simulation de taille standard (256x256). Tester au coin 0,0 et au coin opposé.		* Il faudrait répéter la situation sur une simulation de taille standard (256x256). Tester au coin 0,0 et au coin opposé.
	* Le problème 2 ne semble pas lié à un problème de précision. La suppression d'objets est asynchrone et peut prendre du temps.		* Le problème 2 ne semble pas lié à un problème de précision. La suppression d'objets est asynchrone et peut prendre du temps.
	* Vincent Sylvester explique que la boîte de délimitation (bouding box)[https://uboopenfactory.univ-brest.fr/wiki/index.php?title=Boite_englobante] activée par la physique pour la physique dans OpenSim est de taille 1024x1024, pour le moteur physique BulletSim. Sur des régions plus ~~grande~~ que cela, lorsqu'on se connecte à la région une nouvelle boîte est créée et ne sera jamais supprimée. Cela ne pose pas de problème, elle reste là et consomme des ressources. Cugo Raja pense que c'est probablement la raison car il doit redémarrer OpenSim pour résoudre le problème.		* Vincent Sylvester explique que la boîte de délimitation (bouding box)[https://uboopenfactory.univ-brest.fr/wiki/index.php?title=Boite_englobante] activée par la physique pour la physique dans OpenSim est de taille 1024x1024, pour le moteur physique BulletSim. Sur des régions plus grandes que cela, lorsqu'on se connecte à la région une nouvelle boîte est créée et ne sera jamais supprimée. Cela ne pose pas de problème, elle reste là et consomme des ressources. Cugo Raja pense que c'est probablement la raison car il doit redémarrer OpenSim pour résoudre le problème.
	{{NDLR\|fond=white \|bord=green\|message =		{{NDLR\|fond=white \|bord=green\|message =
	Il semblerait que pour des régions de taille égale ou inférieure à 1024, le système n'ait pas besoin de créer de nouvelles boîtes de délimitation car la taille de la boîte de délimitation existante est suffisante pour couvrir ces régions.		Il semblerait que pour des régions de taille égale ou inférieure à 1024, le système n'ait pas besoin de créer de nouvelles boîtes de délimitation car la taille de la boîte de délimitation existante est suffisante pour couvrir ces régions.

Réunion du 09-07-2024 - Historique des versions

Acryline : /* Rappel */

Acryline : /* Limitation des mises à jours des agents */

Acryline : /* Limitation des mises à jours des agents */

Acryline : /* Limitation des mises à jours des agents */

Acryline le 12 juillet 2024 à 15:18

Acryline : /* Réponses */

Acryline : /* Réponses */

Acryline : /* Problème de précision et problème physique */

Acryline : /* Problèmes rencontrés */

Acryline : /* Réponses */

Acryline : /* Rappel */

Acryline : /* Limitation des mises à jours des agents */

Acryline : /* Limitation des mises à jours des agents */

Acryline : /* Limitation des mises à jours des agents */

Acryline : /* Réponses */

Acryline : /* Réponses */

Acryline : /* Problème de précision et problème physique */

Acryline : /* Problèmes rencontrés */

Acryline : /* Réponses */