Pete Dowson

Yes, when you reload FS it fails to set the interlocks correctly. I said all that twice in my last message! It should work if you make the programming "aircraft specific", as I said. But don't bother if it is a trouble for you. I will fix the problem soon, as I also said. I thought I explained all the options in the last message. Please scan back up the thread and check again. Thanks! Pete

Yes, of course. Exactly right. Well done. If you program buttons in non-aircraft specific mode they will appear in the [buttons] section. no need for a [buttons.Common], as you suggested. It's already there and has been for a long time! :wink: Your term "paint" is my term "aircraft name". It is the only way I know how to distinguish different aircraft. Why do you use the term "paint" instead? Each aircraft listed with a different name is a different aircraft. Regards, Pete

Are you irriatating? Not here you haven't been! :) What is this then? "The actions can be programmed differently for different aircraft. Just check the box “aircraft specific” and then everything you program will operate for the currently loaded aircraft only. Anything programmed without that checkbox selected will also be available, unless overridden by an aircraft-specific assignment." (User Guide). and: "The button programming is saved in sections in the INI file. For globally operative buttons this is called [buttons]. For aircraft-specific buttons it is [buttons.]." (Advanced User Guide). Maybe you are looking at older editions? The documentation is updated for each release in the ZIP. Regards, Pete

Program them in FSUIPC to something innocuous or harmless, or maybe other things you want to use. At present there's a bug in FSUIPC (3.20 and 3.201) which means that this action does not always override the PFC settings upon reloading FS -- I am fixing that now and will release 3.202 later this week. Ahsorry. That bug was found whilst I was away -- there's another thread on it here somewhere. I am fixing it. I think the bug doesn't affect aircraft-specific button programming, so if you only fly a few aircraft you could try programming them as "aircraft specific" for now. BTW I don't override any of the A/P buttons and dials and they do no harm -- only the toggle type switches can override anything else in any case. Regards, Pete

You'd have to use normal Windows APIs. Are you writing an FS module or Gauge? If so, just use normal Windows methods. If you are writing an external program then I'm sorry, but this is not a facility FSUIPC provides. Your best bet is to use a single Modules menu entry to allow the user to call up a dialogue of your own. You'd probably want to opt for FS to pause too whilst the dialogue is visible, and you'll have to take steps to get your window to the top. In FS full screen mode this can be a bit of a problem since FS2004. You may get flashing. Regards, Pete

I've been trying to work out what could be going on with your system. You say: ... but I don't see how this can possibly be FSUIPC because by using a new default FSUIPC INI you most definitely have go no PFC buttons programmed in its Buttons page. Frank's problem is entirely different and I think I've found that. By default, without Project Magenta's MCP running, the GPS buttons in PFC do nothing -- they aren't even all available for you to program. In fact the ones you mention (NAV-GPS, D->, MSG, ON-OFF) are only programmable in FSUIPC -- in PFC with no PM running they are dead, ignored. In order to understand what is happening on your system I need to know rather more about what you've got installed, what is running, what you've programmed. Please also check those buttons in PFC test mode. If the PM MCP is running, then NAV/GPS toggles "N1" (TO/GA by default in FS) which could cut the throttle, ON/OFF is the IAS/MACH selector, D-> sets A/P SPD mode and MSG is VNAV. None of these latter ones would do anything noticeable if the A/P is off. Erthis is even more puzzling, as there are no changes in FSUIPC which would affect PFC. They are different programs. I really need a lot more help understanding this, please. Regards, Pete

That cannot be anything like Dave's problem as he explicitly stated he was starting with a fresh default FSUIPC INI file -- i.e. with no programmed PFC buttons in FSUIPC at all. After several hours of NOT being able to reproduce your problem, Frank, I found it -- the programming of PFC buttons in FSUIPC does override the PFC action, but only in the same session you programmed them, or if you change some other programming in the Buttons page so making FSUIPC scan the data again. Took me ages as I didn't realise you needed to program the button, close FS, then reload it before you got the problem! Seems the initial loading of the data from the INI file isn't setting the override matrix correctly. I'll fix that, it is easy enough, but Dave's problem is something else entirely. I cannot understand it. Regards, Pete

Oh, right. Seems I don't cross enough time zones in my flying to notice any of these things, and I do try not to crash into the ground! :wink: Regards, Pete

ErI don't see how that could be. What is it the location of, then, if not the tower? Further: I think you are making a mistake in the computations somewhere then. Maybe you are treating the lower part as signed? An easy mistake to make. If I go into the FS Map facility and change the KSEA tower location to N47 dead and W122 dead and 800 feet dead, this is pretty well exactly what the 0x0D50 read out then changes to. I'm only monitoring it with FSInterrogate, but it always follows whatever values you set for the Tower. Of course it doesn't. As I said earlier, the tower position is an arbitrary viewing position, which doesn't even have to be at an airport and which can be placed anywhere by the user. To determine the ICAO of an airport given any LAT/Lon you need to search a database and find the nearest and hope you have it right. How else do you think it would be possible in any case? Am I missing some magic computation based on arbitrary positions? Regards, Pete

Oh,right. That's useful to know. Is that what FSRealTime does? I thought the old (FS98-compatible) offsets worked. Thanks. Pete

V/S Hold has been a non-implemented documented facility of FS for many versions. I don't know why it is still listed, as there's never been any code attached to it. To hold a V/S simply set altitude hold, set the target altitude, and set the V/S value. The V/S won't stick without an altitude to reach different from the current one. Well, I would like to do something with all the displays, but it won't be immediately. It would probably have to be a different module as it isn't really in the scope of FSUIPC. It might need to be along the lines of EPICINFO.DLL (maybe "GFINFO.DLL"). But no promises about timescales. There's so much else on my list. And I'm waiting for some more GF units too to sort things out. Regards, Pete

If a button is programmed for a specific aircraft, it is programmed for that aircraft and this overrides any general programming for that button. If you don't program for specific aircraft then the programming applies to all. It is very very simple. Look in your FSUIPC.INI file. The [buttons] secion are the general ones and apply to all aircraft UNLESS overridden by something in the [buttons.aircraft] section for the current aircraft. Also you can't program a button PRESS and RELEASE separately in different sections -- obviously that would be chaotic. Well, apart from "deletions" that is EXACTLY how it works, and how I thought I had documented it. You did refer to the documentation, didn't you? I don't see any point in providing local deletions. If you don't want to use a button don't use it, or assign it to something completely useless or innocuous. Your "[buttons.Common]" is the "[buttons] section already there. I don't want to get into this: "[buttons.CS727 *] valid for all paints", That's horrible. Why on Earth would you want your controls to be different just because the colour outside is different? If you want to have hundreds of planes with minor variations just cut-and-paste the sections in FSUIPC.INI. Isn't that easy enough? I don't want to make the User Interface any more complex than it already is. Sorry. HmmmI knew it was a mistake going this far .. :o Regards, Pete

How does it know what they are? The interface just wants an address and a byte size. It doesn't care at all what the data in or how it is composed. A 12 byte array might be 12 bytes, 6 16-bit words, 3 32-bit ones, or some weird mixture. All it wants is an address and size so it can keep building the block which will be sent by the Process call. The SDK contains all the information about the FSUIPC interface and all the source code. It even has the source code for the libraries supplies for C/C++ programmers -- but in the case of VB and VB.NET and so on I understood it was only source code. Surely you do whatever you like with it. It is only trying to help folks understand how to interface to FSUIPC. No one is making any restrictions as far as I know. You've lost me here. It sounds as if VB.NET is really very restrictive to programming. All the FSUIPC interface needs is an address and a size. I would have thought that's all the parameters to the calls needed to be, whatver the real data is. I know there's a problem in VB about passing pointers to strings, which is why the WriteS function was added. That seemed a bit odd to me too, but you seem to imply that it goes much much further. Ugh. Regards, Pete

Genuine USB, or merely a USB serial port adapter type interface? PFC do that. If the USB device actually shows up in your PC's Device Manager as another "COMx" port, then it is really a COM connection like the PFC badged products. If it is genuine USB and looks to Windows like a set of joystick axes, then you should be able to calibrate it and allocate stuff to it in FS without any problems. If it looks like a Windows HID/joystick then it wouldn't need FS9-specific drivers. Regards, Pete

Are you enabling the FSUIPC magic battery facility? This is what it does, basically -- keeps topping up the battery at a rate depending on the parameter you set. Hmmm "increases"? Decreases you mean? -- the value -2.xxxE-100 is EXTREMELY close to zero whilst -7 is a big drain on the battery, isn't it? I would expect +n to represent charging and -n to be draining, as on ammeter indications for batteries in cars. I would also expect the load on the battery to approach zero when the generators are supplying instead, wouldn't you? Maybe it would go positive (charge) if you switched all the instrumentation off? I assume they are values measured in different places, but where and what they might be used for I'm afraid I've no idea. If and when you find out, please let me know and I'll maybe add some notes in the Programmer's Guide. However, most (all?) of that stuff is in the second table which I'm not sure is even supported/supportable really. Sorry. If I knew about all that stuff AND thought it was reliable and working, I'd document it better and maybe even move it to the first table where it would be supported. But so far either no one has investigated it, or if they have they've not told me. Regards, Pete

I think you have to set both the Zulu and the Local time, not just one or the other. Maybe also the difference between them (0246). Pete

I don't know. How does the Elite 6-lever device connect? Is it a USB device, or Game Port? If so it should be recognised by the Widows "Game Controllers", at least with the correct driver. If you can get Windows to recognise it and calibrate its levers there, then you can assign them in FS with no trouble. Otherwise you cannot use it with FS -- unless Elite do a special driver for FS for their devices (for instance, if it is COM port connected like the PFC devices). I know PFC makes stuff for Elite, but Elite have their own proprietary protocol for their branded consoles, and they certainly need their drivers, not the PFC one I do for FS. It is likely that their quadrant is based on the same system, in which can you'd need to ask Elite whether they have a driver for FS. Regards, Pete

FSUIPC is only showing what FS is telling it the throttle input is doing. If it is changing there it must be changing in FS, because that is all FSUIPC displays. Maybe you have the engine connection broken for it -- try pressing E then 1 2 3 4 (on the main keyboard) in FS. This tells FS to control all 4 engines with the main inputs. Check FS help for stuff like this, it isn't part of FSUIPC at all. Regards, Pete

Ah. good. I got a bit concerned there! :wink: Regards, Pete

I think you can omit the scan code -- if not I think there is a Windows API which will give you a scan code for a virtual key code. Without experimenting with it I'm afraid I cannot be more exact. This feature was programmed into FSUIPC several years ago, and I use it in WideClient (as it says), but without going through code I really couldn't say. All FSUIPC does is use a facility in Windows to put the values through to FS. In case you want to look that up, it is the "SendInput" API. Why not use the names for the Keycodes as Rick says you can? Seems odd, if you have them defined in VB, to have to revert to numbers after all we discussed on this. I normally find out what sequences are needed, to make sure I get the order correct, by using the Spyxx program that comes with MS Visual Studio and seeing the actual sequences when I press the real buttons I want to use. I find this is the only accurate way. However, that said, I seem to recall that, yes, you's do Shift-down, Char-down, Char-up, Shift-up. Horrible, isn't it? Of course, WideClient, my user of the facility, doesn't have much complication as all it is doing is relaying real WM_KEYDOWN and WM_KEYUP messages it receives on the Client PC to FS via the 3200 offset. All it needs to do is copy the wParam and lParam it receives. Similarly, those writing keynoard emulators normally need to know all this stuff in any case, to get keypresses into other programs. I think this is actually the first time anyone has wanted to use this facility with no prior knowlegde at all. Really? For every individual read and write? That is GROSSLY inefficient! Each "Process" call does a Process change to get into FS, activates FSUIPC's offset scanning, processes your changes, then needs another process change back to your program! The whole reason the FSUIPC_Read and FSUIPC_Write procedures were split from the FSUIPC_Process procedure was to allow EVERY read and write you needed to do to be performed in one process. For instance, if your program operates on a 55 mSec cycle (the most usual, based on the standard windows TIMER facility which ticks at 18Hz), you'd build up the complete set of Reads and Writes then do one Process call for the lot, in each such cycle. If all VB programs operate one read or write, one process, then I am not surprised they all seem so slow and inefficient to me -- I thought it was just the horrible code ther compiler was producing! :o No, that won't work in this case. The complete structure of three values is one data value. The largest structure is 8 bytes!!!? Surely you mean the longest single data type, not structure? The 12 bytes should be defined as a simple 3 32-bit integer structure or array. Don't tell me VB.NET doesn't support structures at all? If not, then surely it must have integer arrays? At least in this instance all three parts are the same size, so an array would do. But it doesn't have 12 elements, only 3 -- the three 32 bit values (unsigned really, in Windows, but I don't suppose VB.Net supports unsigned values either -- or does it?) By "one write" it means "one write" -- i.e. one call to the FSUIPC_Write procedure, or whatever it is called in VB.NET, to write the 12 bytes, no matter how you manage to cobble them together before hand. I can see why no one can use Windows APIs in VB.NET then -- if it doesn't support structures then a large portion of the Windows API is unusable, as it is very structure dependent. :( Regards, Pete

The throttles shown on the 4 separate throttles pages are those assigned to throttles in FS, one for each engine. You must assign them and calibrate them normally in FS first -- get them working there before using FSUIPC.The throttle on the main flight controls page is the default all-engine throttle supported by FS for most users, those with simple controls and single throttle levers. The fact that yours shows there means it is not assigned to a specific engine in FS, so it won't show on the specific engine throttles page (unless mapped from the one common throttle).. What are you wanting to do with FSUIPC's pages for this in any case? It is just for more accurate centering and null zone setting. You should be able to get everything working fine first in FS alone, then just use FSUIPC for accuracy. Regards, Pete

Ah, well, that's where I get lost and switch off. I'm still strictly a bottom-up procedural programmer. OOP lost me way back. After 41 years of solidly programming the "old-fashioned way" I have no inclination to change now. And as for productivity, well, maybe I can't make a smart user interface as fast as you clever young(er) chaps, but I bet I can solve programming problems in real code faster than just about anyone! :wink: But I understand where you are at, and why. It's just not somewhere I want to be now, and I guess we will just have to differ about "bloat" and leave it at that. I've disassembled enough of FS's newer code (C++ produced) to see how convoluted and inefficient it is compared to the original (mixture of standard C and ASM, the C parts derived from the original ASM of early years). I reckon FS would be many times more efficient done the "old-fashioned" way, but it would have probably taken them longer -- though using a *smaller* team, not *bigger* might have helped. OOP and all that stuff is probably great for team-built software, it's just that I've always been a "loner", and look for maximum efficiency in the code, not in the development time. Yes, very non-commercial (good job I'm no longer involved in truly commercial projects and can indulge in it more as a hobby, eh? :) ). None of that would be "code" as such in any case, just instructions to the compiler, not the processor. And, no, Windows C/C++ programmers don't have to define things like VK codes. That's the point. They use the names, they don't have to remember the numbers. The names are pre-defined, just as the API procedures are. That's why I couldn't give you your example without looking the values up. I don't use the values that you seem to need. Regards, Pete

Yes, of course. Thrust accelerates the aircraft but cannot instantly make a stationary object fly -- you have to gain airspeed. It is in FS2004, certainly. You could write a simulator which didn't simulate real flight but merely obeyed commands to "go at x knots, turn left, turn right" and so on, but FS isn't like that, at least certainly not in recent versions. Well, by movement resulting from speed, yes, but FS also allows the aircraft to be "placed" by changing those values. Maybe that won't be possible either in future versions. Your best bet is to set the aircraft into Slew mode, then position it, then release Slew mode. FS2002 and FS2004 (but not earlier releases I think) automatically provide airspeed for an aircraft released from slew in the air -- try it manually and you will see. The speed you get isn't adjustable though, as far as I know. I have no idea how to do that -- check the many velocity and acceleration values at 3060-30B8 and 3178-31D0. These are all relevant to what you are a little simplistically calling "speed". Maybe you can get all these set correctly to achieve what you want, but I doubt it. I know the carrier operations catapult and hooking systems make use of some of the accelerations here to achieve their object, but I really cannot advise on this. It's all a matter of trial and error. The simulation engine in FS (in SIM1.DLL as it happens) computes the flight characterstics taking in lots of inputs and producing these many outputs. The result is flight simulation. Some of the inputs are directly accessible, most all of the outputs CAN be changed, but would be overwritten on the very next computation cycle. Right. Maybe investigating how that option manages to set the airspeed may show a way to do it through FSUIPC too. It could involve some considerable extra code disassembly and debugging, however, as it is an area I've never investigated before. But I will make a note and have a look when and if time permits. Regards, Pete

The offsets are better documented in the Programmer's Guide. FSInterrogate is for experimentation so you can see what is happening. You can monitor values in several formats and see what does what, live, as FS operates. Th documentation for FSInterrogate as supplied by the author explains how to use it, not how it works -- it works as an FSUIPC client application, following the interface rules from the SDK. It was written in Delphi, so the Delphi section of the SDK is relevant. Regards, Pete

All that means is that I don't know whether it is working or not. Have you checked it? Once it is determined to actually work correctly (or not) I will fill in that column. I don't think the "tower location" is guaranteed to tell you that in any case! This location can be placed anywhere by the user (see the FS Map facilities), and there are some programs which deliberately move the tower location to different places so that you can get "fly-by" views of your aircraft. I think the only way to determine the ICAO code of your airport (assuming it actually has one), would be to take the Lat/Lon of the aircraft, on the ground, and find the nearest airport listed in a suitable database of ICAO coded airports. Even then, for closely spaced airports, you could in some circumstances actually be nearer a different one when situated at far reaches. Regards, Pete