[SendMessage timeouts]

1 hour ago, Luke Kolin said:

My users all swear up and down that their frame rates are excellent (and I'd rather not instrument that any more than I have) but are there any cases that you know of where FSUIPC will take an excessive amount of time to respond?

There are two possibilities I can think of:

1.  You have made a request via FSUIPC which involves FSUIPC asking FS for something and waiting for the result.  Typical would be reading L:Vars, as an example.

2.  The high (unlimited?) frame rates being allowed in the simulator are precluding sufficient time for other interfacing applications. This would typically be occasional, not constant. Best always to advise users to limit frame rates (either directly by the FR limiter, or via VSync), to something just below the average attained.

Without knowing more about exactly which requests are timing out I can't really help further. You should also state the versions of both FSUIPC and FS/P3D.

Pete

 

[Strange issue in LUA]

Please also supply the actual Lua file. How can we possibly help otherwise? For instance, what is on line 92, as that is where the error is.

10 minutes ago, cellular55 said:

Any idea about which could be the problem? Overall that character is not part of the lines

It looks like a bad character somewhere. I can check the file (view it in Hexadecimal) if you attach it. I can't help blind.

Pete

 

[FSUIPC Mouse Macro Creation For XML Gauges]

12 hours ago, Crashcast_E said:

I was wondering if there was a way to make a mouse macro for an aircraft with XML gauges? I'm currently working with the FSLabs Concorde X, and the L:vars are rather... complex and varied. Looking at the Advanced user manual for FSUIPC 4.97, it looks like it is possible, however I do not know how to find the mouse rectangle needed for the control. Any way I can find this?

Sorry, but I don't think there is a way for mouse macros to work with XML gauges in FSX or P3D1-3.  They do work in all gauges in P3D4 and 5 because L-M implemented the facility for them internally, in the PDK.

Pete

 

[FSX crashing]

14 hours ago, Allan Hook said:

I think all the stoppages were when I found a lot of joystick commands seemed to have vanished so I had to reprogram them.

Re-programmed in FSUIPC or FSX?

FSUIPC doesn't "lose" settings, but there are several reasons why a joystick ID might change. If you are using the facility to use Letters instead of Numbers for IDs then FSUIPC can usually deal with that automatically.

Anyway, next time there's a problem check the Event Viewer for both or either of FSUIPC and FSX crashing (one might lead to the other), and supply your FSUIPC4.INI file as well as the FSUIPC4.LOG for the crash.

Pete

 

[Terminating or killing LUAs in other folders]

2 hours ago, ckovoor said:

And then I ran them, and it all worked perfectly, and the performance, is, if anything, better than before! I mean the displays, and the controls appear more rapidly responsive than before.

Great news!

Pete

 

[FSX crashing]

1 hour ago, Allan Hook said:

FSX has started crashing, usually when I have been running for a couple of hours. Below is the event log.

The Log you attached shows a successful close-down, not a crash.  This was after a session of 1hr57mins. The only odd thing in the Log is the hige number of stoppages in the first 46 minutes, before you loaded a flight from RJAF to RJNH using the SOAR DG8085.

Without a log from a session which crashed I can't really help.  You also need to state what add-ons you were using at the time of the crash. I think it is most likely to be down to one of those. Perhaps you can remember what you changed before FSX started crashing. I assume it wasn't always crashing before you changed something?

Pete

 

 

[Terminating or killing LUAs in other folders]

There is one other thought I've had.

The limit of 127 Lua files in the Modules folder is only because in the assignments encoding only 7 bits are available to encode the Lua index from the [LuaFiles] list.  Those you are starting without assignment don't need to be indexed, so aren't confined to 127.

By placing them all in the Modules folder you should be able to use LuaKill via the 0D70 method (though I've not tried that).

Pete

 

 

[Terminating or killing LUAs in other folders]

2 hours ago, spokes2112 said:

Bummer 😢 , was really hoping it would work for you... Oh Well.

Good Luck,
Roman

I'm not sure that the whole pathname is needed for LuaKill. It isn't as if it needed to locate it on disk. Try it just with the Lua name only.

Pete

 

[Terminating or killing LUAs in other folders]

2 hours ago, ckovoor said:

Most of the Lua files which make up the initial 127 are, in fact, files communicating with Arduinos on dedicated COM ports, and for that reason, as far as I know, they cannot be combined.

There's no rule stating that you can only open one COM device per plug-in. Just use different handles.

Pete

 

[WARNING: Joystick ID 4 is duplicated in Registry causing joystick conflict]

11 hours ago, mwcorder said:

In P3Dv5 I cannot have my Saitek Rudder Pedals and my Thrust Master Warthog Joystick working at the same time.  At bootup, the pedals are available but not the joystick. If I unplug the pedals the joystick becomes available and works normally. If I reconnect the pedals they do not work and the joystick continues to work.

You posted a P3D question in the subforum for FSUIPC7 in MSFS. I've moved it for you. Please always check where you are when posting a support question.

I don't know how the registry has become so messy, but the first thing to try is to renumber the #4 item which has been seen. i.e. change these lines in the INI file

4=Saitek Pro Flight Rudder Pedals
4.GUID={419BB610-5786-11EB-8017-444553540000}
 
to the next available ID:

6=Saitek Pro Flight Rudder Pedals
6.GUID={419BB610-5786-11EB-8017-444553540000}

FSUIPC will then try to correct the registry. You may need to start P3D more than once for this to take effect properly.

Another way, before resorting to Registry editing, is to use the JoyIDs utility to change the duplicated ID.  see https://theairtacticalassaultgroup.com/forum/showthread.php?t=13009

Pete

 

[Terminating or killing LUAs in other folders]

2 hours ago, ckovoor said:

(5) B747v3 Panels.lua is there to start the various panel windows of the B747 in specific locations and sizes to overcome certain graphics card issues I face on my system.

I don't understand why you need so many separate plug-ins, all in their own threads, for the same aircraft. Better with a single Lua per aircraft, loaded via [Auto.<profile>] statements. /that /Panels one is an easy exampe -- why not sort out the panel windows as the first action in such a plug-in?

2 hours ago, ckovoor said:

As a matter of fact, I was led to this solution by your own comments in this thread:

https://forum.simflight.com/topic/74784-lua-files-are-not-shown-in-fsuipc-gui/

in which you state that "a maximum of 127 Lua files can be assigned -- the first 127 in the list in the INI file. You can have other Lua files, preferably in other folders, which can be called by any of those, or directly in [Auto] sections."

Sorry, I plead memory loss through old age.

Roman's ideas look good too.

Pete

 

[Terminating or killing LUAs in other folders]

41 minutes ago, ckovoor said:

I'm (still) running FSX-SP2 and Win 7 x64 with registered FSUIPC4.974b. I have lots of hardware (MCP's, throttle quadrants, radio consoles) containing Arduino Mega's, and hence numerous LUA scripts to manage them.

So a few days ago, I reached and breached the upper limit of 127 LUA files in the Modules folder.

I cannot imagine a scenario where so many Lua plug-ins are required. It sounds like you have separate plug-ins for lots of little things which would be more efficiently dealt with in fewer larger ones. Can you explain what sorts of functions these >127 plug-ins are actually performing?

43 minutes ago, ckovoor said:

So I created sub-folders for each aircraft within the Modules folder, as for example Modules\LuaB747v3 containing all the Lua files pertaining to that particular aircraft. These LUAs are then started automatically from the Modules\Profiles\B747v3.ini file thus:

I'm actually surprised that works. There was no designed intention of allowing plug-ins to be run from other folders.

46 minutes ago, ckovoor said:

So, my quesition is there any way of terminating/kiling a Lua file located in a folder other than Modules? Something like an ipc.killLua() command?

No, sorry. At least not easily. You'd need to build the termination into the plug-in's code, with it instigated by an event on a key or button press.

I would seriously look at rationalising the way you have coded the plug-ins so that their numbers can be substantially reduced.

Pete

 

[Key command triggered by altitude AGL?]

13 minutes ago, Stu Antonio said:

I was just doing as this passage in the manual states "For key presses, the <key> value following the letter ‘K’ is the virtual key code for the key to be pressed." but maybe that's for something else...

Assignments in the FSUIPC INI file can be to Key presses or Controls. To differentiate between those they are preceded (not followed by) a K or a C.

But that is nothing to do with the Lua library functions like ipc.keypress and ipc.control, where the parameters are numbers and there's no danger of confusion in any case.

Glad it is working for you.

Pete

 

 

[Key command triggered by altitude AGL?]

Also the key code for V is 86, not K86.

Pete

 

[Key command triggered by altitude AGL?]

4 hours ago, John Dowson said:

Also, event.intecept() is probably not the function you need, as this intercepts writes from 3rd party applications, not internal FSUIPC writes. You would need to use the event.offset() function on the plane altitude, offset 0200 or 0B4C.

Actually this is one case where using a timer event to do the AGL calculation at intervals (eg one a second should be enough) would be better, because otherwise you'll either get almost continuous events, or actually completely miss the trigger altitude if the ground is rising rather than the aircraft descending. So, something like

aglhigh = false

function checkAGL()
   ground = ipc.readSW(0x0B4C)
   altitude = ipc.readSW(0x0574)
   agl = (altitude - ground) * 3.142 -- convert to feet
   if agl > 550 then
      aglhigh = true
   elseif agl < 450 and aglhigh then
      aglhigh = false
      --SEND KEYSTROKE OR CONTROL HERE:
      -- ipc.keypress(keycode, shifts)
      -- ipc.control(control number)
   end
end

event.timer(1000, "checkAGL")

You'll need to fill in the action to be taken, where I've said. I've allowed 50 feet either side of 500 feet to avoid unnecessary repetitions with an uneven descent.

I've not tested this, but it should be okay.

Pete

[Weird file-path in runways.xml]

3 minutes ago, pellelil said:

I just noticed that the file-tags in runways.xml begins with "\\?". I only use this tag to display where the scanned data comes from (which scenery) so its no a big deal, I just wandered where it came from?

I put that in for MSFS to allow/enforce Windows to accept pathnames greater than 256 (MAX_PATH), since using the default install paths, especially for the Store version of MSFS, easily generates what would otherwise be overlong paths.

See https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=cmd

"To specify an extended-length path, use the "\\?\" prefix. For example, "\\?\D:\very long path"."

Pete

[Make Runways. Version 5.127 not working in P3D v5,2?]

23 minutes ago, Julean said:

Now its running.

Okay, good.

Pete

 

[Can't get WideFS to connect to FSUIPC7]

You should set "no repeats". Unlike using a button press, using a keyboard creates multiple presses automatically. You'll be sending a stream of KeySends so invoking continuous F12 presses!

I have this in my WideClient INI:

Run2=C:\Pilot2ATC\Pilot2ATC_2020.exe
Close2=Yes
UseSendInput=Yes
KeySend110=112,16 ; F1 Press   PTT for P2A
KeySend111=112,24 ; F1 Release PTT for P2A
KeySend112=121,16 ; F10 Press   Sayit for P2A
KeySend113=121,24 ; F10 Release Sayit for P2A
KeySend114=117,16 ; F6 Press   Sound device for P2A
KeySend115=117,24 ; F6 Release Sound device for P2A

All of those KeySends are assigned to buttons in my cockpit -- the PTT to the PTT button on the yoke. Works fine.

Of course, also be sure you have it set correctly in P2A.

Pete

 

 

 

[Can't get WideFS to connect to FSUIPC7]

3 hours ago, jmabrao said:

2765 Error on client pre-Connection Select() [Error=10061] Connection refused

This normally implies a firewall stopping the connection. It might be on the Client PC or the Server, more likely the latter. You'll either need to disable the firewall, or at least tell it to allow FSUIPC7.EXE  (on the Server firewall) and WideClient.EXE (on the Client).

Pete

 

[Make Runways. Version 5.127 not working in P3D v5,2?]

I don't know exactly what the Lorby program does but the first few entries in your Scenery.CFG file look bad:

[Area.001]
Title=
Local=
Active=FALSE
Required=FALSE
Layer=1

[Area.002]
Title=
Local=
Active=FALSE
Required=FALSE
Layer=2

[Area.003]
Title=
Local=
Active=FALSE
Required=FALSE
Layer=4

[Area.004]
Title=
Local=
Active=FALSE
Required=FALSE
Layer=5

[Area.005]
Title=
Local=
Active=FALSE
Required=FALSE
Layer=6

[Area.006]
Title=
Local=
Active=FALSE
Required=FALSE
Layer=7

I suspect it is those which stop the scenery export program doing its job. Having entries with no name and no folder path is pretty obviously wrong. I don't know how this happened, but you need to correct it.

Maybe the AddonOrganizer can do the job for you -- delete those areas? Or delete them manually ang get the AddonOrganizer to do the renumbering then needed?

Pete

 

[Make Runways. Version 5.127 not working in P3D v5,2?]

 

That was for you to look at to see which file to look at — in this case MakeRwys_scenery.cfg

Anyway this shows that MakeRwys and the Lorby program ran ok but that there’s something wrong with your P3D scenery.cfg file. Some scenery updater has probably corrupted it. That file is in the Windows ProgramData folder, in the P3D section.

You can show me that if you need help.

Pete

 

 

[Make Runways. Version 5.127 not working in P3D v5,2?]

2 hours ago, Julean said:

It seem in the latest p3d v5,2 I can't seem to get the make runways running. That have never happen before.  I have made both files this and Lorby ticked as run as administrator. 

I moved your support question to the Support Forum. Please do not post such into reference subforums.

There is absolutely no difference in how MakeRunways works for P3D 5.2 to any previous versions. Check the Runways.txt file -- see what scenery cfg file it is using (it'll say within the first few lines). Then see if that file is correct. Maybe you have a broken main scenery.cfg file which messes the Lorby scanning program up.  If you aren't sure, show me the scenery.cfg file (the file itself, not pictures!).

Pete

 

[FSUIPC4: Joysticks not detected on startup]

1 hour ago, glennav8r said:

I have an issue that has got me beat. When I load P3D V3 the joysticks that I have assigned and calibrated within FSUIPC 4.976 (I think, Jan 21 version anyhow) do not become "active". My work around is to go into FSUIPC, click on Axis Assignment, click on Joystick Calibration, click on Axis Assignment again and then exit out of FSUIPC and everything is working.

It sounds like you have Windows power management enabled on the relevant USB sockets. To fix that run Device Manager (enter that in the start/run box in the task bar), then look at each of the "Universal Serial Bus Controllers" Properties for those with Power Management tabs and uncheck the option "allow the computer to turn off this device to save power".

Pete

 

[Nav lights switch]

I'm not sure about MSFS -- the situation there is always changing -- but in FS/P3D generally there are only ON and OFF controls for Panel Lights and Landing Lights, so how are you assigning the others?

An alternative to using the Controls is to change the bits for the lights in offset 0D0C.  For NAV lights you can assign ON to offset word setbits with a parameter of 1 and OFF similarly to offset word clearbits, same parameter, both for offset 0D0C.

Pete

 

 

[Flight Sim Center 737 TQ and Throttle Offsets]

9 hours ago, vanislepilot said:

The throttle quadrant has its own software in which you set only the desired FSUIPC offset that the corresponding throttle lever will effect (see UI screenshot). There is no direct way of calling FS controls unfortunately

Well that is far too restrictive. Perhaps you should talk to FSC about that and get them to improve their throttle quadrant driver?

There is one other possibility not involving programming: use the offsets in the range 3BA8 - 3BC4. Check the List of Offsets document to see which of those to use. Then you should be able to assign the throttle axes in the FSUIPC Axis assignments tab, and calibrate if necessary too, just as for a proper Windows Joystick type device .

That's only for writing. Leave the read offsets as they are.

Pete