Pete Dowson

I don't see how that can be anything to do with how you program your switches, as those FSUIPC controls don't provide individual digit adjustments, only separate fractional and integral inc/decs. Well, you'd need C's in there to show they were Controls, and of course where the ADF radio has a standby, those change the standby frequency not the "in use" value as for the FSUIPC controls. Also, that series are for adjusting each digit separately. If you want to use the equivalent "standby" adjusters as the "in use" adjusters provided by FSUIPC you would use those like 66461, 66462, 66543 and 66542. However, I'm rather concerned over how your decrement from 400 could possibly go to 500. Can you enable both button and event logging in FSUIPC's Logging page, and show me just this part please (keep it short, just set things up ready, enable the logging, do the deed, disable the logging)? Regards, Pete

Why the condition on the flag 15,4? I don't know any reason whiy repeating a "throttle decrement" control at 10-20 times a second, whatever it is, will defeat any braking. Why do you think that? I don't know how you have your braking programmed -- maybe your assorted buttons are mutually exclusive, hardware-wise? Have you tried using the event or button logging in FSUIPC to see what is happening? On the contrary, I can't think of anything that would interfere with the wheel brakes. I'm afraid you'll need to go into more details. Regards, Pete

Has it been more than 24 hours? If not then you are too impatient -- humans have to deal with your request, and it does only promise 24 hours on the site. If it has been more than 24 hours then something may be wrong -- so you need to fill in a problem ticket on the site. I don't have anything to do with sales I'm afraid. I do development and tech support. Regards, Pete

In 0D0C each light switch is a separate bit, so all you need to to is make the LED conditional on that bit being non-zero. For example, the Taxi lights are bit 3 (meaning 2^3 or 2 x 2 x 2 = 8), or in hexadecimal X0008. For seeing which bits are set, hexadecimal numbers are simpler than the decimal ones we use in everyday life, Take a 16-bit binary number (only 1's and 0's) like 0101101011000011 Which in decimal is 23,235! In hexadecimal you simply divide the binary bits into groups of 4: 0101 1010 1100 0011 and assign a single character to each group: 5AC3 The characters assigned are: 0 = 0000 1 = 0001 2 = 0010 3 = 0011 4 = 0100 5 = 0101 6 = 0110 7 = 0111 8 = 1000 9 = 1001 A = 1010 B = 1011 C = 1100 D = 1101 E = 1110 F = 1111 In the case of the light switches, the bit numbers 0-15 simply mean how far from the bottom bit (the 1 bit or 0001 in hex) they are. So bit 3, for example, is three up, so in binary is 0000000000001000, or in hex 0008 (from the list above). In GFdisplay the offset therefore is X0D0C, as you know, and the "Mask" for the taxi light bit is M0008. Thus your line to control the taxi light bit is L2=X0D0C M0008 Okay? I'm sure you can now work out all the rest for yourself. Regards, Pete

Hi again, Peter, I've posted this in a more recent thread, but felt you ought to know too as it was you who suggested the possible solution to the problem posed in that other thread. As you pointed out, the VOR bearing details are available for FS. These are relative bearings -- in other words you have to add the aircraft heading to them to get the actual direction to the VOR. The values are from 0 to 359 (whole degrees only) and are those shown on the RMI (bottom left on the default 737) when you have the aircraft heading 0. I've mapped them to 0C56 (16-bit/2 byte) for VOR1 and 0C5C (16-bit/2 byte) for VOR2. This facility will be in the next interim update to FSUIPC which I shall release within the next few days. Please keep your eyes on the Announcements above. Regards, Pete

Okay, I have found that the bearing details are availble for FS. These are relative bearings -- in other words you have to add the aircraft heading to them to get the actual direction to the VOR. the values are from 0 to 359 (whole degrees only) and are those shown on the RMI (bottom left on the default 737) when you have the aircraft heading 0. I've mapped them to 0C56 (16-bit/2 byte) for VOR1 and 0C5C (16-bit/2 byte) for VOR2. This facility will be in the next interim update to FSUIPC which I shall release within the next few days. Please keep your eyes on the Announcements above. Regards, Pete

Don't you have any information on this "simboard" thing? I've never even heard of it. If you actually paid for it then you should be able to get help from whoever supplied it or designed it. Regards, Pete

You can read you aircraft's position (latitude/longitude) and the position of the TEST2 VOR (also latitude/longitude). The rest is trigonometry. Your VOR 'TEST' is not relevant of course, it is the aircraft position which is relevant. If the VOR is a close enough (which presumably it is for good reception?) you can probably get away with simple plane trigonometry, assuming a "flat Earth" for the distance involved. However if it is too far then you need spherical trig and great circle calculations, which get complicated. I could probably help with the former, but you'd need to look up the formulae for the latter elsewhere. Google will find plenty of course, search on Great Circle Navigation or similar. By coincidence, there's another thread here (http://forums.simflight.com/viewtopic.php?t=50633) which is very recent and also implies that there may be a way for FSUIPC to provide the bearing to the VOR directly. I am prepared to do this but I am still awaiting a reply from the poster there. Regards, Pete

Just open the FSUIPC.Zip you presumably downloaded from http://www.schiratti.com/dowson and copy the FSUIPC DLL into the FS Modules folder. Please PLEASE look inside the Zip and see that there's DOCUMENTATION. Part of the User Documentation, quite near the beginning, is about INSTALLATION, and that tells you this too. That is ALL you have to do, nothing more, nothing less. Of course not! Just copy the later version into the Modules folder. What's all this nonsense about deleting and re-purchasing? I really don't understand where you get such strange ideas from. The FSUIPC.DLL is one little file, it goes into the Modules folder. Just copy the latest version there. And please look out for later versions -- it is updated quite often -- and do the same each time. I don't support old versions in any case! Sorry, is this all about Captain Sim stuff? It cannot possibly be about FSUIPC as there's no install button, no install anything. PLEASE just have a look at the documentation! You are simply confusing yourself and making a very very simple thing very complicated. Now, don't you think you are now just being rather silly? Go read what you just wrote, and kindly be rather embarrassed by it! If you want to delete it, just delete it. It does NOTHING to your computer, NOTHING to FS, it is simply one little file which sits in the FS Modules folder. Either copy a new one in or simply delete it, it doesn't matter to me. But please don't go on here like a little baby. You don't need any sort of qualification except a little common sense, really. It is nothing to do with computer know-how. If you have anything more sensible to say or ask I'll be here to help, but otherwise, I'm sorry but I can't help you. Regards, Pete

But you said: and these issues are addressed in the SDK -- partly in the Readme, which talks about the problems, and all the information I can offer about the internal interface is held in the ZIP. Even the full C-source codes are there. When all this was designed I was convinced that internal modules could only be programmed in C, C++ por ASM. It seems someone has managed one with Delphi, which amazes me. But to do that you'll need to convert my C code. Sorry, I cannot help further on this. Of course, so is the external access system. It's defined in the standard Windows header files. Surely Delphi supports Windows? Try a search on Google, or even here. This subject has been discussed at length not long ago. As the complete sources are provided you should easily be able to find this information. I'm really sorry, but what you are asking is beyond what I can offer. My part of the SDK is aimed firmly at C and C++ programmers. I simply cannot understake other language support. If you search through the threads here you weill find other references and names of others who should be able to help. Regards Pete

Don't the makers of this "simboard" (which I've never heard of, sorry) provide any support? It sounds like a purely hardware or hardware driver problem to me. If the levers aren't seen by Windows, in its "Game Controllers" applet, then they cannot be allocated in FS. Neither Windows nor FS treat any axes as being solely dedicated to any one use in any case. You don't make a "mixture" lever work, you make a "lever" work. THEN you go into FS and assign it to the mixture. I've no idea what this "simboard control panel" is or does for you. Sorry. Only in the sense that you are using some third party hardware and hardware drivers which you cannot make work. I'm still not clear why you are asking here, you need support from the makers. Once Windows can see your controls, then so will FS and so will FSUIPC. Otherwise there's no way you can allocate them for anything. Regards, Pete

This is true, but only of the new weather interface added for the much more versatile weather system in FS2004. The idea was (and is) to provide a virtually transparent interface direct to FS so that the weather programmers can experiment and do a really good job, unrestricted to the things I (personally) thought were correct in previous versions of FS, where the interface was certainly not transparent. But you should never get them at all. They are indicative of a bug, and that would need fixing. What program is responsible? Hmm. Do you know the acceptable values? I don't. I know which values are supported for standard Cirrus, Cumulus, Stratus and Cumulonimbus -- these are the types supported in previous versions. Are more allowed in FS2004? I don't know. FS95 and FS98 had a "user defined" type, whatever that is, and all sorts of other types have been listed in assorted sources. Maybe they are not not supported if the bitmaps are missing? How would you tell? What matches bitmaps to cloud type number? Well, really the culprit program(s) should be fixed. I've been using FSMeteo and ActiveSky for many years and have never had one such problem occur. I don't know what program you are referring to, but shouldn't that work just as well? As you say, the modification isn't hard. I wouldn't delete such a cloud, only convert its type number. say all unknowns to become stratus (the fastest), or maybe make it dependent on altitude. But really it isn't something I would like to do -- I'd rather the programs were fixed if possible. Can that (correct) method be checked first, please? Incidentally, it is rather odd getting such a request 32 months (yes, not far short of 3 years!) after the facilities and programs were made available!? Regards, Pete

MagicBattery won't apply if it isn't registered. AutoClearWeather will default if it isn't there. I'm pretty sure the default is "Yes" but it will tell you in the Advanced User's document. In any case, that only has an effect if something actually writes to weather offsets in FSUIPC. Regards, Pete

No. Neither. The are active intercpets, part of the user facilities offered. It isn't on GPS load in any case, but on plan load as I remember. In FS2004 that option disappears as it is now offered by FS when you load the plan. No, it doesn't do that. Please check the FSUIPC.LOG which will show what it does. What parameters are they? Without registration, FSUIPC does almost nothing at all unless it is being used by an application program, or by an internal DLL or Gauge. If you are using none of these and you are not registered you may as well remove it. Regards, Pete

I've not come across that .. does it give the Mag or True bearing TO the VOR tuned on NAV1? Or is is in fact a copy of the Course (OBI or OBS) set on the NAV1 radio? There is an offset for this. I see that the VOR1_BEARING_DEGREES value has been available since FS2000 or so, so it is odd I've not been asked about it before. If it is in fact a value I do not currently provide then I shall add it to my list. Please advise. Regards, Pete

That treats FSUIPC as if it is in another process, and uses memory-mapped files and such. It is very inefficient, and it is likely to have problems if there are more than two such modules or gauges as the memory-mapped file would be shared. Please look inside the FSUIPC SDK. Inside you weill find a file called "README.TXT". There's a section in there called "IMPORTANT NOTE FOR FS GAUGE AND MODULE WRITERS". This is why "readme" files are called "readme" you know! ;-) Please check the main Programmer's guide in the SDK. There are offsets which tell you such things. Look at 3364 and 3365. Regards, Pete

Sorry, I don't know. It depends how it works. I assume it doesn't use FSUIPC in any case, so the only way it might work would be if it used Key Strokes, in which case you need WideClient to have the keyboard focus on the Client PC and set the parameter in the WideClient INI file to send them over to FS. This does seem highly unlikely though, and rather awkward if you run other things on the client PC. Regards, Pete

Capatain's Sim install isn't very nice it seems -- it sounds like it is installing an old (pre FS2004 update, Sept 2004) edition of FSUIPC and not actually checking whether you have a later version. Luke is correct. The only way to deal with it is to install the latest FSUIPC after installing the Captain Sim add-on. This is very good advice for any product, in any case. They rarely come with the latest versions. Regards, Pete

"Tick"? Do you mean the INc/DEC controls? I use the same as one press on the Numpad 7 or 1 keys -- I'm just emulating the normal elevator trim, that's all. Does a real helicopter have a rudder trim? It isn't as easy as there's not the same regular controls for that in FS in any case. In fact it was a very late addition to FS altogether, even for fixed wing aircraft, and most light aircraft don't have rudder trim. I'd rather not do it if it is manageable -- after all, you have to keep some pressure, albeit quite small, on lots of light aircraft, especially with high prop revs. That's what your feet are for! ;-) Regards Pete

The problem of using several PCs to try to show an extended outside view is that you just cannot get the weather synchronised on all of them at the same time in any case. I don't think the source of the weather (i.e. which program you use) is relevant. From previous reports I suspect there's also a bug in WidevieW's method of copying the weather. From what folks say it doesn't seem to be dealing with all the local weather stations as you fly, with the result that the weather "disappears". Incidentally, you can't get the AI traffic coordinated across multiple PCs either, though this probably is only of major importance when taxiing at airports and taking off/landing. FSMeteo is a weather program like ActiveSky. The two have been competing for several years now. FSMeteo took an early lead but I suspect ActiveSky is well ahead now. Both are payware of course. I don't know much about FSMetar. There is another payware weather program called WeatherMaker Pro. Regards, Pete

Please try the attached FSUIPC version 3.548. I've added a facility to maintain and apply an "elevator trim" to the "elevator axis" for those models which otherwise have no such trim. The details are: 1. The new trim is operated by all the usual FS controls for elevator trim -- Elev Trim Up, Elev Trim Dn and the axis version. So you just program your trim in the same way as for a normal aircraft. 2. It only operates if you add "ApplyHeloTrim=Yes" into the appropriate JoystickCalibration section of the FSUIPC.INI file. I'm afraid I cannot detect helos in a foolproof way -- the Bell looks like one, but the Robinson doesn't, internally. 3. As a safeguard it also doesn't apply the trim if the normal FS elevator trim value is non-zero. That way you don't get two trims adding to one control even if you make a mistake. 4. The trim is only applied to an elevator axis value calibrated via FSUIPC, in the Joystick Calibration section. This is the only reliable way I can influence it. 5. For a trim indicator or programmatic control I'm reading and maintaining the helo trim value at FSUIPC offset 0BBE (16-bit integer). I cannot provide it via the standard FS indicator position as that is held at zero by FS for helos (as you found). Please let me know how you get on. I'm afraid I'm no helo flyer so I've not actually tested in action here, only theoretically. Regards, Pete FSUIPC3548.zip

The kit I used to have used these and not the more complicated encoding types which you say are more popular -- in fact I didn't even know about the 'popular' types till someone sorted out a way of programming the phase-encoded types for EPIC. There is mention of the phase-encoded types in the Advanced User's document for FSUIPC -- in fact there's a complete example. I think the 2-line phase encoding type is the same as a 2-bit graycode type. I really don't know where you'd get the "simple" ones from. The ones I had (I no longer have that kit) were out of the original Aerosoft (Paderborn) keyboard-connecting control panel, so I assume the switches were German. I've not seen any in any UK catalogues. You could try the cockpit building forums. Someone there may know. Regards, Pete

That cannot be. You are looking in the wrong place. Do a search on your PC for all FSUIPC.DLLs. You are getting something very very confused. It is absolutely not possible for version 3.53 to display "3.48". There is no such text in it. The last time anything like this happened the guy was checking an installation of FS on a different drive or folder to the one he was actually using! Regards Pete

It was the only reason I started on FSUIPC in the first place. Anything is possible, almost -- but I am not starting on anything new, This has taken me many years full time and I'd like to make space to do some flying and maybe even get back to my model railway. I am not taking on any new FS undertakings. Perhaps, since you have ideas you will instead? Please do a search on this, and read the WideFS docs. I have explained this all sorts of ways several times. I really haven't time at present. Sorry. Sorry, what does that mean, "very long process"? You think you can make it all work much faster? The only thing which is slow is process switching -- how can you avoid process switching? Regards Pete

FSUIPC's interface was defined (not by me) in FS95 times in FS5IPC, then FS6IPC in FS98. There's a lot of history. The interface has been compatible now with application programs since FS98, continuously. By all means write an interface to FSUIPC if you like, or, better, feel free to write a replacement to FSUIPC. But how to you make all the applications compatible "just like that"? I'd would really like you to do this as I would rather fly more in future! ;-) Regards, Pete