Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. The log shows you pressing several buttons. Is this right? 167750 *** Entered Buttons option page *** 192282 FirstButtonChange res=00000003 (0.0, 3) Button 3 231110 FirstButtonChange res=00000002 (0.0, 2) Button 2 231125 FirstButtonChange res=00000011 (0.0, 17) Button 17 232157 FirstButtonChange res=00000002 (0.0, 2) Button 2 again 232172 FirstButtonChange res=00000012 (0.0, 18) Button 18 233078 FirstButtonChange res=00000002 (0.0, 2) Button 2 again 233094 FirstButtonChange res=00000010 (0.0, 16) Button 16 247063 *** Exiting Buttons option page *** It looks like button 3 was pressed first, as it is 39 seconds then before any other button is pressed But then the others are in pairs -- button 2 + 17, 18 and 16 respectively, each pair with a second between. If all that is the result of pressing just the one button then there's something very strange going on with that joystick. Are you sure there's no other software doing this? Did you install a driver for it? If so it might be that is the porblem. I see that you have programmed button 16 successfully: 251328 Button changed: bRef=0, Joy=0, Btn=16, Pressed 251328 [buttons.C182_N6182G] 0=P0,16,C65561,0 251328 FS Control Sent: Ctrl=65561, Param=0 251500 Button changed: bRef=0, Joy=0, Btn=16, Released 253938 Button changed: bRef=0, Joy=0, Btn=16, Pressed 253938 [buttons.C182_N6182G] 0=P0,16,C65561,0 253938 FS Control Sent: Ctrl=65561, Param=0 254047 Button changed: bRef=0, Joy=0, Btn=16, Released and it is working okay. If you want to program 17 and 18 to do the same, just make copies of that assignment in your FSUIPC4.INI file -- the part in Red above, with new line numbers (the value before the =) and 17 and 18 replacing the 16. If the one button is representing 16, 17, and 18 I don't see why you'd want to program them to do different things. But you seem to be implying that this 3-buttons-in-one operation is an intentional part of the device's design? Looking earlier you said something which I now realise is contradictory: If button 16 is obtained on the first press, why do you say you have to press it twice to get the assignment obeyed? The log clearly shows that it successfully sent the assigned control (65561 = Pause Toggle). So it worked on one press. The log actually showed the order to be 17, 18, then 16, implying you need to press three times to get the button 16 assignment actioned. Pete
  2. Well, I would have needed to see the results in the INI file of what you "tried". That simply deletes the assignments for the currently detected axis. So that's exactly what I suggested, deleting the duplicate assignment. What was it you thought I suggested? Having two axes assigned to the same control will always produce conflicts unless you ensure one of the assigned levers is kept parked in a place with no jitter. Pete
  3. No, not at all. WideFS merely extends the FSUIPC application interface to other computers, for running those applications separately. What you are mixing it up with is WidevieW, by Luciano Napolitano. Pete
  4. Stranger and stranger, because in that case all WideFS is doing is opening a port. With "AdvertiseService=No" also set it isn't actually doing anything except that. That's an access violation, meaning usually that the module concerned is using a bad memory address, or one not within its process. I've never heard of USP10, but checking on my system I see I have many copies installed, and many different. There are 8 different versions installed in the WinSxS folder -- 4 for 64-bit, 4 for 32-bit. Then Office 10, 11, 12 all have different versions, and also Visual Studio 10 and 12. All seem to be different, judging by the sizes. I wonder if trying a different one might help? Not sure how you'd do that -- maybe putting one in the FSX folder would get it loaded instead of the one in whichever Windows folder it is loading from. Not really. if the process is terminated by a crash it won't be continuing then to generate another one. That DLL doesn't appear to be part of those, at least not only part of those. I just used Dependency Waker on FSX.EXE, and the dependency on USP10.DLL is nested like this: [ ] FSX.EXE [ ] MFC80.DLL [ ] GDI32.DLL [ ] LPK.DLL [ ] USP10.DLL Not that this helps much, I'm afraid. Not sure what else can be done. I myself am a very heavy user of WideFS (I wrote it for my own use originally, with the first editions of Project Magenta). My cockpit system uses 8 PCs, 6 clients linked by WideFS, 2 of which also have SimConnect linkages.and 1 by a separate linkage (Aivlasoft's EFB). If I could reproduce the problem I might be able to get to the bottom of it, but I've no idea how. I'm sure it must be something in your system. If experimentation with alternative USP10's, or a repair/replacement of it, doesn't work or seem viable, I would suggest uninstalling your Network hardware in Device Manager (drivers too), then re-booting so the system finds it again and replaces the drivers. Pete
  5. No idea at all. How is your button doing different things each time? Is it meant to? Is it in the user guide for the device? All I could help with is to tell you what is happening. For this you need to enable Button logging in FSUIPC's logging tab. Then test and show me the log. Pete
  6. It is perfectly correct behaviour. Button and Key assignments can be both Generic and Profile-specific. All that happens is that the Profile-specific assignment overrides any generic assignments for the same button or keypress. This allows the majority of common controls (Gear, Lights, etc etc) to be made just once and apply to all aircraft whilst those switches and options specific to the aircraft can vary. Axes and Joystick Calibrations are either generic or profile specific. They cannot be mixed, because axes are effectivey active all the time, whereas buttons and eyes only do something when you press them. This is written up in the documentation somewhere. I think if you log buttons/switches (an option in FSUIPC's Logging tab) it will show in the log. But of course you can simply click the button and see. Pete
  7. Ah, thanks. Always useful to have a reference. I believe those two turned out to be Network errors, related to a thread trying ot access Network options already closed. I think SimConnect was also in use across the Network. You say: What about if you don't even start WideClient, so that the Network never really got used? I tried the hotkey and allowshutdown options prior to seeking your help The problem I have here is lack of information. Are there no more details of the crash available, eg. from the Windows Event Viewer? Another thing you could do is to stop WideServer broadcasting, just in case it is only related to that channel. AdvertiseService=No You'll need then to be sure that your WideClient.INI file includes the ServerName or ServerIPAddr, and the Protocol. Pete
  8. Well spotted Thomas! Maybe the problem is related to one of those? Pete
  9. This is a support request, moved from User Contributions subforum. Please always post support questions here, not in the specialised subforums which are for the purpose implied in their titles. You have a Regstry problem with your installed FS. To help resolve that I need to see the Install log. That's why one is made. That will contain all the details. You'll find it saved in the FSX modules folder, and also in the folder where you ran the Installer. It is a text file -- you can paste it in its entirety in a reply here. Pete
  10. Would that matter, for this test? It isn't logging every two seconds. The pair of vales are logged together within a fraction of a second, with the -2471 being prevalent and then sticking for a variable number of seconds, sometimes less than a second. The difference between the two numbers is very small -- 260, just enough to be registered by FSUIPC. You could actually make a small change in the INI file for it to be diregarded. I'm surprised it's enough to see movement on screen. Yes, small jitter is a frequent problem, usually occurring when the point of contact in the lever mechanism is just between the two values. It can be exacerbated by wear and tear, by dirt, humidity, and slight variations in the voltage supplied. Best to disable controllers, not to worry about assignments. So, you did not actually test with Mixture 2 assignments removed in FSUIPC? Looking at your Assignments in FSUIPC I see, in the Generic axis assignments.two axes on the same controller both assigned to "Axis mixture2 set": [Axes] 4=0V,256,F,66425,0,0,0 9=1V,256,F,66425,0,0,0 For the Q400 you have no Mixture2 assignments, and for the Piper PA23 you have just the one:You only have 4=0V,256,F,66425,0,0,0 So, I suspect you have an assignment you forgot about (one of those two generic assignments) and it is that which is setting the mixture without your intention. BTW, after you've corrected this, if you still have that jitter and can't fix the device, you can mask it by ncreasing that '256' value in the assignment to, say, 300. I'd also advise you to enable joystick lettering. With 5 different devices you wouldn't want them to get mixed up just because you unplugged one, or updated Windows, or similar. Pete
  11. I've never had any other reprots of such a problem, and WideFS hasn't changed at all in many years. I'd need you to narrow it down. Is WideServer connected to a Client when you exit? If so, what is it running? What if you close the client Application before closing FSX? What if you also close WideClient first? What if you close down using the WideServer hotkey option ("ShutdownHotKey"(? BTW, it's "Dowson" not "Dawson", and version 4.949h has been superseded by 4.949p. Pete
  12. You have lots of changes going on, earlier for mixture 1 too. And lots of other commands being issued! Without knowing exactly what you did here, I can't make any sense of the log. You ran the session for 6 or 7 minutes, with the first 3 or so spent in doing other things with VOR1 and many other controls. Does it take all that to induce your problem? You say but the earlier part of the log shows both Mixtures being operated in concert, The Mixture 2 alone changes start here, i.e. after nearly 5 minutes into the session. 283063 Sim stopped: average frame rate for last 124 secs = 28.3 fps 283063 Max AI traffic was 59 aircraft 293999 *** AXIS: Cntrl= 66425 (0x00010379), Param= -2731 (0xfffff555) AXIS_MIXTURE2_SET And even then it isn't "nudging every few seconds", is is simply jittering around two values, -2731 and -2471. Jitter is quite common with some joysticks.. There maybe a nearby more stable spot to park the lever. Buttons really don't come into it. It's axes or levers. There's most certainly an input, a jittery one, which is assigned somewhere to Mixture 2. If it isn't assigned in any way in FSUIPC then it is either in P3D or some other software you have running. If you want me to check your FSUIPC assignments you need to post your FSUIPC4.INI filer. Pete
  13. It still isn't making sense. How do you assign keys AFTER closing P3D? Aren't you using the FSUIPC options? FSUIPC doesn't run outside of the Sim. There is no control for "GSX window", so how are you assigning it? If you want F12 to go direct to GSX then you must delete its assignment in FSUIPC! And FSUIPC won't be changing anything back. You have F10, F11 and F12 assigned, but not C X or V. That is what you said you wanted. I still don't see where FS2Crew comes into all this. Pete
  14. Er, sorry, I still don't understand. You assigned keys to WHAT functions? What was the assignment to? Where does "FS2Crew" come in and why is it relevant? FSUIPC doesn't care why you assign things, but it needs to know what you want it to do when you press the keys. You say you "changed the assigned keys to another keys". How? Did you delete the previous assignments first? You can assign all your keys to different functions as you wish. They are all separate. You just can't assign keys to keys as you are implying, at least not directly. You say you assigned keys then closed down and rebooted and changed them. Why? Why not just assign them as you want in the first place? Looking at your INI file, I see you have no keys at all assigned by default, you only have them for the 737NGX. So when you load something else they won't be operative. The assignments are: [Keys.737NGX] 14=223,8,66278,0 .........The `¬¦ key (left of the 1 key) assigned to Rudder trim left 15=49,8,66279,0 ...........The 1 key assigned to Rudder trim right 16=81,8,66695,0 ...........The Q key assigned to Toggle jetway 17=123,8,66317,0 .........The F12 key assigned to Toggle alternate static 28=121,8,66297,0 .........The F10 key assigned to Toggle autofeather arm 29=122,8,66317,0 .........The F11 key ALSO assigned to Toggle alternate static So F10, F11 and F12 are assigned, though F11 and F12 are assigned to the same function. There are no assignments to the Z X or C keys, so whatever they do will be up to P3D or any other program which may be intercepting them. Pete
  15. I don't understand. You are assigning keys to keys? How? FSUIPC has no easy way to save a "conversion" of one keypress into another -- you'd have to assign to an FSUIPC control which in turn sent a keypress. Show me your FSUIPC4.INI file please. Your settings are saved there when you "OK" out of the options. There's no way FSUIPC will lose them, so I suspect you have assignments you are not aware of.. Pete
  16. Version 4.949h is out of date and not supported. The current version is 4.949p. There must be something doing this. What add-ons do you use? If there is nothing assigned to mixture 2 either in P3D or FSUIPC, then it must be either something else sending the mixture set control, or a bug in the add-on aircraft. If it happens with default aircraft it must be the former. Try enabling event and axis logging in the FSUIPC logging tab. Keep the session short, just enough to see the problem, then close down and show me the log. But please update your FSUIPC first. Pete
  17. The details you provide show it isn't FSUIPC causing a crash: Framework Version: v4.0.30319 Description: The process was terminated due to an unhandled exception. Exception Info: System.ArgumentException at System.TimeSpan.Interval(Double, Int32) at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr, Int32, IntPtr, IntPtr) FSUIPC doesn't use any part of Framework. Something you have running which uses FSUIPC is probably the culprit. The Log shows you using LINDA. Maybe there's some incompatible element in that? Does it use .NET Framework? I'm afraid I know nothing about LINDA. So, first see if you still get crashes without it, and then see if LINDA support can help. If it isn't LINDA then, as you say, There's something odd about those add-ons, maybe only in relation to LINDA. FSUIPC does care or know what aircraft you are using. Changing buttons or axes goes through the same code for all. Pete
  18. It sounds like something else is grabbing the mouse inputs first. Did it work with the middle mouse button before you disabled it in FSUIPC's INI file? Are you assigning the space bar to the FSUIPC "mouselook toggle" control, or using the on/off facilities in FSUIPC, or leaving it to the default FS control? Either way, try the other. Maybe the FS keypress is being taken by something else. Perhaps you should show me your FSUIPC4.INI file so I can check your assignments. You could also enable some logging so I can see what's happening. You can enable key/button logging, and also event logging in FSUIPC's logging tab. Pete
  19. This makes no sense. How is it you have two installations of FSX-SE? What are the different Modules paths? Which one are you running? Steam itself only installs ONE copy, which will go into the Steam folder (wherever you decided that should be). So C:\Program Files(x86)\Steam\steamapps\common\FSX would be correct if you let Steam itself decide where it should be placed. The log files named by SimConnect would be SimConnect0?.log, where ? runs from 0 to 9. Just look for files using the mask SimConnect*.log Maybe there are log files there but you are not seeing them. Maybe you have Windows Explorer folder options set (as they are by default) to hide known filetype names from you. Log files would appear just as text files most probably. To make it easier for you to find the log, why not just tell it to save the log to the C:\ root directory. i.e. file=C:\SimConnect%01u.log You say: I am wondering if this is the root of all your problems. There cannot be two copies if you let Steam do the installation. It isn't bad news for me, only for you. It seems likely that your Steam installation is in a right mess. If SimConnect won't load any DLLs then there's no way I can fix it from here. I can only make my program work when it is being loaded, which is FSX-SE's job.. I'm only trying to help you find out what is wrong with your installation, and so far all we seem to have discovered is that you have two installations! Looking back now at the Install log you posted I do now see that the registered path for FSX looks okay, but the one for FSX-SE, which should be identical, points to the incorrect one you mentioned earlier: Looking in registry for FSX install path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Games\Flight Simulator\10.0 Parameter"SetupPath" ... >>> OK! FOUND FSX! <<< ... SetupPath=C:\Program Files (x86)\Steam\steamapps\common\FSX Looking in registry for FSX-SE install path: HKEY_LOCAL_MACHINE\SOFTWARE\DovetailGames\FSX Parameter"Install_Path" ... >>> OK! FOUND FSX-SE! <<< ... SetupPath=C:\Program Files (x86)\Steam\steamapps\common\FSX\steamapps\common\FSX Looking further down, the actual FSUIPC installation sensibly only uses the correct path: INSTALLATION FOR FSX:SetupPath="C:\Program Files (x86)\Steam\steamapps\common\FSX\" Checking version of the FSX EXE: ... Version 10.0.62615.0 (Need at least 10.0.60905.0) ... NOTE: This is actually FSX-SE masquerading as FSX-MS which also means it ONLY installed into the Modules folder in that copy, NOT in any Modules folder you might have in the place with the more convoluted path, the one which certainly looks wrong. So, are you perhaps running the wrong install of FSX-SE? Try running (double-clicking) the FSX.EXE in folder C:\Program Files (x86)\Steam\steamapps\common\FSX\ If that doesn't work, it might be best for you to start again. Uninstall it all, including Steam, and re-install from scratch. In fact given the mess int's in, it might be best to do that in any case. Pete
  20. You just installed P3D version 3.1? Really? I think you should be on 3.2. Why are you now installing an older version? And I ALWAYS need version numbers. Just saying "latest version of FSUIPC" is no help. Folks have said that meaning the latest they bothered to download, or latest they already had on their system, and they've sometimes been a year old! Finally, I need more information in any case, like the Windows crash details, the FSUIPC4 Install log, and the FSUIPC4 run time log (two log files in the Modules folder). You can paste these into a message here. Pete
  21. Of course. They are needed. As I said, it's the '-' characters (the hyphens) at the start of those three lines which are wrong/ No. Not only does it look completely wrong (the same path is there TWICE!), but it doesn't contain a filename! There is no way a SimConnect.log file can be produced because you've not told it what the filename should be! The filename is the name of the file you want to see. The path only tells it where to put it. You can put it in C:\ if you like! Did you not actually read the FAQ thread I mentioned. Look now. See the "file=" line? file=path to FSX\Modules\SimConnect%01u.Log Then see below where it says: where you need to replace the "path to FSX" by your particular path for the main FSX folder, Just so you can see this more clearly, I'll highlight in read the parts you seem to have ignored: file=path to FSX\Modules\SimConnect%01u.Log where you need to replace the "path to FSX" by your particular path for the main FSX folder, The "SimConnect%01u.Log" part is the filename. SimConnect will replace the %01u" part with a number, 0-9, changing each time you start FS again, so it can save the last 10 logs altogether. Your entry appears to be two copies of just the "path to fsx" stuck together: C:/Program Files(x86)/Steam/Steamapps/common/FSX/Steam/steamapps/common/FSX You also appear to be using / characters instead of the correct \ characters. The / character is used mostly in URLs (in browsers). File paths in Windows use \, again as shown in the thread you should have referred to So, unless you somehow explicitly told Steam to install it into such a convoluted path, it will be just C:\Program Files(x86)\Steam\Steamapps\common\FSX Also you omitted the "Modules" part of the path needed altogether. Putting it all together, the file= parameter you needed would be: file=C:\Program Files(x86)\Steam\Steamapps\common\FSX\Modules\imConnect%01u.Log Next time please read things more carefully. You made at least six different mistakes in doing something which was spelled out. Pete
  22. Er, just monitoring those offsets doesn't change them. It doesn't change anything. You must have done something else differently. Maybe you didn't have WX Radar switched on before? You didn't add those two lines to the INI file I mentioned, so the logging is not diagnostic in any case, so if it wasn't working it wouldn't have helped. All the monitoring shows is: Before everything is started: 43337 Monitor IPC:861C (U16) = 0 ......range = 0 43337 Monitor IPC:8624 (U16) = 0 .......wx radar = off Then things kick off: 94677 Starting everything now ... 94693 ASN active function link set 94693 Ready for ASN WX radar and the Radar is switched on nearly 30 seconds later (presumably when Prosim starts): 147000 Monitor IPC:861C (U16) = 50 ........range 50 mn 147000 Monitor IPC:8624 (U16) = 130 ........radar switched on with stabilised antennae option selected 7.5 seconds later: 154519 Monitor IPC:8624 (U16) = 2 ............radar switched off again! (Maybe the battery was off and Prosim just finished initialising) 16 seconds later, I assume you switched things on, and the WX Radar is switched on again: 170353 Monitor IPC:8624 (U16) = 130 This is what FSUIPC's monitor is telling us. But monitoring values does NOT change them, so you definitely did something differently! Pete
  23. Sorry, but it appears it is local to you after all. In my hurry to test and compare with FSX, I didn't quite get things the same in the tests. In fact, because the parameters were not correct in my P3D test, the WX Radar was turned off. When it is turned off you get a blank file of 1kb. I ran some more tests, and once things are definitely the same in both FSX and P3D, then the results are definitely the same -- a good Radar image. To check that your radar option has been turned on by Prosim, you need to examine some offsets (the WX radar is controlled by offsets, as listed in the back of the "ASN WX Radar facilities in FSUIPC4" document in your FSUIPC Documents subfolder. So, as well as the logging I suggested earlier, do this: In FSUIPC options, Logging tab, on the right-hand side add these two offsets to the 4-entry table: 861C type U16 (this is the range in nm) 8624 type U16 (the top bit here is the ON/OFF switch, the other bits are for options). Then check "normal Log" below, and ok out of there. Run like that with ASN running and Prosim presumably asking for weather radar for display, then show me the log. Pete
  24. Since my post above, I installed P3D3.2 on the same PC on which I use FSX-SE and ASN, and installed the P3D version of ASN, to test. With exactly the same weather being set in ASN, FSX-SE does generate the weather radar data and it is received regularly by FSUIPC. In P3D3.2 there's never any weather data provided. I checked with exactly the same settings in both FSX-SE and P3D3, so I think either ASN os broken in this area, or there's a P3D bug. I have no way of finding out which, so I have asked the folks at Hi-Fi (the makers of ASN) to check this out for us. I'll post any further information about this I may receive, but I can't do anything further myself at present. Pete P.S. For information, these were used in my tests: ASN version = P3D, 1.0.5921.17125 FSUIPC version = 4.949p P3D version = 3.2.3.16769
  25. 53 decimal = 35 hexadecimal. There are exactly the same value. The only difference is in how it is presented to you. In binary (which is how it is actually stored) it is 00110101. Key press and button programming is exactly the same. If you think the same thing is working in one and not in the other, please show me the FSUIPC4.INI file with both programmed. Pete
×
×
  • 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.