John Dowson

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,

Then read this thread and you will see a version attached above that fixes this issue....

No limit that I am aware of (but I can check this tomorrow). If you change the order of starting the programs, it is always the last one that fails to connect? And this was fine until a dew months ago? Can you remember the last FSUIPC7 version number when they all connected?

Try this version - no need to wait until tomorrow.... FSUIPC7.exe

I think I know what the issue is - I will post and updated version for you to try tomorrow. John

It would also be useful if the first log showed the reduced climb rate, as is usual, the aircraft recovers the climb rate when FSUIPC is stopped, and the second log shows the climb rate reducing again. Try not to touch the controls after the restart. The second log would then show the elevator trim and spoiler positions on start-up, and if these change as the climb rate reduces, and we can then see the controls that are causing this and hopefully determine where they are coming from.... John

First, can you add DontLogThese=67030,67038,67039,67040,67227 to the [Profile.B737PMDG] section of your FSUIPC7.ini - this will prevent the LIGHT_POTENTIOMETER_SET and LIGHT_POTENTIOMETER__*_SET events from being logged, which are of no interest and are filling your log files. Okay, but this is strange as the controls logged are for spoilers down, not up... The offset logging shows that both offsets 6C3C (TRIM_StabTrimMainElecSw_NORMAL) and 6C3D (TRIM_StabTrimAutoPilotSw_NORMAL) held a value of 1 both before and after the restart, and the other two offsets never changed value from 0. Did you not get the STAB OUT OF YTIM warning on this flight? It seems not, so this was another red herring... Ok, so you think that it is the elevator trim that is causing this issue? We did monitor the elevator trim offsets in a previous test and the values, and therefore the elevator trim settings, were the same values just before you stopped FSUIPC and when you restarted, so it looked like the trim hadn't changed, so I am confused now... I cannot tell the trim setting (not logged!), but these are the control stand trim wheel controls (678), and show a 'mouse move' (03) action: The controls being sent before the restart were these: 984844 *** EVENT: Cntrl= 66587 (0x0001041b), Param= 67803 (0x000108db) ROTOR_BRAKE These are also from the control stand wheel trim...also logged when you restart. 985672 *** EVENT: Cntrl= 66587 (0x0001041b), Param= 200703 (0x00030fff) ROTOR_BRAKE This is a control to hide/show the captain's yoke. Not sure why there are so many of these... Spoiler/speed brake controls are here: So it looks like the speed brake is/was in the down position when you stopped FSUIPC.... So it looks like we are back to it being either the elevator trim or the spoilers/speed brake that is causing a decreased climb rate. Can you monito/check those settings both before you exit FSUIPC and again when you restart. Maybe also add offset logging back for these: 0BC0 as S16 (Elevator Trim Pct) 2EA0 as FLT64 (Elevator Trim Position) 0BD0 as U32 (Spoilers Handle Position) I will also ask Pete about this to see if he has any ideas... John