sabres431 Posted October 18 Report Posted October 18 This is from the Flight1 discord: FSUIPC detects data such as landing, taxi, strobe, runway lights on/off, speed, altitude and more from the simulator. The APLv2 add-on I use gets data from FSUIPC and rates my flights. When I turn on the taxi lights toggle, FSUIPC gets data such as landing lights on. This is wrong. Runway turnoff on as taxi on. Separately or together toggles always transmit data such as taxi axis lights on. It doesn't need to transmit anything. When I open the "front cargo door" from EFB the airplane transmits data such as strobe lights on, but the toggle switch is off. It doesn't need to transmit anything. Flight1's response is that this is fsuipc developer's issue to fix. I'm 100% sure this is not your problem, but would like validation to send them back to the drawing board.
sabres431 Posted October 18 Author Report Posted October 18 Flight1 again responds that they have nothing to do with how the MAX interfaces with fsuipc. If this is the case then I've been misunderstanding for a long time how fsuipc works
John Dowson Posted October 19 Report Posted October 19 (edited) Sorry but i have no idea what your issue is.... Be aware that FSUIPC is aircraft agnostic (generally, although it does have specific offsets for PMDG aircraft). If any offsets or controls are not working for a given aircraft, it is because the aircraft does not use that event or simvar. 10 hours ago, sabres431 said: FSUIPC detects data such as landing, taxi, strobe, runway lights on/off, speed, altitude and more from the simulator. It will only detect these if the aircraft you are using uses the standard simvars for these data points. 10 hours ago, sabres431 said: The APLv2 add-on I use gets data from FSUIPC and rates my flights. I have no idea what APLv2 is... 10 hours ago, sabres431 said: When I turn on the taxi lights toggle, FSUIPC gets data such as landing lights on. This is wrong. What is wrong? Proof (i.e. logs)? Explain what you mean by 'gets data'? I think you are either mistaken, or the aircraft you are using is not implemented correctly...there has been no change in the lights offsets (0x0D0C) for many years (if that is what you are talking about). If they are reporting the wrong data, then the aircraft is setting the wrong data and needs to be reported to the aircraft provider. But I think it is more likely you are either misunderstanding something or have an error somewhere. What do you mean by ' If you have an issue, please show me your files - your FSUIPC7.ini and FSUIPC7.log files, the latter with appropriate logging activated for your issue...whatever that is... 10 hours ago, sabres431 said: When I open the "front cargo door" from EFB the airplane transmits data such as strobe lights on, but the toggle switch is off. It doesn't need to transmit anything. But what has this got to do with FSUIPC? FSUIPC just reports and responds to the events seen/received.... Sorry, but I really have no idea what you are talking about...please explain more clearly, if you think this is an issue with FSUIPC... 8 hours ago, sabres431 said: Flight1 again responds that they have nothing to do with how the MAX interfaces with fsuipc. If this is the case then I've been misunderstanding for a long time how fsuipc works Maybe.... PS: I am now on holiday/away for a long weekend, back on Wednesday.... Edited October 19 by John Dowson PS added
sabres431 Posted October 19 Author Report Posted October 19 12 hours ago, John Dowson said: Sorry but i have no idea what your issue is.... Be aware that FSUIPC is aircraft agnostic (generally, although it does have specific offsets for PMDG aircraft). If any offsets or controls are not working for a given aircraft, it is because the aircraft does not use that event or simvar. It will only detect these if the aircraft you are using uses the standard simvars for these data points. I have no idea what APLv2 is... What is wrong? Proof (i.e. logs)? Explain what you mean by 'gets data'? I think you are either mistaken, or the aircraft you are using is not implemented correctly...there has been no change in the lights offsets (0x0D0C) for many years (if that is what you are talking about). If they are reporting the wrong data, then the aircraft is setting the wrong data and needs to be reported to the aircraft provider. But I think it is more likely you are either misunderstanding something or have an error somewhere. What do you mean by ' If you have an issue, please show me your files - your FSUIPC7.ini and FSUIPC7.log files, the latter with appropriate logging activated for your issue...whatever that is... But what has this got to do with FSUIPC? FSUIPC just reports and responds to the events seen/received.... Sorry, but I really have no idea what you are talking about...please explain more clearly, if you think this is an issue with FSUIPC... Maybe.... PS: I am now on holiday/away for a long weekend, back on Wednesday.... John - You answered exactly how I wanted to hear it. I KNOW it isn't an issue with FSUIPC. Ifly is saying that it isn't their issue and sent me here. I'm doing as requested and now will ship your answer back as your answer is how I already knew FSUIPC works. APL is A Pilots Life, It uses fsuipc to pull in data, like lights on/off, gear down, speed etc. and scores you on their appropriate use.
John Dowson Posted October 19 Report Posted October 19 7 hours ago, sabres431 said: APL is A Pilots Life, It uses fsuipc to pull in data, like lights on/off, gear down, speed etc. and scores you on their appropriate use. Ok. Be aware that FSUIPC populates offsets for data based upon the standard simvars, which used to be used by most aircraft (but not all!). With MSFS2020, many more aircraft, some default and many add-ons, don't use or respect the standard simvars, and may use lvars, bvars (input events) or hvars (html variables) instead. If this is the case, then the default offsets won't work / hold the correct data. What you can do for such aircraft is determine what holds the correct data, add this to an offset, and then you can instruct FSUIPC to 'spoof' the reading of the original offset (that the 3rd party app is reading) to read the value of the correct value and supply this instead. If you want to do this, you need to know what offset is being read by the third-party app, and what holds the correct value. If you know this, I can help you with the rest... John
Giuseppe Reda Posted 18 hours ago Report Posted 18 hours ago (edited) Hi John, I'm joining the discussion because I have a similar problem. So, I use the Prosim software (737-Max) for my home cockpit. The problem is that when, for example, I turn on the taxi lights i saw that at the same time Prosim activates in some way on the offset 0x0D0C also the navigation lights and the landing lights even if these visually do not turn on on the plane but in the offset mentioned the bits related to these (bit 0, bit 3, bit 2 etc...) are activated together with the main one just activated (taxi). Since i use an external software that reads the data from Fsuipc and that have the function of giving scores on the flight conduct (A Pilot's Life is the software), this incorrectly read the real situation. So I started to see if the spoofing could help me and i managed to partially solve the problem with the file that I attach here. I said partially solved because I can only get the spoofing to work correctly for the taxi light, as can be seen from the file (in fact now when I activate the taxi light switch, only the bit related to the taxi is activated in the 0x0D0C offset without contextual activation of the others as it did before). But what if I have to add the spoofing for the other lights, such as Anti-collision, landing lights etc.... which have an lvar each in the same Lua file? I tried everything but as soon as I add management of another light and activate the switches to try, the bits values are reset and set to 1 intermittently, it's as if it can't manage more than one condition. Surely i'm definitely wrong, but what can i do to solve? Since the values that i control are in the same offset and are expressed in bits, I don't think there is any possibility in ipc.writestruct to indicate the bits of an offset but only whole offsets. Is there a way to solve it? Thanks in advance. Giuseppe Reda Edit... In the meantime i solved ... but just for my info, can you give a look into the file (prova2.lua) and tell me if the solving method is the better way to solve ? It's already efficient ? or i must modify it using another method to make it more efficient ? Thanks in advance. Giuseppe Reda prova2.lua Edited 1 hour ago by Giuseppe Reda update
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now