Vous n'êtes pas identifié(e).
ADE n'est pas d'une fiabilité exemplaire pour lister les navaids réellement actifs dans FSX car il travaille sur une base de données établie une bonne fois pour toute à partir des data du FSX de "base", et même si ces données de base sont modifiées, il ne prend pas nécessairement en compte les changements et affiche soit l'ancienne balise soit des "duplicates" pour cetains moyens de radionav modifiés (ILS par exemple)..l'auteur (Jon) me l'a confirmé. Peut être FSX planer est plus fiable à cet égard mais je ne l'ai pas étudié en détail. Si, tu as utilisé mes mises à jour, tu as un bouton "conflicts" qui te permettra de savoir si un des tes addons prend la main (ce qui évidemment invalidera les modifs faites sur les fichiers de base)..au moins tu le sauras ;-)
Merci Vincent. Je sens la réponse proche ;-)
GeForce GTX 660 - Driver version 9.18.13.4052 (ce qui doit correspondre au 340.52, n'ayant pas installé le dernier 344.11 car tout marchait très bien et ma carte n'est pas de dernière génération)
Bon j'aurais du faire une recherche avant ARFFF!! Le lien que tu indiques explique tout
Nouvelle installation. Réglages par défaut (rien de modifié après installation). Quelqu'un peut-il m'expliquer ce que sont ces horribles polygones couleur bleu ciel au sol ? J'ai celà partout!
Merci d'avance
Hervé
Au sujet de tes fichiers de navaids, comment les as-tu déclaré ? Car au départ, on utilisait un fichier similaire , réalisé par G. Mitchell, mais malheureusement, il déclarait ses waypoints dans des routes aériennes, ce qui rendait l'organisateur de vol de FSX inutilisable (il générait des routes aberrantes) , sans parler des erreurs de code régionaux, des waypoints en double,
Je ne sais pas ce que tu entends par "déclarer". Nous pourrons peut être en discuter en privé
Mais le waypointType ("NAMED "UNNAMED",et autres options) est, à ma connaissance, sans effet ni distinction visible au niveau du simulateur..La seule distinction visible que je connaisse est celle résultant du fait que l'intersection est incluse ou non dans une balise <airport> (intersection terminale au sens FS). Quant à l'organisateur de vol intégré: il était totalement faux avant (depuis perpète..); il est parfois en effet inutilisable après dès que l'on modifie un tant soit peu les moyens de radionavigation et/ou certaines intersections dans les fichiers "stock". Je dois dire que je ne vois pas de grosse différence au final...et les utilisateurs qui recherchent le réalisme utilisent tous d'autres outils de planification..mais ont besoin que le reste (indications instrumentales) qui ne dépend que de FS soit exact et nominal (cf les discussions sans fin des utilisateurs de FMC évolués qui ne comprennent pas que les indications instrumentales de FS ne soient pas concordantes avec leur dernier AIRAC..). Pour les utilisateurs avertis qui utilisent mes mises à jour, je propose même (option) de désactiver le fichier AT*.BGL afin de supprimer toutes les routes (fausses), intersections (obsolètes) et pouvoir proposer en remplacement des fichiers qui donneront un état des lieux à jour aussi bien pour les moyens de radionav que pour les intersections
Quoi qu'il en soit, je peux te fournir une liste à jour d'intersections au format XML. Il ne te restera plus qu'à les sélectionner et les inclure en intersections terminales ou pas mais tu pourras probablement gagner un peu de temps. Ce sera bien volontiers. On continue par mail? [hsors(at).hotmail(dot)com]
Amicalement
H
De toute façon, FSX est truffé d'erreur (je viens par exemple de repositionner le VOR-DME MPP de Malpensa en Italie, qui non seulement n'avait pas le bon nom, mais était à plus d'un Nm du vrai
En effet, et depuis longtemps..mais pourquoi réinventer la roue (sans aucune volonté d'une quelconque publicité perso) ? sauf à ce que tu ais besoin d'un fichier texte que tu puisses incorporer (et que je te fournirais bien volontiers, on fera celà en private email si tu le souhaites)
http://www.aero.sors.fr/navaids3.html
Pour le reste (charge de travail, temps disponible, etc..) crois bien que je comprends parfaitement ce que tu veux dire et que (quelque part) je compatis
Amicalement
Hervé
PS
car la pente doit être standard à 3.2° et la largeur du faisceau doit être aussi standard dans FSX
La pente du GS est toujours publiée..le plus fréquent est 3° (5.2%). La largueur de faisceau est par contre très très variable (dépend en première approximation de la longueur de piste, et plus précisément de la distance seuil-antenne localizer)
Pour créer un ILS manquant, cela se fait en 2 mn avec ADE; J'ai découvert cela ce weekend en réalisant KBOI - Boise, que j'ai fourni avec un AFCAD modifié.
Sans vouloir être excessivement puriste et pessimiste, c'est un peu plus compliqué que celà. Bien sur ADE permet de créer rapidement un ILS manquant, encore faut-il comprendre que les données à entrer doivent tenir compte d'un décalage possible entre les coordonées réelles de la piste concernée et celles de FS (et il y a parfois un certain décalage..). Entrer à l'arrache les corrdonnées publiées des différents composants de l'ILS (antenne LOC, GP et DME) aboutit assez souvent à des modélisations peu réalistes de l'ILS (avec de écarts significatifs vis à vis des approches publiées, notament des points d'aboutissement et des DME). Seule solution réaliste: travailler par rapport aux "offsets" calculés des différents composants par rapport aux seuils, chose que j'ai fait pour l'ensemble des ILS européens dans les updates que je propose
Autre chose;: il est sympathique, quand on crée ou modifie un ILS, d'y associer les "scenery objects" associés aux différents composants. C'est plus joli à regarder. Enfin il est assez important de bien paramétrer ce qu'on appelle le "beam width" de l'ILS (afin d'avoir des écarts réalistes de LOC en approche) ainsi que la déclinaison magnétique de l'ILS (publiée) afin d'avoir un axe d'ILS correct sur la vue carte. Il faut aussi tenir compte du fait que certains DME sont calibrés afin d'afficher "0" au passage du seuil (c'est le cas de l'ILS 09 à Séville..). Il faut alors les repositionner de façon adéquate
Enfin, il est tout aussi important à mon avis d'ajouter ou de corriger les PAPIs et les balisages lumineux d'approche associés aux approches de précision, pour un peu plus de réalisme (c'est toujours frustrant d'être parfaitement centré sur un glide avec 3 rouges ou 3 blanches, chose courante sur FS dont tous les PAPIs ou presque sont faux..)
Au final, pas toujours possible en 2 minutes ;-)
Quoi qu'il en soit, félicitations pour ce beau projet
Faire d'un don la condition à un service est une pratique peu scrupuleuse
Parfaitement d'accord..et c'est totalement contraire à la définition du "donationware" puisque un processus (peu importe lequel) basé sur ce modèle suppose que le don est optionnel..TOUJOURS. L'absence de don ne doit donc pas entraver la délivrance de la prestation proposée (software, aide ou tout autre proposition). Si ce n'est pas une arnaque, c'est donc en tout cas une dérive éthique vis à vis du modèle proposé
Pour info
Cause principale (99.9%) des anomalies constatées (absence de mise à jour des identifiants de piste sur certains aéroports): présence d'une scène additionnelle dont la priorité est supérieure aux scènes par défaut de FS9/FSX (cf la documentation chapitre 6)..Test: réessayer après désactivation des scènes rajoutées. Si c'est bien le cas vous n'avez plus qu'à demander une mise à jour ;-)
On aurait pu espérer qu'un "patch"
- supprime automatiquement les fichiers à rafraichir (plutôt que de demander à l'utilisateur d'aller le faire lui même)
- s'installe correctement quel que soit le chemin d'installation (renseigné dans le registre..lire le registre on peut espérer savoir faire)
- fasse effectivement la mise à jour des fichiers à remplacer (ma version est restée en 2.0..)
- ne s'accompagne pas d'un message d'erreur d'une clé inaccessible
- etc..
C'est quand même un peu étonnant non? Alors, réinstaller la version complète certes..mais inutile alors de proposer un patch non?
A lire le forum P3D, ils sont pas contents 
Question: il semble d'après plusieurs posts sur le forum P3D, que la mise en oeuvre du patch pose des problèmes aux utilisateurs qui n'ont pas installé P3D dans le répertoire proposé par défaut mais dans un répertoire spécifique. Il semblerait que l'installeur n'en tienne pas compte
Ref
So here is what the patch actually does (and why it fails if you don't have the standard installation path):
1. It checks for your current installation path.
2. It verifies which files are stored in your current installation path.
3. It then completely ignores your current installation path and installs the patched files into the standard folder anyway.
4. It then proceeds to change your correct installation path in the registry to the new, broken path where only half of the files exist.
5. Just for kicks it also changes the Prepar3d shortcut on your desktop to the new, completely broken Prepared.exe installation.Here is how you can manually fix it:
1. Copy all the files from the new, broken installation path into your old installation.
2. Go into the registry and change the path back to the old installation path.
3. Change the shortcut on your desktop to the old installation Prepar3d.exe
votre expérience ?
50€ pour un soft soit disant "PROFESSIONNEL" qui devait être, âpres 2 ans de gestation, parfait et sans de bugs
Ca c'est illusoire..même avec 40 béta testeurs, il est impossible de détecter tous les petits (ou moins petits) problèmes que vont rencontrer plusieurs centaines (voire milliers) d'utilisateurs avec autant de configurations différentes. Il est aussi impossible d'anticiper toutes les demandes d'amélioration. Même les très grosses compagnies le savent (suivez mon regard). Et il ne me semble pas qu'un quelconque développeur puisse annonçer être "parfait et sans bugs". L'ont-il fait?
Assez d'accord avec Antoine vis à vis des coûts exagérés pour la bande passante..il est assez facile de faire le calcul et je ne pense pas qu'il s'agisse d'un quelconque "coup de colère" mais tout simplement d'un prix jugé excessif par beaucoup en comparaison des autres solutions d'autant qu'il ne s'agit que de simulation et non de logiciels destinés à une utilisation aéronautique réelle, tout à fait hors de prix il est vrai). Maintenant chacun fera son choix. J'ose penser que les développeurs, confrontés à une possible désaffectation, reverront leurs ambitions financières à la baisse car j'imagine que ce n'est pas leur principale source de revenus ;-). Je ne méconnais pas l'investissement en terme de travail de recueil et de programmation et le réalisme des solutions apportées (encore que entre les spécifications réelles utilisées et les modèles FS, il y a parfois un monde..) mais, là c'est un peu cher payé, il me semble.
J'ai essayé, enfaite ça modifie uniquement la vitesse de décrochage...
Non..la vitesse de décrochage (dans une configuration donnée) ne dépend que des paramètres aérodynamiques du modèle. Les paramètres de la section [Reference_Speeds] ne sont donnés qu'à titre de référence et sont probablement un "résidu" des modifications qui étaient effectuées dans le temps avec FSEDIT. Malheureusement, il n'est pas possible de régler à ma connaissance (sans gauge ou addon) le déclenchement de l'alarme visuelle/sonore
En revanche il nécessite FSUIPC 3.99 minimum sous FS9.
Négatif..AJPC ne nécessite aucune connexion FS et donc pas FSUIPC..AFSD si
Merci à tous..et les idées sont toujours à prendre en compte (si faisable, dans le cas contraire cela veut dire qu'on est d'abord limité par la connaissance du fonctionnement des calculs que Microsoft a codé pour aboutir à ce que vous obtenez au final- ex: la puissance thermodynamique développée par les moteurs à piston qui reste à valider afin d'obtenir le point de départ des calculs c'est à dire la puissance disponible en entrée pour l'hélice). Je mettrai en ligne réguliérement des mises à jour de ce premier utilitaire (un "updatecheck" est d'ailleurs prévu)..quant à BeeGee, il n'a plus rien à apprendre 
Même si je n'ai pas l'habitude de faire une quelconque publicité aux utilitaires que je développe pour FS, je vous invite à jetter un coup d'oeil à une nouvelle application que je viens de finaliser destinée aussi bien aux concepteurs de modèles de vol qu'aux pilotes (on ne les oublie pas) permettant de calculer les performances réelles d'un modèle de vol FS et, pour les pilotes, de planifier leurs vols (EET, emport de carburant, etc..mais vous verrez)..Attention: les données calculées ne le sont qu'à partir du modèle de vol FS réel (sans aucune hypothèse de départ); elle peuvent donc différer des abaques publiées par les constructeurs..les différences n'étant le fait que des concepteurs du modèle.
Pour le moment cette application n'est utilisable que pour les turbojets (FS9/FSX) subsoniques
Bien sur, n'hésitez pas à me faire part de vos remarques afin d'assurer l'évolutivité de cette application qui est téléchargeable ici (AJPC v1.11 link):
http://www.aero.sors.fr/afsd.html
Il arrive fréquemment que FS ne capte pas l'indication glide au delà de 18-20 NM, alors que le LOC est actif..vérifiez à tout hasard, sinon c'est un problème de scène
Hervé
Même en cochant l'option "Mettre à jour les intersections", rien ne change!!
Cà alors ! Es-tu sur que ta scène "addon scenery" est active ?
Un petit mail "en privé" et je vais te régler cela.
Au passage:
1) Pour FS9, La plupart des intersections obsolètes ont été nettoyées dans les fichiers BGL de mise à jour. Pas pour FSX
2) Toutes les nouvelles intersections sont incluses dans les fichiers descriptifs AP*.BGL (FS9 seulement) ET dans le fichier RA9FRINT.BGL ou RAXFRINT.BGL qui est normalement copié dans le répertoire Addon scenery
En fait il s'agit d'un "hack" du fichier SIM1.DLL (donc prudence) permettant de modifier les coef de friction qui sont codés en interne. Ce fichier modifié avait été mis en ligne à l'époque sur un site allemand il me semble.
Quelques détails ici:
http://www.gamehourz.com/Changing-Ground-Friction-Values-Translate-German-ftopict12513.html
Hervé
fuel_flow_gain=0.002
J'allais dire la même chose après quelques tests, mais Bee Gee a été plus rapide ;-)
Je pense qu'en effet, en l'augmentant, cela va diminuer l'inertie des variations de N1/N2 (même si le nom de ce paramètre ne reflète pas bien les choses) et que ton régime turbine reviendra plus vite en mode iddle. Note que cela aura aussi un effet permanent sur la cinétique des modifications de régime..malheureusement, je crains que cette augmentation brève à la mise en route soit codée en interne et ne dépende pas d'autres paramètres sauf peut être au niveau des tables moteur..mais il y aura alors aussi des effets induits.
petite question à Hervé justement, comment calcules tu la CAS dans AFSD
A partir de la valeur du Mach et du "standard pressure ratio" (delta), ces 2 paramètres étant précis dans FS (le 2ème se calcule à partir de l'altitude géopotentielle). C'est un calcul assez complexe, dont le principe est expliqué dans l'excellent document de W.M. Olson (paragraphe 4.8, pages 35 et 36)
http://pagesperso-orange.fr/hsors/docs/WMOlson_Technical_Information_Handbook.pdf
[---]
Public Function GetCAS(m As Double, delta As Double) As Double
'
Dim QcP As Double, QcPSL As Double
Dim CAS As Double, oldCAS As Double
Dim td As Double
'
If m < 1 Then
QcP = (1 + 0.2 * m * m) ^ 3.5 - 1
Else
QcP = (kCAS * (m ^ 7) / ((7 * m * m - 1) ^ 2.5)) - 1
End If
'
QcPSL = QcP * delta
CAS = aSL * Sqr(5 * ((QcPSL + 1) ^ (1 / 3.5) - 1)) 'subsonic formula
'
If CAS >= aSL Then
Do
oldCAS = CAS
td = oldCAS / aSL
CAS = 0.881284854347331 * aSL * Sqr(((1 - (1 / (7 * td * td))) ^ 2.5) * (QcPSL + 1))
Loop Until Abs(oldCAS - CAS) < 0.01
End If
'
GetCAS = CAS
'
End Function
[---]
Et merci à tous pour vos encouragements ;-)
Le paramètre "braking strength" du fichier air n'a plus aucun effet et a été remplaçé par le "toe_brake_scale" du fichier de configuration comme l'a expliqué Bee Gee (il y en a beaucoup d'autres)..tu peux donc l'oublier. A noter que le même paramètre "toe_brake_scale" affecte l'efficacité du frein de park (si égal à 1). Après, à toi de déterminer ce qui est réaliste en terme d'efficacité de freinage.
Les 3 ILS de Liège (23R-23L et 05R) travaillent en effet sur la MEME fréquence (109.35). En réel c'est sans importance comme celà a été indiqué dans un autre post car un seul est actif à un moment donné (en fonction de la piste en service). Sur FS, pas d'autre solution que d'attribuer des fréquences différentes (via AFCAD ou autre..).
Pour info, la mise à jour dont tu parles corrige les ILS en France mais aussi en Belgique, Suisse et Luxembourg. Ceci étant, elle ne corrige pas le problème de Liege car le 109.35 x 3 est réel et n'a donc pas été changé..faudra peut être que j'y pense..quitte à s'écarter de la réalité