Vous n'êtes pas identifié.
Bonsoir à tous amis simmer
Je viens vers vous car mon p3D v4 ne fait que de planter en phase d'approche. Cela se produit toujours après avoir redécollé vers ma deuxième destination. (c'est à dire que je me pose à mon premier aéroport sans problème, je vais au parking histoire de simuler un chargement de passager, je redécolle et lors de l'approche de ma deuxième destination... me revoilà sur mon bureau)
J'utilise Active Sky P3D v4 avec Active Sky Cloud Art, ORBX global, Vector et open LC Europe.
Je simule avec le DA62 de Carenado.
Avez vous déjà rencontré ce genre de problème?
D'avance merci de prendre de votre temps à me répondre.
Hors ligne
Salut,
Déjà eu quand j'étais sous p3dv4.2, donc pas à jour, en revanche ça ne me le faisait que avec le CRJ de Aerosoft et parfois avec le 737NGX. Donc vérifie que tu sois bien en 4.3 et pas en 4.2
Hors ligne
galais74 a écrit:
Salut,
Déjà eu quand j'étais sous p3dv4.2, donc pas à jour, en revanche ça ne me le faisait que avec le CRJ de Aerosoft et parfois avec le 737NGX. Donc vérifie que tu sois bien en 4.3 et pas en 4.2
"
Pour le savoir de rendre dans la racine de P3Dv4 et le "Prepar3D .exe" tu as la version en mettant le pointeur de la souris dessus . une popup s'affiche .
Patou
Hors ligne
Re les amis.
J'ai pourtant téléchargé la dernière version disponible sur leur site.
Je ne sais pas d'où peut venir ce problème.
Hors ligne
Essaye avec un autre avion pour voir, vole une heure n’importe ou, fais plusieurs approches, mais de la même façon et avec les mêmes vols qu'avec le DA.
Galais74
Hors ligne
Bonjour amis simmers
Hier soir, j'ai appliqué le tuto pour faire cohabiter orbx avec les scènes France vfr (j'ai la scène PACA v2) puis j'ai refais un vol, j'ai pu décoller sans problème de Grenoble direction Pierrelatte puis retour à Grenoble toujours sans aucuns plantage. je vais refaire quelques vol pour voir si mon problème est réglé
Hors ligne
Bonne nouvelle ça, au moins les tutos ça peut servir à quelque chose
Hors ligne
re bonsoir amis simmers
Et bien avoir fais plusieurs vols j'ai toujours le même problème qui se présente, P3D plante sans crier gare.
J'attends de lire les retours sur la v4.4 avant de mettre mon p3d à jours... en espérant que cela règle mon problème.
J'avais abandonné fsx car j'en avais marre des OOM en final et avec P3D j'ai l'impression de revivre ces mésaventures
Hors ligne
themis38 a écrit:
re bonsoir amis simmers
Et bien avoir fais plusieurs vols j'ai toujours le même problème qui se présente, P3D plante sans crier gare.
J'attends de lire les retours sur la v4.4 avant de mettre mon p3d à jours... en espérant que cela règle mon problème.
J'avais abandonné fsx car j'en avais marre des OOM en final et avec P3D j'ai l'impression de revivre ces mésaventures
Selon moi, il ne s'agit que de OOM.
Comme toi, je n'ai que 16 Go de RAM. Mais à partir du moment où la config te permet de mettre les curseurs plutôt à droite, tu n'y échappes pas.
La V4 permet heureusement de profiter de la mémoire extensible. Il faudrait de préférence avoir 32 Go.
Pour te dire, les dernières scènes que j'ai achetées ne sont pas utilisables chez moi, car OOM déjà au départ (au mieux, j'ai 2 - 3 minutes de répit, mais il suffit de changer de vue, et...retour au bureau).
Parmi les scènes devenue inutilisables chez moi, je cite EHAM (Fly Tampa) qui fonctionnait normalement jusqu'à l'instalation de ORBX TrueEarth Netherland, les aéroports de Seattles + City (Drzewiecky Design), EBBR et EDDK de Aerosoft et j'en oublie probablement un paquet.
Heureusement, pour la majorité des autres scènes, j'arrive à décoller, à faire ma croisière. En revanche, je fais une sauvegarde avant l'arrivée, car avec mes add-on (Active Sky, REX Sky Force), le PMDG, tous les ORBX installés, des aéroports paywares uniquement (pas ceux d'origines) ainsi que les curseurs du P3D quasi tous vers la droite, je prends pas le risque de me choper un OOM en courte finale...
Vivement ma prochaine config (pour bientôt j'espère), qui pourra enfin me faire profiter de toutes ces scènes que j'ai achetées et dont je ne peux, pour l'instant, profiter (tiens, il me vient encore en tête d'autres aéroports inutilisables : EDDF et EGGL de Aerosoft, KBWI de LatinVFR, KBOS de Fly Tampa, etc. etc.)
Dernière modification par Foxy (05-12-2018 20:24:38)
Hors ligne
Comment je fais moi avec mes 8 giga de DDR3 ??
Hors ligne
Bonjour
Je suis également sceptique. J'ai certains des aéroports mentionnés et jamais eu de retour bureau avec 16 Go de RAM. Je ferai un test demain en mettant tous les curseurs complètement à droite mais je suis à peu près sûr que ça passera.
Hors ligne
C’est clairement pas un problème de RAM, avec 16Go tu passes à l’aise sous P3D. Avec 32 bits et la limite à 4Go oui ça coinçait sur scènes lourdes mais là on parle de 4 fois plus de RAM donc aucun souci
Hors ligne
ydelta a écrit:
C’est clairement pas un problème de RAM, avec 16Go tu passes à l’aise sous P3D. Avec 32 bits et la limite à 4Go oui ça coinçait sur scènes lourdes mais là on parle de 4 fois plus de RAM donc aucun souci
Voila .
Hors ligne
flighty a écrit:
NEPTUNE6P2V7 a écrit:
Comment je fais moi avec mes 8 giga de DDR3 ??
J'ai appris qu'avec une grande taille de GRAM aide enormement.
Sur XP oui, sur P3D c’est moins critique la GRAM sauf si tu sélectionnes les textures en 4K
Ici on parle bien de la RAM dédiée à P3D pour se charger en mémoire avec toutes ses dépendances.
Hors ligne
Je n'invente rien pourtant. Je viens de faire un test à l'instant et j'ai eu l'OOM attendu.
J'ai un clavier Logitech qui m'indique sur un petit écran l'utilisation du processeur (UC) et l'utilisation de la RAM.
Voici le test que je viens d'effectuer, avec la scène KSEA + aéroports de Seattle + City (Drzewiecky Design) :
- Arrivée sur bureau Windows : RAM = 19%
- Ouverture REX Sky Force 3D qui reste ouvert durant la session P3D : RAM = 20%
- Ouverture de Active Sky pour P3Dv4 qui reste ouvert durant la session P3D : RAM = 21%
- Ouverture de P3Dv4.1... avec UT2 Live et EzDok... arrivée sur l'écran d'accueil : RAM = 30%
- Chargement scène KSEA avec PMDG 737 NGX : RAM = ça évolue rapidement... jusqu'à 55% - 57%
- Jeu démarré => 737 à l'arrêt au gate : RAM = 59%
- Je démarre simplement les moteurs, sans utiliser FS2Crew ou GSX2... je change de vue - ça tape les 60-61% et...
"Your computer has run out of available memory. Please restart Prepar3D and select different graphics, scenery, or traffic settings".
Je précise que l'OOM arrive toujours vers 60-61%... parfois j'arrive juste à 62% (le jeu saccade, j'ai des écrans noirs lors d'un changement de vues, etc. avant le retour au bureau).
Du coup, on peut se demander pourquoi 60% et pas 100% ?
Aurais-je un soucis matériel alors ?
Hors ligne
Je pense que les 60% marqués n'incluent pas la mémoire "réservée" (je me souviens plus du terme exact).
Si tu regardes dans le gestionnaire des taches, dans l'onglet "performances", tu verras que la mémoire est divisée en trois catégories: utilisée, en attente, et libre.
Dans ton cas, la partie "libre" a du tomber à zero. Tu peux peut-être simplement essayer d'augmenter la taille de ton fichier de mémoire virtuelle.
Dernière modification par Daube (06-12-2018 21:58:00)
Hors ligne
Il faudrait que tu regardes dans les infos système combien w10 voit de RAM pour confirmer qu’il voit bien 16 go.
Hors ligne
Voir les Journaux d'évènementWindows/ applications ../ , les info sont plus précises avec un numéro de l'OOM
Et qui te fais quoi ??
ce sera plus simple, que d'avoir des calculs sur le positionnement des valeurs utilisées par tel ou tel processus .
Patou
Hors ligne
Merci beaucoup à tous !!!
Vous aviez raison et c'était bien ma mémoire paginée (virtuelle) qui était à zéro. Visiblement c'est pas une bonne idée pour Windows 10. Je l'ai rétablie et, en effet, les scènes les plus gourmandes passent maintenant sans problème
Je vais pouvoir profiter et découvrir une bonne dizaines de scènes que j'avais achetées mais qui n'étaient pas utilisable à cause de cela et faire mes vols en une traite plutôt que de sauvegarder au milieu et redémarrer le simu
Merci encore à tous
Bons vols
Hors ligne
Mauvaise conclusion à mon sens.
Un système doit être calibré pour l'usage qui en est fait. On est passé sur des systèmes 64b donc les simulateurs ont emboîté le pas et les éditeurs aussi.
A ceci près que les utilisateurs ne prennent pas conscience que tout système a ses limites et ils chargent encore plus "la mule" croyant que le 64b va tout leur permettre ... faux, il permettra plus mais pas TOUT.
Pour avoir travaillé plus de 30 ans sur des systèmes embarqués militaires, à chaque fois nos systèmes développés ont été définis en fonction du hardware du moment et des besoins finaux. En 80 nous utilisions 256ko de mémoire, maintenant pour des systèmes dont les buts sont "identiques" nous sommes à 32 go, bien entendu les besoins graphiques et l'ergonomie n'a plus rien à voir avec ceux des années 80
En simulation, et je dis bien en simulation, il faut quantifier ses besoins et mettre le matériel à la hauteur de ses ambitions. Si l'utilisateur en question nécessite autant de programmes (c'est son droit quoique ...) il lui faudra mettre "la main à la poche" pour mettre la quantité de RAM à la valeur nécessaire, ce qui dans le cas présent ne semble pas être la bonne valeur.
Pourquoi ? Simplement parce qu'un simulateur est un système semi-temps réel et que le fait de passer par un fichier de pagination perturbe cet équilibre fragile donc soit on s'amuse et dans ce cas ... soit on simule et on fait ce qu'il faut.
Je simule depuis les années 90 et tous mes postes de simulateur n'avait pas de mémoire virtuelle, du 286 de l'époque au i5 2550k actuel. Simplement, ma RAMm est à chaque fois calculée pour mon usage du moment. Actuellement, 16 Go me conviennent ... Sans doute la prochaine machine aura le double mais je connais mes besoins.
Dans le cas présent, soit d'utilisateur en veut trop, soit il a mal calibré son système. Passer par un fichier de swap dans l'optique d'un simulateur est une hérésie à mon sens ... à moins qu'il ne "s'amuse" et dans ce cas, c'est une économie budgétaire donc un pis- aller.
Dernière modification par Lagaffe (09-12-2018 12:09:48)
Hors ligne
Ce qu'il faut aussi prendre en compte, c'est que le fonctionnement de la mémoire virtuelle a évoluée avec l'arrivée du 64 bits et que ce qui était applicable avec un Windows 32 bits ne l'est plus avec un Windows 64 bits.
Avant le fichier de swap n'était qu'une extension de la RAM sur disque et on pouvait donc s'en passer si on avait assez de RAM.
Aujourd'hui, ce n'est plus seulement ça : Windows utilise le fichier de pagination pour gérer la mémoire virtuelle vue par les process (le passage au 64 bits ayant fait exploser le nombre de page mémoire).
Et ce n'est pas parce qu'on active la mémoire virtuelle que P3D va se retrouver en swap. Si c'était seulement un problème de taille du process, P3D ne planterait pas alors qu'il n'y avait que 61% de RAM utilisée. La RAM aurait dû se remplir jusqu'à 100% pour que le process P3D arrive en OOM.
P3D ne consomme d'ailleurs pas une quantité folle de RAM. Chez moi, à EHAM FlyTampa, Orbx Netherlands, Active Sky+ Asca, Ezdock Camera, 777 PMDG, tous les curseurs à fond pour le test : moins de 6 Go de RAM pour Prepar3D, 223 Mo pour ActiveSky + Asca, 95 Mo pour Ezdock.
Et je ne pense pas que Foxy ait perdu en perf suite à la réactivation de sa mémoire virtuelle.
La mauvaise conclusion est plutôt de devoir surdimensionner sa RAM pour se passer d'un composant du système d'exploitation.
Dernière modification par Loader (09-12-2018 13:39:14)
Hors ligne