Pete Dowson

Sorry, I've no idea, really. It's a matter of experimentation. The SimConnect documentation lists all of these as "settable", and certainly SimConnect does not reject FSUIPC's writes to them as it does with the others: 3060 - 3070 (Acceleration Body X Y Z) 3090 - 30A0 (Velocity Body Z X Y) 30A8 - 30B8 (Rotation Velocity Body X Z Y) 3190 - 31A0 (Velocity World Z X Y) 31C0 - 31D0 (Acceleration World X Y Z) Those are the Microsoft names for the values. What you might manage to do with them I really don't know -- in FS9 and before it was a "fiddle", a "hack" directly into the Sim Engine -- applications were constantly fighting FS's own computations in order to get their own values established. The fact that Microsoft actually provides official ways of writing these, via SimConnect, in FSX should have meant, I would hope, that they would work without so much hassle. But I am not an expert in any of this area. All I've done is provided the FS9-compatible access. Maybe you should ask questions on the SimConnect forums too, where folks may be trying to write these direct to SimConnect. It does occur to me that all of them will tend to interact with one another, so EITHER one set has to be written first and that affects all the others, or, more likely perhaps (?) you have to write consistent values to all of them at the same time. BTW, referring back to this in your earlier message: Were the offsets 3180, 3188, 3190 an error in your typing? I assume you really meant 3178, 3180 and 3188? These certainly aren't writable through SimConnect, so I assume must be a "result", not an input. Well, not necessarily, because 99% of FSUIPC's access into FSX is via SimConnect. To do anything more than what SimConnect provides would mean hacking into the code and really I am reluctant to do any more of that these days. It was a nightmare in FS9. The use of highly optimising C++ compilers for complex multi-piping processors produces really horribly convoluted code in the first place, and as Microsoft went further and further along the Object-Oriented code route, with even trivial functionality boxed up in virtual private interfaces and buried deep below a series of pointers, I really started flagging. It's no fun any more, especially at my age (66). Maybe some bright young sparks will come up with answers for some of the niggles, and if they would wish to share them then by all means I would incorporate them, but it is more liekly in this day and age for such to be kept secret and used to promote more products. Regards Pete

That is exactly why I introduced the Profile system, to be used instead of Aircraft Specific. With Profiles you only need to generate the few individual sets of settings you want, give them suitable profile names (like Piston, jet Turboprop, Helicopter, Glider), and whenever you load a new aircraft, assign it to one of the profiles in the drop-down profile list. Seems you aren't keeping up with changes in FSUIPC at all? Best download the latest version and browse the History document, see what's changed. ;-) Regards Pete

Well, the first thing that's wrong is that you've not bothered to answer the most important questions I asked: You did say but that doesn't actually tell me how you are operating it, does it? "Set on default"? What does that mean? Anyway, whatever you are doing it is clearly shown in the log that the fuel is being cutoff by a MIXTURE LEAN control: You operate the starter here: 1373916 *** EVENT: Cntrl= 65938 (0x00010192), Param= 1 (0x00000001) STARTER2_SET Oddly, whilst operating the starter you change views/panels a couple of times: 1375663 *** EVENT: Cntrl= 65674 (0x0001008a), Param= 0 (0x00000000) VIEW_FORWARD 1378253 *** EVENT: Cntrl= 66506 (0x000103ca), Param= 8270 (0x0000204e) PANEL_ID_TOGGLE and press the "F" key and hold it so it repeats several times: 1386880 KEYDOWN: VK=66, Waiting=0, Repeat=N, Shifts=0 1386880 .. Key not programmed -- passed on to FS 1386880 *** EVENT: Cntrl= 65584 (0x00010030), Param= 0 (0x00000000) BAROMETRIC Not sure why that appears to operate "Barometric" -- that is usually the "B" key. Anyway, you still have the STARTER2 going during this too. Whilst the starter is still held (or latched?) you move the throttle lever up a bit: 1399984 *** AXIS: Cntrl= 65765 (0x000100e5), Param= -15872 (0xffffc200) AXIS_THROTTLE_SET 1399999 *** EVENT: Cntrl= 65938 (0x00010192), Param= 1 (0x00000001) STARTER2_SET 1400046 *** AXIS: Cntrl= 65765 (0x000100e5), Param= -15360 (0xffffc400) AXIS_THROTTLE_SET 1400062 *** AXIS: Cntrl= 65765 (0x000100e5), Param= -15228 (0xffffc484) AXIS_THROTTLE_SET ... etc Then, after 30 seconds of starter operation you operate the fuel cutoff/idle to introduce the fuel: 1403385 *** EVENT: Cntrl= 65988 (0x000101c4), Param= 1 (0x00000001) MIXTURE2_RICH The starter is still held after this, and you move the throttle a bit too. This is all fineuntil, just 5 seconds later, you (or something in your system) cuts the fuel: 1408720 *** EVENT: Cntrl= 65992 (0x000101c8), Param= 1 (0x00000001) MIXTURE2_LEAN and .. re-enables it again 5 seconds later: 1409282 *** EVENT: Cntrl= 65988 (0x000101c4), Param= 1 (0x00000001) MIXTURE2_RICH But that'd be too late -- the 5 second cutoff will wreck the start. Very odd. If it isn't you doing this (double clicking the mouse or something?) then you have something in your system which is doing it for you. Without more information about what you are really doing I can't help further. You could have enabled Button logging too, as I asked (maybe you did -- I cannot tell as you cut off the earlier part of the log which would have told me what you set). I also said not to do Axis logging, unless you were using a Mixture Axis, so since you did I assume you are? Maybe you could tell me rather more? Regards Pete

There are only a few known causes of that. The most likely is a video driver problem -- if you are running FS in full screen mode, try switching to Windowed mode before going into FSUIPC options (Windowed/Full Screen mode is switched by ALT+ENTER). Otherwise it will either be another added DLL in the Modules folder -- Actigate.DLL is the usual one, but some folks have had problems with PMDGoptions.DLL too -- or possibly a bad Mouse driver. The Kensington mouse or trackball driver is problematic in this regard. You'd probably have to kill its process using the task manager -- you don't appear to need it in any case. Regards Pete

Hi Duncan. What failures? Is it possible one of them affects the controls and somehow sticks on? You are saying AirHauler has nothing to do with it, even though he says it is okay until after he runs AirHauler? Here, check it again: Whether FSUIPC4 is installed from Enrico Schiratti's site or my Updates here in the Forum, or by your Installer, won't be making any difference. What is reported as making the difference is the RUNNING of AirHauler -- but you are now saying that this isn't true, that the user is mixed up? If it is nothing to do with AirHauler, and it happens to him irrespective of having Airhauler ever being near FSX, then, since he appears not to be using FSUIPC himself (not even registered?) it must be something else he's installed in FSX -- but if that is the case why does he only refer to the problem in relation to AirHauler? Obviously the whole story isn't being told here for some reason. :-( I was going to suggest that I should ask to see a log with IPC Write logging enabled, to see exactly what AirHauler is writing, but if what you are saying is true, and AirHauler doesn't need to be anywhere near FSX for this to occur, then evidently that would be a waste of time. This user has something else screwed up on his system. But i wish he'd come straight and tell me exactly what happens -- how else am I expected to help? Regards Pete

If you've not registered FSUIPC then it is doing nothing at all, so it cannot be FSUIPC. Something AirHauler installed must be responsible if that's the only thing you've changed, but think back. It could be something else. Aha! In that case Air Hauler is messing something up in FSX USING the facilities to access FSX which FSUIPC provides. No, the log shows nothing out of the ordinary. There are lots of things we could log, but without some clue from the AirHauler folks about what they are doing, there's really no way to start looking. I'm sorry to throw you back to them, but even if there's something i could do about it it is obviously something which AirHauler needs to tell me about. Regards Pete

Fuel cutoff is controlled by MIXTURE in FS, both for props and jets. The difference is that with jets only full rich (max mixture) enables the fuel flow. Regards Pete

I suspect that the COM port you've got set is wrong -- are you sure you have the right one set? Are there others listed in the dropdown if you elect to change the port (one of buttons on the bottom of that check)? However, the fact that anything at all happens later on is suspicious. That sounds more as if it is the correct port, but incorrect speed or a bad connection. Are you using a genuine serial/COM port or a USB-Serial adapter? If the latter, maybe that's gone faulty. I've had such problems with one or two of the very cheap adapters. Regards Pete

Sounds like you've not assigned the switch correctly, then. You most certainly have something which is not assigned correctly then. Are you operating the cutoff/idle start lever on the cockpit graphic, with the mouse, or with the keyboard, or have you assigned a button for it? If a button, does it work with the mouse or keyboard? If so you have the assignment incorrect. FSUIPC does not do anything you or a program does not ask it to do. By default it does nothing at all. Something you have programmed it to do is wrong -- or else the Saitek device is generating spurious button presses. Certainly one of their devices used to (I actually added a facility into FSUIPC explicitly to get them ignored). Try enabling both Button and Event logging (not Axis logging, unless you have a mixture axis assigned) in the FSUIPC logging page and look at the FSUIPC Log file after such an incident to see what is doing it. (If you have a mixture axis assigned, bear in mind that this set to full rich acts as the start lever set to "idle/start" but ANY other position than max will be fuel cutoff!). Pete

Ah, right -- but not two digits for IAS, I assume -- or IAS/10? ;-) Regards Pete

I thought it might not, as I said. Yes, that's correct. I think the problem is that the extended codes like those need separate special treatment. I am not even sure I can generate them correctly. None of the normal shifts (shift, alt, ctrl) can be easily produced on their own, nor, it seems, can extended codes like the ones you want. Why not use the space bar or one of the normal keys? Surely there are many keys in easy reach. Why are you only looking at key modifiers? Regards Pete

I'm not sure the system used for keystrokes in FSUIPC can provide separate Left and Right shift and control codes, but try keycode 163. You'll need to edit this in the INI file. Assign something easy in FSUIPC's options then find the entry in the INI file and change the keycode you assigned to 163. Why choose such an awkward keycode? Regards Pete

Good. It was a silly error -- glad you tried it. I wouldn't even have thought of testing such an arrangement! ;-) Best open a new one with an appropriate title in case someone else has the answer. I assume you checked the documentation, as brief as it is, and searched the threads? I think the x96 series are all similar in this area -- though I've never even seen one myself. Regards Pete

Test them? They are in heavy use in many many important programs, and certainly work exactly as documented. Have you used FSInterrogate to see their values in real time? FSInterrogate can show you the raw and factored values, accurately. I don't recognise that syntax (what language is "1.3 dotnet"?), but I assume you are doing everything in floating point? Why the "D" on the ends of the 65536? Are you sure you have the reading part correct? It doesn't matter what your computations look like if your are reading the values incorrectly. Compare your results with what FSInterrogate shows. No, because you don't supply enough information. What "doesn't work", exactly -- you can't write, or you write and it doesn't change? In general those sorts of values are DERIVED from the simulation engine inside FS. Every time you write to one of them, FS will overwrite it on the next iteration, at the sim internal frame rate. To have any effect at all you usually have to keep writing at frequent intervals. Probably you'd need to run in-process -- i.e. as a Gauge, DLL or, easier, a Lua plug-in. It would also help if you mentioned what version of FSUIPC and, especially, FS you are talking about. There's an enormous difference between FS9 and FSX internal implementations in these areas. Regards Pete

Found the problem! I was looking at the implementation of the decoded line from the Macro file, not at the creation of the decoded details. When there's no parameter I should have been setting a flag to say so, and wasn't -- only in the case of L:vars! Please try version 4.515, from this link: http://fsuipc.simflight.com/beta/FSUIPC4515.zip Let me know. I'll only need your gauge if it still doesn't work. Regards Pete

I don't know -- does the documentation show how to form entries for display? I really don't remember anything about GFdisplay (having not used GF displays now for many years. Let me have a quick look and get back to you. [LATER] No, I can't see a way. It is one display, so you'd need one value. You'd need to be able to compute (heading * 100) + ground speed assuming the ground speed was less than 100 knots. (what are you flying, by the way, if its max groundspeed fits in 2 digits? A balloon?). There are no computational facilities in GFdisplay. You could write a small Lua plug-in which does the needed computations, writing the values to a user offset (in the range 66C0-66FF), and get that displayed via GFdisplay parameters in the normal way. Regards Pete

Yes, I understand that. This is similar to Fly-by-wire, which is used by Airbuses. With FSUIPC you can do that by disconnecting the axis via offset 310A, reading the input values in the relevant copy offset, and finally writing to the relevant axis offset. This is how many Airbus implementations did it in FS9 and before. with FSX of course Simconnect can be used in a similar way. You could also do the same thing using Lua plug-ins. The advantage of both of those two methods is that they are FS9 and FSX compatible. The L:Var facilities in FSUIPC only apply to FSX/ESP. I have to plans to backtrack them to FS9. The L:Var method you are trying should work, however. I will have to find out why it doesn't. That might be useful. I'll have another look at the code first though. Examples are provided with FSUIPC. Ones you can look at and try for yourself. Why not ask questions if there's something you don't understand? I cannot undertake to give a tutorial, but I can answer specific questions. Regards Pete

As documented, there are two Lua filenames which are automatically run -- ipcinit.lua and ipcready.lua. the 'init' one starts as soon as FSUIPC is initialised (usually a bit before FS is ready) and the 'ready' one starts when FS is ready to fly. You can either put the code into one of thoser, or simply use them to run any other Lua files you want running. Your own gauge? So I cannot try it here? Seems a rather, er, odd thing to do. Is there a good reason for it? Hmmm. It should get the axis value, but this did fall out as a side effect of the way things were programmed -- as I describe in the documentation for the Macros. I'll have to work out a way of testing here. Do you know of any gauges with L:vars taking 16 bit integers which would be visible in some way? [LATER] I've checked the code. The way the parameter is passed is the same for any type of Macro, not just L:Var ones, and I'm sure they work -- or at least, they always did. The code is almost identical. I'm definitely going to need some way of reproducing what you are doing in order to delve further. Regards Pete

Yes, you would need to use a little Lua plug-in to do it. The supplied Lua library functions can read and write Lvars and offsets both with ease. Hmm. I don't really understand. Is this L:Var "AXIS_THROTTLE" a genuine Lvar in a gauge of your own, or one you've found? I'd need to try it I think. In the first example, which value is "displayed" in the variable (and how are you viewing it?). 2? Regards Pete

FSUIPC4 cannot have anything to do with it unless you've registered it (i.e. paid for it) and are using the axis assignment options incorrectly. If it only a problem with AirHauler I think you need to go to Airhauler support and ask them. FSUIPC automatically gets the blame for everything and is very rarely the cause. However, make sure you are using an up to date supported version -- for FSX is it 4.50 or later. Pete

I hope someone else picks this up. I'm afraid I know nothing at all about Java. Pete

If you are referring to FSUIPC, then, no. They are different products. V4 was a complete re-write, the first time since FS98 days, because FSX is so different. Pete

It isn't possible. You need to restore focus to FS. Pete

By "splash screen" you mean FS's opening selection dialogue? FSUIPC cannot do anything whilst FS is in a dialogue -- dialogues are MODAL which means nothing else in the whole process happens! Why don't you simply set FS to run directly into your default flight? The selection screen has always been optional. Here, if you don't know how: Change this in the FSX.cfg under the [sTARTUP] header SHOW_OPENING_SCREEN=0 (change this from 1 to 0) Same for FS9 and most versions before. If you want FS to start up with your flight already loaded, start it with the flight name in the command line, something like: FSX.exe /FLT:flightname I think. Or maybe just FSX.exe flightname Try it. Regards Pete

No, you are writing one byte 0 and one byte rubbish to 3F00: BYTE operation = 0; // 0 to simply load the specified flight/situation. if (FSUIPC_Write(0x3F00, 2, &operation, &dwResult)) Obviously "operation" needs to be a WORD not a BYTE! A byte is 1 byte long, not 2! It would also be much more efficient to do the two writes, in that order, with one process call to send them. There is very rarely any need to do more than one process call per cycle. Always group reads and writes to save frequent process switching. Where's the FSUIPC logging with IPC Writes enabled showing that you successfully did anything? Please please please use the tools provided, especially the logging, to help you develop things. I don't want to see code -- next time show me the log if you don't understand it. Regards Pete