Pete Dowson

3.454 I assume you mean? That's a relief really, as I've not changed anything in the weather section of FSUIPC. In fact nothing's been changed in the weather stuff for many months now. It's been very stable. Since the problem is FS itself actually crashing when FSUIPC is calling the FS "clear weather" routine, I'm lost. Something in FS isn't right, but unless I can reproduce it here I've got no chance. That's probably simply some grahics interference occurring because of the tight loop which is occurring between FSUIPC continually calling "clear all weather" and FS crashing into FSUIPC's error trap. Really, once that has happened once, which is right near the start, the rest of the session is worthless -- you cannot trust the software once it has crashed. The error traps in FSUIPC are only to aid diagnosis, not to allow attempts to continue. Unfortunately, in this case, the information isn't sufficient by the time the error is trapped. If I could reproduce it here I would simply trace through from the call to the Clear Weather routine to the point where the crash occurs -- it will be a jump to a virtual procedure that hasn't been set for the call for which the pointer is supplied. But it's nothing FSUIPC can be supplying -- the "Clear All Weather" routine is parameter-less, so there's nothing being supplied by FSUIPC. The crash is all to do with internals in FS. Okay. thanks. Here's hoping! Meanwhile, if I can think of a way of getting more information on this, I'll get back to you. Regards, Pete

There are some VERY odd things going on here. And worse, it is getting too confused with all the other things you are running. When debugging modules it is easier if you only have your module to look at. Could you, for starters, try again, but first: 1. Temporarily remove PMDGoptions.DLL from the FS modules folder. 2. Delete "LogWeather=Yes" from the FSUIPC.INI file.. We don't need all that stuff logged at presenrt. (Is your DLL trying to set weather?). 3. Don't run whatever it is that is writing weather (assuming that isn't your DLL?). 4. Edit the FSUIPC.DLL further by adding these lines to the [General] section: Debug=Please LogExtras=2048 This last might replace an existing LogExtras line. If you like, ZIP up the resulting log together with your DLL itself (and a source extract if you don't mind), and I'll try to work out what is going on. I've not seen such odd results before, and there are plenty of DLLs and Gauges using this interface. One thing. Is your module running entirely in the main FS thread, or are you using multiple threads? And are you using the very latest module user's library? Or have you extracted the source and 'adapted' it somehow? The correct library is "ModuleUser.lib" dated 10th September 2004. Regards, Pete

Looks like your Client PC can't handle the higher performance WideFS now offers by default. Edit the WideClient.INI file and set the "ApplicationDelay=0" parameter to "ApplicationDelay=60" and try again. I'll put some notes about this in the next release documentation. if I can make it auto-configure itself, I will, but I don't want to sacrifice the really good performance gains made recently. Can you tell me some details about your client PC please? Processor, memory, operating system, video card? Sorry, no. If you go back you'll have to stay back forever, because I cannot support older versions and we will never solve the problem you have. So you'll be stuck. Regards, Pete

Good. Best regards, Pete

I don't know. This part: 109469 Module [M4] identified = "FSUI.DLL" 110125 Module [M5] identified = "FSUI.DLL" 110156 Module [M6] identified = "FSUI.DLL" 111125 Module [M7] identified = "FSUI.DLL" Is worrying. FSUIPC already identified you earlier as Module 2: 85844 Module [M2] identified = "fsint.dll" 89109 Module [M2] "fsint.dll" access registration is okay but then on subsequent calls it cannot find you at all from the stuff placed on the stack. Have you changed the library code for Open2? You said: Why have you done that INSIDE the library code? You should do that when the Open2 call returns successfully! If you have altered the code I supplied, it is possible that you have mucked up the stack structure which my code prepares so that FSUIPC can identify you easily. Have you also altered other source code for the internal users library? Aren't you using the compiled library I supplied at all? BTW, whilst you are testing at this level it's a good idea to enable at least IPC write logging. Pete

Not directly, no. The FS autopilot works on headings and V/S with given target altitudes. You could try varying these until you achieve the pitch and bank you require, but I tend to think that it maintains a fixed bank till close to the heading, so it would be difficult at least for bank. You might be able to control pitch that way though. FSUIPC itself contains some (experimental) feedback controls for both pitch and bank, which work quite well for most aircraft I've tested it with. Download the FSUIPC SDK and check the FSUIPC feedback control text document inside. There's also a speed/mach control included which isn't quite as successful (it needs optimising, as it tends to overcontrol a bit). If you use the facilities I just mentioned you don't need to do that directly. I am particularly proud of the pitch control facility, in fact, because FSUIPC adjusts the pitch first by elevator, then trims the pressure out, just like a real pilot/autopilot would do. Surprisingly, although these FSUIPC facilities have been available for many months now, I've had no feedback at all. Project Magenta's autopilot was going to be the first user, but Enrico Schiratti, the author, has been rather overwhelmed with other pressures. So, if you do use the facilities, please keep in touch about how you are getting on. Regards, Pete

Hi Ted, Please try this interim test version of FSUIPC (3.455). In the controls drop downs (Buttons or Keys) there are, for FS2004 only, new controls: Engine 1 autostart Engine 2 autostart Engine 3 autostart Engine 4 autostart This was a little more complex than I originally thought, as the treatment has to be different for Jets, Props, and Turboprops. Also, as well as simply operating the starter and the fuel levers, to emulate the FS built-in all-engine autostart I had to deal with Battery, Alternator/Generator, Fuel Pump, Fuel Tank selector, and Avionics switch. I think I've covered everything, but so far I've only tested it for engines 1 and 2. Regards, Pete FSUIPC3455test.zip

Hmmm. That's very odd, because the crash with AS2004 is occurring when it asks FSUIPC to clear the weather, and all FSUIPC does for that is call exactly the same routines as the "clear weather" theme does in the FS menus. In fact, that's how i worked out what to do! Got them by email, thanks. But it doesn't help I'm afraid. Your three files are identical to mine. So, it's got to be somewhere else. You deleted the FS9.CFG file and got it re-created, so it can't be anything in that. It's got to either be a corruption in the FS program modules themselves (which is a reinstall as you suggested), or it IS one or more of the .WX files which is getting loaded and creating a bad structure. Maybe you need to delete the default FLT+WX file completely, so it doesn't even try loading it. This may give an error first time, but you can clear all weather manually in the weather menu, then save the new default. However, I would have most certainly thought that if any of those things were true, you'd get problems with FS's weather menu as well, so it remains a puzzle. I'll dwell on it, see if I can think of any way of getting more information. Meanwhile, if anything you try changes anything, please let me know. Did you try the attached FSUIPC 3.454, earlier? It shouldn't make any difference, but it is the one I'm using, so I am curious. Regards, Pete

Isn't there a message at the top explaining why? As mentioned in the documentation, if you program multiple buttons, or conditions and so on, in the INI file, then you can no longer edit them in the window. This is to keep the window simple for its main uses. If you didn't edit the INI file for such things, then maybe it has got corrupted somehow. Either way, you'll need to delete the entries (or double entries) in the INI file. Regards, Pete

Well, further to my last surmises, I've tried your wxstationlist, no problems. I've downloaded real weather -- got a slightly DIFFERENT wxstationlist, again -- no problems. So it isn't directly related to that file. This is therefore really a puzzle. I look forward to hearing your findings. I can't see any other files here which may get changed by downloads, nor really corrupted. But just in case, perhaps you could Zip up the contents of your FS "weather" folder -- just the three files: wxmapping.bin icao pos.bin wxstationlist.BIN Mine are dated 30 APR 03, 5 MAR 03 and 26 APR 02 respectively, so they obviously aren't touched by weather downloads. But I'd like to compare yours with mine, just in case they've got corrupted by something else. I attach the latest test version of FSUIPC (3.454), which has some other changes but nothing in this area. However, it would help if we are using the same version, just in case. Thanks, Pete FSUIPC3454test.zip

Thanks for the files. The FSUIPC log shows that the crash is happening on the (simple!) "clear all weather" call from FSUIPC, right at the start! It isn't even trying to set or change any weather yet! I am now very suspicious of the FS download site. I think it is at the end of December, or in January perhaps, that Microsoft/Jeppesen must update the weather station list on the FS weather download site. I seem to remember the same sorts of crashes in FS occurring this time last year too. I'm going to save a copy of my own weather station list then download some weather and see if some weather stations have been removed. What I think may be happening -- and this causes crashes in FS without FSMeteo or AS2004 -- is that there are WX or other files which refer to weather station index numbers now vacant because the weather station is lost from Jeppesen's list. Either that, or (perhaps more likely?) the update itself goes wrong and creates a corrupt list. This seems to do no harm at the time, but probably creates bad structures, or structures with bad pointers, in the weather matrix inside FS. Then when a weather program or something else comes to change it, crash. Not sure if I can find anything, but I'm going to look. Meanwhile, please can you confirm or otherwise that you have used FS downloaded weather in the last few weeks? Also, without using ActiveSky, can you try clearing all the weather via FS's weather menus, WITHOUT running ActiveSky at all. In fact, try all sorts of things with the menu. I have a feeling that you may be able to crash FS quite easily. BTW you sent me the wxstationlist.BIN file. Thanks. This is dated and timed exactly the same as the FSUIPC log and FS9.CFG file. I'm not sure how they all got to have exactly the same date and time, but did you actually try moving out or deleting the original, like I suggested? I also compared it with mine. There's one weather station missing. I've not identified it yet, but I'm going to try using your list on my PC. Perhaps you could try the one from mine, attached. Regards, Pete wxstationlist.zip

That'll be because you have the wrong version number in your Linkage structure. Whatever you've written to connect to FSUIPC (FSUIPC_Open2(...) and linking to the module user's library I hope?) evidently isn't running then, or it is and is wrong. Don't you have any diagnostics built in to help you debug it? Doesn't your compiler come with a debugger? Sorry, but I cannot tell you how to debug programs. You need to think about how you are going to test it rather than plunge into the deep end. And debugging DLLs deep inside FS isn't easy -- the Microsoft Visual Studio debugger can do it, though. What docs did you hope to find on writing and debugging FS modules? Microsoft don't really approve of it and certainly won't encourage it. No, that's a version number check, that's all. Regards Pete

He started a new thread for some reason. Please see re: writing active weather to fsuipc from active sky Pete

No, this was solved recently, by Lee Glover, and the solution is documented explicitly in the WideFS documentation, under the heading "PTT (push to talk) for Roger Wilco, AVC and TeamSpeak" There again, that word "latest". Folks always say "latest", yet time and time again I then see logs and things relating to months old versions. "Latest" just means "the latest version I saw" or "the latest version I could be bothered to download". Please ALWAYS give version numbers. Regards, Pete

Oh, the transponder. Yes. I have these simulated on my PFC kit, but they don't do anything in FS at all. They must be specific to Squawkbox. I see Jamie has given you a good answer (thanks!). Pete

Sorry, I don't know. AdvDisplay just records the screen coordinates then places itself there each time. It works fine here. If you check the AdvDisplay.ini file you should find the screen coordinates it records for its "Locked" position. Maybe it's something to do with the way the video drivers define those coordinates. Does FS successfully remember moved panel parts? I know a lot of folks have difficulties with those too unless the video driver supports the multiple monitore as a single "wide" screen. "Docking" is similar, but the window then comes and goes with the panel part -- the panel part does not control the position. You might be better Docking it to the main panel on the main monitor even if it is positioned away from it. Panel names are used and you can edit the [AdvDisplay] section in the relevant PANEL.CFG file in order to change that. I think the names used follow the names given in the PANEL.CFG file, so the main panel will be either "Main Panel" or something like that. Regards, Pete

Well, there's no siginificant difference there at all. Unfortunately the vital piece of information is missing -- "at 00000000" should give the address at which the crash occurs. Looks like something is jumping via a link which isn't set. Well, possibly. But let's not quite do that yet, please. Maybe we can find out more. This may produce a HUGE log, so please don't let it run long, and maybe truncate it after the first **** ERROR block occurs. Or otherwise ZIP it up and send it to me at petedowson@btconnect.com. First, before loading FS, edit the FSUIPC.INI file and add the following lines in the [General] section: Debug=Please LogExtras=2048 LogWeather=Yes LogWrites=Yes (replace any lines with the same keyword). Then run FS, load the weather program, get the problem, close FS and see how big the log is! The main suspect is still some discrepancy between the weather station list and the stations in some weather file, but I would like to get a proper diagnosis if I can. Did you delete your wxstationlist.BIN file? If not, perhaps, if you ZIP the log to me you could include that? Thanks, Pete

I must correct you. You are very much mistaken! The only possible reason you will get a problem with a registered copy of FSUIPC and not without registration is that you were using either a time-limited key, or more likely a stolen or counterfeit key. Good, genuine keys, purchased from the appointed outlets, work fine, and in fact operation is more efficient then because all of the individual application access checking, which is occurring all the time the application is running, is by-passed. Of all of the folks I have asked to send their KEY files to me for checking, after they reported problems indicating the possibility of a counterfeit key, only three have ever done so. With two the keys were genuine and the problems did lie elsewhere. The third was ceertainly an illegal counterfeit key. The fact that all of the others never followed up, and never came back for more support, is suspicious in itself. Should I add you to my growing list? Regards, Pete

If you don't mean as PTT (Push To Talk), which is what I assumed you meant, then I don't understand. You surely don't mean to use as a Morse tapper? :wink: PTT for both Roger Wilco and AVC are built in as special controls in the drop-down lists in FSUIPC's Buttons assignments page. If you are using TeamSpeak instead, then just assign whatever Key press is used in TeamSpeak. Look at the Buttons page in the FSUIPC Options, on screen (Modules menu, select FSUIPC). You will see you can assign controls or keypresses to buttons there. If you want to tap out Morse Code on your button that is another matter. I wouldn't know how to advise you on that! Regards, Pete

It hasn't arrived yet. Maybe, as it is a "key" file, if you didn't ZIP it, it will be removed by my ISP as a potential hazard (Key files are also Registry updates I think). Since it is a text file, maybe you could just dump the text into a your email message instead? Also, please check that you got my email address correct: petedowson@btconnect.com. Regards, Pete

It's probably 255, and it is because you are using WideFS 6.44. this was fixed in the interim releases posted here (6.442 and 6.447) with a big announcement at the top of the Forum, and then in the current release which is 6.45. Remember? I did say this a few messages back: First thing is that you are using an out of date unsupported version of WideFS. Current is 6.45. Use 6.45 then we'll talk about it. I cannot possibly support old versions. I spend enough time fixing things and making things better, I cannot keep repeating the same things after I've done that. If you still get problems with the current supported versions of my software (FSUIPC 3.45 too), THEN get back to me. Pete.

Yes, and all that does is toggle that bit in that offset. What then happens is up to PM software. Why are you thinking about entering anything by hand? I don't understand where you are going now. All of the PM stuff is accessible in the drop-down. I only referred you to the Advanced guide because it contains a list of some of the parameters for a couple of the PM offsets -- the MCP Kcodes and the GC options. But the controls for these are in the drop-down, you just need the parameter values to enter into the box marked "parameter"! The PM offsets list on the PM website gives a full and more up-to-date list. Regards, Pete

Going back a bit, you said this: Wouldn't it be easier for everyone (me included, I think) if I added such new controls to FSUIPC's repetoire, instead of messing about with delay specifications and things? If you just want separate engine autostart facilities, remind me please exactly what the "all engines" one does in FS (I don't think I've ever used it!), and I'll see about doing the same for separate engines. Regards, Pete

So you combine turning the fuel on with operating the starter? That needs a little editing in FSUIPC's INI file to place two controls on one button. What would happen (in FS I mean, not in the real thing), if the switch was left in the start position indefinitely -- i.e. akin to the "continuous ignition" mode in Boeings? Well, at present I've not really any idea how to actually specify such a complex sequence in the current structures FSUIPC uses. If a button is ON, it is ON. Are you using a toggle, or are you saying you want a momentary button push to look like it stays on even after it goes off, for a period of so many seconds? The latter sounds feasible, even if messy to present in a user-friendly manner. Regards, Pete

Are you talking about EpicInfo? You really need to mention context please. If so, check the FSUIPC_READ facility, for reading any FSUIPC offset into your choice of PH. Regards, Pete