tana a écrit:

Bonjour,

J'ai fait hier un vol La Paz  Quito avec le PMDG B773 et FSUIPC 4.961, la VAS libre a chutée pendant le vol jusqu'à l'arrêt de P3D faute de mémoire et le plantage complet de P3D, plus de lancement.

Après la réparation de P3D, J'ai récupéré le dernier FSUIPC 4.961 et réinstallé.

Aujourd'hui j'ai fait le même vol et la VAS libre est restée vers 1350 jusqu'au bout du vol.

Je n'ai pas compris. Qu'est-ce-qui a changé entre tes deux tests ? Je vois la même version de FSUIPC (4.961) dans les deux cas... A part la météo, le trafic AI...

Je suis étonné que cela n'est pas plus bougé du côté de Pete Dowson. Une nouvelle piste découverte en parcourant le forum de support : http://forum.simflight.com/topic/82771- … ent=499167

La présence d'une clef [HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers] "F:\\Games\\Lockheed Martin\\Prepar3D v3\\Prepar3D.exe"="$ IgnoreFreeLibrary<FSUIPC4.dll>" bloquerait le démarrage. Supprimer cette clef, permettrait de démarrer normalement P3D sans avoir à re-installer FSUIPC.

A suivre...

La présence d'une clef [HKEY_CURRE ...

Je n'ai pas cette clé ... et pourtant. 
Qui l'écrit ?

Dernière modification par bede40 (07-02-2017 20:47:35)

Je précise: cette entrée registre ne figure pas dans mon registre Windows et malgré cela la dernière version de FSUIPC plante.

Donc, n'ayant pas cette entrée je demande à savoir quel soft ou addon écrirait cette clé qui invalide sauvagement la dll de FSUIPC, en tout cas ce n'est pas P3D HF3 puisque je l'ai installé.




Edit: P3D (ou FsX) crée cette entrée registre lorsque FSUIPC provoque la sortie du programme. J'ai réinstallé la 4.961 pour voir.

Dernière modification par bede40 (08-02-2017 00:46:48)

Merci Christian pour le suivi,
Je m'en vais tester !

Bonjour!

Installation de FSUIPC 4.962. Pas de problème constaté. J'ai effectué un bonne dizaine de redémarrages de P3D avec tous type d'avion PMDG MD11, DASH MJC, Avions de Base pas d'écran noir ni de blocage.

les fichiers de Log, FSUIPC, Wide Server, Wide Client, Lua ne montrent aucune erreur. Par contre la connexion via Wide FS est plus longue il faut bien attendre 1 minutes avant de lancer Wide FS pour avoir une Connexion mais à priori c'est normal Pete Dowson indiquait qu'il laisser le simulateur se charger avant de lancer les modules.

Mes Boutons Send Keys et ceux attribués au MJC DASH Q400 via des macros LVAR fonctionnent bien ainsi que le script LUA qui monitore la VAS.

J'ai également fait la Mise à jour du client WideFS en 6.999z4 peut-être voir de ce coté si ce n'est déjà fait.

Re,
J'avais déjà le client WideClient 6.999z4 (j'adoooore ces numéros de version)... Et hier, cela a fonctionné sans soucis. Va comprendre Charles. A suivre.

Dernière modification par vbazillio (10-02-2017 09:47:58)

Merci pour l'info de la 4.962a :

FSUIPC 4.962a changes since 4.96
1. The memory check facility (OOMcheck) is now performed in a thread separate to the main FS thread. Apparently before this it was causing a longer frame at regular intervals (10 seconds by default). This was modified in version 4.962 so that it terminated properly when the session closes. In 4.961 it might sometimes be engaged in examining the process memory when, in fact, most of it was closed and freed, causing crashes stating “BEX” and “FSUIPC4_Unloaded”. Note that a bug in this 4.961 change which made the "Quiet” option for the check act the same as turning it off was fixed in 4.962a.

2. This version supports Prepar3D version 3.4 with HotFix 3 applied (version 3.4.22.19868).

3. The “Starting everything now” phase of FSUIPC initialisation is now delayed, especially on P3D, to allow more time for the sim to finish loading everything. Sometimes there  as such a long gap that FSUIPC was seeing extended SimConnect timeouts, and resorted to closing and reconnecting to SimConnect. This resulted in an even longer initialisation period!

4. The processor core affinity can now be set in the FSUIPC4.INI [General] section for FSUIP4 general threads, and separately for Lua plug-in threads. The parameters are:
ThreadAffinityMask=0
LuaAffinityMask=0
The value 0, defaulted, leaves the affinities the same as the process (ie the flight simulator affinity). Normal FSUIPC activities have to run in the main simulator thread in any case, so the mask set here does not affect all of what FSUIPC does. The value can be given in decimal, or, preceded by an ‘x’, in hexadecimal, and the previous
value and the new value are logged in both cases. The Lua affinity mask applies to ALL Lua plug-ins. It would be possibly to allow each to set its own mask, via a new function, but I really don’t think it is worth it. Those of different opinion on this can say so on my Support Forum.

IMPORTANT: You cannot use this facility to set core affinities which do not include at least are one core which is allowed by the affinity setting for the enclosing process. Even then, it is not clear whether Windows will ever schedule threads on these different cores. (Maybe someone could devise a test for this to check and let me know?)

5. A bug which can cause the sim to crash if an application tries to change the Logging options by writing to offset 3400 is fixed. (The crash was a result of a long-standing bug in which unknown data was being overwritten. It was just a recent re-build which moved stuff around and happened to change unknown corruption into an actual crash).

tana a écrit:

Toujours des problèmes d'OOM.

C'est à dire ? Des problèmes directement liés à FSUIPC ou bien certainement dû aux compléments installés et aux réglages ?

Dernière modification par vbazillio (12-02-2017 15:46:44)

Et ? Quel est le rapport avec FSUIPC ?

PS : quand je lis "réglage au maximum" et "PMDG" dans la même phrase, je ne m'étonne pas que l'un des termes "VAS" ou "problème mémoire " arrivent rapidement.

Dernière modification par vbazillio (13-02-2017 09:51:17)

FSUIPC intègre un mécanisme d'alerte de l'approche de l'OOM mais aucunement de déclenchement d'OOM. Cela surprend les simmer amateur qui entende une alerte et se demande d'où cela vient. C'est ce mécanisme "OOM Check" dont il est question dans la phrase que tu cites :

-- Fixed a new bug where te Quiet option for the OOM check actually turned off the check altogether