Pete Dowson

So FSIpanel is using the runway data and it's orientation, which has to be corrected for MagVar. That's more like what i would have thought. I'm amazed the FSAerodata does not amend the runway entries. Those are far more important than the airport MagVar which is really not used for navigation at all. Maybe it has only omitted doing so for this one airport. Did you check, for instance, Paris de Gaulle (LFPG) or other likely affected airports? Note that it can amend the runway entries without actually changing that APX BGL. It shouldn't really change existing files. All it should do is include the runway entries in its BGLs, so that they override the lower priority entries. If the magvar changes enough to force a change in runway designation they's surely have to do this -- and with approriate "delete" entries to stop two runways being derived with different designations. Pete

The only point in looking at the Runways.txt log was to see the priority oder. The airport Magvar isn't logged there. But as you saw in your Runways.xml file, it is certainly the LFPO_SIDS.BGL from which that MagVar is obtained. So my previous message applies. The main question must be to the fsaerodata folks as to why they are changing the Airport Magvar to a wrong value (you said it should be -2.00), ad they are not doing this with the runways. How is your program adversely affected? What is it using airport magvar for in any case? Surely only the runways orientations magnetically are important. Pete

So fsaerodata makes the airport value wrong, but leaves it okay for the runways? Why use it if it makes things wrong? What do the suppliers say? Well: 1. It is evidently created or amended by fsaerodata, so they are best placed to answer properly, but 2. It definitely contains an airport definition, which is why MakeRunways picks it up. And 3. Because it is apparently at the top of the priority list it takes precedence over any other such records. That's the whole point of the ordering of priorities. None of the BGLs you supplied appear to contain any sort of record which MakeRunways recognises as relating to an airport other than the header type data with name, coordinates, altitude and magvar. Those are in both LFPO.BGL and LFPO_SIDS. BGL. Take a look in your Runways.txt file. That's a log of the rersults for every file containing airport related data of any sort which is of interest. Search for each entre starting "Airport LFPO" and you'll be able to identify each relevant BGL file for that airport. Each later one will have details replacing or adding to the ones before. There can also be "Delete" entries which delete specific stuff from lower airports. They tend to be used when replacing navaids, runways, gates taxiways, etc when the IDs are different -- otherwise they'd be accumulative, so getting runway 24 as well as 23, for example, where the mag var has changed sufficiently to warrant a new designation. I wonder if it would be worth trying to get LFPO.BGL processed AFTER LFPO_SIDS.BGL, which would make the former higher in priority. I think you might achieve that by simply renaming it, say LFPO_XYZ.BGL. Pete

Nice that you solved it. Thanks for letting us know. Pete

How is fsipanel going wrong? Are you expecting it to show 0.78 or -2.00 and it isn't, or what. You need to know what it is reading and why. I tried to analyse LFPO_SIDS.BGL with ADE (airport design editor), but is contains nothing to analyse. Having only that providing the modification of the variation from fsaerodata or Herve Sors updates seems odd. The important values are surely those connected to the runways as they will affect the magnetic headings of the runways (the true headings don't change of course). I don't really see what I should do any differently in MakeRunways. Having different variations for the same airport just seems wrong. Pete

Actually, it was quicker to debug this using the files you supplied. The thing is, the Magvar entry in the XML file is from the AIRPORT data, whilst the ones associated with runways in the individual runway entries is in the specific runway sections of the BGLs. Both of these are in the same place in the same tables I create the files from, but there are separate sections for AIRPORT, RUNWAYS, GATES and TAXIWAYS. Oh, also COMMS. It looks like your fsaerodata updater only updates one of these -- the airport headers, not the magvar associated with each runway. I think perhaps this could be a problem with ILS orientations. I did once subscribe ot faaerodata, but these days, when I think of updating these things, I use Herve Sors freeway updates. Might be worth you trying those instead? http://www.aero.sors.fr/navaids3.html Let me know. Of course, mostly I only fly to/from addon airports which tend to have updated data in any case. Pete

Thanks. I'll take a look within the next few days, max a week. Pete

Presumably that's the file fsaerodata amends, and not the default. However, my first reply still stands -- the exact same table entry is used for both files and at the same time. Yes, but for some reason 3 of those aren't enabled ("Active=FALSE"). Ah, i see you experimented with activating those after. But all that cannot make any difference when the same value is used at the same time for all. Maybe I just need whatever FSAD BGL is it which was logged for your XML file. There's no way of solving it by discussion. Pete

Well, that is really inexplicable. Maybe, if you supply the BGL concerned which has been modified by fsaerodata, I could track it down. But I don't think i'll be able to do that soon. I'm really tied up for the next few days. the BGL is Scenery\0601\scenery\APX48140.bgl Pete

Don't just delete assignments in P3D. Tell it not to use any controllers -- a check box in the last option in P3D's Controls Assignments menu. And test with a default aircraft. Some add-ons do not like FSUIPC's calibration because it results in it sending controls to P3D at a different SimConnect priority. Pete

MakeRunways merely reads the data in the BGLs. FSAerodata modifies those. Whilst processing the BGLs the program builds tables containing all the data needed for the various files it produces. It only makes the files at the end, when it has finished the complete scan. The MagVar put into both R4.csv and Runways.xml are both from the same value, the same entry in the table.. The two code lines doing this for those two files are close to each oher and there's no way the value can be changed in between. So, the only explanation for your findings is that the R4.csv is not being written. Something is stopping this -- maybe it is open somewhere, or protected from writing. Try deleting it first. Pete

Good. well done. If you want the Lua to be launched with the start of FSUIPC you need to add the section to the FSUIPC INI file: [Auto] 1=Lua <name of your lua file> Or you can have an ipcReady.lua file in the modules folder whhich containas the line: ipc.runlua("<name of your lua file>") ipcReady.lua is executed automatically when FSUIPC detects that the Sim is "ready to fly". Pete

First, your FSUIPC4 is way out of date,, and changes have certainly been made in this area since 4.968. The currently supported version is 4.974. Update your copy then try again. If there is still a problem, as well as the fresh Joyscan file we need to see the FSUIPC4.INI and FSUIPC4.LOG, please. The JoyScan file does show some worrying indications, though. None of the 2235- devices (three of them: 2xCON, 1xDP) give returns when their data is read during the scan, nor in fact does the "DP3T Emulator". Three of those 4 devices are being accepted by FSUIPC "with reservations", whilst, as you found, one of the 2235-CON devices is not accepted at all. It is likely that if you only connect one of the two identical devices at a time, Windows is identifying both as the same device -- it can't tell any difference by reading their IDs. When we do get you sorted with both devices, they will need to remain connected all the time and to the same USB ports, else there will be a mix up with the assignments. Pete

The buttons screen merely sends button presses to FSUIPC. You need to program them in FSUIPC. All you do in WideClient.INI is define labels and colours and whether they "toggle" or not (toggle = press on press, release the next, acting more like a light switch, instead of press/release actions of ordinary buttons.) So you need to refer to FSUIPC button assignment facilities. i think the sort of switch you illustrate would be best and most easily served by two button press assignments, one for up and centre and the other for down and centre. Pete

Without telling FSUIPC to load from that folder it wouldn't have run -- unless you explicity loaded it from that folder using an ipc.runlua function in a Lua which was loaded from the Modules folder! It that case it is evidently a problem with your Arduino programming. That is a different script from any other you've mentioned or shown. The LuaFiles section lists all Lua files which have ever been seen in the Modules folder. It doesn't mean it is still there or that you are running it! It isn't better for me. It is just more sensible as then the processor is not wasting time executing your script, but simply sitting waiting for the LVars to change. And the suggestion is very sensible. Most of the best and most relicable scripts these days use events for that reason. But it was a later addition to the Lua facilities in FSUIPC, which is why there are examples of both still abounding. I actually think since then you've been confusing yourelf and me posting contradictory messages many times. The VSI one for instance was never mentioned before you said it didn't work any more, and then this iall the wrong assumptions you make ad repeat like that concerning folders and script names. I don't need to try to help any more -- just don't post! 😉 Pete

Unfortunately it isn't a good idea to mix like that, as P3D may decide to auto-assign the other axes. Choose one or the other otherwise you are likely to get conflicts. The best way to use the FS controls is to assign to FS controls in FSUIPC. They do exactly what the P3D ones would except for allowing P3D to read the axes directly. Pete

This part I don't understand: "while my script with the event.Lvar() function is on a folder name "RPM.lua" in module folder, as C172.Lua" Why have you named a folder "RPM.lua"? Such a folder name doesn't make a lot of sense, and FSUIPC won't look for lua plug-ins in such a folder unless you change the path for ALL lua files by adding the parameter LuaPath=<path to lua files> to the [LuaFiles] section of the INI (with the path you wish to use instead of Modules), which you have not done. And you evidently do have a C172.lua file in the Modules folder, possibly without your extra code for the VSI? You have enabled Lua logging in the Logging options. That traces through every step. We were only looking for errors in the script which would be reported in ay case However, now that you have enabled the logging, we see these entries: so it seems after all that the C172.lua in the MODULES folder (NOT the RPM.lua folder as you stated) does contain the VSI code, and a value (-4 in this case) was returned. The 28, 31 and 32 are line numbers in your lua program. Now that is more lines than in the last Lua you posted here, so I can't look at those, but you can, and you know now that they were executed and did have the value. You have an unprintable character, that one represented by ï in the log, which is non-ASCII (It's part of the Windows implemented extensions to ASCII, using the 8th bit -- ASCII only uses 7 of the 8 bits in a byte. Lua only handles straight ASCII. Best to delete that line completely and re-enter it, taking care with the keyboard. Those characters (special ones and those with accents) can be entered with various keyboard press combinations or sequences. However, you were asking about VSI which was mainly what I was responding to. When you are writing to offsets you can easily check that the values you expect are being written there by using the "monitor" options in FSUIPC Logging. See the right-hand side. You can monitor up to 4 values at a time. Just enter the offset (just the 66C3 part, not the 0x), and the type (in this case S16, a signed 16-bit or "Word"). Then below select normal log to see the vlaues in the log, or FS window for a display on screen as it changes. If the values in the offset are correct, then look at your Arduino programming! Pete

No, that was good. I thought it would help you, in future or further ventues into Lua plug-ins, to know WHY it was wrong, that was all. sorry if this insulted you! If you look in the FSUIPC documents subfolder (where all the odcumentation is, by the way, in case you ever want to look at it), you will find a ZIP file called something like example lua plug-ins. There's one inside that called "log lvar". If you run that you will get a display on screen of the changes in the LVars associated with your current add-on aircraft. You never showed me one for the vertical speed. Well, you've changed something else then. Use the plug-in I mentioned to check the LVars and their changes. It's by far the best way to see what is going on. The log section you posted ends with 49859 -------------------- Starting everything now ---------------------- Nothing is running before that line in any case, so why post it? Pete

That's because the Lua syntax is all wrong. Please do refer to the Lua library document when using this facility. Even if you "found" a working example elsewhere since, i need to point out the errors in this short script: function(Eng1_RPM, value) -- The correect syntax, as clearly documented is (for a function named, say "RPM1") function RPM1(name,value) event.Lvar("L:Eng1_RPM", 100, Eng1_RPM) -- First, placed in the function, it will only do anything when the function is called. But how can it be when there's no event for it?. -- Second, the function name (the one being called) is a string and needs "...". So: event.Lvar("L:Eng1_RPM", 100, "RPM1") -- but placed at the end of the script ipc.writeUW(0x66c0, Eng1_RPM) -- The value returned you've called value. The Eng1_RPM would be replaced by the name of the LVar, as a string (i.e. "Eng1_RPM"). Please do not try to "wing it". Refer to the documentation! That is what it is for. It would save both of us a lot of time! Also, when testing a Lua plug-in, when it doesn't work CHECK THE FSUIPC log file. If there are errors stopping it running (as in this case) this will be logged. Does the Lvar monitring plug-in provided in the Lua example plug-ins ZIP show proper values for that LVar name? That's your check. Also, as just stated always check the Log for errors. Pete

You need to save the SimConnect.ini file that John showed you into that folder! Then it wouldn't be empty! Simconnect.INI isn't created by P3D but by you. In [SimConnect] level=normal console=no file=D:\SimConnect.log You can put whatever path you like in place of the D:\. That would just save it to the root folder of your D:\ drive. You do not have to install Simconnect -- it is built into P3D. Some thrid party programs, run outside of P3D, might need such a version -- the older ones are for FSX and FSX-Se, with a different one for each FSX build and for fSX-SE. Programs written for FSX may need one or the other. But FSUIPC is a DLL which runs inside P3D and doesn't need a separate older Simconnect. In any case they are all 32-bit and FSUIPC + P3D4 are 64-bit.

In that case use your current SimMarket account to post a ticket asking why. Sorry, i can't help. I am not involved is that side of things. You need to deal with SimMarket. Pete

All the checking does is rescan the joysticks, which would wkes them up. somehow not using the buttons for a period is letting then or the Bodnar boards go to sleep. The Windows power management option is the only thing I know which can do this. FSUIPC will also rescan if you unplug the USB and plug it in again. This will also have the same effect. Changing it in Device Manager Properties for each USB port is always fixed. it is recorded in the registry. Are you pressing OK or confirming in whatever way is shown? It sounds like you are cancelling the change in setting. There is no way it will turn itself back on. FSUIPC runs at whatever privilege level you run P3D at. It can do nothing else. It is a DLL running within P3D! Though I cannot see what that would make any difference. Does SPAD do the job if it isn't run "as administrator"? Pete

You should be okay, provided the joystick IDs haven't changed. If you've already run the FSX install, check the JoyNames section of the generated INI file -- see if they are the same joystick IDs in use in your assignments. If they aren't, you could try changing the IDs. For that you can use the JoyIDs program, available in this thread in the FAQ subforum: Pete

No, it is SimMarket exclusive, except for an old Japanese version which was sold in Japan (I don't think it still is). By "IP address" do you really mean email address? If so, how did you post here which needs registering using your email address. This is a SimMarket/Simflight website (it is the one company). Try creating yourslef as a new user for SimMarket, then post a "ticket" reporting the difficulty you are having and asking for a resolution. you'll need to give your previous email address and password. Pete

You need to specify which LVar you want the event to trap. It doesn't keep scanning all of them just in case! That would slow your system right down! Pete