Fr/A local weather system: Difference between revisions

Jump to navigation Jump to search
m
no edit summary
mNo edit summary
mNo edit summary
Line 108: Line 108:
(devrait être écrit par quelqu'un qui connait les fonctions et limites du système multijoueurs)
(devrait être écrit par quelqu'un qui connait les fonctions et limites du système multijoueurs)


== Dévelopemment ==
== Développement ==


* Quelques utilisateurs ont affirmé avoir des problèmes en utilisant l'outil recommencer/nouveau lieu; le système de météo locale devrait enregistrer dans /sim/signals/* et se suspendre/remettre à zéro lui-même, de sorte que toutes les opérations soient correctement mises en pause. This may include releasing registered times and listeners, as well as terminating worker threads (once being used) [http://flightgear.org/forums/viewtopic.php?f=5&t=7358&st=0&sk=t&sd=a&start=165#p94765]
* Quelques utilisateurs ont affirmé avoir des problèmes en utilisant l'outil recommencer/nouveau lieu; le système de météo locale devrait enregistrer dans /sim/signals/* et se suspendre/remettre à zéro lui-même, de sorte que toutes les opérations soient correctement mises en pause. This may include releasing registered times and listeners, as well as terminating worker threads (once being used) [http://flightgear.org/forums/viewtopic.php?f=5&t=7358&st=0&sk=t&sd=a&start=165#p94765]
* Dynamiquement examiner les APIs FG/Nasal en faisant marcher le code responsable d'exceptions, peut aussi causer certaines impressions d'erreurs sur la console, cela serait une bonne idée d'exposer les variables à l'arbre de propriétés, de sorte que le système log peut quelques fois être dans de tels cas, c'est à dire en introduisant une priorité "nulle" ou "muette" : [http://flightgear.org/forums/viewtopic.php?f=5&t=7358&p=96439#p96370].
* Dynamiquement examiner les APIs FG/Nasal en faisant marcher le code responsable d'exceptions, peut aussi causer certaines impressions d'erreurs sur la console, cela serait une bonne idée d'exposer les variables à l'arbre de propriétés, de sorte que le système log peut quelques fois être dans de tels cas, c'est à dire en introduisant une priorité "nulle" ou "muette" : [http://flightgear.org/forums/viewtopic.php?f=5&t=7358&p=96439#p96370].
* The feature-checking approach used by "compat_layer.nas" should probably be generalized and made available as a standard Nasal module, also for use by other scripts, as it provides a good method for handling backward compatibility [http://flightgear.org/forums/viewtopic.php?f=5&t=7358&p=96439#p96358]
* L'approche "feature-checking" utilisée par "compat_layer.nas" devrait probablement être généralisée et être disponible comme un module nasal standard, ainsi que pour une utilisation par d'autres scripts, tant qu'il propose une bone méthode pour tenir une compatibilité d'arrière-plan.
[http://flightgear.org/forums/viewtopic.php?f=5&t=7358&p=96439#p96358]
* we could introduce another hash/namespace in the compat_layer module for Nasal based workarounds that are directly performance critical, so that the C++ implementation is prioritized.
* we could introduce another hash/namespace in the compat_layer module for Nasal based workarounds that are directly performance critical, so that the C++ implementation is prioritized.
* for some uses, threading may provide a real performance benefit. However, we need to ensure that threading is always OPTIONAL, so that users can easily verify if potential problems are related to threading or not. Worker threads seem to be the easiest and safest way for doing that.
* for some uses, threading may provide a real performance benefit. However, we need to ensure that threading is always OPTIONAL, so that users can easily verify if potential problems are related to threading or not. Worker threads seem to be the easiest and safest way for doing that.
32

edits

Navigation menu