Pete Dowson

To set/change sharing for a folder you right click and select 'Share' or similar -- or Properties, then Sharing there, depending on the operating system. Windows comes with quite extensive Help on these sorts of areas. Click on the Help entry in the Start menu and search for "sharing folders" or similar. Regards Pete

I just drag and drop using Windows Explorer. You probably need to use specifically shared folders on the PC you are not operating this from -- possibly create a folder called "workspace" or "filesfromX", share it with full access by "everybody", then you should be able to see it and read/write to it from the other PC. An alternative is to use a USB memory stick to transfer files. That can be quicker and less hassle sometimes! ;-) Regards Pete

Well, tell it which offset/bit to use to light or extinguish the LED, yes. All GFDisplay does is allow you to operate the LEDs and other GF displays using offset data. Yes, with FSUIPC offsets in the middle there. Also, bear in mind that the GF units and the GFdisplay program don't need to be on the FS PC -- you can connect your GF T8/P8 units to whichever client PC you like. Without browsing through pmSystems logic I can only assume you are correct. Presumably you've gleaned that from the pmSystems files? You need to make sure you are using the pmSystems .lgc and .txt files which are relevant to your needs. I wouldn't be sure they all supported this logic -- the 737 set certainly does. Hmmm. You are using one button for recall and Master Caution? Bear in mind that, at least on the 737, I think the system operates like this: 1. The M/C light is lit whenever there are annunciator conditions for the six pack 2. When pressed, the MC button clears the 6-pack indicators, but the M/C led stays lit if there are still conditions outstanding. 3. The recall is actually a button behind the 6 pack displays -- you press the six pack itself and the leds relevant to the current conditions are re-displayed. 4. The M/C light only extinguishes when there are no outstanding conditions warranting it being lit. In my cockpit I don't have a recall button behind the six-pack, so I devised a system where a single press of the M/C button means M/C pressed, and a double-click means Recall. But this really needs programming, not simple assignments. If you have two buttons you are ok. Maybe you are doing this for a cockpit which operates differently. The P8 and T8 units merely contain the simpler parts of those I have given examples for. For LEDs just look at the examples with lines beginning with "L". For the M/C LED it is easy, as you simply want one line which tells it which bit in which offset drives that LED, in the form: Ln=Xxxxx U16 Mmmmm where n is the LED number, xxxx is the Offset, and mmmm is a mask to isolate the relevant bit -- e.g 0001 for bit 0, 0800 for bit 11, etc. If all of your LEDs are lit by bits from pmSystems, then they will all be dealt with in the same way. If you have the 12 six-pack indicators they all have bits in offset 5530. No, not correct. pmSystems has the logic. The reason FSUIPC can't light your LEDs is because it contains no display facilities at all -- they are in GFdisplay. It only comes on if you've told it to, using the appropriate line in GFdisplay. pmSystems does NOT directly drive GoFlight units, as I've said already I think. No, not at all. FSUIPC is absolutely passive in this. FSUIPC hasn't the foggiest idea what any of these programs are doing. It is just the vehicle for these offset values. pmSystems writes values, other programs, like GFdisplay read them. The whole of the PM suite operates like that. It is all completely independent of FSUIPC itself, that is only the postbox. pmSystems doesn't know anything about GoFlight. This is why you are using GFdisplay!! The caution light comes on for many reasons, including Doors Open, Piot Heat / Window Heat not on, Yaw damper not on, Fuel pressure low, Hydraulic pumps not on, etc etc. When you first switch on the battery from cold and dark, about 6 or 7 of the 2 6-packs with be lit and the M/C light will not go out till all the conditions are cleared. Neither. GFdisplay is provided for that. That is why I wrote it! I agree. pmSystems does drive some hardware (or rather, is driven by it), but those GF units are general purpose -- there's no way pmSystems could be pre-programmed for all possible uses of the assorted units GF sell. This is where GFdisplay comes in, for the LEDs. FSUIPC is perfectly cabable of dealing with the switch inputs. BTW I'm off on holiday on Friday, so I may not be around to help you much more. Have you contacted Thomas Richter -- he's the pSystems expert. A very nice helpful person! Regards Pete

FS doesn't really simulate the six-pack stuff or the fire/caution stuff except vaguely with code local to gauges.Regards Pete

What new weather offsets? If you are talking about the NWI "New Weather Interface", then they are all in the Cxxx block of offsets, clearly mentioned in the documentation. You need to refer to the NewWeather Interface ZIP contents in the SDK for programming details. Regards Pete

Assuming you are using an aircraft which will feather the props (i.e. not an ordinary Cessna with standard prop pitch facilities) then I think the feather value is usually simply the zero value. Those aircraft with reverse pitch facilities would use a negative value for that. If you are relying on the button action on the Saitek pull-back (is it via button?), then it may be that you've not calibrated for a zero at the detente. If it were, say, +N, and the PropN_Dec control merely subtracted less than N, you'd need it repeating to get to zero or below. So -- question - have you enabled repeat for it? Another idea might be to explicitly set zero or whatever instead of using a Decrement. You can do that with PropN_Set and a parameter of zero, or whatever is needed. Regards Pete

You can't. The sounds come from the PC the program is running in. That's actually one of the big advantages of having ATC on a separate PC -- you can have ATC on your headset, not interfered with by FS sounds. I thought that was why most folks ran it that way! On FS2004 with SB3 that's via multiplayer. On FSX with SB4 it's via SimConnect. I'm afraid I can't help in that area. Regards Pete

No. Clicking the top left "set" button meterly enables the calibration. Then you calibrate using the other three "set" buttons. There are step-by-step instructions for doing this in the User guide. Please follow them. That's good -- it ensures you can always reach the full range despite minor variations in your axis readouts (due to things like age, temperature, humidity, voltage levels). Pete

PropDec? What's that. Do you mean "PropN_Dec" control? does that have twin Prop Pitch levers? If you are only talking about one lever, use to "map to 4 props" option in the single prop pitch control in FSUIPC, then calibrate the feather and/or reverse pitch (according to aircraft) in 4 props section. Regards Pete

No. I wish there was. They just seem to be graphics in random places and no information about them is available. You can get a cloud density pattern matrix for FSX, from SimConnect, but I don't think it has the resolution needed -- it's intended only for WX Radar use. Regards Pete

Check the description of the ButtonRepeat parameters in the Advanced User's guide. This addition was also described in the History document -- it was introduced by request in 3.90/4.50. Regards Pete

You are asking the wrong person. Project Magenta offsets are assigned by, updated by, read by, Project Magenta. Most of those concerning subsystems not implemented in FS are dealt with by pmSystems, which you do not mention you have. Yes, though I think the button operations and some of the LEDs are also dealt with by the PM MCP for some of the MCP attachments it handles directly and which include the 6-packs, such as the PFC MCP + EFIS + 6pack combo. With pmSystems you can do almost any subsystem logic, as most of it is controlled by text logic files. However, it does not drive GoFlight directly. You'd still need to program the GoFlight buttons to act of the offsets via FSUIPC, and use GFdisplay to get bit settings in offsets operating the LED indicators. However, I am not a PM expert, only a user. Your questions should really be directed to PM Support, or at least asked on the PM Forum in mycockpits: http://www.mycockpit.org/forums/forumdisplay.php?s=884 You might also be interested in Thomas Richter's work -- see the TSR website http://www.technical-service-richter.com/ You could certainly program the logic yourself, using the user-allocated offsets 66C0-66FF. It would all certainly be possible via, for example, a Lua plug-in to FSUIPC. Regards Pete

This is the repeat delay facility added by request of many users, so that single increments could be used without loss of hugh speed changes when a button is held for longer. This change is listed in the FSUIPC History document provided with each release, which I recommend you always peruse when updating versions. As it tells you there, and in the Advanced Users Guide, you can adjust both the delay and the repeat rate by changing the ButtonRepeat parameter in the INI file. Regards Pete

There's no way in FSUIPC3 to program it to operate exactly as it does when FS2004 acts on it, because FS2004 treats it as an Axis not a series of buttons like FSUIPC3. With FSX and FSUIPC4 you can treat it either way—but FSUIPC4 uses DirectInput for the axes, like FS. FSUIPC3 does not. However, you can get pretty close following the explicit example actually provided in the User Guide. I assume you've not looked there, as it is actually even listed in the Contents list, right at the front! Just look down until you reach the Buttons section and read the very next line! It even has the word "Hat" in the title!! Pete

It is petedowson@btconnect.com. But you'll need to be quick. I'm away on holiday from Thursday evening until the end of the month. Regards Pete

Okay. It was easy to fix. Silly error. When I added the second output, in order to avoid discrepancies between latitude/longitude/altitude owing to timing changes i changed the way I was reading them. I had assumed I wanted the altitude in feet, but in fact some sentences use metres, so the values is supposed to be left in metres and only converted locally to feet for those outputs needing it. I've fixed it in the official new main user release, 4,52, which I've made available in the Updates Announcement above until I can get the Schiratti page updated. Thanks & Regards Pete

Hmm. Sounds like there's a conversion from metres to feet when it is already in feet. Is this ONLY when there are two devices? I didn't notice it here, but maybe I didn't look closely enough. And maybe it is only in certain sentences -- can you tell me what sentences/modes the devices use for altitude? If you can fill in these details I'll look at it tomorrow. Regards Pete

Me too. Strange. Are they perhaps injecting aircraft representing the other fliers and those aircraft aren't DX10 compatible? How do they represent other players? Maybe you still have non-DX10 ASI aircraft folders in your FSX system and these are getting invoked? Can you suppress other player aircraft at all, just to find out? Sorry, I've no knowledge at all of either multiplayer or any of the on-line flight facilities like IVAO and VATSIM. I do have Squawkbox installed but I've never used it so far because they haven't made provisions for the transponder mode and ident to be operated from a hardware cockpit situation. Sorry, no, it isn't the case. And neither IVAO nor VATSIM use FSUIPC on FSX. Perhaps you might get an answer from the IVAO software support folks (Ivap and FScopilot I think), not the IVAO folks themselves? Regards Pete

Why are you trying to use DX10 then? :shock: I've no idea what IVAO has to do with it -- you need to ask them -- but it sounds like you probably have scenery installed which is not DX10 compatible, and/or are using non-DX10 compatible add-on aircraft. No, neither. FSUIPC has nothing whatsoever remotely to do with graphics or screens or DirectX (or IVAO), and nHancer has nothing to do with FS, only with the modes of the graphics driver. Use DX9, or make sure you are only using DX10 compatible add-ons -- i.e. ones explicitly designed and stated to work with DX10. Regards Pete

It is "Dowson", actually, but call me Pete, it is easier. You really needed to mention this when purchasing. But SimMarket can still sort it out for you -- raise a Problem Ticket and explain the situation and give your original login email. The email address itself isn't used by FSUIPC for anything other than tying the Keys specifically to you -- a street address would be used if you purchased by post. Both keys need to be tied to the same identity since there's only supposed to be one user. Regards Pete

There's no such error as "not a 12 digit code". I assume you mean not a valid one? Assuming you bought keys for the version you are using, and not for FSUIPC3, You are making a mistake! In all (100%) of such cases ever reported it has always turned out that the user was not entering one of the three fields correctly. ALL PARTS MUST BE EXACT -- your name, your email address, your key, letter for letter identical to the registration made. Please use cut-and-paste for all three parts if you are not sure! It is easy to mix up 1's and I's, 2's and Z's, 0's and O's, and it never ceases to amaze me how many ways folks have of differently spelling their own names! Regards Pete

FSUIPC doesn't touch anything in your aircraft unless you've told it to. But I don't know this "VASF4", so maybe it is something to do with that? What is it supposed to do? Try not using it. If you've been messing with FSUIPC settings and don't know what you've done, just delete the FSUIPC4.INI file before loading FSX -- then FSUIPC will revert to defaults and not touch your controls at all. You'll find that file in the FSX Modules folder. Regards Pete

Ah. I think the problem here is more that, like many hardware implementations, there's no information about the switch position provided until it has changed. At least, I think that is the case. Certainly the Lua facilities don't have any more access to the switches than FSUIPC -- they are using it directly after all. Looking at my code for GoFlight, it uses a call-back system from GFDev.dll (the GoFlight driver) to receive notifications of changes. I doubt that the GoFlight driver sends any "initial state" information, which is what you'd need. There may be a polling method for the switches implemented in GFDev.dll which could be used to get the initial state. I don't know offhand. I'm not able to access any GoFlight dox at present (I can't find them on this PC -- I may have to re-download the SDK to find out). However, it would be a non-trivial task to add something to get this information even if it were possible. I face the same problem with my PFC cockpit -- I can only read most of the overhead switches when they change. So, on my checklist, before anything else, I have a "run through switches, check all set correctly" item. I think this is pretty realistic in any case -- i.e. good practice. I note that the 747 and most other modern Boeing cockpits use mostly push buttons, so toggle switch states are much less of as problem. Regards Pete

It's possible, of course, but why do you think it is needed? pmSystems has offsets for everything. You can program the switches and buttons directly in FSUIPC's Buttons tab using the Offset controls. Any systems programming can and should be done in pmSystems logic files. Please explain why you want to do extra programming above what is done in pmSystems, and why this wouldn't be better off-loaded to pmSystems logics. Now, if you were NOT using pmSystems, you could instead probably program most of the complex subsystems using Lua. That is another matter altogether, and requires more knowledge about the subsystems logics than is does about Lua. For Lua programming there are several very good books around, plus the stuff on their website. All FSUIPC does is add special libraries for interacting with FS, buttons, keys etc. Regards Pete

Possibly the PCs you were using didn't have the right OpenGL drivers installed. This makes the PM modules resort to emulation, which hogs the processor and starves WideClient of time. On all of the Networks I've ever had for PM, starting over 10 years ago, the data rate has always been able to remain close to the throttled (limited) FS frame rate and provide smooth gauge operation. Either way, all this is probably irrelevant for the demo suite and as you aren't going to spend the money there's no point in investigating further! ;-) Pete