Pete Dowson

Yes it does that. The same happens if you explicitly save a flight. They are not renamed files they are brand new files. Try it yourself, save a flight with a new name, then use "reset flight". What gets reloaded? (Answer: the one you just saved). Yes, I saw the HTM type files in those folders. I thought I said that? No need. And I think the "learning centre" uses Missions in FSX, which explains why they moved. It isn't complex! However, it is a small design shortcoming in FS9 I think. I thought I explained that? What wasn't clear? Let me try again: There are TWO things you can do with a flight -- SAVE it (i.e. create a file with all the details on disk), and LOAD it (i.e. read it into FS and use it in place of the one you were using before). When you LOAD a flight, you evidently get access to any "HTML" file which has the same name, saved in the same place. It sounds like, in FS9, these come up automatically if they exist -- the Missions in FSX certainly do that. When you SAVE a flight, FS creates the new FLT file (and a WX weather file) with the new name, but apparently does not also save the HTML file with the new name. That's fine -- or it would be if FS continued to associate the HTML file with the name of the previously LOADED flight file. If it did so, then merely saving a file (as AutoSave does) would not lose you access to that HTML. Of course, if you restarted a flight, that would restart from the last save, so you'd lose access to the HTML then in any case. But you wouldn't lose it unknowingly. However, it seems that FS9 (at least) associates the HTML file with the same name as the last referenced FLT file, whether loaded or saved. Hence the only solution being the one I suggested, which may well be easily feasible but, as I said, a possible cause of more noticeable stutters. If I implemented it it would therefore probably have to be optional. And maybe I'd only do it for FSX, I don't know yet. Who said you would have to do so? Regards Pete

That must be a mode of FS9 I've never set, as when I select a flight, I just get the flight, in the state I saved it whenever. Oh, rightnot in any parts I've read, evidently! ;-) Yes, I did, but it doesn't change the name of any file at all, it merely tells FS to save a flight with a NEW name, based on the time. Oh, it also deletes older files it saved, according to the the number requested for your cycle of autosaves. The saving action is 100% identical to what happens when you press ";" to get FS to save a file, then enter a name and press ENTER. The only differences with AutoSave is that it does it on a timed basis, and generates the name itself rather than prompt you for it. In that case it really is a design defect in FS, as it should base the HTML filename it reads on the last flight you LOADED, not SAVED, surely? I had a quick look in my FS9 folders. There are ".htm" files in some subfolders in the "Flights" folder. But there are none at all in the "My Documents\Flight Simulator Files" folder. The latter folder is where saved flights have to go. AutoSave cannot save files in the "Flights" folders. If HTM files are copied into the saved flights folders and renamed, do they still work? If so, the only way around this would be for AutoSave to find the name of the currently-loaded or last-saved flight (whichever is more recent, then copy any html file with the same name, giving it the new name. So, with a cycle of, say 30 AutoSaved files you'd get 30 identical HTML files. Right? And then it would also need to delete those when it deleted the corresponding AutoSaved file. All this could cause a stutter in the flight, so it may have to be an option. The deletion is easy enough, the rest is messy for the AutoSave DLL as it doesn't currently have the requisite information. It would be much easier to do for FSX, in FSUIPC4, because AutoSave is part of FSUIPC4. I assume the same problem was carried forward by MS into FSX? Or don't you know? Is all this new in FS9? Even if so, FS9 is now, what, over 5 years old. No one mentioned this before. If it is applicable to FSX I may add the solution I mention to FSUIPC4. Whether I can backtrack to the freeware Autosave.DLL for FS9 I'm not sure -- if the code is not too dissimilar I probably could. [LATER] I just looked at the FSX folders, and the only .htm files associated with flights which I see there are only for Missions, in the Missions folder. Maybe MS fixed the problem in FSX? I'd have to try loading a mission and saving a flight with ";" to see if it saved a new .htm, or if not, whether the same original .htm is remembered and re-used (which would obviously be a far better solution). Regards Pete

Yes, I understood that. I used to be annoyed by it too, but it happens so often that it bothers me no more! ;-) There's another case from seven weeks ago just come to the fore again this very minute, also replied again. We'll see .. Thanks & Regards Pete

So, then obviously I need the same information as I asked before, over seven weeks ago, with never a reply. Please read my message above. When I don't receive any follow up, and it is only a single report, I have to assume that the user concerned solved the problem by himself, or found that a later update fixed it already. I always hope that such users "complete" the thread with a reply, but obviously I cannot force this to occur. There is really nothing in FSUIPC which can be doing this on its own, it is related to some setting or other, or possibly some add-on, but I cannot help you in a vacuum. There's no way for me to proceed. I have to work with actual information, as I asked the previous user, but to no avail. Anyway, in the seven weeks since the last user was complaining about 3.853, there have been many other updates. You should please first try the latest interim version, 3.865, from the updates announcement above. If you still get problem, that is when the log and INI information is needed. Version 3.865 is currently the "release candidate" for the next big release (maybe even 3.90) -- I still have a lot of documentation to work on, as there are several important new facilities which deserve expanded attention. Regards Pete

Thanks! I think this must have been the critical part, missing on the earlier attempts. It's a bit astonishing that rolling back doesn't undo permission changes. We'll have to watch that! Regards Pete

Good! Can you tell us what did the trick? Regards Pete

Yes and yes. That would be excellent! The Macro (.mcro) files are also to the same standard with the same access methods. You should be okay. I'd certainly be interested in seeing the results! Regards Pete

Sorry, I'm confused by this statement. What does "IVAP me hard" mean, and how does it relate to GPSout? I'm afraid that's not a supported release. You should be on 3.85 or later if you want support. And I have no idea why you even mention IVAP. What has that got to do with GPSout or your Garmin? Can you explain the problem in more detail. How is this Garmin GPS connected? USB or COM port? Have you disabled ActiveSync so that it's connection can be used by other programs? Do you even know for certain that it can receive external position data? If so have you put it into that mode? Is the data supposed to be in NMEA format (and if so what sentences), or Aviation (AV400) format? If neither, then GPSout cannot support that device. Not many GPS devices will accept NMEA input for anything other than planning data. I have two Garmin GPSs and neither of them will do so. I've never heard of a Pilot III being usable with GPSout, so what makes you think it can be? Regards Pete

Strange that this briefing needs the name of the last saved flight? I've never used it myself. Is this in FSX, FS9 or what? Is this flight briefing a file, then? Sorry, this is a completely new one on me. If you know the workings of this, perhaps you'd explain? How is the briefing generated, and where does it sit? Regards Pete

You list the log entries, but fail to say how you achieved them, so it isn't really very helpful. The log shows the panel switch sending multiple INCs or DECs. but is it the one switch operating both flaps, or only one? Are you holding the mouse button down to get the repetition? The switch on the panel apparently cannot be a latching toggle switch, can it? It must have a centre off position -- else how do you stop all the repeats? Can you explain anything about the cowl switch operation at all? When you operate the cowl switch on your GF-SECM, are you really hoping to emulate a different sort of switch altogether? Because I don't think it is possible! Your latching switch is going to be either stuck in one position or the other, so you can't let it send repeats forever. If all you want to do is open the cowl flaps fully, or close them fully, by toggling the GF-SECM switch one way or the other, then that is certainly achievable. But you cannot do that with the INC and DEC controls. You'd need to use the axis controls, as I already suggested. In other words, COWLFLAPS1 SET and COWLFLAPS2 SET, with a parameter of either 0 or -16383 for one state, and 16383 for the other. I'm sorry I can't be specific on the values for your aircraft -- you'd need to experiment with the assignment. Get the switch working for COWLFLAPS1, and then, and only then, show me the INI file entries for that. Then it is only a matter of duplicating the lines and changing the COWLFLAPS1 number to the COWLFLAPS2 one. I can help if you show me (but tomorrow now. I'm off to bed). If you really want properly adjustable cowl flaps, like the normal flaps, and the GF-SECM only supplies a latching toggle, as it looks, then I'm afraid you are out of luck. (Though you could program that switch to toggle the function of the spring-loaded centre-off Flaps switch between operating wing flaps and cowl flaps. But that's another story, involving conditional expressions in the INI file). Er, what is this all about? And why on Earth are you logging Keys and Buttons and IPC Writes? I asked you to log Events! That's just one check mark in the Logging tab!!! I've no idea what you are doing with that button, but there most certainly is nothing showing useful in the extract you published, and certainly no cowl flap action. I've no idea why you showed it nor what it is about. Please, if you want me to help, please do as I ask. Regards Pete

Okay. So no centre off. and the cowl flaps are either full open or full closed? Nothing in between? I've deleted the lines which aren't relevant, and commented the others so I can see what's what. But nothing makes sense. Check those button numbers against the ones you last reported. What are you actually doing here? I'm not understanding at present how you are SEPARATING the two cowl flaps, as the controls you were using (none of the rubbish above) operate all cowl flaps. Only the ones with engine numbers on them are selective -- unless you've previously selected an engine by E + 1, 2, 3 or 4. Maybe you should go back to basics firsr. Go into FSUIPC options, Logging tab. Enable Event logging,. Then operate the controls you want to assign, using the mouse, on the panel. Look in the FSUIPC Log file and see what controls each one uses. Those are the controls you need to be assigning! I'd also start by deleting all those lines above. I don't know how you arrived at them -- are they remaining from when we were trying to work out what button numbers related to what switches? Didn't you delete them before we changed them all? Regards Pete

No. Why have you got 3 repeating "press" controls for "DEC COWL FLAPS", and 4 same "INC COWL FLAPS" for the "release"? What has that got to do with multi-engined aircraft? What controls drive the other cowl flaps? You are confusing me no end here. I thought you meant you needed two buttons to assign two controls, one for Engine 1 and the other for Engine2. With a toggle switch you'd need to use the COWFLAPSn SET controls with a parameter or 0 or 16383 (n = engine number). I thought your problem was that there is no "generic" COWLFLAPS SET control operating them all together. (The generic INC and DEC controls should certainly operate all of them). Didn't I ask this before: is the cowl flaps switch a sprung centre-off control, or a straight latching toggle switch? If the latter, as I assumed, then you only need one button number. If the former, then you need two. [No, I see I asked this question about the Gear up/down switch, but you didn't answer anyway]. What has the number of Engines got to do with the gear? You most certainly do not operate left, nose and right gear separately, nor do you have retractable gear for each engine! Gear is either up or down, or travelling. FS only recognises up and down. That's one button number. Pete

You are in the wrong place. WideFS does not do what you are thinking. You are confusing it with WidevieW by Luciano Napolitano. Check his website. In my opinion, since all of the PCs have to run a complete copy of FS, they all need to be the same power and capacity. Regards Pete

Having a separate button number for Open and Close doesn't automatically solve that. All you need to do is assign the same button two both controls, not the one. You can do that by simply adding another line in the FSUIPC INI file, or creating a macro with both assignments in, calling it "Both cowls" or something, and assigning to that. Either way works as well as the other. Regards Pete

You have SimConnect problems already with a fresh install of Windows 7 and FSX? How come? Anyway, Windows 7 will be like vista. You cannot alter things in system folders like WnSxS without changing permissions. Regards Pete

Sorry, you are asking the wrong person. I'm only going by the statements (quoted from Matt Ford) in the thread over in mycockpit.org, where you referred folks here. Have you not been following it? So perhaps you need to ask Matt for more details, or contact Mr. Ben Supnik? I don't have X-plane at present (though I may have a look out of curiosity) and have never had anything to do with it apart from a brief play long ago with a very early version. I didn't like it then, but I see it is up to version 9 now, so I've not really seen at least 6 versions anyway. Regards Pete

What exactly is the "new version of FSUIPC", please? Just saying "new version" means nothing. They have numbers. Always quote version numbers please! FSUIPC has absolutely nothing to do with sound. Your friend must be having a joke with you. Pete

Aha! You are not using a rotary encoder, but a selector switch -- a switch with n-positions each looking like a different button!? Such a switch, though looking like those on the EFIS and in fact operating like those on the real aircraft, is quite different from the way the panel operates. You must have noticed that, in fact, the Level D EFIS on the panel does NOT operate like that -- instead of having several mouse positions, selecting each value separately, it only has a + and - position for each knob, turning them in the suggested direction. Obviously, to emulate that actual IMPLEMENTED switch, instead of the simulated switch, it really also needs just two momentary positions. Two separate buttons would do the trick easily, as would a rotary encoder. Did you explicitly choose selector switches? If you could change to rotary encoders, or even centre-spring two-way toggle levers, it would be much easier for you. It could probably be done with a selector switch, but I think you'd need to go into FSUIPC INI file button programming, as each button number's action needs to be somehow made dependent on the previous button in the sequence (i.e. so going left and right can be distinguished). This would be by using conditional button parameters (as described in the Advanced User's guide for FSUIPC), and probably the flag facilities, but it isn't easy. You are trying to relate one type of switch to another. Alternatively, easier, as it is without conditions, but messy and probably odd to look at, you could program the positions in this way (still by editing the INI file, though): Say there are n possible positions altogether. Consider them numbered 1 to n, clockwise. Switch position 0: send the - macro n times. (then no matter where it was to start, it will always get there) Switch position 1: send the - macro n times then the + macro once Switch position 2: send the - macro n times then the + macro twice ... etc, until at some point it becomes more economical to swap to using the right-most stop: Switch position n-2: send the + macro n times then the - macro twice Switch position n-1: send the + macro n times then the - macro once Switch position n: send the + macro n times I have used this sort of thing, and it does work, but if you have the panel in view it does look odd, with the switch turning all one way then back again. Might be worth a try, though. Note that you could edit the Macro file and add all these as separate macros, then just assign the switch postions to the macros for "Range5", "Range10" etc. Regards Pete

I just tried this here, creating 4 macros: Range-, Range+, Mode-, Mode+, for the Level D 767. They are then assignable and work well. If you can't make this happen, perhaps you need to go into more detail? Regards Pete

Okay. If the macros create and test okay, they should operate from your button or switch in the same way as the mouse. You said Didn't you create separate macros for the two directions (with the mouse one might show "-" and the other "+")? It sounds like you only created one macro for each knob. Regards Pete

EFIS module? In FSX? The default FSX EFIS controls? how do you do that? The default EFIS controls don't seem to be usable except with a mouse. Or are you referring to some hardware? If you could provide some sort of context -- hardware, add-on aircraft, etc, then maybe I could help. Regards Pete

Aha! That's how it should have been. so my code was correct in the first place! The problem was an out-of-date GFDev.dll on your system. I'll need to mention that on the release notes. What's the difference between having a button which is going from off to on or on to off, and having two buttons, one for each transition? I don't see the point. I never use more than one button number for a value which is either TRUE or FALSE. After all you can program for release or for press or for both. How does anything of this make any difference whatsoever for multi-engined planes? Please scrap 3.866. I will revert to my original code. Regards Pete

Which switch has no reaction at all? They all seem to operate at least one FSUIPC button number. Only switches like the magneto/starter, and the flaps up/centre/down need more than one button number. What you've got matches almost exactly a list I've got which is effectively crossed out in favour of the arrangement I was using in the previous FSUIPC update. Just in case GoFlight have actually changed the driver, could you please download the latest GFdev DLL, which I posted in the Updates announcement earlier too. See if you get different results with that. If not I'll try to deal with these issues (differences from even the crossed out list i have), if you'll please just re-verify them so I'm really sure: Pitot Heat none 8 Carb heat none 10 Fuel Pump none 12 Avionics none 14 Beacon none 17 Panel none 19 All those seem to be reversed -- the button number should appear when you switch from "off" to "on". Gear is supposed to be 1 for Gear Up and 23 for Gear Down, according to the list. I'll eliminate the "up" button number, just leaving gear down -- there's no centre off position, is there? The only other discrepancy is that the list shown 20 as Cowl flap up (closed), whereas you have it on 7, which the list shows as "not connected". I'll have to reverse that too, to give 7 when Opened. Tomorrow (Monday) nowI'm off to bed! Regards Pete

Yes, I could help. As I said, it has been done once, for Project Magenta, and worked -- until Austin changed X-Plane again. I think Enrico Schiratti was doing his best but couldn't keep up with Austin's changes.*** Unlike FS, which had a major update only every 2 or 3 years (and for which i've been lucky enough to be involved in Beta testing, so could smooth out the changes), Austin seems to make major changes quite frequently. Or at least he used to. Enrico gave up on it. Maybe the work done before could be resurrected and updated, but I don't know who would do it now. And looks at the positive side of no FSXI looming. It gives FSX a much longer life. With no changes to FS for many years, it does make an even better and firmer base for add-on developers, surely? Regards Pete [NOTE ADDED LATER} *** Note that this is the story as it has been told to me, but it is years old. I expect things have changed since then and, indeed, the story itself has been disputed, and I have seen messages stating that something like the "X-FSUIPC" you propose has indeed been produced. If this is truly the case, then the job seems almost accomplished without any need for further involvement by myself, doesn't it?

Okay. I think I see what they've done. The header file defines something different to what their GFDev.DLL actually provides. It looks like the DLL is providing a direct copy of the un-decoded bits from the hardware. I've made another build, 3.866, for you to try. Please download it with this link: http://fsuipc.simflight.com/beta/FSUIPC3866.zip If you could make your list again, the same way, even if it appears to work, it will be very useful, please. Regards Pete