Pete Dowson

I've been trying this and I simply cannot make it go wrong. Maybe I am not able to do it fast enough? Maybe your "fast" is actually moving so fast it is going up from 90 right round to 15 again? I've checked the code. Of course for the simple INC/DEC FSUIPC is not involved -- your request goes direct to FS. For the fast version, FSUIPC reads the value of the Bug, adjusts it by 10 degrees up or down, and sends it back to FS. If you are SEEING the value increment slowly, then that value is what FSUIPC is reading, to add or subtract 10 from it. There is no other being "held" for seconds so it can come back as you say. I really cannot see how anything could result in what you say you are getting. Please re-check, AND use the logging provided. Log buttons and events (two checkmarks). You should also Monitor offset 07CC as type U16 (right-hand part of Logging page), checking the normal log option at the bottom. Regards, Pete

Ibcidentally, the rounding problem seems intermittent -- usually 360-010 works. So it may be more of an FS quirk. Using which controls please? The "Fast Inc/Dec ones (FS's) or the Dec/Inc Fast ones (FSUIPC added)? I need to know. I cannot re-code FS but I can FSUIPC! Hmmm .. that sounds impossible, as there is no "memory" of what it was before. Is this occurring with the default 737 (the "bug" being the numerical display on the MCP)? Does it occur when there's a delay (pause) between the slow turning and the subsequent fast turning? what about the more usual adjustment method of fast turning followed by slow turning? It isn't anything like scripting or programming, but you do need to understand words like "set" and "clear". For the lights you will also have to be able to work out the hexadecimal number corresponding to a bit among 16 bits, because all of the light switches are in one word at offset 0D0C. You don't need to edit any files, it can be done in the same Button assignments screen you use for other things. It is only a matter of selecting the right control, then an offset, then a parameter (for simple on/offs this is usually 0 for off, 1 for on -- the lights are different as I say. You want Offset setbit for on, and Offset clearbit for off, with the parameter showing the needed bit for that light. Regards, Pete

RightI've tested these two controls here and the ONLY oddity I've found is when incrementing through 360 (000) a rounding error occurs -- the step from 360 to 010 actally gets to 009. Otherwise it works perfectly here. On the other points: FSUIPC added those called "VORn Obi Dec Fast" and "VORn Obi Inc Fast". The others (with the Inc/Dec at the end) are FS's and I didn't think they worked as you'd expect. (The list of all FSUIPC added controls can be found in the Advanced User's document). Can you be clear please about exactly what you mean? I cannot make the added FSUIPC ones go wrong at all. They are much simpler than the Heading ones as the units in FS are degrees in any case -- the heading one is made complex because it uses FS's angles (360 degrees = 65536 units), which is why rounding can play a part. So, please be rather more specific so I can help. I'll certainly try to fix the rounding (360 -> 009), but I need to understand more about what you are saying. I also need the version number of FSUIPC -- if you are not using the latest, please update it first. Note that you can always check that it isn't something in your button hardware, or programming, by assigning keystrokes to the same controls and testing them. They use the same code in FSUIPC. And also, if you look in the Logging section of FSUIPC, you will see that you can use button and event logging to check things even further. Regards, Pete

Sorry, can you explain what "only switching within two places on gauge" means please? It sounds like an FSUIPC bug -- the "fast" controls are added by FSUIPC, they are not FS controls. I'll investigate here and get back to you. Well, if you are using the normal INC/DEC controls, it is FS which accelerates them to operate in 10 degrees -- I only added the FSUIPC facilities for more precision. Have you got something else running which is defeating the acceleration perhaps? Look at your options in FSUIPC's "Technical" page. Anyway, if it is a problem in FSUIPC, I will have it fixed within a couple of days. If I added new controls for all such things my add-on list would be veryt long indeed. I suggest you download the FSUIPC SDK and find the offsets for these things in the tables. You can make your own controls then using the "Offset ..." controls in FSUIPC. Come back after you've looked if you need more help with this. Regards, Pete

I've found this -- it is a long-standing bug in FSUIPC! In fact, decreasing from 400 here goes to 559! It is a silly small error in my code. I have fixed it here and the corrected version of FSUIPC will be available in the Interim Versions announcement above within a day or two, by Monday for sure. Thanks for the report. Oddly, that makes two very old bugs reported in this one week, whereas none have been for a long time. I am expecting a thirddon't things always come in threes? ;-) Regards, Pete

Actually that's wrongwith the same option settings it cannot work with any Version 3's at all, nor even version 2's. In fact you've found a bug that has been there since the "Enable A/P Altitude Fix" option was first provided! Well done. ;-) Yes, for the time being go to the Technical options page and turn off "enable A/P altitude fix". That is reading the altimeter value from FS and assuming it is in feet. That's the trouble. I'm amazed that no one's discovered this for what must be around the five years it has been this way, but the fix is quite easy and the next interim version, up in the Announcements in this Forum, will include the fix. Have a look over the next few days. Thanks, Pete

I thought I was clear? WideFS links one PC running FS (the "Server") with any number of other PCs not running FS (the "Clients"). That is its function. WidevieW is not the same at all -- it links one PC running FS with others running FS too. WideClient effectively REPLACES FS+FSUIPC on the Clients to support FSUIPC applications. WidevieW runs WITH FS and FSUIPC on each machine, Server and all Clients. You can mix both on one Network with a common Server, but not on one Client. All the ways of linking multiple FS installations include WidevieW and Multiplayer, and probably others, and of course you can have different views and so on visible on each one. But none of that is anything to do with what WideFS does, and it isn't an area I am at all involved in. You may want to talk to someone in the WidevieW area instead? Sorry, but that sounds rather confused. I too have a Matrox Parhelia, and, yes, it runs three screens showing one very wide outside view very well. But that is all one one PC running FS. WidevieW doesn't really come into it at all. I have one setup with two fast computers, both with Matrox Parhelias, both with three screens. The one running FS shows a widescreen outside view across the three screens, no panel. The other PC shows all the glass cockpit instrumentation from Project Magenta -- pilots PFD/ND, EICAS+Standby instruments, and Copilot PFD/ND. I also use a lesser PC to run the PM CDU. These are linked by WideFS. I don't use WidevieW. If you want to link multiple FS's I really suggest you try the WidevieW support site and get advice there. There's also a system called "FsXPand" (sorry, I've lost the link -- search on Google) which may be more what you are after. Regards, Pete

WideView's server presumably runs here? The external view will be the main FS view, not one produced by the Wideview link. It is not possible for WidevieW to run without FS being installed on the same PC, and if FS is installed here you cannot use it for WideFS clients. You need to re-think. Doesn't WidevieW come with any documentation? You should certainly have a look at the WideFS documentation. You don't list FS as being on #2, but it must be for WidevieW, and cannot be for WideClient. Yes, of course. Run WideClient ONLY on PCs not running FS, as it says in the documentation. Regards, Pete

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