Jump to content

jgerow

Members
  • Content Count

    5
  • Donations

    $0.00 
  • Joined

  • Last visited

Community Reputation

0 Neutral

Profile Information

  • Gender
    Male

Flight Sim Profile

  • Commercial Member
    No
  • Online Flight Organization Membership
    none
  • Virtual Airlines
    No

Recent Profile Visitors

420 profile views
  1. Issue finally resolved... Thanks to MCE and ActiveSky support for their incremental updates, to help find/isolate the issue. Turned out to be related to DirectX and the 64-bit video drivers for my GTX 980Ti. I run 3 screens for port, front and starboard custom camera views, as well as a small VGA screen for the GPS, and with all these 64-bit apps, the 64-bit video drivers needed to be tweaked as well. (Which is why I could either fly with ActiveSkyNext or with MultiCrewExperience but not both --- P3Dv4 couldn't start it's video and either crashed or hung with no video.) Recent Microsoft DirectX as well as the updated NVIDIA drivers for the GTX980Ti, were needed. [I'm running Win7, others with the newer version of Windows may already have the updates.] I now have a "full up" P3Dv4 running with great active weather [test flights were done in thunderstorms !], voice commanded ATC (with MCE/PF3), and a remote computer running SPAD.next driving all the guages, etc. with FSwidgets GMapHD giving me a moving sectional map with METAR overlays.
  2. Good news: The 7/12/17 "MCE for P3Dv4" update is working fine with PF3. I needed to do a minor workaround to set MCE's PTT button on the yoke since it was defaulting the the Saitek TPM. The workaround was: "unplug the Saitek TPM, start the MCE configuration process to discover the yoke (and initialize to the yoke's button), then after finishing MCE configuration, re-connect the Saitek TPM." --thanks MCE support! [Since the yoke is found correctly with P3Dv3, and the work-around is only needed for the initial configuration phase. i.e. it's a low priority "want."] The only other issue I found in my first "test flight" was that P3Dv4 has issues starting up when both "MCE for P3Dv4" and "Active Sky Next for P3Dv4" are enabled. I suspect it's a case of both have to be aware of the other...but I have let both support teams know about the issue. Since "Active Sky Next for P3Dv4" has been out a while and is fairly stable, I'll be concentrating on getting up to speed with "MCE for P3Dv4" with "PF3 for P3Dv4." [Still can't believe how good the P3Dv4 "environment" is coming together -- not even 2 months since P3Dv4 was released and most of the addons are "getting there" and making the flying experience almost too realistic.]
  3. One thing to point out is that in the log is both the prompt and what was interpreted, so you can confirm that what you said is what VOXATC is processing. (Yes I have submitted the log with the "VOXATC hangs after trying to hail Utiopia radio" issue.) Just wish there was a way of enabling a "more detailed" logging level that would indicate why VOXATC hangs just after calling Utopia radio [aka generic FSS] at 122.2. The extra "locating FSS", "setting up FSS," etc. log entries would help in debugging by indicating the various processing states. Drawbacks is the extra code needed to be added, as well as the exposure of some of the design of VOXATC, so maybe the compromise is to do just output a numeric code at each major step. Hmmm... anyone have any ideas on how to get the log to help both Tegwyn as well as us?
  4. The FSUIPC "mapping" of button to simconnect variable id, then the simconnect variable id mapping to Mindstar gps. is only done once [off-line] as part of the installation of the Mindstar G5330 and Emuteq. During a flight, when an Emuteq button is pressed or a knob is turned, that is a USB event that is processed by FSUIPC, and passed to Mindstar. So the question becomes, how often are buttons pressed or knobs turned? Well, since I have to enter a flight plan manually, and that requires lots of knob "clicks", that can take a tiny percentage of time over several minutes times your frame rate, and you won't notice it. [i don't think I can turn the knob faster than about 10 clicks a second [read that as selecting a letter for the waypoint ID. So going from A to K might be done as fast as a second, then it's click to the next ID position, and repeat for the next character, etc. What you really want to ask is, "with the Emuteq set up as a separate display [e.g. using NVIDIA Surround], how much processing is being done 1) by the video driver, and 2) by the emulated GPS ? And for that, I defer to Mindstar. [i was previously using Emuteq with the built-in GPS, all I'm doing is replacing the built-in GPS with Mindstar's. This is different from no GPS to virtual-cockpit GPS, or no GPS to Emuteq with built-in GPS, etc. So for performance issues, you will always need to specify what is the "before" and what is the "after."]] If you're really performance squeezed on your main computer, there is also a remote capability via simconnect, where a secondary computer drives the Emuteq. I will probably be doing that since I already use remote simconnect with SPADnext to drive several Saitek panels/instruments as well as the FSWidgets GMapHD moving map. Remote "off-loading" means no video driver resources taken on the main computer, and minimal processing to support some gps interaction via simconnect data generation/transfer, the bulk of the GPS processing/display generation will be done on the secondary computer.
  5. If you haven't already set up the Emuteq with FSUIPC, go through the key mapping process on the key button tab of FSUIPC, pressing/turning each button/knob, selecting fs control followed by selecting the corresponding gps function in the drop down choice dialog for button up. Next you'll need to edit the Mindstar GPS.ini file with the simconnect hex values for the buttons. I turned on the FSUIPC (registered version) logging of the buttons/keys and events to console window and successively pressed (or rotated each way) the buttons / knobs on the Emuteq. The console window logged all the button/knob simconnect values with their corresponding event descriptions. I then edited the GPS.ini file to fill in the gps1 entries with the appropriate hex (note: it can only handle the 0x (hex) and not decimal) simconnect values. Note for P3Dv3, I'm able to undock the GPS window, size it and drag it to the Emuteq display, do a save. Also, a known issue is that a P3D flight plan isn't transferred, and manually entering one in the g530 corrupts the P3D one so the knee board nav log is bad, etc.
×
×
  • Create New...