Pete Dowson

Yes it is. I think all is explained. Looking at the code in FSUIPC it only WRITES the offset 7B93. Then, 6 times per second it interrogates this (amongst other related actions) and if 7B93 is set it sends the Ident message to SB4. It then clears 7B93. It never actually writes the '1' to the READ offsets -- in FSUIPC the read and write offsets are separate. FS values and so on are read to the READ offsets whilst user applications write to the WRITE offsets. For most the update is done because the value changes and the read values change as a consequence. This makes sure that what you read is actually what is true, not simply what you set. Since 7B93 only instigates an action, there was never any reason to copy that to the Read offsets. And FSUIPC clears 7B93 as soon as it does the deed. So even 7B93 read value will only be '1' for a short time -- max 1/6th second, min pretty much 0 seconds. 7B91 is different. it's a "mode" and stays set. If you want an Ident to be indicated I think you have to do this based on your button, not on an offset. Regards Pete

Yes, checking the code it simply writes 1 to 0x7B93. I suspect that what is happening is that this is being read by SB4 and cleared directly (ready for the next time). Logging would show. Certainly FSUIPC doesn't clear it, so SB4 must do at some stage. It may do it immediately. If this is the case then you might need to operate your displays from the button press instead of the bit being set, with a delay to clear it. I don't remember enough to be sure you can do that in GFdisplay, but you could certainly do that in Lua. Cut and paste is best. Only the part showing your use of the Ident. Regards Pete

Well, they are very well made, but also VERY very expensive. I got mine at cost because I did the drivers for them, and in those days (many years ago) there wasn't really so much choice. These days I'd seriously look at cockpits like the JetMax offered by FlightDeck Solutions, and others like that. You get a lot more for your money, even though it might not be so solidly built as PFC. Actually, yes, the PFC pedestal yoke and their pedals would be a good fit for the JetMax, which doesn't come with those parts. Regards Pete

No. Buy the combined package FSUIPC4 + WideFS7. Pete

I can't see anything wrong with the DLL.XML, but as a test just rename it (eg DLL.XMLdisabled) and re-run the FSUIPC Installer -- make sure you use the latest. It will generate a basic DLL.XML just to load FSUIPC4. If that works then something in the original is wrong. Otherwise you can rename the original DLL.XML and we'd need to look elsewhere. Pete

It wasn't me who tweaked the model but my friend Thomas, the one in the FO seat in the video. He also did most of the clever engineering work with the overhead fitting. I just do mundane things like wiring up Bodnar interface boards and writing the drivers for everything. There are other "tweaked" models for use with Project Magenta (PM themselves do one), and there's also the Jetstream model from Prosim, meant for their suite of cockpit software. No, they, like the rest of the cockpit other than the overhead are by PFC and built in. They don't sell this stuff any more. I think they only made 15 or so of the 737NGs. Ray is very fussy and self-critical. He insists that we all get together again and I make a replacement video with a 'proper' landing! ;-) Regards, Pete

Okay. So it's just these two lines: 0=X7B93 U8 =1; Ident Active L6=X7B93 U8 =1; Ident Active so the problem must lie in that offset 7B93. Are you sure that's being set? Try monitoring it in the FSUIPC Logging tab (right-hand side). Maybe it isn't = 1, maybe there are other bits in use too and you need a mask? Pete

Most FSX aircraft don't have many if any gauges programmed using the Microsoft C/C++ Gauge SDK. The mouse macro feature only works with such gauges which are getting fewer and fewer. I think many folks interface to iFly using the iFly2FSUIPC program. It may be responsive to L;Var writes too, but I don't know. Are there any ideas in the User Contributions subforum? Pete

When you say you have letter and numbers assigned, what devices still have numbers? The letter assignment should have replaced all of then except things like Goflight and WideFS-connected controls. Neither of those will be affected by a change of PC in any case. But it is likely that all normal joysticks (those numbered 0 to 15) will change IDs. The lettering safeguards this, using the joystick names and (hopefully) unigue GUIDs. Apart from this worry, all you need to do after installing FS, running it at least once, then installing FSUIPC, is copy the FSUIPC INI file, the FSUIPC4 KEY file, and any Lua and MCRO files you are using. All your settings and assignments and calibrations will be fine. Regards Pete

Can you be more specific as to what doesn't work. i'm a little confused. Are you only referring to the GFDisplay script? none of it works, or some does and some doesn't? Can you point out which is which? I'm afraid i'm not at all familiar with GFdisplay these days, having some time ago replaced that entire functionality with the much more sanitory and powerful, AND easier to use and understand Lua gfd library facilities. Do you think you could switch to using those instead? Support would be soooo much easier! Regards Pete

I did actually say, way back "0BC0 is the control input to the trim, no matter where from, and 0BC2 is the indicator. Both are exactly as described and will almost always read the same value. The autopilot is one control and the axis, when enabled, is the other." Yes, if the AP is off the only control input is from either the keyboard controls (elec trim up and down controls0 or, more usually, from the assigned axis -- but the latter takes effect only when changed. It indicates no matter what is changing the trim. Otherwise the cockpit indicator whould not show where the trim was in manual control. Yes. Without actually looking it up, yes, it sounds correct. And as I've said before, this is only if the axis is actually assigned in FSUIPC -- otherwise it isn't being read by FSUIPC so it cannot provide it. Pete

What a mix up! The BINARY 0101 is the computer representation of the number 5. They are bits, only 0 and 1., each one to the left being worth twice the one to its right (in the same way as in decimal, being based on 10, each digit is 10 times the one to its right. So binary 100 = 2x2 = 4 whilst decimal 100 = 10 x 10. Putting 0x in front says that this is supposed to be hexadecimal, and hex 0101 is decimal 257. In hex each digit it 16 times the one to its right, so 100 = 16 x 16 = 256! All these are numbers, but "bit 5" means "the 5th bit", not a nmuber but a reference. Bits are counted from 0 which is the lowest, the one on the end, so bit 5 is 100000 in binary. Remember? We've been through all of this. Therefore the value to test for bit 5 in a logic operation is binary 100000 which is 2 x 2 x 2 x 2 x 2 = 32 = 0x20. This is all repeating what's gone on before. Using 0x0101 is rubbish by any of these measures!!! Please PLEASE go back to that FAQ subforum thread on numbers. I think you have forgotten it all already. Pete

No no no. Sorry, but you have not been reading what I've been writing! 0BC0 is the CONTROL input, which when the A/P is in control is the A/P. FSX will pretty much always copy 0BC0 to 0BC2. I already said that they'll pretty much always be the same. The calibrated JOYSTICK input value is found much later in the offsets. I told you to keep searching to find all the vlaues. FSUIPC will, however, only know the JOYSTICK input value if you assign in FSUIPC -- it won't be reading it otherwise. Pete

Please, please, do look up these functions in the Lua library documentation provided in your FSUIPC Documents folder. It does actually tell you exactly what is going on there. The third parameter is a PARAMETER, not a RESULT. Results are things like X in X = function(parameters). The third parameter here tells the "event.offset" function which user function to call when the stated offset changes. That's the event which instigates the action. If you look earlier you see the function actually called ApuGenOffline (didn't you notice?), so that function is called when the Unsigned Byte (UB) offset 0x940f changes. The function is called with two parameters, the offset value (0x940F) and its current value. This is all precisely as documented in the Library documentation. Please do refer to it. Pete

0BC0 is the control input to the trim, no matter where from, and 0BC2 is the indicator. Both are exactly as described and will almost always read the same value. The autopilot is one control and the axis, when enabled, is the other. But the indicator is the one which you should match -- it is the one setting the needle position on the throttle quadrant or wherever. Pete

Ah! So you, the pilot, will manually move the wheel? You aren't using a program to match it as I thought from your post? So your program will simply display the two values so you can match it? (Of course, if you had a motor-controlled trim you'd be constantly operating the motor to match the AP trim in any case -- I'm lucky enough to be able to do that with my PFC 737NG cockpit). I'm then a little confused by the rest of what you say. Regards Pete

The clue is in the error message: *** LUA Error: ...s\Microsoft Flight Simulator X\Modules\ApuToggle.lua:2: attempt to index global 'Logic' (a nil value) You are referring to a Lua library called Logic, which doesn't exist. The one in FSUIPC is called logic. Note the difference is only a capital letter. Programming is like that -- very very fussy. You have to be more careful to write exactrly what it should be. I must admit this is an easy error to make, and I didn't spot it earlier either :-( (I've now gone back and corrected my post so that new readers aren't also misled). We all make little mistakes like that, which is why it is always important to check for error messages -- which in fact you did. Regards Pete

Okay. They are both available in offsets, assuming the trim wheel is assigned in FSUIPC. I doubt that this is a special case of memory -- all positions of axes are "remembered" in the sense they don't change unless the lever or wheel moves -- excepting that is, for jitter. FSX, like FSUIPC, ignores static values, so the only possible cause of your "memory" effect is that the input value actually jitters slightly. I know from other reports that Saitek devices seem to have a little interaction between their different axes, so that moving one makes another twitch. So you disconnect the axis input from the FS trim action and from then on maintain a fictional value? How then are you going to relate that to user changes on the real trim wheel? If you maintain a constant difference then you could eventually run out of user trim capability at one end or the other of its movement. The only thing I can think of it to slowly adjust the difference until you can again allow the real value through -- i.e. "reconnect". Have you looked through the offsets list? These things are easy enough to find. Search on "elevator trim". You'll find both the FS control input and the indicator output. That's one half. Further searching gets you to the bit in 310A to disconnect the elevator trim axis (and read the note which says you need to refresh that every few seconds), and yet further searching will get you to the offset where the calibrated FSUIPC trim vale, from the axis, can be read. How are you "getting lost"? Regards Pete

Okay. Let me go through the problems I pointed out and explain them a little more. Perhaps they were a bit terse, but the intention was to make you think it through so you could solve things yourself next time. The first point was that "functions" are lumps of code, starting with the "function ..." line which names it and declares what data it should receive (known as "parameters"), and ending with an "end". These lumps of code are executed by referring to them elsewhere, and that reference to them supplies the actual values you want for those 'parameters'. Your function had two parameters, but your call to it had three values. Additionally, the values you supplied were not in fact the types of values your function wanted. That covers the first couple of points I made. The next point relates to data types. There are numbers, like 53 and 0x35 -- the first is decimal, as you'd use every day and the second is hexadecimal, which is much more useful in many computer applications because it relates directly to what hapens in the computer. 53 and 0x35 are the same value, they are just different ways of writing it. The reference I gave to the FAQ subforum was intended to allow you to do things like work out "bit numbers", because you were obviously befuddled by the term "bit 5". It would show you that bit 5 is the bit in binary with value 2^5 (i.e. 2 x 2 x 2 x 2 x 2 = 32 = 0x20). Bits are counted from 0 (2^0 = 1). Another data type which is commonly used is the "string". That term is simply a reference to a string of characters, like "abcDEF1234", and strings are used for messages and passing names and so on. If they look like numbers they can be treated like numbers (this is a facility peculiar to Lua, though, and is not generally true in programming). But not otherwise -- which is why I pointed out that your original proposal would fail on the line if Logic.And(value, 0x0101) ~=0 This would fail because the value parameter was set to the string "UB" by the call to the function. In a follow up message, more in line with the questions I thought you'd respond with in the first place, you said: There are three errors or questions there. The first is that "940F" which is not valid. For hexadecimal it must be 0x940F -- the "0x" in front tells the computer it is hex not decimal. There is a relaxation implemented for the ipc functions where an offset can be given as a hex number in a string, thus: "940F", but I think that needs discouraging because it isn't generally applicable. By "test n" I meant "see if the value n tells you to do whatever it is you want to do, or not". You already programmed a "test" in your line if Logic.And(value, 0x0101) ~=0 You just needed to read the offset 'value' (my 'n') first. And the third question is how to test bit 5 instead of bits 0 and 8, which in your line the number 0x0101 tests. I did actually give you the direct answer to that before -- 0x20 is the value for bit 5. The explanation for that is in the FAQ you didn't want to look at for some reason. The answer provided by Roman earlier is almost there. There were two errors I just noticed and forgot to point out before, so here is the corrected version. All you need is this bit, the corrections are in red: MyData = ipc.readUB(0x940F) if logic.And(MyData, 0x20) ~= 0 then -- Bit 5 = 100000 binary, 32 decimal, 20 hexadecimal -- stop apu else -- start apu end Now all you need to do is fill lin the lines to stop and start the APU, then assign the saved Lua to your button. BTW note that in Lua comments are introduced by --. The // prefix is from C/C++ and doesn't apply in Lua. Pete

You simply provided a solution. I could have done that but he stated he didn't want that! He actually stated the event -- assigned to a button or switch. That isn't an event so much as the thing which runs the plug-in, so all he needs is the content of the function, not the function itself. I did explain that too. But then he threw my help back at me. I don't understand folks like that. Makes no sense! Regards Pete

What's that supposed to mean? You asked me to help you program some Lua plug-in. So I did so, step by step. I could instead have written the program for you -- it's only a few lines -- but the way you asked you seemed to want to learn. If you do not want to learn just ask for the solution instead! I provided a detailed step by step account of what was wrong and how to make it right! What better could I do? Sorry, but if you don't appreciate the help I give, please don't come and ask for it. I don't appreciate having my detailed assistance thrown back in such a way! :-( Good bye. Pete

You need to test things yourself. You won't do any harm. It either works or doesn't. This function: function ApuToggle(offset, value) has two parameters, "offset" and "value". Why? You never use "offset". This line: ApuToggle("940F", "UB", "0x0101") calls your function, setting offset to the string "940F", and value to "UB". The third parameter (0x0101) is of course discarded because the function only takes two parameters. No where do you actually read the value in offset 940F, so the plug-in cannot do anything. In fact it will fail on this line: if Logic.And(value, 0x0101) ~=0 because you cannot use the And function on the string value (which is sert to "UB", remember? For what you want to do you don't need functions. All you need to do is read the offset (using ipc.readUB) and test it. But not with 0x0101 which is a 16 bit value with bits 0 and 8 being tested. Why bits 0 and 8? You said it was bit 5, which is 0x20. If you don't understand hexadecimal numbers or binary or bit numbers, please see the FAQ subforum hread on bits and numbers etc. Pete

Actually, I'm a bit puzzled. Without delving into the code I don't really know what is going on. The data returned by HidScanner does lead me to believe that the HID facilities could actually decode the Mouse style data. The button positions are identified, as are the "axes" positions, albeit with different names. However, I plugged the Vendor and Product IDs into HidDemo.lua (one from the collection installed with FSUIPC), and get no data from com.read or com.readlast. Note that I had to increase the "Device" number to 1 in any case. With my logitech wireless mouse and keyboard system all three parts (the wireless module, keyboard, mouse) have the same Vendor and Product, so you need to count down in HidScanner to see which Device number to use (counting from 0). I'm a bit intrigued. There's nothing obvious staring at me for the difference, apart from the blatant "Device is a mouse" message in HidScanner. Maybe my code for HID devices simply eliminates non-joysticks. I'll have to delve into it. But not now -- maybe tomorrow. I'll see. Meanwhile, I suspect you won't get anywhere at present. Pete

Mouse events are available in FSUIPC4. I'm afraid I have frozen FSUIPC3 development, some time ago in fact. Recent changes have been just corrections and minor improvements. Adding complete new facilities is a definite no-no. It's such old code now, I have to move on. I'm afraid only joystick type HID devices are fully handled by the HID functions in the COM library. Mouse and keyboard devices use completely different protocols which FSUIPC will not recognise (in the same way as HidScanner doesn't, in fact). You can certainly try reading data from them and working out what it might mean, but for that you'd be on your own. The gethidvalue, gethidbuttons, gethidcount and testhidbutton functions provided by FSUIPC only interpret joystick type data. Maybe you can get reference information for Mouse USB data on the Microsoft support websites. Or else, trial and error -- with logging, as you say, but you'll not LogExtras=512 because that logs results of the HID-specific functions which only work on those joystick devices. You'd need to read the data and format and write it to the log yourself, with your own Lua code. (the Lua trace/debug option might help, but decoding the data from that would be difficult). Note that in your code all you have done with the mouse is open it to get a handle. You need to do that just once at the beginning. You need the handle in a "com.read" function in order to actually read data. The length is given by the 'rd' parameter you got in the open response too (or maybe the 'rdf' value if the data is supplied as a 'feature' block) but I think these lengths might only apply to the input report types supported by joysticks. For mouse and keyboard the input report numbers may be different and openhid won't know their lengths. You are going to need a lot of experimentation, including possibly selecting which reports you receive give you the information you need. Regards Pete

You don't need separate up and down settings in any case, just check both up and down so they are bi-directional! Good. That is the better way. Regards Pete