Jump to content
The simFlight Network Forums

John Dowson

Members
  • Posts

    12,260
  • Joined

  • Last visited

  • Days Won

    250

Everything posted by John Dowson

  1. Your ini file is confusing me more... You only have ome assignment, and that is to the S axis of your HOTAS throttle. Is that the sweep lever? I thought this was a separate device.. The flaps settings make no sense: First, determine what the flap position values of the flap detents are. To do this, activate logging for Axis Events and send these to the console window. then move the flaps lever in the VC and take a note of the parameter for the Flaps Set event, or note the event being used. Then assign that lever by removing the assignment to the axis itself (you can select '(unused)'), and then set three ranges for your axis, and on entering/leaving set the values determined for the last three detents using the Flaps Set control, or use the controls logged for each detent.
  2. Yes, as explained in my previous comment. No it cannot - that will not work. You cannot set B:vars via calculator code. That is a question for Asobo/MSFS, but I very much doubt it. SU15 is the last sim update this year. John
  3. Why have you installed FSUIPC7 under your Documents folder: start "" "C:\Users\Al\Documents\Al's Flight Simulation\AddOns\FSUIPC7\modules\FSUIPC7.exe" "-auto2" ? Re-install in a non-windows protected folder. If using the MSFS.bat method does not work for you (and I have no idea why this would be), then switch to using the EXE.xml method in the installation process. I have no idea what this means... As I have said many times now, if FSUIPC7 does not auto-start using the MSFS.bat auto-start method, re-install and select the EXE.xml method instead. John
  4. What do you mean by this - what is the issue? Can you please show me your FSUIPC7.log file and explain the problem. I do not provide or support earlier versions. John
  5. I am still waiting to see a FSUIPC7.log and FSUIPC7.ini file showing this issue, when you have added IgnoreDevice=0xFFFF,0xFFFF to the [JoyNames] section of your FSUIPC7.ini file. That should be a temporary fix for this issue, and if that does not work then I need to see those files to determine why. John
  6. What do you mean by this? If there is no Assignments menu, then you are running an unregistered version. You need to re-run the installer and enter and register your license details to generate a key file. There is no latest beta - download and install the latest version, which is 7.4.12. John
  7. Can you show me your ini and log files for this please? That should certainly work, and something else must be going on if not...
  8. You can be back in business now by adding that ini parameter, as suggested. I have no idea when the next release will be, but hopefully not for quite a while... John
  9. Your log shows that FSUIPC7 attempted to reconnect many times during MSFS start-up, and that auto-tuning was active. Can you please test again next time you restart, and if you get the same issue, try restarting FSUIPC7 (i.e. exit FSUIPC7 and re-start by double-clicking the FSUIPC7.exe file in windows explorer). Also, please activate logging for Buttons & Keys, and re-attach a new log if still having issues. John
  10. Aggh, : I added a new facility to allow a device to be ignored, and when this is not used it defaults to using a device with product and vendor ids of 0000, which is what your Fulcrum One Yoke has registered with (for some reason...!). I am not sure why your device hasn't given a non-null vendor/product id, but FSUIPC still should not ignore this. I will correct this in the next update, but for now please add IgnoreDevice=0xFFFF,0xFFFF to the [JoyNames] section of your FSUIPC7.ini file. This will then ignore that device rather than defaulting to the vendor/product values of your Yoke. Sorry about that. John
  11. If there is no icon in the system tray or task bar, then it will not be running. Does Alt+F open the FSUIPC7 main window? If not, then it is not running. Note that you need to use the MSFS.bat file or the Desktop MSFS link (created by the FSUIPC7 installer) to start MSFS if using the MSFS.bat auto-start method. If this is not working, I have no idea why - the bat file simply starts MSFS, waits for 95 seconds, and then starts FSUIPC7. If this is not working, I do not know why. Re-install and go back to the EXE.xml auto-start method - in the components installation page, open the auto-start options, de-select or uncheck the MSFS.bat method (first option) and select / check the EXE.xml method. John
  12. No, it is not broken. Have you read the above? Are you using the Desktop MSFS icon installed by the FSUIPC7 installer to start MSFS? If not, that is why FSUIPC7 is not being auto-started. If you are using that, and you are leaving the bat file running (i.e. not closing/killing it by closing the console window that is created) then FSUIPC7 will be started. If you are not using the Desktop MSFS link, then FSUIPC7 will NOT be started. Re-install and when you get to the components screen, open the auto-start options, deselect the MSFS.bat auto-start method and select the EXE.xml auto-start method. There is no problem to solve. You should update and decide which auto-start method you want to use and then use that. John
  13. Yes, please install the latest official 7.4.12 as there are a few updates from the beta (and also from the 7.4.12 version I provided for SU15), including documentation. John
  14. Why do you think it has stopped executing commands? Could it be that the commands are being sent, but they are not having any affect on the aircraft? You could try using FSUIPC's logging facilities and open the logging console - this will tell you what FSUIPC is doing.... What actually happened? Did the sim pause/stutter? Are you using auto-save? Can you attach your FSUIPC7.log and FSUIPC7.ini files and I will take a look, although I doubt that they will show anything... Could you try a flight with the logging console window open and logging for Buttons & Keys and Events activated, and take a look at what is happening when you think that commands are not being executed, and take a note of the timestamp of the last log message, or whenever you think there is an issue. John
  15. Ok, so you are not using the MSFS.bat file (via the Desktop icon installed by FSUIPC) to start MSFS and FSUIPC7. Yes, you can add the start of FSUIPC7 to the batch file you are using. Best to do this after a delay (95 seconds) period from starting MSFS, and also a good idea to pass the '-auto2' parameter so that FSUIPC knows it is being started via a batch file. Alternatively, you can re-install and select the previous method to have FSUIPC7 auto-started, via the MSFS EXE.xml file. John
  16. Again, this is misleading. You can use presets via UI assignments and Lua - just defining a preset does nothing. And you need to use whatever works for that particular button or switch - it may be a standard control, an input event, and lvar, a hvar, or a combination of one or more of these (which can implemented via overloading assignments, a preset, a macro, or in lua code). You need to use what works. If there are multiple ways to control a switch or button, then you can choose which method to use. No - use whatever works! It is silly to restrict yourself by using one method only - you will invariably get stuck. If there are toggle controls/events, you can use these. Otherwise, if you are using presets, you can possibly implement the preset as a toggle control (ie.g. the preset can toggle/inveet a value, or the code can do different things depending on the state of a simvar or lvar via a conditional). You can also overload key assignments as you can button assignments. If you want different things to happen depending on if it is the first or second press, then you would need to have two assignments and use an offset condition to determine which assignment is needed. If there is no offset that determines this, you will need to add one. Otherwise yes, the alternative is lua. John
  17. I am sorry but I need to see your FSUIPC6.ini file to see your settings, not your FSUIPC6.log file. Please attach this. Maybe in the real aircraft, but how does this work in the sim? I presume you are using the flap controls for the flaps (flaps set, flaps incr/decr), but what controls/events are used to control the wing sweep? Ok. So you want one hardware axis to control one section of the sim's flaps axis (to control flaps), and another hardware axis to control another section of the flaps axis. So, the full range of your hardware flaps axis (-16384 - + 16383) will control the flaps section of the sims flaps axis (-16328 to x), and the full range of your wing sweep axis (again -16384 to +16383) will control the wing sweep range of the sim's flaps axis (x to 16383)? And that will also cycle through the wing sweep positions, no? Ok. But the flaps could be in any position when you use the wing sweep lever, no? If so, would this not cause a strange jump if using the wing sweep lever, say, when the flaps were stowed? Rather than using axis ranges, try assigning to the Flaps Set control, and then scale the axis assignment to the range to the wing sweep range, using FSUIPC's axis scaling functionality - see section Additional parameters to scale input axis values on page 43 of the Advanced User guide. If you want the wing sweep lever to control the range 12000 to 16383, try adding a scaling factor of *0.134,+14195. If the wing sweep range is before or after the 12000 mark, adjust as needed. It should also be possible using axis ranges, but I think you would need to use the Flaps Set control to set the flap positions to the correct wing sweep setting for each range, and not use the in/dec or other controls. Sorry, can't see that as I am not on Facebook. John
  18. Not sure what you mean. Once FSUIPC7 is started, it is iconized to your system tray, not the task bar. This has always been the case. It will only appear in the task bar once you open FSUIPC7 from the system tray, or if it is iconized to the system tray once opened. The only change to the auto-start is the way FSUIPC7 is started, now how it is available from the system tray or task bar. John
  19. That looks fine, and shows that FSUIPC7 should be started here: start "" "C:\FSUIPC7\FSUIPC7.exe" "-auto2" after a 95 second delay after MSFS is started. As long as you don't kill the script (by closing/exiting the console window) I cannot see how FSUIPC7 cannot be auto-started if using that bat file (usually via the MSFS desktop icon). As I said, if you are having issues with this (and I have no idea why), then re-install and switch back to the old method of starting FSUIPC7, via the EXE.xml file. John
  20. Please see Could you please attach your MSFS.bat file so I can take a look at it. John
  21. Are you aware of the changes to auto-start in the latest version, 7.3.12? In 7,4,12, the default way to auto-start FSUIPC7 has been changed from using the MSFS EXE.xml file to using the FSUIPC7-installed MSFS.bat file, vie the MSFS Desktop icon installed by FSUIPC7. Therefore, if you are using the default auto-start method, you must use the MSFS desktop icon installed by the FSUIPC7 installer. If you start MSFS any other way, FSUIPC7 will not be auto-started. A console window is also created but this should be iconized, although sometimes this window is shown (a black/empty console window). If this window is killed/closed, then FSUIPC7 will not be auto-started. If you are having issues with starting FSUIPC7 via the MSFS.bat file/Desktop icon, you can go back to the previous method of auto-starting FSUIPC7, using the MSFS EXE.xml file. To do this, re-run the FSUIPC7 installer. In the Components selection page, open the auto-start component, de-select the MSFS.bat method of auto-start and check the EXE.xml method. This will then revert to the previous method. Note that I changed this as it looks like lua fscripts are running approx 10-13x slower when FSUIPC7 is auto-started via the EXE.xml method. If you do not use many lua scripts then this may not be an issue, and the performance is still probably acceptable even if you are. John
  22. Btw, where is that cockpit VC image from? That doesn't look like the virtual cockpit that I see in the C510. What are those lighting switches that you say do not work? There are various Input Events for the lights, so try those. For the generator switch, you can use the Input Event ELECTRICAL_Alternator_2 with values/parameters 0, 1 & 2 for the 3 positions. In the down position (2), it will only stay there momentarily and then spring back to the central position (1), as it does in the VC. John
  23. Not really. This doesn't really make sense. All your assignments are kept in the ini file (or files). The myevents.txt file just holds your preset definitions. I could have kept these in a [myOffsets] section of the ini file I suppose, but as the MobiFlight presets are provided via the events.txt file, I thought I would use the same mechanism for user-defined presets. Why not? What do you mean? You should use Input Events when available, I see no reason not to. No need to attached this as I know what is available as I have this aircraft. I don't see why they shouldn't. There can be a short delay when using Input Events for incrementing/decrementing the Input Event value, as a round trip to the FS is needed to get the updated value before a next increment/decrement, but this is the same as when using lvars. John
  24. First, you posted in the Announcements sub-forum, where it explicitly states NOT for support requests. Please post in the correct forum for support. I have moved your post. It it is not working, it can be due to one of three things: 1. There is an issue with the assignment and FSUIPC is not sending the key press when you press the button. You can easily check this by activating logging for Buttons and key operations, open the logging console (check Send to console window) and see if the keysend command is logged. 2. The keyboard shortcut Ctrl+[ is not assigned to control the TOGA switch. Check this in your P3D key assignments. Note the default assignment for TOGA is Shift+Ctrl+G. You can also set logging for Events (non-axis controls) and you should see the AUTO_THROTTLE_TO_GA event logged. 3. The default AUTO_THROTTLE_TO_GA command does not work for the PMDG NGX aircraft. PMDG aircraft use their own custom controls for many buttons/switches. Looking at the header field for the NG3 (for the MSFS version, I do not have this aircraft for P3D) I can see the following custom controls: #define EVT_CONTROL_STAND_TOGA1_SWITCH (THIRD_PARTY_EVENT_ID_MIN + 684) #define EVT_CONTROL_STAND_TOGA2_SWITCH (THIRD_PARTY_EVENT_ID_MIN + 687) To use the PMDG custom controls, see this FAQ entry: John
  25. Can you please attach your FSUIPC6.log file so that I can see your assignments. Are you calibrating with detents, or sending those Flaps Decr and Flaps 1 (not sure what the first extension would be in this aircraft) commands on entering/leaving an axis range? If so, I don't understand why you would want to do this if you have also assigned the axis itself to the Flaps Set control. And the Flaps Incr/Decr events/controls do not take a parameter. If not calibrating with detents, maybe try this - see page 45 of the User Guide. Best to do this with the axis assigned using Send direct to FSUIPC calibration, but can use Send to FS as normal axis if this gives issues.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.