[PFC.dll]

I bought the fantastic Jetliner Console from PFC, but when I openend the PFC-menue I found only the 767 PIC preprogrammend.

That's because I managed to hack into their programming interface (which they provided but then did not publish for reasons best known to themselves), no other reason.

So,because I am flying the DF 737 (like many other Simmer) I would highly appreciate to get also this upperpanel working with the console !

If it can be controlled by keystrokes you can program that yourself. There is no programmable interface provided by the DF folks, so there's no other way possible. Using PFC.DLL in combination with FSUIPC Button programming facilities you can actually re-program almost every switch, knob and button on the console. But if there's no way to control the panel other than using the mouse, you are stuck. you could try the freeware program "key2mouse" or whatever it is called. Sorry, I don't have a URL.

Unfortuantely the APU,De-Ice andsome light-switches do not communicate !

If the DF folks don't use the standard FS anti-ice controls for their de-ice, then that is not surprising. The standard FS light switches are already well catered for in the PFC driver, I cannot support others -- but you can program switches if there are keyboard codes for them. There's no APU simulated in FS.

Do you see a chance to fix that problem ?

No. I do not mind adding code pecially for some of the more popular cockpits, if the designers provide a programming interface and tell me about it, but most do not. There is no way I can hack into the innards of every gauge and special panel out there. Life is too short. Sorry.

>> When I link the APU+ to the APU-switch of the console within the menu <<

What APU switch of the console? Sorry, you've lost me. How are you linking them?

Regards,

Pete

[WideFSClient waiting for connection!]

Of course if somebody is using Win2000 pro and have any thing to say, please come forward!

I am using Win2000Pro on one PC, WinXP on two others and Win98SE on two others. WideFS 5.41 is running using TCP/IP with never any problems. There are no problems if your Network is working. I have absolutely no other protocol enabled on the Network. You need to get the network working well, then it is easy.

Regards,

Pete

[Spurious "Windows Installer" window appearing ...]

What I do not get is that you did not do anything but copy 2 files. How can this action invoke the windows installer ?

No idea. I don't even know what it is or why. I assumed it was a window in your EXE. After all, that is all I'm executing.

I assume you have restarted Win2000 . Any other installations via the Windows installer you might have done recently ?

As far as I know I have never used it. I'd never heard of it until what I thought was your Window told me it was it.

idea: might it be you have an update pending on some operating system dll, ocx?

You use any of those? I am not getting this window any other time except in TrafficBoard, and, as I say, it is obviously part of that process as when I force close it, so does TrafficBoard.

I wouldn't worry too much about it. It stays behing TrafficBoard when I maximise it, and closes when I close TrafficBaoard, so it does no harm. Just seems silly, is all!

Pete

[Spurious "Windows Installer" window appearing ...]

I haven't got a clue what the Windows Installer wants to do. There hava been no installation changes on the upgrade since BETA testing.

Although you sent me Betas, I was away a week then sick till a couple of days ago, so I never tried them.

Did you use the upgrade kit or the full install driven by InstallShield ?

Just the upgrade. I downloaded it and copied the EXE and CHM files over the top of my old installation (which was an early Beta where you were first doing the ground traffic, if you remember).

Everything seems to work fine, but this Windows Installer window is always there and cannot be shut down -- if I force it to close by Task Manager, then TrafficBoard closes too, so it seems to be part of the same process.

In fact you might have opened a workspace from 1.1 which did not carry RefNums. Rebuilding & reactivating the workspace will build the links as well as scanning the active Traffic.BGL.

Yes, that is correct. It all worked fine after that. Just took me by surprise, is all. :)

Regards,

Pete

[Widefs error on XP pro.]

330 Client socket() failed [Error=10047] Address family not supported by protocol family

This is ALWAYS because the protocol you are asking WideFS to use is not installed. At least I've never yet seem such an error which wasn't because of this in the 6 years WideFS has been around!

I just check the tcp/ip addrs., and the TcpIP=yes option in both PC's without results.

May you should use the "UseTCPIP=Yes" parameter? There is no "TCPIP=Yes" parameter.

Regards,

Pete

[Pb to write variables with fuipc]

I don't understand well which variables are in writing mode and which are in read only state in the documentation of fuipc.

Most are both, but FS won't necessarily respond to them all being written. Things used to be a lot clearer in FS98, but times change. Use FSInterrogate and experiment, that's the way to find out.

I wish replay data of real flights in FS2002. The latitude, longitude, heading, altitude, roll and pitch are OK but not many other variables.

Actually heading roll and pitch are normally only settable in paude or slew mode. Certail Lat/Lon/Alt are always settable. Engine/Sim derived values are calculated and overwritten constantly by the simulation engine, so don't expect to be able to change stuff like RPM, N1, N2 -- except maybe in slew mode where it means nothing.

For example, write the IAS (address 0x02BC) does not have any effect on the gauge which remains to zero.

IAS is a derived value. If the aircraft is at rest it has to be accelerated to achieve a speed.

Is it possible to program all the variables with fuipc or the majority are read only ? In other words, is it possible to replay a real flight (with many parameters recorded in the crash recorder) in FS2002?

In slew mode, or with the simulator actually stopped some other way (such as setting the Sim Rate to 0) you should be able to affect most things, but whether you can do everything is a matter of trial and error. Most of this changed between FS98 and FS2000 when the sim engine was rewritten to be completely dynamic.

Regards,

Pete

[FSUIPC 2.9.7.5]

it says

Version 2.974, made 14th March 2003

Sorry about all that. It was going to be 2.974 and I rounded it up before release. Seems like I changed one part but not the other. Thats the trouble with haste. And I've not been well. Don't worry about it. Just assume 2.975 == 2.974!

Regards,

Pete

[Spurious "Windows Installer" window appearing ...]

Hi Josef,

I've just installed your Version 2 update to Trafficboard, and now, every time I run it, I'm getting a "Windows Installer" window also appearing. this simply says "Preparing to install ..." but does nothing. If I use Win2000's task manager to close it, this closes TrafficBoard down too.

Otherwise it seems to work quite well, except that I get a pink window coming up telling me that the wrokspace is not linked to a Traffic BGL -- how did that happen? Do I have to scan again? As you know, I use TrafficBoard over a Network, but I usually have to do the scan on the FS PC then copy stuff over, because you use the paths from the SCENERY.CFG which are, of course, local to the FS PC.

Regards,

Pete

[new module for FS2k2]

where can I find any info about developing own module (.ddl) for Flight Simulator?

Assuming you mean a .dll for the Modules folder, there is no published information. Why would you want to do such a thing? It is a lot of work and really unnecessary -- what do you hope to gain?

GAUges are DLLs. the only difference is that they are loaded by the PANELS system instead of loaded initially by the FS main code. Learn to write Gauges first, then you are half-way there. But ask yourself what you want to be doing running inside FS's process? What is this needed for? Is the FSUIPC interface, especially extended across Networks via WideFS, not sufficient for your needs?

Regards,

Pete

[Access to 767PIC variables]

Could you give me a little hint of how would the hacking be done?

Er, no, sorry. I learned programming from the hardware up, starting in 1963. Getting into other folks' code without their help and their source first means learning assembler code, then using a disassembler such as IDA Pro (which I use) and a debugger such of Soft-Ice (which I also use, at least a very old version of -- can't afford updates to this expensive item!).

Does the same DLL (gauges are in fact DLL's) always have the same memory area in use?

It is not likely, at least for gauges, no.

If not how could I make the gauge always find the right memory address to be used?

You can get the memory address from Windows. Use LoadLibrary. In the 32-bit windows world the handle that returns is actually the base address of the DLL.

Anyway the memory area of the gauge is pretty large so I would have to scan through it somehow to find the right memory address which is used to store the MCP's altitude value.

If indeed it is stored withon that space. It may allocate memory and store it there, in heap space. You'd need to find a pointer to it then instead. It takes a lot of work analysing disassembled code. I have to do this sort of stuff all the time, to make FSUIPC work inside FS, and it takes many many hours -- months and months for complex things like the FS weather.

Regards,

Pete

[Access to 767PIC variables]

Sorry, you can see I'm new at this forum stuff. I seem to have managed, somehow, to have replaced your original message with my reply! I hope it is still useful, but it does make this thread look a bit silly now!

Regards,

Pete

[WideFSClient waiting for connection!]

The answer is on the documentation

I assume this means you solved the problem yourself already, Tony? Was it simply the ServerNode you forgot to add to the client INI file? This wasn't needed in all Win98SE setups, but WinNT/2K/XP complicates things, unfortunately.

Best,

Pete

[PFC setup]

When i plug my rudders ( PFC cirrus rudders ) into my PFC throttle control, they work fine except for one thing :

I the neutral center position when i do not have my feet on the rudders, the plan rudder moves from right to left , just very little moves but it moves, as if the center position was so sensitive that in fact the rudders are never exactly in the center

You need a centre "null zone". In the PFC calibration section, select the rudder so it it highlighted (has a frame around it), then press the rudder a little one way to set one of the centre limits (see the buttons to the left), and then the other way to set the other limit. It is all explained in the documentation. While you have that selected you can if you wish also adjust the response curve (the graphic on the left) to suit your needs.

I tryed to go to the PFC setup but could not find how to make the central position sensitivity smaller

Seems like you are looking for the wrong thing. It isn't a "sensitivity" adjustment you really want in the centre, it's just an area of no action, a "null zone". You can adjust the slope, viewing the graphic on the left, to change sensitivity, which is a different matter. But if it is less sensitive in the centre (flatter) it has to be more sensitive in the extremes (steeper) to allow full deflection to still be attained. FS's own sensitivity doesn't operate in the same way.

When i plug these rudders into my Yoke ( a USB AETI III yoke ) no more problem, the center position is stable !!

In that case it probably isn't providing the same level of resolution as the PFC connection. Some small amount of jitter is qite normal, though it shouldn't be much. Variations in temperature and other factors cause the resistance through potentiomenter coils to change slightly, so any system measuring it with any accuracy will usually see some variation. If you have a lot, you need assistance from PFC or your suppliers, though, not from software. Maybe there's a problem with the controller card in the throttle system, or possibly it has an inadequate power supply?

Regards,

Pete

[Problems accessing flight director fields with FSUIPC.]

Something suddenly occurred to me, from an earlier message. One question, Joshua, before this goes possibly way off in the wrong direction, when you say:

The flight director in the simulator window seems to more around just fine, but FSUIPC_Read constantly reports 0 and 0.2868537... for fd bank and fd pitch, respectively.

Can you tell me exactly what modes you have set for the FD to direct? The values you quote sound suspiciously like the exact values which a non-directing FD would show -- the non-bank because there's no heading mode selected, the 0.2 something is a normal default pitch when there's no climb or descent involved.

Is this merely a case of misunderstanding what the FD does? Make sure you set HDG mode on the A/P and adjust the heading so that the FD indicates a turn -- does the Bank still stay zero? Set ALT mode and adjust the Altitude to indicate a climb.

Bank is +ve for right bank, -ve for left, pitch is negative for pitch up, +ve for pitch down.

The values are not NEEDLE positions, they are the pitch and bank values which the needles should direct the pilot towards. How they actually do that, graphically, then depends on the current aircraft pitch and bank, the IAS (probably), and of course the type of inidicators used -- crosshairs and chevrons operate slightly differently. You aren't expecting these values to tell you specifically WHERE to draw the lines, are you?

Please confirm that you HAVE tested all this with an actively directing FD?

Regards,

Pete

[Problems accessing flight director fields with FSUIPC.]

Out of curiosity, how does FSLook get its data? I thought it was through FSUIPC, through message passing and the like. Can an external non module call lookup_var?

It uses a special non-supported call to FSUIPC, to do a "lookup_var". It was an original experiment to try to make external gauges using the same sort of system. But it is far too inefficent. FSLook can bring FS to its knees. It was never followed up for that reason. Worse, it cannot be used through WideFS -- WideServer needs to keep scanning values for changes, this method is too slow. I kept FSLook available just as an assist for gauge makers, not for real time use.

Yes, FSLook reports the same fixed values, while the gauges in the airplane move around normally. On your system, the values in FSLook change??

Certainly, they work fine. That's what I don't understand. These values are used by others quite successfully.

I'm using FS2K2 running on windows 2000, and I've confirmed this error on two different computers running the same. What version of Flight sim & Windows are you using?

FS2002 under WindowsXP, another on Win98SE and another on Win2000Pro (I need multiple setups for testing).

I know that it's outside the scope of FSUIPC's involvement but do you have any ideas on what might be causing this, or how I can try to pin the problem down?

Try using FSUIPC IPC logging (see the Technical page) -- you can ask it to log Reads or Writes from your program. Use FSInterrogate also to verify what you are seeing. It doesn't sound right at all. This is not a problem area, not something that ever didn't work. the values are simply there, they don't need processing or coaxing or anything.

Did you confirm which version of FSUIPC you were using? Do you think you may have any other add--in modules which could be interfering with this?

Regards,

Pete

[Problems accessing flight director fields with FSUIPC.]

I'm using using the 737-400, which does have flight_director_available=1 in the [autopilot] section of it's aircraft.cfg. The flight director in the simulator window seems to more around just fine, but FSUIPC_Read constantly reports 0 and 0.2868537... for fd bank and fd pitch, respectively.

... and the same in FSLook? They are both simply reading the same thing the gauge must be reading. I cannot make it go wrong here at all -- only in pause or slew mode do the values stop being updated. This is with the default 737-400. It seems to be behaiving just fine.

I really can only pass on to applications what FS passes on to me, or in this case also to the gauges. FSUIPC isn't doing any calculation or derivation at all here. It is merely the "window", not touching anything. And FSLook does not do it from the locations you mentioned, it actually reads the gauge token values in EXACTLY the same way as gauges do!

Regards,

Pete

[Problems accessing flight director fields with FSUIPC.]

I've noticed a problem while attempting to read from a few fields. The flight director pitch, and flight director bank fields in particular (0x2ee8, 0x2ef0) do not seem to contain the information that I had expected. The flight director pitch will remain stuck at a fixed value which is not consistent with the controls in Flight Simulator. The flight director bank is always zero.

HmmmI don't know those fields, personally. I'm just providing what FS provides -- as you have detected with FSLook, it is in fact what FS provides to allow the FD needles to be programed in gauges.

In the cases where they are not correct, are you saying that the FD bars in FS's gauges are not the same? If you are checking this on an aircraft not equipped with a flight director, then I don't think you'd expect the needle values to be updated. You don't need it to have a gauge with FD, but the AIR or Aircraft.CFG file must show it to be so equipped -- for instance, the [autopilot] section will have "flight_director_available=1". Did you check this? Also, of course, the FD should be active, else the needles won't be updated either.

I've just checked all this with the default FS aircraft with FDs and they seem fine.

Regards,

Pete

[Terrain avoidance?]

I was wondering how easy it would be to have some way to pause FS2002 (through FSIUPC) when you get too close to the ground? The reason is that I plan my flights with FSNavigator and it does not show "real" terrain elevations. I go for a shower or whatever during my flight and I come back to a plane that has crashed into a mountain that I did not know was there!!! Any ideas?

Thanks

"Sorry sir, I hit a mountain I did not know was there"! :D What a story to tell the authorities!

When you planned your trip you should really have noted the "MSA" (minimum safe altitude) for each section passed through. I use the relatively cheap TPCs or ONCs which you can get for virtually anywhere in the world -- I think the TPCs for the USA are equivalent to the WACs.

Unfortunately, nothing in FSUIPC tells you about mountains ahead. It really isn't much use just reading the ground elevation directly below the aircraft. In England with it's mostly rolling countryside maybe the ground rising slowly beneath you is a warning or something dangerous ahead, but that isn't going to be the case most of the time. In parts of the USA in particular, mountains have that annoying habit of sticking up out of an otherwise very flat plain! There's no way to predict that from the ground level beneath you.

No doubt something somewhere in FS knows about the shape of the country side around you, otherwise it couldn't draw it. But I don't know how to access that to proivde a terrain view ahead. Sorry. Programs that do this make use of their own terrain data files, I think.

Meanwhile, all I can suggest is set up AutoSave to save your flight at intervals, so when you come back to the wreckage you can go back in time a tad and change the course of history!

Regards,

Pete

[Weather Problems]

Jupp, thanks Pete. I'll be contacting the guys from the progs.

Regards, Chris

Well, I don't know if they'll be able to help, either, but with that information I said to gather, we should stand a good chance between us! It's just that there's no data for us to determine what is happening yet.

Regards,

Pete

[Weather Problems]

Ok. I'm using 2.97.2 together with either FSMeteo or ActiveSky. In both cases I don't have wind, clouds, temperature etc. Only the standard fs values. When I deleted 2.97.2 and the .ini and put the 2.95 back in all was fine.

Hmmm. What can I say? Version 2.972 most certainly has exactly the same weather interface as 2.95 and it implements the input from those programs in exactly the same way. There's been no change, and it is working everywhere else as far as I know. Have you any logs to show me? -- go to the FSUIPC Technical Page, and switch on Weather and IPC Write logging. Keep the session very short, just to know for certain that you should have weather. Save a flight, zip up the FSUIPC.LOG, the saved FLT + WX files, and I'll take a look -- you should really be talking to the weather program authors too of course.

BTW the version number is 2.972, not 2.97.2. Version 2.975 will be released this weekend.

Regards,

Pete

[58kt on ground - why?]

Hei!

Following problem occurs while using fs2002, FSuipc 2.95, fsmeteo is connected via wideFS 5.3.

(fsmeteo runs in standard mode, means that all 6 min connects to the weather server)

All works fine, until final approach to the destination runway. Then the winds are still the same as at cruise altitude. In the latest case 350 at 58kt at Kastrup (EKCH), difficult to land the 737 without several damages:-)

It's strange that fsmeteo and WEATERSET.EXE are reporting the correct winds! And it's impossible to reset the weather options of FS2002 directly in the FS-MENU nor to delete all weather-settings. There is no way to change these winds!

Please only ever use latest versions -- FSUIPC is 2.972, WideFS is 5.41. I don't support old versions. Please refer to the announcements here about this.

This problem is a well known but thankfully quite rare problem of weather caching in FS2002. It was reported to Microsoft over a year ago, but they could not reproduce it. I only ever managed to get it to happen once, never again. Some folks get it a few times a week, most not at all. It have never been reproducible to order.

Also it doesn't just apply that way around -- sometimes surface winds get stuck when you climb, but not many would notice this so much. It is also not actually dependent upon FSUIPC or external weather. It has occurred also with downloaded real weather and no FSUIPC installed.

There is no known cure. The stuck cache IS cleared when you reload a flight or even just an aircraft (originally it was thought you had to close and reload FS, but that is not true).

Anyway, you should change FSUIPC to the latest version -- the timing system used in FSUIPC now is far better than it was way back in 2.95 and it has been reported that, whilst this does not stop the cache sticking, it seems to make it much less likely.

Regards,

Pete

[Metar Station]

Hello,

How I can read the "METAR STATION" name in my program linked to FS2002 via FSUIPC.

I've read FSUIPC SDK documentation, but I've not found any offset can tell me witch "closest Metard Station" is near of plane position.

I've seen with ActiveSky it's possible to have this information (In main windows : Active Wx Station : XXXX [where XXXX is the ICAO code]) but perhaps this data is made by ActiveSky and not by FSUIPC ?

Hi Fabrice,

It isn't available from FSUIPC generally. There is a complex and obscure way to get a best guess Metar station identity through the AWI (Advanced Weather Interface) of FSUIPC, for FS local downloaded weather only, but that isn't foolproof and can be misleading -- FS interpolates weather from three METAR stations in a triangulation system which isn't always easy to determine.

ActiveSky and FSMeteo of course actually feed the data from the METAR stations (which they know, as they are reading them) into FSUIPC -- FSMeteo uses the AWI, ActiveSky uses the FS98 system at present. But neither tell FSUIPC any of the METAR data itself. They are in fact controlling global weather, not local weather, in any case.

If you merely want to determine the nearest METAR station to a particular location, such as that of the aircraft, you can search through the ICAO POS.BIN file (in FS's Weather folder) and choose the entry closest to that position. The format is easy enough -- 16 bytes per entry: a 4 byte ICAO, then three 32-bit floats -- Latitude, Longitude, Elevation.

Regards,

Pete

[FSUIPC]

DOes anybody know where i could get FSUIPC 2.72 for Fanda's Dash 8?

Or will the newest version of FSUIPC work ok, because i have experienced a couple problems with the Dash 8 that could be related to the FSUIPC. Gauges don't appear, moving parts are acting funny (flaps). If anyone has any suggestions please help me. Thankyou very much.

brett

2.72 does not exist. The only correct and supported version is the current one, 2.972 at this time (2.975 soon). FSUIPC (like all my modules) is developed with backward compatibility maintained. Each new version supplements, corrects, builds upon the previous one, it doesn't destroy what the previous one did. You should ALWAYS use the latest one, especially before asking for support.

If any problems do arise in new versions I try to correct them as soon as possible, but there really are no errors which can do such weird things to your Dash 8!

It seems many folks are under the illusion that FSUIPC does just about everything in FS (why use FS at all then? ), but in fact mostly it does nothing much at all. It is sitting passively waiting for programs to ask it for information. It knows nothing of gauges nor of moving parts -- all that sounds like an aircraft installation problem. You need to seek the help of the author or supplier.

Regards,

Pete

[Weather Problems]

Hi, I use 2.97.2 and tried 2.97 but I don't get weather. 2.95 works as it should but 2.97 doesn't. I deleted the .ini and configured it again. When I switch back to 2.95 it works. Any ideas?

Chris

Sorry, can you explain a little more about the problem, please. FSUIPC doesn't as a rule generate any weather at all. You either need to set weather in FS's weather dialogues, or download FS "real weather", or use one of the excellent external weather programs such as FSMeteo or ActiveSky. In the last two cases, FSUIPC is used to actually set the weather into FS.

There are some minor weather filter facilities in FSUIPC, but in general these are operating on the weather from the external programs.

There has been no specific changes in the weather filtering facilities for some time, though you can and should review the changes which have been made -- please refer to the History document which is included in the ZIP. For 2.972 you will see all the changes in the versions you mention.

Regards,

Pete

[Shutting Down via WideFS?]

Hi Stuart,

>> I have set the AllowShutdown=Yes in all the INI files, but when I send 0xABCD to the address in FSUIPC (or use the PM CDU) to shutdown, all the PC's just log off and sit at a login prompt. <<

That was a problem with an older version of WideClient, it used a "ShutDown" call to Windows (which I thought would do -- the PM CDU actually uses it) -- but in fact the "POWEROFF" call is the one which works. It should therefore be okay with WideFS 5.41 -- provided, of course, your Win98SE mobos do allow shutdown completely too. If the PC does power down from the "Shutdown" options. then it should work.

Regards,

Pete