Pete Dowson

No settings. Just assign the hat in the Axes assignments tab in FSUIPC. It's exactly the same assignment that FSX itself would use. Pete

Also try using TrafficLook, which is the test program I made for the FSUIPC AI traiffic data readouts. Pete

It isn't a standard joystick device and I don't support Saitak devices. I think there's a program called SPAD which you can use. Sorry, I don't know where it is, you'll need to Google. I also don't support old versions of FSUIPC. Regards Pete

Assign the hat as Pan View in the axis assiggnments, not as a set of buttons!!! That's an option made for other uses! Pete

Sorry, Stackhash problems are not related to anything I do. Try reducing settings, especially those which tend to use memory like the texture size and the LOD_RADIUS. Also a friend of mine and myself both got stackhash crashes with recent ASUS Z87 motherboards -- since switching to Gigabyte I've not seen one. Pete

Doesn't look like you would have got any crash in the short period you ran FS -- ony 4 minutes? Did you always get the crash in the first 4 minutes? Anyway, with no crash averted there's no logging of the original possibly reason for it, so the log tells me nothing execpt you only flew for 4 minutes. Pete

You need to run the Installer in order to set things up so that FSUIPC is actually loaded. What are you afraid of? The installer simply sets things for FSUIPC to run. It changes nothing else. Yes, but do not replace a newer FSUIPC4.DLL with an older one. Best to just restore all the other files, mainly your FSUIPC4.INI file and KEY file ,and any bits of Linda etc. Pete

Please refer to the documentation of this parameter which already states this. Pete

Sorry, I've not answered because I was hoping someone else might know. I certainly don't know of any way at all. Once folks see I've answered they tend not to, which is why I held off. Pete

Okay. It was a long shot. I've just tested it in my cockpt and have no problem. No FSUIPC log of events to show what was sent? That was the point, really. . Unless the write of 01 to 3367 changes its previous value, it won't do anything. You don't seem to be monitoring 3367 as I asked, nor do you show any logs, so I'm really none the wiser. Those are only from the [General] section. The Monitor part has its own section. Sorry, I've no idea. Maybe we need to see identical logs etc from 4.920 ad 4.927f to compare them -- FSUIPC logging/monitoring and SimConnect logs. If there's a difference it should show up. The fact that it works perfectly fine here suggests there's some interaction with something different on your system. Is "NewInterceptTextMenu=No" set in the [General] section of FSUIPC4.INI? If not, try that. So far I've insufficient information. Aren't you using the Monitor as requested? Also the actual logs would be more useful to look at than your extracts -- what are they from? Yes, and that proves things were correctly set: > 9.82378 [136, 1887]MapClientEventToSimEvent:EventID=66389, EventName="TOGGLE_AIRCRAFT_EXIT" That's where FSUIPC's definition of its event #66389 is assigned to TOGGLE AIRCRAFT EXIT, and > 174.83120 [136, 2463]TransmitClientEvent:ObjectID=0, EventID=66389, dwData=1, GroupID=3, Flags=0 < 174.83121 [136] >>>>> EXCEPTION=3, SendID=2463, Index=4 <<<<< that's where it said the request was invalid. Why it does that I'm afraid I've no idea. Note that the request was for Exit 1 (dwData = 1). "Index=4" refers possibly to that parameter rather than the control number (ID) itself. Does Shift+E+1 work? (0 is a default if no numbers are given). Pete

Looks like it could be a corruption someplace in your installation. "TOGGLE_AIRCRAFT_EXIT" is the correct control. It takes a parameter, 1, 2, 3 or 4 defining which doors to toggle. A parameter of 0 is the same as 1 in this case. Try using the keyboard, with the logging still exabled. I think door toggling is Shift+E isn't it? (Check first), then the number you press after becomes the parameter. If that works then FS is okay but there's possibly something up with SimConnect. It might be helpful to get a SimConnect log -- there's a FAQ about that the FAQ subforum. It'll be big though -- maybe ZIP it and send to petedowson@btconnect.com. But first try the latest FSUIPC test version, FSUIPC4927f.zip which may just possibly make a difference as it should fix a small problem related to interception of SimConnect Text requests. Pete

That doesn't necessarily follow. The options for power management are always there, in all versions of Windows. Go to the Windows device manager and look through all the properties of all the USB hub and other devices listed. There will be power management options on some of them, for sure, and Windows defaults them on. There is never any need to click on anything. With axes only the profile specific settings are ever loaded. With buttons and keys both the generic settings AND the specific settings are loaded. That is the only reason you don't see that checkbox ticked. With buttons and keys the specific settings simply override any similar settings in the generic sections. That isn't done with axes. It is this difference which is confusing you (but it is expalined in the user guide). So all you are teally doing is causing the re-scanning of the joystickk devices. No. There is no point. There is nothing in there which will affect this. Regards Pete

The doors work fine here, with 4.927a or 4.927b (the current version), and there's been no change at all anywhere near this area. The doors operated through 3367 use regular FSX controls -- please enable event logging and see if the toggle controls are being used. You could monitor 3367 as type U8 on the right-hand side of the Logging tab to check too. Show me the log (paste here). Pete

Could you add the INI lines I mentioned above in my revised post above and show me the resulting log. I think I know what is happening now but I need confirmation before I solidify the code. Thanks! Pete

Strange that it would need that. That parameter is only related to releasing the parking brake with toe brake pressure. Pete

It's fine. Thank you! Pete

AI Smooth doesn't use SimConnect, it's an FSUIPC application and isn't involved in this at all. It was most likely the Wilco installer. Regards Pete

It reads everything in P3D that it does in FSX. The rest depends on P3D. Pete

Trry Saitek support. This is the FSUIPC support forum. I don't support Saitek. Sorry. Pete

It needs to be there for ASN to work correctly. Without it ASN canot perform many of its operations, including smoothing. I've been checking the FSUIPC code exactly where the FSUIPC crashes occur, and I know it isn't anything to do with ASN. There's another SimConnect application which is making some calls which are causing FSUIPC to have a headache. I know how to work-around it but I want a proper solution. Have you added anything else recently? Another installer probably lost the as_connect entry in the DLL.XML and may be responsible for FSUIPC's confusion too. Yes, it will be. It sounds like you have Windows hiding filenames from you -- see the notes in the FSUIPC documentation about that, it's a folder option in Explorer. You should be able to see the correct filenames, like FSUIPC4.DLL (the program) FSUIPC4.INI (the configuration settings) FSUIPC4.LOG (the run time log file) FSUIPC4 Install.LOG (the log showing the installation actions) FSUIPC4.KEY (registration details) With Windows left to hide the correct filenames all you see is its classification according to what program it thinks you should use with it. Text files like Logs and INI and CFG files, which can be opened with Notepad will say Text Files or similar, but that might change if you use some other program for looking at these. Best to turn that annoying option off. In earlier versions of Windows it defaulted off, which was much more sensible.

Why? Reinstalling FSUIPC does nothing, unless possibly updating it if you download a later version. Replacing a DLL with exactly the same DLL does nothing useful. I've not had a problem with the FSX 737 in P3Dv2. I use Project Magenta and other cockpit software, and they manage to provide ample electrical power from APU or ground power using FSUIPC's facilities to control the battery voltage -- basically doing the same as the facility in the Miscellaneous tab in FSUIPC. I'm sure there are many folks using ported aircrft with no problems. However, I admit I've not used P3D very much. My FSX setup and performance is so good these days I'm not jumpng ship yet. If FSUIPC's battery management doesn't work in a specific aircraft it must surely be because the code in the aircraft implementation is defeating it? Are you saying the facility works in all other aircraft except he A300, or in all aircraft ported from FSX, or in all aircraft including the ones supplied with P3D? I'm a little confused by what you are saying now. Try monitoring offset 2834 as a FLT64 in the Monitoring facilities in FSUIPC's logging tab. That's where the battery voltage is stored, and it is that value which is kept up by the FSUIPC facility (and used by cockpit software for APU and ground power). Regards Pete

Please download FSUIPC 4.927f and try it for me. I'm anxious to get to the bottom of this because I cannot reproduce it here. Please add these lines to the [General] section of the FSUIPC.INI file: Debug=Please TestOptions=x8000 This version may not actually crash, but it may well get the same error -- I've tried to trap the error before the crash occurs so I can log the details instead. So after using 4.927f whether you get a crash or not, please paste the log here. If no crash, by all means carry on using it but show me the log after each session for a while, please. If the log is too big to paste here, ZIP it an email to petedowson@btconnect.com. Once I know exactly why it is happening I'll fix it properly -- then you'd just need to remove those two added INI lines. Thanks, Pete

Please download FSUIPC 4.927f and try it for me. I'm anxious to get to the bottom of this because I cannot reproduce it here. Please add these lines to the [General] section of the FSUIPC.INI file: Debug=Please TestOptions=x8000 This version may not actually crash, but it may well get the same error -- I've tried to trap the error before the crash occurs so I can log the details instead. So after using 4.927f whether you get a crash or not, please paste the log here. If no crash, by all means carry on using it but show me the log after each session for a while, please. If the log is too big to paste here, ZIP it an email to petedowson@btconnect.com. Once I know exactly why it is happening I'll fix it properly -- then you'd just need to remove those two added INI lines. Thanks, Pete

Please download FSUIPC 4.927f and try it for me. I'm anxious to get to the bottom of this because I cannot reproduce it here. Please add these lines to the [General] section of the FSUIPC.INI file: Debug=Please TestOptions=x8000 This version may not actually crash, but it may well get the same error -- I've tried to trap the error before the crash occurs so I can log the details instead. So after using 4.927f whether you get a crash or not, please paste the log here. If no crash, by all means carry on using it but show me the log after each session for a while, please. If the log is too big to paste here, ZIP it an email to petedowson@btconnect.com. Once I know exactly why it is happening I'll fix it properly -- then you'd just need to remove those two added INI lines. Thanks, Pete

I don't know "Controls=0". Assuming you mean Joysticks=1 then I don't know. I've had that happen to me, but not often. I think it's an FSX bug. Pete