Pete Dowson

I've implemented this now for you to try. If you please download these updated versions: http://fsuipc.simflight.com/beta/FSUIPC3908.zip http://fsuipc.simflight.com/beta/FSUIPC4508.zip and let me know if these work for you, both in FS9 and FSX. Regards Pete

Well, since by default FS assigns the F2 key to the "THROTTLE DECR" control (which would actually be a better choice to the keypress -- all FS is doing is looking up F2 in its keyboard assignments and converting it to THROTTLE DECR), I should think the equivalent for Propeller Pitch is "PROP PITCH DECR", which by default is assigned to the Ctrl+F2 keypress. Likewise, the MIXTURE DECR control is assigned to Shft+Ctrl+F2. In all cases, however, i'd strongly recommend assigning direct to the FS Control rather than the KeyPress, which is (a) inefficient and (b) liable to reassignment (by you of course, but also other programs, including FSUIPC). Regards Pete

None that I know of. All of the SimConnect variables for the GPS are read only. I found the EFIS switches were controllable via the gauge's named Local Variables (L Vars), after adding the facilities to FSUIPC4 for listing and accessing these. Using the Loglvars Lua plug-in I supplied I don't see any named variables for a GPS. Even with the FSX G1000 loaded there are none which appear applicable. There's a whole array of GPS controls in FSX. Do any of them work? Do any of them do the job? They are the ones beginning "GPS ...". Regards Pete

Hmmm. So if you want the peak I'd need to keep changing the offset when on ground until it decreases, leaving the hiughest value I saw? Lua facilities, like Macros and assignments, need a registered copy. Sorry. Show me your Lua program (to save me time) and I'll run it here when I get a chance. Regards Pete

Okay! Hope you progress well now, then. The same BCD encoding applies to all of the radio frequencies too, by the way. Regards Pete

That is all the info i got. I searched all the pdf's for any information about how to use the value, as the value wasn't 0x1200 for the code "1200" i didn't know what to do. :( That is all the information you need. Plus an elementary book on programming. To write programs you need to at least have a rudimentary understanding of bits, bytes and number representations. If you are a complete beginner then interfacing to FSUIPC is certainly not the place to start. Pete

You need to use a better search program then! The write up for offset 0354 starts off saying "Transponder setting" before it goes on to show 0x1200 as an example. How on Earth do you know 0354 is the correct offset if you don't even refer to the offsets listings? Surely they are the mainstay of the SDK!!! Please ALWAYS refer to the documentation for any offset you plan to use. It will help! Pete

4608 is decimal, and that most certainly that equals (i.e. is IDENTICAL to) 0x1200 (hexadecimal). As clearly documented, the transponder value is in Binary-Coded Decimal -- there's even an example shown -- the "0x" is the prefix for hexadecimal -- in Basic I believe it is &H. In BCD each group of 4 bits gives one digit. Show it in hexadecimal and it will look right. Please please do read the documentation a little closer! Even use the tools provided, like FSINterrogate and the FSUIPC IPC logging, both of which would have clearly shown you that 0x1200 = 4608. ( = 1 x 4096 + 2 x 256 + 0 x 16 + 0 x 1) Regards Pete

Ernot so sure that won't simply give you a "normal" rather than impact-related value. Hmm. Before I make any changes, please monitor the values and check that FS is indeed doing what you think. I suspect it may not. You can do this by using a little Lua plug-in to read and log to a file the G-force continuously (with, say, a 5 or 10 mSec sleep per loop only, to make sure you don't miss any frames). Don't you use FSX too? have you checked it there? With SimConnect working asynchronously it may give different results. Regards Pete

That FSUIPC version is out of date and unsupported. Not that I can see it makes any difference. And there is no problem with the WideFS links shown in the logs. Did you check the FSUIPC log too, to make sure no errors are reported in its communications with FS? Everything? Or just the PM instrumentation? Surely no FS pauses? It sounds to me as if there are problems with CDU access via its file operations. Maybe your folder, specified in the CDU INI for its access, is situated badly? It would be best on the CDU PC, not on the FS PC where disk access may be slower because of FS needs. Don't forget that a lot of PM's communications relies on simple file sharing access over the network, it isn't all FSUIPC/WideFs related. The only other possibility i can think of relates to graphics drivers on the PFD/ND PCs, but if this was the case i would expect them to occur any time, not just when there's a CDU update. Regards Pete

No, it only runs at start-up. Really the main idea of ipcReady is to load and run any Event-monitoring routines you want. You could get ipcReady to run a Lua plug-in which monitors changes to the aircraft name offset (0x3D00, string, length 256), then take action when it does. No. None. ipcInit and ipcReady are run at FSUIPC startup and FS first "ready to fly". That's it. No other times. Functions installed by the Event library stay loaded for the whole session, unless you explicitly Kill them, or have an ipc.exit call in the Event receiving function, or an event.cancel call to cancel the function. Event functions can monitor FSUIPC offsets, joystick buttons, keypresses, and FS controls ("key events"). Regards Pete

Not "shortcuts", but you can create controls which you can then assign to buttons or keyboard shortcuts. For the PMDG add-ons I think everyone has had good success with using the "mouse macro" facility in FSUIPC for this. Just for those particular switches, or aren't you having success with any? If you can't make it work with any of the switches you need to tell me exactly what you are doing, because you are going wrong somewhere. If only with the ones you mention, then I don't know if PMDG actually has any code behind all of the switches -- if they don't actually do anything, they may just be decorative graphics. Mouse macros have to have actual code inside the panel software to call. A mere graphics effect only won't be usable -- there's little point in any case. The whole idea behind using the mouse macros was to be able to use them WITHOUT the graphic even being on screen. If you only want to see a switch toggle on screen then either use the mouse, or take a look at Luciano napolitano's "Key2Mouse" program. Regards Pete

Yes, all the radio frequencies have always been in "Binary Coded Decimal" in all versions of FS I've ever worked with, right back to FS4. Make for easy conversion into characters -- each decimal digit is just 4 bits, 0-9, so shift out 4 bits, add the character '0', and you have the printable digit. They are all documented this way, with examples. Applies to ADF and Transponder too. Regards Pete

Oh, good. That's a relief! 4976 in decimal is 0x1370. That is correct BCD encoding for 113.70 frequency. You evidently have FSInterrogate showing decimal instead of hex? Maybe you are sending the wrong values? If you are sending 1370 decimal that represents an invalid frequency (105.5A) so will probably be rejected by FSX. for 113.70 you have to send 0x1370, or decimal 4976. The pattern is clear if you use the correct number base! Regards Pete

That still works in FS9? I think I documented it for FS98 or FS2000 many years ago, but i thought that all changed when FS was updated to use DirectInput. If it works still that is useful! Regards Pete

I'm afraid I've forgotten everything. I've not used EPICINFO for nearly 10 years and have no EPIC card to test with. Certainly nothing in EPICINFO has changed for all that time -- excepting the conversion to FSX for EPICINFO5. But that has never been tested by me on an EPIC, only via logging . The testing was done by others and there was no bad feedback. Really it should all work the same as the only changes were in the interface to FSUIPC, which I could test by simulation and logging. Can you use the Logging facilities in EPICINFO to work out what is going on? Also log IPC reads/writes in FSUIPC. Are you able to re-test with FS9? If it works there but not in FSX then I have a bug. Else it is something you are forgetting. Pete

That's neata much better solution! ;-) Thanks! I'm not sure how to do that either, other than possibly make the config file read-only (stopping you making any changes), or editing the devices CFG files in FS which define the defaults it assumes when it sees a "new" device (i.e. one which wasn't connected last time it ran). Alternatively, if you have a registered version of FSUIPC you can of course disable controls in FS and assign everything through FSUIPC. In the recent versions there are facilities for disassociating the Windows joystick ID number (0 -15) from the Joystick Name, using letters A-Z instead, so that FSUIPC can re-assign by name if things move. Regards Pete

51? You don't look 51! Is that an old 'photo? :shock: I was pretty bald by the time I was 40not much left at all now I'm nearly 66! ;-) Pete

"Likewise" to a thread which ended a year ago isn't a lot of help. If you have a problem you want help with, please start a new thread and post full details. Regards Pete

That had me puzzled till I realised 5 of those 7 seconds were occupied by the first message displaying! ;-) Every "ifthen" needs an "end" after the code it applies, as does every "whiledo". Regards Pete

That would only be the case where your switch is programmed to operate a "toggle" event or control in FS. Most switches can be operated with On or Off controls, or, failing that, by using the Offset controls to change FS internals. All the lights are mapped to bits in offset 0D0C, so you can use Offset Word Setbits to switch them on and Offset Word Clearbits to switch therm off, individually. The mapping is shown in the FSUIPC SDK document listing all the offsets. That would make sure your switches still operated correctly in the on/off sense, but of course it doesn't deal with general synchronisation when you start up or when you load a new flight. The easy way to deal with that is to make it a matter of procedure to flick all your switches up and down initially, and after loading a flight, to get everything in synch. If you were more ambitious you could write a Lua plug-in which could either be run initially, when FS is ready, or when a flight is loaded (or both), which scans your switches and sends the appropriate commands to FS. Regards Pete

All offsets in range (i.e. 0000 to FFFF) are "valid" in all versions of FS -- you just read zero or rubbish if that version doesn't support it. If you write to an unsupported offset you might have it logged as a failure in FSUIPC if it is a read-only one, or you might possibly crash FS if it relates to some unknown location inside its workings -- though this cannot happen in FSX because all of the offsets are artificially presented by FSUIPC and only valid ones get through to FSX via SimConnect or FS events. Mostly reading or writing unsupported things has no effect, but take greater care with writing. Regards Pete

Aha! so the trimming is actually working, it is only the graphics which have a bug. I don't suppose many folks notice this -- when flying you trim the aircraft for correct trimmed flight, you don't tend to do it whilst watching the wheel move up and down! ;-) It varies. A lot of panels have decorative switches with no functions other than to make them look better. I certainly have some add-on aircraft with working taxi lights. Regards Pete

But not good. Since the number 0 ends the list of Macros, all you needed to do for that example is: Actions737 = {0, 65584, "QNH -- LOC SET" } Then you won't get a spurious macro sent. For no control, you should simply have Actions737 = { "MACRO NAME", .... , 0, 0, "QNH -- LOC SET" } and test for ~= 0 for sending the control. i.e. -- now the control i = i + 1 if actions[i] ~= 0 then ipc.log("Sending control " .. actions[i]) ipc.control(actions[i]) ipc.sleep(500) end Better, if you want to allow a list of controls, do it like the macros: -- now the controls i = i + 1 while actions[i] ~= 0 do ipc.log("Sending control " .. actions[i]) ipc.control(actions[i]) ipc.sleep(500) i = i + 1 end That will cope with zero or more controls. Ahanswered! ;-) Ouchdoesn't an error get reported? If the string is optional you should alter the code like this: -- and lastly the message i = i + 1 if actions[i] ~= nil then ipc.display(actions[i], 5) end You should be able to figure out your own code enhancements from these simple examples. Regards Pete

Erisn't that something you do regularly anyway? It's a PC left on all the time? Sounds like something glitched and corrupted something in the lower levels somewhere. Anyway, glad you sorted it! Regards Pete