Troubleshooting/fr

Retour au Sommaire

Cette page donnne des configurations specifiques a certains systèmes qui peuvent etre utiles et des conseils pour des problèmes pouvant être rencontrés.

Conseils généraux
Si OpenSimulator démarre jusqu'au stade où vous pouvez taper des commandes dans la console de la région, alors vous pouvez connaître la configuration du simulateur en utilisant les commandes "config get" et "config save" comme détaillé à la page Server Commands. (et en tapant help dans la console). Cela peut être utile pour supprimer une erreur de configuration lors du diagnostic de certains problèmes.

Assurez-vous également que vous exécutez les bonnes versions du runtime .NET et de la base de données. Voir la Configuration pour avoir des informations sur les versions des bases de données. Vous devez aussi utiliser .NET 3.5 ou plus. .NET 2.0 ne possède pas de System.Core. Si vous utilisez Windows .NET, téléchargez simplement la mise à jour 3.5 ou 4. Si vous utilisez Mono, vous devrez mettre à jour votre version de Mono.

CentOS 5 (64bit)
If you are running Mono 2.2 compiled from source on CentOS 5.2 64bit (not sure if it applies to other scenarios as well), you need to take these steps: sudo yum install libgdiplus sudo yum install libexif sudo ln -s /usr/lib64/libgdiplus.so.0 /usr/lib64/libgdiplus.so ldconfig

Cela m'a finalement permis de faire tourner OpenSimulator sans erreurs, et même de me connecter à d'autres grilles.

Gentoo
certaines dependances de Mono et le dernier Mono devraient utiliser les packages masqués de "~x86" (en assumant que votre plateforme soit un x86, le changement peut etre effectué pour apparaitre comme ex:"~amd64" pour 64bits). Vous pouvez verifier pour le parametre USE avec:

ACCEPT_KEYWORDS="~x86" emerge -vp subversion nant mono libgdiplus

Ensuite installez avec:

ACCEPT_KEYWORDS="~x86" emerge subversion nant mono libgdiplus

N.B: The ACCEPT_KEYWORDS="~x86" peut etre changé dans le fichier Gentoo /etc/make.conf, mais ceci change les valeurs dans testing/unstable, en l'utilisant au debut de la ligne de commande seulement pour le process emergeant

Mac OS X
Si vous obtenez des erreurs concernant le framework 2.0 qui n'est pas supporté, vous devrez peut-être mettre à jour votre chemin pkg-config. Par exemple, vous pouvez le définir dans ~/.bash_profile :

Par exemple, vous pouvez le définir dans ~/.bash_profile: export PKG_CONFIG_PATH="/Library/Frameworks/Mono.framework/Versions/Current/lib/pkgconfig/:${PKG_CONFIG_PATH}"

Erreurs de connexion MySQL après environ 6-8 heures
MySQL dispose d'un délai d'attente qui interrompt la connexion après 28 800 secondes (8 heures) d'inactivité, ce qui entraînera probablement un échec de la connexion après que le serveur utilisateur soit resté inactif pendant une longue période. Si vous rencontrez ce problème, augmentez le délai d'attente à quelque chose de plus grand, comme 604800 (1 semaine) ou 31536000 (1 an). Dans la console mysql, tapez :

set global wait_timeout=604800;

System.DllNotFoundException: gdiplus.dll
D'abord verifiez d'etre sur que libgdiplus.so est connu en tant que gestionnaire de lisaisons dynamique:

/sbin/ldconfig -p | grep libgdiplus

Si rien n'est trouvé, verifiez bien que le dossier libgdiplus.so existe ou bien dans votre variable LD_LIBRARY_PATH ou listé dans un fichier *.conf file (e.g., gdiplus.conf) dans /etc/ld.so.conf.d/. Ensuite lancez ldconfig pour mettre a jour le cache. Ensuite, il devrait etre capable de trouver la librairie.

Vous devriez toujours avoir l'erreur ci dessus, cependant depuis que libgdiplus depend aussi d'autres librairies dynamiques, et si elles ont echoué au lancement, libgdiplus echouera. Pour tester cela, lancez OpenSimulator avec les informations de debug activées:

MONO_LOG_LEVEL=debug mono OpenSim.exe

Sous Mac OS X - vérifiez que le fichier suivant existe... /opt/local/lib/libgdiplus.dylib si c'est le cas, en tant qu'utilisateur root, éditez le fichier /opt/local/etc/mono/config et ajoutez la ligne suivante



MySql.Data.MySqlClient.MySqlException : La table 'opensim.UserAccounts' n'existe pas.
Environnement : Opensim Server 0.7.0.2 derrière Linux Ubuntu 8.0.4 avec mono 2.8 et MySQL 5.0 installés.

Quand vous migrez une base de données Opensim 0.7 fonctionnant avec MySQL 5.0 sous Windows vers Linux, lors de la connexion d'un utilisateur dans le serveur Opensim, vous pouvez recevoir l'exception suivante dans la console du serveur Opensim :

Dans le client, vous recevez également l'erreur suivante :

Login Failed Error generating Login Response

Cette exception est causée par la façon dont MySQL stocke les noms des tables. Sur un serveur MySQL Windows, les noms des tables ne sont pas sensibles à la casse, mais toutes les tables dans MySQL Linux sont sensibles à la casse par défaut, donc quand OpenSimulator veut les trouver dans la base de données avec des noms en premières majuscules, il ne peut pas les trouver.

Une solution serait de changer les noms des tables requises par opensim (ALTER TABLE's), mais la solution la plus propre est de changer la configuration de MySQL, en vérifiant l'option "lower_case_sensitive = 1" dans le fichier "/etc/mysql/my.cnf", section [mysqld].

Pour MySQL


 * 1) sudo nano /etc/mysql/my.cnf

.......................... [mysqld] .......................... lower_case_sensitive=1 ..........................

Pour MariaDB


 * 1) sudo nano /etc/mysql/mariadb.conf.d/50-server.cnf

.......................... [mysqld] .......................... lower_case_table_names=1

Cela permet à MySQL de traduire automatiquement les noms de tables en minuscules. Après avoir redémarré le serveur MySQL et OpenSim, les tables sont chargées sans problème.

Attention : n'essayez pas d'effacer la table migration pour forcer opensim à re-migrer votre base de données, car 'cela provoquera un dégât sur votre base de données.

Erreurs dues à des migrations de données incomplètes
Cela peut se produire lors des mises à jour de version si, pour une raison quelconque, une migration de base de données échoue lorsqu'il y a un changement dans la façon dont OpenSimulator stocke les données.

Vous pouvez voir des erreurs sur la console OpenSimulator comme :

[LLOGIN SERVICE]: Exception processing login for [username]: MySql.Data.MySqlClient.MySqlException: Table 'opensim.UserAccounts' doesn't exist at MySql.Data.MySqlClient.MySqlStream.OpenPacket [0x00000] at MySql.Data.MySqlClient.NativeDriver.ReadResult (System.UInt64&amp; affectedRows, System.Int64&amp; lastInsertId) [0x00000] at MySql.Data.MySqlClient.MySqlDataReader.GetResultSet [0x00000] at MySql.Data.MySqlClient.MySqlDataReader.NextResult [0x00000]    at MySql.Data.MySqlClient.MySqlStream.OpenPacket  [0x00000] at MySql.Data.MySqlClient.NativeDriver.ReadResult (System.UInt64&amp; affectedRows, System.Int64&amp; lastInsertId) [0x00000] at MySql.Data.MySqlClient.MySqlDataReader.GetResultSet [0x00000] at MySql.Data.MySqlClient.MySqlDataReader.NextResult [0x00000]

Dans ce cas, la table "users" n'avait pas été migrée vers la table "UserAccounts", comme l'attendait OpenSimulator, ce qui a également entraîné l'erreur côté viewer :

Login Failed Error generating Login Response J'ai résolu le problème en corrigeant les permissions du système de fichiers qui causaient l'échec de la migration (sur ma machine Linux, '/var/lib/mysql/...' s'était embrouillé), puis en supprimant la table de migration et en relançant le serveur (d'après les avertissements de migration [non-critical] rencontrés, il y avait probablement un moyen plus précis de le faire, mais j'avais tout sauvegardé et j'ai fait ça à la va-vite). À part la perte des références des données de terrain et des données de silouhettesd'habillage et d'attachement (facilement restaurées dans la simulation), tout est résolu pour moi.

Lors de l'installation de mono ou libgdiplus0, il se peut que la dépendance libexif.so.9 soit manquante
Ceci a été indiqué pour Centos5 mais peut se produire sur d'autres systèmes, téléchargez ftp://rpmfind.net/linux/conectiva/snapshot/i386/RPMS.extra/libexif9-0.5.12-47547cl.i386.rpm et installez pour résoudre le problème. Vous pourrez maintenant installer mono (si tout va bien).

The assembly mscorlib.dll was not found or could not be loaded
Ceci indique qu'il vous manque une des librairies mscor qui viennent avec nant. Ceci est facilement resolu en recuperant NAnt, qui est fourni avec les version 1.0 et 2.0 de la librairie necessaire.

apt-get install nant

External Program Failed: /usr/lib/pkgconfig/../../lib/mono/2.0/gmcs.exe
Ceci est rapidement reparé en recuperant mono-gmcs.

apt-get install mono-gmcs

The type or namespace name JScript does not exist in the namespace Microsoft
Notez que cela dit Jscript en boucle. Un indice peut etre ?

apt-get install mono-mjs libmono-microsoft8.0-cil

Sur Fedora et OpenSUSE, le paquetage nécessaire est "mono-jscript".

The type or namespace name Tcp does not exist in the namespace System.Runtime.Remoting.Channels
Celui ci est pris en compte avec une rapide installation:

apt-get install libmono-system-runtime2.0-cil

error while loading shared libraries: libgthread-2.0.so.0: cannot open shared object file
Si vous demarrez un systèeme de base Debian comme nous avons fait en haut de cette page, mais à la place d'utiliser la version apt de mono vous utilisez l'installeur depuis leur site web, alors vous pouvez rencontrer ce probleme.

Après avoir obtenu le fichier .bin depuis http://www.mono-project.com/Downloads, et l'avoir installé en suivant les instructions, en lançant 'mono --version' vous aurez ce message. Vous devez installer libglib2.0-0.

apt-get install libglib2.0-0

The current runtime framework 'mono-2.0' is not correctly configured in the NAnt configuration file.
Celle ci semble être réparé en récupérant la version apt de nant.

apt-get install nant

Ceci peut aussi etre dû à pkg-config qui n'est pas capable de localiser le fichier mono.pc. Ajoutez le dossier qui contient ce fichier dans votre variable d'environnement PKG_CONFIG_PATH devrait resoudre le problème.

Problèmes de réseau et de configuration
Voir aussi la page wiki :
 * Network Settings
 * Firewall Settings
 * Configuration

Vous pouvez vous identifier, mais pas vous connecter à une région à partir d'un client distant.
Regardez dans votre dossier OpenSimulator/bin/Regions :
 * 1) Essayez 0.0.0.0 pour l'InternalAddress dans votre fichier Regions.ini.
 * 2) ExternalHostName=127.0.0.1 sera nécessaire pour changer son nom en nom DNS évaluable tel que "opensim.example-host.com" ou "71.6.131.152" (votre ip accessible au public).

Si vous avez toujours le même problème, il peut s'agir d'un problème de pare-feu. Vérifiez si votre pare-feu est actif et configurez-le. Voir Firewall Settings pour des instructions détaillées.

J'obtiens un délai d'attente pendant handshake (établissement d'une liaison) de la région

 * Avez-vous indiqué l'IP correcte dans vos fichiers de configuration de Regions\* ? Celle-ci doit être accessible depuis la machine du viewer.
 * Avez-vous plusieurs interfaces sur le serveur qui exécute OpenSim ? OpenSimulator ne lie pas les paquets UDP sortants à une IP spécifique, son IP par défaut pour vous joindre sera celle avec laquelle la région répondra à l'UDP. Si vous avez configuré la région pour une autre IP, vous obtiendrez un timeout pendant la connexion.

Je ne peux pas me connecter à mon OpenSimulator

 * Voir Connecting ou Firewall Settings

Mon viewer est constamment déconnectée ou le mouvement de l'avatar est très mauvais (élastique, lag, etc.).
D'une manière générale, cela se produit soit parce que


 * 1) le viewer est surchargé
 * 2) Le simulateur a un problème ou est surchargé.
 * 3) la connexion réseau entre le viewer et le serveur a une bande passante insuffisante, une latence très élevée ou une perte de paquets significative.

La façon la plus simple de diagnostiquer le premier problème est de se connecter à des régions similaires sur d'autres grilles avec le même viewer et de voir si les mêmes problèmes se produisent.

Les problèmes de simulateur sont plus difficiles à diagnostiquer du seul côté ddu viewer, bien que l'on puisse regarder les monitorage côté client pour savoir si le simulateur est surchargé ou a d'autres problèmes.

La connexion réseau peut également être difficile à tester sans la coopération des opérateurs du serveur et du viewer. Si l'on peut compter sur la coopération des deux, on peut utiliser un programme externe tel que lperf en mode UDP pour effectuer des tests de base sur la connexion. iperf est disponible pour Windows, Mac et Linux. Si ces tests UDP révèlent une instabilité élevée (écart important par rapport à la latence moyenne de la connexion) ou une perte de paquets significative, cela posera des problèmes pour la connexion du spectateur au simulateur.

Je ne trouve aucun fichier de compilation ou de fichier solution
runprebuild.bat runprebuild.sh
 * Si vous êtes sous Windows, exécutez
 * sous Linux/Mac/FreeBSD, exécutez

VS2005 ne veut pas ouvrir le fichier .sln

 * Essayez d'exécuter VS2005 C#. Vous utilisez probablement VS2005 C++. Ceci est un projet C#.

L'exécution d'OpenSim.exe à partir d'un shell Cygwin refuse l'accès à certaines dll

 * Faites un 'cd bin' suivi de 'chmod a+x *' pour rendre tous les fichiers dll exécutables.

Comment faire une recompilation propre ? (par exemple, après 'APPLICATION EXCEPTION DETECTED' ,après une recompilation avec des sources mises à jour)
Lorsque vous compilez à partir du code source, puis mettez à jour le code source, recompilez et essayez de l'exécuter, vous obtenez d'étranges exceptions d'exécution comme celle-ci :

APPLICATION EXCEPTION DETECTED: System.UnhandledExceptionEventArgs Exception: System.MissingMethodException

Lorsque vous compilez la source, il est "compilée" en fichiers exécutables appelés "dlls" ou Dynamic Link Libraries. Ces fichiers portent l'extension .dll, ils sont ajoutés à votre installation locale et ne sont pas soumis au contrôle de la source. Lorsque nous changeons l'endroit où ces dlls sont créées, les "anciennes" dlls, issues des versions précédentes, seront toujours présentes. Le programme essaiera alors de charger ces anciens fichiers DLL, avec des résultats inattendus.

En général, l'un des correctifs suivants devrait résoudre le problème :
 * Faites un 'nant clean' si vous utilisez Nant, ou xbuild /t:clear ou msbuild /t:clean.
 * Supprimer le dossier bin/addin-db-002
 * Supprimez tous les OpenSim.*.dll (seulement les fichiers qui commencent par "OpenSim." et se terminent par ".dll", comme "OpenSim.Framework.dll") récursivement de votre répertoire d'installation. C'est ce que fait "nant clean" ci-dessus. Enfin, reconstruisez et exécutez.
 * Faites un checkout propre, construisez-le à partir de zéro, puis copiez tous les fichiers de données (*.db, *.ini) de votre ancienne installation, reconstruisez et exécutez.

Si tout le reste échoue, rejoignez le canal IRC #opensim, ou envoyez un email à la liste de diffusion opensim-users.

L'entrée console d'OpenSim.exe est brouillée (scramblée) lorsqu'elle est exécutée avec mono sous Windows
Ceci est dû au fait que OpenSimulator utilise une console modifiée qui émule le contrôle du curseur et l'aide contextuelle. Il est destiné à être utilisé sur la console _nix, donc si vous l'utilisez dans la console dos, cela se produit.

Essayez de commencer comme ça. Cela permet d'utiliser la console "basique" sans fonctionnalités supplémentaires. mono OpenSim.exe -console=basic

Exceptions dans la console
Voici une liste des exceptions que vous pouvez voir sur la console, ce qu'elles signifient et si elles posent problème.

System.DllNotFoundException: lib32/libopenjpeg-dotnet-2.1.3.0-dotnet-1-i686
'''Veuillez noter : openjpeg-dotnet doit maintenant être construit en utilisant le code du projet libopenmetaverse (d'où provient cette bibliothèque). La version dans opensim-libs est ancienne et ne fonctionnera plus.

Vous êtes sous FreeBSD, et la libopenjpeg-dotnet a besoin de quelques modifications pour fonctionner sur votre système


 * Allez à la page http://opensimulator.org/mantis/view.php?id=5916
 * Téléchargez les deux patchs spécifiques à FreeBSD (opensim-freebsd-patch-OpenMetaverseDllConfig et opensim-freebsd-patch-opj_malloc)

git clone git://opensimulator.org/git/opensim-libs cd opensim-libs/libomv-0.7.0/openjpeg-dotnet patch libopenjpeg/opj_malloc.h /path/to/downloaded/opensim-freebsd-patch-opj_malloc gmake cp -p libopenjpeg-dotnet-2.1.3.0-dotnet-1.so /opensim/installation/directory/bin/ cd /opensim/installation/directory/bin patch OpenMetaverse.dll.config /path/to/downloaded/opensim-freebsd-patch-OpenMetaverseDllConfig

System.DllNotFoundException: ./libopenjpeg-libsl-2.1.2.0.so
Vous êtes sous Linux, et la bibliothèque native libopenjpeg-libsl-2.1.2.0.so n'est pas compatible avec votre système pour l'une des raisons suivantes :
 * Vous avez un vieux processeur (libopenjpeg a été compilé avec des optimisations).
 * Vous êtes en mode 64 bits (aucune des librairies natives n'est construite pour 64 bits).

Vous pouvez reconstruire votre propre libopenjpeg à partir des sources, ou l'exécuter dans un environnement compatible. Vous pouvez le faire avec : git clone git://opensimulator.org/git/opensim-libs cd opensim-libs/openjpeg-libsl/ make
 * 1) (sous FreeBSD, utilisez gmake au lieu de make, mais vous voudrez probablement utiliser la correction libopenjpeg-mono à la place.

Puis copiez libopenjpeg-libsl-2.1.2.0.so dans le dossier bin d'OpenSimulator.

System.NullReferenceException at OpenSim.Region.Communications.Local.LocalLoginService.PrepareLoginToRegion
Votre premier démarrage d'OpenSimulator a échoué. Vous avez par exemple, donné un nom de domaine inexistant lorsque vous avez été invité à indiquer le nom de l'hôte externe de la région. Cela ne provoque qu'une initialisation partielle. Vous devez supprimer le dossier bin, faire une mise à jour svn, reconstruire et purger la base de données pour résoudre ce problème.

Exception: System.NotImplementedException: The requested feature is not implemented
Si votre exception commence comme ceci :

Vous avez probablement passé involontairement l'option --optimize=-all à mono. Le problème est que Mono compile dans une version "optimisée" des méthodes de la classe System.Threading.Interlocked ; ces optimisations sont faites en utilisant l'assembleur brut pour votre architecture (détecté automatiquement au moment de la construction). Lorsque vous passez --optimize=-all, le runtime détecte que ces fonctions sont optimisées, et les désactive. Ainsi, la prochaine fois qu'une classe essaiera d'appeler ces fonctions, le runtime constatera qu'il n'existe pas d'implémentation native de ces méthodes ! Ceci affecte presque toutes les primitives de synchronisation System.Threading. Puisque OpenSimulator s'appuie fortement sur les mécanismes de threading et de verrouillage, nous ne pouvons pas nous passer de cette fonctionnalité. Peut-être qu'une future version de Mono vous permettra de passer --optimize=-all, et de fournir une implémentation non optimisée (par exemple pthreads), plutôt que de lever une exception.

Si vous cherchez à déboguer un problème de bas niveau avec mono (comme une erreur dans le code natif), passer --optimize=-all n'est pas la bonne façon de procéder. Au lieu de cela, définissez la variable d'environnement MONO_LOG_LEVEL=debug et exécutez votre programme avec l'option --debug passée à mono. Vous pouvez également exécuter mono sous gdb, comme n'importe quel autre processus.

Command error: System.IO.FileNotFoundException: Could not load file or assembly 'System.Core, Version=3.5.0.0, culture=neutral,PublicKeyToken=b77a5c561934e089' or one of its dependencies
L'absence de System.Core indique que vous utilisez une ancienne version du runtime .NET.

Vous devez utiliser .NET 3.5 ou une version ultérieure. .NET 2.0 n'a pas de System.Core. Si vous utilisez Windows .NET, téléchargez simplement la mise à jour 3.5 ou 4. Si vous utilisez Mono, vous devrez mettre à jour votre version de Mono.

Disparition de prims à cause de doublons d'UUIDs
Ce problème se produit généralement lorsqu'un fichier save-xml/load-xml est chargé dans la même simulation sans utiliser le paramètre -newUID pour générer de nouveaux UUID pour les objets. Voir Server Commands pour des informations détaillées. ( load-xml -newUID ).Mais si cela ne fonctionne pas, l'autre moyen est de copier par décalage votre build et de le faire glisser en l'air... puis de supprimer celui en l'air, (qui est en fait la copie). Cela va générer de nouveaux UIDs sur tous vos prims... vous pouvez maintenant quitter ce build, et charger votre fichier load-xml original dans une autre région.

Pourquoi mes genoux sont-ils pliés lorsque je suis au repos ?
Cela semble être le résultat du moteur physique ODE sur les systèmes 64 bits. Une solution consiste à éditer OpenSim.ini et à modifier la ligne suivante : en
 * av_capsule_standup_tensor_linux = 550000
 * av_capsule_standup_tensor_linux = 1700000

Notez que cette ligne de code se trouve dans la section [ODEPhysicsSettings] de versions anciennes du fichier OpenSim.ini.

Mon avatar semble bouger sans cesse et s'envoler de temps en temps sans que je puisse l'arrêter
Cela est souvent dû à un ordinateur extrêmement surchargé ou à des problèmes de réseau (par exemple, une connexion au simulateur avec une bande passante trop faible ou une latence trop élevée).

En exécutant "show queues" depuis la console, vous obtiendrez la liste du nombre de paquets UDP qui ont dû être renvoyés au client. Si ce nombre représente un pourcentage élevé du total des paquets envoyés (par exemple, environ 10% ou plus), vous avez probablement l'un de ces deux problèmes.

Malheureusement, la seule solution consiste à améliorer l'ordinateur client ou à résoudre les problèmes de réseau. Les problèmes de réseau peuvent être nombreux et variés, de la bande passante disponible pour le serveur aux problèmes de certains routeurs wifi domestiques qui ne délivrent pas les paquets de données en temps voulu.

Lorsque je crée une nouvelle peau et une nouvelle silhouette, le système devient fou en créant constamment de nouveaux assets
Vous n'avez pas configuré de cache pour les ressources

Vous devez configurer soit le cache cenome, soit le cache flotsam

Sans cache d'assets, les assets temporaires ne peuvent pas être conservés, ce qui signifie qu'ils sont continuellement redemandés.

Copiez le fichier config-include/CenomeMemoryAssetCache.ini.example, ou le fichier flotsam correspondant, dans le fichier .ini, éditez-le et configurez-le en fonction de vos besoins, puis vérifiez GridCommon.ini ou StandaloneCommon.ini et décommentez la ligne correspondant à ce cache.

(standalone utilise par défaut cenome grid pour flotsam)

J'ai des problèmes pour visualiser la carte du monde

 * Cela peut se produire lors de l'exécution d'OpenSimulator sur un serveur Linux, à la fois en mode grille ou standalone.
 * Symptômes : lors de l'ouverture de la fenêtre de la carte du monde dans le SL-viewer, les sims ne sont pas affichés grahiquement dans la carte du monde, la console du serveur montre une erreur liée à openjpeg, la session en cours se fige....
 * Raison : votre tronc source svn ne possède pas la bonne (ou autre...) bibliothèque libopenjpeg-libsl</tt>.
 * Autre raison : le fichier "defaultstripe.png" n'existe pas dans le même dossier OpenSimulator, ou est corrompu.
 * Solution : obtenez le code le plus récent de opensim-libs, suivez les instructions pour libopenjpeg-mono ou libopenjpeg-libsl en fonction de vos messages d'erreur.
 * Recompilez et redémarrez OpenSimulator.

Je démarre la simulation et elle ne se connecte à aucune grille
Lorsqu'OpenSimulator est lancé pour la première fois, il a besoin d'être configuré.


 * Voir Configuration.

Ma grille fonctionne bien avec un utilisateur, mais lorsque deux utilisateurs se connectent en même temps, les deux se bloquent

 * Assurez-vous que vous avez export MONO_THREADS_PER_CPU="100" dans votre environnement.

Après environ 20 minutes, ma région commence à prendre 100% du processeur et la ou les régions se bloquent

 * Si vous avez mono 1.9.1 ou inférieur, mettez à jour vers mono 2.2.
 * Information ci-dessus est datée, en effet, actuellement, avec OpenSim 0.9.1 on utilise mono 5.12 ou supérieur.

Après avoir démarré OpenSimulator avec Hypergrid activé, mon inventaire ne se charge pas !

 * Si vous êtes en mode grille, vérifiez d'abord votre OpenSim.ini pour vous assurer que les noms ou adresses dns de vos serveurs de grille sont accessibles pour vous et le public.
 * Vérifiez les fichiers de configuration XML de vos serveurs UGAIM pour vous assurer que tout fonctionne à partir d'une adresse IP accessible au public.
 * Si c'est le cas et que vous devez changer vos adresses UGAIM, vous devrez exécuter quelques requêtes SQL rapides sur votre base de données afin de mettre à jour les comptes utilisateurs de votre grille pour qu'ils pointent vers les nouvelles adresses IP de votre UGAIM.

Connectez-vous à votre serveur sql et passez à la base de données de votre grille. Ce qui suit mettra à jour les URI d'inventaire et d'assets de vos utilisateurs après avoir modifié les adresses de vos services UGAIM dans les fichiers de configuration XML.

'''!!!!ATTENTION!!! - Soyez intelligent ! Faites toujours une sauvegarde de vos bases de données avant de faire des changements dans OpenSim ! - !!!!ATTENTION!!!!''' UPDATE users SET userInventoryURI="http://new.UGAIM.address:8004" WHERE userInventoryURI = "http://old.UGAIM.address:8004";

UPDATE users SET userAssetURI="http://new.UGAIM.address:8003" WHERE userAssetURI = "http://old.UGAIM.address:8003";
 * Si vous travaillez en mode standalone ... - Quelqu'un de familier avec le mode standalone veut-il compléter ceci ? -

Problèmes d'utilisation de OpenDynamicsEngine (ODE) de ubOde sur *nix
Si vous avez des problèmes pour utiliser OpenDynamicsEngine sur *nix, essayez de régler votre niveau de réserve de pile plus haut que le niveau par défaut avec la commande suivante ; ulimit -s 262144, ou éditez opensim.sh en changeant ulimit à cet endroit et exécutez-le pour démarrer OpenSimulator.

Exception et perte de la physique ODE (System.EntryPointNotFoundException : dSpaceLockQuery)
L'erreur suivante est généralement causée par l'utilisation d'une mauvaise version de libode :

Essayez d'abord de chercher dans votre système de fichiers pour voir si vous avez d'autres copies du moteur physique ode :

find / -name "libode.so"

Ensuite, assurez-vous que vous avez la dernière version.

Lors du chargement d'un OAR ou au démarrage du simulateur, il se bloque avec StackOverflowException
Cela peut se produire si un thread convertissant un script de LSL en C# manque de place sur la pile. Il affecte particulièrement les serveurs Windows 64 bits, mais pas les mêmes serveurs exécutant OpenSim.32BitLaunch.exe ou les serveurs Mono (32 ou 64 bits).

Si vous voulez trouver le script qui échoue, définissez

<logger name="OpenSim.Region.ScriptEngine.XEngine"> <level value="DEBUG"/>

au lieu de INFO au bas de OpenSim.exe.config.

Pour résoudre ce problème, augmentez le ThreadStackSize de 262144 dans la section [XEngine] d'OpenSim.ini.

J'obtiens "Primitive : Error compiling script : unknown char : . error" lors de la compilation du script
Lorsque vous essayez de compiler un script (en utilisant DotNetEngine ou XEngine), vous pouvez obtenir cette erreur :

Et dans la console :

Cela se produit sous linux lorsque vos locales ne sont pas définies par défaut ("C"). env LANG=C mono --debug OpenSim.exe export LC_ALL=C export LANG=C Je sais que c'est une façon horrible de configurer les locales sur une machine linux, mais cela fonctionne bien sur ma machine Linux From Scratch.
 * Vous pouvez vous référer à Mantis #2088 et Mantis #2015 pour une solution de contournement pour exécuter opensim.
 * Vous pouvez également modifier votre configuration locale. Voici ce que j'utilise dans mon '.bash_profile' :

Remarque : J'ai vu que Melanie a corrigé certaines parties du code source il y a quelques semaines pour éviter de tels problèmes.

J'obtiens "Primitive: Error compiling script: ApplicationName='gmcs', ..." lors de la compilation du script
Lorsque vous essayez de compiler un script (en utilisant DotNetEngine ou XEngine), vous obtenez une erreur du type :

D'autres fonctionnalités incluent la désactivation du "Touch" sur la molette du menu du clic droit.

Vous avez peut-être une installation mono cassée (c'est-à-dire gmcs pas installée sur une machine Ubuntu 8.10 Intrepid).

Vérifiez que mono-gmcs (sudo apt-get install mono-gmcs) est correctement installé.

J'obtiens "gmcs: Cannot find the specified file" lors de la compilation du script
Installez simplement le paquet "mono-gmcs" sur votre système. Voir Dependencies pour plus de détails.

Problèmes local
OpenSimulator moderne (après 0.7.3) devrait correctement définir la locale en_US pour toutes les sauvegardes de données, ce qui est nécessaire pour la compatibilité entre simulateurs. Cependant, si vous rencontrez des problèmes avec de grandes quantités de données corrompues, vous pouvez essayer de régler votre machine locale sur en_US et soumettre un rapport de bogue.

Questions relatives à l'Apparence
Voir Appearance Troubleshooting.

Retour au Sommaire