Pete Dowson

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

wideFS is only using simple, standard TCP, UDP or IPX protocol, about as simple as you can get, copied from Microsoft examples. something is certainly blocking it completely. There's nothing I can see wrong with the INI files or Logs. There's simply nothing getting through. Have you tried UDP at all, just in case it's only the TCP side that broken? I think windows Explorer uses UDP, idf it is Explorer you mean by " thru my home network". Certainly sounds like hardware put like that. Software doesn't normally behave like that. Regards Pete

You have two axes assigned to the same function: I expect one is preventing the other from being seen in calibration because of arbitration. If you download the latest Update from the Announcement above the arbitration is now switched off during calibration. However, if you don't want both axes operating and possibly conflicting in FS, you should renmove one of those assignments. Pete

You do if the broadcasting isn't getting through. That needs both PCs running WinXP or later, and both to be in the same named workgroup. Wireless routers are general pretty good these days, but if they are used in a room with lots of metal and electrical equipment (like a kitchen!) they can prove problematic. I need two access points in my house because of thick walls made with some sort of old fashioned brick which seems as hard as metal! Well i don't use firewalls BETWEEN my PCs -- I have a good setup on my ADSL modem/router. But you certainly should simply be able to give permissions -- FS and WideClient, ports 8002 and 9002. Nothing at all as far as WideFs is concerned. It isn't a disk access program, it sends data only by Ethernet. However, some programs you run on the clients may want to read or even write data on the Server. That's something you have to find out from the application documents. Typical things are scenery file access for planners building databases, flight and Plan files folder access for planners and other programs which need to read plans, etc. Regards Pete

Hmm. All that shows is that nothing is arriving at all from your client. So, it has to be either firewall, or a selected name or IP address which is incorrect, or simply that your Network isn't working. Have you checked the actual network? I've had network cards/ chips fail before, and switches/hubs come to that. Check the INI files again. In fact better that that, show me them, both of them, Server and Client. There's nothing else to go on here. All the logs indicate that the two PCs aren't communicating, full stop. No, it just means you haven't installed that protocol. Microsoft made it optional a while back now. Regards Pete

That's only half the story. Where's the Server's log file? Well, someone has, obviously! ;-0 Pete

I've done one which should work, for those two aircraft, and I've done it in a way you should be able to add to it quite flexibly. There will be as many ways of doing this as there are programmers, but i am a beginner in Lua, so this is as good as I can do it in a short space of time: aircraft = { "747", "737", 0 } -- needs to match somewhere in the aircraft title macrofiles = { "747 EFIS", "PMDG737", 0 } -- the macro filenames for those aircraft -- Lists of macros for each aircraft, followed by 0 then the control to use then the message to use Actions747 = { "BARO_ON", "FPV_ON", "TFC_ON", "STA_ON", "FD1_ON", "FD2_ON", "VOR1_ON", "VOR1_ON", 0, 65584, "EFIS -- SET\nQNH -- LOC SET" } Actions737 = { "EFIS_1", "EFIS_2", "EFIS_3", "EFIS_4", "EFIS_5", "EFIS_6", "EFIS_7", "EFIS_8", 0, 65584, "EFIS -- SET\nQNH -- LOC SET" } -- table of those actions for indexing the same way as the aircraft and macrofile names IndexToActions = { Actions747, Actions737 } -- read aircraft title Name = ipc.readSTR(0x3D00, 256) ipc.log("Name = " .. Name) -- identify aircraft by substring from "aircraft" list above i = 1 j = 0 while aircraft[i] ~= 0 do if string.find(Name, aircraft[i], 1, true) ~= nil then j = i break end i = i + 1 end if j > 0 then -- found it! ipc.log("found it at " .. j) -- use action list actions = IndexToActions[j] i = 1 -- first all the macros while actions[i] ~= 0 do ipc.log("Action" .. i .. "= " .. macrofiles[j] .. ": " .. actions[i]) ipc.macro(macrofiles[j] .. ": " .. actions[i]) ipc.sleep(500) i = i + 1 end -- now the control i = i + 1 ipc.log("Sending control " .. actions[i]) ipc.control(actions[i]) ipc.sleep(500) -- and lastly the message i = i + 1 ipc.display(actions[i], 5) end The parts you'd need to add to for other aircraft are: Aircraft list aircraft = { "747", "737", 0 } Identifying the aircraft by substring in its title. You may want these to be more specific -- they'll catch the default 737 and 747 too. Just make sure there's a 0 at the end of the list, so stop the loop. Macro file names used macrofiles = { "747 EFIS", "PMDG737", 0 } A one-for-one relationship to the aircraft list. If you need more than one macro file for an aircraft list you'll need to do it differently. i just separated the file nmae from the macro name to save space and typing! ;-) Action lists Add a list of the actions for the aircraft, naming it what you like, and adding the name to the correct place in: IndexToActions = { Actions747, Actions737 } Note that I've adopted a format with a list of any number of Macros, ended by 0, then the control you want to send (if it is always the same, take it out of there and use it explicitly instead at the end of the code), and the message you want displayed (same consideration). You'll see "ipc.log" calls in there -- that is for testing, so i could see that it worked okay, even though i don't have the aircraft nor your macros. Take them out when you've done, as you like. Regards Pete