Pete Dowson

Sounds like you need to re-wire the yoke altogether to suit the throttle quadrant. I cannot advise you how to do that -- you probably should have told PFC you wanted to connect it that way when you ordered it. Check with them anyway, perhaps they'll exchange it for you instead. Regards, Pete

Specifically on the PMDG737? You are saying you have spoilers on other aircraft working fine, but not on that particular one? If so you need to contact PMDG support to see what they've done. I thought that they operate the spoilers in the standard manner, using the normal FS controls. If you don't mean specifically that aircraft, but FS in general, you need to go into FS's Options-Controls-Assignments, select the Joystick, scroll down to find the spoilers axis, and do the assignment there. The fact that you use FSUIPC and WideFS isn't really relevant. You do not need either to get FS2004 spoilers working on an axis. This is supported by FS out of the box. By the way, don't try calibrating and testing the spoilers on the ground. The control only works correctly in the air. They'll flicker or move to 100% deployed (i.e. ground detente) if you try to use them on the ground. Regards, Pete

Where are you reading those? That's the maximum possible range allowed for the input. Yes, that would be the default position for the centre. You need to press the "Set" button in FSUIPC (so it changes to "Reset"), THEN use each of the separate buttons in turn to set the values which FSUIPC will use. Currently it sounds like you aren't using FSUIPC. Please check the FSUIPC User Guide. There are step-by-step instructions there. Regards, Pete

Great. Glad you resolved it so easily! No. Those numbers are simply the internal values for controls otherwise assigned in FS's CFG file. If you go to FS's Options-Settings-Assignments you'll see lots of controls you can assign to keystrokes or buttons. Each of those has a name and a number. FSUIPC lists the names in the drop-downs in its Keys and Buttons pages (it gets the names from FS's own CONTROLS.DLL). The numbers are simply how those names are represented internally -- and how FSUIPC records assignments in its INI files. 66532 for instance is the control named "AIRSPEED BUG SELECT" (whatever that is). If you want to assign keystrokes to controls you can do that in FS's Assignments or in FSUIPC. The only difference is that FSUIPC lists all of them, whether useful, working, or not. It simply extracts the list from CONTROLS.DLL. FS only lists those that Microsoft thought you'd find useful. I think GoFlight have their own programming system for assigning controls to their buttons and switches, though, again, they seem to be rather selective. Happy New Year, Pete

Well, it was -- till I visited some real home-made cockpits in California earlier this year. Now this one feels like what it looks like, a bunch of computer bits on a desk. I'm saving up now for a PFC Jet Cockpit (http://www.flypfc.com). I need one 'ready-made' as my only 'practical' skill is programming. Ahanother "real" cockpit builder! At least when you've finished it will feel like a cockpit, not a collection of computer bits! :) Happy New Year! Pete

These are both very old. The last completely free versions (not suitable for FS2004) were 2.975 and 5.5 respectively. Since you can't use those versions on FS2004 at all (they won't even run!), if you are getting similar problems on FS2002 and FS2004 they are evidently nothing to do with my modules, but let's see ... Your "analogues" are joysticks and throttles? Calibrate them in Windows and assign them correctly in the Options-Settings-Assignments section of FS. This is the same sort of process as it was in FS2000. But you may want to add "stick_sensitivity_mode=0" to the [Controls] section of the FS CFG file. This makes FS2002 and FS2004 treat the analogue inputs more like they were in FS2000. I don't know how that works -- FS2000 always listed the joystick assignments, nice and cleanly with proper Joystick identifications. Since FS2002 FS has used Direct Input (part of DirectX) for joysticks, and this, in my opinion, messed things up somewhat. The Joysticks are then identified by complex "GUID" strings of numbers and letters. No, but FSUIPC and WideFS are absolutely nothing to do with this -- you need to get FS to recognise your joysticks with no add-ons or add-ins anyway. Why do you think my modules are involved? I do note you listed "FS Comm" and "Epic USB Epicenter" amongst your add-ons. Is FS Comm an EPIC driver for FS, and does it use FSUIPC or does it do things differently? It isn't one of my programs -- in fact I note that you don't use any of my EPIC related programs anyway. Perhaps your problems are related to EPIC? Do you have any analogues connected through that, and are they being mapped to normal joystick controls or processed by your own programming in EPL? If the former then you still need the Windows calibrations and FS assignments correctly sorted. If the latter then it sounds like a question for FS Comm. Certainly, if FS comm uses FSUIPC then for FS2004 you'd need FSUIPC 3, not 2. If it doesn't, then perhaps you need an FS2002 version for FS2002 and an FS2004 version for FS2004. Certainly that isn't true for EPICINFO, which is primarily an OUTPUT module -- it only provided some POV/Soft axis inputs AFTER FS2002 came out, precisely because proper radio control was impossible using POVs through Direct Input -- POVs were used in FS2000 quite happily, as any value could be used. Direct Input destroyed that, only "proper" POV values were accepted. That's why I added such things to EPICINFO. It has NEVER had any axis type input facilities, they are always between EPIC and Windows to sort out. I have no idea what "FS COMM" does. Sorry. Regards, Pete

No, I run full-screen as one display. The resolution I currently use is 2400 x 600 but it will go up to whatever you like. My displays will allow 3840 x 1024. But since I have no panel display on it, the difference for an outside scenery view isn't so noticeable so I reduce the resolution and enjoy a better frame rate. The display is running a 0.50x Zoom, which suits me. some Parhelia users prefer 0.31x but I find that rather unrealistically wide. I prefer the view to be a genuine looking wide front view, not a wraparound cockpit, but you could use it at 0.31x which wuold give what you suggest. The Parhelia certainly is not a fast card compared with the current crop of ATI and nVidia cards, so even driving one screen it isn't a screamer. But at present it's the only card which does what I want. I actually use two of them -- one is in a second PC runs my Project Magenta instrumentations -- Captain's ND/PFD, EICAS, First Officer PFD/ND on the three screens. I have everything in FS turned up to max, plus Ultimate Traffic running at 100% and with detailed airports like UK2000 Manchester. My FS Frame Rate Limiter is set at 20 fps, and most of the time the Frame Rate is hitting 19.9 -- never dropping below 10. That's fine for me. If it ever dropped below 10 I'd reduce some of the settings. This is on a 3.2GHz P4, mind. I don't run any instruments on the FS PC. I'm not sure what sort of performance you'd get then. I suspect you'd need to reduce a few settings. And since you'd need to run at a higher resolution (for the sake of the instruments) it doesn't sound so attractive. I would really only recommend it for the widescreen "wraparound" views, not for supporting three independent screens. To do what you now suggest I would rather recommend a fast ATI or nVidia AGP card for the two views and a possibly slower PCI card for the instruments. Regards, Pete

Yes, for some of the facilities -- the same things are not provided on both. Please see the examples and descriptions in the user guide. By the way, the current version is 3.135. Regards, Pete

WidevieW links multiple FS installations. If you are displaying scenery you really need the full FS installation on each such PC, and ideally they all need to have the same power -- otherwise the slower ones will be pretty jerky. I use a Parhelia card with three monitors on one PC. With most current video cards you can have two monitors. I don't think WidevieW is out yet for FS2004, but it is on its way. As far as the instruments are concerned, if you mean FS cockpits then, again, that's another full FS installation. Otherwise you are looking at external instrumentation systems like Project Magenta, or possibly FreeFD. Those will operate through WideFS with no addition FS installation. Regards, Pete

Not at present. The assorted links between two FS installations always have one of them as Master and the other Observer (WidevieW and MP in observer mode), or flying different aircraft (normal multiplayer). You could conceivably use the master/observer type link and have some programming to transmit the controls from one PC to the other, but I suspect the latency would make it a bit erratic. A better alternative would be to swap the master/observer roles when control is passed from one pilot to the other, but then you haven't really got dual controls as such. Regards, Pete

FSUIPC has facilities for up to 4 each of aileron, elevator, rudder, throttle, left and right brakes. Please see the section entitled "Multiple Joysticks" in the Advanced Users Guide supplied in the FSUIPC.ZIP package. You don't really get "independent" control -- that would be impossible, as there's only one set of ailerons, elevators, and so on to control, and why would one pilot want to climb/bank left whilst the other descended/banked right? :) FSUIPC takes the maximum deflection of each of the 4 connected controls in each case, so it is best if the non-flying pilot just left them alone. Regards, Pete

Sorry, all FSUIPC can do is pass on the weather settings to FS2004. There's nothing it will be doing to either change or fix winds. There's probably some settings in AS2004 -- I think most folks get too many nasty wind changes and this may possibly be part of the attempted fix for those. The wind shifts seem to be a problem inside FS2004 as I can get them with all weather sources, including FS's own weather downloads. You should be able to get some help in the AS2004 support areas/forums, I expect it's a matter of getting some settings right. Regards, Pete

Hmmm. I can't understand that. And doesn't it conflict with your other report about it crashing? It sounds like your parameter may be in the wrong part of the INI file. There's actually no number "29" anywhere in the program EXCEPT to define the default for that particular parameter. Whatever number is substituted is used to allocate the memory space for the checkpoint data. Looking through the code (which is many years old now and getting difficult for me to remember!) it looks like the only likely reason for a crash with too many waypoints would be the actual size of the output files. Currently it just pre-allocates rather more space than any (originally possibly) valid result would need. But an output requirement more than double that would possibly crash it. Additional waypoints a few above the 29 shouldn't, though. I'll need to do tests, next week. Whatever your problem is, it doesn't look a trivial job I'm afraid. The code isn't even completely compatible with the compiler I'm using now, so there's going to have to be a bit of a conversion job first. Pete

Hmmm. There's a lot of local climatological infomation built in then? I certainly didn't know that. How would it know to improve the weather or worsen it? It can't be at random, surely, as the supplied themes seem to change in a specific described direction. Yes, but if these are merely static weather sets, as WX files would be, what is the difference, the advantage of themes over any savesd set of FLT+WX files? Regards, Pete

Odd, most seem to manage okay. That system is about 6 years old now and the documentation has got better, not worse (or at least that's what I hoped and tried for). What does "holds the key" mean? Do you just want to use "Push To Talk"? If so, with Roger Wilco you don't need any key. The special keywords "RWon" and "RWoff" are provided, as explained in the documentation. If you want to use WideServer, you need to work out the button number to put there in place of ?????. But it is far easier to do in FSUIPC's Button's page. Check the FSUIPC User Guide, assign your button (which you only have to press for FSUIPC to identify) to the KeySend control, and set it with parameter 1 for press, 2 for release (for example). If all you want is Push To Talk in RW, assign RWon to the KeySend number allocated to the press (1 say) and RWoff to the KeySend number allocated to release (2 say). i.e KeySend1=RWon KeySend2=RWoff I'm not going to repeat the rest of the documentation here, but you should really have read enough to see that Roger Wilco PTT is treated specially, in both WideFS and FSUIPC documentation. These are the codes used in FSUIPC's INI file. Why do you want to know those? Please DO NOT BOTHER TRYING TO EDIT FSUIPC's INI file! I have gone to great lengths to make all that stuff as easy as possible in the Options screen. Just press ALT M F, find the Buttons page, and read the FSUIPC User Guide section on this (NOT the "Advanced" Users Guide, which is for Advanced users! :) ). Sorry. I do try my best with the documentation, which seems to work for most. I really do hope it is not really as complex as you make out -- you seem to have actually gone well out of your way to get so confused! I'm not sure how to improve it beyond explaining how to do things and giving examples as I do. Please read the easier stuff before the advanced stuff. To summarise: use FSUIPC's Buttons page. Do NOT even look in the FSUIPC.INI or WideServer.INI files. There is no need. It is all quite simple if you don't want to do clever things. Regards, Pete

Is there no limit in RC now? I didn't know that! No one tells me these things. I haven't got time this week -- I am back to programming work next week,, and I'll look then. I really wouln't be that surprised if FStarRC didn't allocate enough memory for as many waypoints. Regards, Pete

No, FSUIPC isn't contributing to that. The only reason for the different timing is the slight difference in memory arrangements and time processing messages. It sounds like something related to video drivers and interaction with DX9. I use a Parhelia too, but with no panel displayed, only scenery. The latest drivers (1.05 something) seem pretty reliable. But possibly some of the Display options in FS need changing? Sorry, I've really got no other ideas at present. Experimentation is the key I fear. Regards, Pete

You can try writing to anything, to see if it does anything, but I don't think you can change the aircraft's airspeed or grpondspeed like that -- the speed is a result of thrust and acceleration and is dynamically re-calculated each frame. You influence it by increasing thrust, or diving. You may be able to make a temporary effect by writing to some of the accelerations. I think this is how the catapult and braking applications work. Regards, Pete

I don't recall there being any of that when I used the beta theme generator, but not sure. What's the point of themes if they are just static weather? Isn't that the same as defining static weather? I though themes had moving fronts, developing storms, stuff like that. A sort of "weather script". If not, what is the point of them? It baffles me even further why you should need to develop weather in one form and convert it to another, especially if there's no programmatic element to it, like development over time. Colour me confused! :o Best Regards & Happy New Year! Pete

Possibly -- IPX/SPX should be okay with a 100% Win98SE set up. If you are using WinXP or WinMe I'd be very suspicious of IPX/SPX in any case. Smoothness shouldn't be a problem with TCP/IP, unless you have too much of the server processing time being hogged by FS, not allowing the (certainly less efficient) TCP/IP stuff to operate. Try reducing the FS frame rate limiter more. I hope you find the answer. Regards, Pete

To be honest I don't know anything about themes and scenarios. I thought they used rather different data internally than straight-forward WX files. The latter just contain a list of weather settings for Global and each of any number of weather stations by ICAO id. I thought the scenarios included data about how things are to develop. Is this not the case? When you've programmed a scenerio, where do you put it and how do you load it? Is this all via the Themes list in the ALT W W dialogue? :D No -- wrong scale anyway. my model railway is N-gauge (2mm to the foot), so the hoverfly would look monstrous. Anyway, while I learn to fly the thing properly I need lots of relatively unobstructed space! :lol: Best, Pete

If that is used as the limit for the process call then it is too big -- neither WideFS nor FSUIPC will handle that correctly. 32512 is correct (hex 7F00). the value 65568 is rather peculiar in any case, being 33 more than the largest possible 16-bit number. Okay. I hope it is easy to resolve. I look forward to hearing from you when it is! In case it helps, this the is active statement in the C code: m_pNext = m_pView; It actually does this BEFORE the call to FSUIPC, but after marking the end of the data with a 32-bit zero word, thus: ZeroMemory(m_pNext, 4); // Terminator Because it also then uses the same pointer to process the returns from READs, it resets the pointer to the beginning of the buffer again, just before the exit: m_pNext = m_pView; *pdwResult = FSUIPC_ERR_OK; return TRUE; Maybe this apparently redundant, but certainly not, repetition is omitted in the C# version? Incidentally, even this stuff isn't really my code. FSUIPC uses the original interface from FS5IPC/FS6IPC, and the code was written by Adam Szofran (it isn't my style, actually -- mine is rather more obscure! :) ). Regards, Pete

I'm sorry, but neither of those is a language I'm familiar with. Can you contact the author for clarification? It sounds like the pointer to the next free position in the memory file map is not being reset in whatever is the equivalent to the FSUIPC_Process call. I only programmed the C library code, of which the source is provided. I know that works. Also the Delphi package must work, as that is used in FSInterrogate. The VB stuff must work as most of the FSUIPC utilities folks write use that, so it is sounding now like there's a bug in the C# code. The FSUIPC/WideFS interface doesn't support block sizes larger than around 30-31k including all the red tape that is added. Even if your local C# code is changed to accept such, the Process call will go wrong in WideFS or FSUIPC -- I'm not sure what you'd get, probably just most of the block ignored. Where do you get this "default" buffer size from? In all my code the maximum block for FSUIPC_Porcess is defined by #define MAX_SIZE 0x7F00 // Largest data (kept below 32k to avoid // any possible 16-bit sign problems) (see the IPCuser.c file original Lib_source). There is no "default 64k buffer" in anything I've provided. For each individual read/write a number of bytes of red tape are added. See the header files for that. No necessarily. It may be an error in the C# code provided in the SDK. I'm afraid I just provide whatever is provided for me. If you understand C# please check it and let me know. You could compare it with known working code, like the C, VB and Delphi versions. Regards, Pete

Oh, good -- glad you found it! Did you see this via FSUIPC's logging? Regards, Pete