
John Dowson
Members-
Posts
13,317 -
Joined
-
Last visited
-
Days Won
272
Everything posted by John Dowson
-
@Tuomasi Please try the attached version(7.4.10d) with DetectToConnectDelayAuto=375 In this version i have updated to allow a maximum value of 500. John FSUIPC7.exe
-
PMDG event.offset is slower than MSFS event.offset
John Dowson replied to Fess_ter's topic in FSUIPC7 MSFS
There is no poll rate of the offsets, and all offsets are treated equally by the event.offset function. What would be different would be the update rate of the offsets. Most standard offsets are populated and the sim visual frame rate, whereas the PMDG offsets are populated when the PMDG (client) data is received/broadcast from the aircraft. I therefore suspsect that this is related to the data broadcast rate if the PMDG client data. I can do some testing here at some point to check this, but I am not sure when I will have time to do this as I have quite a backlog at the moment... John -
But that is a new ini parameter not available in 7.4.9. Please download the latest beta, 7.4.10c - attached above, and try again. A value of 300 might not be enough for your installation, looking at your log files. Looks like you need a value of 375, but this is currently not possible. Try with 300 first, and if that doesn't work let me know and i will change the maximum value to 500. john
-
Ok, then you can use the presets G58 Fuel Boost Pump R Switch Off G58 Fuel Boost Pump R Switch Lo G58 Fuel Boost Pump R Switch Hi I am not sure why there are not similar presets for the left pump, but you easily add these by adding the following to your myevents.txt file: //Black Square/Baron G58/Fuel G58_Fuel_Boost_Pump_L_Switch_Hi#1 (>A:CIRCUIT SWITCH ON:4, Bool) 2 (>L:var_FUEL_Switch_Pump_1, number) G58_Fuel_Boost_Pump_L_Switch_Lo#1 (>A:CIRCUIT SWITCH ON:4, Bool) 1 (>L:var_FUEL_Switch_Pump_1, number) G58_Fuel_Boost_Pump_L_Switch_Off#0 (>A:CIRCUIT SWITCH ON:4, Bool) 0 (>L:var_FUEL_Switch_Pump_1, number) Maybe, but this is the FSUIPC support forums and therefore I need to show how this can be assigned in FSUIPC for other users who come across this, not how to assign this is using Spad.Next. Anything that you can assign in Spad.Next, you can also assign in FSUIPC. John
-
Yes - I will ask about this on the Asobo forums. John
-
No idea, sorry. FSUIPC relies on the simconnect functions to load/save a flight and has no control over what is actually saved and loaded. You could try reporting this to either Asobo or Fenix. However, also note that the function used to save a flight (SimConnect_FlightSave) is still documented as 'NOTE: The current status of this function is NO ERROR, NO RESPONSE', which is Asobo's way of saying that this function is still not working correctly. John
-
But why did you even try with 105? That was the value I determined for another user based upon his log file. Looking at your log file, the value you need is around 240. As I have said, I will create a FAQ entry on how to determine the value needed. Basically you need to look into the log and find the timestamp of the detected log message: and then find the last 'SimConnect_Open succeeded' message, which from your prev log is this: The difference between those two timestamps is 241.359 seconds, so 240 is a good starting value for this parameter for your installation. John
-
FSUIPC7 location of your UserCfg.opt file.
John Dowson replied to Commandant_Wolfe's topic in FSUIPC7 MSFS
Ok, that is interesting. So it seems that the installer is picking up the environment variables from an 'Admin' account, rather then the user's account. I think the admin privileges are only needed for the registry update and not the installation itself. I will see if I can update the installer to either not request admin privileges, or to only request for the registry update and not for the other parts of the installation process. John -
The default values will be the same as in the current release - 60 (seconds) for DetectToConnectDelayAuto and 5 (seconds) for DetectToConnectDelay. Both ini parameters will have a maximum value of 300 (seconds) and a minimum of 1 (second). I will also create a FAQ entry on how and when to adjust this value from the default. John
-
I have checked these now (in the Asobo G58). The FUEL Pump 1 and FUEL Pump 2 input events work with a parameter of 2 for off, 1 for lo and 0 for high, The deice input events all work with a parameter of 1.0 for on and 0.0 for off. John
-
Ok, that's good. As I said, this issue seems to arise when FSUIPC7 connects while MSFS is starting, and the requests to receive key presses/releases are not honored, even though no error is returned. I will report this to Asobo. The fix would be to use this parameter and adjust to a value where the initial connection attempt succeeds and a reconnection is not required. Regards, John
-
As I have said, you need to tune the DetectToConnectDelayAuto ini parameter when auto-started. Looking at your prev log, you should try a value of 105, i.e. please add the following to the [General] section of your FSUIPC7.ini file and try again with auto-start and auto-connect: DetectToConnectDelayAuto=105 If that doesn't work, try increasing it until you arrive at a value that consistently works for you. John
-
assign more commands to one button
John Dowson replied to ddressel's topic in FSUIPC Support Pete Dowson Modules
This is the forum for FSUIPC7 - use the main support forum for FSUIPC6. I will move your post. To assign multiple commands to a single button press, you can only do this by manually editing your FSUIPC6.ini file. The procedure is as follows: 1. Make sure you have the FSUIPC6.ini file open in an editor. 2. Open the FSUIPC6 window, go to the button tab and make your first assignment Click Ok, then open the window and tab again. 3. In the editor, reload the FSUIPC6.ini file. Locate the button assignment that you just made, then comment this out by inserting a semi-colon (;) after the = sign. Save your changes. 4. Go back to FSUIPC, and click on Reload all buttons. You can now assign your second command. 5. If you want to add more assignments, go back to step 5 and repeat until all your assignments are done. 7. Once all assignments have been made and saved, go back to the editor (with the button assignments tab open) and remove all the semi-colons you added, to uncomment the previous assignments. Save the changes, then go back to FSUIPC and again reload your button assignments. 8. You should now have multiple assignments to the button. The assignments will be grayed-out in the UI and you can no longer edit them. You need to adjust or remove from the FSUIPC6.ini file if you want to update. John -
Not sure what happened previously, but with the attached version FSUIPC7 always receives the key press/release events, so can you try this version please. John FSUIPC7.exe
-
Well, I am not getting any key press/release events through to FSUIPC7 now...no idea what is happening at the moment, but this seems to be a problem with the MSFS SDK. I will investigate and get back to you. John
-
That is quite a few and will certainly affect the start-up time of the FS. You should consider using the MSFS add-on linker program which can be used to limit the community folder to just the items you will be using for the flight -see https://flightsim.to/file/1572/msfs-addons-linker Yes - menu Log -> Buttons & Keys. This may have been because you had not activated the appropriate logging, but these statements are now present in your log files, e.g. 66703 HotKey entry at 3214, VK=48, Shifts=0, Flags=0, Result=0 Can you both try the attached version please. Add the following to the [General] section of your FSUIPC7.ini file: DetectToConnectDelayAuto=240 John FSUIPC7.exe
-
What do you mean by this? FSUIPC7 will give access to all lvars. Please show me this "snippet" - it should be relatively straightforward to turn that into a preset. Are you using the Asobo G58? If so, there are presets for de-icing: G58 PROP DEICE ON and G58 PROP DEICE OFF, and there are several de-ice lvars that you can look at. Alss, look at the Input Events - there are these: DEICE_Pitot_1<;FLOAT64> DEICE_Propeller_1<;FLOAT64> DEICE_Windshield_1<> DEICE_Airframe_1<;FLOAT64> DEICE_Engine_1<> Thee are also Input Events for the fuel pump you can try; FUEL_Pump_1<;FLOAT64> FUEL_Pump_2<;FLOAT64> But that lvar doesn't exist, at least not in the Asobo G58, so I don't know how this can possibly work. I think you should be looking to use the Input Events for both the Fuel pump switches and the de-ice switches. I will take a look later (or tomorrow) to check these and see what values/parameters you need to use.
-
This log shows that FSUIPC7 couldn't connect until more than 3.5 minutes after the sim was detected...very strange. Do you have a lot in your community folder? I will adjust to allow more time to be specified before the attempt to connect is made. No it doesn't. When you stop FSUIPC7, the log file is closed, and when you restart it a new log file is created and the old/previous one is renamed to FSUIPC7_prev.log. I therefore need to see the FSUIPC7_prev.log file if you do this, as that will be the log for when the hot keys were not working. The log also shows that you did not activate logging for Buttons & Keys, and also no hot keys were registered. John
-
Ok, great. Ok, interesting. That looks different from the available presets. Maybe you can share your assignments (presets?) so that other users can use these - i.e. post your assignments here. Regards, John
-
Ok, thanks for the update. There should be no problem when stopping a flight, going back to the main menu and starting a new one. Please show me a log file (no additional logging required) showing your issue, i.e. when starting a new flight, if FSUIPC7 isn't functioning as expected, close FSUIPC7 and attach the log file here. John
-
This is a very old post - I have no idea, sorry. I probably didn't even raise this with them following Roman's post, But things have changed a lot since this post. To control the fuel pump in the G58 (and G36) you can use the available presets and maybe there are also some Input Events for this (I haven't checked). You can also use both presets and Input Events via offsets. John
-
Can you show me/attach a log file please. This parameter didn't exist before 7.4.9. Try the minimum value of 30 (seconds), John
-
I will take a look anyway and either update to allow calls that go to the FS when the thread is terminating, if possible, or I will update the documentation to specify what is allowed in a terminate function. It is interesting that a dying thread cannot send/post messages to another thread (or so it seems) and I would like to understand why and if this can be changed. I can also maybe look into changing the order of things, and process the terminate event before starting the thread termination, but that may not be possible, for various reasons. I may also update to post some messages (asynchronous) rather than send (synchronous) as this will allow subsequent calls to be processed, although the messages still won't be delivered/received/processed, for the same reason as already mentioned, but will allow any other calls to be executed Cheers, John.
-
Ok. This problem is that key presses are not being received and seems to be related to the state if MSFS when FSUIPC obtains the connection and starts requesting data and the key presses. It seems that sometimes the requests are accepted (i.e. no errors) but the request to receive keys is not processed and no key input is received. This seems to be a timing issue related to when the connection to the sim is obtained. I have been adjusting this in recent releases to fix this issue when reported, but this then breaks it for other users. Very annoying... What your users who are experiencing this issue can try is to manually set the delay between detection and connection. This is controlled by the ini parameter (in the [General] section of the FSUIPC7.ini file) DetectToConnectDelayAuto, which uses a default of 60 (seconds). They can try both increasing and decreasing this to see if that helps, e.g. add the following to the [General] section of the FSUIPC7.ini file: DetectToConnectDelayAuto=75 or maybe DetectToConnectDelayAuto=30 (note this ini parameter has a max of 90 and a min of 30). There is also a related ini parameter DetectToConnectDelay which is used when FSUIPC7 is manually started, which has a default value of 5, a max of 10 and a min of 1, Anyone experiencing this issue should play around with those parameters. I would be interested to know if this fixed the issue, and if so what values are used. Also, any log files from people experiencing this would be of use. Cheers, John
-
I can see this issue. Please try the attached version where this should be corrected. This was due to an error on my part - I removed (commented-out) some code that determined the Input Event control number from the name when the number was not available as I had added additional code to reload assignments once Input Events are loaded which would also set the correct control number. However, I then removed this additional code as it was creating further issues and forgot to re-active/uncomment the original code. Sorry about that. John FSUIPC7.exe