Pete Dowson

Please, to start with, don't try to use FSUIPC to calibrate axes until they are working reasonably well in FS2004 as is. All FSUIPC is doing is taking the results of the FS assignments and calibrations and scalings and allowing you to define the end points and centre zones more precisely. It is dealing not with the Joystick but with values inside FS, the final values just before they are passed to the simulation engine. This means that if they are in a mess and not working properly before you start using FSUIPC, all you can do is make things worse. You need to start by ensuring good calibration in Windows itself, in Game Controllers. Also you might want to add the line "stick_sensitivity_mode=0" to the [Controls] section of your FS9.CFG. Maybe you did this for FS2002 and forgot? It makes the axis inputs linear instead of time-based. THEN load up FS. Do this without the FSUIPC calibrations -- delete the Joysticks section in the FSUIPC.INI file if you've not used it for any of the others -- otherwise go to the appropriate pages in FSUIPC options after FS is loaded and press the relevant "Reset" buttons. In FS, assign the axes to whatever functions you want to use them for, and ensure the sensitivity is high and the null zone low (otherwise you are immediately losing a lot of the input detail). Also make sure there are no other assignments to the same functions. If you have multiple joystick connections, go through the list of axes for each joystick and delete any conflicting assignments. Now try them in FS. If they more or less do what you want, by all means refine them in FSUIPC. If not, there's some problem which is really outside my field of knowledge. You want to find the forum in which Bob "Sticky" Church visits -- he's a real joystick expert! Regards, Pete

What is "filled in by FS" is the pointer in your ImportTable to each imported Module's "Linkage" structure. And, yes, the poniters are exactly similar to the Init/Deinit pair in all of the Linkage structures -- but it isn't those which are filled in by FS. It is almost universally, though of course it doesn't have to be programmed that way. Any, I've just looked them up and the calls for Chain and Unchain are at offsets off the base EXE's Linkage of 0x438 and 0x43C respectively. This is in FS2004 only. That should make it easy for you to spot them. I am pretty sure the closest you'll get to a frame rate call is chain 0x13, though in FS2004 that seems to go twice as fast when the flight mode display is showing (Shift+Z). Very odd. I had to take special steps to deal with that. All of which are, if anything, easier to do without impacting FS performance from an external program, whether on the same PC as FS or on a separate PC interfacing through WideFS. Running inside FS means taking a great deal more care about how you organise the program and perform the tasks you are doing. Instead of having Windows timeslice for you, you are now responsible. It is MUCH more difficult not to impact FS performance from a DLL or Gauge than from an external program, where Windows is helping considerably. Much of the 5+ near full-time years put into FSUIPC and WideServer has been spent on making sure they have minimal impact. If you run FS on an Intel P4 with "hyperthreading", FS only appears to run in one of the two virtual processors. You can add a few ancillary programs running in the other without any noticeable impact. Of course, it is still best to offload all your joystick, serial and parallel processing activity to another PC if possible. Regards, Pete

Yes, it looks like there was a case of misunderstanding somewhere down the line. I'm sure Damian will sort it out. I know his support efforts are excellent. Please let me know after it is all resolved. Regards, Pete

You could try an FSUIPC_Write call, instead of a Read? Pete

No, sorry. None of the user options are. The free installation is just an interface for other programs, just as its predecessor, FS6IPC, was. Regards, Pete

It's a little easier than that, as there will be another, for the same module function, to an adjacent address in FS's EXE Linkage table, in the DLL's "De-init" too. Choose a DLL with small Initi and Deinit routines and it can be pretty quick. Well, no, because I prefer to encourage the use of external EXE programs. One of the best applications for FS is, for me, completely ruined by being an FS DLL rather than an external program which I can run on a WideFS client PC -- this is FSNavigator. Shame. Regards, Pete

Okay, I can reproduce that here. Very strange. I will fix this and re-test here. Are you in desperate need? I am away from Friday for 8 days (visiting my son in Spain), but I am hoping to make a new release (with lots of small improvements) aound the end of the month, or perhaps early October. If you are in dire need I could send an interim fix, but some things may not be quite finished and there will be no new documentation, yet. Sorry for the inconvenience, either way. Odd that no one has spotted this problem and reported it before! Regards, Pete

Yes, as described in the WideFS documentation in fact. Not at all! They both send and receive it! WideClient provides a complete remote FSUIPC interface. Where do you get the impression that they cannot send data from? There are many cockpits built around programs like Project Magenta, for example, where not only all the instrumentation is held on Client PCs, but the FMS and main autopilot (MCP) controlling flight. TaKe a look sometime at the Project Magenta site. I've run both ActiveSky and FSMeteo on a client PC, under WideClient, for many years -- in fact right back to FS2000 days in the case of FSMeteo. Regards, Pete

All FS keyboard controls can be changed anyway, by the user, in Options-Controls-Assignments, so it is always hazardous using specific keys. You should always use the controls you want, instead. Airbrakes == speedbrakes == spoilers. Spoiler controls Spoilers_On, Spoilers_Off and Spoilers_Toggle. The '/' key is normally assigned (in FS Options-Controls-Assignments) to Spoilers Toggle. You can either send FS the control, directly (as a WM_COMMAND) or via offset 3110 in FSUIPC (which has the advantage of also working via WideFS), or, via FSUIPC, you can control the spoiler setting directly in offset 0BD0. Regards, Pete

Hmmm. How odd. Okay, I'll set something up here and see if I can reproduce this. It is odd, because all the client button pressing does is set a flag bit in FSUIPC offsets when the button is pressed, and clears it when it is released, so it should look "pressed" all the time it really is pressed. If you program a different action for the Release, does that happen correctly, when released, or immediately, at the same time as the press? I'm a bit tied up this morning, but I'll get to this later today, maybe tonight. Regards, Pete

Sorry, I can't help since I don't know if your problem is to do with lack of engines being synchronised. Are you using two throttle levers? If not, then it can't be synchronisation. If you are, then increase the left throttle slightly, compared to the right. You can check whether thrust is equal on both by reading the N1 or EPR figures on the cockpit engine instruments in any case. It sounds to me more likely a rudder which isn't centred. If you are using pedals try re-calibrating and give them a bigger "null zone" (this can be done in FS, it's just more precise in FSUIPC ). It could be rudder trim -- find the rudder trim in the cockpit (sorry, I don't know the aircraft myself) and adjust that. Regards, Pete

No, I think all "_SET" controls are axes. The only difference here is that THROTTLE_SET is the original FS98/FS2000 control whilst the AXIS_THROTTLE_SET was introduced in FS2002 onwards. There's a lot of duplication with slight variations. Just look at all the ways of setting the ADF frequency for instance. You can check my FS2000 and FS2002 lists (both also still available) to see some history. In fact the FS2000 one is worth having as there's much more explanation in there, most of it still valid. Sometimes they forget to support an old ones, sometimes they add new ones to the list but don't get time to put the code in to implement them. So it's a bit of pot luck when you try things. Where there are alternatives like this, the joysticks page in FSUIPC accepts them all but converts them to one -- though whether it's the newer or the older one depends on whatever side effects there may be, if any. No, the parameter facility is there so you CAN apply fixed "SET" values for axis commands if you like. The example in my documentation, for setting STD pressure, for instance, uses an "axis" command with a fixed value. Also, as I found out very recently, some of the button controls MAY take a parameter -- someone said something about some of the INC/DEC controls using the parameter as the increment (in place of 1 or -1) if it's non-zero. But I couldn't get that to work on ones I tried. Mind you, I haven't got that sort of patience! Regards, Pete

"POV-Views"? I don't list such a control. Can you be more explicit please? No, it will be a "POV" (point-of-view) control, neither a button nor an axis as far as Windows or FS is concerned. It returns an angle between 0 and 360 degrees. An 8-way hat (which is as much as FS or FSUIPC copes with) supplies angles at 45 degree intervals. FSUIPC converts those into buttons 32-39. POVs are treated as above both in WideFS, for Clients, and in FSUIPC. No difference. FSUIPC doesn't handle Axes at all at present, not just not for clients. It is a big job, bypassing all of the FS axis assignment systems and providing all the options which would be needed. It's been on my list for a couple of years. The controls you've assigned here are "PAN LEFT" and "PAN RIGHT". In cockpit mode those actually select VIEW_LEFT and VIEW_RIGHT, and repeating those will obviously not make any difference. If you want them to actually pan around you have to be in Virtual cockpit mode. However, there is a "fix" if that's what you really want to do in 2D cockpit mode -- it isn't defaulted because it appears very odd having the cockpit stationary whilst the scenery slides past in front of you. To apply the fix add pan_in_cockpit_mode=1 to the [Controls] section of the FS9.CFG file. I think this is one of the hints in the FS2004 FAQ somewhere in SimFlight (ref. FS2004 Forum). Regards, Pete

It cannot and never will be able to. WidClient is a single server - multiple client system. The server runs FS, the clients run ancillary programs. It can run whatever it is suitable for running. But if you are not running FS on it then it cannot run WideServer (which is an FS DLL, not a separate program, nor WidevieW (ditto). It is WidevieW's job to synchronise everything between the two FS machines, that is what it is for. I don't know how it is dealing with the weather in FS2004 -- in FS2000 and FS2002 it used the advanced weather interface, which only works with "global" weather. It probably does the same now -- i.e. reads the current weather from one and sends it to the other as "global" weather. Recent versions of ActiveSky, of course, deal with local weather stations. However, provided WidevieW transfers the weather regularly, there shouldn't be any big discrepancy. If you are thinking that clouds formations and edges etc can be synchronised, lined up as it were, then that wouldn't happen even if what you wanted was possible. There's really no way to synchronise cloud graphics, the same as there's no way to synchronize AI traffic. Hmmm. I seewhat an odd use of WidevieW. Sorry, I thought you'd use it for multiple views. Wouldn't your setup work as well, if not better, making your secondary system the one and only FS machine and just add a PCI graphics card for the panel? If not, then what you really want is WideServer on the machine showing the graphics, and send it the weather, then somehow get WidevieW to transfer weather the other way. This sort of thing was possible in the original, full-blooded WidevieW. It could be run bi-directionally with configured data. As the documentation clearly says, you can use IPX/SPX or TCP/IP. There's even a table in there showing pros and cons. Regards, Pete

I'm not certain about what synchronises with what, but the callbacks are by adding procedures in your code to one or more "chains". There are two FS routines --- Chain and Unchain, both of which used to be in CHAIN.DLL but which are now merged into the base EXE. The best way to find out what these procedures are and how to use them is to do what I did -- disassemble one of the shorter modules. You must already know that, like Gauges, each module has an INIT and a DEINIT call from FS, listed in its linkage. (If you don't know this much, best first to write some gauges and see how they operate, examine the code.) Most all modules register one or more procedures in specific Chains in their "Init" routine, and Unchain them in their "Deinit" routine. You will be able to spot those quite easily after finding the Initi and Deinit routines via the Linkage export. Those calls work fine IF there's a panel loaded, but are likely to crash FS if used before FS is "ready to fly" (fully loaded a panel), or is in the process of reloading one as part of loading an aircraft. You might find the FSUIPC offset 3364 and 3365 flags useful here, but it is difficult to make things truly crash-proof if you make gauge calls from a DLL. The 0x13 value for gauges isn't used in the ImportTable -- obviously, not all gauges can fit in one import entry in any case. Worse, I think some add-in DLLs used the same ID, presumably because they used the Panels SDK as a starting point. You can determine the correct IDs for each official FS DLL by looking at the declaration of their ID in their Linkage. Only "Linkage" and "ImportTable" are exported in any case by DLs and Gauges, so you should have no trouble sussing out the structures -- but get the official panels SDK for it to be revealed fairly clearly in any case. Bear in mind that once you set off down this path you will have a program which, like FSUIPC and my other modules, will need checking and updating, perhaps extensively, for each new version of FS. Regards, Pete

Hmmm. Actually, for aircraft specific entries in the Buttons and Keys sections, I think they will get loaded if you edit them for a different aircraft, then change to that aircraft (or just change and return). This is because there's no limit on the number of different aircraft I may have to cater for, and I don't know their names in any case before they are loaded. So, those sections are read when needed. I will add the facility to reload the general Buttons and Keys sections to my list of things to do. Rather than have a special button/key/menu option to do this, though, I think I would reload it when the aircraft is changed/reloaded (even if same aircraft). That should be easy enough. Alternatively, just going to the Keys or Buttons pages in the options and "okaying" out could be made to do it. What do you think? I don't want to apply this to any of the other sections in the INI file, though. Much too dangerous -- I would have to recheck too much of my coding. The buttons and keys stuff is okay because it is all concentrated in two specific modules, nicely self-contained really. Regards, Pete

Great! Good flying! Pete

To calibrate the reverser? That is not programming, nor advanced! It is enumerated step by step in the User manual. Which particular step don't you understand? There is really no point in me re-printing sections of the manual here! Why on Earth are you thinking you have to go anywhere near any INI file? The options are provided in a DIALOGUE, on screen, when you are running FS. Install FSUIPC, run FS, select FSUIPC (Modules Menu, FSUIPC, or ALT M F), select the Joysticks tab, and so onthere are even pictures of the dialogues in the User manual! What are you missing here? The instructions for calibration are in the joysticks section of the user guide, and are enumerated. Please skim through the manual and find the joysticks section, then read the little bit on calibration and follow the instructions, one line at a time. If there is a line you don't understand, please tell me what and why. This part of the documentation has stood the test of time now for three releases of FS -- FS2000, FS2002 and already over a year of FS2004. I don't mind trying to improve it, but I need to know WHY you don't understand it? And why you are even thinking about editing any INI files! It looks like I may be out all day tomorrow and it is 01:25 hrs here now, so there may be a delay in any further replies. Regards, Pete

Of course. What an odd question! There's no realistic practical limit on the number of clients -- there is a built-in limit of 256, but I really wouldn't expect anyone to get anywhere near that number (I think problems of performance and timeouts would start occurring long before then). Most Project Magenta users will have several clients -- I myself normally have 4 client PCs for my FS server PC. Regards, Pete

What makes you think there will be any such offsets? Many add-on panels are programmed with their own data in their own code and with no access for anyone else. I really cannot hack into every add-on to expose their particular variables. In fact, some of the PMDG stuff does use FSUIPC offsets, but these are private to PMDG and have not been published. I understand someone has hacked some of them, but I'm afraid I am not at liberty to help further in this matter as it is not the policy of PMDG to allow access to these things. Please write your objections and needs to PMDG. I would hope that with enough user demands they may perhaps one day relent and publish their SDK. Regards, Pete

For the spoiler you don't need FSUIPC. Just go into FS Options-Controls-Assignments, select Joystick axes, and reassign your prop axis as a spoiler. For reverse thrust on the mixture control, you simply go to FSUIPC's Joysticks page, find the part with the reverser on it, and calibrate it there (press the "Set" button and simply follow the numbered steps for calibration in the User Guide). Is the user documentation really that bad? :( Regards, Pete

No. One of the parameters you have to set in WideClient is the name of the Server. You can't have two Servers with the same name. Regards, Pete

It occurred to me that I may be able to help. I still have an FS2002 installation, so if I had the utility that Nav3 uses to make its database I could make you one. Of course, it will relate to the default FS2002 scenery rather than FS2004, but most things will be the same and it would certainly be better than nothing. Regards, Pete

Okay -- I assume this is built into the program or in the Version Information, to save user's having to enter it manually. the manual method was provided only for "dead" software and seems to confuse folks. Yes, that's okay. User registrations are valid for any 3.xxx version. When you install the "latest version" do you check that the one they have is not later? Otherwise you should make that optional. Regards, Pete

This is all a function of the seller. Was this from SimMarket? They say, on their site, that you get notification within 24 hours, and if not to report it via their problem button/report system (is it a "problem ticket"?). Please check the site on this, as I do not know all the details. It may be that the email was sent but has gone astray. If the email address was in error this will happen, of course, but there may be other reasons. If you go to http://www.simmarket.com and open your account there you may find your key that way, if it has been generated. Regards, Pete