[MSFS Stops Responding to FSUIPC]

1 hour ago, John Dowson said:

Could you see any movement of the axis on the axis assignment dialog?

I have not tried it or looked when it happened. If it happens again I will check. These seem to happen at inopportune times (this time on short final), so didn't have a lot of time to troubleshoot (had a few pauses before I was going to crash).

1 hour ago, John Dowson said:

So pause works, which indicates that button input and also sending events/controls to the sim.
You don't have any errors in your log, simconnect or otherwise.

I was triggering Pause with direct (in-sim) bound default keys.

1 hour ago, John Dowson said:

Does this occur all the time, or occasionally? Have you changed anything recently? You seem to keep having issues that get resolved, only to re-appear several days later....

This is the first time. I don't do long flights (pretty much all are <30 mins) and it seems these all take time to manifest themselves. There have no changes in my platform/peripherals, except the upgrade to FSUIPC 7.0.1 and the Profile specific assignment for piston aircraft.

1 hour ago, John Dowson said:

You could try changing this:
    NormalStallTime=-2
to
    NormalStallTime=1

in the [General] section of your ini, although I don't think this will make any difference in this case (as there are no stall messages and simconnect seems to still be working).
You could also try re-activating the SimConnect log file, to see if that reports anything.

 

 

Ack.

[MSFS Stops Responding to FSUIPC]

This issue is similar to when FSUIPC would crash (and control would be lost), however this time there was no crash of FSUIPC, but MSFS would not react to input. You'll see a few pauses where I tried to troubleshoot, but it did not restore input. I had to quit FSUIPC and only after restarting it did controls start working again (without sim restart). The "prev" log is where MSFS stops responding to input.

 

 

 

FSUIPC7_prev.zip FSUIPC7.ini FSUIPC7.log

[New FSUIPC Crashes with MSFS 1.10.7/8]

Ack, will let you know if I see crashes.

[Calibration based on engine type?]

Ok, so I can create a profile and remove the buttons/keys, which would then apply the generic profile?

[Calibration based on engine type?]

What would you suggest for change calibration type based on engine type?

For example, I'd like mixture to not have a "reverse" zone (e.g. cutoff) for piston engines, but should have one for turbines.

Or would you suggest using profile specific settings? Is there a way to apply one certain aspect via a profile, like the mixture (but not, say, buttons)?

[New FSUIPC Crashes with MSFS 1.10.7/8]

3 hours ago, John Dowson said:

Can you also attach your FSUIPC7.ini file please.

What are you starting in your ipcInit.lua? Maybe try without that. Also, if you are still using AxisScanOnSimConnectOpen, then please try without that.

John

Ok, I removed AxisScanOnSimConnectOpen, and will let you know.

My ipcinit and ipcReady simply launch some AutoHotkey scripts, the first to get FltPlan GO connected, the other to change my StreamDeck button profiles for the specific aircraft.

FSUIPC7.ini

[New FSUIPC Crashes with MSFS 1.10.7/8]

I've started experiencing new FSUIPC crashes with the latest patch of MSFS, that don't seem to be related to the transmit client errors.

Faulting application name: FSUIPC7.exe, version: 7.0.0.0, time stamp: 0x5f9c2f1a
Faulting module name: ntdll.dll, version: 10.0.19041.546, time stamp: 0x5b56177b
Exception code: 0xc0000374
Fault offset: 0x00000000000fed29
Faulting process id: 0x5640
Faulting application start time: 0x01d6b061a31e5c25
Faulting application path: D:\IslandJohn\FSUIPC7\FSUIPC7.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: bba1c786-f4c1-4c87-9b49-07142d488354
Faulting package full name: 
Faulting package-relative application ID: 

 

FSUIPC7.log

[Conditional Axis Sensitivity?]

30 minutes ago, John Dowson said:

If I read this from a user-specified offset, then you could have a simple lua to write the max steer speed needed to that offset. The lua could then also read whatever offset it likes to base this value on, and also take a fraction or apply any other type of calibration, also updating when the aircraft changes.

I think that's a great idea, it makes it completely customizable.

[Conditional Axis Sensitivity?]

This is an interesting feature. Any chance this could made so that these are based on the stall speed (e.g. a fraction) instead of absolute values?

[Offset for which fuel selector/tank positions are available?]

It's offset 123E.

Let me try to clarify what I'm trying to achieve.

I have a button which I would like to use to toggle through available fuel tanks selections in sequence (e.g. L, R, Both, Aux L, Aux R for example). In order to do this, I need to programmatically determine which tanks are available in the aircraft through some FSUIPC offset. I see there's an offset for finding the number of tanks, but I didn't notice one for which tanks are available.

[Offset for which fuel selector/tank positions are available?]

I see there's a "number of fuel selectors available in this aircraft" reading, but how can I tell which specific ones are available?

I'd like to assign a key to sequentially toggle through them (except the off position) with a script, but I would need to know which ones I can switch to.

[0x3F02 triggering during flight?]

I was confused between the offset... I see, thanks.

 

[0x3F02 triggering during flight?]

3 hours ago, John Dowson said:

I'm not sure why this is - what is the FLT file loaded when this occurs (check your FSUIPC7.log)?

Yes, a flight file called flights\other\MainMenu.FLT is sent when MSFS enters the menus. I guess I could add some code to ignore this FLT file, and not update the offsets when this changes.

However, as your script acts on the value of offset 0x3D00 (the name of the current aircraft), why don't you just use that for your event? Your script would then fire only when the aircraft name changes.

 

You mean use 0x3F02 for the event trigger instead?

[0x3F02 triggering during flight?]

I have the following ipcReady.lua to switch my StreamDeck profiles based on aircraft (button layout).

function onload(offs, data)
  acft = ipc.readSTR(0x3D00, 256)
  ipc.log("loading StreamDeck profile for: "..acft)

  if string.match(acft, "XCub") then
    os.execute('start D:\\IslandJohn\\Scripts\\sd\\profile_msfs_xcub.ahk')
  else
    os.execute('start D:\\IslandJohn\\Scripts\\sd\\profile_msfs.ahk')
  end
end

event.offset(0x3F02, "UW", "onload")

This works well as it triggers right on the screen with the "Ready to Fly" button.

However it also seems to trigger after I'm in the aircraft (as I started a takeoff roll for example).

It also triggers on return to the main menu.

Is this expected? Is there a better offset to use? I can always just keep state for last loaded profile, just curious.
 

[FSUIPC7 intermittent disconnects: TransmitClientEvent failures]

Ack, will report back when/if it occurs again.

[FSUIPC7 intermittent disconnects: TransmitClientEvent failures]

Here's another instance of FSUIPC crashing (and me, just before landing on a bush strip in strong winds:). This has "extras" logging enabled.

I will now turn on UseAIClient=No.

 

logs.zip

[FSUIPC7 intermittent disconnects: TransmitClientEvent failures]

Just now, John Dowson said:

Maybe you could also try with this added to the [General] section of your FSUIPC7.ini:
     UseAIClient=No

This will instruct FSUIPC to NOT use a separate SimConnect connection for AI, and will use the main connection instead (i.e. no change in functionality). This would help me to determine if the issue is related to multiple SimConnect connections interfering somehow.

Ok, I'll start with Extras logging to not compound issues, until it occurs again (seems to be less frequent).

[FSUIPC7 intermittent disconnects: TransmitClientEvent failures]

3 hours ago, John Dowson said:

@Thomas Richter Those assignments are fine. He's just overloading the previous button press (adding '10' to the entry number, and using offset conditions.

Yes, I'm just doing this for OCD reasons and to keep the numbering grouped in some way for compound buttons. 🙂

3 hours ago, John Dowson said:

These are the ones that should be removed as they are assigned to controls that no longer exist:

I assigned these, but haven't flow a plane to try them yet (I believe they're spoilers), and was not using them in this case (unless I accidentally pushed them).

3 hours ago, John Dowson said:

For the actual problem, I'm still not sure if the TrransmitClientEvent failures are due to MSFS or FSUIPC7. However, when this occurs FSUIPC7 should be able to disconnect and reconnect successfully without crashing. This looks to be a threading issue which I'll look into.

Btw, could you also activate 'Extras' logging. This will add a but more information (namely the thread id of the thread logging the message) which may be helpful.

Thanks,

Ack, will do.

[FSUIPC7 intermittent disconnects: TransmitClientEvent failures]

Well... I finally managed to catch this in the act again (FSUIPC crash) with the latest FSUIPC and 1.9.3.0, while also having SimConnect logging on. All logs and settings attached.

 

logs.zip

[Battery events]

This is awesome, as I couldn't find a way to toggle individual batteries. This works in the Baron for example, so great find!

Unfortunately this doesn't seem to work for Toggle Avionics Master (if param is not 0, it does nothing).

How did you do the "trace"?

[Offset Status vs. Send Control and "Hold"]

Thanks... is there a way to see what events are connected to what things in the aircraft model? For example, on some planes Avionics Mater switch events don't work. Are there options to try to inspect what should be sent instead?

[Offset Status vs. Send Control and "Hold"]

4 hours ago, John Dowson said:

This seems to be a common misunderstanding. The offset status documents is for the read/write functionality offered by FSUIPC's offsets. The data in the offsets table is populated (mainly) from simulator variables (aka simvars), not controls or events. Where an offset is related to a simvar, this is shown in the offset status document in the third column (column G).

Offsets (or simulator variables) can sometimes be updated directly on user request, and others are updated automatically by the model or on sim events (or controls). The read/write status of each offset is also given in the offset status document, together with its previous status in other FSUIPC versions (where it also indicates if the variable is updated by an event 'Ok-SimE' or by directly updating the simvar 'Ok-SimC').

So does updating an offset (thus simvar) sometimes have the same ultimate effect/result as a control would?

4 hours ago, John Dowson said:

Currently I have not provided a list of the available controls, which comprises of those provided by the SDK together with other controls added by FSUIPC. For the former list, you can use the 2016 list of FSX controls provided in previous versions (and attached to this comment). The FSUIPC added controls are  defined in the Advanced User manual, section Additional “FS” Controls added by FSUIP.The 2016 List of FSX and P3D Controls.pdf

It would be nice if this document could split into a table (like the spreadsheet for the offsets) so that we could filter on what works for MSFS (e.g. a checkbox column for each sim instead of the colors).

4 hours ago, John Dowson said:

You could try with Magneto Set, with a parameter of 1 on your button/key press, and a value of 0 on release. But I think that may also time out after a second or two. You could also try with repeat on. However, I think that this is probably how the starters are implemented, with it switching back from start automatically after a short period (or the engine is started).

Ack, will try that.

However, if I'm trying to make a generic starter button (which would need to send both magneto start and turbine start), there's no way to do this with repeat, correct?

If I have to resort to Lua for some things, a QQ: are the scripts loaded each time they're activated (e.g. button press), or are they cached in some way?

[Offset Status vs. Send Control and "Hold"]

I noticed that some of the events listed in offsetStatus doc are not in the send control drop down, for example "GENERAL ENG STARTER:1".

Are they supposed to be?

Also are these new events toggles or settable?

Lastly, in general (for example TOGGLE_STARTER1) how can I achieve a "hold" behavior? If I use toggle starter it will toggle on for only a little while, not enough for the engine to start. Is there a way to achieve a "on while held" functionality?

 

 

[Offsets vs Events vs Control sent when button pressed]

In general, should we use "custom control" and the offsets, or the named event from the dropdown, for button presses? Or, does it not matter?

 

[Offsets vs Events vs Control sent when button pressed]

Thanks. Spot checking, it seems like the official event name from this doc to the dropdown list is to TitleCase it, is that correct?