Pete Dowson

Ooops! thanks. I'll make sure it is changed for the next version, whenever. I am hoping to release it this weekend or at the latest early next week. But is there something special you wanted it for? Regards, Pete

Well it's done that on FS2004 ever since FS2004 came out. It's to prevent flicker -- the way FS now draws its window causes any dialogues which are produced without using its own complex DirectX-oriented system to flicker horribly even when static. To get around that, FSUIPC prevents frequent re-painting in the main FS window whilst the dialogue is displayed. This creates the effect you see, if you drag it. If you've not noticed it before you've probably not actualy moved them about. Regards, Pete

But they don't use GFDev.dll, the have FS dlls installed in the Modules folder. Find the GFconfig program, wherever that is. GFDev.dll should be in there too. I don't think anything else of Goflight's uses it, and older versions of the Install didn't install it. There should be a Registry entry pointing to the GFconfig. That's how FSUIPC finds it. If you've reinstalled Windows but not the current GF software then the registry pointer probably won't be there. If FSUIPC can access GDdev.dll there's nothing stopping it seeing the buttons. The same goes for WideClient if you have GoFlight stuff on a Client PC. Regards, Pete

Prop Amplitude? What is that please? And where is this gauge -- I don't see it anywhere on the default FS2004 Baron? I don't know. The only thing I can think of for a propeller which might be called "amplitude" is the pitch. That is controlled by the propeller pitch value (offsets 088E and 0926 for the two engines). There are also values for the propeller "Beta" blade angle, which is either the same, or presumably related, to the pitch. See offsets 2418 and 2518. Ah, is your "prop amp" related to vibration? I see nothing anywhere in the variables inside FS which may relate to that for props I'm afraid. Are you sure FS models what you want? Regards, Pete

It doesn't work like that. If a second application writes a message before an earlier one has timed out or scrolled off, the first will be discarded and the second one will take its place. There's no queuing or concatenating. It just operates simply, as does the original FS facility which it is intercepting. Regards, Pete

Did you install the Goflight software? FSUIPC needs to be able to find the GFDev.dll which is installed along with the GF configuration program. In fact I think it goes with it into the GFConfig folder. The installer also updates an entry in the Registry which FSUIPC uses to locate the DLL. Regards, Pete

Ahvery sorry. I didn't examine your original code segment closely enough. Yes, you had: val.lval=(unsigned)((Altitude-val.hval)*65536); which of course isn't right. Think about it, with an example. half a metre (0.5) would be represented in binary by a 1 bit just below the "binary point". In this 64-bit bumber the "binary point" is between the two 32-bit values -- the first, or lower 32 bits, represent the fraction. So, 0.5 metres is, in hexadecimal: 0x80000000 in that 32-bit word. By only multiplying your fraction by 65536 you were only shifting the value to the top of the first 16 bits (65536 = 0x10000), so getting only 0x00008000. I expect this was coming back as zero because FS doesn't work to any greater accuracy than 1/65536th of a metre (0.15 mm). In fact it probably doesn't even use all of the top 16 bits. If your compiler supports long long or _int64 (as I think the current MS C/C++ compilers do) then all you needed to do was _int64 llAlt = (_int64) (Altitude*65536*65536); then write llAlt as an 8 byte value. Regards, Pete

Check the thread http://forums.simflight.com/viewtopic.php?t=31427, entitled slightly obscurely "Button programming question". The latter exchanges are relevant. Seems we found a way to make it work with at least one (latest?) version of TeamSpeak. The clue was Lee reporting that FSUIPC programmed buttons worked for TeamSpeak PTT when the latter is on the FS PC. The version of WideFS with this SendInput facility is being made ready for release now. I hope to release FSUIPC 3.44 and WideFS 6.44 over the weekend. Check the usual place early next week. Regards, Pete

Unless you calibrate throttles in FSUIPC, it doesn't touch actually touch them at all in any case. Does this "feel There ERJ" actually use FSUIPC for anything? Do you have an FSUIPC Log file (please run it and close FS so the FSUIPC LOG is closed first). I'm not sure why you think it is a "conflict" with FSUIPC. How do you arrive at this conclusion? Can you be more specific? Also, I always need the FSUIPC version number, in any query about it whatsoever. Finally, have you contacted support for the ERJ -- it seems they should be the ones who wish to resolve anything like this. If they aren't willing or bothered to discuss it with me I doubt that any progress can be made in any case. Is "Feel There" the name of the aircraft or the company? Is it payware or freeware? Is it actually designed for FS2004 or some old aircraft brought forward from FS2002 or FS2000? Regards, Pete

Just write the control number to the 4 byte value offset 3110. You don't need to bother with a parameter for these increment/decrement controls. If you have 4 rotaries you use the first 8 controls above. the other three aren't relevant to your needs. Those are included in your list above ...? Those are the added FSUIPC controls which will suit you if you only have 2 rotaries. Didn't I mention all this in my last message? Regards, Pete

That's all outside my knowledge completely I'm afraid. I do not know FSbus at all, so I don't know what facilities it offers. Are you saying it doesn't provide anything that looks like "button presses" which can be programmed in FS or FSUIPC? If FSbus only allows incrementing and decrementing offsets, then you could achieve that by addressing each of the two bytes containing the Transponder value separately. i.e., of XXYY the XX is in the single byte 0355 and the YY is in the single byte 0354. However, simple incrementing and decrementing won't really work correctly. The values go from 00 to 77 not to FF -- in other words values 8-F for any digit are not valid. You would need to increment/decrement and then logically AND the result with 0x77 to remove invalid bits. Can FSbus do that? If it cannot be made to emulate buttons, then the only way to use those would be to use the facilities at offset 3110 to send controls to FS. You find the control number and write that to 3110. For FS controls use my list of FS2004 controls, included in the last FSUIPC.ZIP release. For added FSUIPC controls the list of numeric equivalents is in the Advanced Users guide. But doesn't that go wrong? For instance, doesn't it increment 4567 and make is 4568 (invalid) instead of 4570? Sorry, that's a question for FSbus. Doesn't the documentation cover it? I'm afraid I don't know FSbus at all, as I said. Maybe sending controls to 3110 will work? Regards Pete

You are Mapping a single generic throttle to the 4 separate ones! Why? I thought you said you had two throttles? If you have only one throttle axis, that should be assigned to the single generic throttle in FS, not to Throttle1. If you have two separate throttle axes you do NOT calibrate or Map the single throttle value -- that isn't even used. The values shown above are default values. It looks like you've not been through the calibration process either? Regards Pete

If the IN and OUT values are always the same, then FSUIPC is not processing the axis at all. The button above on the left will read "Set". If FSUIPC was doing anything it would read "Reset". Please, please, please, follow the steps in the documentation to calibrate in FSUIPC. Regards, Pete

Sorry, I really have no idea whatsoever at present. Could it just be that your PC is well able to cope with FS2002 but less so with FS2004? What is it, exactly, and how much memory does it have? Also what operating system? Have you tried limiting the frame rates in FS2004? What is the typical frame rate you experience? The logs are for only very short periods. On the Client there's a gap of apparently "good behaviour" (?) lasting 20 seconds or so: 54500 Connection made okay! 75187 Error on client post-Connection Select() [Error=10053] Software caused connection abort Are these regular? Could there be something else running in the background that might have such a period? Remember FS2004 is MUCH more demanding than FS2002 and may be more heavily affected by things you previously thought mattered little. On the Server side, how is it that it didn't actually start for over 28 minutes after FS was loaded? Does it take your FS2004 that long to load, or was it sitting in the initial selection dialogue awaiting your attention for that long? The Server and Client logs do not sem to relate to the same session. The time of day is wildly different and there is no apparent period matching the 20+ seconds of "silence" in the Client log. In order to see things better I'd really need rather longer logs -- at least long enough to see if there is any pattern -- and ones which actually came from the same session so they can be matched. Regards, Pete

7 segments? 7 segment LEDs are rather outside the scope of what offset 0354 is about! Do you mean 1 out of 4 digits? Are you writing a program to change 0354? If so, why not simply read it, change whichever digit you want to change, then write it back? Ah, you mean to program a rotary to change any one of 4 digits? Why are you messing about with FSUIPC offset 0354? Why not simply use the FS controls designed to do just that? XPNDR 1 DEC XPNDR 1 INC XPNDR 10 DEC XPNDR 10 INC XPNDR 100 DEC XPNDR 100 INC XPNDR 1000 DEC XPNDR 1000 INC These are all assignable in FSUIPC Keys and Buttons. Actually they may well be assignable in FS itself for all I know. Have you looked? Also, in a recent release of FSUIPC, as you will see from the History document (and the Recent release notes above), I did add special FSUIPC controls to inc/dec the transponder in two halves (if you want to save on rotaries): Xpndr low NN dec Xpndr low NN inc Xpndr high NN dec Xpndr high NN inc So with two rotaries you can change it mighty quickly. What else might be needed? It seems to be pretty well covered all ways, doesn't it? Regards, Pete

Hi Bob, Thanks for trying to cheer me up! Actually I'm not too down, but it does seem, sometimes, that there's always a rash of weird symptoms I need to deal with just when I'm on the point of freezing a new version ready to document and get out the door! Best wishes, Pete

If FS2002 and before, FS itself read and actioned these offsets, albeit only in Pause or Slew modes. In FS2004 it never reads them. FSUIPC has to see you writing to them and call a routine in FS's SIM1.DLL to get them activated. I don't know precisely what is happening, but by writing the low part and the high part separately you are invoking two independent calls to that routine in FS, and odd results may well occur. Try either using a single 64-bit value (long long or __int64 depending on your compiler), or a structure with the two values in (unsigned int for the fraction and int for the integer part, respectively). Write using one write of 8 bytes. Let me know please. This is something I've not previously been aware of. In general it is always better to structure single entities like this in your own program and write them as one unit to FS. In fact the Altitude is one one of 6 values, and all 6 have to be written together even when you only change the altitude. These are offsets 0560 to 0583, encompassing Latitude, Longitude, altitude, Pitch, Bank and Heading (LLAPBH). There's no separate way I can change one part. Regards, Pete

Run it again, then close FS. Zip up the FSUIPC.LOG and FSUIPC.KEY files (from the FS Modules folder). I will check your user registration here. So far this has only ever arisen from a bad user registration, so I need to check it for you. Regards Pete

What's the "idle setting button"? How do you mean "0" position? Where are you reading this? When the Input from your throttle is reading -16256 (the "IN" value in FSUIPC), what is the OUT reading? If you've calibrated correctly it will be something like -4096. That's maximum reverse thrust. Down only to zero, not into the reverse zone? I really cannot picture what you are seeing from here. The individual throttle facilities always work setting reverse, this has never been any sort of problem. Please show me the Joystick calibration section of your FSUIPC.INI file. Regards, Pete

There's no reason memory would do that. If the calibration is "going off" during a session it sounds like either the pots in your controls are failing, or more likely shifting. I had such problems with my old Thrustmaster pedals, years ago -- the pot was seated in the centre, between the two footrests, but somehow it lost its fixings (the plastic lugs just sort of wore smooth) and it used to gradually turn in use. The upper limit of 16383 seems suspicious. that's the highest it can possibly be. Are you sure you calibrated correctly in the first place? Anyway, those values aren't the important ones. They aren't going to change at all. They are read from the FSUIPC INI file, where they were written when you last calibrated. The important values are what your pedals are showing at each extreme and in the centre, NOW -- i.e. the IN and OUT values. If those are different each time, you have a hardware problem. The -8192 and +8192 values are too exact, too clinical, to be true calibrated values. It really looks like you have't calibrated them correctly. Try going through the ennumerated steps in the documentation. If you have pressed the "set" button (so that it now reads "reset") for each axis you are using through FSUIPC, and confirmed (pressed OK, not Cancel, close or ESCape), then the calibrated values and the fact you've calibrated them will be written to the FSUIPC.INI file to be read next time. Are they? Check! Is your FSUIPC INI file write-protected, perhaps? That will certainly prevent ANY FSUIPC options sticking. Regards, Pete

Ahthe "sticky"? I can expand that soon to encompass what we've learned recently about TeamSpeak PTT. I'd love to be able to do that one day. It needs time, patience, and skill at writing at that sort of level. I'm afraid I'm very short in all three departments. And I don't even fly on-line, so it isn't my subject at all. I am always hoping that one day soon I may even find time to actually fly a bit myself. I think I manage to get about three decent, for fun, flights per year. Thanks for you worthwhile suggestions though. Perhaps we'll get a volunteer stepping into the fray one day. :wink: Regards, Pete

1. What version of FSUIPC please? 2. What does the "OUT" value show as you reduce the throttle back from the idle position to full reverse? Is the IN value actually getting to your -16256? 3. Observe the throttle quadrant on the panel. What is the throttle lever doing? 4. Check that you don't have more than one throttle axis assigned to the throttle -- this can happen if you have (or had) more than one joystick/device attachment. Look in FS Options-Controls-Assignments, see if there are other devices with axes assigned to either Throttle 1 or the generic single throttle-does-all axis. 4. Is this with all jet aircraft, or a specific add-on? I think some Airbus implementations have throttle management which interferes with any attempts at direct throttle settings. Test things on the default 737, say, first. Regards Pete

Oh, right. I don't think Windows knows about PCBs. Certainly this isn't a recognisable unit of anything as far as FSUIPC is concerned. Sorry, I have absolutely no idea. I think Windows, or maybe the USB specification, has a limit of 128 devices, but that may be per USB connection, not overall. Again, I have no idea. I am not a hardware expert and know nothing about USB. There's a maximum number of programmable entries in the INI file, yes. I don't remember what it is now -- it is mentioned in the documentation. It isn't at all related to USB or Game controllers or PCBs, which FSUIPC knows absolutely nothing whatsoever about. Well, not really. You seem to think I am some sort of hardware expert, which I am not. As I explained in my last answer, for buttons FSUIPC uses the Windows joystick API. That is limited to 16 joystick devices, each with 32 buttons and one POV. That's the limit. How your PCBs relate to joystick devices I have no idea. Sorry. Regards, Pete

Well, normally Damian is quite good at this, and discusses things with me first. I have no idea why he is doing this now. No. That comment dates back about 5 years or so, and refers to programs which interface to FS and find out automatically which version is running by reading the text in the title bar. Unfortubately some of them compared the whole string which is obviously different if WideServer has added its bits. I really cannot remember which they were, but it is unlikely that they are still around in the same form today. I have no idea how it is at all possible for any texturing or any graphics in FS to have anything whatsoever to do with any activity at all in WideFS or FSUIPC. Where do you read these things? Certainly no one has mentioned anything like that to me that I remember at all. Neither FSUIPC nor WideFS have any relation to anything graphical, either inside or outside FS. No, that's wrong. The only thing he might be referring to is the flickering of 2D panels when clouds are redrawn, by FS's own weather engine, on the behest of a weather program. Apparently this can be fixed by turning render to texture off. There's some notes about that near the end of the FSUIPC User Guide. But it is in no way an "FSUIPC requirement", it's something weird with Fs's graphics handling. Regards, Pete

Sorry, I don't really understand the question here. What do you actually mean by "prints"? To me, a print is a copy of a photograph or a photocopied or printed piece of paper. I'm sure you don't mean that. Anyway, I'll try to answer what you may be asking. First, FSUIPC does not interface to USB, Game Port, or any other hardware directly. For buttons it can input from EPIC (via EPIC.VXD for ISA EPic only, via EPICIO.DLL otherwise), from Go Flight devices 9via GFDEV.DLL), and from the Windows joystick API. The Windows joystick API supports up to 16 joysticks each with up to 32 buttons. That is therefore the limit for FSUIPC. However, in addition, FSUIPC will convert a single "point of view" control (POV) on each of the 16 joysticks to up to 8 separate buttons, the 8 cardinal directions. FSUIPC does not use DirectInput, so its coverage doesn't extend to the extras that can make available. Regards, Pete