Pete Dowson

"This" G3D.DLL crash? There isn't ONE G3D.DLL crash, but very many. They are almost all down to scenery problems. the only one i've ever had dealings with was one very specific one which was actually avoidable by a patch in FSX. I've never got involved in such things for P3D because P3D is under active development, unlike FSX. You need to report crashes to Lockheed-Martin. FSUIPC saves any settings changes immediately you exit the FSUIPC menu. FSX and P3D only save settings upon a successful close of the program, so they may well lose settings if you get a crash first. FSUIPC will never change any of your assignments. If you are seeing what you think is that in FSUIPC it is probably that you are using different assignments for different aircraft, or even different variants of the same aircraft. Check your FSUIPC4.INI file, see what you've done. Pete

The are FSX SimConnect.msi files which can be used to install usable modules. With P3D you shouldn't need to -- it may be a re-install job. Best to show me your log file first. In fact if you can find the FSUIPC4 Install log as well as the FSUIPC4 log file, both in the Modules folder, show me both -- paste them into a message here. You can use the <> button above the edit area to quote them as a text file. Pryr

No, the weather reading cannot be responsible for any delays, and that's a very regular action in any case, up to frame rate repeating, same as most of the other data obtained through SimConnect.. From what you say I really don't think it is FSUIPC giving you the problem. There's nothing at such intervals -- the only possibility was the autosave. Check the FSUIPC4 log, a text file in the Modules folder. Maybe the SimConnect installation is failing and the delay is caused by a regular attempt to reconnect. The log will show such attempts. Otherwise I can only suggest you ask for advice in the P3D forum over on AVSIM, or at L-M. Pete

Writing a Lua program to deal with sockets is likely to be more complex than the other method. All I can do really is point you to the socket examples supplied. Why did you get this tiller if you weren't going to use ProSim? Can't the supplier help you interface to FS without ProSim? Seems odd that they make hardware suited to only one system software. Pete

Did you enable FSUIPC's autosave option, to save flights at 3 minute intervals, or similar? It is possible for that to cause a stutter if there's a lot to save, as with some add-on aircraft, though for all normal use it shouldn't be noticeable at all. I have mine set to 3 minutes and never notice the tiniest stutter, but I know folks using PMDG aircraft, especially, have this problem as the PMDG aircraft flight saving stops everything whilst it collects all the subsystems data, so they are all synchronised on reload. If you are getting it with default aircraft I can only think your disk is very full and your Windows caching is off or for some reason unable to get enough memory. Pete

I moved your post to the Support Forum, where it can be properly answered. Please post general support questions here in future. Did these instruments come with a driver or some sort of interface software? If so, does it use FSUIPC? If it does use FSUIPC, did you install it, or did it install automatically? Does Sim Kit have any support you can ask questions of? Pete

You don't mean "FSUIPC won't connect to the sim" -- FSUIPC is effectively part of the sim. If your applications cannot connect to FSUIPC there can be several reasons. The first thing you need to do is find the FSUIPC.LOG file, in the Modules folder, and paste its contents in a message here. Make sure FS is closed first.q Pete

If you want to use FSUIPC's tiller option, along with an assigned and calibrated rudder, so that effectiveness gradually transfers from one to the other on the ground, you simply need to find the FSUIPC tiller control number (there's a list in the Advanced Users manual), and write the axis value to offset 3114 using IPC.writeSD, then the control number to 3110 in the same way. If you prefer, you can use FSX's own steering axis -- look up the control number for that in the FSX controls list. I'm very surprised your "tiller" only has button inputs. That seems crazy. Not sure how you'd want to use that. You need a proper axis really. You'd have to maintain an axis value and use the buttons to increment and decrement it. Ugh!

The Aerosoft MCP driver simply uses the virtual button offsets in FSUIPC. There's nothing special in FSUIPC for this device, and, yes, you would need to use the driver from Aerosoft, Australia. I'm afraid I don't know where you'd get that these days -- ask around in the www.mycockpits.org forums. Pete

Ah, sorry. Yes, I was getting ahead of myself. It WILL be installed by the next full install update, but meanwhile it is included in the latest ZIP file with the updated module and changes document. Please see the Download Links subforum. Pete

There's not really much difference for actioning controls. INI file assignments are not modified by new versions. In fact the Installer doesn't touch the file at all. If you are using profiles in FSUIPC you can have all the assignments for different profiles in separate INI files. This facility was added recently and is described in a new document installed in your FSUIPC Documents folder. Pete

I don't use PMDG aircraft so I don't know the answer. It will either be by using one of the Events they support and listed in the PMDG SDK document, or possible by writing to local panel variables (L:Vars) if the aircraft uses such things. If neither way is possible, then it probably cannot be done directly. Maybe you can ask folks over in the PMDG support forum? There are defined events for operating the course selectors with parameters identifying the mouse operation to be made, thus simulating the user doing it with the mouse on screen. So one solution is to use the appropriate event, in a loop, reading the value from the relevant offset, until the desired value is reached. Pete

I do not use any PMDG aircraft and I don't know anything about the parameters other than what is in that PMDG SDK document. I expect that trhe parameters are all based on the equivalent mouse action which you would otherwise use on the cockpit on screen, i.e. these as listed in that document: #define MOUSE_FLAG_RIGHTSINGLE 0x80000000 #define MOUSE_FLAG_MIDDLESINGLE 0x40000000 #define MOUSE_FLAG_LEFTSINGLE 0x20000000 #define MOUSE_FLAG_RIGHTDOUBLE 0x10000000 #define MOUSE_FLAG_MIDDLEDOUBLE 0x08000000 #define MOUSE_FLAG_LEFTDOUBLE 0x04000000 #define MOUSE_FLAG_RIGHTDRAG 0x02000000 #define MOUSE_FLAG_MIDDLEDRAG 0x01000000 #define MOUSE_FLAG_LEFTDRAG 0x00800000 #define MOUSE_FLAG_MOVE 0x00400000 #define MOUSE_FLAG_DOWN_REPEAT 0x00200000 #define MOUSE_FLAG_RIGHTRELEASE 0x00080000 #define MOUSE_FLAG_MIDDLERELEASE 0x00040000 #define MOUSE_FLAG_LEFTRELEASE 0x00020000 #define MOUSE_FLAG_WHEEL_FLIP 0x00010000 // invert direction of mouse wheel #define MOUSE_FLAG_WHEEL_SKIP 0x00008000 // look at next 2 rect for mouse wheel commands #define MOUSE_FLAG_WHEEL_UP 0x00004000 #define MOUSE_FLAG_WHEEL_DOWN 0x00002000 Those are in hexadecimal. The value 536870912 is the same as hexadecimal 0x20000000, which means "MOUSE_FLAG_LEFTSINGLE" -- in other words a single click with the left mouse button. FSUIPC also accepts hexadecimal parameters. Just precede the value with an 'x', i.e. x20000000. Pete

No. FSUIPC does NOT see hardware at all! It is an interface into FS, not to hardware. The buttons and switches it sees are only seen because Windows sees them and supplies the values. You seem to have a complete misunderstanding of what FSUIPC is! To interface any hardware which isn't recognised by Windows as a joystick or keyboard or mouse you need a driver which either makes the device look like a joystick or keyboard or mouse, or supplies values direct into FSUIPC's offsets.. You can write one in Lua, because FSUIPC's Lua libraries include COM and HID functions to read and write serial port and USB devices. But you have to do the programming! Either that, or use the driver your device came with -- i.e. EHID. Pete

Same file: #define EVT_CONTROL_STAND_AT1_DISENGAGE_SWITCH (THIRD_PARTY_EVENT_ID_MIN + 682) #define EVT_CONTROL_STAND_AT2_DISENGAGE_SWITCH (THIRD_PARTY_EVENT_ID_MIN + 685) The TOGA buttons also listed. Pete

The numbers on the left of every log line give the elapsed time since FSUIPC started in milliseconds. So, for example, 136501 is 136.501 seconds from the start.time, which is logged in a line near the beginning. Pete

If this is for the 737NGX, then the document in the PMDG SDK installed with the update they released ("PMDG_NGX_SDK.h") lists: #define EVT_MCP_DISENGAGE_BAR (THIRD_PARTY_EVENT_ID_MIN + 406) Earlier in the same document THIRD_PARTY_EVENT_ID_MIN is defined by #define THIRD_PARTY_EVENT_ID_MIN 0x00011000 // equals to 69632 So, the <custom control> to be assigned in FSUIPC is 69632 + 406 = 70038. Whether it needs any parameter value I don't know. You'd need to experiment. Maye '1' (for "TRUE"). Pete

Show me the FSUIPC4.LOG file from such a test. You can post it here, or if it is too large, Zip it and sent it to petedowson@btconnect.com. Pete

Haven't you even looked at any of the examples yet? Try HidDemo.lua, for instance. Take a look at that. For a normal joystick HID device things are relatively simple. If the device has its own protocol and formats it will need effort by you to decode the data. My HidScanner program will help a lot there as it gives a breakdown of the positions for most standard inputs. You can download that from the Download Links subforum. Pete

As far as I recall (I did have a number of TRC gauges, and so used their driver, some time ago), it will all work through WideFS perfectly well. The difference between Win 7 and Win XP is easily resolved in one of the two ways I mentioned in my last reply. A network is a network is a ... If you have an Internet router it is usually easiest just to connect them both to that. If your two cockpit PCs are separate altogether, you can network them with a special PC-to-PC "crossover" Ethernet cable, not a normal type. Pete

Any version of Windows from XP SP1 onwards works with the current WideClient. The only thing to watch is that XP uses a different default network workgroup name to Win7, so you should change one to match the other for WideFS to link automatically. (Or you can always link inany case by giving the Client the IP address or name of the FS PC). For my cockpit I have the main FSX PC using Win7 64bit, and 5 other PCs on WinXP. Pete

I had a look at this today and it actually isn't possible to suppress controls the way FSUIPC currently intercepts them. I thought it would be reasonably easy, but it isn't. I would have to change the control interception to use SimConnect event handling, in the same way as happens for axis mapping and calibration, and I'm really not willing to make such drastic changes at this stage. Sorry to disappoint. The only way I can think of to fix your situation, albeit rather clumsily, would be to use event.control as you are now to see the offending controls being sent, and immediately sent the counter- or reverse control, to undo what it does. This is actually the way FSUIPC implements some of the systems inhibit options it provides via bits in offsets, like stopping flaps and spoiler actuations.. Without knowing which controls are causing the problem I can't really help much more. Regards Pete

Okay. Good. The Lua as quoted from the old message is totally corrupted by image references in your re-print, though. I hope you got it okay from the original. Pete

No. They've not changes at all since being defined in 1997 (FS98). Those are the Engine 1 and Engine 2 throttle control inputs, and setting them to any negative number within the aircraft's range will set FS's reverse thrust -- until and unless the values are overwritten again, possibly by normal throttle axis input. So, check several things: 1. The maximum reverse thrust on many aircraft is 25% of full thrust. It is defined in the aircraft.cfg file for the specific aircraft. A 25% reverse would have the value -4095. Your -5800 value is 35%, which is okay if the CFG file says the max is .35 2. Try is with -4095 and with the default FS 737, because add-on aircraft might behave differently in any case. Some sophisticate add-on aircraft manage their own throttles. 3. When applying the reverse you need to first make sure your throttles are in a stabile idle position, with no jitter to interfere. Make sure the throttle levers are properly calibrated with a good idle position. You can check what is going on using FSUIPC's logging facilities -- enable Button, Event and Axis logging. If you temporarily put FS into Windowed mode and enable the FSUIPC console log option you'll be able to see what is happening in real time. Pete

But I assume it communicates with ProSim via FSUIPC offsets? I think EHID is not ProSim-specific, it is used with other cockpit packages too, like SimAvionics and Project Magenta, is it not? But FSInterrogate is simply a utility to allow you to read and write FSUIPC offsets by hand, i.e. using the keyboard. It doesn't interface to anything but FSUIPC. There are no hardware drivers! FSUIPC knows nothing at all about hardware. The Lua com library does allow you to read and write to any USB or serial port device, but you have to do some programming. There's no other way unlist your EHID driver is writing the tiller value to an FSUIPC offset somewhere -- if it is, then the rest is very easy. XML is just a collection of data definitions. It is not a program in its own right. What program is using the data in the XML, and what then happens? Pete