Pete Dowson

Macro files? I'm not sure whether "trying to add" is relevant. Have you tried to create that macro in a separate macro file. Just name it slightly differently. Check it, and show me that file. I want to remove both the confusions arising here -- the first to do with your displays (hopefully now dispelled) and the second to do with the difference between "adding" and "creating" -- there should not be any difference, and here I cannot see that there is one. But does their file work. with the same button on the same visible part, or not? And is the version of the MD-11 exactly the same in both cases -- or have there never been any updates, any different versions? The mouse macro system works for specific software. If it is changed slightly, so will the macros need re-generating. I don't know the MD11 at all, but the PMDG 747 has several DLLs, not just one! I don't think that is relevant. You are mixing up aircraft names, types, with SOFTWARE modules needed to run them. There's not necessarily 1 file per aircraft -- often there are many. Regards Pete

Thought not. If TAB doesn't work then it probably isn't a mouse-macro-able action. The 1: part refers to a different Gauge file. There should be a line giving the gauge name, like module1="XXXX.GAU" (or maybe "XXXX.DLL", whatever). Evidently, the place FS called when you clicked was not in the "default" module, "PMDG_MD11.DLL". That was in the "original DLL" then. Anyway, what is "the original file" -- not, presumably, the one you are Adding WPT to? I'm afraid you need to be more explicit. what is the "original file", where did it come from? why are you re-doing it if it was okay? Yes, so? Why so puzzled? If it doesn't work when you test with TAB, then either it needs a numeric suffix because it isn't (just) the button press which operates it, or it simply is not mouse-macroable. You might need to work out exactly what you are doing with the mouse, and/or then experiment with the "mouseflag" values, as detailed in the Advanced User's manual (around page 32). I would help, but I don't have the PMDG MD11. BTW why are you specific "not working in FSX". Surely the add-on in FS9 is not the same. You surely aren't trying to use macros made for an FS9 add-on in FSX? What can anything here possibly have to do with your screen? These macros have nothing to do with the screen. The system works purely through hooking into the software parts which are called when you operate by mouse. The mouse and its position are totally irrelevant thereafter. Regards Pete

Okay. Please try 4.507, from the Updates Announcement above. No, it is only a timing coincidence -- the dialogue asking for the macro filename is closed externally, but in some circumstances it doesn't actually close the Window. Well "hang" is too strong a work. I think it is merely a windows drawing error. Yes, as I thought. No, but i hope it is fixed in 4.507. I can't make it happen here, but then, as i said, it is a matter of timing. Please let me know if it still happens and I will re-examine the code. Regards, Pete

That sounds like a little screen update buglet (not serious, just a Window not getting closing when it should) which was fixed a few weeks ago. what version of FSUIPC are you using, please? (This is information I ALWAYS need, every time!). You don't even say whether it is FSUIPC3 or FSUIPC4! If it isn't the latest from the Updates above, could you also try that. It only gets saved when you return to the Options screen and select End macro making. Pete

Definitely ! ;-) Oh, I'm away visiting my daughter from tomorrow evening (Friday 1st May), back on Saturday 9th, so it would need to be pretty quick if it needs my attentions still, or it would have to wait a week or so. Regards Pete

Time to learn, then, as it is really very very simple. Hex is like decimal, but instead of using 10 digits (0-9) it uses 16 (0-9 then A-F). So each position in a number can be any one of 16 values instead of 10 values. Letters A-F represent values 10-15. Now, in decimal, each digit in a number represents 10 times the next digit. i.e. 123 = 1 x 100 + 2 x 10 + 3 x 1. In hex, because the digits go up to 16, each digit represents 16 times the next digit. i.e. HEX 123 = 1 x 256 (16x16) + 2 x 16 + 3 x 1. Okay so far? That's Hex. Now to bits. In binary there are only 2 digits, 0 and 1. But the principle still applies. Now each digit represents 2x the next one. Remembering this it is easy to see that Decimal Hex Binary 0 0 0000 1 1 0001 2 2 0010 3 3 0011 4 4 0100 5 5 0101 6 6 0110 7 7 0111 8 8 1000 9 9 1001 10 A 1010 11 B 1011 12 C 1100 13 D 1101 14 E 1110 15 F 1111 See how one HEX digit represents exactly 4 binary digits, or bits? That is VERY useful, and why it makes HEX so useful and easy as you'll now see: For a 16-bit value, like offset 0D0C (the lights), there are 4 x 4 bits (4 x 4 = 16, easy). So, these can be written as 4 HEX digits. A pattern of bits like this: 0 0 1 0 0 1 1 0 1 1 1 0 1 0 0 1 would be written in HEX as 26E9, because 0 0 1 0 = 2 (see table above) 0 1 1 0 = 6 1 1 1 0 = E 1 0 0 1 = 9 Now all you need to know is how the bits in a 16 bit value, like 0D0C, are numbered, and you then have the whole story. By convention, bits are normally numbered according to their "power of 2". In effect this means that the LAST bit, the one worth a measly 1, is bit 0 (2^0 = 1). The next one up is bit 1 (2^1 = 2 ), the next 2 (2^2 = 2 x 2 = 4) and so on, up to the first, or "topmost" bit 15 (worth 2^15 = 2 x 2 x .... = 32768). So that hex pattern above, 26E9, which as we saw represents these bits: 0 0 1 0 0 1 1 0 1 1 1 0 1 0 0 1 the numbers of the bits which are set are, from left to right: 13, 10, 9, 7, 6, 5, 3 and 0. Finally, if you ever need the DECIMAL equivalent of such a HEX number, you'd probably do better with a calculator, but the method is: e.g. 26E9 Step 1: 2 x 16 = 32 Step 2: Add the 6 = 38 Step 3: x 16 = 608 Step 4: Add the E (= 14): 622 Step 5: x 16 = 9952 Step 6: Add the 9 = 9961. Answer = 9961. I have to do a lot of such conversions as a programmer, so i use a special calculator that does Hex to Decimal and Decimal to Hex conversions. ;-) Well, I hope that's clear now. If not, then I'm sorry but that's the best I can do. You need a basic guide to computers. Regards Pete

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