Iceking007

Okay, thank you.

doh! I'm so sorry John, I'm such an idiot! The control I was looking for was the Gyro drift; I must have had the wrong control numbers in a backup. ini file that I used. It's working properly now. Do you know if there's a way to export "keypresses" from fsuipc to my Swift VATSIM client. I want to control Swift 'hotkeys' with cockpit hardware. Fsuipc can see this hardware but Swift doesn't. I understand I'm outdated, I appreciate all the assistance you've offered. It has helped immensely.

I had assigned a couple keys to rotate the compass (HSI) to correct for wind drift. This has been working well, until lately, I think a potential culprit is RXP and the problems I have been having with their new software. However even when I completely uninstalled and removed it I did not get the compass functionality back. I tried changing the keys but that had no success either. The log file is attached, INDUCTOR_COMPASS_REF_INC/DEC (66577/66578). I'm not sure if something is broken in FS, as it seems these are seen by fsuipc correctly and passed through. Is there some way I can troubleshoot or fix this? Do I need to completely reinstall fs or can I just replace a couple files? Thank you for your time. FSUIPC.log

Okay, I think I sorted it, I put it at -65532,0,0,65016/1542 It looks close from the digital indicator from the ground but I'll have to take it flying to see; it might still be too much, I wonder if the real Mooney has this much trim deflection!? I cannot fathom why you would ever need that much given the flight characteristics in the simulator. But I find too that the "takeoff setting" areas for horizontal and vertical trim are both aggressive and not very practical in my experience. More fun at the airfield. Have a good one.

That's okay. So this goes into the [JoystickCalibration] section? As: Rudder Trim=-65532,0,065016/16? What do these numbers mean? Why is RudderTrimControl=0, should that be 1 or something? Another oddity while I have you here... fsuipc won't let me set the Throttle and Mixture up (my vernier ones). These are in the same usb control box as this rudder trim. FSUIPC sees them in the calibration tab but not in assignments, I have to assign the via the fs menu. I think it's something to do with PFC/Windows labeling these axis as "dial" and "y rotation"; however luckily fs does see them correctly. I'm trying to make use of the fsuipc custom configurations so that when I change between my vernier and other throttles I don't have to go and reassign everything like I have in the past. That makes changing aircraft even more cumbersome than it already is. Thank you.

Is that entered in the Axis Management tab, or the Calibration tab? I'm only able to enter values in the Axis tab when setting up ranges... Also, is the divided only on the last one? Thank you John.

Hello, I am using a PFC USB throttle system, it includes a rudder trim knob. The problem is that when I fly the Mooney Bravo (M20M), it requires VERY little and extremely precise trim adjustments. This works okay with the factory trim buttons, but I don't have hardware trim buttons, only this hardware knob. FS does not recognize this axis so I can't configure that in there and use the sensitivity adjustment. I have been unable to create the desired affect in fsuipc. I can make the knob FAR more sensitive, but not less. Ideally I probably only need 25% or even 10% of the current range on either side. As it is now I can select maximum trim deflection in only 20° of rotation... I'd like to get 25% deflection at 120° of rotation. Barring that, perhaps I can get it to use the rudder button like a jog/shuttle wheel would. I could see doing that with the range adjustments in the axis tab, but that would take painstaking configuration to say map every 5 degrees in both directions to a single button press. Thank you for your time.

Okay.

This is my file so far... It does run in fs. The # and "" as used above are just place holders, and obviously just forgot it was only event.key instead of event.keypress; I cannot memorize everything you know. Yes, the 2 was supposed to track the key up; if you recall I was using that earlier and it was not working, then you suggested just tracking the key up/down variable; as you will see, that is what I am using now; however tracking it both as 1 or 0 in my timer code doesn't yield the results I'm after. FYI: As a side note, I'm planning on separating my 'display' code into a separate Lua file, it has some bugs currently, so please ignore it. Please don't laugh at my work, remember that I am not a programmer or I wouldn't even be here in the first place.

Hi John, Well... it seems no matter what I do I am unable to get a key up reaction. Is there a quick method you would suggest to viewing the key state changes? It seems to me that the key up does occur somewhere in the chain as my key downs are tracked without fail; I need to be able to verify if the key release (key up after a precursor key down) is being seen in Lua and how it's being interpreted. I'm loosing a lot of wind in my sail with this whole fiasco, I sincerely appreciate all the assistance, it's just I was expecting to take less than a week on this and now it's been a couple months. I just recently purchased a used pc, and so I am slowly changing over to a Windows 7 64bit build for my fs. I should be then able to run the software, but I'm not giving up on this coding project, I forsee the ability to implement it, and I don't like to stop just because something is broken that should work. The other problem with going away from Windows XP is that some software I want to run is only XP compatible, I'm hoping I can still run it on W7 in compatibility mode. To add insult to injury, as if I don't have enough on my mind, I just recently lost my job... and so now in this uncertain economy I need to get that sorted ASAP; the bills are already piling up! I miss flying, I'm hoping I can get back up into the air soon! I didn't have much luck with event.keypress(#,#,2,""), but if I use: event.keypress(#,#,kd,"") and then: function ""(#,#,kd) if kd == 1 then ipc.display("Key is Down") else if kd == 0 then ipc.display("Key is Up") else ipc.display("Key is Other") end end That's simple and should work? - you're probably going to poke all sorts of holes in my code, but at this point I just don't care... I haven't been sleeping very well lately and now I'm up in the middle of the night typing this out without much though, so I guess I deserve it. Funny how we all get what we deserve. Thank you for your time and your patience, I hope to one day not be a burden!

Re: offset 05CC appears to be "The viewpoint Bank" according to my documentation. Are these offsets an fsuipc thing?! I was under the impression they were fs memory locations; but if so then they would not change with fsuipc updates, only with fs versions (ie fs9, fs10).

So I completely misunderstood the hex BCD reference, that is until you spelled it out for me of course. I apologize for my stupidity; much to learn I have. I believe I've made all the corrective changes to my code now, I'm hoping to test it sometime in the next week. With any luck it should all work. I'll try not to pester you with my learning; I have spent a lot of time (most of my time as of late in fact) learning Lua, and reading all the documents, and going through other Lua programs both related and unrelated to fs. But I'm sure you are aware, these skills cannot be mastered in two weeks. Thank you for your guidance; IF I get my code working as intended I shall post it online to share with others.

No I don't believe it is a limit as I already have that call and all the functions run. But I'm just trying to toddy up my code and make it more efficient.

Okay I appreciating all of that. Yes by skipping the downup function I was referring to your keyUpDown(); I should be able to just use that within my current function rather than shooting another one. I'll get it sorted out, thank you.

Hi John, I'll have to try those out in the Sim to see what I'm actually getting; I don't think there's much extra processing to convert the hex?! But I certainly was not aware there was also a decimal registry; I didn't seem to find it in the offset document but I will look that up as well. So with the keys and buttons, then I'm assuming fsuipc just automatically assigns a down/ up (1/0) bit to every input and that is 'catalogued' in the third "slot" ie(1, 2, 3)? I haven't added conditions to any of my functions, they seem to be working, save for this issue. However if what I'm thinking above is correct... then I'm thinking I could bypass the downup function and just pass that indicator bit onto my actually function and qualify it with a simple if statement; less code I figure that way, as I don't need a discreet return of this state. Thank you.

So for reference, the string.format("%x") returns a hex value; I altered this to %d in order to return a decimal value... or at least it works in a Lua terminal, I have yet to test it on the simulator. I was even able to get the decimal in there, part of the code In using is below. local comVal = "\t " .. string.sub(string.format("1%d", Com1Actv), 1, 3) .. "." .. string.sub(string.format("1%d", Com1Actv), 4) I have been listing my Lua code in the Auto section as well, FYI, but thank you for that tidbit. I'm curious, could you explain the function "..."(#, #, "downup")? Is downup a variable fsuipc sends? I'm assuming these are just (unclassified) variables, in that I could use: function "..."(apple, peach, spaghetti) and it would still work, or would I break things? [obviously that's a ridiculous example, but I have seen so many variations of joy vs j, downup vs du] And what is the specific reason to specifying or calling/ pushing a variable? Won't all functions see all variables unless they are local? Thank you; not enough time to completely work on all of these changes, hopefully I can get this working this weekend!

Okay, that's excellent, thank you for all of that information. - yes the 311A was just a typo... I am using 0x311A in all instances as per documentation; I saw the "311A" reference as well, but don't use it. Also instead of k, o as per above, I'm using variables that are assignments to my key; it's working because it's the same code throughout. I'll try your downup grab, hopefully that works out better; and the logging could be useful. Thank you, have a good one.

Hello, I have a few problems running certain Lua code in FSUIPC 3.9. I have been working with the log files and starting to get the hang of understanding what is going on. I appreciate all the help so far and the push to get me to where I am now; I finally see some light at the end of the tunnel. The first problem I have rooted out and am unable to solve for the moment on my own is that I am using the event.key() function to pull controls and run functions inside my code. event.key(k,o,"'function'") seems to be working well (and therefore "keydown" registers properly). However if I'm looking for event.key(k,o,2,"'function'") - ie: key up - does not seem to return a result. To test this I literally used: event.key(k,o,"keyDown") event.key(k,o,2,"keyUp") where: function keyDown() ipc.lineDisplay("Key Down") end 《and》 function keyUp() ipc.lineDisplay("Key Up") end Even omitting the 'down' function, I don't get any results from the 'up' function. Perhaps I'm missing something somewhere? This is to run the "Triple Use" code, however I'm setting ipc flags to track Key up and down because the example Lua file uses a joystick test function (that I do not believe, has an equivalent "key" counterpart... not that I have found). According to the documentation this method should work. Another issue I found was with trying to get COM and NAV offset values. For example ipc.readUW(0x311A), If I use: comDisp = "1" .. ipc.readUW(311A) ipc.lineDisplay(comDisp) OR comDisp = "1" .. string.sub(ipc.readUW(0x311A), 3) ipc.lineDisplay(comDisp) I get results... but I cannot fathom how to interpret the results, the numbers I get on screen or something like 10007, or 1961. I tried converting these from hexadecimal to decimal but even that doesn't give me a "BCDE" frequency. So I'm not sure what step I'm missing; same happens with Com1, and Nav frequencies. A few minor issues I will hope to clean up, are, FSUIPC's log reports "... not defined, sent to FS"; but it still runs in my Lua script properly. Do you have to define keys (and joystick buttons for that matter... but mostly keys), in both fsuipc and Lua? If so do you just assign the key press to "Lua script" general? Or "Lua set"? Or one of the other options? Do you need to specify an offset or parameter?! I'm not clear on all that but it seems like there's a lot of wasted pushing around that I hope to clean up. Another thing; I haven't been able to get SPAD working... but I did notice during my COM display tests, as mentioned above, when I use my rotaries to adjust the COM frequency, while calling for the display to update there is a severe bottleneck; however it's not the rotary or display independently (it's mostly likely the circular reference in my code); if I adjust the COM frequency with the Saitek the display is instant, the rotary works well for other commands and is instant; but the code together has an issue I'll have to look at better. The login in fsuipc is actually very good; even helps with Lua code issues just like a terminal; thank you ever so much for this program!

Offsets are still very confusing to me... I'm not even sure how you envision that working. But in my Lua script I was adding some offsets to read values... so that's a start. However a Mentone I can't even get it loaded. Thank you for all the help John. I'm sorry I wasted your time.

Hm, perhaps the doc I have is written differently... I interpreted that as only for buttons. So format would be: [Keys] n=CP(F+121,11)121,11,C# ?

How do you do conditional formatting on keys? If you can then that is a possible solution.

But if you need a button to activate a key you just do that in the .ini file: n=p#,#,C# But I can't use a button; my hardware is only programmed as keys... that is the whole problem; I need to convert a key into a conditionally formatted command.

Dang! This doesn't hold much weight, but I don't think that's very useful. I don't know why you would need to have a button activate a key; I need a key to activate a button. So, I guess I can only use Lua?

I thought 1070 can be used for virtual buttons also as per the advanced user guide: "1070 Key Press and Release (param is Keycode + 256*Shift code, or JsBk)" - JsBk? So this is not possible then?? In the .ini file, the keys that were used are 109 & 6 respectively. FSUIPC.ini

So I'm learning a little bit about logging. I have some new data; does this help us at all? I started fs and turned on my battery and avionics; that's all, and then I pressed one button. Here is what I can tell is the last line from the avionics master switch, and then everything else the log wrote from only the one button press. 110641 *** EVENT: Cntrl= 66293 (0x000102f5), Param= 0 (0x00000000) TOGGLE_AVIONICS_MASTER 130703 FSUIPC Control Action: Ctrl=1125, Param=0 130703 FSUIPC Control Action: Ctrl=1070, Param=2937 130703 SendKeyToFS(00060079=[ctl+shft+F10], KEYDOWN) ctr=0 130703 Sending WM_KEYDOWN, Key=16 (Shift) (Scan code 42), Ctr=3 130703 Sending WM_KEYDOWN, Key=17 (Control) (Scan code 29), Ctr=3 130703 KEYDOWN: VK=16, Waiting=0, Repeat=N, Shifts=1 130703 .. Key not programmed -- passed on to FS 130703 KEYDOWN: VK=17, Waiting=0, Repeat=N, Shifts=3 130703 .. Key not programmed -- passed on to FS 130750 Sending WM_KEYDOWN, Key=121 (Scan code 68), Ctr=1 130750 KEYDOWN: VK=121, Waiting=0, Repeat=N, Shifts=3 130750 FSUIPC Control Action: Ctrl=1070, Param=2827 130750 SendKeyToFS(00060079=[ctl+shft+F10], KEYUP) ctr=0 130750 SendKeyToFS(0006000B=[ctl+shft+(null)], KEYDOWN) ctr=3 130750 .. This key is programmed in FSUIPC 'Keys' options 130781 Sending WM_KEYUP, Key=121 (Scan code 68), Ctr=6 130781 KEYUP: VK=121, Waiting=0 130813 Sending WM_KEYUP, Key=17 (Control) (Scan code 29), Ctr=5 130813 Sending WM_KEYUP, Key=16 (Shift) (Scan code 42), Ctr=5 130813 Sending WM_KEYDOWN, Key=16 (Shift) (Scan code 42), Ctr=5 130813 Sending WM_KEYDOWN, Key=17 (Control) (Scan code 29), Ctr=5 130813 KEYUP: VK=17, Waiting=0 130813 KEYUP: VK=16, Waiting=0 130813 KEYDOWN: VK=16, Waiting=0, Repeat=N, Shifts=1 130813 .. Key not programmed -- passed on to FS 130813 KEYDOWN: VK=17, Waiting=0, Repeat=N, Shifts=3 130813 .. Key not programmed -- passed on to FS 130844 Sending WM_KEYDOWN, Key=11 (Scan code 0), Ctr=1 130844 KEYDOWN: VK=11, Waiting=0, Repeat=N, Shifts=3 130844 .. Key not programmed -- passed on to FS 130875 SendKeyToFS(0006000B=[ctl+shft+(null)], KEYUP) ctr=0 130875 Sending WM_KEYUP, Key=11 (Scan code 0), Ctr=1 130875 KEYUP: VK=11, Waiting=0 130906 Sending WM_KEYUP, Key=17 (Control) (Scan code 29), Ctr=2 130906 Sending WM_KEYUP, Key=16 (Shift) (Scan code 42), Ctr=2 130906 KEYUP: VK=17, Waiting=0 130906 KEYUP: VK=16, Waiting=0 This button (I presume - imo) did not do anything useful... Now to compare that log with the next code; which after I pressed that button, looked at the log file, saved the log file externally, then I only pressed one more button; the hardware 'sister' button to that one; this is the log script from that one to this one: 391281 FSUIPC Control Action: Ctrl=1125, Param=2937 391281 FSUIPC Control Action: Ctrl=1070, Param=2422 391281 SendKeyToFS(00040076=[shft+F7], KEYDOWN) ctr=0 391281 Sending WM_KEYDOWN, Key=16 (Shift) (Scan code 42), Ctr=2 391281 KEYDOWN: VK=16, Waiting=0, Repeat=N, Shifts=1 391281 .. Key not programmed -- passed on to FS 391313 Sending WM_KEYDOWN, Key=118 (Scan code 65), Ctr=1 391313 KEYDOWN: VK=118, Waiting=0, Repeat=N, Shifts=1 391313 FS Control Sent: Ctrl=66624, Param=0 391313 .. This key is programmed in FSUIPC 'Keys' options 391313 *** EVENT: Cntrl= 66624 (0x00010440), Param= 0 (0x00000000) GPS_CURSOR_BUTTON 391422 SendKeyToFS(00040076=[shft+F7], KEYUP) ctr=0 391422 Sending WM_KEYUP, Key=118 (Scan code 65), Ctr=1 391422 KEYUP: VK=118, Waiting=0 391453 Sending WM_KEYUP, Key=16 (Shift) (Scan code 42), Ctr=1 391453 KEYUP: VK=16, Waiting=0 Does that help us in determining what is happening and what isn't happening? I thought maybe the Ctrl is the problem, so I briefly changed the command in fsuipc to another function and it worked. So it's not the hardware, the button, or the assignment. FSUIPC appears to be registering and processing it. There seems to be some sort of disconnect between the "keys" activating virtual buttons. I even changed my fsuipc code to remove the conditional formatting for the buttons (ie no modes, just plainly activate the command - fixed- ) no luck there either. So to me, it definitely seems to be a broken link between keys and virtual buttons.