Pete Dowson

I suppose it would be possible with a Lua plug-in. There's a complete range of Internet and Networking facilities there if you include the external package parts you might need. I'm afraid I wouldn't be much use to help you as I've never dabbled in internet program access at all. Check out the Lua websites. Regards Pete

Sorry, but I don't know the iFly aircraft nor what data iFly2FSUIPC supplies. I think you really have no choice but to clarify this with those folks. Tell them what you want to display and what offset you are using and ask them to confirm it is the same value, or not, and if so whether it needs conversions. Regards Pete

Sorry, I really don't know what you are trying to do. You don't say what you are doing or want to do. FSUIPC only provides values from FS. Add-on aircraft often do their own thing. Maybe that "iFly2FSUIPC" program gets data from the iFly aircraft and puts it into FSUIPC offsets for you to read, but to work that out you need the documentation which comes with iFly2FSUIPC. I don't know anything at all about either iFly or iFly2FSUIPC. Are you writing your own interface program? What language do you program in? The FSUIPC SDK have packages and examples for several. BTW you posted exactly the same message twice -- I've deleted the other one. Pete

2EFS is not a hexadecimal number, that's why! Hex numbers consist of digits 0-9 and A-F. It should be 2EF8. Pete

FSUIPC has nothing to do with downloading and setting FSX real weather. The most likely thing is that the FSX weather server has closed down. Ask over in the AVSIM FSX forum -- there may still be a few folks trying to use Microsoft's weather. There's not been any changes whatsoever in the weather facilities in FSUIPC4 for FSX. They are minimal in any case. FSUIPC4 is unable to do much at all with FSX weather -- it can help weather programs set and read the weather, but it can do virtually nothing with FSX's own weather downloads. You are assuming wrongly it is anything to do with FSUIPC. It seems quite likely that now, with withdrawal of FSX support for Micxrosoft after 7 years since its release, that they have also withdrawn the weather download service. I don't know because I've never used it, the results of the better weather programs being so much better! Oh, similar outages by Microsoft have been reported from time to time. See for example http://www.flightsim.com/vbfs/showthread.php?262601-Microsoft-Weather I really wouldn't be surprised if it disappeared permanently, but maybe this current outage is another temporary one. Ask around. Regards Pete

You've got simething else going on then. There's absolutely no way anything to do with FSUIPC will be deleting any files whatsoever. You need to look for another culprit! I'd go to the Prepar3D support forum about that. You also need to get the CTD details from the Windows event viewer. The only sort of program i know of which will sometimes appear to delete an EXE file is a virus checker -- but those tend to move them to an "prison" folder where they are prevented from doing harm, and would normally present you with a message telling you what they've done. Did you not look for the FSUIPC4.LOG file first? If that is not produced then FSUIPC4 is not even getting run. I assume you must mean FSUIPC4.DLL, because FSUIPC.DLL is is for FS9 and before. Without more information I can't really help. It could be due to a bad SimConnect set up, or it could be something else which is doing it simply because the timing and memory layout will be a little different when FSUIPC4 is being loaded. There have been no other reports, and FSUIPC4 has worked successfuly now for alll releases of P3D. It is even working well with the upcomng version 2. Not really, not without details of the crash and sight of the run-time LOG file. Have you tried installing the latest version of FSUIPC, 4.921, over the FSUIPC4.DLL in the Modules folder (see the Download Links subforum)? Also provide the details to Lockheed Martin by reporting it in their Support Forum --- I'm sure they'd be interested in a bug which somehow miraculously deletes their EXE file! That would be sure to catch their attention! No. If there's an FSUIPC4.LOG that would certainly be relevant. But the install log is only useful for installation problems. Regards Pete

Hmm. Very strange. I've no idea how they've programmed the graphics -- normally gauges receive their data for display directly from the Sim, so if the Sim is throttling up so do the depicted levers. I don't know of any other way they could do it unless they actually read the hardware input directly. If this problem occurs with normal joystick-interface connected throttles, but not with keyboard throttle (the 3 and 9 keys on the numpad), then maybe using Throtle INC and throttle DEC would work. To drive those with an axis you'd need to use the right-hand side axis assignment facilities to program INCrements in one direction and DECrements in the other, with repeats allowed. Not nice though. Pete

That makes no sense. On the one hand you say "... setting axis in FSUIPC .." and on the other you " don't see the axis in the controls/joystic axis menu". How can you "set" an axis (whatever you really mean by that) if it isn't "seen"?? I think you need to be more specific! Seems you forgot something then. When trying to assign PFC axes in FSUIPC you need to disable them in the PFC driver. i.e. uncheck the axes you are assigning in FSUIPC. Since I don't know what you did (as what you say is self-conflicting as I pointed out), I can't. Tell me more specifically what you did, in the actual terms used in the displays and documentation. You seem to use words which don't relate to either FSUIPC or PFC. It probably just means that, like PMDG aircraft, it is reading (intercepting) the standard FS controls. That's why I suggested assigning to them. It means you cannot use the same axes for reverse thrust, because that demands the ThrottlesN_Set controls, not the standard FS ones. It probably also means you can't calibrate in FSUIPC because that would make the values sent by FSUIPC to FS differ from those the aircraft code is reading. Hence my suggestions as to what to try. If you did calibrate you'd probably need to set "UseAxisControlsForNRZ=Yes" in the FSUIPC INI file [Axes] section(s) and check NRZ (No Reverse Zone) in the calibrations section before doing the calibration. Pete

Yes, just look at the example. Documentation for the functions there is found in the Lua library PDF in the Lua package in your FSUIPC Documents folder. Pete

If you assign in FSUIPC to those controls I mentioned, and don't calibrate in FSUIPC, then there is really no way any add-on can tell the difference between that and FS assignment. The results are identical. Pete

I don't know what the problem is, but see if assigning the throttles in FSUIPC to the normal FS "axis throttleN set" controls, with or without FSUIPC calibration, helps, instead of allowing the PFC DLL to do the control directly. It may be that it just doesn't like other throttle control methods. Pete

I've had a look at this, and I can really see no way to add such a facility without jeopardising the stability of FSUIPC. The code for handling button changes is now very old and has grown to encompass virtual buttons, POVs, Goflight and VRI devices, and many of these things also on WideFS clients. Handling it all correctly without making an error is really not something I want to risk at this stage. So, the only answer is to use a Lua plug-in. I thin this would be more efficient and more flexible also, in that not only could you have it running automatically each time you loaded a different aircraft, you could also have a button or keypress to run it so you could synchronize buttons and aircraft switches at any time. To start you off I've made a template / example. You'd need to put the Product and Vendor names in (use HidScanner to find those -- see the Lua thread in Download Links subforum) and then add the programming for the actions you need in the case of each Switch being on or off. Here I've done it for a GoFlight 8-toggle switch panel, the GF-T8: Vendor = "GoFlight" Product = "GF-T8" Device = 0 -- Multiple devices of the same name need increasing Device numbers Switches = 8 -- Number of switches to check -- Use separate Lua plug-ins for separate devices! dev, rd, wrf, wr, init = com.openhid(Vendor, Product, Device, Report) if dev == 0 then ipc.log("Could not open HID") ipc.exit() end -- read any data available from the device (only need most recent report) data, n = com.readlast(dev, rd) if n ~= 0 then -- Data was returned, so get the status of all the possible "buttons" we are using -- one value of 32 bits Buttons = com.gethidbuttons(dev, data) buttonbit = 1 j = 0 while j < Switches do if logic.And(Buttons, buttonbit) ~= 0 then -- HERE DO WHATEVER ACTION IS NEEDED WHEN SWITCH j IS ON -- E.G ipc.control, or ipc.keypress, or ipc.runlua, or ipc.macro, etc. else -- HERE DO WHATEVER ACTION IS NEEDED WHEN SWITCH j IS OFF -- E.G ipc.control, or ipc.keypress, or ipc.runlua, or ipc.macro, etc. end j = j+1 buttonbit = 2 * buttonbit end end com.close(dev) Save your result as a lua file in the FS Modules folder (eg scanT8.lua for this one), and either assign a keypress or button to "Lua scanT8" (or whatever), or, for automatic action, add [Auto] section(s) to the INI file containing 1=Lua scanT8 Hope this is clear? Let me know how you get on -- it might be worth adding this into one of the SunForum's as a helpful permanent hint. Regards Pete

You can have a Lua plug-in to read the states of switches initially, using the HID facilities built into the CMO library. At present this would be the only way. The normal joystick interface is designed for buttons, really, not switches, so it is assumed that they are normally "off" (un-pressed). There are some examples in the Lua examples ZIP of reading HID devices and interpreting the data for button states and so on -- for example Rotaries.lua and HidDemo.lua. Both offer much more than you'd need for this, though. I'll make a note, though, and may consider some way to build in initial switch state actions. The problem would be to try to do it in a user-friendly manner without being over-restrictive. Maybe it will just have to be an INI parameter to list those buttons (actually switches) which should be treated as if "changed" initially. There's only one initial button parameter, with one button press. But of course you can have multiple actions resulting from that button. And that button need not be a real one. There's really no need for there to be more than one. Only on first load, when first "ready to fly", exactly as documented. I think it is described clearly enough, no? Regards Pete

That trim wheel sounds like a really bad device. Is it Saitek as well? If I were you I'd try and get assisyance from them. Seems it is not fit for purpose. Pete

Is this on a new PC, or after a complete Windows re-install? If not, how did you remove the previous install of FSX? Most methods leave the SimConnect side-by-side system is an unrepairable mess, and if so then this would explain why it won't work. When I tried this on a Win7 system the only way out was to reinstall Windows first. With WinXP it was possible to get it sorted by Registry editing, but that was also a long and compicated job! Why are you using the FSUIPC4 Loader? Did you not read the Installtion instructions? Did FSX ask you for permission to load FSUIPC4? If so what did you answer? Check the [Trusted] section of the FSX.CFG file for FSUIPC4 entries and if there are any, delete them. Is there an FSUIPC4.LOG and/or FSUIPC4.INI file in the FSX Modules folder? If there's a LOG show it to me. Try this: 1. Delete the DLL.XML file -- you know where it is, as you posted it (in an odd format with no new lines) above. *** 2. Delete the FSUIPC Loder DLL from the FSXModules folder 3. Re-run the FSUIPC4 installer. If this doesn't help, enable Simconnect logging as described in the FAQ sunbforum thread, and try again. Show me the SimConnect log so produced. Pete *** This is what the DLL.XML file you posted should look like. I suspect that whatever editor you used to cut and paste it corrupted the format. Be careful with that! <?xml version="1.0" encoding="WINDOWS-1252"?> <SimBase.Document version="1,0" Type="Launch"> <Descr>Launch</Descr> <Filename>dll.xml</Filename> <Disabled>False</Disabled> <Launch.ManualLoad>False</Launch.ManualLoad> <Launch.Addon> <Name>Object Placement Tool</Name> <Disabled>True</Disabled> <ManualLoad>False</ManualLoad> <Path>..\Microsoft Flight Simulator X SDK\SDK\Mission Creation Kit\object_placement.dll</Path> </Launch.Addon> <Launch.Addon> <Name>Traffic Toolbox</Name> <Disabled>True</Disabled> <ManualLoad>False</ManualLoad> <Path>..\Microsoft Flight Simulator X SDK\SDK\Environment Kit\Traffic Toolbox SDK\traffictoolbox.dll</Path> </Launch.Addon> <Launch.Addon> <Name>Visual Effects Tool</Name> <Disabled>True</Disabled> <ManualLoad>False</ManualLoad> <Path>..\Microsoft Flight Simulator X SDK\SDK\Environment Kit\Special Effects SDK\visualfxtool.dll</Path> </Launch.Addon> <Launch.Addon> <Name>FSUIPC 4</Name> <Disabled>False</Disabled> <Path>Modules\FSUIPC4_Loader.dll</Path> </Launch.Addon> </SimBase.Document>

More information is needed really -- you say " I have tried the options in fsuipc", but don't say what they are or what you mean -- but if you've assigned the trim wheel as an axis in FSUIPC, but haven't calibrated it in FSUIPC, you can reverse the action by adding the multiplier -1 to the assignment line in the INI file [Axes] section. This is as described in the section "Additional parameters to scale input axis values" in the Axis chapter of the Advanced User's guide to FSUIPC. Just add ",*-1". If you are calibrating the trim axis in FSUIPC then it would be easier to simply check the "REV" checkbox for that calibration. Do this before doing the actual calibration. Pete

Well You certainly could do that, but I think it would be much more efficient if you simply enable ALL your scenery areas, run MakeRunways just once to get a complete database, then revert to your normal choices. You don't need to run FS at all -- MakeRunways simply goes by the enabled layers in the current SCENERY.CFG file. Then, like most folks, you'd only ever need to rerun it if you installed updated or new scenery areas. Regards Pete

You can assign axes in FSX and still calibrate in FSUIPC. In fact for most users that is the normal way. The advantages of assigning in FSUIPC are really for cockpit builders with specialised equipment and those with multiple controls who like to use different ones for different aircraft types (eg Arbus vs Boeing vs. Turboprop vs Helicopter, etc). I'd still like to know why it plays up in FSUIPC, because the values displayed in the Axis Assignments tab are the actual values supplied by Windows and FSUIPC is using the same methods as FSX to read them! Pete

What you call "microsoft flight sim x calibration settings" is actually just an in-game way of getting into the Windows calibration facilities. They used to be more directly available as the "Game Controllers" applet in the Windows control Panel, but I've no idea how you'd get to them nowadays in Windows 7. Probably through the Device Manager in Systems applet. The way in through FSX is fine. You'll just need to (temporarily) reenable FSX controller, otherwise the calibration button is disabled. Pete

Sorry if you feel i wasn't up to your mark. I am a technician and I tell it as it is. I don't see any point in beating around the bush. And I would naturally expect folks using computers to fly what is quite a complete simulation, specially using Networked addons, to have sufficient intelligence to make use of resources provided to them. Sorry if you think this is unreasonable. :-( Pete

Okay. That's progress of a sort. It certainly means the broadcasting wasn't working despite both WorkGroup's having the same name. I am wondering if this is something to do with the weird default way Win7 has of trying to make you use the "home group" networking, which is supposed to be simpler! My network is a mix of WinXP PCs and Win7 ones so I can't use that and reverted to "normal" networking. Basically what you have happening now is that Windows is blocking the Client attempt to contact the Server. Whether this is happening on the Client or the Server is really impossible to tell. It will be down to one or more of three things: 1. There's a firewall on the Client blocking the Client's outwards attempt 2. There's a firewall on the Server blocking the inward connection from the Client. 3. The port required by Wideclient (8002 by default) is already in use on the Server. More about the 3rd one: the Broadcasting uses port 9002 and the normal interaction uses 8002. Maybe 9002 was blocked too. Both of these can be changed, but you'd need to change them in the WideClient INI file and the FSUIPC4 INI file too. However, I'd guess that the real problem is that your firewall(s) are blocking the connection. Try disabling the firewall at both ends. If it then connects you will either need to leave the firewalls down, or find out how to allow WideClient.EXE and FSX.EXE through. I'm afraid I would be lost in the latter case as I always disable firewalls between my PCs. I hate systems trying to stop me using my computers as I wish, and Windows does far too much of that nonsense. If you have a decent Internet Router the firewall there should be good to protect you. At least that's my opinion. Regards Pete

That can either mean that you are turning it so fast that many of the controls which might be sent are being missed, or that the trim device you have has insufficient resolution to provide enough increments between extremes. You might need to calibrate the axis properly in Windows, it might not have the full range needed. You could also try reducing the Delta value on the axis assignment tab for this axis, so that smaller changes in the input value are handled. Pete

And yet again you post many copies of the same log. Why? Why not delete the unwanted rubbish? It makes your messages much harder to read and reply to. You say you read the guide, but I think you must have missed the essential part, the part I mentioned -- the part with the red banner saying IT IS IMPORTANT FOR ALL USERS TO READ AT LEAST PART OF THIS! You mention the firewall, but not the WorkGroup, which is "VERY IMPORTANT #2". Don't forget to scroll down a little, after checking all that, to the part that says "... However, if you find the connection is still not happening ...". Maybe this might apply to you, don't you think? I can see from the Logs that you've not yet bothered to follow this at all. I did write all this stuff down so folks could help themselves pass all the obstacles that Windows throws at them! Pete

Re-installing the same version changes nothing. Installing an updated version only changes the DLL itself and maybe updates the documentation. If you want to remove all your options and settings and start again, just delete the configuration file, FSUIPC.INI or FSUIPC4.INI (depending which Flight Sim you are using) before loading flight sim. A new one will be generated with just default settings. And, no, reinstalling or removing your settings will not affect the application interface at all. Pete

Reinstalling FSUIPC can never solve anything as you are simply replacing the DLL with the exact same DLL. And does the same thing happen in the Windows "games controller"? (To check that the easiest way is to temporariy re-enable controllers in FSX, via Options-Controls, then select Calibration -Calibrate - Properties - Test. You should probably calibrate there too (Settings - Calibrate or similar). Maybe the registry data for the device is screwed up and calibrating in Windows like that should sort it out if so. Otherwise it is looking seriously like a motherboard or driver issue. I really don't know what to advise. Pete