Pete Dowson

The interface WideFS uses into FSUIPC hasn't changed at all, not for many years. It looks like you have some performance or, more likely, reliability problems. Do you think it is possible that there are so many axes being scanned that the FS PC is overwhelmed? Ir possibly you've set the "Delta" so low that every little jitter in each axis creates many FS messages? Perhaps you ought to show me the [Axes ...] sections of your FSUIPC.INI file, just in case? You could also temporarily remove them (just make a copy of FSUIPC.INI and delete those sections frmo the one in FS Modules folder), and run FS and wideFS again, for comparison? There is a parameter which can change the polling frequency FSUIPC uses, so we can try adjusting that, but let's see if it is anything to do with the axis assignments at all first. Some other information is relevant to, please: * FS PC's operating system and version * FS PC's Processor type & speed * FS PC's main memory size * FS's frame rate limiter setting * Whether FS joysticks are enabled or disabled However, whilst it would be a good idea to check them all, now looking at the WideServer log I really don't think it can be any of the above. Sumcheck errors mean that the data arriving from the Client is certainly corrupt. I have never seen such errors without there being something wrong with the network somewhere, and in fact I've never seen such a bad example -- even on a faulty Network card I've only seen the odd sumcheck error from time to time. I really think this is more likely to be due to one of: * faulty network card or driver * faulty hub or switch if you are using one * bad cable * main memory faulty * IRQ or DMA conflicts in the FS PC, possibly with the video card The network may look to be working fine for other things, but in my experience this is an illusion, as Windows doesn't appear to check things -- it takes it on faith that the Network subsystem guarantees data integrity. Last time I had a faulty network card things like file transfers from Explorer appeared to go well, but when doing file comparisons afterwards (using the binary file comparer "FC /B" or Directory Toolkit) nearly all the files (and certainly all of the large ones) contained differences -- a crucial problem when such files are supposed to be programs! Incidentally you did not show me the WideClient Log, though you appearently intended to. If you look it seems to be another copy of the FSUIPC Log, which in fact isn't relevant in any case. Regards Pete

I'm afraid I am unable to help with C#, which is really quite alien to a C programmer (I have no idea why MS called it C anything :roll: ). The C# part of the SDK is undergoing a serious overhaul with new tools being added, but I don't think a release is imminent. Meanwhile, you could direct you questions to its author, one Pelle Liljendal. I think you should find his details, even his website, via the Sticky above about FSInterrogate. Two things I do find rather odd, but it may be my non-understanding of C#: 1) You seem to have a thing called "fsuResult" which somehow has a dual purpose. For example, on an error you treat it as a result code: TranslateResultCode(fsuResult) but then, just after that, you treat it as if it receives the Air Speed itself: Surely if it were to contain the result code, a zero for success would be what you'd expect? 2) The value in 02BC is, as documented, the airspeed in knots * 128. In other words the units are 1/128ths of a knot. Yet here you are multiplying it again by 128. Do you really want it in 1/16384ths of a knot? Regards Pete

The most likely reason is that you have something else also displaying things. Try right-clicking on the window and selecting the "multiline" option. Then only multiline messages will go to this window, the others will go to FS as usual. RC is either the only, or one of very few, programs using multiple lines. Incidentally, for RC you can make the window a bit shorter (the number of lines never exceeds what you see above), and it looks much neater if you "dock" it or "lock" it, at your choice. If you have space on your panel you can make it look more like a panel instrument -- change the font and colours to match as you wish. For Windows XP (only) I can make transparency and translucency work in FS's Windowed mode (I have a version here which does this). But I can find no way of making it work in FS full screen mode (on FS2004) without an horrendous flicker (at the frame rate I think) making it not only unusable but very annoying. I've not released this version because I think most folks use FS in full screen mode. If you don't, you can certainly try it if you like, let me know. It isn't fully working the way I like (sometimes after changing an option is isn't repainted in the right transparent/translucent mode, and I have no setting at present for varying the amount of translucency). I'm afraid I've never found a way into the parts of FS which do windows like the ATC one. I wish I had managed to do it, because it would be great to divert the FS default ATC messages to a separate program for appropriate responses or actions, possible automatically. Regards Pete

I am sorry, but there is no possible way WideFS, can have any affect on your graphics or on any cockpit in FS. WideServer simply provides a service to any Wideclients on other PCs. If nothing connects from those, WideServer does nothing whatsoever. However, if you are using WideFS or FSUIPC with a bad user Key, then things can go wrong in FSUIPC, and this can most certainly affect FSUIPC users such as the PMDG 737NG. Please Zip up the FSUIPC.KEY file from the FS modules folder, and send it to me at petedowson@btconnect.com, along with details of your purchase of the WideFS key from SimMarket (or wherever). I will check it out here for you. Regards, Pete

I am sorry, but there is no possible way WideFS, can have any affect on your graphics or on any cockpit in FS. WideServer simply provides a service to any Wideclients on other PCs. If nothing connects from those, WideServer does nothing whatsoever. Regards, Pete

Ah, by reading the WideFS document, and finding this section: You still need to run and configure the twin virtual ports, of course, using the other freeware provided in the GPSout ZIP. Regards, Pete

I am sorry you feel this way. I really don't see how you bring "courtesy" into it. I have tried extremely hard, to the point of answering specific questions with specific answers, and trying to understand what it is you cannot fathom. But you should appreciate that trying to deal with someone who doesn't appear to actually read things and doesn't follow simple advice is not only unfortunate but it is very very unproductive. This will probably come across now as a "rebuff" but I honestly cannot see how you can possibly say that any of my previous efforts on your behalf were. There's only so much one can do with some folks, and I have tried all I can. Gargantuan? Verbose? Most folks complain I don't explain enough. I don't like doing dsocumentation as it is, maybe I shouldn't bother in future? I know most don't read any of it in any case. And I am not sure what you actually mean by the "interface", but if you mean the easy-to-use FSUIPC options one, to assign controls, I assure you that is used a lot by many without any trouble. I did tell you exactly which control it was, even if you had missed the sections about it in the WideFS dcumentation. As for WideFs, well, there is no "interface" which normally concerns most folks. It is primarily an extension of the FSUIPC interface for applications. that is what you get. the extras, being able to actually do "KeySend" stuff and have remote buttons and so on are all additional frills requested by and used by cockpit builders who are relatively knowledgeable both about aircraft and technical things. I know this from experience in this field over many years. But it is not what it is provided for, nor indeed sold as. And you did have all the opportunities you needed to read the documentation and ask questions even before parting with any cash. I hope SB3 gets the original problem fixed as for PTT, then you will be able to continue. Otherwise I wish you a fond farewell. Regards Pete

KeySend1=123,16 ; Press F12 KeySend2=123,24 ; Release F12 Look at this (from the wideFS document): So, 16 = 8 + 8, so this is "key on its own", and "press the key". 24 = 8 + 16, so it is "key on its own", and "release the key". There. What is hard about that? Please tell me, because I've never had to explain it at this level at all in the 8 years of WideFS! Evidently my English isn't as good as I thought and maybe I've just been lucky all these years? Help me improve the documentation! Oh dear. I'm sorry, but it is very hard for me not to lose a little patience now. As I've said twice before, you just don't! FSUIPC has no facility to send keystrokes to clients. You evidently entirely missed this part of the WideFS document: You simply program your button to send the KeySend control (it is in the list of controls you can assign -- please go and look!). The parameter for the Keysend control is the number N in the "KeysendN=..." in the WideClient INI parameters you've just quotes examples of. If this is still beyond you, I really do suggest you wait until Joel has looked at the SB3 PVT system. I don't think I can possibly explain this at any lower level than this. I'm very sorry. Regards, Pete

Possibly. Sorry, I don't know SIOC. Pete

No, not at present. I have been thinking of adding it, with the new Axis Assignment facilities, but it isn't easy. I have to work out a way of making it efficient, only scanning those axes which are actually calibrated in FSUIPC. You can use the buttons of course. Pete

No. I think those offsets are used both for output to PM as well as by PM itself. If you want some offsets, best to apply as suggested in the documentatin. If you don't need much then 66C0-66FF (64 bytes) are available for general use by anyone. Regards Pete

Because the interface FSUIPC and WideFS presents to applications was invented for and designed for FS98. Even FS's main Window is called "FS98MAIN". Wideclient replaces FS98MAIN for applications to see, thinking they are connecting to the FS98 interface. What am I using? Well one or all of these, not necessarily all at the same time, but mostly so: ASV6 FSRealTime Radar Contact V4 pmSounds pmSystems AISmooth ShowText Project Magenta MCP Project Magenta PFD/ND Captain Project Magenta PFD/ND F.O. Project Magenta EICAS Project Magenta CDU Project Magenta RCDU Flight Keeper TrafficBoard Regards Petes

That's not right. FSUIPC will process the 3110 write BEFORE it processes the 3114 write. You must either write them in the same FSUIPC_Write (i.e. make a structure of 2 x DWORDs and send 8 bytes) or do the FSUIPC_Write for 3114 before the FSUIPC_Read for 3110. That's weird. I will have to try it here when I get time. If it is an FS bug I'm afraid I cannot really do anything for you -- all FSUIPC does here is send your control and parameter to FS. you could actually do exactly the same by posting a WM_COMMAND message to FS's Window with the command as wParam and the parameter as lParam. However, please revise your code to fix the order first, just in case it is that which is messing things up. Well, as I say, FSUIPC is transparent here. Try fixing the order first, before crying. Regards, Pete

Zip up the FSUPIC.INI file and send it to me at petedowson@btconnect.com. I can check that easily. There are some powerful axis assignments you can make, you certainly don't want to assign things willy-nilly! ;-) If the graphics "problem" was actually only a continual change of view then the most likely thing is that you've assigned a jittering axis to one of the view controls. If that's the case you should be able to find it simply by reviewing all the assignments, one by one, in FSUIPC. i.e. go through the process looking at each axis in turn. If you send me the INI file I can check here too, to see what's been assigned. Either way, "reinstalling" FSUIPC isn't realy necessary as the only data file controlling what FSUIPC does is the INI file. You can either simply delete that before loading FS again, or, if you have set lots of options up the way you like them, edit it in Notepad, find the [Axes] section and delete just that one section (or more if you've made them aircraft-specific -- each of those will be [Axes.]). But please don't delete it until you've sent the file to me. Please let me know either way, and also, if you do encounter folks discussing problems with FSUIPC elsewhere, please see if you can encourage them to come here. Regards, Pete

I seem to have read this before in another thread? Please don't post the same things twice, it just makes a lot of extra work. Trying? This is probably the commonest action FSUIPC is used for, and it has been used in this way now since FS2000 days with no problems. Why did it need "trying"? You most definitely had something else entirely going on there then -- there is absolutely no way FSUIPC touches any of that. There's no difference whatsoever unless you want to use FSUIPC's axis assignments. And no one's asked questions here, until now, so why are they "responding" elsewhere? The Beta versions are provided here for a reason, so I can get testing and feedback. It is no use having that going elsewhere! :-) If you are confused by Axis assignment in FSUIPC, why on Earth use it? Use the assignment in FS. Of course you can assign an axis to the mixture in FS OR in FSUIPC, not both. Either way it would be picked up by the default setting for reverser in FSUIPC's Calibrations. An easier way without going via "mixture" is to use the "direct to FSUIPC calibration" option to assign it directly to the Reverser! Surely, isn't it obvious that FSUIPC's Axis Assignment is an alternative to FS's axis assignment, with more facilities. That's what it says. Why any confusion? It is ANOTHER FACILITY! That is all. Would it be clearer if it were in a different program called "AXISASSIGNMENT"? If so, why, exactly? I am vey very puzzled over this reaction. My general advice is: if you don't understand it you probably don't need it at all, so don't use it. It was added in answer to requests, and I'm sure those who requested it will use it well. Sorry, I've no idea. There's no such thing as "X rotation" in the standard Windows joystick API. It must be a name given to or by DirectInput. However, if the same axis changes the numbers, then, yes, it IS the same axis, by definition! That's how I would find out if I needed to know. The axis calibration facility scans the axes and shows the one with the biggest change at that time. It does this initially and the scan can be repeated by clicking the Rescan button. Please read the documentation about this. It explains at length, with pictures, how to use that tab. If an axis is shown as soon as you select the tab it usually means that axis is changing. If you aren't touching it this would usually indicate some jitter. You might need to use the Ignore button to see the one you want to program next, or check on another. No, it writes the INI with ALL the changes you have made on any or all Tabs, only when you press Ok to exit. At any time before you press Ok you can Cancel, or press Escape, and NONE of the changes you made, at all, during this entire entry to FSUIPC options, will be effected, all of the previous values will be retained. No, never. Only after user Registration, when you are prompted to restart. Why should one be needed at any other time? That would be horrendous! I really cannot imagine what you are doing, but the fact that other things got screwed up is certainly an indication that something else is wrong with your FS installation. I would advise reinstalling FS itself. POVs are not read and cannot be detected by FSUIPC's axis programming. They are only read by the Buutons tab and converted to 8 buttons according to direction. Not just yoke, all and any joystick devices. But you don't have to disable them, I only said you could IF you wanted to do everything through FSUIPC. It might be more efficient, and certainly more flexible that way (what with the aircraft-specific capabilities). But you don't have to. You certainly can mix them. Just take care not to have any specific axes or buttons programmed in two places at the same time. Regards Pete

Well, not having it in the CFG file doesn't help if FS generates it internally on each load in any case. The CFG file only represents what it was using at the time you closed it down. Trying? This is probably the commonest action FSUIPC is used for, and it has been used in this way now since FS2000 days with no problems. Why did it need "trying"? You most definitely had something else entirely going on there then -- there is absolutely no way FSUIPC touches any of that. There's no difference whatsoever unless you want to use FSUIPC's axis assignments. And no one's asked questions here, until now, so why are they "responding" elsewhere? The Beta versions are provided here for a reason, so I can get testing and feedback. It is no use having that going elsewhere! :-( If you are confused by Axis assignment in FSUIPC, why on Earth use it? Use the assignment in FS. Of course you can assign an axis to the mixture in FS OR in FSUIPC, not both. Either way it would be picked up by the default setting for reverser in FSUIPC's Calibrations. An easier way without going via "mixture" is to use the "direct to FSUIPC calibration" option to assign it directly to the Reverser! Surely, isn't it obvious that FSUIPC's Axis Assignment is an alternative to FS's axis assignment, with more facilities. That's what it says. Why any confusion? It is ANOTHER FACILITY! That is all. Would it be clearer if it were in a different program called "AXISASSIGNMENT"? If so, why, exactly? I am vey very puzzled over this reaction. My general advice is: if you don't understand it you probably don't need it at all, so don't use it. It was added in answer to requests, and I'm sure those who requested it will use it well. Sorry, I've no idea. There's no such thing as "X rotation" in the standard Windows joystick API. It must be a name given to or by DirectInput. However, if the same axis changes the numbers, then, yes, it IS the same axis, by definition! That's how I would find out if I needed to know. The axis calibration facility scans the axes and shows the one with the biggest change at that time. It does this initially and the scan can be repeated by clicking the Rescan button. Please read the documentation about this. It explains at length, with pictures, how to use that tab. If an axis is shown as soon as you select the tab it usually means that axis is changing. If you aren't touching it this would usually indicate some jitter. You might need to use the Ignore button to see the one you want to program next, or check on another. No, it writes the INI with ALL the changes you have made on any or all Tabs, only when you press Ok to exit. At any time before you press Ok you can Cancel, or press Escape, and NONE of the changes you made, at all, during this entire entry to FSUIPC options, will be effected, all of the previous values will be retained. No, never. Only after user Registration, when you are prompted to restart. Why should one be needed at any other time? That would be horrendous! I really cannot imagine what you are doing, but the fact that other things got screwed up is certainly an indication that something else is wrong with your FS installation. I would advise reinstalling FS itself. POVs are not read and cannot be detected by FSUIPC's axis programming. They are only read by the Buutons tab and converted to 8 buttons according to direction. Not just yoke, all and any joystick devices. But you don't have to disable them, I only said you could IF you wanted to do everything through FSUIPC. It might be more efficient, and certainly more flexible that way (what with the aircraft-specific capabilities). But you don't have to. You certainly can mix them. Just take care not to have any specific axes or buttons programmed in two places at the same time. Regards Pete

I don't really know what those controls do -- is that the Virtual Cockpit panning normally associated with a point-of-view hat on a joystick device? If not I would have thought it was the latter you wanted. Not sure what you mean by "exchanging axis", but for all AXIS (and _SET) controls you need to make sure the paramter is written first (to 3114), or at least at the same time in an 8-byte FSUIPC_Write. FSUIPC actually triggers the control itself when it sees you write to 3110. A "tilt" will presumably tilt left or right based on your current viewing axis. Is that correct? Are you expecting it to retain the aircraft's axis instead? If these are viewing controls, which I assume they are, aren't they naturally all relating to the viewer's axis? How are you doing that? I wouldn't think that of the three available AXIS PAN controls one would be siginifcantly different from any other, unless you've just found a bug in FS? I am at a loss to understand the problem in the first place, sorry. Is it some interaction between the three axes that concerns you, or something which looks buggy just with the Tilt one? Regards, Pete

The time is from the start of one message to the start of the next. At these low speeds the message itself can eat into that time enough to make it look faster. Additionally, the time will vary a little -- the FS PC is busy doing other things. The timing is based on a Windows timing system which will fluctuate a little, then, added to that, the serial port driver system is buffering. I cannot control the exact timing synchronously because that could adversely affect FS performance (inducing stutters). If your device fails when messages are too close, increase the time a little to ensure more space. Okay, good. Regards Pete

I've had an exchange with the SB3 author, and he points out that the bug you refer to as already listed is not relevant to this problem. He also says that as far as he is aware the feature is implemented as I understood it, and was tested. However, he or I will try to test it again within the next few days. Nether of us are in a position to do so yet. It may help if you provide all the details to the support team and get it listed as a potential bug. Yes, there are facilities in FSUIPC for sending keystrokes to FS, or rather to the PC in which FSUIPC is running in, which normally amounts to the same thing -- as the program with current focus is the one normally receiving keystrokes. Other programs only manage to by "capturing" them as hot keys. Yes, FSUIPC has never transmitted keystrokes to clients. WideFS simply does not support such a feature, mainly because it is impossible in the keystroke mechanism to direct such events. You forget that there are many systems with multiple PCs in the Network. Instead, FSUIPC and WideFS support a MUCH more powerful and flexible system called "KeySend" which sends an event, called KeySend, with an event number (1-255). You can program FSUIPC to send any of 255 events, either in the Keys or Buttons section. These events go to all Clients. Then, in the WideClient in which you want the event to actually do something, you tell it the event number (1-255) and what you want it to do. this is normally a keystroke, which can then be delivered either to the PC, as in FSUIPC's case, or directly to a specific program's window. This is all described in the WideFS documentation. Did you look? Yes, you can do that in the way I just mentioned. What syntax? From what you say you''ve not even actually looked up the KeySend stuff as I suggested yet. How can you know that your "weak mind" is so weak as not to be able to understand any of it? I don't mind asking specific questions, but you please make an effort, if you want to achieve anything. Regards, Pete

Oh dear. What a shame. I'll write to Joel about it -- seems odd, it isn't a difficult thing, he already did something very similar for the normal PTT to match the original Roger Wilco methods. You can't do that. FSUIPC offers no facilities to send keystrokes directly over a Network, only to FS! As documented in the WideFS document, you must program your button to do a KeySend control in FSUIPC, then match the KeySend numbers against the keystrokes you need to do in WideClient.INI. Please refer to the WideFS documentation. It isn't so easy because different programs need different ways of getting Keystrokes into them. I wouldn't know what works for SB3, you'll have to experiment. WideFS offers several ways. This is why I added the VERY EASY automatic PTT and PVT controls which involve no messing in INI files at all. It would be FAR better to get the PVT facility working as it was intended. if no one has reported this to the SB3 folks then it won't get fixed! Regards, Pete

In FSUIPC/WideFS the implementation of the PVT transmit on/off is IDENTICAL to the implementation of the original PTT except for the same of the specific registered message used. I merely support the message which the author of Squawkbox said he was implementing. I am not a Squawkbox user, I don't have it and wouldn't know what to do with it if I did. So I presume the facility has been implemented correctly in SB and tested by now. But no one has ever let me know one way or the other. Sorry. Your first stop syhould be with SB support to check this. Regards, Pete

Just read the details for offset 02A0. Pete

It was only added in a recent SB3 update. Sounds like you have an older version. To implement it via FSUIPC / WideFS it is exactly as for the PTT one. You do need the recent versions of FSUIPC and WideFS though, of course. If you are using the correct version of SB3 then I'm afraid you need to refer to their support. Pete

Sorry, I don't think Level D use FSUIPC offsets for their switches and values. They do provide a software development kit though, so maybe someone's implemented something. Are you sure GoFlight don't support it? Pete

Sorry, you do really need Simkit support. I've absolutely no idea how they operate their gauges. I thought you calibrated them using software they provide. Also, are you sure it is intended to work with the PMDG aircraft? Test it with the default aircraft first. Maybe it has to be calibrated differently for each aircraft. Regards, Pete