Pete Dowson

Oops. Thanks. I'll fix that later. Pete

So the "ignore axis" facility works for you. How often are you needing to re-calibrate the assigned axes? That's normally a job that onvce done stays done, at least till you axis pots wear out, which shouldn't happen for years. If you are re-calibrating for different aircraft then you should be using profiles in any case. calibrations are saved independently for each. Pete

Yes, john is correct. My P3D4 is on drive E: and the entry as exported directly using RegEdit is: [HKEY_LOCAL_MACHINE\SOFTWARE\Lockheed Martin\Prepar3D v4] "SetupPath"="E:\\Prepar3D v4\\" Your "StuPath" makes no sense really. Not sure how that can have been produced except by careless editing. Pete

The problem is fixed in version 4.873, now available for download. The problem was a 'transparency' flag I didn't know about, so code 128 meant "concrete (transparent)2'. I assume transparent runways are used when the underlying runway is better represented by a ground texture or photo. Thanks are due to Jon of ScruffyDuck, author of ADE, for help with this. Pete

First, please always post support questions here, in the Support Forum, not in any of the Reference subforums (you posted in "User Contributions") If it's the same rectangle ID from the same switch, then the Click Type should be the same. "3" just means a single click of the left button. Your 10 means you MOVED the mouse, not clicked it on the switch -- or at least moving the mouse was your last action in the rectangle area. So try again. Pete

Ah! I remembered (but only because John mentioned it in another thread!). There is a facility to Ignore specified buttons! See the Advanced User's guide, search for "IgnoreThese", in the Button Programming section. You can list all the 'real' buttons so that the assigned 'virtual' buttons can be seen and assigned. So, if you want the easiest way out then that's the answer. Sorry I didn't remember this before. I am getting too old! 😞 Pete

Yes, there's something odd with the way the Installer has formed up the Modules folder path after being told where to find the P3D EXE.. Really the problem here is that P3D is not correctly installed. There's no correct installation entries in the registry. It looks like either P3D has been moved, or Windows has been restored from a time before it was installed. This will give many add-on programs problems problems. it would be far better for the user to re-install P3d properly. Pete

If you don't assign those 'ghost axes' to anything, then FSUIPC will not be bothered by them at all. The way DirectInput works is that all buttons, axes, and POVs are read on each scan. It is just one call to DirectInput. This is why there's no 'ignore axis' facility -- there is no need for it at all. Just don't assign axes you aren't using! That only applies whilst you are assigning. It is simply to stop a jittering axis being recognised before one you want to assign. It has no further effect once you exit. I don't think it is worth adding a new facility, as it simply isn't needed. Perhaps alihor can explain what is really troubling him? Pete

Of course. Apologies. I forgot the ignore option only applied to axes. The only reason you are generating "virtual button" presses is for assignment in FSUIPC, right? Instead, why not simply program the action you want directly into the Lua. i.e. use ipc.control to send whatever it is you wuold be assigning to? More efficinet really. However, there's another method which saves all that Lua serial USB handling and relies on Windows instead.. The ROTARIES.LUA file you are using was intended for devices which do not register as regular joysticks in Windows. for those which do there is no need at all to have all that stuff. Instead you can read the buttons directly. Have the Lua pre-loaded via [Auto] and use event.button to act on the button changes -- both on and off. If the time between them is short it is being turned quickly, so you do one thinmg, if else do the other (via ipc.control). One catch. The joystick must be being scanned by FSUIPC for this to work -- only scanned joysticks can cause events to be detected by normal Lua functions. So you need at least one button assigned in FSUIPC, though that can be to something innocuous. Pete

You will need to try monitoring the COM ports to find out. But as John says, use LINDA which you say works! Pete

Since they also look like normal joysticks you'll get both. You will need to suppress the joyskic #3 axes using the button provided, i think it is top right. Pete

Odd that ADE sees it as Concrete even though it must be encoded in the BGL differently, and evidently with a code I don't know about. I have ORBX Arlanda too, so I can check that as well. Might be a few days before I can get to it. Pete

Why have you got Device = 3? You only appear to have one device with that Vendor and Product number! You are telling FSUIPC to select the third such device, which doesn't exist! Pete

Sorry, I am misunderstanding something here. If MakeRunways reports a surface as "unknown" it is because the encoding contains a value which isn't listed in any documentation I have. Do you know what the surface is (Concrete?)? If so I could add it to MakeRunways tables provided i know how it is represented in the BGL. For that I would need to see the BGL itself (EDDN_ADE.bgl). I don't like the idea of "taking over the runway material in the case of runway deletion". Later (and therefore higher priority) AFD files should be able to override all of the earier lower priority stuff. Evidently 29Palms knows something different about that runway -- either that or there's an error in their BGL which they should be asked to correct. Pete

Even if the inputs from the axes are dissimilar, then proper calibration in FSUIPC will match them all to the range expected by FS9. That's the prupose of calibration. So the minumum and maximum will be made to match. How that is spread across the movement of the axis will not necessarily mach across all of the throttles, however. That will depend more on the quality of the controls, how well matched they are. With such an old FSUIPC version (FSUIPC3 for FS9 and before has been out of development for years) there are less facilities for trying to scnchronise the throttle positions, so you have to compensate by simply adjusting the levers to their needed position for the desired thrusts. This is quite realistic -- real throttles rarely match up unless the aircraft is factory-fresh. Pete

I used Ardino once, but I don't remember a lot about it, but the folder with the Arduino software contains Arduino_debug.exe as well as Arduino.exe I seem to remember debugging my little program before using them in practice. Maybe I'm mis-remembering. it was a while back and I am getting old! Okay, so the Lua program is working, though I still think you need to consider what the \n terminator is actually doing. Maybe making the messages fixed length and only sending and reading that number of characters would be better. Well, if the clocks in both Arduino and the PC were also somehow synchronised, and ran at exactly the same speed, and P3D and other threads in the PC didn't interfere with the Lua timing, and the value you are reading changed often enough to guarantee a new value at least on time, and you somehow started the Arduino loop running a millisecond or so after the Lua sending started, then, yes, they might stay synchronised. But no, that isn't possible for most of those reasons. So, if the Arduino read just waits for more to arrive before diving a result then the Arduino loop should be running faster that the Lua. However, none of that explains why the Arduino end isn't seeing the data. Is there no way you can log what it gets -- as you say it is obviously getting something. But I think it will be the Arduino side you need help with. If you want to see what is going out of the COM port you can either use logging in FSUIPC (see below) or a port monitor program. To log COM data add these lines to the [General] section of the FSUIPC5.INI file: Debug=Please LogExtras=x40 The data will be in hexadecimal of the ASCII byte values. This will be all from me till 19th, earliest. Pete

Sorry, what is "OACSP"? Don't you have any means to track what the Arduino is actually receiving? I thought there was a program which could show you everything your program did? I really don't know Arduino. Is "lcd" a standard Arduino library? Sorry, I don't understand the terms used here either. Consistent with what you intend, you mean? So you know the Lua part is okay, then, right? In the Arduino code I assume "Setup" is automatically run on loading. Does the "All Good" message get displayed? How does the "loop()" function get called? How many lines does the LCD have? If only one, wouldn't the '\n' character at the end of each string cause it to scroll off? One other thing I do notice: you are sleeping for 200 mSecs in the Lua, presumably to prevent a pile up of messages in the Arduino. In the Arduino code you seem to have defined the \n as "endmarker" but i don't see that being used anywhere. And in your loop reading the serial data you also delay 200 mSecs. Couldn't having the same delay both ends possibly cause a clash, where you get the last half of one message and the first of the next? I suspect you want to have the Arduino code reading a lot more often. Is there a good reason to have a delay at all? I assume the "readString" will wait till there's something to read? ========================================== Please note that FSUIPC is really just a utility program, not a hardware driver. Specific hardware support does really need to be addressed by the corresponding hardware maker or it's included software. Possibly there's an Arduino support forum which can help, if you are seeing the data logged by Lua matching what you expect. Pete

I'll let Paul answer the questions about the facility in his DLL, but the example picture you show is from a WideClient-connected Joystick, not one local to the simulator PC. Jpysticks 0-15 are the only ones representing true DirectInput joysticks which are scanned regularly on the Sim PC. 64-72 are "virtual buttons" only. These are really just offsets which are changed by FSUIPC applications. You can monitor those using Offset reading facilities. For the correct offsets please check the Offsets list PDF in your FSUIPC Documernts folder. Pete

Well, the LorbySceneryExport program is merely a special version of that AddOnOrganizer which MakeRunways can call directly to do the same processing, -- generating the scenery list you see in AddOnOrganizer, and writing it out to the MakeRunways-chosen filename. The same sort of export can be produced also by AddOnOrganiser (I think you just right-click and select export). So, without being able to see the details in the log ("runways.txt"), I think you need Lorby-SI support to resolve your problem. Pete

I am away from early tomorrow until the following Friday (the 19th), but maybe John or others can help. But you can also try Lorby-Si support, because the MakeRunways_Scenery.CFG file is built by the Lorby-Si scenery export program, and that needs to be correct for MakeRunways to process the scenery files added via the Add-Ons.XML methods. If you have the Lorby AddonOrganiser, run that free-standing and see if that finds all your sceneries okay. If not, then the problem is to do with your folders not found under the correct names. You haven't renamed the Prepar3D.exe file have yo? Just check that it is there is the same folder you placed MakeRunways into. I get the feeling that you are placing it into the wrong folder. Another test: if you remove the scenery export EXE from the MakeRunways folder, then execute MakeRwys, if the folders are correct it should find all of the default scenery layers and any add-on sceneries added the old way, via Scenery.CFG. Pete

The Runways.txt file, which will certainly be there, is the log file showing everything it did. How big is that? Were any of the expected files produced? Also: are you using version 4.801, as per the title of this thread? If so then that will probably explain it. The current version is 4.872! If the Runways.txt file is short enough, or you can cut and paste just the first page or so, then please show us what it says. Pete

and So the throttle unit is a normal Windows-recognised throttle, or does it have specific drivers? What make is it? Check Windows "Game Controllers". Is it seen there, as throttle, and will it show its actions there? If not then that's what FSUIPC doesn't see it. Well the slave PC change would have no effect at all on the main PC so that's not the main problem. And it really isn't possible for things to get messed up by only a change from P3D3 to 4 and FSUIPC4 to 5. They are completely interchangeable as far as FSUIPC is concerned -- well, except for isolated facilities like "mouse macros" which won't apply to ProSim aircraft in any case. So i'm sure something else must have changed in your changeover process. It would be useful to know what, but never mind. Let's move on. I don't think there's much to worry about on the 'slave'. I think we're now only trying to work out why the throttles aren't seen. Incidentally, have you considered assigning and calibrating the throttles in Prosim instead, in any case. I'm sure it suits it better -- as i say, i've been using this method through all ProSim 1 and 2 versions. Why? Prosim is becoming more and more capable. What other cockpit software would you consider? Pete

FSUIPC5 always created the FSUIPC5.Joyscan.csv file. It will certainly be there, in the same folder as your FSUIPC5.INI and FSUIPC5.Log files. I'm finding this a bit confusing. If the Bodnar board is connected to the same PC as your P3D Installation, then that's where the throttle axes will be seen, and directly, not via WideFS. If your throttles are connected to a Bodnar board on a different PC, then WideClient does not send the axis inputs through to FSUIPC, only buttons -- these will be seen as connecting to joysticks with numbers with a client PC number first. Client numbers are listed in your FSUIPC5.INI file, here: [ClientNames]1=SLAVE122=SLAVE133=SLAVE14 I don't know what troubles you are having with connection, or which WideFS client your Bodnar board is connected to (if it is), but the WideServer.LOG you posted showed a healthy connection with "SLAVE14": ********* WideServer.DLL Log [version 7.076] *********Blocksize guide = 8192 (double allowed)Date (dmy): 07/07/19, Time 21:17:29.187: Server name is MASTER11 15085 Initialising TCP/IP server 15085 Initialising UDP/IP server 17082 Connected to computer "SLAVE14" running WideClient version 6.860 (IP=192.168.15.120) UDP 726028 Auto send for 0 stopped before sending all data (0 of 47 sent), Error=10013 (IP=255.255.255.255) UDP 732549 Close signalled to clients 733657 Closing down now ...Memory managed: Offset records: 244 alloc, 242 freeRead buffer usage: 6932 alloc, 6932 free, max in session: 1Write buffer usage: 31690 alloc, 31690 free, max in session: 1Throughput maximum achieved: 20 frames/sec, 789 bytes/secThroughput average achieved for complete session: 4 frames/sec, 137 bytes/secAverage receive rate from "SLAVE14": 9 frames/sec, 552 bytes/sec********* Log file closed ********* The error 10013 is only the disconnection when you closed the P3D session. It was obviously quite happily exchanging data for nearly 12 minutes before this. However, WideFs is not involved in your throttle axis problems. If the only change was from P3D3 to P3D4 and so FSUIPC4 to FSUIPC5, and no changes were made to the hardware at all, then everything would have worked exactly as before. That's always been one of the whole points of the FSUIPC interface -- continuity right through FS versions since FS98. Changes to the USB connections would mean the assignments have to be re-matched, for which I see John has helped sort out for you. Also, re-installs of Windows changes things too because it will generate new "GUIDs" -- the unique identity assigned by Windows to everything (all devices, all objects, even all internal textures and so on). Incidentally, I assume you are using the old version of ProSim (v1)? The latest versions of Prosim v2 do require you to assign and calibrate all flight controls in ProSim. But i have been doing this for my throttles successfully now since first using ProSim, which was then an early version 1. I've only just recently moved my flight controls (yoke, rudder, till0 to ProSim. Pete

When a device is connected, FSUIPC will automatically re-scan the devices in case there are are any assignments which will now work, necessitating a regular devices scan. This is really an essential action, so it shouldn't be inhibited. The answer is to determine why you have disconnections/reconnections occurring so you can fix them. It might be a bad connection in a device, a bad USB connection, a faulty HUB, or even a problem in the USB port on the PC. You've eliminated the last by trying on a different PC To find the culprit among the others will need a process of elimination. The logs and other results John has asked for would also help. Pete

In order to assign any controls in FSUIPC, then FSUIPC must see them! You say they do not work, but maybe you haven't assigned them anywhere? If you didn't use your FSUIPC4.INI as I said you could, then you won't have ANY assignments in FSUIPC if you haven't used the Axis tab to assign them in FSUIPC Options, which, since you don't seem to know about it, you have not. (Please look in the FSUIPC documents subfolder in the Modules folder. there you will finf DOCUMENTATION. Please read through the relevant chapters of the User guide you'll find there. I shows it all with pictures too). Really? In that case I can be of no help as I know nothing about SIOC. You would need help elsewhere. WideFs talks to FSUIPC directly. It doesn't care which version of P3D it is nor which version of FSUIPC. Provided you entered your WideFS key when you installed FSUIPC, then, without any network changes, it will work as it did with P3D3. Perhaps you'd better clarify. Does WideClient, running on the client PC, show that it is waiting for something in the title bar when P3D is running? If not, what does it say? Well, yes, you have to delete it -- otherwise Windows won't let you rename the FSUIPC4 version to the same name. I'm afraid I'm away now for over two weeks. or more questions on FSUIPC5 + WideFS John or others can help here, but for SIOC and ProSim you'll probably need to go elsewhere. Try the ProSim support forum first. Pete