Djeez

Because if I try to be as complete as possible in my description and also give a work-around you just state that I should use that workaround. I don't feel taken seriously that way. It used to be that Lua scripts are terminated if they were already running. That is even documented behaviour, see lua plugins.pdf: By the way, also if I close FSUIPC using the Exit command from the File menu I get a not-responding, maybe because there is a Lua script running? -Emile.

I just wanted to let you know what is going on so that you can improve the product and tell others reading the forum how to workaround issues. It is clear that there are many issues with FSUIPC7, it is not as stable as FSUIPC3 and FSUIPC4, based on my experiences. I will keep other annoyances and workarounds to myself. -Emile.

Hi, I have an ipcReady.lua scripts that starts several scripts: ipc.macro("Lua ga_c172") ipc.macro("Lua throttle") ipc.macro("Lua pedestal") When I make a change to one of the scripts, I restart them with the command Lua ipcReady.lua that is bound to one of my keyboard keys. However, when I press that key to restart, the FSUIPC7 program shows "not responding" in the title bar and I have to kill it through the TaskManager to proceed. First a LuaKillAll and then restarting the scripts works fine. Regards, -Emile.

I agree. Thanks for your efforts! -Emile.

Hi John, I tested 7.0.5d using a Lua script on the Asobo C172 and it works exactly as you described, reading and writing. Thanks. However. The fact that the offset does not reflect the actual plane state does not help me. Now it only indicates my last action and I could keep that information just as easily in my Lua script. I understand that because of the missing Sim variable the solution is not possible without SDK extension. Would it help if I put in a request to the MSFS Zendesk to ask for such a Sim variable? If you decide to keep the offset then please document clearly that it does not reflect the actual plane state but the last write action to the offset. Regards, -Emile.

I would appreciate that and I can test it for you. -Emile.

Thanks for the info, but I would also need an offset to read the switch state in my lua script. Regards, -Emile.

I can confirm that the following offsets work correctly for both reading and writing, in addition to the list in offsetStatus-v0.14.ods. Tested on the Asobo C172. 0x0BC8, parking brake 0x0892, starter switch engine 1 0x3101, alternator 0x3102, master battery 0x3103, avionics master. This seems to control both Bus 1 and Bus 2 avionics. I have not found a way to control them independently. 0x3104, fuel pump 0x029B, alternate static air source 0x0AF8, fuel tank selector 1 0x029C, pitot heat Hope this helps to improve the documentation. Regards, -Emile.

Hi John, After hours of fiddling with different socket distributions and dll replacing, I got it to work. In the end the solution turned out to be blatantly simple: put the socket.lua from the LuaSocket project for Lua 5.1 in the FSUIPC7/lua folder. That's all! The only reason I think this can work is that after the long discussion you referred to, Pete linked the socket core library into FSUIPC. I don't see how this could work otherwise. Anyway, it would be good if someone could verify this solution to see that indeed I do not have some hidden dependency on my system after all the fiddling. Regards, -Emile.

Hi, The Lua Plug-ins manual (pdf) has a link referring to a solution for a 64 bits socket library solution. However, this link does not work for me and searching in the User Contribution section for "socket" does not help. Can you please provide a link to the solution for using sockets in 64 bit FSUIPC? Thanks! Emile van Gerwen.

Use the wheel-up and wheel-down values. In a lua script like so: ipc.control(EVT_OH_PRESS_FLT_ALT_KNOB, MOUSE_FLAG_WHEEL_UP) Emile van Gerwen.

Thanks Pete. I always used "require" or "ipc.macro" to start other plug-ins and I overlooked the ipc.runlua command. I guess that is what you refer to. Indeed this solves my problem. Regards, -Emile.

Hi Pete, I have a couple of Lua scripts that use blocking socket calls. To prevent them waiting for eachother I would like to start them in a seperate thread. This works if I assign a different key to them and start them by pressing all the assigned keys but I would like to do this automatically from ipcready.lua or some other means. I could rewrite my scripts to use non-blocking socket calls but that would make my scripts (and the other side) much more complicated so if you can suggest a way to start scripts in their own thread I would be very grateful. Thanks! Emile van Gerwen (using registered FSUIPC4, P3D)

Thanks for looking into it. I will look into your suggestion of using L-Vars. That is new to me. If I add a hidden gauge to a 2D aircraft panel, are then its L-vars accessible from Lua even if that panel is not displayed? Or are these gauges only accessible from Lua when shown? -Djeez.

Hi, As you requested, this is a kind reminder for looking into the GPS interface. Thanks! -Djeez.

I don't exactly understand what you mean with full GPS capabilities. My intention is to build a GPS-like display on a Saitek instrument panel where the user aircraft is displayed in with a sketch of the surrounding navaids and the flightplan. I probably could calculate the nearest navaids myself using MakeRunways (I have not used it before) and parse the flightplan file, but since all of this already done by FSX for the GPS.xml gauges, I thought maybe there is a possibility to hook into that. Then (phase 2), I want to extend this with information on destination airport information and weather enroute. Then (phase 3), I want to extend this with information on IVAO controllers online that are relevant for the flight. My overall purpose is to display all information I need during flight on my Saitek displays and have my computer monitors only for outside view. In my opinion looking down on the flight instruments is so much more realistic than looking at the monitors for information. -Djeez.

Pete, I very much appreciate your continous work on extending the FSUIPC capabilities. If you could have look into the GPS data that would be very kind indeed. No problem if that takes time. By the way, I have over 20 professional programming experience including C and C++ so if there is a way I could be of assistence then please feel free to ask. I can only guess why I am the first person to ask... Maybe most applications (such as FSNavigator, FSCommander) need access to the whole navaid database and there is no other way to obtain that than by building a database from the bgl files. Other applications that I use such as AirTrack (connects FSX to an iPad) apparently use a real world database but that has the downside that it does not match the FSX scenery. Perhaps they just forgot to ask you! ;-) This is for FSUIPC4 (FSX). Best regards, -Djeez.

Sorry I have to revive this issue. I stopped developing since I did not have a clue on how to proceed, but now I the issue pops up again. The XML gauge facility can get to the information I need. The gps_500.xml that is part of FSX (it is in the gauges\fs9gps.cab file) is a good example. Somehow it manages to access the FSX database. Some of the code in this xml file: <Macro Name="c">C:fs9gps</Macro> <Macro Name="g">C:fs9gps</Macro> ... <!-- update coords for the nearest pages --> (A:GPS POSITION LAT, Radians) (>@c:NearestAirportCurrentLatitude, Radians) (A:GPS POSITION LON, Radians) (>@c:NearestAirportCurrentLongitude, Radians) 9 (>@c:NearestAirportMaximumItems) 200 (>@c:NearestAirportMaximumDistance, NMiles) (A:GPS POSITION LAT, Radians) (>@c:NearestIntersectionCurrentLatitude, Radians) (A:GPS POSITION LON, Radians) (>@c:NearestIntersectionCurrentLongitude, Radians) 9 (>@c:NearestIntersectionMaximumItems) 200 (>@c:NearestIntersectionMaximumDistance, NMiles) (A:GPS POSITION LAT, Radians) (>@c:NearestNdbCurrentLatitude, Radians) (A:GPS POSITION LON, Radians) (>@c:NearestNdbCurrentLongitude, Radians) 9 (>@c:NearestNdbMaximumItems) 200 (>@c:NearestNdbMaximumDistance, NMiles) (A:GPS POSITION LAT, Radians) (>@c:NearestVorCurrentLatitude, Radians) (A:GPS POSITION LON, Radians) (>@c:NearestVorCurrentLongitude, Radians) 9 (>@c:NearestVorMaximumItems) 200 (>@c:NearestVorMaximumDistance, NMiles) (A:GPS POSITION LAT, Radians) (>@c:NearestAirspaceCurrentLatitude, Radians) (A:GPS POSITION LON, Radians) (>@c:NearestAirspaceCurrentLongitude, Radians) (A:GPS POSITION ALT, Meters) (>@c:NearestAirspaceCurrentAltitude, Meters) [/CODE] (I just copied this code from the xml file, I have the feeling that this does the magic I need but I don't know how...) Bob McElrath (http://www.robbiemcelrath.com/blackbox/?gps) wrote an extensive book on how this system works, but he only refers to XML gauges. In my case I want to display this information on Saitek panels and would like to use FSUIPC for that. As I know that the Lua library supports LVars, my hope is that maybe there is also a way to get to the information that is used by the XML gauges through the Lua extensions. Thanks! -Djeez.

You can assign a keypress to LuaKill <your script> and Lua <your script>. Then pressing those keys will restart your script. Regards, -Djeez.

Yes, I did that, that is not the problem. I figured it out. The modules saitek.dll and gd.dll that are required for my Lua script depend themselves on 7 other dll's that are distributed with LuaForWindows. These have to be placed where the native loader can find them, e.g. in the FSX folder because that is the current directory of the fsx.exe process. Maybe the easiest way for users is just to install LuaForWindows... Are you sure about the name? In my version (4.712) it should be the Lua folder.

Hi Pete, We talked earlier about my tcas lua script. Now I am getting feedback from people who downloaded it that it doesn't work. I have narrowed the problems down to the fact that they do not have the Lua development environment installed (and I do). If I rename the Lua directory of C:\program files(x86)\Lua to something else, the FSUIPC log file shows the message *** LUA Error: error loading module 'saitek' from file 'C:\FSX\modules\lua\saitek.dll': The specified module could not be found. Same happens with the gd.dll module if that is required first. Of course I could tell my tcas users to download and install the Lua Windows development kit, but I am sure that was not your intention when you developed Lua scripting for FSUIPC. Do you have any suggestion what to do? Thanks! -Djeez.

Yes, it is a FSUIPC plugin that uses your ipc and logic libraries. This is the direct Avsim download link. You are welcome to include it in your package but installing takes a little more than just copying one lua script. It uses some clibs as well. I will post a message in the User Contributions subforum as well, I must say I had not noticed it before. Best regards, -Djeez.

Hi Peter, In the Lua manual you write: Well, I have used Lua to create gauges for the Saitek Instrument Panel. One is uploaded to avsim file library (tcas.zip), a new one will follow soon. Thanks!!

Hi, I would like to get GPS information from a FSUIPC-started Lua script, but as far as I can see the FSUIPC offsets do not provide all information such as waypoints, nearby VORs,... Is there a way to obtain the necessary information? Thanks! -Djeez. btw, I just recently discovered the Lua support from FSUIPC. This is awesome!

That was it :D After my visit to the local flightsimclub I forgot to put the CH Pilot connector back in (the old, anologue game port one). Windows Game Controller showed an error and when I plugged it in all was well again. Thank you very much for the outstanding support. I need the button programming (and GFDisplay) to program around some annoying bugs in the GoFlight software. I wish they were as responsive as you are! Cheers, Djeez.