Pete Dowson

It must be the same account for which you install FSX. If you are the sole user of the PC you really would be best off just using the PC as the sole user. You will have admin rights in any case when you want, using "Run as Admin". Installers have admin rights in any case. I think the user actually called "Administrator" is special in some odd way. I can't even access mine. I just installed Win 7 with my name, Pete, and use that 100% of the time. I don't know why you are using "Administrator". Pete

You are in the wrong place. RC has its own support forum. I have no idea what key combinations you have for other programs. I use a lot of programs and I have RC commands assigned to Ctrl+Shift+whatever they have by default. So, for instance, "1" becomes ctrl+Shift+1. I assign buttons to them all in any case so it doesn't matter if they are difficult to finger on the keyboard. The "SuperATC" free addon to convert spoken commands to RC commands also assumes you do as I do. And the payware one, "ItsYourPlane" which i use. Regards Pete

Yes, you said that before, a few months or so ago (or so it seems!). But for which user name? It should be in C:\Users\Administrator\AppData\Roaming\microsoft\FSX which is in the Appdata for a user called "Administrator", which is not the user name normal to most if any users, yet it appears to be the one you are using when installing FSUIPC4! So far I'm afraid you are not making a lot of sense nor reading what I'm saying. Sorry, but it is very difficult to help in this slow trickling way, with me squeezing information out a tiny bit at a time. Can you not open up a bit, read more carefully, answer questions more fully? Please? Regards Pete

But for which user name? It should be in C:\Users\Administrator\AppData\Roaming\microsoft\FSX which is in the Appdata for a user called "Administrator", which is not the user name normal to most if any users, yet it appears to be the one you are using when installing FSUIPC4! So far I'm afraid you are not making a lot of sense nor reading what I'm saying. Sorry, but it is very difficult to help in this slow trickling way, with me squeezing information out a tiny bit at a time. Can you not open up a bit, read more carefully, answer questions more fully? Please? Regards Pete

Maybe in your earlier test your call "FSConnection.ReadAndProcess" failed -- perhaps you asked before the interface was ready. Doesn't it return a result saying whether it was okay or not? In the C/C++ direct interface I provided you get a TRUE or FALSE result and an error number stored in a "Result" variable. You shouldn't use data if there was an error. Regards Pete

Not the layout, it's just bigger, so there's probably more space. It is now set to use "Shell Fonts" (whatever they might be), because it seems on some Windows systems the normal fonts I was using can make the inside parts (the Tabbed sections) too big for the outer part (the main dialogue with the OK button on it). When that happens folks can't see all the optionstook a lot of research and trial and error to find this solution! Regards Pete

0xcccccccc is the default initialisation most Microsoft compilers do for variable initialisation, so it really indicates that whatever your code is supposed to do, it certainly isn't setting any value into that variable. I don't know that way of interfacing to FSUIPC. If it is via the Client DLL for .NET interface provided by Paul Henty, then you might be better posting in the sticky thread above which Mr. Henty checks. Otherwise post again but with the reference to the DLL clear in the title. For seeing what happens at the FSUIPC end, which is where I can help, please use the FSUIPC Logging facilities. You will find the IPC read and write logging very useful. Regards Pete

You must not put the GFDev.dll module which FSUIPC uses to interface to GF modules into the FS9 Modules folder. With FSX it does not matter, but with FS9 it would cause FS to crash as it will try to load it like an FS module. If you've installed the GoFlight software correctly then you should not need to worry about where GFDev.dll is, as FSUIPC can find it via the Registry entry for the GFConfig.EXE program installation. GFDev.dll should be in the same folder. Regards Pete

There is no reason for any of them to be different now, in 3.964, compared to 3.90. Except possibly ADF2 which sounds like doesn't exist in the aircraft you are using. Check the Aircraft.CFG file for that. Merely having a gauge for it doesn't make it work. with 3.964 there is no difference in button processing at all in flight mode. The only timeout check is in the assignments, and for recognised joysticks that timeout is now defaulted to 80 mSecs. Once the buttons are assigned there is no change. Please enable Button logging in the FSUIPC Logging tab, operate COM1, COM2 and ADF, stop the session when you see them not working, and show me the log (or at least the last large section), please. Regards Pete

There is no information on Airbus "detentes" because there was never any real Fly-by-Wire thrust detentes in FS. Presumably you are using an add-on aircraft which simulates an Airbus properly, in which case you'll first need to work out how to use it from their documentation. If it needs different controls or keypresses sent to it for the different thrust modes, this can be done, but it isn't anything to do with calibration. It is an entirely different and more advanced subject. Calibration of throttles is merely the setting of end points, and idle zone if reverse is being included on the same axis. The currently supported version of FSUIPC for FS2004 is 3.96 and the User Guide for that is dated 10th January 2010, so you are out of date in any case. The numbered steps for axis calibration are on pages 49-50 in that edition, so they must be close in the one you have. There's also a separate guide written in a different style by "SIM SAMURAI" which you may prefer. It was included by permission in the recent release. You would be best calibrating your axes in Windows game controllers first and making sure they work well in FS before even looking at FSUIPC. Then when you calibrate in FSUIPC do it with default aircraft, not with any add-on which might be utilising the standard FS axes in weird and non-standard ways. Once you have all that sorted out, then you can start to think about more advanced stuff liker the thrust modes used in a well modelled Airbus. The numbers must increase from left to right. You cannot have a minimum value which is greater than a centre value or a centre value greater than a maximum value. The words "minimum" and "maximum" should be a strong clue, though "Reverse" is substituted for "Minimum" as an extra guide on the throttles page. Full reverse is certainly the minimum (most negative) value. There are no detentes in throttle calibration in FSUIPC, excepting the idle position when including reverse. The step by step approach to calibrating axis is laid out clear and easy in the User Guide. Please look again. If you cannot find it I don't understand as it is there in black and white. Many thousands of users before you have found them and used them, and the instructions have been helpful to all over a period of 11 years or so, albeit with some improvements derived from constructive user feedback -- certainly not from unhelpful attacks. Please make sure you are using supported versions of my software before asking for support. It does work better that way. There's an announcement at the head of this Forum which tells you what is current. There's also an interim update released since 3.96 available in the Updates and Other Goodies announcement. For assistance on Airbus thrust mode assignments, by all means come back for specific help on that when you've got ordinary calibration done. I don't know much about the Airbus, but if you ask specific questions and can give specific answers easily and willingly. Or, if you really find my style so obscure, possibly you might find others who've licked it over on http://www.mycockpit.org/forums . Regards Pete

GPSout makes FS emulate a GPS feeding information to a moving map, to show position, altitude and speed, those elements allowed by the relevant NMEA 0183 protocol sentences and the only useful information for that purpose. Quite often it is the moving map program which contains the plan which it has generated for FS in the first place -- for instance, as with Jeppesen's FliteStar (for which the package was originally written). The current trend to use a real GPS as the moving map program for FS seems odd to me, but if folks enjoy that it is fine. However, if you want your flight plan in your real GPS you'd need to feed it in there just as you do in FS. No, not by any means I know. If the GPS was capable of outputting the needed information at the rate needed for good controlled flight, like an autopilot, then I expect you could write an interface program to do that, but I'd be doubtful that it could. Do you use the GPS yourself to control a real aircraft? Or is it simply providing the information for you to set the autopilot or for you to hand fly? Regards Pete

Yes, of course. I understand that. It's just that I come from more of an engineering background, and when I managed departments of up to 30 or 40 programmers we were working on development and diagnostic test suites for mainframes and minicomputers, as well as simulators to test them on. I started when there were still computers in our Bureau using valves and mercury delay line memories! ;-) The "bottom up", "don't trust software if you don't know what it is doing" mentality became rather engrained! I'm not likely to change now, at 66! ;-) Regards Pete

Sounds like the joysticks are timing out. There's a new check in 4.57 to stop hangs. But it turned out to be too tight for some folks' systems with apparently occasionally slow responding joysticks. Please see the Updates and Other Goodies Announcement above, where this is one of the problems listed as fixed in the interim updates, along with others. The first fix was available there within a couple of days of 4.57's release. It would always be worth your while looking at such Announcements from time to time, especially if you have any problems. Regards Pete

A generous offer! If it is truly not a difficulty for you, then I would be interested in giving it a try. After having given this some thought, I would optimally want at least the six primary pieces of aircraft state data to be sync'd up with the time stamp (ie, lat/lon/alt/roll/pitch/yaw). Hopefully they would all arrive at the same time. I wouldn't want to have to maintain six different timer copies. If they all change together then I should get them in one package so I'll just copy the time over then. If not then maybe I can include a set of flags to show which ones changed on that timestamp, though I'm not sure that'll do you any good if you don't catch all of the changes. I think really you should assume that those that look the same didn't change. That should work. I'll let you know. Too late for now. I'll look at it over the weekend. [LATER] Okay, I was curious, so I implemented it, including the flags to show what was received. And ... it is disappointing. The granularity of the FS elapsed time is only 1/18th of a second, so it only just keeps up with an FS frame rate of 18 or less. Therefore it only changes at that rate at most no matter how often the LLAPBH values change. In fact you get exactly the same value as you get in offset 04A8 in any case. At least I have proved that all 6 values, LLAPBH, are updated at the same time if they have changed. so having one timer is not a problem. So, I am providing the Windows "tickcount" elapsed time instead. This is a bit better, but I don't know if it'll be good enough without smoothing or interpolation. The trouble you've then got to sort out is that it will show real elapsed time, not FS time -- FS can run faster or slower, as you know, and will pause on demand and stop when in menus, etc. You'd have to correct the time differences you measure in the new offset based on the FS differences you get from 04A8. There's nothing else i can think of which will help I'm afraid. Try the update in any case. It will be version 4.576 in the Updates and Other Goodies Announcement at the top of the Forum, tomorrow some time. I will include Notes on the changes in the Announcement -- scroll down a bit. Regards Pete

Strange. At least it's simconnect should have installed okay. What does the FSUIPC log say now? Yes, it will restore the links. I think that appears after you uninstall SP2. Or else if you click on the "show updates" option. Pete

This is the problem: Whilst you appear to have the SP1 update for FSX installed, the SimConnect module is still the base version, 60905. I don't know how such a mess arises, but it causes a clash in FSX which therefore won't allow anything to connect correctly. I suspect the only full solution would be a complete uninstall and reinstall of both SP1 and FSX, but best first to try applying the free SP2 update to FSX, which I'd highly recommend in any case as it fixes lots of bugs and is more efficient. Regards Pete

Okay. Apart from the fact that you've not yet installed the important SP2 update to FSX (or Acceleration, which includes it), the install was fine. So, now the question is whether FSUIPC4 is being loaded or not. Please look in the FSX\Modules folder, and see if there's an FSUIPC4 log file. If so show it please. If not then then it is either a SimConnect problem, or the DLL.XML file which FSUIPC4's installer updated is in error in some way. If there's no FSUIPC4 log file, please find and show the DLL.XML file which will be here: C:\Users\Jon\AppData\Roaming\Microsoft\FSX I'd recommend you get FSX up to date, whatever else we might find. Regards Pete

Did you run FSX first, to make sure it was working okay? FSUIPC4 shouldn't be installed until you've run FSX for the first time, as it says in the documentation. Show me the FSUIPC4 Install log. It will be in the FSX Modules folder. Incidentally, in FSX it is in the "Add-Ons" menu, not "Modules". Regards Pete

It really is not hard. I'm sure you are over-emphasing your incompetence. The WideClient.log file will be in the same folder as WideClient, so look wherever you put that. The WideServer and FSUIPC logs are in the FS Modules folder, the same place as FSUIPC. These things aren't spread around or hidden. To put text into a message here you simply load it into a text editor, like NotePad (which comes free with your Windows), and cut or copy, then paste it into your message here. If you don't know how to cut and paste I must refer you to Windows help in general. All this is much easier than learning to fly an aircraft, and as you appear to be a PM user which is all fairly advanced stuff, I cannot believe you don't understand anything as easy as files, folders and editing! :roll: Regards Pete

Ideally your LED should reflect the state of the LevelD battery switch, not your GF switch. I'm sure there's an interface for the LevelD aircraft produced by one Niko Kaan (http://www.lekseecon.nl ). He uses the details supplied by LevelD in their SDK. Can you not find the correct offset from that, or even use Nico's driver? Well, if you know the LevelD offset it would obviously be rather easier simply to change your GFDisplay parameters. Regards Pete

I don't think i know how to do that. Have you tried the "white messages" option? The window is not mine but FS's. I merely call a procedure in FS and I don't know all of the parameters it uses. If the white messages option doesn't change it I might be able to make it do so. But if you mean mixed colours in the one display, the answer is no. There is no way to do that. Pete

As documented, see the ButtonRepeat parameter in the Advanced Users guide. It is set to speed up when held long enough. You can adjust the base rate and the delay. But if you want to only change this for trim you might be better programming the Trim differently in the first place.That's actually the very subject of the Offset Increment/Decrement Controls example in the User Guide. It would likely be quicker for you to use the search facilities in your PDF reader to find these things in the documentation. I have to do this in any case. Pete

The normal joystick axis response is pretty strange, being time-related, and has been since around FS2000 time I believe. Have you not tried the "STICK_SENSITIVITY_MODE=0" change in your FSX.CFG file, as recommended in the Calibration section of the FSUIPC User Guide? That reverts the treatment to the more linear response provided by FS98 and before. No, but you could program your own via a Lua plug-in. Assign the axis to a free FSUIPC offset (the range 66C0-66FF are assigned for users). Have a Lua plug-in, loaded by the ipcReady lua plug-in (so it's always running), which has an event function dealing with changes to that offset. Perform your mapping or computation and send the result as the parameter to the relevant axis control. I would have thought that was one of the things adjustable in the Aircraft.CFG file. Certainly easily done via a Lua plug in. The only other way I can think of is to calibrate the axis normally but then apply a multiplier/divisor factor to the FSUIPC axis assignment, to artificially reduce the range so the full calibrated range cannot be reached. But that seems very unrealistic to me. If the aircraft is designed with ailerons which can achieve certain angles, then you should be able to achieve them. If the FS aircraft is designed incorrectly, adjust it in the CFG file or design your own. There are quite a few add-on aircraft which are supposed to be a lot better than default FSX aircraft in any case. I didn't think any serious user stayed with any of the defaults. Regards Pete

Lua is a programming language used by a lot of programs for customisation and plug-in options. Please see the details in the brief documentation available in the "Lua Plug-ins.Zip" package -- it is installed with FSUIPC or available in the Updates and Other Goodies announcement at the top of this Forum. Your choice. I was only suggesting it because one end of your possible TCP/IP link is already done in the demo "slave" Lua program I mentioned. Not quite. The Lua plug-in route has the advantage of being a thread within the FSX process, so there's no process switching. Multithreading is much more efficient. The idea of the Lua plug-in part isn't to become a large program in any case. It would just be doing the FSX control for you. You interface to the plug-in, whether locally or remotely, in any case with whatever large C/C++ project you wanted to do. (I am a .NET Managed language hater BTW! I'd prefer Assembly Language if it were productively feasible in today's over-complex systems, but as it is I use a little Assembly here and there and the rest is C, not even C++.) I'm afraid it doesn't . If you want it to look smooth you'd certainly need to interpolate between your values to bring the rate up to nearer 20, really 15 at minimum, depending on the aircraft speed of course. If it's a slower aircraft you could get away with less. If it's a fighter or stunt aircraft you'd probably need 25 to 30. If, instead, you wanted FSX to fly the aircraft you'd really need to supply it with a very very detailed flight plan and fly on autopilot and autothrottle, perhaps manipulating those parameters too. Regards Pete

Okay. In fact you might even find it easier and more efficient these days to do it via the Lua plug-in interface. There are plenty of examples provided of both reading out values (display vals) and setting them (see below). There's even support for Luasocket built in, so you could drive it direct from an Ethernet connection using TCP, say. 5 Hz should be very easily accomplished. One would hope for something more like normal frame rates, i.e. 20 Hz. Try the supplied Lua plug-ins which link two networked PCs both with FSX installed (actually one or both could be FS9), one as Master the other as Slave. The Lua plug-ins are "SlaveServer" and "MasterClient", and don't need much configuring -- only the name or IP address of the Server in both. I've got good results at up to 20 fps with those. Regards Pete