Pete Dowson

Please note -- I changed the lines you need to add for the logging. One of them would have given you reams of unwanted data about AI aircraft. Pete

It hooks into the calls between the WEATHER.DLL module and the SIM1.DLL module where the former sends the wind data to the simulation engine. It modifies the data going across (the X/Y/Z wind vectors). But even that isn't foolproof -- wind deviations still occur. I don't think I ever located the exact correct places to fiddle these things, unlike with FS9 and before. To be honest, this whole area of FSUIPC4 is so complex that I find that, despite my helpful comments in the code, I have to study it quite a lot to see why things behave as they do. It is over six years now since I wrote it, and at least 4 years since I last messed with it. The imposition of the values written to the offsets you are using DO actually take part in this hooking between the two FS modules, but not necessarily the exact same ones. And without delving into the code a lot more I don't actually remember why. If you add the following lines to the FSUIPC4.INI file before running FSX a quite full log of the actions being taken in FSUIPC4 will be produced. Perhaps you could then find the area in the log which leads up to and includes the failure of your writes, and show me the extract: Add the lines to the [General] section: Debug=Please TestOptions=x4000 Regards Pete

I'm amazed you get them working at all if you are only updating them at 5 second intervals. You could try doing it every 50 mSecs. But in the offsets list it does actually say that "it is hoped that this can be written to ...", and the right-most column, the one detailing write capabilities, it does say "No" too! And even in red. Did you not notice these comments? Basically, Microsoft stopeed developing SimConnect for FSX before they got to this facility even though it was on the list right from the beginning. For FSX, the weather control features which work well are those operated through the New Weather Interface, and even then they are only directly controllable at the aircraft if you put FSX into global Weather mode. This is what ASE/ASX/AS2012 does in "DWC" (Direct Weather Control) mode. Otherwise the weather is always affected by the three weather stations designated for the area the aircraft is in. Regards Pete

You are referring to the Programmer's Guide which covers up to FS2004 only. Please refer to the document called "FSUIPC4: Status of IPC Offsets for FSX". That is your offset reference for FSX, ESP and P3D. Pete

Yes, and I've been waiting for you to confirm which controls you assigned to, but then it got confused when you talked about offsets. You never actually said which controls you used. Actually, there was a typo in my earlier message. There are no FS "COM1 ..." controls, the standby controls are COM Radio fract dec and COM Radio whole dec, etc. You couldn't actually have made the assignments you say. The controls starting COM1 are those added by FSUIPC and have "Use" not "Radio" in their names. The COM Radio ones are the normal FS controls, exactly as you could just as easily assign in FS itself, and all FSUIPC does is pass them straight on to FS. So what happens then depends upon FS. Why don't you try using FSUIPC's logging facilities to find out where you are making mistakes? Here's a log from my FS9 installation, where I've assigned 4 keypresses, one each for COM Radio Fract Dec, Inc and COM1 Use fract dec, inc. I've enabled Key/Button logging, event logging, and Monitored offsets 034E (Use COM1) and 311A (standby COM1). This is with the default 737: 205188 Monitor IPC:034E (U16) = 8853 205188 Monitor IPC:311A (U16) = 6144 209400 KEYDOWN: VK=190, Waiting=0, Repeat=N, Shifts=0 209400 FS Control Sent: Ctrl=65639, Param=0 209400 .. This key is programmed in FSUIPC 'Keys' options 209400 *** EVENT: Cntrl= 65639 (0x00010067), Param= 0 (0x00000000) COM_RADIO_FRACT_INC 209525 Monitor IPC:311A (U16) = 6146 209541 KEYUP: VK=190, Waiting=0 209978 KEYDOWN: VK=190, Waiting=0, Repeat=N, Shifts=0 209978 FS Control Sent: Ctrl=65639, Param=0 209978 .. This key is programmed in FSUIPC 'Keys' options 209978 *** EVENT: Cntrl= 65639 (0x00010067), Param= 0 (0x00000000) COM_RADIO_FRACT_INC 210087 Monitor IPC:311A (U16) = 6149 210118 KEYUP: VK=190, Waiting=0 210648 KEYDOWN: VK=188, Waiting=0, Repeat=N, Shifts=0 210648 FS Control Sent: Ctrl=65638, Param=0 210648 .. This key is programmed in FSUIPC 'Keys' options 210648 *** EVENT: Cntrl= 65638 (0x00010066), Param= 0 (0x00000000) COM_RADIO_FRACT_DEC 210758 KEYUP: VK=188, Waiting=0 210836 Monitor IPC:311A (U16) = 6146 211194 KEYDOWN: VK=188, Waiting=0, Repeat=N, Shifts=0 211194 FS Control Sent: Ctrl=65638, Param=0 211194 .. This key is programmed in FSUIPC 'Keys' options 211194 *** EVENT: Cntrl= 65638 (0x00010066), Param= 0 (0x00000000) COM_RADIO_FRACT_DEC 211210 Monitor IPC:311A (U16) = 6144 211304 KEYUP: VK=188, Waiting=0 213644 KEYDOWN: VK=77, Waiting=0, Repeat=N, Shifts=0 213644 FSUIPC Control Action: Ctrl=1032, Param=0 213644 .. This key is programmed in FSUIPC 'Keys' options 213644 Monitor IPC:034E (U16) = 8855 213784 KEYUP: VK=77, Waiting=0 214158 KEYDOWN: VK=77, Waiting=0, Repeat=N, Shifts=0 214158 FSUIPC Control Action: Ctrl=1032, Param=0 214158 .. This key is programmed in FSUIPC 'Keys' options 214158 Monitor IPC:034E (U16) = 8704 214330 KEYUP: VK=77, Waiting=0 215250 KEYDOWN: VK=78, Waiting=0, Repeat=N, Shifts=0 215250 FSUIPC Control Action: Ctrl=1033, Param=0 215250 .. This key is programmed in FSUIPC 'Keys' options 215250 Monitor IPC:034E (U16) = 8855 215375 KEYUP: VK=78, Waiting=0 215765 KEYDOWN: VK=78, Waiting=0, Repeat=N, Shifts=0 215765 FSUIPC Control Action: Ctrl=1033, Param=0 215765 .. This key is programmed in FSUIPC 'Keys' options 215765 Monitor IPC:034E (U16) = 8853 215874 KEYUP: VK=78, Waiting=0 You can surely see that the FS controls (COM_RADIO ...) only change offset 311A whilst the FSUIPC added ones (not logged because they are implemented inside FSUIPC) change the in-Use offset 034E. I am sure you must be making an error and misreading what you are doing. If not, show me a log like the one above, please. BTW, also check your AIRCRAFT.CFG file. If you've altered that to set no standby frequencies then for sure the normal controls will affect the in-use ones. The relevant section is this (this is the default 737 setting): [Radios] // Radio Type = availiable, standby frequency, has glide slope Audio.1 = 1 Com.1 = 1, 1 Com.2 = 1, 1 Nav.1 = 1, 1, 1 Nav.2 = 1, 1, 0 Adf.1 = 1 Adf.2 = 1 You will see that the two COM and two NAV radios have standby's but not thetwo ADFs. Regards Pete

You posted your support question to the User Contributions subforum. Ive moved it for you to the correct place, the Support Forum, so it can be answered. The problem here is that Lua compares strings as binary objects. Your plane_type will be 24 bytes in length including the zero terminator: "Piper" followed by whatever else was in those 24 offset bytes -- a zero then unknown. The zero terminating the string doesn't terminate the comparison, only the very last zero (or whatever) does. So there's no way your literal string "Piper" matches -- you'd need to compare with a 24-byte string with the same contents, which you don't actually know. The only way to compare such strings properly is to use a string library function to force the unknown string to be the same length: if string.sub(plane_type, 1,5) == "Piper" then ... end The string.sub function delivers a string made up of characters 1 to 5 of the original. The original remains intact so you can proceed with other comparisons. Regards Pete

You really do need to updae that! On the contrary. You did NOT purchase version 4.53, but FSUIPC4. You only ever buy it once! You are expected to keep it up to date if you want it supported. It doesn't cost anything other than a download, and you simply run the Installer. Regards Pete

What made you think updating FSUIPC would change anything? I only asked you to update because I don't support old versions! I can't help unless you tell me what actual controls you are assigning to! Oh dear! You never said you were using offsets not controls! Why not mention such crucial things? You even strongly implied you were using controls by talking about "button assigment" -- even the title says as much! So, instead of telling me what controls you are (NOT) assigning to, please tell me what offsets you are using and what you are doing to them! I cannot possibly help without information and it seems very difficult to get any from you. :sad: Regards Pete

No, only the flat 10 foot wide screen at about 5 feet in front of me, seen through the (glassless) cockpit windows. In fact, because i have severe tunnel vision (from the Retinitis Pigmentosa which stopped my real flying ambitions in the first place) adding more view to the sides wouldn't add anything to the effect for me. It would be useful when taxiing or on visual base legs -- for that sort of side view I use a pair of rocker switches on the yoke (in place of the 737's "flight number reminder gadget") with 4 view angles selected with smooth motion via EZDOC. Not realistic at all, but workable. The hat release returns the normal view, so it's never held long with any risk of confusion. ;-) Regards Pete

You Support query has been moved from the FAQ subforum to the Support Forum, where it can be answered. You didn't buy 4.751, but FSUIPC4. You need to keep it up to date if you want support. The earliest supported version is 4.853. Just download and run the Installer. Do this for every new update. I'm not sure I understand the question. The installer installs into both FSX and P3D automatically, if that's what you are asking. Regards Pete

Ah, okay. I didn't manage to work that out when watching the video. I did have a chance to put my PFC 737NG cockpit on small pistons, the type which only move up and down 2 or 3 inches. It would have needed 6 or 8 working in harmony. But the problem is that my cockpit is in an upstairs room on wooden floorboards. The joists are quite big and very strong, but the cockpit weights nearly 3/4ths of a ton already, and moving it up and down could double that! Additionally the extra height it would have entailed and the fact that my outside view is a 10 foot wide projection screen would have meant a complete re-think of the visuals! I gave up on the idea! ;-) Regards Pete

For button pressing or switch switching you only want them to be "writeable", not read AND write! What is reading them? You still seem very confused! Only programs written to display the switch settings (as lights or indicators, for instance) need to read them, and they can read a different offset as specified. There is no way any button can "read" anything! Buttons have no use for reading and no software to read things. Regards Pete

Interesting video to watch, but shouldn't the motions be based on accelerations? It looks as if it is working on the rotation of the stick/control surfaces instead. Is that right? In other words, once you're in a bank (for example) it seems to keep you banked. Shouldn't that "wash out" slowly (so you don't feekl it) back to horizontal so it's ready for the next acceleration? Regards Pete

You mean the FSUIPC INI file? The user-editable entries are documented in the Advanced Users guide -- a PDF installed in your FSUIPC Documents folder along with all the other goodies, as listed in the Installation and Registration document included in the main download ZIP. Regards Pete

There is a reasonably easy way to do that with existing facilities. The current zero/back toggle is really implemented for the very common need to force the traffic to reset itself after loading new weather -- otherwise it takes a while for the traffic to start using the correct runways. Use a macro to test the button's flag and if set then set one value and if not set the other value. Button flags automatically toggle with each button press and thereby can turn a button into a toggle switch as far as the resulting action is concerned. For this method, check the button programming section of the Advanced User's guide. I'll be glad to help if needed. Also you could do something even more sophisticated with a Lua plug-in instead. The airline, GA and Ships/Ferries density values are individually both readable and writable in FSUIPC4 "UB" (Unsigned Byte) offsets 0250, 0251 and 0252. On the press of a button you could reconfigure any or all three whilst remembering the previous values for restoring next time. Regards Pete

That link is now dead. Version 4.859e is now available via the Download Links subforum, where you will also now find 3.999y which has the same change included for FS9. Regards Pete

No, you'd need to read this information from the WideServer log file in the FS Modules folder. This is how, for example, Projeect Magenta's "pmFileCheck" program does it. Regards Pete

No. Closing errors, or FSX appearing to close completely but still in fact be running with no Windows, are almost always due to some timing differences between the assorted add-ons and their multiple threads. Often it is something using SimConnect keeping that busy whilst the rest of fSX closes down, leaving that thread high and dry. If there is an actual crash you should try to isolate the cause -- the Windows event logs will point to the module in which the crash occurs. Also you could try to close all the external add-ons down before closing FS, or selecting a default aircraft. Hmm. Quite a few DLL's being loaded. The FSUIPC installer appears to have done a good job. I can't see anything wrong. It is trying to load all these DLLs: iFly737NG.dll EJetH.dll E145XH.dll A2A_Service.dll LegacyXHUD.dll FSUIPC4.dll If you've uninstalled any of the related add-ons you should remove their sections from the DLL.XML. A section begins with <Launch.Addon> and ends with </Launch.Addon> If you do edit it, use Notepad or any basic text editor, NOT WordPad or any word processor. Make a backup copy first. The install log for FSUIPC4 looks okay. Pete

Not with FSUIPC. FSX does have a steering control. I don't know whether it works well or not, having never tried it. the FSUIPC tiller uses the FS rudder control as that was always the only way to steer. Pete

What controls are you assigning to? The normal FS controls ONLY change the standby -- FSUIPC adds extra controls which can change the Active. Normal FS controls are COM1 radio fract dec, etc FSUIPC adds COM1 use frac dec, etc. Please update your FSUIPC. That is far too old and cannot be supported. Regards Pete

I don't understand how FSUIPC could possibly be involved in such behaviour so I don't know why they would even refer to FSUIPC. Are you sure it isn't more to do with weather - turbulence or other weather effects like gusts and variance? Check your weather program. If you are using FSUIPC's wind smoothing you can also inhibit its own wind effects using the check boxes on the same tab. If FSUIPC is "corrupted" it won't run. There's a signature check applied to the code which is very thorough. Regards Pete

You could process the log file, "runways.txt". Or refer to the XML file instead. Create a shortcut and add the command line parameter to the command line, same as it's always been done under Windows. Regards Pete

I'm sorry, but I don't see anything in what you said which relates to FSUIPC4. It looks like it is all to do with VSATSIM or IVAO. None of the on-line flying applications even use FSUIPC, and FSUIPC has nothing to do with any internet connection. I think you need to go to support for Squawkbox oe Ivap. Since the problem is common to both it sounds like it could be a problem with your internet setup for Win8. For details of the actual crash, pointing to the responsible module, check the Windows event logs. Regards Pete

The FSUIPC log you supplied shows it was working okay, though it would be more helpful if you closed FSX before getting the logs as they show more in the final summary. Is that perhaps a log left over from some previous session? It is dated and timed very recently: 15381 System time = 28/11/2012 18:28:36, Simulator time = 17:24:09 (07:24Z) Are you perhaps looking in the wrong place? The AddOns menu entry is normally the right-most (last) one in the menu strip. The SimConnect log, however, shows that it isn't being loaded. I assume this is from later on? You appear to have no DLLs loading at all, only two EXEs: 0.13582 Exe Launched: Path="C:\Program Files (x86)\EZCA\EZCA.exe" CommandLine="" Version="1.1.5.0" 0.13777 Exe Launched: Path="C:\Program Files (x86)\Saitek\DirectOutput\SaiFlightSimX.exe" CommandLine="-run" Version="6.2.2.4" I suspect therefore that you have deleted or corrupted the DLL.XML file which should be in the same folder as your FSX.CFG file (I could tell you exactly where if you showed me the FSUIPC4 Install log).. If you have no other DLLs to be run all you probably need to do is re-run the FSUIPC4 installer. That will create another DLL.XML file for you. It may even manage to repair a damaged one. But if that does not work, or you think you might have other DLLs which should also be loaded, please find the DLL.XML file and past it in a message here. I'll try to find the corruption for you. Regards Pete

Probably best to append a note about this request to the same thread in the sub-forum I've had a quick look at the script. There is actually an error, of no real consequence, but which I think need correcting first: In two places (lines 11 and 36) this appears: setfi(ipc.readSW(0x332E))[/CODE] This is calling function "setfi" which is defined as: [CODE]function setfi(off, val)[/CODE] so the parameter, the value read from offset 332E is being supplied to that function as "offset" (!), whilst the value itself is not supplied at all and remains undefined. The reason it is inconsequential is that neither "offset" nor "Val" are even actually referenced in the function "setfi"! Instead, it actually reads offset 332E again, in line 18. There is another error which may have consequences but probably normally doesn't. The variable "timefi2 is referenced before being defined for the first time, which can cause a Lua error. So the corrected script should be: [CODE]-- v.2 ATR Idle Gate timefi = 0 function onground(off,val) if ipc.readUW(0x0366)==1 then ipc.writeLvar("L:ATRIdleGate", 0) ipc.writeUB(0x310A,0) ipc.writeSW(0x088C, ipc.readSW(0x332E)) ipc.writeSW(0x0924, ipc.readSW(0x332E)) else ipc.writeLvar("L:ATRIdleGate", 1) setfi() end end function setfi() if ipc.readUW(0x0366)==0 then if ipc.readLvar("L:ATRPLLeft_notch") == 0 then if ipc.readSW(0x332E) <= 3600 then if ipc.readUB(0x310A)==0 or ipc.elapsedtime()-timefi>4000 then ipc.writeUB(0x310A, 8) ipc.writeSW(0x088C, 3600) ipc.writeSW(0x0924, 3600) timefi = ipc.elapsedtime() --ipc.log("TimeSet"..timefi) ---------------------------------------------------------------------------------- end elseif ipc.readUB(0x310A)==8 then ipc.writeUB(0x310A, 0) end else ipc.writeUB(0x310A, 0) end end end function checktime(time) if ipc.readUW(0x0366)==0 and ipc.readSW(0x332E) <= 3600 then setfi() --ipc.log("TimeKick") ---------------------------------------------------------------------------------------------------------------------------------------------------- end end event.offset(0x0366,"UW","onground") event.timer(5000,"checktime") event.offset(0x332E, "SW", "setfi")[/CODE] Now on to your question. Offset 332E actually provides the calibrated input value for the generic all-engine throttle. You need this to reference Throttle 1 offset 3330 and throttle 2 offset 3332. Also note in the script references to 088C == actual throttle 1 control 0924 == actual throttle 2 control 310A == throttle disconnect control: value 8 = generic throttle. There are different values for thr1, thr2 and both. So it gets a little bit more complicated. You need to process throttle 1 input on 3330 and output on 088C with bit 6 (value 64) in 310A, and also, simultaneously, throttle 2 input on 3332 and output on 0924 with bit 7(value 128) in 310A. I could sort this out for you except that I don't understand what the ATR Idle Gate is nor how two throttles would affect what appears to be only one "gate" or whatever. i.e. the functions of [b]L:ATRIdleGate[/b] and [b]L:ATRPLLeft_notch[/b]. How would the operation of the throttles separately affect these when they only appear to be single? Should there be a [b]L:ATRPLRight_notch[/b]? And is there only one [b]L:ATRIdleGate[/b]? If the answer to this is "it doesn't matter" then the following modified code might work: [CODE]-- v.2 ATR Idle Gate modified tentatively by Pete for twin throttle inputs ... ? timefi1 = 0 timefi2 = 0 function onground(off,val) if ipc.readUW(0x0366)==1 then ipc.writeLvar("L:ATRIdleGate", 0) ipc.clearbitsUB(0x310A,192) ipc.writeSW(0x088C, ipc.readSW(0x3330)) ipc.writeSW(0x0924, ipc.readSW(0x3332)) else ipc.writeLvar("L:ATRIdleGate", 1) setfi() end end function setfi() if ipc.readUW(0x0366)==0 then if ipc.readLvar("L:ATRPLLeft_notch") == 0 then inhibits = ipc.readUB(0x310A) if ipc.readSW(0x3330) <= 3600 then if logic.And(inhibits,64) == 0 or ipc.elapsedtime()-timefi1>4000 then ipc.setbitsUB(0x310A, 64) ipc.writeSW(0x088C, 3600) timefi1 = ipc.elapsedtime() end else ipc.clearbitsUB(0x310A, 64) end if ipc.readSW(0x3332) <= 3600 then if logic.And(inhibits,128) == 0 or ipc.elapsedtime()-timefi2>4000 then ipc.setbitsUB(0x310A, 128) ipc.writeSW(0x0924, 3600) timefi2 = ipc.elapsedtime() end else ipc.clearbitsUB(0x310A, 128) end else ipc.clearbitsUB(0x310A, 192) end end end function checktime(time) if ipc.readUW(0x0366)==0 and (ipc.readSW(0x3330) <= 3600 or ipc.readSW(0x3332) <= 3600) then setfi() end end event.offset(0x0366,"UW","onground") event.timer(5000,"checktime") event.offset(0x3330, "SW", "setfi") event.offset(0x3332, "SW", "setfi") [/CODE] Sorry, but i can't test this or say that it works. Maybe the original contributor will see this, in its correct thread, and contribute. Regards Pete