[FSX] optimisation après OOM

Pilote95 · [↑]

Bonjour,
Après mon premier OOM avec le PMDG777 (...), je cherche à optimiser ma conso afin de ne pas exploser mon VAS. J'aurais quelques questions, sachant que je fais principalement du vol IFR.
J'ajoute que j'ai déjà parcouru le sujet concernant l'OOM sur http://support.precisionmanuals.com
J'ai d'ors et déjà réduit mon texture max load de 4096 à 2048 et mon cloud layers sur ASN en le repassant à sa valeur par défaut.

Mes questions donc : Quelles sont les valeurs à rentrer pour IMAGE_COMPLEXITY & AUTOGEN_DENSITY ? A l'heure actuelle, j'utilise respectivement 4 et 5 (j'ai suivi ça : http://c-aviation.net/fsx-tweak/image_complexity-scenery-complexity-setting/ // http://c-aviation.net/fsx-tweak/autogen-density-in-fsx/).
Le passage à Dx10 peut-il améliorer les choses ou les chances de planter sont les mêmes ?

Mes addons: multiples aéroports, REX4, ASN, FTX Global+Open LC EU+Trees
Config : i7 4790k + gtx970 + 8Gb ram

Merci pour vos conseils.

Dernière modification par Pilote95 (11-11-2015 17:02:23)

Ptipilot · [↑]

Pilote95 a écrit :

J'ai d'ors et déjà réduit mon texture max load de 4096 à 2048 ...

Si les ingénieurs de dev n'ont pas dépassé le 1024... Il y a peut être une raison...

skyrader_57 · [↑]

Bonjour,
Je possède également le PMDG777 avec ces OOM. C'est vraiment galère. Seul moyen baisser les curseurs ds FSX. Je suis en DX10. Je ne vole pas avec en plus.
voila les lignes ds fsx.cfg :
TEXTURE_MAX_LOAD=1024
[JOBSCHEDULER]
AffinityMask=84
LOD_RADIUS=4.500000
TERRAIN_MAX_AUTOGEN_BUILDINGS_PER_CELL=1700
TERRAIN_MAX_AUTOGEN_TREES_PER_CELL=2000
IMAGE_COMPLEXITY=4
AUTOGEN_DENSITY=3
cordialement

Zangdaarr · [↑]

Ptipilot a écrit :

Pilote95 a écrit :
J'ai d'ors et déjà réduit mon texture max load de 4096 à 2048 ...
Si les ingénieurs de dev n'ont pas dépassé le 1024... Il y a peut être une raison...

La même que pour laquelle ils ont laissé des fuites mémoire partout ? Au passage en 2008 quand on mettait des options de configuration dans un fichier texte c'est que c'est fait pour être changé, sinon on la met pas et on met une bonne grosse variable globale en dur dans le code (parce qu'on sait pas coder, faut pas abuser non plus).

Je te dirais de passer à P3D, mais bon, tu as payé ton 777 je comprends que tu ne veuilles pas repasser à la caisse

Pilote95 · [↑]

Bon j'ai essayé de refaire le même vol que celui qui m'a fait planté, de EIDW (scène aérosoft) jusqu'à LSZH (même chose) avec les changements sus cités + load radius à 4.5, TEXTURE MAX=2048 et AUTOGEN_DENSITY=4. Démarré entre 2.8/2.9Go à EIDW puis à 37000ft c'était redescendu vers 2.6 pour finir entre 3.5/3.6Go une fois à la porte. Bon ça n'a pas planté et j'ai pas entendu FSUIPC s'affoler. A voir sur un vol plus long....

skyrader_57 a écrit :

TERRAIN_MAX_AUTOGEN_BUILDINGS_PER_CELL=1700
TERRAIN_MAX_AUTOGEN_TREES_PER_CELL=2000

Oui merci j'avais vu ces lignes que j'ai rajouté également.

Zangdaarr a écrit :

Je te dirais de passer à P3D, mais bon, tu as payé ton 777 je comprends que tu ne veuilles pas repasser à la caisse

Oui entre autre. J'ai eu l'occasion de l'essayer mais j'ai pas trop accroché (moins d'addons compatibles, je parle même pas du prix de la licence et je préfère les textures de FSX que je trouve moins sombre). En plus, j'ai pu voir dans mes recherches que P3D souffre aussi du syndrome OOM.

J'aurais encore une question concernant Dx10Fixer. Je l'avais testé sur mon ancienne machine mais j'avais un bug avec les high level clouds qui m'affichaient un flash gris durant leur chargement (notamment quand je tournais la caméra). J'avais lu que changer le type de nuage de haute altitude réglait le problème. Du coup un petit tour dans REX suffit à changer le type de nuages et corriger le problème ou il y a autre chose à faire ?

Merci

Ptipilot · [↑]

Zangdaarr a écrit :

Ptipilot a écrit :
Pilote95 a écrit :
J'ai d'ors et déjà réduit mon texture max load de 4096 à 2048 ...
Si les ingénieurs de dev n'ont pas dépassé le 1024... Il y a peut être une raison...
La même que pour laquelle ils ont laissé des fuites mémoire partout ? Au passage en 2008 quand on mettait des options de configuration dans un fichier texte c'est que c'est fait pour être changé, sinon on la met pas et on met une bonne grosse variable globale en dur dans le code (parce qu'on sait pas coder, faut pas abuser non plus).

Plutôt que de t'encrer dans ta bêtise, essaye plutôt de comprendre les choses!...
Ils ont laissé à l'utilisateur final la possibilité de réduire la taille de 1024. Pas de dépasser les limites qui ne sont pas permises dans l’interface graphique.

Cherche un peu et tu verras que cette limite n'est pas du fait des développeurs de FSX.

yvesamuel · [↑]

Bonsoir,

Juste un exemple : je viens de terminer un vol EDDF KSEA en 777 PMDG sans OOM, avec les mêmes addons installés, notamment les ORBX NA, EDDF AS et KSEA T2G, alors qu'avec FSX il était impossible de voler plus de 3-4 h avec le 777...
Cela te donnera peut-être à réfléchir.

Bons vols
Yves

Dernière modification par yvesamuel (11-11-2015 20:19:48)

Zangdaarr · [↑]

Ptipilot a écrit :

Zangdaarr a écrit :
Ptipilot a écrit :
Si les ingénieurs de dev n'ont pas dépassé le 1024... Il y a peut être une raison...
La même que pour laquelle ils ont laissé des fuites mémoire partout ? Au passage en 2008 quand on mettait des options de configuration dans un fichier texte c'est que c'est fait pour être changé, sinon on la met pas et on met une bonne grosse variable globale en dur dans le code (parce qu'on sait pas coder, faut pas abuser non plus).
Plutôt que de t'encrer dans ta bêtise, essaye plutôt de comprendre les choses!...
Ils ont laissé à l'utilisateur final la possibilité de réduire la taille de 1024. Pas de dépasser les limites qui ne sont pas permises dans l’interface graphique.
Cherche un peu et tu verras que cette limite n'est pas du fait des développeurs de FSX.

Quand on veut avoir un paramètre maximal, on le peut.

[img align=C]http://www.pilote-virtuel.com/img/members/177/Capture.PNG[/img]

C'est pas compliqué de pas faire n'importe quoi. Sérieusement. Factuellement, ils ont permit à l'utilisateur final de dépasser la limite de l'interface graphique.

Leurs chargements de scénarios ne sont pas libérés, la mémoire allouée lors de la construction d'objet ne l'est pas si la construction échoue - on se souvient tous des fuites mémoires causées par les fichiers manquants de FVFR. Y'a des techniques pour ça basées sur l'usage de pointeurs intelligents.

J'ai du mal à comprendre pourquoi tu les défends tant que ça, leur code daube, à tous les niveaux, rien que le travail de LM le prouve allègrement: il n'est pas robuste ni tolérant, un comble quand on veut faire de l'open !

En plus, j'ai pu voir dans mes recherches que P3D souffre aussi du syndrome OOM.

C'est normal, il est 32bits, tu ne pourras jamais charger plus de 4Go de mémoire dans une application 32bits.
Par contre, ils adressent mieux les fuites et la libération de mémoire, ce qui rend le programme plus stable sur le long terme et permet d'en mettre un peu plus. La version 64bits sera une vraie libération, dommage qu'elle soit encore loin dans le temps.

Ptipilot · [↑]

Zangdaarr a écrit :

J'ai du mal à comprendre pourquoi tu les défends tant que ça, leur code daube, à tous les niveaux, rien que le travail de LM le prouve allègrement: il n'est pas robuste ni tolérant, un comble quand on veut faire de l'open !

Dans du code, on peut tout faire!...
Lorsque l'on développe une interface graphique pour le paramétrage, généralement le contrôle du range est fait à ce niveau. Si, l'utilisateur by-pass celle-ci, c'est à ses risques et périls...
La plupart des produits fonctionnent suivant cette logique!...

A un moment, il faut trouver un juste équilibre entre le juste besoin et le besoin délirant engendré par un mauvais comportement de paramétrage. C'est un produit "ouvert"!... Si l'utilisateur ne veut pas s'invertir un minimum, qu'il se tourne vers un produit complétement bridé sur console... Ce sont deux philosophies différentes.

Concernant la libération de mémoire, nous ne devons vraiment pas avoir la même version de produit...
Chez moi, cela fait des années que je l'utilise et tout ce passe très bien!
Tu as même un contrôle automatique fait par FSUIPC (avant dernière ligne du log...) pour le valider.

Concernant les OOM, ils peuvent être de nature très diverses... Et, effectivement FSX peut en déclencher lorsqu'il est mal paramétré. Perso, comme je n'aie pas la possibilité de mettre des trappes dans le code, je déclenche des OOM volontairement à la demande pour trouver les limites de telles ou telles fonctions.
Mais, pour faire cela, il faut avoir étudié un petit peu le fonctionnement de la fonction à paramétrer...

A la différence de toi, je n'attaque pas systématiquement tel ou tel produit, mais j'essaie de comprendre les contraintes des producteurs et mesurer leurs limites. C'est pourquoi, je ne comprends pas ton mode de fonctionnement qui devrait être à l’inverse pour un professionnel de l'informatique.
C'est d’ailleurs ce que j'ai fait (grâce à FSX...) en étudiant le pipeline graphique alors que je n'en avais absolument pas besoin professionnellement. Mais, j'ai voulu comprendre les limites des producteurs de jeux et je me suis aperçu que c'était un domaine passionnant.
Des bugs sur FSX, il y en a comme dans tous les produits (j'en ai quelques uns dans ma poche...)... Mais, ils ne sont pas bloquants.

Concernant le 64 bits, cela ne changera absolument rien au fonctionnement. Seules les limites mémoires seront différentes.
Et un produit mal écrit, qu'il soit en 32 ou 64 bits, sera toujours mal écrit.

Dernière modification par Ptipilot (12-11-2015 09:54:00)

NEPTUNE6P2V7 · [↑]

Ha bien voila ! Si le mâle et crie , c'est qu'il est pas comptant .

Patou

Zangdaarr · [↑]

Ptipilot a écrit :

Zangdaarr a écrit :
J'ai du mal à comprendre pourquoi tu les défends tant que ça, leur code daube, à tous les niveaux, rien que le travail de LM le prouve allègrement: il n'est pas robuste ni tolérant, un comble quand on veut faire de l'open !
Lorsque l'on développe une interface graphique pour le paramétrage, généralement le contrôle du range est fait à ce niveau. Si, l'utilisateur by-pass celle-ci, c'est à ses risques et périls...
La plupart des produits fonctionnent suivant cette logique!...

Wow mais juste non quoi.
Je vais pas développer trop parce que c'est pas un forum de "comment designer son code" mais un standard c'est d'avoir une classe qui consomme les inputs, les valide et éventuellement leur applique des transformations (comme des filtres), voir les encapsule dans des conteneurs de données (comme des classes à unités ou à énumérations pour, par hasard, des paramètres de configuraiton), avant de les mettre à disposition du reste du système. Si on a plusieurs points d'entrées pour un même input ça doit atterrir au même endroit à la fin.

Les devs ont certainement bossé "en mode panick attack", tout le long du projet, et sincérement je me fiche un peu de ce qui a pu se passer et à quel niveau ainsi que de la dilution des responsabilités, je vois juste le résultat: un produit qui prend plusieurs années à être corrigé.

Concernant le 64 bits, cela ne changera absolument rien au fonctionnement. Seules les limites mémoires seront différentes.

Oui ben ça, ça change tout au niveau des add-on justement.

Ptipilot · [↑]

Zangdaarr a écrit :

Wow mais juste non quoi.
Je vais pas développer trop parce que c'est pas un forum de "comment designer son code" mais un standard c'est d'avoir une classe qui consomme les inputs, les valide et éventuellement leur applique des transformations (comme des filtres), voir les encapsule dans des conteneurs de données (comme des classes à unités ou à énumérations pour, par hasard, des paramètres de configuraiton), avant de les mettre à disposition du reste du système. Si on a plusieurs points d'entrées pour un même input ça doit atterrir au même endroit à la fin.

Hé Bien... Je vais t'étonner...
Mais, je suis à deux cents pour cent d'accord avec toi sur ce point!...

J'ai regretté qu'ils ne l'eussent pas fait à l'origine, surtout que ce n'est pas trop compliqué à traiter en incluant même des retours d'"Out of range" dans un log... Et malheureusement, P3D n'a pas évolué d'un millimètre sur ce point...

Tu vois que par moment nous avons la même vision des choses!...

Dernière modification par Ptipilot (12-11-2015 17:06:43)

niepce · [↑]

Le passage à Dx10 peut-il améliorer les choses ou les chances de planter sont les mêmes ?

Oui, chez moi le passage à Dx10 avait effectivement libéré de la VAS et atténué fortement les OOM, à l'époque ou j'utilisais FSX.
Sinon je te conseille d'installer Config Scenery Editor (freeware), et de décocher tous tes add-ons d'aeroport, hormis celui de départ et d'arrivée de ton vol.
Dernier conseil, dans FTX Vector, ne coche que les primary et secondary road avec les underlay, éventuellement les beach.
Dans ton 777, désactive le RAAS (dans dll.xml je crois).
Au pire du pire, efface le modèle exterieur (et tu ne voleras plus que dans le cockpit)
Ca plus ton texture_max_load à 1024 ca devrait aider.

Pilote95 · [↑]

Merci pour ces précisions.

Pilote95 · [↑]

Est-ce que ces valeurs

TERRAIN_MAX_AUTOGEN_BUILDINGS_PER_CELL=1700
TERRAIN_MAX_AUTOGEN_TREES_PER_CELL=2000

sont indépendantes de la valeur de l'AUTOGEN_DENSITY= ?
Je comprends que ça va limiter le nombre d'arbres/buildings au km². Mais comment ça va influencer l'autogen density par exemple entre une valeur 3 ou 4 ?

Pour SceneryConfigEditor ça apporte quelque chose sur la durée du vol ? Parce qu'en désactivant tous les aéroports ou pas, dans les mêmes conditions (ASN actif, même aéroport (EIDW), même porte, sans rien toucher) au bout de 2min le VAS va obligatoirement se coller à une valeur similaire vers les 3Go.

Dernière question, combien consomme orbx vector ?

Dernière modification par Pilote95 (14-11-2015 14:13:20)

aidata · [↑]

Salut
Je te renvoie à un post que j'avais fait il y a qqs temps "ca vas un peu mieux ..."
J espère que ca t aidera.

Fuchs · [↑]

yvesamuel a écrit :

Bonsoir,
Juste un exemple : je viens de terminer un vol EDDF KSEA en 777 PMDG sans OOM, avec les mêmes addons installés, notamment les ORBX NA, EDDF AS et KSEA T2G, alors qu'avec FSX il était impossible de voler plus de 3-4 h avec le 777...
Cela te donnera peut-être à réfléchir.
Bons vols
Yves

Je fais des vols sur FSX de 10-12 h avec le 777 entre la Chine et l’Allemagne sur un terrain ORBX, des textures REX, une méteo ASN et avec des scènes d'aéroports installées sans OOM...
Faut arrêter de dire que c'est impossible...

Vous ne savez pas régler votre simu et ou êtes trop gourmand, ça c'est très possible par contre....

Pilote95 · [↑]

aidata a écrit :

Salut
Je te renvoie à un post que j'avais fait il y a qqs temps "ca vas un peu mieux ..."
J espère que ca t aidera.

Ok mci je vais jeter un œil à tout ça.

Fuchs a écrit :

Je fais des vols sur FSX de 10-12 h avec le 777 entre la Chine et l’Allemagne sur un terrain ORBX, des textures REX, une méteo ASN et avec des scènes d'aéroports installées sans OOM...
Faut arrêter de dire que c'est impossible...
Vous ne savez pas régler votre simu et ou êtes trop gourmand, ça c'est très possible par contre....

Possible d'avoir une idée de ton .cfg ? mci

BiplanBonplan · [↑]

Pilote95 a écrit :

Est-ce que ces valeurs
TERRAIN_MAX_AUTOGEN_BUILDINGS_PER_CELL=1700
TERRAIN_MAX_AUTOGEN_TREES_PER_CELL=2000
sont indépendantes de la valeur de l'AUTOGEN_DENSITY= ?
Je comprends que ça va limiter le nombre d'arbres/buildings au km². Mais comment ça va influencer l'autogen density par exemple entre une valeur 3 ou 4 ?
Pour SceneryConfigEditor ça apporte quelque chose sur la durée du vol ? Parce qu'en désactivant tous les aéroports ou pas, dans les mêmes conditions (ASN actif, même aéroport (EIDW), même porte, sans rien toucher) au bout de 2min le VAS va obligatoirement se coller à une valeur similaire vers les 3Go.
Dernière question, combien consomme orbx vector ?

Bonsoir,

Tout simple :

Curseur de la densité d'autogen à fond à droite tu auras bien par dalles d'autogen 1700 bâtiments et 2000 arbres.

Curseur de la densité d'autogen à moitié du auras 50 % de ces valeurs, 850 bâtiments et 1000 arbres

Bons vols

Foxy · [↑]

TERRAIN_MAX_AUTOGEN_BUILDINGS_PER_CELL=1700
TERRAIN_MAX_AUTOGEN_TREES_PER_CELL=2000

Tout le monde va me prendre pour un cinglé, mais personnellement, depuis que j'ai supprimé ces deux lignes de mon fsx.cfg, je peux finir certains vols qui se finissaient toujours avec un OOM.

Pour en avoir le cœur net, j'ai replacé à nouveau les lignes et... OOM ! ... Ai refait un essai sans... et ça passe...

Aussi étrange que ça puisse paraître (voire paradoxal), ces deux lignes accélèrent l'arrivée des OOM.

Zangdaarr · [↑]

Je ne vois pas ce qu'il y a de paradoxal dans le fait que de blinder son simulateur d'arbres générés automatiquement bouffe de la mémoire.

Ptipilot · [↑]

Foxy a écrit :

TERRAIN_MAX_AUTOGEN_BUILDINGS_PER_CELL=1700
TERRAIN_MAX_AUTOGEN_TREES_PER_CELL=2000
Tout le monde va me prendre pour un cinglé, mais personnellement, depuis que j'ai supprimé ces deux lignes de mon fsx.cfg, je peux finir certains vols qui se finissaient toujours avec un OOM.

Mais non mais non!...

Ces deux lignes permettent de jouer sur la balance de la partie variable de l’autogène.
La valeur par défaut est de 3000 ou 3500, je n'ai plus le chiffre exact en tête.
Donc, lorsque tu supprimes tes lignes, tu retournes aux paramètres par défaut.

Pour ma part, depuis des années, j'ai bloqué ces valeurs aux maximums (6000).
Donc, je prends tout ce qui a été créé par le concepteur de la scène....

Dernière modification par Ptipilot (18-11-2015 08:48:59)

bouzemb · [↑]

@pilote95
bonjour
consulte ta messagerie;je t'ai envoyé un message
a+

GUIBRU · [↑]

Pilote95 a écrit :

aidata a écrit :
Salut
Je te renvoie à un post que j'avais fait il y a qqs temps "ca vas un peu mieux ..."
J espère que ca t aidera.
Ok mci je vais jeter un œil à tout ça.
Fuchs a écrit :
Je fais des vols sur FSX de 10-12 h avec le 777 entre la Chine et l’Allemagne sur un terrain ORBX, des textures REX, une méteo ASN et avec des scènes d'aéroports installées sans OOM...
Faut arrêter de dire que c'est impossible...
Vous ne savez pas régler votre simu et ou êtes trop gourmand, ça c'est très possible par contre....
Possible d'avoir une idée de ton .cfg ? mci

Bonjour,

Cela ne vous servira à rien d'avoir son .cfg, le mieux est l'optimiser par vous-même. Pour rappel c'est un tout, vous devez avoir une harmonie entre vos réglages dans votre .cfg et ceux de votre carte graphique.
Commencer par passer sous DX10 SF avec un .cfg vierge en rajoutant Highmemfix=1 puis faite des tests.
Si votre fsx est moyennement stable alors prenez connaissance de ceci (DX10 HowTo.pdf) ---> http://www.nzfsim.org/index.php?dsp=downloads

@+
Guillaume

Dernière modification par GUIBRU (18-11-2015 09:43:14)

Foxy · [↑]

Ptipilot a écrit :

Foxy a écrit :
TERRAIN_MAX_AUTOGEN_BUILDINGS_PER_CELL=1700
TERRAIN_MAX_AUTOGEN_TREES_PER_CELL=2000
Tout le monde va me prendre pour un cinglé, mais personnellement, depuis que j'ai supprimé ces deux lignes de mon fsx.cfg, je peux finir certains vols qui se finissaient toujours avec un OOM.
Mais non mais non!...
Ces deux lignes permettent de jouer sur la balance de la partie variable de l’autogène.
La valeur par défaut est de 3000 ou 3500, je n'ai plus le chiffre exact en tête.
Donc, lorsque tu supprimes tes lignes, tu retournes aux paramètres par défaut.
Pour ma part, depuis des années, j'ai bloqué ces valeurs aux maximums (6000).
Donc, je prends tout ce qui a été créé par le concepteur de la scène....

Le but ainsi que la raison d'utiliser ces deux lignes, je les connais parfaitement.

Cette "limitation" arbres et/ou bâtiments va amener les avantages que l'on connais bien.
En revanche, leur existence dans le fsx.cfg (et quelque soit les valeurs mentionnées) engendreront les OOM plus rapidement que si on ne fait aucune limitation (y compris si le curseur Autogen dans le simu est tout à droite).

C'est cela que je voulais dire. A moins que je ne sois toujours pas clair dans mon explication...

#1 [↑][↓] 11-11-2015 16:58:25

[FSX] optimisation après OOM

#2 [↑][↓] 11-11-2015 17:18:05

Re : [FSX] optimisation après OOM

#3 [↑][↓] 11-11-2015 18:40:07

Re : [FSX] optimisation après OOM

#4 [↑][↓] 11-11-2015 18:48:48

Re : [FSX] optimisation après OOM

#5 [↑][↓] 11-11-2015 19:13:09

Re : [FSX] optimisation après OOM

#6 [↑][↓] 11-11-2015 19:16:49

Re : [FSX] optimisation après OOM

#7 [↑][↓] 11-11-2015 20:19:16

Re : [FSX] optimisation après OOM

#8 [↑][↓] 11-11-2015 22:27:16

Re : [FSX] optimisation après OOM

#9 [↑][↓] 12-11-2015 09:18:22

Re : [FSX] optimisation après OOM

#10 [↑][↓] 12-11-2015 09:23:47

Re : [FSX] optimisation après OOM

#11 [↑][↓] 12-11-2015 14:00:57

Re : [FSX] optimisation après OOM

#12 [↑][↓] 12-11-2015 14:29:53

Re : [FSX] optimisation après OOM

#13 [↑][↓] 12-11-2015 14:38:48

Re : [FSX] optimisation après OOM

#14 [↑][↓] 12-11-2015 17:05:43

Re : [FSX] optimisation après OOM

#15 [↑][↓] 13-11-2015 12:13:29

Re : [FSX] optimisation après OOM

#16 [↑][↓] 14-11-2015 18:49:12

Re : [FSX] optimisation après OOM

#17 [↑][↓] 14-11-2015 19:22:25

Re : [FSX] optimisation après OOM

#18 [↑][↓] 15-11-2015 11:06:36

Re : [FSX] optimisation après OOM

#19 [↑][↓] 15-11-2015 16:51:38

Re : [FSX] optimisation après OOM

#20 [↑][↓] 17-11-2015 19:35:39

Re : [FSX] optimisation après OOM

#21 [↑][↓] 17-11-2015 21:59:49

Re : [FSX] optimisation après OOM

#22 [↑][↓] 18-11-2015 08:29:31

Re : [FSX] optimisation après OOM

#23 [↑][↓] 18-11-2015 08:47:29

Re : [FSX] optimisation après OOM

#24 [↑][↓] 18-11-2015 09:42:35

Re : [FSX] optimisation après OOM

#25 [↑][↓] 19-11-2015 20:54:43

Re : [FSX] optimisation après OOM

Pied de page des forums