Pete Dowson

Just ZIP them! They are all simple Text files and ZIP up very small. Pete

Well, the only difference is those extra log lines, which were intended to be temporary. They must affect the timing but it is a very small difference. Thay's a log of extra log lines each time a Lua is loaded: 90578 RunLua just called: Filename "C:\P3Dv4\Modules\linda\system\init.lua" 90578 About to Create the Lua thread: Entry 0, Filename "C:\P3Dv4\Modules\linda\system\init.lua" 90578 Create Lua thread: Entry 0, Filename "C:\P3Dv4\Modules\linda\system\init.lua" 90578 Inside the Lua thread: Entry 0, Filename "C:\P3Dv4\Modules\linda\system\init.lua" ... 90578 Inside the Lua thread: Entry 0, Filename "C:\P3Dv4\Modules\linda\system\init.lua" I might have to do a process of elimination on those, or just substitute a delay instead of all of them. But first, because it is presumably because of the Kill action overlapping the fresh load (?) I will double check to make sure the LAST thing the Kill sequence does is free the table entry so it isn't used prematirely by the new thread. It's the only thing I can thing might be occurring. All that must be down to assumptions about your / usage made in other Lua program in your portfolio, as I always only ever use \ with never such problems. Never mind anyway. We know it isn't that. It was only a straw to be clutched! ;-) Pete

All that does is re-scan the devies. It's nothing to do with the assignments. The usual reason for this is that the device is "going to sleep", maybe as a result of Windows power management. Check the Windows Device Manager, USB section, and make sure Power Management is turned off for all USB Hubs. (Right click on each for Properties). I'm not sure what you intended to convey with the LOG you supplied, but that appears to show the rudder device responding fully. You operated the Right Brake pedal well enough, then later the rudder itself, and all within the first 7 or 8 seconds of the system being "ready to fly". Then later the Left brake axis, but still within 26 seconds. All without visiting the Options at all! Pete

As does the one I included in the FSUIPC ZIP file. Is the "new" one a later version? The one I supplied was 2.2.8.0, as shown in my Logs along with the devices I could test here: 174269 Using "E:\Prepar3D v4\Modules\GFDEV64.DLL", version 2.2.8.0 174269 GoFlight GFP8 detected: 2 devices 174269 GoFlight GFT8 detected: 2 devices 174269 GoFlight GFRP48 detected: 2 devices Do you have more devices tested? Maybe check the FSUIPC5.LOG for similar lines to the above? Pete

There is absolutely no relation between the two different simulators. Which are you having problems with, P3Dv3 or P3Dv4? And what exactly do you mean by "conflicts"? What is all this switching between P3Dv4 and P3Dv3 got to do with anything? It makes no sense Talk about them separately. They are separate, not related! If you are assigning in FSUIPC you must disable controllers in P3D. It is not enough to "delete axes", they will be picked up again. And if you do things like delete FSUIPC INI files then how are you going to show me what is wrong? You supply a log only for FSUIPC5, not FSUIPC4. Does that mean all is good in P3Dv3? If so you should be able to use the FSUIPC4.INI from P3D3 in P3D4 after renaming it to FSUIPC5.INI. And if you show me the other files for both sims I would be able to spot any responsible differences. The log shows just three devices actually connected: 796 Device acquired for use: 796 Joystick ID = 2 (Registry okay) 796 2=vJoy Device 796 2.GUID={F9721F10-96BD-11E6-8002-444553540000} 796 Device acquired for use: 796 Joystick ID = 1 (Registry okay) 796 1=PFC Cirrus Yoke 796 1.GUID={352AD440-9656-11E3-8001-444553540000} 812 Device acquired for use: 812 Joystick ID = 0 (Registry okay) 812 0=Arduino Leonardo 812 0.GUID={DE67F590-3F2E-11E7-8001-444553540000} I don't know "vJoy". It says it's a "virtual joystick" made by Shaul Eizikovitch. I suppose you know about this? It appears to provide 8 buttons and 6 high resolution axes. You do have a PFC Cirrus Yoke. I assume this is one of the later USB versions which looks like a joystick type device to Windows too? There's no PFC rudder connected. The only other device is an Arduino. I have no idea what you have or have not assigned as you didn't supply the INI file with your settings. And I have no idea what your "conflicts" are because you don't say. Next time, please also supply your settings (the INI file) and also the file called FSUIPC5.JoyScan.csv (or FSUIPC4.JoyScan.csv for P3D3), as well as describing what your problem is, and in which simulator. Pete

Whether buttons are pushed or not is probably irrelevant. Are there hardware-related programs or drivers running when you Kill the thread responsible for them? As this is the only thing I can think of which might be able to cause the crashes. I'm sure there not related to the problem we are investigating. On that, here's my final test module, with logging as close as I can get t where it says there's a "" filename (or did do when I added that log line into the base Lua code, now removed). After this test I give up. FSUIPC5103f_T3.zip I thought you were out all day today? Pete

Once you have your aircraft in a Profile, to automatically run a Lua plug in only when that profile is in use, you need a section haded [Auto.profilename] with lines loading the Lua plug-ins and any macros you also want applied. See the section on "Automatic running of Macros and Lua Plug-ins" in the Advanced User's manual.

The variety is something to do with incorrectly sourcing the string for the first added log line, but this is rather odd: 581688 Create Lua thread: Entry 0, Filename "C:\P3Dv4\Modules\linda/system/init.lua" 581688 *** LUA Error: cannot open : Invalid argument That filename in the first line is definitely the one passed to the Lua function which is failing. I'm a little worried about your use of / instead of \, as there are many places in the original Lua code (and in my code come to that) which do assume that path separators are always \. I know Windows appears to accept it, but conventionally / is used for URLs and \ for file paths. Can you try to repproduce the error using \ only please? The alternative would be for me to search every path string ever passed to Lua functions to ensire all / characters are replaced by \. Pete

Ouch. Crashes in ntdll ... I can't really do much with those. Usuaully, even if I can reproduce them here under a debugger, the call stack is deep and with no sign of anything I can call familiar FS or FSUIPC code. Did you have any devices being driven then, or is this LINDA in the mode as here, not doing anything? Pete

That normally only happens if you have Wondows operating power saving on the USB hubs. That's controlled by a power management tab in the Properties of each USB hub in the USB section of the Windows Device Manager. Also Windows 8 did have a problem with losing joystick devices in any case. Pete

Not the title bar (which most folks don't have showing in any case) but certainly in the usual green bar at the top of the main Window. Just use offsets 3380 and 32FA. Pete

I need Windows crash details for such things. I've no idea why that would happen, but if pathnames are "disappearing" I suppose the same problem could cause crashes. This is mch more of a puzzle: The filename is the second line should match the one in the third. The one feeds the other! Could you have Button/Key logging enabled next time please? And you can take the LogExtras and TestOptions lines out now, they only make the log unnecessarily larger. Pete Aha! That might be a clue to the above. Maybe I've somehow have sourced the string from the wrong place. I'll take a look -- tomorrow. But you didn't manage to get the original error at all? After Thursday I am out for 9 days. Pete

Okay. That's what matters! ;-) Pete

But the reason for that is presumably the same reason that there's no button seen on anything else. So you aren't worried about not seeing buttons after all? I am really confused now. If you want to test for button recognition, thy closing down that Razer software before loading the sim. So, problem solved? Not that it matters now, I assume, but the picture from Device Manager you posted shows the Human Interface Devices section expands. That is NOT the Universal Serial bus controllers section, which oddly enough is actually called Universal Serial bus controllers!!! Pete

Sorry, you were too quick. i modified it immedfiately after I posted it! Try again. Pete

Well, this is very odd. The link is correct and the file is actually there! I'll try it with a different name, though I can't see anything wrong with the name! FSUIPC5103f_T2.zip Try that. Pete

Okay, almost the last gasp ... FSUIPC5103f_TEST2.zip This has the same version number etc, and two different log entries from before. Please also enable Button/key logging in the FSUIPC logging options -- that gives me the "beginning" message too, without the Lua tracing needing to be enabled. Pete

So the filename is disappearing immediately you execute the RunLua! Weird. I'll look to see where I can log closer to that, but there's not much involved. Pete

FSUIPC uses DirectInput to read the data from the devices. Each joystick-type device supples both Button and Axis states tgether. They cannot be separated. So if FSUIPC can see the axes it can see the buttons -- unless some other software or driver is preventing this. The axes you have assigned are on all of the other devices, Saitek Rudder, Yoke and Quadrant, and the HOTAS Warthog, so if all those axes are working there's no way FSUIPC can not see the buttons without some other interference in DirectInput, which seems very unlikely. No buttons? It seems t be telling DirectInput that it has 24 buttons, and 6 axes (RUVXY and Z), here: Details: Btns=24, POVs=(0, 0, 0, 0), Cal=x00000000, Max=R255,U255,V255,X255,Y255,Z255 So how are these assigned? It sounds like there's some software being run for the OrbWeaver which is seriously interfering with everything else. Do you know about any software? Howdo you configure this "keypad"? Sorry, that seems to be contradictory. You say: "it works ;-) all the buttons work with the Orbweaver connected" but then "I will give it a go if I hope this really work"! Which is the truth? It works or you hope? I'm not sure about that "Power Options" picture you showed. Maybe it is different in win10? The USB power management I'm talking about is in Device Manager, in the "Universal Serial bus controllers" section, and in the Properties (right click) for each entry described as a "Hub". Did you also try what I asked, i/e: What about if you go into the FSUIPC options, Buttons or Axis assignments tabs, and select the "reload" button? Do they work then? Pete

Okay. there's not much for me to log n this part really. I've added a log line at the entry to the thread creation process, to make sure the fielname is still intact there, and then just before the loadfile is actually called. The acode in between looks pretty innocuous, but these two log lines will implicate or eliminate them and give me the next steop. Download this special Test version (the new logging is temporary): FSUIPC5103f_TEST.zip You can take the trace option off. Please generate the error again and showw me that area of the log. Pete

The focus has been moved to Explorer. If you aren't doing that you are running something else which is doing it. Maybe something starting by entries the EXE.XML or DLL.XML files, the the FSUIPC3 Documents add-ons files for P3D. This is the wrong Forum for such queries. You should visit the P3D forums on AVSIM or Locheed Martin's own support forums. Pete

The attached file is from a fresh load of P3D4 and if 5Mb long, not 5Gb! The entry at 178735 is 3 minutes into the run. We should have used the Lua tracing berfore. I've been wasting my time. The error here: 176641 LUA: "C:\P3Dv4\Modules\linda/system/init.lua": killed 178735 LUA.1: C:\P3Dv4\Modules\linda.lua:157 fn: Start 178735 LUA.0: beginning "" 178735 luaL_loadfile fopen error 0, flags 0000, filename "" 178735 *** LUA Error: cannot open : Invalid argument Shows LUA.0: beginning "", which appears to be my own added code finding that the filename is already empty before the Lua code I've been trying to track is even called! I'm in the process of scrapping all the extra logging I've been adding and will now look in my own code. Pete

There's a chapter on this in the User Guide. So no axes or buttons get through if the Orbweaver is connected, except for those on the Orbweaver? That's really very strange. What about if you go into the FSUIPC options, Buttons or Axis assignments tabs, and select the "reload" button? Do they work then? And what happens when you connect the Orbweaver later, instead of having it connected at the start? Everythng carries on working pus the Orbweaver? Are all the devices connected to separate USB sockets on the PC? Or are they on a hub? A powered hub? Can you check in the Windows Device Manager that power management is disabled (i.e. no power saving) on each USB hub or other USB devivce which has that tab (it'll be in the device properties if it is there). But if it doesn't detect the Orbweaver then your assignments to it (Joystick ID 5) won't work. I see no assignments to any axes on it, but you said the axis works on the Orbweaver. If you don't intend to use it, why connect it in any case? Pete

The documented user offsets are 66C0 to 66FF. Is that enough? Pete

I found that the fopen I was looking at was probably something related to other things your Lua stuff is doing. things like require" do file loads as well. By simulating what you are doing I can see that they layering is not hard so I'm looking now (I will put a time limit on it) yto see if I can put traps elsewhere. One thing you could do to help, please, is enable Lua trace in the Logging options. Obviously the log is going to get absolutely huge, so also selct the separate files option. If you can get the error please try to make the relevant part of the relevant log small enough to post here or direct to me -- ZIP it of course. The trace from the INIT load beng honoured in that Lua and the resulting INIT log if there is any. Pete