Pete Dowson

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

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