Pete Dowson

And nothing else? It doesn't need access to any FS folders on the client? Pete

It is most certainly NOT the same problem -- in Daz's case the server was not even waiting for clients, and in fact FSUIPC wasn't starting. A completely different set of symptoms! I can't tell why your client isn't connecting without information. i need to see both FSUIPC and WideServer logs from the FS Modules folder, and the Wideclient log from the client. Pete

Aivlasoft EFB uses its own Data Provider, not WideFS. If FS Commander can use WideFS (I don't know if it can or not, sorry), then if WideClient is connecting the only likely problem is that it aso needs access to FS folders. Check its documentation and maybe ask in its support forum. Pete

Again, with a Lua plug in you can control any value as precisely as you like. With controls the INC and DECR amounts are fixed by FS. You could actually try using FSUIPC's Offset increment and decrement controls to change the values directly, You'll need to look up the offsets in the Offsets document supplied in your FSUIPC Documents subfolder. Pete

Well that's some VB6 problem, nothing to do with FSUIPC. Sorry, you need to debug your VB6 code. Are you still learning VB6? Well if your program fails with an error I'm not surprised nothing happens. The free slot is only 0 because you aren't previous running programs which are also using this facility, so you cannot assume that. And you have an error in any case: the 0 in "0My_Menu" is a character 0 which is actualy 48. So you are trying to use slot 48, not 0. The first byte written MUST be the slot number, binary, not a character version of the number. If it were than no slots could be used past 9! Try using FSUIPC's IPC write logging to see what is actually getting into fSUIPC. That's what it is for. In the FSUIPC SDK. It took a lot of hacking into FS code. You start by learning how to write C or C++. And you'll need some ASM as well. You'd need to learn to write Gauges first, then disassemble some parts of FS to find out how to hook into things. It takes months for each version of FS. Pete

Writing is identical to reading but the other way around. There is no "data type" as far as the reads and writes are concerned, it is all just bytes. The data type is by interpretation, not by definition. What "error" do you get when writing? I'm afraid I don't know VB6 at all. Sorry. Code "ideas" are by the examples in the SDK. Pete

WideFS does absolutely nothing at all except allow programs on the client to talk to FS through FSUIPC. You most certainly have something else making these changes. Maybe you have some Lua plug-in installed in the same folder as WideClient on the client PC? Any .lua file there will be automatically run as soon as WideClient connects. If not then you have some other program or assignment doing it. Don't forget that buttons and switches on the Client PC can also be assigned in FSUIPC on the FS PC. Regards Pete

Such an implementation could be achieved, but certainly not through simple assignments. I've never even received such a strange request in the whole 16 year history of FSUIPC! ;-) In order to accomplish something like that you'd need to program it in a Lua plug-in script, assigning the said axis to that Lua plug-in and having that decide what to do with the resulting value based on the switch setting. Regards Pete

Well, to calibrate one assigned to a reverser axis, yes. Yes. You are looking in the wrong drop-down list. The "FS Controls" do not feature a reverser axis. You have to first select "Direct to FSUIPC" in the axis assignment choices, then the drop down list shows all the FSUIPC axes. Those assignments go direct to calibration and so are more efficient (the FS axis controls go to FS and, if calibrated, are then intercepted by FSUIPC). The reason the default is for FS controls is that some add-on aircraft don't like the controls FSUIPC uses, as they need to be sent to fS at a lower SimConnect priority level. FSUIPC supports a common reverser for all engines, or up to 4 separate ones. Pete

Assuming you aren't starting in Paused or Slew mode, which can sometimes result in a stall initially, I suspect the messages needed by FSUIPC aren't arriving from SimConnect because the latter is overloaded at start-up time. In the log you posted initially, how long were you actually flying for? It looks like you closed down after a few minutes. You said you weren't running anything on the Network, so what do you use WideFS for? When you say "when i boot up FS Commander it cannot find FSX and likewise a program i used as part of my flight logging for BA Virtual is connecting either", are both of those, then, running on the same PC as FSX? If so then they should connect -- the only thing which might stop them s if you are running FSX at a different privilege level to those programs -- either run everything normally, or everything "as administrator", not a mixture. Pete

The only thing FSUIPC will be doing is rescanning all connected USB joystick type devices. Maybe this is waking up an sleep device, or causing one to stop doing something odd. Have you made sure that Windows power management is turned off on all USB hub devices in the Windows device manager? BTW you can stop FSUIPC doing this by adding "AutoScanDevices=No" to the [General] section of the FSUIPC4.INI file. Pete

"LVar" stands for "Local variable", and these are used commonly these days in Gauges -- especially those written in XML. FSUIPC provides a way of setting values to these variables, using a macro from a macro file. To discover if there are any LVars or interest in use in that aircraft the first step is to get FSUIPC to produce a list of them. That's done by assigning a button or keypress to the control called "List local panel variables". It will then simply list all those it finds for the currently loaded aircraft, along with their values. If any of them look to be of likely use, the next step is to see how they change. That's a bit more complicated. You need to put the Lua file called "log lvars.lua" (from the Examples ZIP in your FSUIPC Documents subfolder, in the FS Modules folder) into the Modules folder, then load up FS and assign a button or key to "Lua log lvars"., then use it to start the program. Now the L:Var values will be shown on screen as they change, so you can operate switches and see their affect. After that it's a matter of constructing the macros to operate those switches through their L:Vars instead. There is documentation for all this stuff, but if you need further help come back. First you need to see if L:Vars might be the way, or not. Pete

You have a bad P3Dv2 installation -- its SimConnect part is not installed. .That's essential for most add-ons and is heavily used by FSUIPC4. Try finding and running the SimConnect.msi file. Maybe you can get help in this in the P3D forum, as I personally don't understand why it hasn't been installed when you installed P3D. You might need to redo the installation completely. Pete

Okay.the log shows you using the DHC6, which is in profile "Twin Engine Turboprop" with only these axes assigned: 0=AX,256,D,7,0,0,0 1=AY,256,D,8,0,0,0 2=AR,256,D,47,0,0,0 i.e. the toe brakes and the rudder/slew combo. You have no assignments to your controller B for that profile, unlike the other profiles. Pete

The "blah blah blah" bit is the important bit. That error can only occur if you asked Wideclient to run some program or other, as in a "Run" command. Ah, hold on -- didn't you say you were trying to run a Lua program using "RunKey"? That won't work. Lua programs are not recognised as such by Windows. Only a Lua interpreter can run a Lua program. Yes. "setbtnstate" is for Toggle buttons, whilst "setbtncol" is for non-Toggle buttons. They are two ways of doing effectively the same thing for the different types. What buttons are you thinking of testing here? I'm completely confused about what you are trying to do. If you want a button to change colour when it is toggled, use the toggle facility. If you want the colour to reflect a state of something in FS it is the offsets in FSUIPC you need to be testing, and you can have events for those. So you need to test the switch states by having events on the appropriate offsets which reflect the switches in FS. I really don't know why you are concerned with testing buttons, which you can't do anyway on the client except for the relevant offsets which reflect the buttons states in FS. Pete

If it is on-screen then it isn't FSUIPC. I thought you meant in the Log file -- FSUIPC only deals with VRi devices if there's a VRinsight section in the INI file. e.g. something like [VRInsight] 1=COM3 but if the device isn't there there would simply be an entry in the Log file -- same as if it was there in fact but with a "not" or similar. Try the VRinsight support forum. It probably just needs something disabling in the VRi control program. I think it is all new since I last got involved. Pete

Your choice entirely. I don't know Saitek pedals from any others I'm afraid. Don't mix up the notions of assignment and calibration. FSUIPC's calibration works on FS controls, not axes, and works no matter where you assign. Be aware that if you have FS's controllers enabled, then it can and often does automatically assign axes and buttons, especially if it, for any reason, thinks the controller is newly attached. If you are assigning in FSUIPC you should really disable controllers altogether in FS for this reason. But if you are only using FSUIPC for calibration, you can assign everything in FS instead. Your choice. The main advantage of assigning axes in FSUIPC is simply that you can have different controllers for different aircraft, something you can't do with FS assignments. Pete

Just remove whatever you added to make the VRi COMBO work. I don't recall any of the VRi stuff myself (not been involved with it for years), and I'm away from the PC containing the documentation. Can you look it up? It's be an appendix to either the User Guide or the Advanced Users guide, or maybe even a separate document. All the documentation for all things to do with FSUIPC is found in the FSUIPC Documents folder, within your FS Modules folder. Pete

Software doesn't change on its own, and nothing touches settings you have made. I can't tell from the files you uploaded because though you called one "INI" and the other "LOG" they both contain the same identical LOG file!! Your settings are in the INI file. However, you seem to have enabled all sorts of logging and the log does show plenty of inputs arriving from somewhere -- probably controllers. For axes is shows Mixture1 and Mixture2 inputs. After what appears to be a USB device reconnection (you were unplugging things and re-plugging them?), rudder and toe brake inputs. I'd guess that your controls are swapped. The usual problems folks have is when they have multiple controllers connected and either don't keep them plugged in, so that each time they are reconnected in a different order they acquire a different ID, or you do some update to Windows which also changes the IDs. The way around both problems is to always use joystick lettering so that FSUIPC can track the movements of the controllers. There's a chapter about this in the User Guide, listed in the contents. Pete

Enable event logging in FSUIPC and see if those mouse clicks send normal FS controls. If so you can assign to those. If not, the next step is to see if they are susceptible to the FSUIPC 'mouse macro' option, and lastly, failing that, log L:Vars and see if you can operate them using L:Var macros If the MD11 you are using is the PMDG one, then have you looked at the User Contributions subforum? This thread: http://forum.simflight.com/topic/63151-pmdg-md11x-commands-upd16thdez09/?hl=md11 certainly appears to show that the mouse macro method works well. Regards Pete

Yes, that's the general idea. Ooops! Well spotted -- the red [Not WideClient] notice should be there. Sorry, it isn't possible to use LVars on a client Pc. They are intricately bound into the gauges which use them. 193? Reported where? By Windows? Windows error 193 is "bad EXE -- not a valid EXE program". I don't know how that can be connected to Lua. LUA files are simple text files. Just use Notepad or any text editor! Any file or filetype .lua placed in the same folder as WideClient will be run as soon as WideClient connects to FS. This has never failed. Check the logging -- Lua files run there are logged. I assume this Lua was NOT placed in the same folder as WideClient, then? Where do you find "ipc.btnstate"? What does it mean? And how is (40,0) button 1? You can't just invent your own library functions. You can only use what is there. That line would give you an error, logged in the log for that Lua plug-in -- didn't you look? And note that ipc.setbtncol can't be used on button spaces declared as Toggle. Pete

Yes, the logging was for your information, not mine. It simply shows which lines in the Lua plug-in were being executed in relation to changes in the ground speed. none of those lines restore the original frictions. Which is what I've been saying. Really, if you think there's something wrong with the frictions being set by the plug-in you'd be better off going to the AVSIM FSX forum and finding the original very long thread there about the whole matter. I'm sure it's been thrashed to death. I've never used any friction patch myself because the aircraft model I use performs quite as expected and verified by real pilots. Regards Pete

If you are assigning the throttle via FSUIPC, then as well as the assignment on the left in the Axes tab, on the right you can assign FS controls to operate when the lever is moved through or into defined regions. F1 by default is assigned to the FS control "throttle cut", so try assigning Throttle Cut to the range near and into your idle zone, selecting only the down direction (so it doesn't get sent when trying to increase throttle). Pete

That's just a log of it starting and ending. To see what it actually does you need to enable the Lua Debug/Trace option. BTW, when you apply brakes, there's a delay after releasing them before they are fully off. Pete

Okay. Let me know how it works out. If folks bounce they it should be recorded in any case! ;-) Pete