KDN Posted June 29, 2016 Report Share Posted June 29, 2016 Hi all, So I have been trying to use some 3rd party gauge software in combination with P3Dv3 and FSUIPC, the issue I have is addon aircraft (A2a) using their own offsets. I am using a LUA script that should provide the correct values, however the lua makes no difference at all, the gauges still display the incorrect values. The script I am using is attached. since I like to keep things simple, I changed the script to this: Eng_RPM = 2100 Expected that my gauge should show 2100 as soon as the plane loaded (as proof the script was doing something), however they did not, infact they showed the exact same information they always do. help please :) A2Agauges.lua Link to comment Share on other sites More sharing options...
Pete Dowson Posted June 29, 2016 Report Share Posted June 29, 2016 9 minutes ago, KDN said: the issue I have is addon aircraft (A2a) using their own offsets. An A2A add-on using FSUIPC offsets? I don't think so. There are certainly none reserved for A2A and they've never requested any. Looking at your Lua briefly, it seems to only be reading standard FS offsets. and, for a "C172" and a "C182" amd a "Cherokee", a series of L:Vars (local panel variables). Are these the A2A ones -- not offsets but gauge values? Does the script work with default aircraft? How are you loading it? You can check the names of the L:Vars and see their values by using the "List local ..." control in FSUIPC's assignments. If no error is being logged for the Lua script in FSUIPC's LOG file, then it will be doing what it says. I think you may need some assistance with your 3rd party gauge supplier. Pete Link to comment Share on other sites More sharing options...
Gypsy Baron Posted June 29, 2016 Report Share Posted June 29, 2016 Just to help clarify, much of the A2A Accu-Sim code is done 'outside' of FSX so the standard A:Vars often are not representing what the Accu-Sim engine is doing. The user needs to use the L:Vars to obtain the 'accu-sim' data for use in any custom gauge/display. Also, reading the L:Var data and writing it to a 'normal' FSX offset may not work if FSX is updating that offset. It does appear that the OP is attempting to save the data to user-defined variables, which should work, but the lua script is rather 'untidy' and difficult to read so I can't really do much in the line of checking for errors in the script without reformatting the script. As much as I would like to help, I am about to head to the airport in a few hours for another 'vacation' I just don't have time to investigate his issue. Paul Just a quick thought....how is the script in question being launched? I see no 'on event' or any other means to launch the script. When I use scripts I use 'functions' that are triggered by events, time,offset changes, etc. . This script is just 'hanging there'. Another EDIT> I just noticed that it appears there is a missing "end" in the script. The single 'end' there is not 'bold' in my script editor like all the others that are properly 'paired'. Adding an 'end' before the 'sleep' seems to satisfy the situation, then I looked further and inserted what appeared to be an if-then-else segment without a terminating 'end'. I just can't remember now where I placed it. I'll try to attach my edited script here. Oh, and please use indentation to differentiate the various if-then-else-end segments for easier reading/debugging. A2Agauges.zip Link to comment Share on other sites More sharing options...
Gypsy Baron Posted June 29, 2016 Report Share Posted June 29, 2016 Here is a screenshot of the re-formatted script in my Lua script editor. Hope this helps. Paul Here is a zip of the above image for easier reading: script_formated.zip Link to comment Share on other sites More sharing options...
KDN Posted June 29, 2016 Author Report Share Posted June 29, 2016 Hi Paul, thanks a ton, I will try this out this evening when I get home and report back with my results, And yes that was my concern also, I dumped a lua file into my modules folder and that was basically it, I thought I would need to do something to invoke it like assign a button to run it and press it everytime the sim started. Link to comment Share on other sites More sharing options...
Pete Dowson Posted June 29, 2016 Report Share Posted June 29, 2016 5 minutes ago, KDN said: I thought I would need to do something to invoke it like assign a button to run it and press it everytime the sim started. You can do that, or you can make it load automatically by adding it to an Auto section in the FSUIPC4.INI file, thus: [Auto] 1=Lua A2Agauges If you already have some entries then just number the next one. Pete Link to comment Share on other sites More sharing options...
KDN Posted June 30, 2016 Author Report Share Posted June 30, 2016 (edited) Hi guys, Ok so I downloaded Paul's tidied up copy of the LUA script, and invoked it under auto in the FSUIPC4.INI file. However unfortunately the results have not changed. It would seem my gauges are still displaying the default values on the C172. (default aircraft work fine). RPM is particularly the worse being 400-1000rpm off. Just a query on one of Paul's statements above, does my gauge software need to be looking for a particular offset? I have two different products I am using, one is looking for the default rpm value (which I thought this script is overwriting) and the other I can set it to look for a particular offset so I set that to: RPME0 = double,66C0 Both programs show the same values on their gauges. Ideally I would like the first situation to work, where the default RPM value is overwritten with the correct values from the L:vars so any 3rd party application should work out of the box, is that what my lua script should be doing? ** just to add, so I printed the local vars with full throttle and this is what I saw in the log for RPM: L:Eng1_RPM = 2139.263506 the 3rd party gauge however only showed 1500 thanks Edited June 30, 2016 by KDN Link to comment Share on other sites More sharing options...
Pete Dowson Posted June 30, 2016 Report Share Posted June 30, 2016 55 minutes ago, KDN said: (which I thought this script is overwriting) No no no! It is writing values to the user offsets in the range 66C0-66FF. The default FS values will be constantly overwritten by the FS values, on every frame or even more often! For most aircraft your script is simply copying over the default FS values, but for selected aircraft it is getting the L:Var (Local panel variable) values and copying those into the user offsets instead. Quote Ideally I would like the first situation to work, where the default RPM value is overwritten with the correct values from the L:vars so any 3rd party application should work out of the box There IS a facility in FSUIPC to "spoof" FS offsets, by feeding applications false values instead of the FS ones, but that is not so straightforward. This is described at offset 0024 in the FSUIPC4 Offsets Status document, and there is a Lua example of it being used in the Example Lua plugins ZIP -- it's called "Liar.lua". Pete Link to comment Share on other sites More sharing options...
KDN Posted June 30, 2016 Author Report Share Posted June 30, 2016 Thanks for that reply Pete, I will have a look at the liar script! However in that case, for my (second) program "simplugins panels" that is reading the user offset for the RPM gauge, in theory I should be seeing the correct values by calling offset 0x66C0. Is there any way I can see what value 0x66C0 holds at any one time? If it holds the correct value (ie it is the same as what I see in the virtual cockpit display in the A2A aircraft) then I promise to leave you in peace and talk to the panel providers! Link to comment Share on other sites More sharing options...
Pete Dowson Posted June 30, 2016 Report Share Posted June 30, 2016 4 minutes ago, KDN said: Is there any way I can see what value 0x66C0 holds at any one time? Of course -- the Monitoring facility in the Logging tab, right-hand side. Just enter 66C0 as the offset and FLT64 as the type, and select Normal Log or FS Window below (or both). Pete Link to comment Share on other sites More sharing options...
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