Pete Dowson

Hi again, I found the information you must be referring to towards the end of the SA_WXR User's Manual. Unfortunately I don't really understand it either. For offset 6D00 he's provided two modes -- a switch mode where a bit=1 for switch set, =0 for clear, and a "toggle" mode, where I assume you have to change the bit to change the switch. The problem with the toggle mode, if indeed he does mean you have to change the bit rather than just write to it, is that it appears that to change the Mode you have to write 0 to bit 7 and 1 to bit 1 as well as, at the same time, toggling changing bit 0. Without writing a program to do this is isn't really possible -- certainly not with one control anyway. Looking at the "switch" mode, it seems you have to set bit 7 to 1 (easy enough), but not change any of the bits you don't want to change the settings of. For the mode this makes it difficult (impossible) to do in one control yet again, because you need the lower two bits set 00 for OFF (i.e. CLEARING, not SETTING bits), 01 for WX and 10 for WX+T. Again, in every case you have to set some and clear others. Without doing a simple write for the BYTE at 6D00 it cannot be done in one control. To write it in one byte you'd also have to write the correct bits for the Range and your OFP and GCS switches. Maybe I'm misunderstanding all this, but to my reading it looks as if the interface is designed for programmers to use in interfacing a separate control program to SA_WXR. I cannot see any sure way of doing it with simple FSUIPC key or button programming. You could TRY sending two controls per key or button press. That would mean editing the FSUIPC.INI file -- or for buttons you could, I suppose, send one on the press and another on the release and still program it in the dialogue. Whether this would work properly though, I really don't know. It seems unlikely to work consistently. To try this the pairs needed would be: To set OFF: ---- Offset Byte Setbits, offset x6D00, param x80 ---- Offset Byte ClearBits, offset x6D00, param x03 To set WX: ---- Offset Byte Setbits, offset x6D00, param x81 ---- Offset Byte ClearBits, offset x6D00, param x02 To set WX+T (aha! One control only! ;-)): ---- Offset Byte Setbits, offset x6D00, param x83 To increment tilt ---- Offset Byte Setbits, offset x6D00, param x80 ---- Offset SByte Increment, offset x6D01, param x01/x7f To decrement tilt ---- Offset Byte Setbits, offset x6D00, param x80 ---- Offset SByte Decrement, offset x6D01, param x01/x80 Without further help from Florian I'm afraid this is about all I can suggest. As I say, I have doubts that these sequences will work, because I don't know what the program will do "between" seeing each change. Maybe sometimes it will work (because it will see them as one change), whilst at other times it won't. I recommend you ask the author, Florian Praxmarer for more assistance in this. Perhaps he can be persuaded to give working examples in his document. Regards Pete

I don't use those options at all. Can you be more explicit about what you want to do with what offsets please? Regards Pete

Yes, it is almost impossible. Try running FS in Windowed mode instead, you can make it work then. Otherwise you have to keep trying all sorts of horrible repainting tricks involving intercepting loads of messages. It really sucks and gets extremely convoluted. Ugh. It worked with FS2002 (but even then it was messy). The problem with FS2004 is the new way the DirectX does the graphics. I once asked some FS team guys how to get around it and they pretty much said "don't, it isn't possible"duh! :-( Pete

Yes, and because it is allowing the higher values through and only THEN changing them, there is absolutely no way you can fix that. The gauge needs to be written so that it traps the joystick inupt and modifies it before FS sees it. Yes, but it cannot change dynamically. Your gauge is trying to do that. You can't do both in any case. It would be best to write the gauge correctly in the first place. I cannot see any other way. It is exactly as you explained before, but it still makes little sense to recalibrate any axis suddenly in mid-flight just because of a flaps change. You would have a sudden change of surface positions as a result, as I explained, and probably lose control. If your gauge is meant to do this limiting slowly, gradually, then that is fine, but it needs to do it BEFORE FS sees it, not after, otherwise you are bound to get your flutter. In my opinion you would be much better off simply using one of the flattened-centre FSUIPC calibration slopes, so mostly you have less severe effects for most of the movement but are still able to reach the extrmes when needed. It is exactly for the sort of control variations you are describing that these facilities were added. Regards, Pete

Well, no one from FS HotSeat has talked to me, but I have been part of all the Radar Contact beta teams for years, albeit not really as a fully active tester. There are two ways to get the needed AI data -- in bulk through the original TCAS data area I devised, or one-by-one for specific AI aircraft through a request-and-response system. The former is suited to TCAS displays, and anything needing lots of data for lots of AI at the same time. It is they which need the option set appropriate to the needs, with the default Airline+flight number being normal. For ATC interaction with many AI aircraft, RC also falls into this category. RCV4 does use the individual request method when it is identifying the make/model of aircraft in front of you so that it can give appropriate instructions as in "after the 737" and so on, or in notifying nearby aircraft types when airborne. As far as I know FSHotSeat (which is almost not at all I'm afraid), I think it mainly needs the latter simply so that it can play appropriate sound effects. No doubt you will corect me if this is wrong. The problem is that FSHotSeat was probably written in the days before the individual AI aircraft request method was provided, and the author did not come to me and explain what he wanted to do so that I could meet his needs (as I did with RCV4). The answer to the problem now, apart from not using both together, would be for a revised FSHotSeat to use the individual request method for its AI data requests. I am sorry, but I hope you now see that there is really no solution I can implement in FSUIPC. But there is a solution, and it is in FSHotSeat's author's hands. Regards, Pete

Ok -- the raw values are changing rather more frequently than the 256-graduations which the variables you use indicate. In the updated FSUIPC attached I've provided the values in 32-bit floating point format (float or FLOAT32) as follows: offset size meaning 2AAC 4 VOR1 Localiser needle value in 32-bit floating point format 2AB0 4 VOR1 Glideslope needle value in 32-bit floating point format 2AB4 4 VOR2 Localiser needle value in 32-bit floating point format 2AB8 4 VOR2 Glideslope needle value in 32-bit floating point format I'm also updating these more frequently (at least every frame) than the FS98-compatible values. This applies to FS2002 (untested) and FS2004 (tested ok), but nothing before these. Let me know if this does the job you want. Regards, Pete FSUIPC3509test.zip

Yes, the resolution of even the best gauges presumably never needed more than 256 steps. Hmm. I don't know if the raw data I'm using to populate those is any more accurate. Just being in floating point format doesn't mean more accuracy -- there are lots of cases in FS where floating point resolution is is just as low as that shown in the old FS98-compatible ways. I'll check the raw values for you and let you know. Regards, Pete

I don't quite understand. Do you mean that the gauge is letting the joystick values through to FS, and only then changing them? If so, then, yes, I would imagine that would give a very unstable effect. Well, no, this is not currently possible. You can have separate calibrations for different aircraft, but not for different settings on a single aircraft, dynamically changed. Actually, I don't really like the thought of that in any case -- you would have to be sure to have the elevator and aileron more or less centred when changing from no flaps to flaps or vice vera, or face a severe risk of losing control because of the sudden drastic change in the control surface positions. Additionally, if FSUIPC were limiting the values through a different calibration, what would your special gauges be doing? Are they reading the joystick axis at source? It sounds unlikely, as if they were they could modify the input to FS so that you wouldn't get the fluttering in the first place. If they are only monitoring the resulting surface positions then FSUIPC's calibrations would have already occurred, so the gauges' actions would double the effect. No. It seems to be that the only solution is for the gauges to intercept the axis controls en route to FS, modify them as needed, then pass them on. Then you'd not get the fluttering. If using FSUIPC calibration you'd then need to be sure to calibrate with flaps up. Maybe I'm misunderstanding you in the first place. If so, apologies. I'm not even sure why you'd want any of this in any case, but I assume it is something to do with the incorrect behaviour of a particular aircraft? With many airliners the main effect of flaps on control sensitivity applies to stabiliser/elevator trim. For instance, on the 737 the trim should be operating twice as fast when any flaps are down -- you can actually see the trim wheels spinning faster when electric trim or autopilot trim is performed. Regards, Pete

Ah, yes. According to my references for the 747, that arrangement is correct. A real 747-400 manual I have states this: OFF = Disarms and resets the system DISARM = Disarms and releases all brake pressure to the wheels. Subtle, eh? :-) Quite honestly I don't know what pressure should be applied to the wheels in the OFF position in any case -- there shouldn't be any, in my reckoning. So the difference seems zero to me, at least as far as manually SELECTING it is concerned. However, it goes on to say that the system itself selects that postion in similar cases to those for which, on the 737, the "Disarm" light comes on. In other words, I think it is more of an indication to you of the "disarm" condition than it is a position which you'd ever normally select manually (except maybe for engineering purposes). Perhaps, by the time they got to glassing the 737s they realised they didn't need a separate Disarm selector, only the light, for economy? (There's no similar light on the 747 A/B panel). As far as FS is concerned I think you'll just have to treat it as "OFF" when selected. If the switch is motor-driven you could select disarm programmatically in the cases I listed previously, as the indicator. Regards, Pete

It is most unlikely they have in any case unless their programming is split into more than more module/program. Even with multiple gauges they can use systems provided in the PANELS subsystem to maintain local named variables with shared access. Those that use FSUIPC data space do so as a way of communication between otherwise completely separate parts -- Project Magenta is the main example. You can of course use FSUIPC's Logging (IPC read/write) to see what traffic there is between FSUIPC's offsets and everything else. In order to see the wood through the trees you'd want to cut FSUIPC users down to the bare minimum. Regards Pete

Well, my feelings too. But there are folks who cling to VB despite the difficulties it seems to impose. Best regards, Pete

Disarming the autobrake is setting it to OFF. The offset is documented (2F80) and the value 1 written to the byte there with disarm the autobrake. For programming on a button or key, FSUIPC's Buttons and Keys pages offer an extra control (in the dropdowns) to operate the AutoBrake -- "Autobrake Set". To disarm, assign this with a parameter of 1. If you are instead asking about the indicator light called "Autobrake Disarm" on the A/B Control Panel, you would need to program that for the applicable conditions (for instance, it can be done with pmSystems). All I know is the 737NG. The light should come on when: * Manual brakes are applied during RTO or landing. The autobrakes should disarm automatically (FS doesn't do this, but some add-on aircraft do). * Three seconds after thrust levers are advanced, after touchdown (again, the A/B does disarm) * RTO is selected on the ground. The light only comes on for 2 seconds. This is just a test. * There's some malfunction in the A/B system which prevents correct operation. Regards, Pete

FS2004 is still around in 2005, isn't it? What's this about 2 months? If you mean "the next version of FS", if and when that may be, I'm no fortune teller. But I try my best -- after all I have a big investment in using my own programs myself, with a 737 cockpit and a separate light aircraft setup. Regards, Pete

IMO there's nothing wrong with hacking for your own purposes, or if it is okay with the authors. After all most of what I've done with FSUIPC and my other modules was through hacking into FS code. Luckily Microsoft don't mind (they like it -- it does good for the product). I don't actually agree at all with PMDGs stance. I think it would be good for their product too. But I can't go against their stated policy. You can, but in private. If there's a keyboard shortcut you can. If it uses FSUIPC offsets you can. If it is only mousable you'd need something like Luciano Napolitano's "Key2Mouse" program. Regards, Pete

Sorry, no. Really, I have a good relationship with PMDG and really cannot actively help folks hack their secrets. I suspect they encode the values in some way, or use different units in any case, to make hacking more difficult. All I can advise you to do is seek help on the 'Net. I think this sort of thing has been worked out by others, or at least it was for the original 737NG release. They may have made it more complex in later updates. Regards Pete

I should have answered this part too. You can add parameters to FSUIPC.INI to make FSUIPC load your program for you. See the section in the Advanced User's guide on this. There's also a utility, made by Jose Oliveira, available on the http://www.schiratti.com/dowson page to help. Regards, Pete

PMDG use proprietary internal data which they currently keep secret and will not publish. I think some parts have been "hacked" and published somewhere on the 'Net, but I am sorry I cannot help you there. PMDG say they don't want hardware manufacturers to take 'unfair advantage' of the many man-years of programming they have invested in their aircraft systems. Having said that, have you checked with GoFlight? I did see that GoFlight had done something for the LevelD 767 (which is in a similar position except they have published an interface). Maybe GoFlight are in the process of doing something with PMDG by now? Sorry, I don't really know -- best to ask in the GoFlight support forum. It seems on the surface that PMDG regard their system as being entirely contained within the PC and don't see the home-built or even commercially-built cockpit market as something they are interested in, unfortuately. This is why, though I use PMDG aircraft I don't use any of their panels or systems, only Project Magenta. It is rather a shame for such an otherwise excellent system. Regards Pete

The DLL you use for your API is specific to your process. It will not be an FS DLL. Just because both programs use such libraries please do not be fooled into thinking that any program can use anyone else's library (DLL). It cannot unless specifically written to do so, and I doubt that you can persuade Microsoft to change FS to use your DLL. DLLs used as FS Modules are written especially to be DLLs that run as modules in FS. They are not any-old library from any other project which are just tarted-up and plonked into the Modules folder. The nearest thing to an FS Module which is fully documented is an FS Gauge -- in fact a Gauge is merely a DLL which is loaded with a panel. If you learn to write FS gauges in C you will not be far off being able to write a Module. Regards, Pete

The 737NG cockpit came in a 6'x7'x7' crate and the gross weight was about 2000 lbs I think -- a lot of that (about 400 lbs or so) being the crate itself! Egad indeed! ;-) Check the topmost announcement in this Forum. The PFC.DLL has been going through lots of changes since 1.92 -- it's now 1.989. It's only not on general release because (a) I've not had time to update the documentation, and (b) most of the changes are only applicable to the 737NG cockpit and then only to recent versions -- though there are many other improvements along the way. It certainly isn't withheld from general release because it is unreliable in any way, far from it! You might as well get FSUIPC 3.507 too whilst you are there. ;-) Regards, Pete

I don't know about that. Does it have motor drive for the trim? Is it fitted with the latest firmware which includes the facility for my PFC.DLL to tell the trim motor where to go? (You may need to ask PFC about that). Can you ask PFC what it is all about then let me know, or get them to let me know please? I have only one device of theirs with trim motors, and that is the 737NG cockpit with motor driven trim wheels. The electric trim drives that and the pot associated with that drives FS. In the latest PFC.DLL I disconnect the electric trim buttons on the yoke from FS and allow the trim axis to operate instead, and this is defaulted for the 737 cockpit. If your trim system is sending both trim axis commands and trim controls, you need to go into the yoke button options in PFC.DLL and reassign those buttons to do something innocuous. But also check the latest PFC.DLL (see top announcement in this Forum). There have been lots of changes in this area. You'd also need to calibrate the trim axis in PFC.DLL, and probably enable the motor drive if you expect the A/P to be able to operate the electric trim too -- but this latter action really depends how it is all connected and operated. As I said, I don't know the device at all. In any future questions, on ANY of my modules, please always state the version number. It is very difficult to help blindfolded both as to the hardware and the software! ;-) It won't. Don't use it. It is for the system using increments/decrements. A trim axis system, once calibrated, has its own (calibrated) centre. Regards, Pete

FSUIPC has nothing to do with scenery at all, but you have too much logging enabled in FSUIPC. No doubt your disk is fragmented and saving all this rubbish won't help FS run smoothly. Go to FSUIPC's logging page and uncheck it all! If FS stutters still it will almost certainly be down to any one of many things: * not enough real memory * not enough video memory * insufficient hard disk space * badly fragmented disk space * insufficient power in the video card or processor for the load you are placing on them * running other processes or add-ons which are taking too much processor time. Try defragmenting the disk, turning some of the FS sliders down (FS Options-Settings-Display), reducing the screen resolution, and/or running less add-ons or add-ins. Possibly consider adding more memory, and/or upgrading video card and/or processor. You can also often get smoother flight by actually *reducing* the frame rate -- set a specific limit on the Frame Rate Limiter in the Hardware part of Options-Settings-Display. Try something like 20 or 25. A lower but consistent frame rate is better than one which swoops up and down all the time. Finally, try the FS2004 Forum for more suggestions, and look for the FS2004 FAQ. Regards, Pete

Sure: All of the parameters except "Next" and "1=" are in the wrong section. The [Files] section is not for User editing, it simply keeps track of which files have been saved and which need deleting next. ALL User options go into the User section, that is why it is there. i.e. [user] Interval=60 Files=1 AlsoSave=My Restart AlsoInterval=60 SaveOnGround=Yes [Files] Next=1 1=Tue 124844 Same as all the saved flights -- AutoSave actually has no control over that, they go where FS decides to put them. In the case of FS2004 they are all in your "My Documents" folder, in the Flight Simulator Files sub-folder. Regards, Pete

Sorry, I couldn't make any of that work either. I guess that either the ports are already taken or there's more to that naming convention than we understand. I think that turning activesync off may not actually get rid of it, there's some background process still running I think which probably still owns the 'port' needed. Hopefully someone who got it working will chip in and say how. Regards, Pete

I used VS6 all the time till I decided to lash out and buy VS .Net 2003. The differences are mainly that the debugger is much better and the optimising compiler leaves VS6 miles behind. But for developing your C/C++ programming skills VS6 is fine. But if you also have VS2003 .Net, why not use it? I suppose 2005 includes 64-bit compiling capabilities? No doubt I'll need to upgrade in due course ... [LATER] Of course, I forgot. The super-optimising version of the C/C++ compiler was only available in the Professional Edition and above, which is why it came with all the other stuff I didn't really want. The cheaper editions don't produce such good code I'm afraid, but you could get C++ without the other stuff. I just checked on the 2005 version. Seems it'll be here in the UK in about 5 days or so. I'd need to go for the Pro Edition upgrade, which isn't cheap, so I think I'll leave it till I really do need to think more seriously about 64-bit (which, I note, is included in the Pro Edition). Regards, Pete

It depends on what you want to do and how much you know already. VB is easier for beginners but, in my opinion rather limited. C/C++ is powerful and very flexible but it is easier to make mistakes. MSVC doesn't seem to be available on its own these days. In order to get the best optimising C compiler I had to fork out for Visual Studio .Net 2003 (the 2005 version should be out soon if not already). That comes with all sorts of things I didn't need or want, like VB, C#, MFC and C++ (I only wanted C). But I think it has the best optimised code output for C and the best debugger, especially if you are doing stuff for Windows XP. Regards, Pete