0.9.2.0 Release/fr

From OpenSimulator

(Difference between revisions)
Jump to: navigation, search
(Problèmes connus)
 
(11 intermediate revisions by one user not shown)
Line 1: Line 1:
 
{{Languages|0.9.2.0_Release}}
 
{{Languages|0.9.2.0_Release}}
  
'''ACTUELLEMENT EN COURS DE DÉVELOPPEMENT'''
+
= Géneral =
 +
Bienvenue sur OpenSimulator version 0.9.2.0 Yeti, un environnement virtuel 3D multi-utilisateurs open-source et une plateforme de serveurs métavers.
  
Voir les derniers changements de code à l'adresse [http://opensimulator.org/viewgit/?a=shortlog&p=opensim Dev (git master)]
+
OpenSimulator est un système très complexe. Divers scénarios d'utilisation (autonome, grille, hypergrille, etc.) en combinaison avec différentes dépendances (par exemple, différentes versions de mono sur Linux/Mac) peuvent parfois produire un comportement inattendu ou instable.
  
* Un paquet binaire compilé automatiquement à partir du dernier code de développement peut être téléchargé à l'adresse [{{#var:url_testbinzip}}OpenSim-LastAutoBuild.zip]
+
Si vous effectuez une mise à jour à partir d'une version précédente d'OpenSimulator, nous vous recommandons fortement de commencer par les fichiers de configuration par défaut et de transférer toutes les modifications que vous avez apportées à votre ancienne version d'OpenSimulator.
  
* Pour compiler OpenSimulator vous-même voir [[Build Instructions/fr]]
+
Vous pouvez télécharger cette version d'OpenSimulator à partir de [[Download|Télécharger]].
 
+
Remarque :  en raison du travail de développement et de traduction en cours, il se peut que les informations qui suivent soient incomplètes ou qu'elles contiennent quelques erreurs. À utiliser avec précaution.  
+
 
+
= Géneral =
+
 
   
 
   
 
Voir aussi [http://opensimulator.org/wiki/0.9.1.1_Release/fr  Notes de version 0.9.1.1]
 
Voir aussi [http://opensimulator.org/wiki/0.9.1.1_Release/fr  Notes de version 0.9.1.1]
 +
 +
Date de version : 5-Dec-2021
  
 
= Problèmes connus =  
 
= Problèmes connus =  
 +
 
La gestion de l'environnement d'une région change et est remplacée par un système unique.<br>
 
La gestion de l'environnement d'une région change et est remplacée par un système unique.<br>
 
Dans les versions précédentes LightShare et WindLight fonctionnaient côte à côte, chaque processus ayant son propre mode de stockage de données et ses propres protocoles de communication, avec parfois des résultats contradictoires.<br>
 
Dans les versions précédentes LightShare et WindLight fonctionnaient côte à côte, chaque processus ayant son propre mode de stockage de données et ses propres protocoles de communication, avec parfois des résultats contradictoires.<br>
 
Les nouveaux viewers introduisent désormais des fonctionnalités d'environnement étendues, c'est pourquoi  la version 0.9.2 utilise maintenant une représentation interne plus adaptée à ces nouvelles fonctionnalités. Cette nouvelle représentation est automatiquement convertie vers et depuis LightShare ou Windlight selon les besoins.<br>
 
Les nouveaux viewers introduisent désormais des fonctionnalités d'environnement étendues, c'est pourquoi  la version 0.9.2 utilise maintenant une représentation interne plus adaptée à ces nouvelles fonctionnalités. Cette nouvelle représentation est automatiquement convertie vers et depuis LightShare ou Windlight selon les besoins.<br>
Le code de région informera les viewers plus anciens sur l'environnement des parcelles mais pas par hauteur d'environnement (traduit de "but not per altitude environment.").
+
Le code de région informera les anciens viewers sur l'environnement des parcelles mais pas sur l'environnement par altitude.
 
* LightShare ne dispose plus de son propre protocole de communication. Ce système était déjà obsolète, il est donc inutile de demander aux développeurs des viewers de continuer à le maintenir. Par conséquent, certains viewers peuvent ne plus détecter les changements d'environnement d'une région effectués par d'autres utilisateurs ou via un script. Cela inclut également les changements à l'entrée ou à la sortie d'une parcelle avec son propre environnement. (Firestorm ou Dayturn permettront de voir ces changements, Singularity ne le peremettra pas par exemple). Ainsi, LightShare ne se résume plus qu'à une fonctionnalité scriptée. Cette fonctionnalité ne prend en charge que son sous-ensemble original de paramètres d'environnement. De nouvelles méthodes de remplacement pourraient être ajoutées à l'avenir, ce qui  rendrait LightShare définitivement obsolète.  
 
* LightShare ne dispose plus de son propre protocole de communication. Ce système était déjà obsolète, il est donc inutile de demander aux développeurs des viewers de continuer à le maintenir. Par conséquent, certains viewers peuvent ne plus détecter les changements d'environnement d'une région effectués par d'autres utilisateurs ou via un script. Cela inclut également les changements à l'entrée ou à la sortie d'une parcelle avec son propre environnement. (Firestorm ou Dayturn permettront de voir ces changements, Singularity ne le peremettra pas par exemple). Ainsi, LightShare ne se résume plus qu'à une fonctionnalité scriptée. Cette fonctionnalité ne prend en charge que son sous-ensemble original de paramètres d'environnement. De nouvelles méthodes de remplacement pourraient être ajoutées à l'avenir, ce qui  rendrait LightShare définitivement obsolète.  
 
Le rendu de l'environnement d'une région dépend encore beaucoup du modèle, de la version ou des options graphiques du viewer et se transformera toujours de la même façon pour le même ensemble de paramètres. Mais, il y a une différence majeure que les concepteurs d'environnement doivent prendre en compte, il faudra penser aux deux types de visiteurs, ceux avec un viewer de nouvelle génération avec les nouvelles fonctionnalités et ceux ayant des viewers de versions plus anciennes avec seulement Windlight. <br>   
 
Le rendu de l'environnement d'une région dépend encore beaucoup du modèle, de la version ou des options graphiques du viewer et se transformera toujours de la même façon pour le même ensemble de paramètres. Mais, il y a une différence majeure que les concepteurs d'environnement doivent prendre en compte, il faudra penser aux deux types de visiteurs, ceux avec un viewer de nouvelle génération avec les nouvelles fonctionnalités et ceux ayant des viewers de versions plus anciennes avec seulement Windlight. <br>   
 
Une transposition parfaite n'est bien sûr pas possible et peut donner de mauvais résultats.
 
Une transposition parfaite n'est bien sûr pas possible et peut donner de mauvais résultats.
* Les nouveaux environnements des régions doivent être créés avec l'éditeur pourvu des fonctionnalités étendues, mais vérifiez avec la version ancienne d'un viewer si les visiteurs peuvent toujours l'utiliser. <br>
+
* Les nouveaux environnements des régions doivent être créés avec l'éditeur pourvu des fonctionnalités étendues,  mais testés avec d'autres viewers, en particulier les anciennes versions, les utilisateurs peuvent toujours les utiliser. <br>
* Il faut vérifier si l'asset 3a367d1c-bef1-6d43-7595-e88c1e3aadb3 est une véritable texture transparente. Si ce n'est pas le cas, il faudra la remplacer. Elle devra également être supprimée de tous les caches des régions conservées (dans bin/assetcache/3a3) (ou voir la commande de console fcache deletedefaultassets ou même fcache cachedefaultassets) et du cache des viewers. Ensuite, assurez-vous que les viewers se connectent à une grille/région mise à jour. La copie fournie sur les versions précédentes n'était pas une véritable texture transparente.
+
* Il faut vérifier si l'asset 3a367d1c-bef1-6d43-7595-e88c1e3aadb3 est une véritable texture transparente. Si ce n'est pas le cas, il faudra la remplacer. (Remarque : ce remplacement est  automatique si vous utilisez les services d'assets de base, mais si vous avez votre propre version des services d'assets, vous devez le faire manuellement). Elle devra également être supprimée de tous les caches des régions conservées (dans bin/assetcache/3a3) (ou voir la commande de console fcache deletedefaultassets ou même fcache cachedefaultassets) et du cache des viewers. Ensuite, assurez-vous que les viewers se connectent à une grille/région mise à jour. La copie fournie sur les versions précédentes n'était pas une véritable texture transparente.
 +
 
 +
* Le moteur de script par défaut est maintenant YEngine. Si vous avez des problèmes avec les scripts, corrigez-les. Si vous ne pouvez pas les corriger, changez le moteur par défaut de opensim.ini en XEngine, mettez Enable à false sur [YEngine] et Enable à true sur [XEngine]. Contrairement à XEngine, YEngine limite l'utilisation de la pile et du tas de mémoire. Vous devrez peut-être modifier les paramètres ScriptStackSize et/ou ScriptHeapSize.
 +
* Sur les nouveaux simulateurs Standalones, assurez-vous d'ajouter votre région dans la section [GridService] de config-include/StandaloneCommon.ini. Par exemple, pour la région "Ma Region", il devrait y avoir Region_Ma_Region = "DefaultRegion, FallbackRegion" ( c'est-à-dire qu'il faut commencer par Region_ et remplacer les espaces dans le nom par _ ).
 +
* Sur les grilles, assurez-vous que vous avez au moins une région avec les flags DefaultRegion, DefaultHGRegion (pas nécessairement les mêmes régions) sur des entrées similaires dans la section [GridService] de Robust.ini.
  
 
= Conditions =
 
= Conditions =
Line 31: Line 35:
 
* Au moins Mono 5.x sous Mono (Linux ou Mac).
 
* Au moins Mono 5.x sous Mono (Linux ou Mac).
  
En raison de la renumérotation de la migration de la base de données qui a eu lieu à la version 0.9.0.0, si vous mettez à jour à partir d'une version d'OpenSimulator antérieure à la 0.8.2.1, vous DEVEZ d'abord mettre à jour vers la *0.8.2.1* puis procéder directement à la mise à jour vers la version 0.9.2.0. Voir 0.9.0.0_Release/fr#Version pivot: 0.8.2.1 pour plus de conseils.  
+
En raison de la renumérotation de la migration de la base de données qui a eu lieu à la version 0.9.0.0, si vous mettez à jour à partir d'une version d'OpenSimulator antérieure à la 0.8.2.1, vous DEVEZ d'abord mettre à jour vers la *0.8.2.1* puis procéder directement à la mise à jour vers la version 0.9.2.0. Voir [[0.9.0.0_Release/fr#Version pivot: 0.8.2.1]] pour plus de conseils.
 +
 
 +
Le support expérimental de .NET Framework 4.8 (et Visual Studio 2019/2022) est fourni via runprebuild19.exe ou runprebuild19.sh.
  
 
= Changements et corrections =
 
= Changements et corrections =
* La gestion de l'environnement des régions a été modifiée pour prendre en charge les nouvelles fonctionnalités des viewers (voir ci-dessus).
+
* La gestion de l'environnement des régions a été modifiée pour prendre en charge les nouvelles fonctionnalités des viewers (EEP dans la terminologie du  viewer)(voir les problèmes connus ci-dessus).
* Modification du mécanisme de lecture de la section OSSL d'OpenSim.ini avec l'utilisation d'un fichier config-include/osslDefaultEnable.ini suivie ensuite par le chargement de configuration personnalisée via le fichier config-include/osslEnable.ini.  
+
* Modification du mécanisme de lecture de la section OSSL d'OpenSim.ini avec l'utilisation d'un fichier config-include/osslDefaultEnable.ini suivie ensuite par le chargement de configuration personnalisée via le fichier config-include/osslEnable.ini. Notez également que le nom de la section est maintenant [OSSL]. Veuillez modifier vos fichiers OpenSim.ini et config-include/osslEnable.ini en conséquence en utilisant les exemples  OpenSim.ini.example et configo-nclude/osslEnable.ini.example.
Notez également que le nom de la section est maintenant [OSSL]. Veuillez modifier vos fichiers OpenSim.ini et config-include/osslEnable.ini en conséquence en utilisant les exemples  OpenSim.ini.example et configo-nclude/osslEnable.ini.example.
+
* Ajout de nouvelles fonctions de script pour les nouvelles fonctionnalités d'environnement et autres fonctionnalités [[osGetSitActiveRange]], [[osGetLinkSitActiveRange]], [[osGetStandTarget]], [[osGetLinkStandTarget]], [[osSetSitActiveRange]], [[osSetLinkSitActiveRange]], [[osSetStandTarget]], [[osSetLinkStandTarget]], .( voir [[OSSL Implemented|Fonctions OSSL]] )
* Ajout de nouvelles fonctions de script pour les nouvelles fonctionnalités de l'environnement et autres fonctionnalités [[osGetSitActiveRange]], [[osGetLinkSitActiveRange]], [[osGetStandTarget]], [[osGetLinkStandTarget]], [[osSetSitActiveRange]], [[osSetLinkSitActiveRange]], [[osSetStandTarget]], [[osSetLinkStandTarget]], ....
+
* Suppression du support obsolète pour SimianGrid. Simian était une alternative web/php à Robust (https://code.google.com/archive/p/openmetaverse & https://github.com/openmetaversefoundation).
* Suppression du support obsolète pour SimianGrid. Simian était une alternative web/php à Robust (https://code.google.com/archive/p/openmetaverse).
+
* Maintenant, les NPC sont activés par défaut et ne comptent plus dans la limite du nombre d'agent car à présent,  ils ont leur propre limite.
 +
*[[YEngine]] devient le moteur de script par défaut.
 +
* Certaines conversion de type (cast) implicites de script ont été modifiées, nécessitant un conversion de type explicite pour éviter les erreurs de codage. Cela concerne principalement les conversions de type pour les entiers et les flottants. Par exemple, llAbs ne permet plus les flottants, utilisez llFabs à la place.
 +
* Cette version permet seulement la connexion à la région demandée, si elle est en ligne, ou à une région en ligne avec le flag DefaultRegion  (DefaultHGRegion pour les connexions HG) ou FallbackRegion. Si aucune de ces régions n'est trouvée, la connexion à une région déconnectée envoie vers une région indéfinie, en ligne, avec un éventuel problème de confidentialité. Assurez-vous d'ajouter des régions avec de tels flags dans la section [GridService] de Robust.ini ou de config-include/StandaloneCommon.ini en mode standalone.
 +
 
 +
Les fichiers de configuration ont beaucoup changé. Veuillez utiliser ceux de cette version, modifiés selon vos besoins. N'utilisez que ceux que vous avez déjà comme référence.
  
 
=Remerciements =
 
=Remerciements =
Line 44: Line 55:
  
 
[[Category:Release Notes]]
 
[[Category:Release Notes]]
 +
[[Category:French Translations]]

Latest revision as of 08:04, 23 December 2021


Contents

[edit] Géneral

Bienvenue sur OpenSimulator version 0.9.2.0 Yeti, un environnement virtuel 3D multi-utilisateurs open-source et une plateforme de serveurs métavers.

OpenSimulator est un système très complexe. Divers scénarios d'utilisation (autonome, grille, hypergrille, etc.) en combinaison avec différentes dépendances (par exemple, différentes versions de mono sur Linux/Mac) peuvent parfois produire un comportement inattendu ou instable.

Si vous effectuez une mise à jour à partir d'une version précédente d'OpenSimulator, nous vous recommandons fortement de commencer par les fichiers de configuration par défaut et de transférer toutes les modifications que vous avez apportées à votre ancienne version d'OpenSimulator.

Vous pouvez télécharger cette version d'OpenSimulator à partir de Télécharger.

Voir aussi Notes de version 0.9.1.1

Date de version : 5-Dec-2021

[edit] Problèmes connus

La gestion de l'environnement d'une région change et est remplacée par un système unique.
Dans les versions précédentes LightShare et WindLight fonctionnaient côte à côte, chaque processus ayant son propre mode de stockage de données et ses propres protocoles de communication, avec parfois des résultats contradictoires.
Les nouveaux viewers introduisent désormais des fonctionnalités d'environnement étendues, c'est pourquoi la version 0.9.2 utilise maintenant une représentation interne plus adaptée à ces nouvelles fonctionnalités. Cette nouvelle représentation est automatiquement convertie vers et depuis LightShare ou Windlight selon les besoins.
Le code de région informera les anciens viewers sur l'environnement des parcelles mais pas sur l'environnement par altitude.

  • LightShare ne dispose plus de son propre protocole de communication. Ce système était déjà obsolète, il est donc inutile de demander aux développeurs des viewers de continuer à le maintenir. Par conséquent, certains viewers peuvent ne plus détecter les changements d'environnement d'une région effectués par d'autres utilisateurs ou via un script. Cela inclut également les changements à l'entrée ou à la sortie d'une parcelle avec son propre environnement. (Firestorm ou Dayturn permettront de voir ces changements, Singularity ne le peremettra pas par exemple). Ainsi, LightShare ne se résume plus qu'à une fonctionnalité scriptée. Cette fonctionnalité ne prend en charge que son sous-ensemble original de paramètres d'environnement. De nouvelles méthodes de remplacement pourraient être ajoutées à l'avenir, ce qui rendrait LightShare définitivement obsolète.

Le rendu de l'environnement d'une région dépend encore beaucoup du modèle, de la version ou des options graphiques du viewer et se transformera toujours de la même façon pour le même ensemble de paramètres. Mais, il y a une différence majeure que les concepteurs d'environnement doivent prendre en compte, il faudra penser aux deux types de visiteurs, ceux avec un viewer de nouvelle génération avec les nouvelles fonctionnalités et ceux ayant des viewers de versions plus anciennes avec seulement Windlight.
Une transposition parfaite n'est bien sûr pas possible et peut donner de mauvais résultats.

  • Les nouveaux environnements des régions doivent être créés avec l'éditeur pourvu des fonctionnalités étendues, mais testés avec d'autres viewers, en particulier les anciennes versions, les utilisateurs peuvent toujours les utiliser.
  • Il faut vérifier si l'asset 3a367d1c-bef1-6d43-7595-e88c1e3aadb3 est une véritable texture transparente. Si ce n'est pas le cas, il faudra la remplacer. (Remarque : ce remplacement est automatique si vous utilisez les services d'assets de base, mais si vous avez votre propre version des services d'assets, vous devez le faire manuellement). Elle devra également être supprimée de tous les caches des régions conservées (dans bin/assetcache/3a3) (ou voir la commande de console fcache deletedefaultassets ou même fcache cachedefaultassets) et du cache des viewers. Ensuite, assurez-vous que les viewers se connectent à une grille/région mise à jour. La copie fournie sur les versions précédentes n'était pas une véritable texture transparente.
  • Le moteur de script par défaut est maintenant YEngine. Si vous avez des problèmes avec les scripts, corrigez-les. Si vous ne pouvez pas les corriger, changez le moteur par défaut de opensim.ini en XEngine, mettez Enable à false sur [YEngine] et Enable à true sur [XEngine]. Contrairement à XEngine, YEngine limite l'utilisation de la pile et du tas de mémoire. Vous devrez peut-être modifier les paramètres ScriptStackSize et/ou ScriptHeapSize.
  • Sur les nouveaux simulateurs Standalones, assurez-vous d'ajouter votre région dans la section [GridService] de config-include/StandaloneCommon.ini. Par exemple, pour la région "Ma Region", il devrait y avoir Region_Ma_Region = "DefaultRegion, FallbackRegion" ( c'est-à-dire qu'il faut commencer par Region_ et remplacer les espaces dans le nom par _ ).
  • Sur les grilles, assurez-vous que vous avez au moins une région avec les flags DefaultRegion, DefaultHGRegion (pas nécessairement les mêmes régions) sur des entrées similaires dans la section [GridService] de Robust.ini.

[edit] Conditions

OpenSimulator 0.9.2.0 requiert :

  • Au moins .NET Framework 4.6 sous Windows.
  • Au moins Mono 5.x sous Mono (Linux ou Mac).

En raison de la renumérotation de la migration de la base de données qui a eu lieu à la version 0.9.0.0, si vous mettez à jour à partir d'une version d'OpenSimulator antérieure à la 0.8.2.1, vous DEVEZ d'abord mettre à jour vers la *0.8.2.1* puis procéder directement à la mise à jour vers la version 0.9.2.0. Voir 0.9.0.0_Release/fr#Version pivot: 0.8.2.1 pour plus de conseils.

Le support expérimental de .NET Framework 4.8 (et Visual Studio 2019/2022) est fourni via runprebuild19.exe ou runprebuild19.sh.

[edit] Changements et corrections

  • La gestion de l'environnement des régions a été modifiée pour prendre en charge les nouvelles fonctionnalités des viewers (EEP dans la terminologie du viewer)(voir les problèmes connus ci-dessus).
  • Modification du mécanisme de lecture de la section OSSL d'OpenSim.ini avec l'utilisation d'un fichier config-include/osslDefaultEnable.ini suivie ensuite par le chargement de configuration personnalisée via le fichier config-include/osslEnable.ini. Notez également que le nom de la section est maintenant [OSSL]. Veuillez modifier vos fichiers OpenSim.ini et config-include/osslEnable.ini en conséquence en utilisant les exemples OpenSim.ini.example et configo-nclude/osslEnable.ini.example.
  • Ajout de nouvelles fonctions de script pour les nouvelles fonctionnalités d'environnement et autres fonctionnalités osGetSitActiveRange, osGetLinkSitActiveRange, osGetStandTarget, osGetLinkStandTarget, osSetSitActiveRange, osSetLinkSitActiveRange, osSetStandTarget, osSetLinkStandTarget, ….( voir Fonctions OSSL )
  • Suppression du support obsolète pour SimianGrid. Simian était une alternative web/php à Robust (https://code.google.com/archive/p/openmetaverse & https://github.com/openmetaversefoundation).
  • Maintenant, les NPC sont activés par défaut et ne comptent plus dans la limite du nombre d'agent car à présent, ils ont leur propre limite.
  • YEngine devient le moteur de script par défaut.
  • Certaines conversion de type (cast) implicites de script ont été modifiées, nécessitant un conversion de type explicite pour éviter les erreurs de codage. Cela concerne principalement les conversions de type pour les entiers et les flottants. Par exemple, llAbs ne permet plus les flottants, utilisez llFabs à la place.
  • Cette version permet seulement la connexion à la région demandée, si elle est en ligne, ou à une région en ligne avec le flag DefaultRegion (DefaultHGRegion pour les connexions HG) ou FallbackRegion. Si aucune de ces régions n'est trouvée, la connexion à une région déconnectée envoie vers une région indéfinie, en ligne, avec un éventuel problème de confidentialité. Assurez-vous d'ajouter des régions avec de tels flags dans la section [GridService] de Robust.ini ou de config-include/StandaloneCommon.ini en mode standalone.

Les fichiers de configuration ont beaucoup changé. Veuillez utiliser ceux de cette version, modifiés selon vos besoins. N'utilisez que ceux que vous avez déjà comme référence.

[edit] Remerciements

Un grand, grand merci à tous les développeurs (et leurs chats), testeurs et membres de la communauté qui ont contribué à cette version et qui aident à l'utilisation d'OpenSimulator en général. Votre travail acharné rend tout cela possible.

Personal tools
General
About This Wiki