Pete Dowson

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

Well, i'm not taking offence, but at present I would consider that sort of crash highly unlikely to be FSUIPC or WideFS. However, events may prove me wrongall i can do is suggest that you update to the latest versions all the time and see if there's ever a difference. If I do find any reason my software may be involved I will certainly publish it. As you see, my release notes contain plenty of "bugs fixed" type entries as well as additions of new features and so on. If you wish to walk a little on the wild side, I can send you the latest Betas I have here, still under test. These should make release by the weekend if things go well. If you want to try them write to me at petedowson@btconnect.com. Incidentally, I've just got the AS2004 b163 beta update, and I'll see if I can try that soon. If that's something you've changed recently, and the problems has got worse since then, it may be an AS problem, but it seems unlikely too. Though any program can actually crash FS by writing things to the wrong place in FS, through FSUIPC or WideFS. There's only a few things FSUIPC can guard against, like writing to a read-only location or one that isn't allocated to FS. Regards, Pete

I think 2.11 dates back to July 2003!!! There's really nothing different in AdvDisplay for 1 character or 128 characters of text, it does the same for all. and it's been working pretty solidly all this time. What's suddenly changed on your system, or have you only just started using it? Not sure how that's related to anything of mine. The only program I did which handles sound was Esound (not supported for a while). Nothing actually buffers into windows. The display of text is simply a standard Windows function, called as needed. The text (up to 127 characters, actually) is kept in memory. How are you hiding it? If you use the Menu to uncheck it, it is totally disabled, it does nothing then. Any more details? Not sure how this connects to what you say. Data/audio conversion? That's something in FS I assume? I only handle text, not sure where the audio goes. What happens if you disable or remove AdvDisplay? If you can tell me how to reproduce it I'll try, but if you've had this happening for over a year I'm not sure I would know how to tackle it. I've had no other similar reports all this time. Regards, Pete

This is explained clearly in the WideFS documentation. The clients time-out a lack of messages from the Server before the Server times out messages from clients. When the client times out, it reconnects. The server allows a lot more time before it discards connections. Hence the increase. Something is going badly wrong with the connection to one or more of the clients. The logs will show lots of reconnections. This will cause bad jerky behaviour in the client applications. From the Server log you have provided it looks like you have a general problem across all 4 of your clients, but this didn't start till well into the session: 23071313 milliseconds to be precise (6 hours and 25 minutes). What happened then? Maybe something you are running on the Server has a memory leak? I think some types of scenery files (AGNs? The AutoGen files) if placed in the Addon Scenery folder can do that. There may be other causes too. Other possibilities are overheating somewhere -- network card/switch? Or other problems at that time in FS? You'd need to observe what was going on at the time for clues. WideServer itself doesn't use much memory. The summary at the end shows the count of buffers it actually allocated and freed: Regards, Pete

I cannot tell a "reset". Flight loads would also result in an aircraft load or reload, and these are counted at 32FC, though I'm not sure whether that would catch resets. If FS does the reset from cached data in memory, and not by file accesses, then I don't think there's any way i could detect it anyway. Regards, Pete

Obtuse? Hmmm. Reproducible? Good, that helps! Tell me the exact steps I need to take to reproduce it on my PC please. You seemed to be saying it occurs irregularly, unexpectedly, but now it has become reproducible? Why are YOU so sure it is anything to do with WideFS or FSUIPC? There is nothing to indicate this. Your "event logs" have no such information. Read one again, here: Registry information, message DLLs to display messages from a remote computer? What has that to do with anything any of my programs do? That all sounds very much system level stuff to me, to do with your Windows set up. You can say the same for any software product, although some others never get fixed. For my own programs, of the changes made in each successive version, around 90% are new facilities (mostly requested by users) or improved performance, and, yes, 10% are fixes to bugs, mostly introduced by the last round of additions. This is a regular thing. FSUIPC is added to continuously and is a full time job. Show me another product with so much support and attention to detail. WideFS has been running now for over six years with relatively minor changes. Its Network handling is all bog-standard Microsoft code direct from their own examples. Of course there are bugs, no non-trivial software is ever free of bugs, but there are far more bugs in FS itself, in video drivers, in Windows, than there are in the relatively trivial parts played by my contributions. Folks always blame FSUIPC or WideFS first, on the basis of no evidence whatsoever. It's in the "middle" of things and an easy target. When there are isolated instances of CTDs these have always turned out to be something else. If you do have some evidence, or some way of narrowing things down, please let me see it so I can fix it, but at present I am 99% sure it is not in my ability or responsibility to fix these specific problems. There is nothing to note yet. Of course I will give it my attention when it seems to be justified, but so far everything points to other things. Sorry. And actually I wasn't offended until now. Sorry you feel the way you do. When and if you can isolate your problem fursther, please let me know. I can really do nothing here about it. Both FSUIPC and WideFS trap their own errors and log them. If you wish to try the very latest Beta version of FSUIPC and WideFS, just in case something about the changes helps or otherwise, please write to me at petedowson@btconnect.com and I will send them. I am hoping to get them out as new versions by the weekend. Regards, Pete

Seasonal texture problem? Video drivers? Overheating? Sorry, I really can't diagnose CTDs. Before FS9.1 there were loads of possible reasdons. Since 9.1 there are less, but I doubt they are all fixed. Please see his thread next to this one, here. I don't want to repeat the whole exchange again. No, it couldn't. Why say that? Please ask the AS support person to justify that throw away remark. He is probably just as depressed with you blaming AS as I am with folks blaming me. Scan through some other forums sometime. Folks who use none of my programs get CTDs too you know! FSUIPC or WideFS get all the stick all the time, and it is very depressing, but there are far more users without such problems than with, and certainly enough folks not using anything of mine who get identical problems to prove it is not specific to my programs. Regards, Pete

I think the term CTD is only usually applied to those sudden disappearances of FS. One moment it's there, the next you are staring at the desktop. They are the most annoying as there's never a way to find out what happened. The ones with error messages are just plain "crashes". Well, with those you can get more details by clicking for details. you can get the name of the module (often, unfortunately, just ntdll, a common library part of XP) and an offset. If that's one of FS's modules then it is useful -- G2D and G3D, for instance, will indicate either a scenery problem or, just possibly, video driver. Well, certainly the FS9.1 update was supposed to have cured a great number of those found by the FS team at Microsoft. Regards, Pete

FS already has the facility to not load upper winds. If you are using an external weather program, mostly they can disable them too I think. But surely, you have wind smoothing enabled? The Concorde can easily manage slow changes in the winds -- you can make the changes as slow as you like. If you haven't enabled wind smoothing then, yes, you are liable to sudden 180 degree shifts in the winds which will cause all aircraft severe problems, not just Concorde! Regards, Pete