Pete Dowson

Yes, you'd need to set those around you. I don't think FS has any way of recording weather for anything by the at the weather stations. Everything in between is interpolated. At some of the larger airports, in areas where there are several airports close to, and all are WX stations, you can get the weather varying over the one airport, due to interpolation. This can be a little odd when downloaded weather features weather for near stations with different reporting times! For READING weather, you can use either. If it's a lat/lon between stations it will be interpolated. For WRITING weather, the ICAO is needed -- not only that, it must be one listed in FS's list (which does change from time to time -- current one is the WxStationList.BIN in the same folder as your FS9.CFG file. Don't worry about the ".BIN" filetype. It's just a compact list of 4 characters per station, just the ICAOs). The positions and names are given in files in the weather folder in the main FS folder. It won't do any harm writing to invalid ICAOs. They just won't work. Depending where you get your METARs from, they won't necessarily correspond to FS's (from Jeppesen) in any case. The main weather programs do try to set stations which aren't listed and come to no harm. If you want to be sure, or even want a data base of positions and names, check out the files in the FS weather folder. note that locations (lat/lon/alt) are in 32-bit "floats" in those. Regards, Pete

You can do, but it's really more efficient just to write each part. Obviously the fields which are adjacent would be more efficient together, and this would apply really to anything less than 16 bytes or so apart (the overhead for a new block). But you can do it all in one process. The only thing to be sure of is to write the command (at offset C800) LAST, as it is that which triggers FSUIPC into action. I've just re-read that, and I've had to make a correction. Sorry. I was pretty busy and confused then I think. I shall have to write some extra documentation for the NWI, because even I had to refer to my code to make sure of some of these things. Here's the low-down on signatures and what triggers what. This is sort of a draft expansion for the current flimsy documentation, so please have a good read and let me know if it makes things clear: ======================== SIGNATURES and Reading Weather The signature fields are only really used when READING weather, in the CCxx offsets. This is to prevent one application reading one thing and another reading another before the first has picked up his data. Since, for reading, the signatures are so important, it is they which trigger the actual operation in FSUIPC of asking FS for the weather at XXXX ICAO or the particular Lat/Lon. When reading weather it is also important to wait for the TimeStamp to change to indicate that it has been read. This can give rise to some interesting situations if your program runs on a WideFS client PC. I have recently devised a scheme which I think makes things foolproof (and this applies to other read facilities in FSUIPC which use signatures and timestamps): At the start of the program, sleect or generate a pseudo-random number as a starting signature. Then, for each read: 1. INCREMENT your signature 2. Put together the FSUIPC block of requests and issue the Process call. The order would be: (a) read the timestamp CC04 (to be checked AFTER) (b) write ICAO to CC08, or Lat & Lon to CC10 & CC18 with all spaces to CC08 © write signature to CC04 (must be last to trigger the read) (d) read CC24 (e) FSUIPC_Process 3. If CC04 was read as non-zero, retry from step 1 (this is effectively a normal CC04 wait, in case something else was reading already). 4 Else, wait for CC24 to change (i.e. read CC24/process till CC24 reads differently). Now this is good for reading a single weather station, such as for giving ATIS reports or ATC instructions. If you want to read a whole bunch or stations or positions, for instance in order to build a weather map, then this will be too slow. Because you are incrementing the signature each time, the next request won't be accepted till the previous one has timed out -- about 8 seconds in the current FSUIPC. So, when reading a whole bunch of weather stations or positions, after the first time for the batch, you need to skip step 1 (i.e. leave the signature the same) and bypass the check in step 3. This is ONLY for that batch, mind. Next batch, first time through, you do the whole thing. COMMANDS and Writing Weather When writing weather to a WX station, via offsets C8xx, all you have to do is write all the assorted weather data you want to set, but be sure to write the Command value, at offset C800, last. It is writing that which triggers FSUIPC into actually doing anything. Prior to that, anything written to the rest is simply ignored. To avoid other programs interfering with what you want to write, it is best, however, to write it all in one call to FSUIPC_Process. In other words, you can have as many separate FSUIPC_Writes to set the various weather aspects (those you don't want to change could be copied direct from the Read area, of course). At then end of the sequence of Writes, you have one to write the command, then the Process call. The normal rules about efficiency apply to these writes. It is more efficient to have less numbers of separate writes, so writing larger areas, but only if this doesn't involve writing masses which you don't need. Writing all 1024 bytes is easier program-wise, but less efficient as far as the data transfer goes. But bear in mind that each separate write or read carries an overhead of about 16 bytes, and of course a little extra processing time in FSUIPC. After each weather write you do need to wait for the TimeStamp at C824 to change before writing the next, otherwise the data you then write may supersede the previous one. FSUIPC can only write one station at a time using the interface it has to FS's weather engine. ======================= I'm afraid that, although after clearing all the weather, setting GLOBal weather does take effect, the weather at each WX station gradually becomes localised. Once it is using its own local weather, no amount of simply writing GLOBal weather again will change it -- such writes will only succeed for stations not yet "localised" (i.e. usually those well out of range of the aircraft). I'm afraid, using only GLOBal weather, you would have to periodically "clear all weather" as well, to enable any changes. This would be okay if you could do it without it having any real effect until you then set the new global weather, but I'm afraid the effects are noticeable and not nice. What it comes down to, really, is that for decent weather control in FS2004 you have to set local weather -- i.e. weather at local weather stations. Yes. You simply specify the number of layers and provide the values for each. There's no automatic layer generation if that's what you mean. They are items in an ordered array, lowest to highest. Regards, Pete

I haven't heard any results from you on this, good or bad. If this is not yet resolved, I would like a couple more simple tests done, if possible, please. First, with the current FSUIPC, before running AS2004 at all, clear all weather in FS itself. i.e. go to the Weather folder and select "Weather Themes" and "Clear skies". Does it still crash? (This has probably been tried before, but I mention it just in case). Second, please install the attached FSUIPC 3.461. Then try AS2004. Let me see the Log. In this version not only do I trap errors but I try to identify which routine the error was in via flags, which will be logged too (as "Diag="). From this I may just be able to tell which FS routine is responsible. Of course, whether I can then actually do anything about it is another matter. The FS routines to clear and visualise weather are very complex and call lots of other routines, mostly indirectly via C++ type virtual procedure tables. Really horrible stuff to follow. Also, however, if a crash does occur before weather setting or weather clearing, the crash logging routine now clears down the FSUIPC flags telling it that there is a weather operation pending. Therefore it now may not actually loop, but carry on even without clearing the weather. I suspect this will make it crash somewhere later, and it isn't a solution at all, just a way of trying to get nearer an explanation. Thanks & Regards, Pete FSUIPC3461test.zip

There's nothing FSUIPC will do with any axis input UNLESS you have told it do. Simply go to the mixture part of FSUIPC's joystick options and press the button marked "Reset". Also make sure there are no "Map to ..." check boxes checked. Take a look at the page with the four separate mixture axes too -- maybe your real axis is assigned to one of those instead. If you want FSUIPC to revert to its default treatment of axes -- i.e. none at all -- then you can do so easily and completely by editing the FSUIPC.INI file before loading FSUIPC and deleting its [JoystickCalibration] section altogether. Finally, the current version of FSUIPC (6.45) includes facilities to log axis inputs (see the Logging options page). You could try that, briefly, to see the sorts of axis values which are arriving. They will be labelled too, so you can see if they are the generic all-engine values or the separate ones. They'll go to the Log and make a large file quite quickly, so only enable it for a short time, operate the mixture axis, then disable it and look at the FSUIPC.LOG file. Regards, Pete

There's no button to press. If WideClient is connected, that's it. All you do now on the client PC is run whatever program it was you purchased WideFS in order to run. If you want you can even edit the WideClient.INI file to get it to load the programs for you, all as described in the WideFS documentation. Regards, Pete

Hmm. I'm still not sure that there's nothing for me to be concerned about (oops, a double negative!), in particular the odd looping on the module check which seemed to be indicated in your Ivap logging. Are you saying that you now think you understand what was wrong, or are you, sort of, just starting afresh? If there's nothing for me to sort out, that's great, but if there might be I'd rather do so whilst there's a way of sorting it than have it come back to bite me later! :wink: And, yes, I think I will put just a few seconds of "grace" on Gauge access after I see aircraft reloads, just in case the odd gauge hang-over you demonstrated happens in real life! :) Regards, Pete

Well, Project Magenta (PM) has its own set of offsets which you can drive directly. I think that would be more efficient. The "virtual buttons" facility at offset 3340 is really for the more general purpose application of buttons to be programmed in FSUIPC. For the PM offsets you need to refer to the list avaialble on the Project Magenta site, http://www.projectmagenta.com/resources/docs.html. Regards, Pete

What "doesn't work" on the PC that does not have FS on it? What FSUIPC application are you trying to run? WideClient does not do anything much on its own, it os only an interface for other programs. Pete

Okay. Glad it is resolved. Regards, Pete

There is a freeware key for Squawkbox, but not this version. The details for the accredited version are given in the Freeware Keys list above. The main problem here is that the Product description is wrong -- there's never been a registration key requested or issued for a Squawkbox with a product field saying "sb2 Application". Perhaps your copy is out of date? Regards, Pete

So, not something which folks would do normally? All I can think of doing is allowing a few seconds leeway before eraing previos registrations. I can't just delay the recognition of a new aircraft loading, else that may occur after one of the gauges has registered. Anyway, I'll consider how to deal with it and meanwhile treat it as an unlikely fluke. You say "so far it works ...", so I am now confused. What were the logs and report about? Is that with a different version of your program? Please help me understand what is what here. As far as threads not terminating when FS terminates, I think this is related to when the assorted Windows are closed which process the messages. Certainly, FSUIPC will always process a message it receives before termination, but it won't deal with messages still in the queue when FS tells it to quit. In all my multi-threaded programs I takes steps to terminate the threads forcibly if they don't do so by themselves. You need a flag set by the thread saying "I'm running", and if that's still set when you are ready to exit, you use TerminateThread. for that you need the Thread handle from CreateThread. I suppose in the case where you are calling FSUIPC from a different thread this might be better -- but how many seconds? It is certainly never likely to be a problem when calling from the main thread. I really prefer to play safe and throw threads off forcibly Regards, Pete

The PMDG test appears to show an attempt to load the PMDG_737NG_Main.Gau with the aircraft "Beech Baron 58"! There are no other gauges listed as present in the whole list of modules in the FS process -- so I can only assume that, at the time this attempt to access FSUIPC, one of the PMDG gauges had not terimnated correctly, and in fact none of the Baron gauges had even loaded yet. It's a bit odd as this is a good 1.4 seconds after FSUIPC recorded the access to the Baron AIR file. Possibly aircraft do take a long time to load on your system? The many other PMDG gauges: PMDG_ACS PMDG_737NG_OHD_NAV_SOURCE PMDG_737NG_Overhead PMDG_737NG_OHD_PAX_SIGNS.GAU PMDG_737NG_OHD_ELECTRICAL_DISP.GAU PMDG_737NG_OHD_WS_HEAT.GAU PMDG_737NG_OHD_Flight_Controls.GAU PMDG_737NG_OHD_LIGHTS_LEFT.GAU PMDG_737NG_OHD_PRESSURIZATION.GAU PMDG_737NG_OHD_ELECTRICAL.GAU PMDG_737NG_OHD_ENGINE_STARTERS.GAU PMDG_737NG_OHD_HYDRAULIC.GAU PMDG_737NG_OHD_PNEUMATIC.GAU PMDG_737NG_OHD_LIGHTS_RIGHT.GAU PMDG_737NG_OHD_PROBE_HEAT.GAU PMDG_737NG_OHD_VOICE_REC.GAU PMDG_737NG_OHD_FUEL.GAU PMDG_737NG_OHD_ENG_AI.GAU PMDG_737NG_OHD_APU.GAU had all been unloaded (correctly) by then. The fact that this one remaining PMDG gauge was still loaded and obviously running after you'd selected a new aircraft is very odd -- either it had hung or was involved in something of its own and ignoring the outside world. When it accessed FSUIPC it obviously did not send a new registration to 8001 because it hadn't been restarted. This is the only reason for the error -- the module was, in fact, correctly identified this time too, but being a GAUGE not a module (DLL) it should have been registering itself on loading with a fresh aircraft. This continued presence of a Gauge through the reloading of an aircraft would cause this problem throughout the whole life of FSUIPC 3, yet it has not been reported before, so I can only assume you are doing something pretty unique to get gauges to hang about? Yes, but all that does is cause another module search to be applied, as you will see. In the PMDG case, the only registration error which actually occurred was this one: 198719 Stack 09 = 1DE7B660 PMDG_737NG_Main.GAU 198719 Module [M2] identified = "PMDG_737NG_Main.GAU" 198719 Illegal write attempt: offset 62FF, size 1 [M2] 198719Program or module not accredited for use with this unregistered FSUIPC for which the detailed explanation is as above. I would like to know how you achieved this phenomenon of a gauge running from one aircraft after loading a new one. Maybe it's a freak timing thing. Possibly I may need to get around it by not assuming an aircraft is actually changed when I see one being loaded, but allow a few seconds after that. However, this may cause other problems, so it isn't anything I'd undertake lightly, and it would only be a problem if bits of the supposedly unloaded aircraft kept accessing FSUIPC, as in this case. No such error seems to occur at all with FSINT.DLL. Anyway, with DLL's, since they are resident over the loading and reloading of aircraft, FSUIPC remembers their registration in the FSUIPC.KEY file (did you look in there?). This is because it is not reuqired for DLLs to send the data to offset 8001 each time an aircraft is reloaded. Now, what is odd in the Ivap log, is the apparent loop that FSUIPC seems to get into, scanning the modules and stack over and over. There's something wrong there. Evidently that thread mechanism I put into the ModuleUser library is not working in your code -- it works fine in my test code here, so there is something different. What were the symptoms you saw in the Ivap case? There seems to be no accreditation rejection. Are you now using the compiled library as I supply in the SDK, or still something of your own which is changed? There are by now a large number of users of this and you seem to be the only one with a problem. If you cannot figure it out, perhaps you would like to send a debug version of your code (with the .pdb file) so I can try to pin down what is wrong. Regards, Pete

You don't say what program you are talking about. Registration for FSUIPC or WideFS is dealt with entirely by the product sellers, for instance SimMarket. If you've followed the links to the correct page, and purchased the product, then you will receive your registration key from them within 24 hours, as it says there. If you don't, you will need to go back to them and raise a problem ticket. Please explain "How do I edit the Network Details and pretty much get it Working". You don't say what you've got or what you are trying to do. If you are, indeed, talking about any of my programs, then please check inside the ZIP you downloaded. Inside you will find some documentation. Please read that in the first instance. Regards, Pete

Okay. Let me know please. Also see if it's the same without FSUIPC installed (just temporarily remove FSUIPC.DLL from the FS Modules folder). I have changed the method actually used for the "fix control accelerations" option in 3.45, in order to provide more coverage -- so it deals now with keypress and mouse controls as well as those from joystick buttons, and also deals with XML gauges which seem to get their controls into FS by a route I was not previously intercpeting. But this facility is only designed to prevent acceleration when using buttons, keys, mice slowly, but controls from panel parts intervene and cause FS to accelerate (i.e. use increments of 10 instead of 1) when it shouldn't. By itself, FS will accelerate a control if the next one follows within 400 milliseconds (4/10ths of a second), which is surprisingly easy to get to even with mouse-clicking. I might look to see if I can change that to, say, 200 mSecs, if acceleration generally is a problem. But previously I've only heard of this in relation to interference from complex panels and possibly other add-ons. Regards, Pete

Sorry, I still don't know what control you are using. If it is one button, how do you tell it to trim up as opposed to down or vice versa? Please check the assignment of the button in FS assignments. If it is the standard TRIM UP or TRIM DOWN then I really have made no changes that would affect this adversely. And what do you mean by "middle acceleration in FS control UI"? I don't understand that term. It is very difficult for me to offer help with no information. You could try using the Event logging in FSUIPC's logging page -- it will send details to the log of every control event passing through FS2004. Regards, Pete

Even with default panels? If so, I have no idea what causes that. The "fix acceleration" option (in FSUIPC's Techincal tab) is designed to help prevent such control acceleration when using one of the few (but growing in number) panels which do send a lot of controls, repetitively. Check the controls actually arriving in FS by using the Event logging (FSUIPC Logging page). Are there a never ending stream of them? (You'd need to look at the FSUIPC LOG after a short test). If so, even if you are using default panels, you must have some add-in DLL installed which is sending them. Regards, Pete

Yes, it works fine. In fact it should be better in that it now operates with XML gauges too. You can log things now, in FSUIPC's logging page. Please check it for yourself. Whenever it sees a control which changes it will say that its fixed the acceleration. I assume you are talking about discrete controls, not axis controls, aren't you? You just say "trim wheel" but you don't say what's controlling it. I''ve never heard of the trim wheel being affected before in any case -- the only reports for over three years have been for things like heading bugs and MCP values. Regards, Pete

Something is interfering there. GPSout doesn't cancel or purge anything. It's very simple, it just chucks stuff out. That definitely is something else then. It opens a single "file" for writing, and that's it. It really is dead simply standard Windows code. Regards, Pete

It works perfectly. Did you look at the documentation at all? There's a Windows option which stops it working. You have to turn that off. See the user guide please. Pete

Well, like GoFlight and Joystick buttons, you can re-program PFC buttons and switches in FSUIPC. But you would need an autopilot which accepts keystroke shortcuts. Sorry, no idea. Don't they use the FS autopilot? There really aren't all that many that don't. If they don't, then you'd need to see if they provide keypress alternatives to mouse clicks. Alternatively there's the "Key2Mouse" program by Luciano Napolitano which could be used to turn FSUIPC keystrokes into mouse movements and clicks. Get's rather complex and messy though, and I'd hate to think how you'd adjust things like MCP altitude, heading, speed and VS with the rotaries sending keystrokes which operate mousclicks -- the latency of such a chain might make thing rather, er, odd. Regards, Pete

I try to make sure all the special advice already thought of is in the documentation! :wink: Regards, Pete

Yes, certainly. For example, such communication is done profusely between the several (external) modules of Project magenta -- spread over several PCs -- and by ActiveSky and FSMeteo. Both the latter have gauge or module components. Even some of the more advanced aircraft panels use these methods for communicating between internal components in FS. This is done via specially allocated areas of FSUIPC's offset memory. The allocations are made on request to myself -- it is done this way so that different applications do not clash with each other and corrupt each other's data. Because there is a limited space available (without considerable changes to FSUIPC and, especially WideFS), I ask applicants to work out their needs in advance, with due consideration for economy (for instance, using bits for TRUE/FALSE flags, not bytes or words, and so on -- i.e. only using the space that's needed). If you need to discuss details, write to me at petedowson@btconnect.com. Regards, Pete

Told you it wasn't tested! I'll look at it over the weekend if you send me the test program. Otherwise it will have to wait until I have time to write my own. Send to petedowson@btconnect.com. Regards, Pete

No idea, sorry. In the time FS has to make one frame it is doing all sorts of things, and drawing the graphics is only one of them. Presumably most of the actual calculations leading to the values you need are done early in the frame, as new positional data then needs feeding to the graphics routines which have to draw things. Whether the values I am mapping to are those evaluated initially, or derived some other way, I've no way of telling. I really don't even know if it actually is synchronously doing one computation per graphics frame -- it may be doing a lot more for all I know. It won't (shouldn't) be doing less, and I don't see a lot of point in it doing a lot more -- though that depends on its algorithms, presumably. But FSUIPC is locked to frame rates for obvious reasons. Updates to all of its client programs need to be as smooth as FS is, and that is the best way. Even if I did know when things really happen, your program would presumably be reading the data from an external program by sending a message and getting a reply. Even if you managed to get your timing synchronised to the FS recalculation loop, how could you guarantee to have the request in my code at precisely the instant after the values are recalculated and available? You cannot, in fact. On top of all that there are very very many things going on in FS which are simply not synchronous in any case. Most of the events (like input control movements) actually get posted via Windows messages. They form a queue and take their chances with everything else. I think all you can do is experiment and find out if you can get what you want. Regards, Pete

Safer to move it out of the Modules folder. If you rename it be sure to omit the "dll" part. Did you check the sensitivity setting in FS? For some reason it seems to occasionally reset sensitivities to zero -- that gives exactly the symptoms you describe. There's nothing else I can think of. Regards, Pete