Pete Dowson

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

Yes. If you have TeamSpeak on the same PC as FS and FSUIPC, you simply program the appropriate keystroke, as assigned in TeamSpeak. I understand TeamSpeak does not "swallow" the keystroke, so you need to choose something not used by anything else. If you are using TeamSpeak on a client PC under WideFS, then please check the WideFS documentation. Facilities were added recently to enable this to be implemented. Regards, Pete

that means "I'm on holyday until Feb 8th, I will reply as soon as possible" Oh, thanks! What a nuisance. I prepared all these tests and extra diagnostics to find out what was going on with his WideFS installation, now I have to try to forget it for a whole 4 more days. :cry: :cry: Regards, Pete

Well, there's a thing. Problem reported, problem solved, and all whilst I was sleeping! Good goingand thanks Jim! :D :D :D These clouds. Are they good? What are they? I wouldn't mind trying some improved clouds myself! Regards, Pete

Hi Eric, I received the logs I requested, but they leave me very puzzled. It seems the Server is not even trying to send anything at all to the Client. This is very odd because the changes in the Server have been small, mostly cosmetic and associated with the logging. I tried to send you some files and ask for more tests, if that's okay with you. Unfortunately though, I go this reply: I don't know if I should re-send or not. Please let me know. Regards, Pete

HmmmWhy did I send 3.457, above, then? I never tested them for ground handling, of course. they were only meant to be for use in an external autopilot. That's probably a bit slow. Add to that the extra latency (by the time you see the values they've already changed) and you'd have some difficulty getting smooth control and avoiding over-compensation. No, there's no way to change turbine or prop speeds directly. My control is only throttle, nothing else. Similarly the pitch is elevator (optionally trim, but normally only trim after pitch is achieved) and bank is aileron. Regards, Pete

In C/C++ on a 32-bit PC an integer is 32-bits, as is a long. An unsigned integer is the same size. They have to be "short" to be 16 bit. In modern compilers 64 bit integers are also supported (long long, I think, or in MS compilers _int64). I don't know VB. I think VB users have enormous problems with strings, judging from all the questions and problems arising from that subject, so I would think you'd need to keep clear of them altogether. But, again, I don't know VB. I hope a VB expert will help you. Regards, Pete

That's odd, because that pretty well makes it like 6.44, for most purposes -- except for the crashes which could occur with 6.44.. Before you tried 6.45, what was the previous version of WideFS you used? Set the ApplicationDelay back to 0. Change the Log setting in WideServer.INI to "Log=Debug" Change the Log setting in WideClient.INI to "Log=DebugAll" Run Fs. Start WideClient when FS is ready, then run, say TrafficLook. If it doesn't appear to work, close FS, close WideClient, ZIP the client and server logs, and send them to me at petedowson@btconnect.com. Include the INI files too please. Regards, Pete

Too nice, and I shouldn't do this. :wink: But try the attached interim test version 3.457. If you set flag 2^3 for the speed control it uses GS as the reference instead of ASI. Still in knots -- I do the conversions for you. This is untested. Let me know how your experiments go! Really the only advantage having this code in FSUIPC rather than in an external application program is that it is closer to the simulation and, in theory, can react faster and therefore, hopefully, obtain more accurate control. This certainly seems to be the case for pitch and bank which give great results, but speedugh! I'd like to improve the default parameters for the speed and mach controls, so if you find better ones for specific aircraft, let me know. I could build in a table for the defaults, making selections based on gross weight, engine type, etc. Regards, Pete FSUIPC3457test.zip

Good! All's well thatetc. :wink: Regards, Pete

Thanks for the invitation, but I am declining. Sorry. I don't like the sound of my own voice and really would not like to inflict it upon anyone. It is bad enough having my picture up here -- I was persuaded to do that, against my better judgement! 8) (Which reminds me, I really should replace it -- I am two years older now, and look more!). Best of luck though, in finding "good" candidates! Regards, Pete

Well, two things of note. First is that of the three controls provided (pitch, bank, speed), the first two are working well but the third needs some work on "tuning" the values I am using -- they are adjustable in the interface, but I haven't found values which suit all aircraft. Second is that the speed control is based on either Airspeed or Mach, not Ground Speed. You are okay on the ground as long as there's either no wind or the wind is lateral (cross) only. If there's any head wind you'll go too slow (if at all), and if any tailwind youl may go too fast. I would have thought doing a simple ground speed control would have been relatively easy, especially if you don't mind dabbing the brakes now and then too. After all the range of speeds is very small, as is the usable range of throttle you'd consider. Regards, Pete

I think they are available, do a search through the offsets list. That's what I would have to do in any case! :wink: Yes, but be careful. Some panels do this by their own internal sub-systems programming. It doesn't necessarily mean that FS itself is simulating these things. It probably does for the basic default aircraft, but there are many sophisticated add-on aircraft with panels which simulate or derive all sorts of other things not dealt with by FS. Best to always check through the offsets list to see if what you want is there. Observe it with FSInterrogate to check. If you do find anything you really do think must be from FS which isn't listed, then mention it and I'll see if I can find it inside FS. Regards, Pete

The latest version of the library should work from any thread because it provides the callers address in the first 4 bytes of data when making the call to FSUIPC. The previous one would only work from the main FS thread. If FSUIPC was called from a different thread, it had no way to identify the caller as the return address would be on a different stack. Are you sure you are using the latest version? Well, the source provided, dated 10th September 2004, is the source for the version which should work okay from threads. The crucial bits of code are: m_pNext = m_pView + 4; // Allow space for code pointer in the Open2() part, __asm { push eax call next next: pop eax mov dwError,eax pop eax } *((DWORD *) m_pView) = dwError; dwError = SendMessage(m_hWnd, WM_IPCTHREADACCESS, (WPARAM) (m_pNext - m_pView - 4), (LPARAM) m_pView); m_pNext = m_pView + 4; in the Process() part -- noting especially the message being "IPCTHREADACCESS", which tells FSUIPC that the caller address in in the first 4 bytes. If you had these things in place I really don't understand what could have been going wrong. Didn't you try the Logging with Debug=Please LogExtras=2048 set? That would show the stack search if FSUIPC had been doing one. It doesn't do one if the above code is correctly in place. Regards, Pete

Does a real Garmin 530 have a serial input and accept standard NMEA sentences to tell it positions and so forth? Also remember, GPSout is one way -- there wouldn't be any input back from the Garmin to FS. Pete

Annunciating what? If you mean something like the 737NG "six-packs", then most of the things annunciatred on those aren't even simulated by FS. I believe you'd need something like Project Magenta's "pmSystems" to program the correct subsystems. Regards, Pete

If you mean FSUIPC offsets for program access to FS innards, that is entrely contained in the FSUIPC SDK (http://www.schiratti.com/dowson). If you mean FS controls, then there's a list of those I know of included in the current FSUIPC.ZIP package. If you mean added controls by FSUIPC, they are listed in the Advanced User's guide in the FSUIPC.ZIP package. That question doesn't really make any sense. There are no "hex codes" for such things. The programming interface FSUIPC provides is by offsets from the base of an imaginary (conceptual) memory area. This derived from the way FS used to be controllable by changing values in its own GLOBALS.DLL (FS98 and before). Though FS has changed considerably since then, FSUIPC maintains the illusion so that programs can be written to be compatible across versions. Please see the SDK. There's a programmer's guide inside. There are things known as "events" (actually "KEY EVENTS" to be precise) in FS. These are instigated by FS controls. They can be programmed on buttons and keypresses either in FS itself (FS Options-Controls-Assignments) or, for a far larger range, in FSUIPC's own Buttons and Keys programming options. See the list of controls I already mentioned. Regards, Pete

Before you do that (if I've caught you in time!), could you try the attached 3.456? I checked through the code for "clear weather". In fact it isn't ONE call to FS, but four. This reproduces what I saw happen in FS when you clear the weather there. However, I am not sure that the middle two calls are really needed, so, just as a test, I've removed them in this version. The first call clears the weather, the last call makes it visual. I thought the intermediate ones were to do with populating all the local WX stations with default weather, but maybe FS does that in any case. I'll carry on testing here with FSMeteo and ActiveSky, but please try there too and let me know. This is a sort of last-ditch attempt from me, really. The set of four calls for clear weather have actually been there in FSUIPC since FS2004 was first released, 18 months ago. I've a feeling that all this may do, if it does do anything, is move the problem to the first real weather setting call, instead of the clear weather call. But if it does move it, at least i will know it is something to do with one of those two routines I've removed calls to. Regards, Pete FSUIPC3456test.zip