Pete Dowson

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

You have Squawkbox installed in some peculiar way. As far as FSUIPC can see, the program name is "SQUAWK~1". It will never register with that name. You need to sort out the SB installation so that it loads with normal Windows program and path names, not those DOS 8-character abbreviations. Check with SB support if you used their installer. As listed in the Freeware keys list above, the correct name to enter is "SquawkBox", but this has to match what FSUIPC sees to be running, which it doesn't at present. Regards, Pete

You are certainly wrong. In both places! First the Program name is clearly FSGarmin530 (see the emboldened part in the Freeware Keys list -- you are entering the Product name, which isn't the same!_ In the Key, that 1 should be an I. Try cut and paste if the font you are using in your browser doesn't show the difference. Regards, Pete

Check the Programmer's Guide in the FSUIPC SDK (http://www.schiratti.com/dowson) No, never. Nowhere near in fact. 1 millisecond would represent 1000 frames per second being calculated, if not displayed, in FS. How are you going to achieve that with today's hardware? Even process switching is going to take nearly that long, often significantly longer. Most things in FS are calculated frame by frame, and even if they are performed quicker there's no way to get at them faster. Regards, Pete

There are some freeware traffic radar gauges which don't need any registration, and there is also of course my own TrafficLook (not exactly a radar though) which is included. There are also payware panels and gauges with traffic radar (TCAS), and mostly they already have accreditation so don't need you to pay for FSUIPC. If you really want to purchase FSUIPC, check the various payment methods on SimMarket (and reproduced in one of my announcements above). I think they offer most possible methods. BTW the current version of FSUIPC is 3.45, not 3.40. Please always make sure you get the latest. See http://www.schiratti.com/dowson. Regards, Pete

As far as I know TeamSpeak does not look at buttons, only key presses. This is why I was talking about keys and keyboard focus, NOT buttons. You have to select a Key press in TeamSpeak, then, in FSUIPC, you would program your button to send that keypress (see FSUIPC's Buttons tab, left hand side). Since most keys are already used in FS you'd need to be sure to select one not required then delete any assignment to that same key in FS. As far as I know TeamSpeak only offers the PTT via a keyboard key press, and that is selectable in TeamSpeak, so there is no way I can do it automatically in FSUIPC. It was different with RW and AVC which both provided registered Windows messages for the PTT on and off functions! Doesn't TeamSpeak come with any documentation at all? You'd think they'd mention how to set their own PTT option in their own documents, wouldn't you. :x How did you get to thinking they supported joystick buttons? None of the others do as far as I know. Regards, Pete

Sorry, I do not have TeamSpeak or know anything about it really. I don't fly on-line at all. The information I have is from another thread here, a few weeks back. By "not swallowed" I simply mean that the user who helped solve the problem with WideFS (now published in the WideFS documents) said that, although you can assign almost any single key to TeamSpeak for PTT, and that it will capture it with or without FS having "keyboard focus", the keystroke is actually still allowed to pass onto whatever has focus. In other words, the keystroke is not "stopped" (swallowed, consumed, used up, ...) by TeamSpeak. That is a bit awkward. For instance, if you assign "G" as the key, then every time you press it for PTT you will raise or lower the Gear! See? Whatever keystroke you choose, be sure to de-assign it from any function in FS. Regards, Pete

Yes, I checked. It was indeed tested here with MyIE, and I think you tested it okay there too? This is about two months ago! Since then FSUIPC 3.44 and 3.45 have been released. What has changed? Aha! I think I see it: In this log: you have changed the Product name! The registration you requested was for: Product="MovingMap" Company="RanaInside" You cannot expect to keep changing the registration details and have the Key still operative! Here's the good log from two months ago: Regards, Pete

I don't know if that is your personal FSUIPC key or not, but I have had to delete your message in case it is! You must never publish your personal user key. It violates your purchase agreement! If it is not your user key, why have you a line reading "FSUIPC Key= ..."? If you want help with aut-registration by program, please turn on IPC Write Logging, and also tell me more about how you have programmed this access. Regards Pete