Pete Dowson

Your email hasn't arrived yet. The ponies must be a bit tired? ;-) Pete

I've had another look at the code and I can probably change the XML output (only) without too much trouble. One trouble is that I've rather bemused by this statement of yours, because nothing you say relates to any information I have: In my lists, code 2 is most definitely equated to Water, and isn't unknown. These are the extra entries you might get in the XML file if I make the changes I'm looking at: 7 "clay" (instead of "dirt") 9 "ice" (instead of "snow") 17 "bituminous" (instead of "asphalt") 19 "macadam" (instead of "asphalt") 21 "sand" (instead of "gravel") 22 "shale" (instead of "gravel") 23 "tarmac" (instead of "asphalt") You see this if you refer back to our earlier discussions: viewtopic.php?f=54&t=77144&p=471298 [LATER] Okay. Being eager to get on with other work I need to do, I've completed the change I proposed. Please use MakeRunways 4.42, now available in the Updates announcement. Regards Pete

I've found it -- it's a bug in the "event.cancel" function which only manifests itself when two or more plug-ins are using it. I've fixed it in versions 4.586 and 3.969, now available in the Updates Announcement. I think you will be able to handle your 12 buttons easily now. I did think of a way to handle all 12 in one plug-in, but it is quite complex, involving arrays and indexing, and, quite honestly, I think it would be less efficient in terms of performance and demands on the PC than having the 12 little simpler plug-ins. After all, those are merely taking up a little memory space, only running when triggered by the appropriate button. That would not be the case the the other way of doing it which would involve monitoring all the buttons closely enough to detect short press-release cycles. Have fun! Regards Pete

I think SimMarket can make arrangements for you if you specifically mention this, but also it isn't so important now. If you download and install the currently supported version (3.96 or 4.57) and take a look at the Installation and Registration documentation provided, you will see that these new versions allow different email addresses to be used. The name part must still be identical, however, letter for letter. After you install the latest version please note there are updates for them in the Updates and other Goodies announcement above. They fix a few things and add more features. Regards Pete

Again, there's no way for me to know. But if a program runs as a separate process from FS, and interfaces exclusively to it via FSUIPC, with perhaps some relatively minor reference to its files, then it will probably work fine remotely via WideFS. It might need special treatment, by the user, though, if it needs a lot of access to FS's files. In such cases folder access via normal Explorer links between the PCs is needed on top of the WideFS link. Programs like FS Commander are like that, I think, though they may have provisions for you to pre-prepare files on the FS PC for transfer to the remote one for more efficiency. Flight Keeper is like that. You run a utility on the FS PC which creates the files, and it transfers them to your client PC. Same with Radar Contact. Really you should work out what programs you want to use, research them a little, and perhaps ask specifically about those. I use quite a few and can advise with those, and there will be other users here who can also advise. Regards Pete

Sorry, what Beta? I've no need of any Beta testing at present. I don't recall a George S. but then there are many thousands of messages here and also in my email archives If you want to contact me privately for any reason please use petedowson@btconnect.com. But keep normal support exchanges here, please. Regards Pete

You need to update. As per the Announcements above the earliest supported version is 4.57, and there's 4.585 or later in the Updates announcement. No, sorry. There's no way of knowing until someone lets me know. With Garmin units I think they should be okay if they have the "Aviation" or "AV400" protocol listed as an Input. You probably also need Garmin's proprietary connecting cable, not just the one they use for downloading the charts etc. From other threads here I suspect any x96 model would do. I've got two Garmin GPS's and neither can be used, but they aren't aviation or boating models specifically. No, it is only positional data. The GPSout facility is merely a facility for driving moving maps, normally on another PC --- probably a LapTop. The reason it is called "GPSout" is that it emulates the positional output capabilities of a real GPS, just as if that GPS were fitted inside your FS airplane. The connection to a moving map is like doing that with your real GPS in your real plane, having it feed a laptop on your copilot seat, for instance. It amazed me when folks started connecting it to real GPS's (like connecting one GPS to another). The effect using a proper mapping program on a 10 or 12" laptop screen is much nicer. But if it works, well;-) Regards Pete

Ah! That probably explains it. 4.583 was last week's update, for something else entirely. It was yesterday afternoon (12:32Z as per my message to that effect) when I uploaded 4.584 with the fix. Later, around 16:00 I uploaded 4.585 with some other, unrelated change. You either went and downloaded 4.583 before you saw my message saying the fix was there, or you somehow managed to download a cached copy on your ISP's server. That simply confirms 100% that the problem is merely to do with the initialisation, as I suggested, as FSUIPC's initialisation actions were over and done when you loaded GFDevFSX. THat in turn which means it most definitely is fixed in 4.584 and later, but of course not 4.583 because that pre-dates the change (as in fact you could check by looking it the date on it -- I think you'll see it's the 4th, i.e. last Thursday! Regards Pete

Hmmm. Strange. Now FSUIPC is not addressing the GF displays at all, unless you've set the BlankDisplays parameter to "Yes", which seems rather unlikely. So, although my code is now the same on both FS9 and FSX, you still have exactly the same problem with FSX whilst it is fixed on FS9. After FSUIPC has initialised its links to GFDev.dll, it doesn't touch the displays. In fact there is no difference at all between 4.53 and 4.57 or later after initialisation, unless of course you run a Lua plug-in which operates with GF units. I've done a special test here. I've run FS9 to get my GF46 operating with both label and number displays working, then force-ended FS so that the displays are still shown. I then loaded and ran FSX, with the latest FSUIPC4 update, but without GFDEvFSX.EXE. The displays stayed, unchanged. Before today's update they were most certainly being cleared. So I am happy that my side is now okay. So, this either points to a rather insidious interaction problem between GFDev.DLL and GFDevFSX.EXE, for which I am going to have to await GoFlight's pronouncements, or, just possibly, it indicates that you are actually not really running the later code. Just as a positive elimination of that second possibility, could you please double check for me? Run FSX and go to the main tab in FSUIPC options, the one showing the version, and tell me what it says. And check the FSUIPC4.LOG, see what that says. Thanks. Oh, by the way, both FSUIPC3 and FSUIPC4 do still blank the displays when you close down the FS session. I thought that was okay, and neat. ;-) Regards Pete

Well, you most certainly should not have to do that. I never use "run as administrator" in that way, but then I never allow FS to install where it wants to do. This mainly started out as a desire to have a simple path to FS, like "C:\FS9" or "D:\FSX" rather than "C:\Program Files\Microsoft Games\Flight Simulator 2004". And this alone avoids most of the problems on Vista and Windows 7 because many of them are associated with the protection against users for everything installed in Program Files (or Program Files (x86) on 64-bit versions). Regards Pete

Yes, so the part I didn't know was that you are writing to offsets, not using buttons nor producing keystrokes. Now that is very confusing. Before you said "And using certain aircrafts like the PMDG and ATR a lot instruments are contolled through keystroke.". But now you say you are creating macros and assigning keystrokes to them, which is the other way round -- that implies you are not sending keystrokes TO the aircraft, but using keystrokes to activate FSUIPC macros. Please clarify, otherwise I don't know how to advise you. You don't want to use keystrokes to activate macros via WideFS, that's very inefficient and liable to errors and all sorts. Just instigate the macro directly through the offsets provided for that (see offsets 0D6C, 0D70). If you want to program things in FSUIPC's options you can instead just operate the Virtual Button facilities at offset 3340 and following. Toggling any of the 288 bits there is recognised in the Buttons tab as a button change, and you can assign as needed. If you really must send a keystroke from the program running on the Client, the best way is sending the appropriate FSUIPC added control via offset 3110. There are controls for "Key Press", "Key Press and Release" and "Key Press and Hold". The parameter encoding is documented in the controls list in the Advanced Users guide. Regards Pete

I've changed both FSUIPC3 and FSUIPC4, on the assumption it is the same problem on both. The updated versions are already available in the Updates announcement. Regards Pete

Well, in this case it's only a little arithmetic I think. Let's see: So, say you want to increment or decrement in 100 feet units, with the display rounded to the 100's Save this in your FS Modules folder as "AltInc.lua": -- Read the S-A A/P altitude and convert to the number of 100's of feet alt = ipc.readUD(0x53A4) * 3.28084 / 6553600 -- Add 1 (increment by 100 feet) if not already max (990 ? Or less?) if alt < 990 then alt = alt + 1 end -- write it back, converting to metres * 65536 ipc.writeUD(0x53A4, alt * 6553600 / 3.28084) Do the same for a file called "AltDec.lua", except change the middle part to -- Subtract 1 (decrement by 100 feet) if not already zero if alt > 0 then alt = alt - 1 end Now all you need to do is assign your INCrement to "Lua AltInc" and your DECrement to "Lua AltDec" in the FSUIPC Buutons tab. Regards Pete

So, at least for you just cutting out my Blanking during initialisation would fix it. I'm hoping the others in this thread can confirm. I'll make the change anyway to FSUIPC3 now and put it up in the Updates announcement at the top of the Forum. Check later today or perhaps tomorrow morning. Regards Pete

Yes, but WideClient has to have the keyboard focus to receive them. It won't intercept the keyboard, it only receives keystrokes if it's window is selected first. To get it to forward them on to FS you have to enable that action in the WideClient.INI file. (Offhand I think the param is "SendKeyPresses", but please search for "KeyPress" in the WideFS Technical document). But how is this application sending the keystrokes to WideClient? If it involves buttons which FSUIPC can recognise you'd be far better off just using those and then programming the buttons in FSUIPC to send your keystrokes. Regards Pete

There's a timeout in FSUIPC too, though. I'd still advise you to get the more recent version of FSUIPC available in the Updates announcement at the top of this Forum. The first is the original control provided in FS since at least as far back as FSW95. All the "AXIS_ ..." ones were added by Microsoft in FS2000 or FS2002 (don't remember which now). The main difference is that the old ones operate from 0 (off or idle) to 16383, with negative values used for things like reverse thrust or prop pitch where applicable, whilst the new ones operate from -16383 for idle or off to +16383 for full on. In order for FSUIPC to provide reverse thrust on the throttles and reverse pitch on the props it uses the older non-axis controls. For spoilers where's really no difference as far as you're concerned. Really, if you are assigning in FSUIPC you'd be better off assigning "direct to FSUIPC calibration" and by-passing all of the FS controls. Regards Pete

They won't have gone -- they're in your INI file, same as always. That is never deleted. Sounds like your joystick timed out. The timeout was a little too strict -- please see the Updates announcement above. Just replace the DLL. Regards Pete

FSUIPC3 uses the original joystick access facilities provided in Windows. These only support 6 axes, XYZRUV. It sounds like your pot isn't configured to be one of those. In FSUIPC4 I changed over to using DirectInput instead, and that supports more axes -- I expect that's why you see it in Game controllers and FS. FS itself has used DirectInput since about Fs2002 but FSUIPC dates back to FS98 days. Regards Pete

I'm now wondering whether I've been misinterpreting what you all have been reporting. With FS9 and the GF-46 programmed with 8 different radio capabilities as allows for in GFConfig, I get the following sequence when FS9 is loading: 1. Initially, as FS9 is loading, the GF46 displays one of its redio settings, label on left, numeric value on right. 2. when FSUIPC initialises, the name blanks, but the numbers stay. 3. On using the button to select another function, the label comes back. From then on all is okay -- the label is always there. If this is what you are all seeing, or similar, then I think all it is down to is FSUIPC's initialisation: as soon as it sees any devices with displays it clears those displays ready for use by whatever. I think what is happening is that the GoFlight initialisation is occurring first, and thereafter it doesn't replenish its display. If this is the cause of the "problem" I can fix it easily -- just not clear the displays, or make it optional and off. What makes me think it isn't that simple was this original report: I would have thought that if the modules are put into use later, by the GoFlight driver, they would re-display. FSUIPC's "blanking" is only done once, at the start. Please advise. Regards Pete

So you don't have a problem arming the spoiler in the default aircraft? If not, if it is something specific to this aircraft, then maybe they are doing their own thing there and have some other mechanism? Or possibly you are using an FSUIPC-calibrated spoiler axis but the PSS 777 locates the arm detente in a different position along the range of values? Not really, and I'm not sure why or how it could help matters. Are you assigning a joystick axis for this, and if so where and how? Sorry if I sound confused, but you said "when I arm them with SHIFT-/, nor when I move the spoiler axis into the "Spoilers armed" position" which sort of implies you are using a keyboard or mouse for this. You also said: which I don't understand either. The only problem I'm aware of with arming spoilers is if you try to do it on the ground, when the "on ground" flag would usually trigger the full deployment. You go on to say: The "arm" detente or zone on the lever is not relevant if you are pulling it back into speedbrake use values, so I don't think that can be it. The "arm" state is only set in one area, one range of values of the axis. Regards Pete

Just run the "Install FSUIPC" program again, the same one you used in the first place to install FSUIPC. There's no point in buying another copy, and nothing refers to a "page" in any case. That installer program is the installer. The registration for both FSUIPC and WideFS is there. Exactly as described in the little Installation document included in the ZIP and illustated in pictures both in that document and in the User Guide. The reason the registration is performed in the Installer is that it, and only it, has the necessary privileges when using Vista or Windows 7. Regards Pete

Okay. Thanks. I'll work out what's happening during the week. Regards Pete

Hmmm. Shouldn't hang. Do you mean pressing both buttons together? They might interfere with each other though. I'll have to investigate that -- it won't be today though. Perhaps you could Zip up the Lua programs and send them to me at petedowson@btconnect.com , so I can use exactly what you use. Ah, yes. The Lua code accesses the memory locations for each joystick, and isn't aware of the Letter assignments. I never thought of that . If possible I'll make it accept those too, in a later version. Thanks, Pete

I'm not aware of any specific facilities for camera selection. I didn't know you could define cameras in the Aircraft.CFG file. How are they activated? You don't mean the window views in the PANEL.CFG files, do you? Regards Pete

I'm not aware of any problems at all with spoiler auto-deployment. Are you testing with default or add-on aircraft? How have you programmed the spoiler on your equipment. If you are using a spoiler axis, maybe you've not claibrated it correctly to stay in the "armed" section when set and it overrides the other controls? That's out of date and unsupported now. Install 3.96 then get the latest updated DL from the Updates announcement above. Regards Pete