Pete Dowson

Well, the reason it doesn't work is clear enough: 78828 LUA.0: Could not open HID That error would have been logged even without you enabling the trace/debug option. You need to remember to always look at the log if things don't do what you expect. So, the device identification is wrong. Let's look at that: Vendor = "0x16C0" Product = "0x27CB" Now there's the problem. There are two ways of identifying the device -- by names, as in the original examples: Vendor = "GoFlight" Product = "RP48" or by numbers. You seem to have chosen neither. Why didn't you just do as the example showed and use names? 0x16C0 and 0x27CB are numbers, but putting them in quotes "..." makes them strings and so names. But those certainly won't really be the names. Either provide the numbers or the names, otherwise the device will not be identified. Pete

You have a bad FSX installation with a corrupted SimConnect side-by-side entry. I suggest you first try updating to FSX SP2 or Acceleration, as this should fix that and will also fix a lot of other bugs in FSX. Regards Pete

The easiest way to fix that is to simply swap over the controls in the Lua file, so that trim dec is trim inc and vice versa. Those are the two numbers in the ipc.control functions.. Pete

You might find more Goflight users who can help over in the GoFlight support forums. I provide a lot of GoFlight support in FSUIPC, but I am not a Goflight user and would certainly not be able to advise on configuring it for different aircraft. If you install FSUIPC you can read through the documentation and make up your own mind. You might also find examples for some of your aircraft in the User Contributions subforum. I can answer specific questions about FSUIPC, if they aren't covered in the documentation, but not about GFConfig nor specific aircraft. Regards Pete

But in the previous thread you were talking about saving to something you called "trimwheel.ini". Don't you see? You were completely confused then through not reading correctly, so I naturally assume the same here! Can you blame me? There you go again. Assigning axes and calibrating controls are two different things on separate Tabs and described in separate chapters in the manual! Please please read the words, don't substitute your own incorrect words, and refer to the manual when in doubt! You are NOT doing any calibration whatsoever for this appl;ication, and calibration has never been mentioned in anything I've said about it. Not specifically this one use of assigning an axis, but there's a picture of the assignments tab and descriptions of what to do to assign things. You won't have found it because you are insisting on looking in the wrong place and ignoring what i'm saying! Of course there's no specific instructions on doing the infinite numbers of different things you can do with Lua plug-ins and the like. FSUIPC offers a set of tools to do almost anything you want to do. The instructions are for using the tools themselves, not applying them. There are examples to help with that, and the help I provide here -- which you continue to misread or ignore! Pete

Er ... that thread only has contributions by you and I. Why on Earth post again like this trying to pretend it was someone else and you had difficulties in finding your own thread entries of only a short time ago? What game is this? I know I asked you to move to the Support Forum, by why such subterfuge? I'm not going to explain it all again. All the information and instructions you need are there. And despite my correcting you in the other thread, you still persist in copying the stupid mistake you made and have simply completely ignored what I said. It is not "1=trimwheel" but 1=Lua trimwheel!!! And it is not "ini files in FSUIPC" but just THE FSUIPC INI file. There is only the one!!! It contains all your FSUIPC settings. Why don't you read what is actually written? You are perpetuating the same silly errors agasin and again by simply not bothering to read properly. What on Earth have "calibration settings" got to do with it? As I explained there and in other places, you assign the Axis to LuaValue trimwheel. You have evertything 100% wrong. You just aren't reading what is written! :sad: It is extremely frustrating to have to explain the same things over and over when you just can't be bothered to read the replies correctly! Don't you see? Please understand that and READ THINGS MORE CAREFULLY! It would also help to actually read some of the documentation supplied with the program. That's what it is for, to explain things. There are even pictures in some of the documents! Pete

II don't know. I haven't got 8.1. The logging I suggested, which turned out to be nnecessary because my "guess" turned out correct, resulted in the fix! ;-) Pete

Try using the log/debug lua facilities to see what is going on -- see the Logging tab. Even if the timing is alll wrong, if you have the correct device and vendor details you must be getting a virtual button indication in the Buttons & Switches tab. Have you checked the FSUIPC log to see if you are getting a Lua error? Pete

Why not just delete the extra rubbish rather than leaving so many copies to scroll through? :-( As I said earlier, a connection has two ends -- there's a Server too, with a Log file, and I told you where to find it. So why not do so and paste that as well? But briefly it looks like the server broadcasts aren't getting though, assuming the server is actually enabled (which is still a question without the essential log). Did you read some of the WideFS user guide at all, especially the bit with a red note asking everyone to make sure they read at least that part? To do with configuring the network? Pete

Yes, it would be easy in Lua. You'll need to look up the location of the 4 COM frequesncies in the Offsets document. They are all 16-bit words, so you read and write them using these Lua functions (UW = Unsigned Word) ipc.readUW ipc.writeUW So, to swap the frequencies just read all 4 into variables (using obvips but short names like com1u, com1s, com2u and com2s should be clear enough for those), then write them back the other way. There are exmples of Lua plug-ins in the files provided, but most are more complex than this, so don't be intimidated. Yours with be a straightforward set of 4 reads then 4 writes. If you do get stuck, ask questions. Regards Pete

This is a problem in SimConnect which affects some folks and, inexplicable, most not at all. Please refer to the thread in the FAQ subforum entitled "FSX fails to run after FSUIPC4 first installed". where there are several suggestions. Also make sure you are using the latest -- FSUIPC 4.92, or even update that with the 4.921 download which will help if you are using Windows 8.1. Pete

I assume you mean "WideClient" on the client PC? Why are you running "as admin"? It will say it is waiting for a connection until you have started FS on the FS PC and it is ready to fly, assuming you have registered and enabled WideServer in that PC. All Network connections have two ends. You are only looking at one end. I don't want to see any "notepad thingies". The relevant information is in the WideClient.log file on the Client and the WideServer.log file on the Server -- the first is in the same folder as WideClient.exe and the second is in the FS Modules folder. If you can't see them it is because you have Explorer set to hide filetypes from you. Please see the FSUIPC User Guide or Installation Guide for instructions on how to turn that damn silly option off. Don't try to attach files here, just cut and paste the text. BTW, rather than entitle your thread "Help Please" it would be more sensible to actually state the problem in the title. Then others will likely jump in and help too. This is especially true during the frequent and sometimes extended periods whilst I'm away. I do look at all threads here, but others will only look at those which might mean something to them. Okay? Pete

You could write a Lua plug-in which reads both COM1 and COM2 values and swaps them over. You'd then assign this to a button or keypress. Are you wanting 4 frequencies all preset -- COM1 use and standby, and COM2 use and standby? If so you'd need to swap both frequencies each time. Pete

Mouse macros can only work with gauges written in a very very specific way -- using the MS C/C++ gauges SDK very strictly. There's no way for FSUIPC to locate the right point in the gauge code to call otherwise. The number of gauges written this way is declining rapidly these days. And very very few of MS's own gauges are written that way either! But I'm not saying that you definitely won't be able to program them in FSUIPC. And you most certainly don't want to mess with the XML, if they are written in XML. What I actually said, if you read it again, is that you might be able to program them using Local Panel Variables (L:Vars). FSUIPC has facilities for writing to L:Vars, you just need to find the names of the ones you want and the values to set them to. FSUIPC offers logging of L:Vars to make this easier. Please look them up in the documentation. If neither Mouse Macros nor L:Vars are available, then, unless the author of the gauge has kindly provided a way of assigning keypresses to it, you've really got no other resort except maybe using somethnig like Key2Mouse to convert keypresses to mouse movements and clicks. Pete

Hmm. There's a sort of logical problem with that. You will still have the Ctrl and M key pressed when FSUIPC tries to send the others. Not sure what will come out of that.. Enable button and key logging in the FSUIPC Logging tab and see what actually gets done. Maybe it might work better if you programmed the macro to operate on key release not key press? Pete

No! Please don't! 4.92a was an interim version to test a fix. The correct one is 4.921 as shown in the Download Links subforum! BTW I have no website. The Download Links subforum is my prime way of keeping up to date with interim updates. The Schiratti site is Mr. Schiratti's, not mine, and I don't control it. Pete

Different add-ons running simultaneously in or with FS might be using different versions of the SimConnect interface, though of course it all connects to the same code inside FSX/P3D in the end. Only the functions listed and supported by the SimConnect.DLL interface are a little different. If you mean which of the possible SimConnect interfaces is being used by FSUIPC, the only way at present would be from the message like Trying to use SimConnect Acc/SP2 Oct07 in the Log. If you simply mean the version built into FS, which will obviously depend on the FSX version, then that is in the other message: Running in "Microsoft Flight Simulator X", Version: 10.0.61637.0 (SimConnect: 10.0.61259.0) but more easily probably from the line in the INI file, [General] section, such as: SimConnectUsed=10.0.61259.0 Note that this version number is the version actually of the SimConnect in the FSX/P3D, so would be RTM for the RTM FSX, SP1 for the SP1 FSX and SP2 for the SP2/ACC FSX, irrespective of the actual SimConnect.DLL interface being called and in which the functions avaialble differ somewhat. (For P3D 1.4 it would be 1.4.0.0. But it was also possible to use the ESP version of the DLL with P3D). I'd be interested to know what use this information could possibly be in a Lua plug-in, assuming that you are actually talking about an FSUIPC plug-in. Care to share? If all you really want to know is whether it is FSX or P3D, just read that in offset 3308. Pete

Well, if you must, there are separate ZIPs for the documentation only in the Download Links subforum. I'd rather you just kept your installation up to date. Even if there are bug fixes? If you are out of date don't ask for support. Update before you do, please. Of course! The installer only replaces the old DLL and the out of date documentation and example files in the FSUIPC Documents folder. Pete

This just means that those click spots are mnot programmed in a way which can be "mouse macro'd". I'm surprise you've not met more before. Unless they provide key press assignments for their switches, the only other way may be via local panel variables ("L:Vars"). Most XML-based gauges use these. Pete

ATT? Do you mean ALT? I've never had a Radio Stack here. My code should recognise it, thanks to help from users who have it, but it only handles these codes from that device (the numbers after the // are the joystick/button number assigned, which you should see). "TRNVFR", // 274,0 "TRNx1200", // 274,1 "TRNIDEN", // 274,2 "TRNON", // 274,3 "TRNSTBY", // 274,4 "APLMST", // 274,5 "APLHDG", // 274,6 "APLNAV", // 274,7 "APLLOC", // 274,8 "APLBCRS", // 274,9 "APLALT", // 274,10 "APLTHR", // 274,11 "APLFD", // 274,12 Don't you see any of those button numbers appearing in the Buttons & Switches tab when you operate those buttons? You should do. What parts do you see missing? Pete

You don't say what assignments you are making in FSUIPC. All you are shoing is a trace of VRI commands and replies. Are you using FSUIPC just to change the action for some of the commands? Have you tried assignment to whatever button number appears when you press the ALT hold button? Pete

Yes, there is a very important reason. All button, switches and Keypress assignments can be global or specific. The specific assignments override the global ones where they are to the same key or switch, but both sets are otherwise applicable. This is very useful because many many switch assignments will be common to a lot of aircraft and simulator functions irrespective of aircraft or profile. This cannot be done with axis assignments and calibrations because, unlike buttons, switches and keys (which need pressing or switching), axes are active all of the time. You wouldn't want the base assignments to be interfering with the specific ones. This difference is documented. Regards Pete

You'll need to reenter your registration details. Pete

Refer to the History document installed in the FSUIPC Documents subfolder. I cannot support old versions. Regards Pete

There's no "payware" version as opposed to another version. They are one and the same. EZDOK does not use FSUIPC. You need EZDOK support. Looks like FSX crashed, not FSUIPC. Ezdok doesn't use FSUIPC in any case. If the FSUIPC menu option disappears from the FSX menu then SimConnect has crashed or has stopped responding. That would be why other Simconnect applications, like EZDOK, also had problems. Something on your PC is causing it -- judging by the G3D.DLL crashes being "saved" by FSUIPC I suspect there are other crashes caused by overloading or corrupted scenery or textures. Sorry, I cannot support old versions of FSUIPC. Before asking for help ALWAYS be sure you are using a current version. Regards Pete