Pete Dowson

FSUIPC isn't looking for anything. It doesn't care at all. It is Flight Simulator you are sending the values to. FSUIPC is really just a passive interface. The current FSUIPC flaps facility is, of course, intented to be used the other way round. You calibrate the lever to suit FS, not FS to suit the lever! Odd to use a pot for fixed number of detentes. Surely fixed resistors and a multiposition switch would be better? You choose the resistor values to get the desired result -- probably equal values despite the differing values of the flap angles. Otherwise if it is working evenly but with too low a change, either the pot value is wrong (have you tried different values?) or you need to calibrate it differently -- include only the active section, for instance, leaving bigger null zones, so spreading the range and increasing the difference. I still think more precision is possible with separate fixed resistors or maybe trimpots. Otherwise, you can do something similar to EPIC, write a little program to read the axes, convert inputs according to a table, then write them directly through FSUIPC. If you still need something done next year, when I may have "conquered" FS9 , ask me again and I'll look at adding a look up conversion table facility (only via the INI file). Pete

The date/time is not produced or in any way tampered with by FSUIPC, it is only exposed for applications to access. The time is given by FS with Seconds, and Hours and Minutes on a 24-hour clock. Two sets of hours and minutes are given, one Zulu (UTC or GMT) and the other Local Time. The date is given as a Year and a Day number in the year. The application would be calculating the actual month and day of month from that -- it sounds very much as if it has got those calculations wrong! I'd report it as a bug if I were you. I think there is a bug in FS which makes the day number one out -- i.e. one day, not 45 days out. It doesn't always occur, and is probably due to a mix-up over whether Jan 1st is day 0 or day 1 in different parts of FS. Pete

The date/time is not produced or in any way tampered with by FSUIPC, it is only exposed for applications to access. The time is given by FS with Seconds, and Hours and Minutes on a 24-hour clock. Two sets of hours and minutes are given, one Zulu (UTC or GMT) and the other Local Time. The date is given as a Year and a Day number in the year. The application would be calculating the actual month and day of month from that -- it sounds very much as if it has got those calculations wrong! I'd report it as a bug if I were you. I think there is a bug in FS which makes the day number one out -- i.e. one day, not 45 days out. It doesn't always occur, and is probably due to a mix-up over whether Jan 1st is day 0 or day 1 in different parts of FS. Pete

The name you are referring to is presumably the ATC name and type. The reason this doesn't apply to FS2000 or FS98 is that the built in ATC was only introduced in FS2002. This should be applicable to FS9 as well. For FS2000 and FS2002 there's also: 3C00 Pathname of the current AIR file 3D00 Name of the current aircraft (from the “title” parameter in the AIRCRAFT.CFG file) From which you may be able to derive what you want, ven if you have to read the files yourself. There's no way FSUIPC is ever going to provide anything extra for FS98, which precedes its development start. It only was made to run on FS98 so I could use the IPC logging to work out how the FS98 interface worked and maintain is as a subset for application compatibility. As FS develops, so will the interface I provide, but I am not about to try to simulate new facilities in previous versions of FS. Pete

The name you are referring to is presumably the ATC name and type. The reason this doesn't apply to FS2000 or FS98 is that the built in ATC was only introduced in FS2002. This should be applicable to FS9 as well. For FS2000 and FS2002 there's also: 3C00 Pathname of the current AIR file 3D00 Name of the current aircraft (from the “title” parameter in the AIRCRAFT.CFG file) From which you may be able to derive what you want, ven if you have to read the files yourself. There's no way FSUIPC is ever going to provide anything extra for FS98, which precedes its development start. It only was made to run on FS98 so I could use the IPC logging to work out how the FS98 interface worked and maintain is as a subset for application compatibility. As FS develops, so will the interface I provide, but I am not about to try to simulate new facilities in previous versions of FS. Pete

In that case it is either the hardware unit itself, or the cable (did you check no wires had come unsoldered, for instance?), or the driver or whatever it is that talks to the device. Really you need Safeline support to help here. If that's consistent then something's out of phase somewhere. This "console gauge" you see in FS, is that the driver for the SafeLine device? Is there no EXE driver you need to load? No, FSUIPC knows nothing about any hardware at all, and it most certainly does not touch COM ports. FSUIPC is a passive interface, it just does what applications interfacing to it ask of it, FS-wise, not hardware wise. Folks seem to think it does everything, but that reaslly is NOT true. In fact, it is sounding like your Safeline device doesn't even use FSUIPC. Certainly if it a commercially sold device and they use FSUIPC they should have asked permission in any case, and I've never even heard of it. Does it say in their manual you need FSUIPC? If so, have you their address? Pete

In that case it is either the hardware unit itself, or the cable (did you check no wires had come unsoldered, for instance?), or the driver or whatever it is that talks to the device. Really you need Safeline support to help here. If that's consistent then something's out of phase somewhere. This "console gauge" you see in FS, is that the driver for the SafeLine device? Is there no EXE driver you need to load? No, FSUIPC knows nothing about any hardware at all, and it most certainly does not touch COM ports. FSUIPC is a passive interface, it just does what applications interfacing to it ask of it, FS-wise, not hardware wise. Folks seem to think it does everything, but that reaslly is NOT true. In fact, it is sounding like your Safeline device doesn't even use FSUIPC. Certainly if it a commercially sold device and they use FSUIPC they should have asked permission in any case, and I've never even heard of it. Does it say in their manual you need FSUIPC? If so, have you their address? Pete

Radar Contact makes the sounds on the computer in which it is running. That's the whole point of running it on a client -- to separate the ATC sounds from the aircraft sounds, making them much clearer and amenable to using a headset/headphones, just as in a real aircraft! I don't know Flightdeck (perhaps you mean Flight Deck Companion?) but likely the same goes for that. There's no way a separate PC on a Network can ventriloquise its sound onto a different PC unless it has its own networking components designed to do this, but I don't see the point in any case. You would be throwing away the main advantage of running it on a separate PC! Pete

Radar Contact makes the sounds on the computer in which it is running. That's the whole point of running it on a client -- to separate the ATC sounds from the aircraft sounds, making them much clearer and amenable to using a headset/headphones, just as in a real aircraft! I don't know Flightdeck (perhaps you mean Flight Deck Companion?) but likely the same goes for that. There's no way a separate PC on a Network can ventriloquise its sound onto a different PC unless it has its own networking components designed to do this, but I don't see the point in any case. You would be throwing away the main advantage of running it on a separate PC! Pete

That's fine. I run the Glass Cockpit on one Client and the MCP and FMS on another. Where are you running the MCP? That is needed, as it is the MCP which includes all the processing for the PM commands. If the MCP isn't running then none of those PM controls will work as far as I know. If you are not using an MCP I think your only recourse is to use the KeySend facilities in FSUIPC, and program the KeySends to send keystrokes to the ND in the Client. Really Project Magenta support is the better place to sort this out, as it is a PM matter. All I do is provide the tools to program the commands it uses. What it then does is up to Enrico Schiratti. Pete

That's fine. I run the Glass Cockpit on one Client and the MCP and FMS on another. Where are you running the MCP? That is needed, as it is the MCP which includes all the processing for the PM commands. If the MCP isn't running then none of those PM controls will work as far as I know. If you are not using an MCP I think your only recourse is to use the KeySend facilities in FSUIPC, and program the KeySends to send keystrokes to the ND in the Client. Really Project Magenta support is the better place to sort this out, as it is a PM matter. All I do is provide the tools to program the commands it uses. What it then does is up to Enrico Schiratti. Pete

Sounds very much like you've not installed FSUIPC. Pretty much all of my modules need FSUIPC when used in FS2002. Sorry it isn't documented -- this dependency wasn't actually discovered till long after release, because most people use FSUIPC in any case. Regards, Pete

Sounds very much like you've not installed FSUIPC. Pretty much all of my modules need FSUIPC when used in FS2002. Sorry it isn't documented -- this dependency wasn't actually discovered till long after release, because most people use FSUIPC in any case. Regards, Pete

Yes. Use the Keys page in FSUIPC options. All of the available Project Magenta controls are listed in the drop-down, for assignment to joystick buttons as you like. Pete

Yes. Use the Keys page in FSUIPC options. All of the available Project Magenta controls are listed in the drop-down, for assignment to joystick buttons as you like. Pete

No. FSLook is even more limited than FSInterrogate. It isn't looking at offsets, it is reading FS Gauge TOKEN variables, those with names documented for regular FS gauge use in MS PAnels SDKs. If panel programmers choose to do their own thing, then only they can tell you how to get their variables. They are not "public" FS values, they are private to their panel modules. There are no such things as "offsets" (in the FSUIPC sense) for them. The "offsets" in FSUIPC are positions in FSUIPC's mapping of FS variables. It has no way of getting into private panel coding. Regards, Pete

No. FSLook is even more limited than FSInterrogate. It isn't looking at offsets, it is reading FS Gauge TOKEN variables, those with names documented for regular FS gauge use in MS PAnels SDKs. If panel programmers choose to do their own thing, then only they can tell you how to get their variables. They are not "public" FS values, they are private to their panel modules. There are no such things as "offsets" (in the FSUIPC sense) for them. The "offsets" in FSUIPC are positions in FSUIPC's mapping of FS variables. It has no way of getting into private panel coding. Regards, Pete

I don't know -- I suppose it must be in the registry. I just used to reselect the default in the Control Panel multimedia or sound applet (not sure which, probably mm). Regards, Pete

I don't know -- I suppose it must be in the registry. I just used to reselect the default in the Control Panel multimedia or sound applet (not sure which, probably mm). Regards, Pete

Once the app has opened the sound resource it doesn't change it. You can load up FS then when it is ready, change the default sound device and load up Radar Contact, or whatever. I've done this sort of thing before now, but these days just use another PC, it's easier! Pete

Once the app has opened the sound resource it doesn't change it. You can load up FS then when it is ready, change the default sound device and load up Radar Contact, or whatever. I've done this sort of thing before now, but these days just use another PC, it's easier! Pete

I've never heard of it referred to as FS2003. It was originally FS2004, then FS9, the "Century of Flight" seems to have stuck now, but I wouldn't swear that it'll stil be that on release. So, "FSCOF" Not exactly. The weather in FS9 will be more advanced. There was almost no change from FS2000 to FS2002 so the AWI, designed for FS2000, was sufficient. I aim to retain the AWI but not enhance it. I will add completely new facilities to take full advantage of the developments in the weather. But I may not have time to do that in the first released version. Regards, Pete

I've never heard of it referred to as FS2003. It was originally FS2004, then FS9, the "Century of Flight" seems to have stuck now, but I wouldn't swear that it'll stil be that on release. So, "FSCOF" Not exactly. The weather in FS9 will be more advanced. There was almost no change from FS2000 to FS2002 so the AWI, designed for FS2000, was sufficient. I aim to retain the AWI but not enhance it. I will add completely new facilities to take full advantage of the developments in the weather. But I may not have time to do that in the first released version. Regards, Pete

Odd, there are a lot of folks happily using WidevieW. Perhaps your Network is not fast, or your client PCs aren't the same specification as your main one? Best really to have the instrumentation on the main PC and only views on the others. Okay, then use WideFS instead. No idea, sorry. You need someone who uses WidevieW to tell you, maybe Luciano himself can offer suggestions. Use WideFS. That's what it is for. That is what Project Magenta uses. Pete

Odd, there are a lot of folks happily using WidevieW. Perhaps your Network is not fast, or your client PCs aren't the same specification as your main one? Best really to have the instrumentation on the main PC and only views on the others. Okay, then use WideFS instead. No idea, sorry. You need someone who uses WidevieW to tell you, maybe Luciano himself can offer suggestions. Use WideFS. That's what it is for. That is what Project Magenta uses. Pete