Pete Dowson

I've never seen that. I certainly don't understand it. I can't see how it has any relation to the VRI provisions. Hmm. curiouser and curiouser ... Can you test with just 1=COM3, which is how you would do it if you programmed only in FSUIPC, without SerialFP2? Well, without the two serial ports used in FSUIPC, neither are involved in any of the serial port activities being conducted in the FS process, so really that is an incorrect conclusion. It will be the USE of these things that cause a problem, not whether they are available or not. Here is the log, but for me there is no unusual thing... ... 97204 *** FSUIPC log file being closed Average frame rate for running time of 16 secs = 38.0 fps Memory managed: 125 Allocs, 124 Freed ********* FSUIPC Log file closed *********** Yes, the last part shows that FSUIPC has cloosed everything and is not there any more. Something is causing the problem and it must be something to do with serial ports. Remind me what version of Windows you are using please. And if your serial ports are USB adapters, what adapter driver -- if FTDI, is it the latest version? Regards Pete

Why? Do the encoders send on/off pulses? If so, how fast? If you want a faster scan rate in FSUIPC you'd need to adjust its polling interval -- "PollInterval" in the relevant [buttons] sections of the INI file. The default is 25 (mSecs) which is 40 polls per second. Here's the relevant paragraph quoted from the FSUIPC Advanced User's guide: Of course, the Windows keypress queue is also a bottleneck. When you use the SHFT+CTRL+F1 press on the keyboard and hold the key down, does it go fast enough for your liking? I don't think you will get it a lot faster -- maybe a little. Pete

Hmmm. Shame. It seems worse on your system than mine. Here mostly everything closes fine, but sometimes it needs the FSUIPC thread I mentioned to kill the process after more seconds. I rarely get FSX simply not terminating -- at least not on the system on which my test VRI devices are connected. I do get FSX sometimes not terminating correctly on my main FSX PC -- no VRI devices. It is to do with SimConnect and one of the add-ons using it. I'm not sure which -- could be ASE, UT2, AddOnManager, FollowMe or any of a number. I guess I should try a process of elimination, but generally I know when it has not terminated because "FR Limiter's" display doesn't close, so it isn't really a problem. See if it is related to some combination of VRI serial use and one or more other Add-Ons. There are so many threads going on I suspect one isn't reacting correctly. I've not got time to investigate further here for a week or so. But I'll have another look then. It is on the FSUIPC side. As soon as FSUIPC is told that FSX is closing down it kills all Lua threads, closes all open ports and frees all resources. Does your FSUIPC log show the log closing? If not, then you have an unusual case -- FSX is hanging before FSUIPC has closed. There's one option I was going to try, and that it operating the SerialFP2 "kill" before closing my end of the COM link. But I think you said closing SerialFP2 manually before closing FSX didn't help -- or am I mistaken and you've not tested this? If it worked i could change the order in FSUIPC. Regards Pete

You've not looked far enough then. ;-) Offset 0366 is the "on ground" flag -- monitor that, then, when on ground becomes true, offset 030C gives the touchdown V/S value. Pete

Won't this SIOC thingy send button presses? Then it would be easy -- just assign to those controls with those parameters. At present writing to offset 341E merely uses HYDRAULIC_SWITCH_TOGGLE with a parameter of 0. I didn't realise it took a parameter to operate 4 switches. However, writing 1 to 341E when it currently contains 0, or vice versa, should operate the first switch, as it will send the same value. Possibly the panel has been written in such a way that toggling the switch sends the control to FS, but changing the simulated switch in FS isn't reflected in the graphical switch position. That would be a shortcoming in the programming of the panel -- not a lot you can do about that, unless it is using a Local Variable which you can access (see "L:Vars" in the dox). See if using 341E does actually change the hydraulic operation in FS. If so, then it is only a graphic problem. If it works let me know and I'll possibly extend 341E to use 4 bits, one for each hydraulic switch. Regards Pete

It will only not open if it doesn't exist, or is already opened by another program. Are you using a USB-Serial port adapter? If so, have you checked that it is still COM3? Pete

Please note that 4.57 is no longer supported. You need to update to 4.60. WideFS doesn't use or care about filesharing. If it is connecting okay and staying connected that's all it needs to do. Sounds like you need to provide filesharing for IYP at least. I think FS Commander needs some filesharing too. I've no idea what that "1001:5" refers to. Where do you see that? Is that an IYP message? IYP support is quite good, have you tried them? I thought you installed FSX on as separate drive to the operating system? Why the "Program Files (x86)" part? My FSX is in "E:\FSX", and the whole folder is shared. Hmmm. Sounds like some sort of access permissions limitation. I'm really not the best person to advise on filesharing in Windows. I have had such problems in the past, and still do occasionally -- folders accessible from 6 of 7 PCs but not from the 7th. Sometimes a re-boot fixes it. I think it gets messed up by automatic Windows updates, and I've now disabled those. Sorry, you need someone who knows more than I do about Network filesharing. I can help if you have WideFS or FSUIPC problems, but Windows is far more complex than my programs. :-( Regards Pete

You'd need to monitor the airspeed, of course. The FSUIPC part of the feedback is maintaining the pitch you request. Obviously you wouldn't get the same tight feedback loop, but I think 10-20 mSecs which is easily attained should be fine. There are some external autopilots doing good jobs even over a network (viz Project Magenta, Sim-Avionics and Flight Deck Software). Regards Pete

Which program runs okay. the F-18 or FSUIPC? When does what tell you you don't have FSUIPC 4.60? Pete

And I still have no information to work with. Pete

If a special check thread in FSUIPC4 is still running some seconds after FSX says it is closing, that thread should focibly close FSX. But that might be 10-20 seconds later. Is this with SerialFP2 running? I found that with SerialFP2 still connected FSX would not close tidily. Somehow it has to do with that COM pairing arrangement. Trying to debug it is almost impossible, as FSUIPC isn't there any more. See if getting FSUIPC to "KILL" SerialFP2 helps. It's an option in the Run parameters. Regards Pete

I don't know. If you read the documentation I provide it says that offset is the APU starter, as a percentage of something which on one has provided feedback for as yet. However, it should start and stop the APU. Doesn't it? To find out if the APU is running I think you need to read something like the APU RPM. Pete

If it is only temporary, and you remove your KEY file when finished, you need not bother. Otherwise I suggest you buy one new registration in the name of the facility. Provided the 4 PCs are in one place and used together I think that would be fine. Regards Pete

Sounds like the bug in SimConnect's "trust" check is being invoked. We'll probably need to change the order in which your DLL's are being loaded via the DLL.XML file. Alternatively you could temporarily rename your existing DLL.XML file, then re-run the FSUIPC installer. Run FSX and get FSUIPC 'trusted'. Then you can close FSX and restore your previous DLL.XML file. You'll find DLL.XML in this folder: C:\Documents and Settings\Gary\Application Data\Microsoft\FSX\ Regards Pete

The installer worked fine, as you said. Is there an FSUIPC4.LOG file in the FSX Modules folder? If so, I need to see that. If not, I need to see your DLL.XML file which is here: C:\Users\Scotchegg\AppData\Roaming\Microsoft\FSX\ Pete

Nothing changed with FSUIPC version 4.607? That really cannot be. Something MUST have changed! The results cannot possibly be as they were before! Please show me the log, but first double check that you did install 4.607. Pete

I can't tell for sure without a complete FSUIPC log, but the usual reason is either an invalid registration key, or an incorrect system date which makes the key look invalid because it was purchased AFTER "today's" date. If you aren't even registered then possibly the DLL is corrupted of has been tampered with. A log would show if this is the case. Pete

Looking at the offset documentation, I think this offset was only added as a doors open indicator, not a control. That's how it reads to me, and checking the code that is how it is implemented, at least in FSUIPC3. I extended it in FSUIPC4 when adding the other doors -- more useful really. The FS2004 version can't even detect the other doors. The only way you can do it programmatically in FS9 is by sending the Toggle Aircraft Exit control via offset 3110. You should check the status in 3367 first, of course, because there is only the toggling control. Pete

You have to invoke the macro by name, using the facilities at offset 0D70. Regards Pete

Certainly lots of folks do so. Is there a problem assigning THROTTLE DECR to the Joystick 169 buttons? I don't understand. Really? This is in FSUIPC3? I'll check that. But it really shouldn't be a problem. I only added to parameter because one person was confused about getting two joystick numbers for the same buttons. But it does no harm. [LATER] I've checked, and there's no incidence of "PollGFTQ" anywhere in FSUIPC3, only "PollGFTQ6" which is both Read and Written. Regards Pete

No, sorry. Yes, but couldn't you do that by using the pitch control feedback facility. That works quite well. Pete

Does CTRL+S give the top-down view by default? I never knew that. If FS sees the Ctrl key and FSUIPC sees the CTRL key, it means the CTRL key appears to be pressed. I can only think that FS is somehow not allowing the KEYUP for the Ctrl key to get passed on when it's busy doing the top-down graphic. I've not seen anything similar. Anyway, where are you assigning this? If you are using FSUIPC why not assign to the control itself in the first place -- avoiding the keyboard altogether? Really there's never any point assigning buttons to keypresses if all those are doing are converting back to assigned controls inside FS. In FSX Ctrl+S is assigned to "VIEW PREVIOUS TOGGLE" by default. In FS9 it's "VIEW TYPE". Regards Pete

Sorry, I'm not sure what you mean by that. Are you using FSUIPC's Profiles facility for your settings, or possibly the Aircraft Specific settings? If so, possibly you've set them for a very specific aircraft, like "... Paint 1" and not for any others. There are easy ways to make things applicable to any group of aircraft, as you wish, using either Profiles (the easiest) or short aircraft names. FSUIPC doesn't care about any of that. But if you assigned things to one very specific aircraft they won't apply automatically to other similar aircraft unless you actually do something to make that so. No. Saved flights don't matter to FSUIPC. Only aircraft names. If you tell me what you've done I can tell you how to proceed. Or else, please check the Appendix to the User Guide which deals with the "ShortAircraftNameOk" option. Alternatively take a look at the Chapter on Profiles. FSUIPC won't lose or change settings. It must be down to your aircraft names. Regards Pete

For commercial use we just need to come to some financial agreement. You don't need to force your users to buy a user Registration. Write to me at petedowson@btconnect.com. Regards Pete