John Dowson

Can you please attach log files rather than paste their contents - this makes a thread a lot easier to follow. Can you please also show me/attach your FSUIPC4.ini file. Do you not have any controllers? What other add-ons do you have running? Can you please create and show me a SimConnect.log file - instructions here: Me neither...and strange that it was ok for a couple of flights before the problems started occurring...Do you get the same after a reboot? Can you monitor your system resources (CPU activity, HDD usage, GPU activity) during the next flight as well. to see if your system is being overloaded. Also, check the windows event viewer to see if anything relevant (errors or warnings) is reported there around the time you get the errors - check under Application and System (Windows Logs). Your issue looks similar to this very old issue:

Yes. Yes - your assignments are not affected by an update.

I have nothing to add to this topic that I have not already said. Maybe @WP3325 or @Novais75 could report back if they solved this issue... John

This will be moved to an ini parameter when I release 7.2.16, so I suggest that you add the following now to the [General] section of your FSUIPC7.ini file: MaxButtonAssignments=9999 This will prevent issues when you update to the released version. John

No problem. Be aware that such assignments may work ok when using the individual toe brakes, but will cause the rudder to flap a lot when using both toe brakes. You could get around this issue by using a lua script instead, which would combine both toe brake axis readings to produce a single number for the rudder position. John

No

It should, but there seems to be an issue with the calibration using this method (as I mentioned above). You can try it to see if you get the same... Just tried this again and it seems to be ok this way as well - and better as no round-trip of the axis value to the server and back required... Not sure why this didn't work the first time I tried it this way... John

Ok, thats good to know. Thanks for the update. John

This issue should be corrected in the attached beta if you would like to try it: FSUIPC7.exe John

It should, but there seems to be an issue with the calibration using this method (as I mentioned above). You can try it to see if you get the same...

Yes, you can still calibrate if sending to the FS - FSUIPC receives the value back from the FS, masks it (so it isn;t applied), applies the calibration and then resends it. No need to show me the logs/assignments if it is working.... I'm happy we got to a solution for this one!

I should say that this is what I see with my assignments using Axis Mixture1 Set. When I move the mixture in the VC, I see Mixture 1 Set events where: - < 164 is cut-off - between 164 and 16064 is low idle - >16064 is high idle So, switching to assigning with Send to FSUIPC as normal axis, and using Mixture Set and unchecking Exclude MIXTUREn_SET and with No reverse zone checked, I can then set the minimum axis position, Setting this to just below your detent should give cut-off in the range before your detent, and then low/high idle for the rest if the axis range. This is basically what you are trying to achieve, no? John

correct. If by macro you mean preset, then also correct. John

Could you log Axes Controls and let me know the output values you see when you move the mixture lever. I have tested here and see that - any value above -16186 or so moves the mixture out of cut-off to low idle - values between -16186 and +16000 (or so) are shown when moving the lever between the low idle zone - values above +16000 are high idle So, if any small increment above -16383 moves the lever from cut-off to low idle, to allow more movement until low idle is achieved, you should be able to set the min value to just below your detent. HOWEVER, when I try this here the calibration minimum seems to be completely ignored.... not sure why this is at the moment. I will look into this (when time permits, I have a lot of things to look into at the moment...), but would like to know if you see the same. Maybe you could also attach your FSUIPC7.ini so that I can see your actual assignments. John

I will also look into this further...I think offset writes to user-defined offsets are automatically copied to the read area, which is why the 2nd condition would be true. For offsets that have lvars added to them, there should be no copy and the read offset area should only be updated when the new value is received from the FS.

What you could do is just use the offsets for reading the lvar state and change them using calculator code / presets. So, you would define a preset (in your myevents.txt file): Aux_Bus#$Param (>L:XMLVAR_AUX_Bus_ON) And then assign to that preset (with parameters 1 and 0 respectively) instead of the Offset Byte Set control. John

Button assignments are processed sequentially, in order. When assigned 11 is processed, if 10 has already been processed and the value in offset A000 changed from 0 to 1, then the condition for 11 would then be true and so processed. That case is different as it was sending a control, which requires a round trip to the server, and we also never got to the reason why it wasn't working as expected. In this case, it is obvious as the offset is directly changed by the first assignment, so the condition will be true when the 2nd assignment is processed. John

You should be able to achieve this by assigning both left and right brakes to the rudder axis and then manually edit the FSUIPC7.ini file to apply scaling to each axis assignment - see the Advanced User guide section Additional parameters to scale input axis values on page 41 on how to do this. The example given would be how to scale the right foot brake (i.e. use *0.5,+8192), and for the left one you need to scale by *-0..5,-8192. John

Well, as I am not sure what that "code" is or does, it is difficult to say, but I don't see why it wouldn't be possible in lua if its just using custom events and lvars. It may even be possible to implement directly in calculator code, in which case you could just define a preset and use that. The MobiFlight Discord channel would be the place to ask about turning that into calculator code. John

This issue also posted in this topic: I haven't had time to look at this yet...once I've got the next version of FSUIPC7 released I will take a look to see what PMDG have changed and see what I can do about it... John

👍

Ahhh...sorry, I was missing the point here....thought you were talking about the throttle axis for some reason, not the mixture.... For the mixture, can you not just calibrate this on the 4th page of the calibration screen (and assign to mixture1, not mixture). With a reverse zone, you can set the range for the idle zone - it defaults to 8192 but you should be able to set/change this to whatever values you need....so the default would be: and you can calibrate/change to something like (for around 256): ? This is only available on the individual mixture controls - you can map the mixture control to the 4 mixture controls and calibrate there. John

But this is not the case...if you are sending an axis value to an FSUIPC offset, then there is no calibration in FSUIPC. That is up to you. You also need to determine the max/min values od the axis that you use in the lua script, as the values you read will be raw input values, that completely depend on the hardware and drivers used (e.g. for certain older devices/hardware it could be a range of -128 to +128!). The midpoint of an axis that goes from 0 to 16384 is 8192... what you seem to be asking is to calibrate your axis from 0-8192 to send 0-5000 (for example), and then the values from 8192-16384 to send 5000 - 16384. This is, in effect, two distinct calibration settings for different axes ranges If you want to do such things, then this is easily achievable using lua, but you also need to know (i.e. hard-code) the minimum/maximum axis values, as well as the midpoint. I am not going to look into adding such facilities into the UI - it is already over-complicated for most users. Not sure what 'a monitoring Lua' means ... a lua file/plugin is a lua file, and they can be ran (auto-started) as profile specific or not.

That is the same one as referenced in the following User Contributions topic: John

Also see John