Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. I wish you'd show the files not screen shots that are harder to read and cannot be quoted from! And what's the first one for with an arrow pointing to what looks like it might be SimConnectP3D3? The screenshot of part of the INI file (which as I said would have been far better as text) shows that you've edited the [JoyNames] section and made a mess of it. If I could get at the text I could show you more clearly, but you appear to have changed the letters assigned to all the device, using S, C, T and R, but you left the all important accompanying GUIDs as their defaults of A, B, C, and D. The result is that nothing will match! Please do read the documentation a little more carefully. You will see there are TWO lines for each device, the name and the GUID. Changing one without the other makes it completely unusable. In the event it would have been far better to just let the automatic lettering, A ... Z do its job. Pete
  2. That was good of you. I was just going to use a Comparison program I have. I agree, none of those are involved is anything at all related. Thank you. Pete
  3. Nothing changed? Installing Windows is a huge change and almost always changes all the GUID and Joystick IDs! For some reason Microsoft has registered your Saitek Pro Flight Quadrant twice with EXECTLY the same GUID! 19000 ---------------------- Joystick Device Scan ----------------------- 19000 Product= Saitek Pro Flight Quadrant 19000 Manufacturer= Saitek 19000 Vendor=06A3, Product=0C2D (Version 2.2) 19000 Assigned joystick id 2 (fixed Registry) 19000 GUID= {71690BD0-222A-11E7-8002-444553540000} 19000 Product= T-Rudder 19000 Manufacturer= Thrustmaster 19000 Vendor=044F, Product=B679 (Version 1.16) 19000 Assigned joystick id 0 (Registry okay) 19016 GUID= {A17BFC30-221E-11E7-8009-444553540000} 19031 Product= Saitek Pro Flight Quadrant 19031 Manufacturer= Saitek 19031 Vendor=06A3, Product=0C2D (Version 2.2) 19031 Assigned joystick id 3 (fixed Registry) 19031 GUID= {71690BD0-222A-11E7-8002-444553540000} 19031 Product= Saitek Pro Flight X-55 Rhino Stick 19031 Manufacturer= Madcatz 19031 Serial Number= G0000016 19031 Vendor=0738, Product=2215 (Version 0.87) 19031 Assigned joystick id 1 (Registry okay) 19031 GUID= {A1DEAA10-2228-11E7-8001-444553540000} 19031 ------------------------------------------------------------------- and it looks like the T-Rudder joined the party late (see the two separate joystick scans because of that). If you have two throttle quadrants they MUST have different GUIDs, otherwise FSUIPC will only be able to access one of them -- and the Joystick ID might keep changing. I am suspecting something odd in your registry. Please run Regedit (from the place Win10 allows you to type in program names to look for them). You will see it comes up with an Explorer type Window. Navigate right down to HKEY_CURRENT_USER\System\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput then, in the File Menu select Export ... and choose a place to save the data -- save it as a Txt file, NOT a Reg or you won't be able to upload it here. then, before leaving Regedit, do the same (but with a different name of course) with HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput (Don't worry if you can't find one of the above. As long as one of them is there. But there are both normally). Then please show me both files. I am rather worried that the new Joystick scanning mechanism I implemented, which was supposed to solve these sorts of problems properly, may not cover all cases after all. I should be able to tell from this data whether it is me or you genuinely do have a Registry problem. Thanks, Pete
  4. What changed? P3D or FSUIPC or both? Or Windows, what, the really good Win7 to the problematic Win10? No need to use JoyID these days. FSUIPC does what that used to be needed for, to make sure proper IDs were assigned. I'd need more details, like your FSUIPC4.INI and a LOG. You can paste their contents here. Pete
  5. No, no way. You'd need to do that in a Lua plug-in. Easy enough with a little program. Pete
  6. Why on Earth put my SimConnectP3D3.DLL in the main P3D folder? It is only used by FSUIPC4 and it won't find it there! DELETE IT! Just download and install FSUIPC 4.966 which with install a new DLL in the correct place! Why not try the User uide? That's what it is for. There's a chapter about it which is even listed in the Contents, right near the beginning! Or just change "AutoAssignLetters" to Yes in the [JoyNames] section of this INI file if you don'tcare what letters are used. i prefer letters liky Y for yoke, T for throttle, R for Rudder etc. Pete
  7. Well, nothing about this seems remotely concerned with FSUIPC, so I've no idea still why you posted the previous entry nor what on Earth it means. Pete
  8. The log shows both X55 stick and throttle recognised, as joysticks 1 and 2, with your Saitek rudder as 0. Do you perhaps has the assignments differently? Really with multiple controls you should use joy letters. Do you? The log shows a different problem entirely, one concerning SimConnect's faculties. That's the puzzle, not joystick devices. Pete
  9. Sorry, I've absolutely no idea what you are on about there. There has NEVER been a SimConnect DLL in the FSUIPC-created modules folder till P3D, and only then , reluctantly for the reasons given. Only FSUIPC uses SimConnectP3D3.DLL. Other programs may use the Modules folder (but there's not many I know of), but not my DLL. Perhaps you'd be good enough to explain what all that was about, please, Pete
  10. This DLL is ONLY used by FSUIPC, nothing else. It was made simply because by default P3D did not come provide with SimConnect access via DLL, only by direct compilation with their Library (.LIB file). When users of P3D also have, or previously had, FSX or FSX-SE, they would have already had SimConnect DLL installed. Maybe RTM, SP1, and/or SP2/ACC versions. FSUIPC can use any of those with P3D, but with a few facilities missing, but it will only do that if the SimConnectP3D3.DLL is removed from the Modules folder. I don't see why anytone would do that, except in the case of my previous DLL not working with P3D versions before 3.4. It's the Level D website then, isn't it? Who makes that? I thought that pre-dated P3D by quite a stretch. Pete
  11. Install FSUIPC 4.966 if you want my support! Neither PMDG nor Aerosoft Airbus have anything to do with any of my software. 4.966 will not do anything at all for them. The other SimConnects you are installing won't have any affect on FSUIPC either-- unless you actually remove my SimConnectP3D3. DLL, as that is used in preference AND is more up to date. I suggest you now go to the PMDG and Aerosoft fora respectively. It sounds like you've messed things up quite well, but, sorry, I cannot help. Pete
  12. I doubt whether they are capable of recognising what probably amounts to inconsistencies with device identities and GUIDs rather than outright errors or corruption. Hmmm. I suspect that is quite likely. I've always found i need to reinstall everything after a mobo change. CPU, RAM and Video Card upgrades on the same mobo are fine. I did actually once purchase a program which said it could transfer a system complete from one PC to another even if the latter was completely different (i.e. especially mobo -- the rest is easier). The target machine was a newly built one from a specialist dealer. The program cost over £100 so i thought it "must" be good. Well it seemed to do it. It announced success and when I looked nearly everything seemed to be there okay. There were a few things it didn't manage, so I sorted those manually. Within a few days I was tearing the little bit of hair I've got out with frustration.I ended up wasting the £100 and 5 days and starting from scratch. I finished reinstalling everything, after a re-format, within a week (long hours, mind). But then I have LOT of stuff and I am very fussy about what things look like. I have developed a way of working on computers which is too comfortable. (One reason I am avoiding Win10 completely -- just have it on my Surface Pro). Pete
  13. I have seen that on the signs, yes. I live just a couple of hundred metres outside Stoke-on-Trent, in a place called Biddulph, which is twinned with Fusignano in Italy, not far from Bologna. Pete
  14. Yes, of course I did suggest that something might be messed up in your Registry. However, messing with the registry is not for the faint-hearted and most folks would find a Windows restore more palatable. Do you have a restore point at all from when you never had either Bodnar board? Else it would have to be a reinstall. I don't think you'd need to reformat, unless you do suspect disk corruption. Of course, if it is long ago then restoring may effectively uninstall many things you've added since then -- not removing the actual programs, just making them look missing as far as programs checking the registry for locations, etc, are concerned -- and will often also require you to re-register programs with passwords and/or keys. Pete
  15. The "PT,0" part says "when button 0 on T is pressed ... ". But this is a macro which you are presumably going to assign to a button! Which button? Sorry, maybe I didn't see all this before. I've been so busy sorting other problems out. Now FSUIPC 4.966 is released with those problems resolved i can think more clearly about other things. The condition on acting on a button press or release is part of the testing of the button to see whether to ignore that press or release or not. As such it is part of the assignment only, not of the macro. The macro execution is a possible outcome of the button press if the condition allows it. To put it another way, since all button conditions are based on whether the button is acted on or not, there are no condition facilities in macros. The macro is merely an action which can be assigned to a button or keypress. There is nothing else but that. It is executed or it isn't. You can have a macro like [Macros]1=OpenAllDoors1.1=K69,9 -{Key press: shft+E}-1.2=K49,8 -{Key press: 1}-1.3=K50,8 -{Key press: 2}- and button assignments to execute this macro based on conditions. But this brings me back to the question I asked a while back: "Why use a macro when you can do it by just button assignment, as it looks like you've done?" There is really no advantage in using a macro for this unless it is to build a set of macros to help others make assignments to functions on specific aircraft.. I do realise that it would theoretically possible to have button conditions in macros, though it could get very complicated if there were conditions on the button as well as on the macro actions. However, some time ago I decided that I ought to avoid adding more and more complex programming facilities to the separate features of FSUIPC because this tends to break more things than it adds as well as making it more and more obscure for users. I decided to add the Lua interpreter to it instead, a well-respected scripting language designed specifically for enabling simple and more complex parameters to be used in driving programs -- as well as actually adding facilities, which was an unexpected bonus of this approach. If you want to do interesting things I recommend you look at using Lua instead of Macros. I probably wouldn't have added the macro facility at all if I'd discovered Lua first! The syntax and rules for macros (and button programming) are arcane and very restrictive and error prone by comparison. On the other matter: I had this assignment: 2=P174,6,Cx0D003367,x03 -{offset byte togglebits, offset 3367}- (Joystick 174 is a Goflight RP48) Both doors were definitely opening or closing on the default FSX Beaver. With Event and Button logging enabled in FSUIPC I get this shown in the LOG: 659510 Button changed: bRef=0, Joy=174, Btn=6, Pressed 659510 [Buttons] 2=P174,6,Cx0D003367,x03 659510 IPC Offsets Control: Ctrl=x0D00, Length=1, Offset=3367, Param=x3 659510 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00000040} 659510 *** EVENT: Cntrl= 66389 (0x00010355), Param= 1 (0x00000001) TOGGLE_AIRCRAFT_EXIT 659510 *** EVENT: Cntrl= 66389 (0x00010355), Param= 2 (0x00000002) TOGGLE_AIRCRAFT_EXIT 659697 Button changed: bRef=0, Joy=174, Btn=6, Released 659697 JoystickValues PCnum=0, dwCount=1, data[2]={000000ae 00000000} You can see that all that changing bits in offset 3367 does is send the exact same FS control that shift E does. The parameters for that control select the door, so FSUIPC here sends the control twice, with parameters 1 then 2. You could actually program such parameters in FSUIPC for the control too, rather than use the Shift E keypress method, which is rather crude compared to sending the controls directly. To illustrate that here's what happens when I press Shit+E then 1 then 2: 1657744 KEYDOWN: VK=16, Waiting=0, Repeat=N, Shifts=1 1657744 .. Key not programmed -- passed on to FS 1658212 KEYDOWN: VK=69, Waiting=0, Repeat=N, Shifts=1 1658212 .. Key not programmed -- passed on to FS 1658212 *** EVENT: Cntrl= 66389 (0x00010355), Param= 0 (0x00000000) TOGGLE_AIRCRAFT_EXIT 1658290 KEYUP: VK=69, Waiting=0 1658337 KEYUP: VK=16, Waiting=0 1658696 KEYDOWN: VK=49, Waiting=0, Repeat=N, Shifts=0 1658696 .. Key not programmed -- passed on to FS 1658696 *** EVENT: Cntrl= 66389 (0x00010355), Param= 0 (0x00000000) TOGGLE_AIRCRAFT_EXIT 1658712 *** EVENT: Cntrl= 65538 (0x00010002), Param= 0 (0x00000000) SELECT_1 1658790 KEYUP: VK=49, Waiting=0 1659055 KEYDOWN: VK=50, Waiting=0, Repeat=N, Shifts=0 1659055 .. Key not programmed -- passed on to FS 1659055 *** EVENT: Cntrl= 66389 (0x00010355), Param= 0 (0x00000000) TOGGLE_AIRCRAFT_EXIT 1659055 *** EVENT: Cntrl= 65538 (0x00010002), Param= 0 (0x00000000) SELECT_1 1659055 *** EVENT: Cntrl= 65539 (0x00010003), Param= 0 (0x00000000) SELECT_2 1659195 KEYUP: VK=50, Waiting=0 You can see, by comparison with the direct use of the control actually named "Toggle aircraft exit" in FSUIPC assignments the FS process is a lot less clumsy. BUT both methods work fine here, with all the aircraft I've tried. Something odd is going on with your system if the offset method doesn't work. Perhaps you should ebable the Button and Event logging so we can check. BTW FSUIPC 4.966 is released and that is what I was using. Maybe youshould update first? Pete
  16. I'm releasing 4.966 this afternoon (Saturday 15th), earlier than I expected as I've solved the other problems I had with it which I thought might take a few more days ... Pete
  17. I've tested with several different formats and with several different programs, and this form: RUN4=READY,CLOSE,"C:\IVAO\IvAp v2\ivap_dllhost.exe C:\IVAO\IvAp v2\ivap_fsx.dll" should most certainly work, provided the EXE program can be found and the parameter provided is correct. The whole program pathname including the parameter (i.e. everything in the "" above), but without the "", is submitted to Windows via the CreateProcess function. This implies that the program pathname is okay. So I researched further. It seems Windows needs the program path to be one space-delimited parameter. Else, for each space it tries to find an executable file. In the case above it will try: C:\IVAO\IvAp.exe before C:\IVAO\IvAp v2\ivap_dllhost.exe and then, if Ivap.exe loads, it will give it parameters v2\ivap_dllhost.exe C:\IVAO\IvAp v2\ivap_fsx.dll In my testing this morning it seems that, although I was using paths with spaces (and more that one!), the EXE names it came up with all failed to find a file UNTIL it had the whole intended program name. So, I think the problem all along was bad luck and you have a file C:\IVAO\IvAp.exe (or another executable file named IvAp in the same folder). It seems Windows needs this: "C:\IVAO\IvAp v2\ivap_dllhost.exe" C:\IVAO\IvAp v2\ivap_fsx.dll but FSUIPC strips off the ""! I think this dates back to when FSUIPC was using the WinExec function instead of CreateProcess. The WinExec allowed separately specified parameters. So, I fixed it. You'll need to download and install 4.966 when I upload it -- it will be here and on the Schiratti site -- withing the next hour or so. Change to line to that just above and you should be good to go. Pete
  18. Okay. The mystery of the SimConnectP3D3.DLL incompatibility with P3D3.3.5 is resolved. Apparently L-M made changes to their supplied LIB file, needed to interface to P3D, which rendered it incompatible with previous versions of P3D3. This is unusual and unexpected. It was already known to be incompatible with P3D2. In fact the major versions, 1, 2 and 3, all have non-backward-compatible SimConnect LIBs. This is the first time a secondary update version has affected this compatibility. I have tested the older DLL (the one in the SimConnectP3D30.ZIP file) with P3D3.4 and it is okay, so that can be used as an interim fix for P3D3.0-3.3 users till I can release the next installer. FSUIPC uses a function which isn't included in the P3D3.0 version if the DLL, so the newer installer will install a revised version of the 3.0 DLL with that function added. The fact that it is missing in the meanwhile does no harm -- you just lose some version information in the log. I'll make a sticky with this information and the link so it will be seen at the top of the Forum. Apologies to those affected by this problem. Pete
  19. Is this with ProSim too? I seem to recall a thread on the ProSim forum about it having problems with over a number of boards. Pete
  20. You must be losing the FSUIPC4.REG file from the Modules folder. Show me the two logs in the Modules folder, the FSUIPC4.LOG and the Install log. Do this AFTER closing P3D. And check that there is still an FSUIPC4.REG file in that folder (do not post it here). Pete
  21. I've moved this from the FAQ subforum, which is for refernce subjects. Your problem is NOT the same problem as that which the FAQ thread was dealing with -- you have a strange problem with one out of three levers on the same device. Since this is not about FSUIPC at all, but only FSX, I really suggest that you re-post in the relevant AVSIM Forum. I suspect you might get more response there. I cannot imagine what is happening, though the first test you should do is see if it works in FSX when assigned to another control. It may be to do with the aircraft you are using. Pete
  22. Try eliminating (i.e. preventing running) one thing at a time from the Add-Ons menu. In fact, can you list them for me? I can try to tell you which ones I know are okay. Pete
  23. Okay, thanks. I too would like to know the difference. Pete
  24. You register in the Installer. The file it produces is "FSUIPC4.KEY" and it is placed in the Modules folder. It it only ever read by FSUIPC, never written. Pete
  25. There's no mention of LETJ at all in the Runways.TXT file. I've no idea what file it is supposed to be in. And the KCGX folder has no BGL recognised as an Airport Facilities Data (AFD) file. When you say they are "well recognised in the simulator" do you mean just visuals, or are they selectable with runways and/or gates in the "Go To Airport" dialogue? If they are so featured then they are included in some strange format of AFD which I, and therefore MakeRunways, have not encountered before -- neither FS9 nor FSX format. Are they P3D only format using some new system? I also see there are many others at the end of the Runways.txt file, equally with no AFD files. Are they airports too? (See befow). Pete ============================================================================= Area.173 "Hawaii Islas - Kahoolawe" (Layer=173) Path(Local/Remote)=F:\Flight\Escenarios\Oceania\Pacifico\Hawai Islas\FSX & P3D - Hawaii Photoreal Vol. 2 - Kahoolawe v.1.0 Plus\scenery ============================================================================= Area.174 "Hawaii Islas - Lanai" (Layer=174) Path(Local/Remote)=F:\Flight\Escenarios\Oceania\Pacifico\Hawai Islas\FSX & P3D - Hawaii Photoreal Vol. 2 - Lanai v.1.0 Plus\scenery ============================================================================= Area.175 "Hawaii Islas - Maui" (Layer=175) Path(Local/Remote)=F:\Flight\Escenarios\Oceania\Pacifico\Hawai Islas\FSX & P3D - Hawaii Photoreal Vol. 2 - Maui v.0.97 Plus\scenery ============================================================================= Area.176 "Hawaii Islas - Molokai" (Layer=176) Path(Local/Remote)=F:\Flight\Escenarios\Oceania\Pacifico\Hawai Islas\FSX & P3D - Hawaii Photoreal Vol. 2 - Molokai v.0.99 Plus\scenery ============================================================================= Area.177 "Hawaii Islas - Molokini" (Layer=177) Path(Local/Remote)=F:\Flight\Escenarios\Oceania\Pacifico\Hawai Islas\FSX & P3D - Hawaii Photoreal Vol. 2 - Molokini v.1.0\scenery ============================================================================= Area.178 "Hawaii Islas - The Big Island" (Layer=178) Path(Local/Remote)=F:\Flight\Escenarios\Oceania\Pacifico\Hawai Islas\FSX & P3D - Hawaii Photoreal Vol. 3 - The Big Island v.0.93\scenery ============================================================================= Area.179 "Hawaii Islas - Barco" (Layer=179) Path(Local/Remote)=F:\Flight\Escenarios\Oceania\Pacifico\Hawai Islas\Barco\FSX HAWAII-SHIPS-PEARLHARBOR-2015-C\Scenery ============================================================================= Area.180 "Trebujena (Cadiz)" (Layer=180) Path(Local/Remote)=F:\Flight\Escenarios\Europa\Espana\Trebujena\scenery
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.