Jump to content
The simFlight Network Forums

John Dowson

Members
  • Posts

    13,423
  • Joined

  • Last visited

  • Days Won

    277

Everything posted by John Dowson

  1. Then where re your brakes assigned? And then what ha[[ened? That doesn't help much - I need to see the full logs. But it does seem that something is turning off the autobrakes You can also use a free file transfer service to show me the logs, e.g. https://filetransfer.io/ 2f80 just shows the autobrake setting as it is in the sim - nothing to do with reads. It is showing 1 (off) when calibrated, but going from RTO to off and back to RTO when calibrated, But hard to tell anything more when that is all that is logged. But looks lik it was never even set to RTO when calibrated, if the offset always holds 1. But, I really need to see the full logs to understand anything here. But it is certainly not FSUIPC altering auto-brake settings. May be the calibration is triggering iFly to turn this off, not sure. Where are your brakes assigned? And what happens if you remove the current assignment and assign in FSUIPC?
  2. The log file shows that FSUIPC could not connect to MSFS. When did you start FSUIPC? i.e. Did you wait for MSFS to arrive at the main menu before starting FSUIPC? If so, you may have run out of simconnect connections due to another mis-behaving add-on. You should increase the MaxClients parameter in your SimConnect.xml - see What other add-ons are you using? Why don't you use auto-start?
  3. Looking at your ini, the only thing you seem to be using FSUIPC for is the brake calibration, where you have set quite a big slope (flattened at the start and stepper later), and rudder calibration. You don't have any assignments at all, neither axes or buttons. Are your brakes assigned in P3D, or in iFly itself? I am not sure why brake calibration could affect the auto-brakes. It is very large as you have so much logging enabled. Could you please just enable logging for the following (and disable the rest): Axis Controls, Events & Extras. Also, please add logging for offset 2F80 (as U8, and make sure to check to send to the normal log file). The file may still be too large to attach (your attachment limit will increase the more you post) - try compressing/zipping it. This will show if the auto-brake setting in offset 0x2F80 is being changed. If it is, we may need to enable IPC Write logging to see if this is being changed by an external program, but leave this off for the first log. It would also be useful if you could provide two log files - one with the FSUIPC calibration and the autobrake issue, and another with he calibration removed and the autobrake working as expected. You could also try with the toe brakes both assigned and calibrated in FSUIPC, to see if this makes a difference. Try assigning the toe brakes using the Send direct to FSUIPC calibration option. John
  4. So your assignment in ProSim move the switch but the lights don't turn on? This would indicate that whatever you have assigned to is triggering something that moves the switch, but something else is needed to actually control the lights. However, if you are assigning in ProSim, you need ProSim support. I can only support FSUIPC, not ProSim. You said that ProSim has a WASM module to control the lights - did you install that? Your log file does show that you have an error in your announcement.lua file: That error indicates that you are requesting a callback on some type of event, but you have not provided the callback function to receive the event. John
  5. Note that for PMDG aircraft, you probably need to use the custom controls that they provide. See the FAQ section on using PMDG custom controls (valid for P3D and MSFS). John
  6. Your log shows the button press sending the key presses and then these key presses being received back, e.g. So your button assignments to key presses are working. Note that your log also shows that you are trying things too early - around 5 seconds after FSUIPC was started, but it hadn't fully started until a couple of seconds later. You should give FSUIPC a bit more time before trying to control the aircraft via FSUIPC. Ok, makes sense. Note you can also set logging for Events (Log -> Events), as well as Buttons & Keys, and also open the logging console window (Log -> Open Console), This would then not only show you what FSUIPC is doing, but what the key press is assigned to in MSFS (i.e. the event that it triggers). Anyway, good luck with MSFS2024...I don't use this much (still prefer MSFS2020 or P3D), but at least its a lot more stable these days... John
  7. But, as I said, you have no key assignments (i.e. assignments to key presses/releases) in your ini file. Are you sure you have made some in FSUIPC? I have never heard or seen FSUIPC lose an entire key assignment section... You can also check (or send me / attach) your back-up FSUIPC7.ini file, from the backup-ini folder. This will contain your assignments as they were when you installed version 7.5.4. John
  8. You do not have the WASM installed - from your log file: Did you try to install the WASM? If not, re-install and accept the default options. If the WASM is then still not installed/detected, please show me the InstallFSUIPC7.log file. The ProSim WASM probably handles the specific events that control the ProSim 737. You would need to assign somewhere, such as in FSUIPC7, to have these events triggered and sent to the sim/wasm. Also, please always exit FSUIPC before attaching files. The log file you attached shows that FSUIPC was still running. John
  9. If you mean assignments to keys, then there are none of these in your ini file. Or do you mean button assignments to send key-strokes? If so, this also depends on the key presses also being assigned in MSFS. John
  10. You did not set logging for Buttons & Keys (Log -> Buttons & Keys) as I asked for, so your log file tells me nothing. Please set this logging and try again, and also provide some information as to what is not working. You are also not using substrings for your aircraft profile names. This means that any variant you load will not match a profile that is not already in the profile, and so the assignments for that profile will not be loaded. When you add an aircraft to a profile (or crate a new profile), you should always edit the name added to the profile section to make it a substring that matches all variants. I have done this for you in the attached ini, so please download and use this one. John FSUIPC7.ini
  11. Sorry - if its key assignments it cant be related to GUIDs. Set logging for Buttons & Keys for the lig file, and try an assignment that isnt working, i.e. "forgotten". If its an assignment to an lvar or preset, it could be the WASM has crashed....
  12. No, FSUIPC will/should not "forget" or lose assignments - they should all be stored in your FSUIPC7.ini file. What can and does happen sometimes is that your device GUIDs can change, and then FSUIPC recogognises it as a new device and your old/original assignments wont be available. This can sometimes hapoen on windows uodates, or possibly when reconnecting a device to a different hub (although less likely in this case). Another reason assignments can seem to be missing is when using an aircraft with a different livery, and not using aircraft substring names in your profile section. In either case, show me / attach your FSUIPC7.ini and .log files and I can take a look. John
  13. Ok, interesting. But you should be able to handle most things by using the FSUIPC profiles, as long as your lua names are distinct for each aircraft. For managing such a set-up (i.e. not having to copy things across manually), there is also a program called SimStarter NG that handles this kind of thing, but I don't know if thats available for MSFS, its mainly for P3D I think. For MSFS there is the MSFS Add-ons linker, but haven't looked at this for a few years. This was useful for having a cleaner MSFS Community folder for specific flights, but not sure what else it can handle these days but maybe worth taking a look at, out of interest if nothing else. But whatever works for you! Regards, John
  14. This depends on which aircraft (and from which provider) you are using, which you don't say. It does not depend on your device/controller - every controller is just a collection of buttons, switches and axes as far as FSUIPC is concerned. You can also always use logging to see what is being used: set logging for Events (non-axis controls), open the logging console window, activate the cut-off buttons in the virtual cockpit (VC) and see what is logged, then assign to that.
  15. By the way, you should really only add input events to offsets via a profile-specific InputEventOffsets section, as input events are always aircraft-specific. John
  16. Well yes - I did say you should use this and add it to an offset way back near the beginning of this thread! Note that b:vars are also called 'input events', and are closely related to the input events provided by FSUIPC, but not exactly the same - its all rather confusing. The input events you can access via FSUIPC directly come via the simconnect input events,, available in both MSFS2020 and MSFS2024, whereas you can only access b:vars via calculator code, and only in MSFS2024. Also, you usually get several b-bars of the form _set, _inc, _dec, etc that map just to one input event you see via the simconnect interface, and not all b:vars have associated input events via the simconnect interface. Yes, that should be the case. Input events can fire multiple events, such as updating lvars, firing events, etc. You should prefer them over lvars, when available. However, this does not mean that sometimes they need to be used in conjunction with something else - this really depends on how the aircraft is implemented. But mostly they seem to be more complete and should be preferred, when available. John
  17. Glad its now working, but do you know what the actual issue was?
  18. Yes, please do - that is always helpful, although probably difficult to find. I am working on an new FSUIPC website (and support forum) where hopefully I can provide such information where it is easier to find/access. No problem - glad you resolved your issue. Regards, John
  19. Ok, that can happen. Thats fine - whatever works for you. Just pointing out that for most things, the various FSUIPC logging facilities should be proficient enough, but you do have to 'connect the dots; as you say. Yes - you need to do it this way anyway if the position lvar only changes the position but not the actual function/lights.
  20. I think this is the issue - or one of them. By setting this to true, the script is sending a value of +16384 for brakes off, and -16383 for brakes full on. Try setting that back to false. This variable is to reverse the brake axis values sent to the sim. In fact, the script is not clear on this and it seems that it wasn't tested properly with a reversed brake lever axis. I have corrected this in the attached script, so please try this and set brakeAxisReversed to true and leave brakeReversed as false. The second issue is that the initial brake lever offset will be set at 0, which is 50% brakes. I have also attempted to correct this in the attached script, which explicitly calls the brakeChange function to set an initial value of -16383 ( or +16383 if reversed) so that brakes are initially off. If you want the brakes initially full on, set the initial/default value of lastBrakeValue to 16383 instead of -16383 (regardless of reversing). Please try this and let me know how it goes, and show me / attach your log if any issues (with enableLog set to true). John spitfireBrake.lua
  21. Note that you can see available lvars by listing them (Add-ons=>WASM->List Lvars) - no need to use the MSFS behaviors dialog, except as a last resort (i.e. usually to discover b-vars or h-vars). No problem about the incorrect lvar name - these things happen...! Now you have the correct name, you should check if setting that directly works to control the switch. If so, the assignments can be simplified as you don't need the compound condition on the position of your switches, and you only need to send the one one command to change the lvar two positions instead of three (e.g. switch up, pause, switch up). Anyway, you should try and understand those assignments and try to assign yourself the next time you want to make a conditional assignment. I will help if you run into problems, but you should have enough info in this thread to make a start. Regards, John
  22. Your ini is also a bit of a mess. I have cleaned-it up a bit. Your device names/guids changed a few times, so I gave removed unwanted entries and corrected one missing one. I have also updated your profiles to use substrings, so you don't have to keep adding variants to profiles. FSUIPC7.ini
  23. Just took a quick look at the logs. You started to test BEFORE the lvars were available (5 seconds or so too early), so the first two button presses (26 and 29) had no effect. then the next few had no effect as the switches were out-of sync with the VC. The log does show some movement of the switch (or change of value of the lvar) - three switch-down commands were sent: 13672 [DEBUG]: Calculator code sent: 31 (>L:VC_Miscellaneous_trigger_VAL,number) 13735 [DEBUG]: Calculator code sent: 31 (>L:VC_Miscellaneous_trigger_VAL,number) 15485 [DEBUG]: Calculator code sent: 31 (>L:VC_Miscellaneous_trigger_VAL,number) Did you not see any movement of the switch at all? Also add logging of offset A002 (using Log->Offsets). Show me /attach another file with the lvar (L:VC_POSITION_LIGHT_SW) and offset logging activated, and also wait a bit before you start testing, and I will take a look at the new logs tomorrow.
  24. Ok, then the presets should work. Ok, thanks. I should have also asked you to log the value of the lvar L:VC_POSITION_LIGHT_SW. Maybe you can do this as well for the next logs - details on how to log lvars are in the Advanced User guide (you add another section to your FSUIPC7.ini to do this...). Got to take the dogs out now and am finishing for the day. I will take a look at your logs tomorrow. John
×
×
  • 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.