← Modification précédente Modification suivante →

Version du 27 octobre 2025 à 18:31

Changements du code de la semaine

Sauvegarde des modifications des objets

Commit

Commit 02249b : Réduction des sauvegardes inutiles des primitives des inventaires.
Changement en rapport avec ce qui a été discuté la semaine précédente.
Ubit Umarov explique qu'auparavant, l'inventaire des prims avait un indicateur permettant de sauter la sauvegarde si aucune modification n'était faite. Cet indicateur a dû être désactivé car, dans certains cas, une sauvegarde nécessaire n'avait jamais lieu. Dans ce commit, il a essayé de couvrir ces cas et il a laissé l'indicateur fonctionner à nouveau.

Configuration conseillée

Configuration dans OpenSim.ini : Ubit Umarov conseille de définir MinimumTimeBeforePersistenceConsidered à une valeur la plus élevé possible. Gavin Hird conseille de régler le paramètre à une valeur assez haute pour les simulateurs peu sollicité et plus basse pour les simulateurs très sollicités.

;; Valeurs par défaut
MinimumTimeBeforePersistenceConsidered = 10
MaximumTimeBeforePersistenceConsidered = 100

Au lieu de s'appuyer sur l'utilisation de ces paramètres, Vincent Sylvester préfère se concentrer sur les causes sous-jacentes pour une solution plus bénéfique pour tous, y compris pour les utilisateurs peu familiarisés avec la configuration.
Une valeur élevée pour MinimumTimeBeforePersistenceConsidered pourrait également impacter la suppression des objets temporaires et la sauvegarde des modifications lors de l'arrêt du simulateur, ce qui pourrait entraîner la perte de certaines modifications.

Tests

Vincent Sylvester a passé plus de temps à rechercher les cause du problème en exécutant environ 20 minutes de journaux d'audit SQL pour comprendre exactement ce qui provoquait les sauvegardes intempestives de primitives non modifiées dans l'inventaire.
Certaines boules dansantes réinitialisaient en permanence son script contenant llTargeOmega ainsi que le système de particules, et un objet sur une région de la grille était constamment signalé comme étant modifié, même si rien n'avait réellement changé.
Il a intégré des modifications de type if(changed) dans la propriété HasGroupChanged, afin de vérifier si un objet a réellement été modifié. Un code de déduplication pour la table Primitems a également été inclus.
De nouveaux tests sont prévus, avec l'espoir d'obtenir des résultats similaires à ceux de la semaine précédente. D'ici jeudi, des données devraient être disponibles pour analyse. Si tout se passe bien, Vincent Sylvester pense que ce sera la voie à suivre.

Bilan et problème

Cela va offrir une amélioration significative pour les grandes grilles actives, et peut apporter une légère amélioration pour les grilles moins actives.
D'après Ubit Umarov , l'enregistrement des objets liés est très basique. Tout ce qui compose l'objet lié est enregistré à la moindre modification. Donc même une petite modification sur une primitive forcera une sauvegarde complète de l'objet.
Il faut noter qu'il existe une limite de 1 000 éléments au total dans tous les inventaires des prims d'un objet lié. (NDRL : mais j'ai peut-être mal compris, car ce n'était pas très clair.)
Vincent Sylvester signale que le problème critique est que certaines fonctions LSL, chargées de définir les paramètres des prims, ne comportent pas de vérifications pour savoir si les paramètres sont déjà configurés de la même manière. Cela entraîne une réinitialisation répétée des mêmes valeurs, ce qui marque tout l'objet lié comme modifié. Bien que certaines fonctions aient cette vérification, ce n'est pas le cas pour toutes.

Avertissement

Attention : Ce résumé existe pour orienter vos recherches. Des erreurs d'interprétation ne sont pas à exclure. Pour plus de précisions, veuillez vous référer aux sources ou vous adresser directement aux développeurs d'OpenSimulator en assistant aux réunions du mardi ou sur le canal IRC. Je ne fais pas partie des développeurs, ne vous adressez pas à moi pour les joindre. Merci.😉

Bibliothèques

BulletSim

Ubit Umarov attend toujours le retour de Cuga Rajal.
Cuga Rajal n'a pas encore pu joindre MrBlue à propos de Bullet.

Scripts

LlModifyLand

Fonction

Fonction: llModifyLand( integer action, integer brosse );
Modifie le terrain en appliquant l’action avec la taille de brosse indiquée

Code dans OpenSim

Dans /OpenSim/Region/ScriptEngine/Shared/Api/Runtime/LSL_Stub.cs

# Ligne 1433
 [MethodImpl(MethodImplOptions.AggressiveInlining)]
 public void llModifyLand(int action, int brush)
 {
      m_LSL_Functions.llModifyLand(action, brush);
 }

Dans /OpenSim/Region/ScriptEngine/Shared/Api/Runtime/LSL_Constants.cs

# Ligne 332
   public const int LAND_LEVEL = 0;
   public const int LAND_RAISE = 1;
   public const int LAND_LOWER = 2;
   public const int LAND_SMOOTH = 3;
   public const int LAND_NOISE = 4;
   public const int LAND_REVERT = 5;
   public const int LAND_SMALL_BRUSH = 1;
   public const int LAND_MEDIUM_BRUSH = 2;
   public const int LAND_LARGE_BRUSH = 3;

Signalement du bug

Bug déjà mentionné dans le rapport de bug Mantis 9216 : Les paramètres de modification du terrain et du pinceau sont incorrects.
Jagga Meridith le signale pendant la réunion car il est possible que certains scripts les utilisent, ce qui causerait des dysfonctionnements : il faut remplacer les contantes par les valeurs de brosse 0,1 et 2. Le wiki de Second Life conseille aussi d'utiliser les chiffres.

 llModifyLand(LAND_LEVEL,0); # brosse de 2m * 2m    
 llModifyLand(LAND_LEVEL,1); # brosse de 4m * 4m    
 llModifyLand(LAND_LEVEL,2); # brosse de 8m * 8m

Modules

Carte

Mise à jour des tuiles de carte

Question

Pourquoi la mise à jour des tuiles de cartes ne se fait pas toujours ?

Réponses

La manière dont le serveur Robust gère les tuiles lorsqu'il les reçoit repose en grande partie sur des suppositions selon lesquelles il ne recevra pas de données supplémentaires pendant qu'il est en train de les générer.
De plus, la mini-carte et la carte du monde sont mises en cache dans le viewer, il faut un certain temps avant qu'elle n'essaie d'en récupérer de nouvelles. Redémarrer le viewer résoudra ce problème.
Même avec le nouveau système que Vincent Sylvester teste depuis des mois , certaines tuiles n'apparaissent toujours pas. Il ne comprend pas vraiment pourquoi, car le nouveau système est censé attendre un certain temps avant d'essayer d'analyser les données. Il soupçonne qu'il y aurait un problème avec la mise en cache des fichiers dotnet.

À propos du nouveau système de Vincent Sylvester

Exportation : conservation des détails

Question

L'exportation de la carte d'altitude conserve-t-elle la même profondeur de bits que le fichier TIFF importé ? (C'est bien l'exportation de fichier Tiff qui pose problème à Cuga Rajal. )

Chargeur de terrain Tiff

Réponses

Pour l'importation, Vincent Sylvester a écrit un code pour modifier le chargeur TIFF afin qu'il accepte une profondeur de 32 bits. Il dit que ce n'est pas difficile, mais le chargement des fichiers est très manuel, bit par bit, car le chargeur natif ne prend pas en charge cette profondeur de bits.
Pour tout ce qui n'est pas r32, on obtient des approximations.
La plupart des formats d'image normaux coupent la carte à certaines hauteurs.
Cuga Rajal exporte les fichier via la ligne de commande. C'est la seule méthode qui fonctionne pour lui. La fonctionnalité du viewer ne marche pas. Le téléchargement et le chargement du viewer sont vraiment lents parce qu'ils se font via UDP ou quelque chose comme ça. Les données sont envoyées morceau par morceau et cela prend une éternité. Parfois ça ne se termine jamais comme pour les varregions de 2048x2048. Une seule région peut mettre 5 minutes si la heightmap est vraiment complexe.
Le code du viewer ne gère que des configurations de simulateur 1024x1024.

Informations

Techniques de terraformation

Terraformation des frontières

La terraformation des frontières d'une région est souvent un problème en particulier quand la différence de hauteur est importante.
Gavin Hird utilise une petite brosse "flatten" pour travailler de la région la plus élevée vers la plus basse en descendant vers la frontière.
Jagga Meridith trouve que les brosses ne sont pas assez sensibles.

Utilisation de scripts

Script niveleur "land flattener" : objet scripté que l'on déplace pour niveler le terrain autour de lui.
Script terraformeur mobile "crawler" : objet scripté qui se déplace sur le terrain pour le façonner.

Utilisation de heightmaps

Vincent Sylvester souligne que pour obtenir un terrain vraiment détaillé et esthétique, il est souvent nécessaire de recourir à l’importation de heightmaps. Les contrôles du viewer pour le terrain ne permettent pas d'obtenir un niveau de détail aussi élevé.
Gavin Hird note que pour ceux qui souhaitent effectuer des changements des années plus tard, la méthode d'importation d’images pourrait être limitée, car des anciens points de terre pourraient ne jamais être lissés en raison de données corrompues dans la carte de terrain.

Séance de questions-réponses avec Phillip Rosedale

Sujet : nouveaux serveurs vocaux WebRTC de SL
Date : 1er octobre à 13 h (heure du Pacifique)

Source

http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2025-09-30

@@ Ligne 95 : / Ligne 95 : @@
 * La plupart des formats d'image normaux coupent la carte à certaines hauteurs.
 * Cuga Rajal exporte les fichier via la ligne de commande. C'est la seule méthode qui fonctionne pour lui. La fonctionnalité du viewer ne marche pas. Le téléchargement et le chargement du viewer sont vraiment lents parce qu'ils se font via UDP ou quelque chose comme ça. Les données sont envoyées morceau par morceau et cela prend une éternité. Parfois ça ne se termine jamais comme pour les varregions de 2048x2048. Une seule région peut mettre 5 minutes si la heightmap est vraiment complexe.
 * Le code du viewer ne gère que des configurations de simulateur 1024x1024.
-* 🏗️
 = Informations =