John Dowson

This issue is specific to PMDG and I think it is due to FSUIPC's calibration facilities which work well with PMDG aircraft. Try assigning your elevator and trim axes with Send to FS as normal axis and remove/reset any calibration.

I think this may be due to the calibration of the elevator, or maybe the flaps. PMDG aircraft in P3D don't play well with FSUIPC calibration due to priority levels, so maybe this is also the issue with PMDG aircraft in MSFS. Try calibrating the elevator again and see id the problem returns. If so, switch to assigning with Send to FS as normal axis and remove/reset the calibration.

Thanks for reporting back. John

If you would just read the comment where the key file is available, it would save us both some time: As the installer is showing the trial license details, the key file is already in the correct place, i.e. your FSUIPC7 installation folder. John

This change is already implemented in the latest beta if you would like to try it, available here:

If there are no controls logged, you could also try listing the available lvars to see if any look appropriate, and if so try those. Otherwise, you can try using mouse macros.

It is valid. However, trial licenses are NOT validated by the installer. as it says in the comment where the license is available....

If using FSX/FSUIPC4, please use the main support forum. You posted in the FSUIPC7 / MSFS sub-forum. I have moved your post. Try activating logging for events, open the logging console and switch of an engine using the VC. See what control/parameter is logged and try using/assigning to that.

What aircraft are you using? If this is the PMDG 737, then there is already a thread om this topic: Otherwise I need to see your FSUIPC7.ini and FSUIPC7log files, the latter with logging for Events and Axis Controls set, and also add monitoring for the elevator trim offset 0x0BC0 as S16.

For which aircraft? You can try with the standard controls/offsets to see if they work, but for some aircraft you will need to use lvars or presets. It sounds like you just need to assign your key press to the FS control Toggle Taxi Lights - have you tried that? Otherwise, try searching for a preset for the aircraft you are using. If there are only separate on/off controls, you can assign your key press to both controls, and add an offset condition to determine which control to send depending on the current state of the lights. You can check if offset 0x0D0C bit 3 is set or not to determine the current state of the lights. You can also assign to set/clear/toggle bits on that offset to control various lights.

What offset are you using to drive the LED? Sorry but this doesn't mean anything to me. You may have better luck asking about this on the MobiFlight Discord channel, or on Dash support.

You can use event.cancel to remove all event tracking on the same function. This seems overly complicated. Why not just use one script that has a flag (or two) which determine if the brakes should fail or not. You can then set/clear these flags by using an ipcParam variable, and using an event.param function in your script, and assigning with LuaValue to tell the script when to set and clear the brakes failure flags. John

Did you check and try everything in the documentation? i.e. setting the workgroup, checking your firewalls (client, server and router - test with all disabled), Please see the Configure your Network section of the WideFS user guide. Try with the server name specified in the WideClient.ini rather than the IP address, and you should also specify the protocol (try with TCP). Also check that WideServer is activated and running in FSUIPC7. Note that you will need to have an aircraft loaded and ready-to-fly before wideserver is activated and wideclient can connect. I am not sure what those pm log files are or why you attached them. Please also attach your FSUIPC7.log and .ini files.

Sorry - I fixed the handling for the key press in unregistered versions but forgot the release. Could you all try the attached version please: John

Can you please specify the FS and version of FSUIPC you are using please - this always helps. Depending on the version of FSUIPC you are using, it may be just a simconnect text window. See this support request which is as you reported: Note also that mouse macros are not available for all aircraft - it depends how the aircraft is implemented. This affects more aircraft in FSX than P3D.

The only differences between the two ini files that I can see that could affect your PMDG profile are: 1. Flaps calibration: in your old/bugged in you have flaps ranges calibrated: 2. In your old/bugged in you have the spike removal options set: 3. Elevator calibration in your old/bugged ini looks slightly off (mull zone looks off centre, but this should not be an issue), and not calibrated in the working ini : Anyway, keep the ini as-is for a while to confirm the issue has gone. Then try adding them back one-by-one to see if any make the issue return. You should calibrate your elevator axis so I would start with that. John

Comments are generally allowed in most sections, but not in all. I can update to allow comment in the [Auto] section. I will add for the next release. John

That offset is in a range assigned to the A320 FMGS (Jean Luc Nitard), amongst other software - FSUIPC does nothing with this offset. Not sure what you mean, but you need to determine what to use for the lights controls - if standard events don't work, you may need to use lvars, hvars, input events (b vars) or more complex calculator code (maybe via a preset). You can send all such controls via offsets - see 0x3110 and 0x7C50. You can also use these offsets via lua, or there are dedicated functions for most control types. John P.S. I have deleted your duplicate post.

It always helps if you specify the FS and version of FSUIPC you are using. Can you please attach your FSUIPC .ini and .log files, the latter generated with relevant logging activated- Buttons & Keys and Events or Axes Controls. Just load your aircraft, activating the logging, move the lever assigned to the function not working then exit and attach your files.

@Coast_Flyer This issue should be fixed in the latest release of Spad.neXt.

Just looked at the traffic tables using TrafficLook while sitting on the tarmac at EGLL. The airborne-to-ground transition looks to be fine - I see the aircraft in the airborne view going from Enroute, runway assigned, and then at around 10nm the status changes to Landing, It then either goes to GoAround or is removed from the airborne table and added to the ground table still with status Landing, this soon changes to Rollout and then Taxi-in. So the tables seem to be holding the correct data. Can you maybe try using the TrafficLook client. It only shows one view at a time (Ground or Airborne), but you can run two copies to show both at the same time. If you see the same aircraft in both tables, take a screenshot and show that to me please. John Later: after a couple of hours monitoring the AI traffic, I see all aircraft removed from the airborne tables when landed, and I then see them in the ground tables if in distance, so I can't see any issues.....

Hi @cellular55. Sorry for the delay in looking into this. I will look now over the next few days. But there is no LANDED status for AI traffic - where do you get this from? This is the list of AI Traffic State strings, which iis what FSUIPC uses, from the SDK documentation: FSUIPC uses the SIM ON GROUND flag to determine if the AI aircraft is airborne or on the ground, Anyway, I will do some testing here now and get back to you. John

Yes, there were some issues with .3 fixed in .4. There are only a few changes between .2 and .4, and these related to the a/c going in and out of the parking state, i.e. when the user goes from the main menu system to ready-to-fly, and when going back from a flight to the main menu system.

Yes, sounds like a good idea. The A/P, once engaged, should be controlling the trim, so I don't think its this that can be causing your issue. Logging is always useful - sometimes the visuals in the VC can be different from the actual setting in the a/c, so worth monitoring, and it costs nothing. John

Thats very strange, but if it doesn't happen every time, then it cannot be related to the number of clients connected. I have no idea what could cause a client to fail to connect so irregularly, and there has been no change on the SDK side for many years,