Pete Dowson

There are others. Sim-Avionics is cheaper I think, and they do list both the GoFlight MCP and the VRInsight MCP-Combi as supported. The parameter lines "RdFilter.n= ...", as used in the examples of using the Lua plug-ins I provide. Please see the document called "Lua PlugIns for VRInsight Devices" which is in the "FSUIPC Documents" folder in your FS modules folder. For more good help with VRInsight devices you should go to the support forum for them. They are new to me, I have only seen them and tried them in the last two or three weeks. Most of the testing was done for me by other users. You will find them very helpful. Regards Pete

It isn't FSUIPC4 which is crashing, as your details show: It is the weather DLL crashing, probably because of a corrupted WEATHER file (.wx) being loaded for your default flight. Those weather files are in a binary format and can crash FSX quite easily when corrupt. The only reason it happen with FSUIPC4 loaded is that as part of its service to applications FSUIPC4 is reading the weather data through SimConnect. Delete the .WX files in your "My Documents\Flight simulation X Files" and you should be okay. Regards Pete

if you want to stop just that and not use the VRI radios you can simply set read filters in FSUIPC for commands "NAV?" and ""COM?". But it should do anything with COM and NAV radios if you leave it selecting DME, ADF or Transponder. I would have thought it would be useful to leave it on the DME selection. I've not found it doing things except when turning its dials or pressing its buttons. I can't teach programming. Sorry. For Lua please look at the examples provided and perhaps go to the Lua website. There are also several books you can buy about Lua. I can help with specific questions on the Lua libraries in FSUIPC and how to set up the INI file parameters, but I'm afraid i cannot do anything more general. You ask specific questions, I answer them if I can. Regards Pete

What does "the rest doesn't" mean? I don't have any add-on aircraft but the A/P speed value is the same as in ALL of the default aircraft. If you are talking about PMDG or LevelD or other aircraft with their own separate autopilot, then you should know that there is no way I know for any external display to show the correct A/P values. Well, that's not QUITE true -- the Level D one does have an SDK and the value can be extracted. I believe there's a program by Nico Kaan which will map the values to fSUIPC offsets. Sorry, again I don't understand that part. Get WHAT working "as the speed"? Other aircraft, other values? Didn't you just say the speed wasn't working in anything other than the F1 MD80? Or didn't you really mean that? How can something which is "not speed" work as speed? What "jumps two places"? You mean 2 knots? As far as I know the VRInsight display is updated from the FS value. That's what happens here. Try it! Load the default 737, Change the heading bug in FS, the heading changes on the MCP-Combi. And it works the other way around. Please explain what it is you are trying to say. I am evidently not understanding you at all. Is this part related to the previous parts? You can do quite a lot with the displays in the VRInsight devices, but you cannot really change the format of the displays. They seem to be controlled by internal firmware, not from SerialFP2. You can't really do much with the radio displays unless you avoid using any of the knobs associated with them. Much of what happens is built into the device. You could try though. You can take as much control over the VRInsight devices as SerialFP2 has, using the COM library programming facilities in a Lua plug-in. just don't run SerialFP2 at all. Don't add any VRInsight sections to FSUIPC.INI. Instead load your own complete MCP Combi program written in Lua. It is not a small project, but certainly feasible. Maybe when it is working you will donate it as an example here for others to use? If you have problems with VRI devices have you tried talking with the folks on the VRI support forum? Regards Pete

Sorry, I don't understand what you are asking. The autopilot heading and altitude are already shown in the VRInsight MCP-Combi. There isn't enough room for the V/S value too unless you want to replace one of the others. You could use some Lua programming to enable the altitude display, say, to be toggled between altitude and V/S by pushing a button. Is that what you mean? Regards Pete

You simply download the FSUIPC4.ZIP file, take out the "Install FSUIPC4.EXE" program, and run it. It does the rest. All your settings and your registration will be preserved. It just updates the program and the documentation. The User Guide explains all about installing and uninstalling FSUIPC. It is covered in the first few pages. There is also a shorter Installing and Registering guide in the ZIP you download. Regards Pete

Then they either were not assigned, or not calibrated. The USB power management is normally on by default and has to be turned off individually in the Device Manager for each USB hub listed there. It's nothing to do with the easy control panel power stuff. Yes, but they can be assigned in both, which will give the conflicts you state, and also you can, in FSUIPC and FSX, assign more than one control to the same thing. This is what I was describing, not anything outside of FS at all. Yes, i know. but re-check. FS has a habit of redoing assignments automatically unless you actually disable the controllers themselves, not the assignments. It will especially do this if you ever unplug any of them and reconnect -- and the power management side might also be doing the same. None of the tutorials are mine, but contributed by users. If they have mistakes in them it would help to point them out, please, so they can be remedied. I'm too close to it all and wouldn't see them. You haven't supplied any actual data as I requested so I cannot help further at present, but if you want to try again I'd suggest, yes, deleting your INI file, get everything working in FSX, not in FSUIPC, and then going into FSUIPC just to calibrate those axes you want to be more "precise". Thousands of folks have used these facilities to great satisfaction in the past, and they have stood the test of time -- the calibration part having remained essentially unchanged since FS98 days. I'm sure you can manage, but please ask about things before getting het up and in a state of "total frustration". Except when I'm away I always strive to give really fast support, so there's really no excuse not to simply come here and ask. But please be specific. Regards Pete

I'm afraid this tells me nothing, as evidently this time something else already had the COM3 port to which your VRI device is connected. You need to ensure SerialFP2 is closed BEFORE running FS or there's no way FSUIPC can access the port. The log does show that FSX is taking a long time to load your initial flight: That's 106 seconds to load the flight. However, if there's a lot of photo textures to load that's not unexpected, especially if you've not defragmented your hard disk for a while. FSUIPC is not doing anything at all during that time -- it will be nearly all disk activity, probably with the progress bar going very slowly to 100% (the numbers on the left in the log are milliseconds. Divide by 1000 for seconds). After the COM3 port failed to open, the SerialFP2 program should have been loaded: but there's no sign except that 15 second gap. Are you sure that the apparent hang, which you get out of by hitting "ESCape", isn't an error message box saying that SerialFP2 either can't be loaded or has an error? If you are running FSX in full screen mode you might not see it. For testing try running FSX in Windowed mode, just in case. And check that you have this line right in your FSUIPC4.INI file: It seems odd that you have SerialFP2 on D:\Program Files (x86)\ when FSX is on G:\Program Files (x86)\ No, nothing in this log bears any relationship at all to what happened in the last and doesn't help locate THAT problem at all. Sorry. You'll need to reproduce the first case -- i.e. where COM3 is, in fact, available for use as it was then. Maybe you should restart Windows before doing any test, to make sure everything starts off the same way? I don't think hardware has anything to do with this. This last inability to open COM3 merely means either that the device is no longer on COM3 (which seems unlikley), or that the COM3 port was already owned by another program. If you aren't sure what is running before starting FSX, right-click in the task bar and select "Start Task Manager", then the "Processes" tab. Scroll down the list and make sure neither FSX.exe or SerialFP2.exe are listed there. If they are, terminate them ruthlessly. Regards Pete

How come you didn't see the links to the correct Support forum, so that your long message of woe had to be re-directed to the correct place? This support forum is noted in all my documents and there are links on the sales site and the download site, and even on the main front page of the options! But now you are here, please close FSX. find the FSX Modules folder, and paste into a message here the FSUIPC4.LOG and FSUIPC4.INI files. You can enclose them as "code" so they can be easily scolled and extracted as needed. That'll be a start, so I can at least see what it is you've been doing, or trying to do. Incidentally, why are you going direct to the extreme of wanting to do everything in FSUIPC? That makes life a bit more complicated unnecessarily. If all you wanted was a little more precision, as you say, why didn't you simply set everything up in FSX, as you say you can, then just calibrate in FSUIPC, via the one tab for this, and following the numbered steps to do so? You don't need to assign those things in FSUIPC -- such facilities are invaluable for advanced use in cockpit builder's hands, but certainly not at all necessary just for "more precision". The original use of FSUIPC for this never had any assignment facilities in any case. FSUIPC is like the Swiss Army Knife, a kit of many tools. Just choose what you need, don't try to use everything just because it is there. Sorry, it is getting late here, so it'll be tomorrow (Thursday) before I get to look at anything else now. [LATERIt's morning now] Other little comments on your 'report': Is that the recommendation when jumping from a very old version of FSUIPC to a new one? Or from someone saying do that to avoid confusing yourself? I ask this because I've striven veery hard to make sure all INI file details remain compatible throughout all updates and developments, to avoid the need ever to discard past settings. I am still using INI files which started life many years ago! You mean they are not saved and reloaded, or do not do what you expected in the first place? Please clarify. The INI file settings are only saved if you OK out of the options. Cancelling or ESCaping will reverteverything set in that entry to the way it was before you went to the options menu. Why? That seems a bit OTT. What on earth prompted you to do such a thing? Two things can do that. First is that the flight being used was saved with the thottle at max -- neither FS nor FSUIPC applies any axis value until it changes, so if you've not moved the throttle its current position isn't relevant. The other possibility is that the joystick driver is supplying spurious values initially. That sems to hapen more often with certain makes. If they are connected via USB the Windows Power Management may be putting them to sleep too -- switch poweer management off on all USB devices used in FS. However, since you say things are okay in FSX assignments I don't see how that could be a problem. That's almost 100% sure to be a double assignment -- having two devices assigned to the same control, or the one device assigned in two places. BTW please can you explain this: as these sorts of facilities haven't really changed much at all in 11 years. Additional little things have been added, but I'm pretty sure there can't be any "tutorials" out there which simply don't match any version of FSUIPC from many years. Regards Pete

No idea at present. Tell you what. don't worry about the email for now, just download this: http://fsuipc.simflight.com/beta/FSUIPC4601a.zip Copy the DLL into the FSX Modules folder, and rerun the test. Then show me the FSUIPC4.LOG again, please (even if it works by some chance, which is unlikely because i've only added a couple of Log lines into it -- for entry and exit from the routine doing those Open okay/fail attempts). It's only that 1=COM3,COM22 line which could be doing this, but how I've no idea, yet. To simply get on and have a fly, remove that line -- but not till after you run this test for me, please! I'll not get to see it till tomorrow (Thursday) now. Regards Pete

AhaNOW things become clearer. COM3 is opened okay, as also is COM22, But then something is continually trying to open COM3 again! Ouch. With nothing at all to show why it is looping trying to open COM3 again and again! How strange. Yes, all that is okay. sorry, I am at a loss at present. I cannot see how this can happen. There's no other user (out of at least the 10 in the Beta group, and I) who've had any such problem as this. I'll need to re-examine my code, see if I can find a clue as to what might be happening. I might need to supply you with a special test version of FSUIPC with extra logging. Is that okay? Could you send me an email please, so I can send a link to a test version by email? To petedowson@btconnect.com . I'll get onto this tomorrow (it is late here now) and get back to you. Regards Pete

You would need to purchase a Key for "WideFS7", which allows you to make WideServer work in FSUIPC4. You then register by re-running the FSUIPC4 Installer. You don't need to change the Clients. The WideClient program is the same no matter what version of FS you use on the Server. Regards Pete

Hi Philippe, My French is really useless these days (not really used my school french since leaving secondary school 50 years ago!) So I got Google to translate for me: You evidently have misunderstood what WideFS does. It is a package for extending the FSUIPC interface to other PCs on the network. This allows programs written to work with FSUIPC to be used on other PCs. It does NOT allow assorted bits of FS to run across a Network. There is nothing at all which will do that. FS's gauges are part of FS and need FS to run inside. There's no way of running them separately. The nearest you can get is to install FS on both PCs and use "WidevieW" to link them together. WidevieW is by Luciano Napolitano, not by me. Alternatively there are avionics packages providing their own instrumentation which can be run over a Network: Project Magenta, Sim-Avionics and Flight Deck Software are the main three payware products of this type. Regards Pete

Try first just filtering it off. What does it look like? "VVS+nnn" or similar? Are you using the M-Panel SetBaro plug-in I provided? If so you could add "VVS" as WrFilter.2=VVS? in the [VRInsight.MPanl] section of the FSUIPC INI file. See the example data in the Lua documentation. I'm sure there's a way around it, even if you have to program the Vertical Speed adjustment yourself in the Lua plug-in. I can help with that, but at present I am not sure I understand what is going wrong. Regards Pete

If your FSUIPC Key is purchased with a date LATER than today (as it would look if your PC's date is not set), then it looks like a bad key, a pirated illegal key. So FSUIPC won't work. It doesn't like to work for pirates! ;-) Pete

With the ports failing to open, FSUIPC is doing nothing regarding anything VRInsight-wise. What on Earth is "locking up" and what exactly do you mean by that? You haven't said either time -- surely not FS as it really isn't getting involved at all with no COM ports to handle. If COM3 and COM4 fail to open then they are not available to be opened. It is as simple as that. Either they don't exist, or something has them open already. Please show the WHOLE of the FSUIPC log files, not extracts -- close FS down first if it isn't "locked up". Regards Pete

I don't think FSUIPC registration keys arrive in emails these days. You just get them by opening your account in SimMarket. You can do that anytime. There's really no point in sending me stuff, i don't have the data except in exceptional circumstances. SimMarket handles it all. Please do backup your FSUIPC.KEY file next time, as advised in the documentation. Regards Pete

Nothing to activate. Just correct the system date. Regards Pete

I don't know. Are they being invoked? You can use FSUIPC's Key and Button logging to check exactly what is going on -- it logs keypresses arriving in FS no matter who sends them. If you run FSX in Windowed mode (just whilst testing) and enable FSUIPC4's console log, you can see the stuff being logged in real time. That should soon help work it out. Regards Pete

Sorry, I don't have any Airbus add-ons to test with. I doubt that the M-Panel itself is doing anything wrong, it is most likely the SerialFP2 programming for add-on panels, using keystrokes probably, which is getting confused by what you are doing. If you've re-programmed M-Panel actions in FSUIPC they should not reach Serial FP2, so then you would be okay assigning your own actions and programming different actions for different settings (via conditional button actions). But don't forget that the dial on the M-Panel sends different codes, and therefore does different things with SerialFP2, depending on your selection there, on that panel. The logging in FSUIPC should help you untangle what you are doing. Pete

FSUIPC is not at all dependent upon any particular version of any of that. Are you running FS at a different privilege level to your add-on applications? If you run FS "as administrator" you must run all those "as administrator" too. That must be something else you have wrong. FSUIPC cannot get between the keyboard and any add-on plane or gauges. What does the FSUIPC.LOG file say (close FS first). Paste it here. Pete what can i do? thanks miguel

That's a PROCESS property, not a DLL one. DLLs run inside a process. The EXE owns it. Pete

There MUST be a folder called "modules" because most of FS9 lives there! In that folder, if you have installed FSUIPC, there must be, at minimum: FSUIPC.DLL FSUIPC Install.Log and (for version 3.98 or later), a subfolder "FSUIPC Documents". Be sure you HAVE installed FSUIPC version 3.98, not any earlier version! If you are using an earlier version, it is not supported in any case. Assuming that it okay, and if you've ever run FS9 since FSUIPC was installed there will also be: FSUIPC.INI FSUIPC.LOG If those are not there then either you have not run FS9 since installing FSUIPC, or you are looking in the wrong place. Check two things: 1. You have only one FS9 installation, and you are looking in the right one (it has happened several times before that folks have run a different install to the one they installed into!") 2. You are looking at the REAL "modules" folder. If you let FS9 install into Program Files under Vista or Win7 it might not be the real folder. Run Windows Explorer by right-clicking its Icon and selecting "Run as administrator" to make sure you see the correct folder. Did you check your system date? You did not say. Pete

Check the Windows system date on your PC. Is that before your purchase date of the FSUIPC or WideFS keys? If so it makes the keys look invalid, as they cannot be issued with a future date! If that doesn't explain it, please close FS and show me the FSUIPC.LOG file from the FS modules folder. Pete

Okay. The updates are now available in the Updates and other Goodies Announcement: 3.981 and 4.601. Regards Pete