Pete Dowson

Of course. It has to record an address within the gauge module which has to be called directly by FSUIPC code when you want to use that function from a button or keypress you assign later. What else could it possibly do? Each possible action that a suitable coded gauge can execute has to have its own recorded entry point in the code, to be called to carry out that action on request. One macro file can contain as many as you like, each one with a different name to identify it. what exactly do youo mean "3 of them in succession"? It is more usual to do a complete cockpit in one session, making one macro file with all of the controls encoded for that cockpit.. One macro from three separate mouse clicks? Sorry, I really don't understand. What would that mean? It makes no sense to me. If each place you click has a difference action, each has to be recorded. Each will have different characteristics. What do you think you would be trying to do with this "harvesting"? Once you have all your macros created you can put them together how you like, assign multiple actions to buttons, switches, keypresses and so on. Assignment to macros comes later. First you need to record them. I see you still don't understand. FSUIPC in NOT recording a "spot". It doesn't care anything about the window or the display. Once the macro is recorded it will work with no display, with the gauge hidden. The graphics and mouse become totally irrelevant. The macro is directly calling the code behind the gauge, the actual code making it work, directly. There's no mouse, no graphics involved. Oh dear. This IS hard work, isn't it. :-( I repeat, there are NO MOUSE CLICKS involved. The mouse macro system is a way of FSUIPC finding out what actual code to execute inside your aircraft. One the macros are recorded you can easily have your three successive actions associated with a key or button. I already explained all that a reply or two back. You can assign as many macros or keypresses or controls as you like, by editing the INI file and doing it there, by hand. THIS IS TO DO WITH ASSIGNMENT ! You do your assignments AFTER you make your macros! You are totally confusing yourself, mixing separate stages altogether! Pete

It isn't an "action", it is an optional way of running FS. Why would you want to assign it to a button? If you need it because you have an aircraft which is using elevator trim in Autopilot vertical modes and the elevator axis you've assigned interferes (presumably because of jitters), then you need it on. Otherwise you can leave it off. Why switch it on and off? You either need it or you don't. Pete

WideServer can do that tidily. Well, assuming the errors in the client log after over 12 hours were due to the server closing untidily, then the only 'problem' I see in what you've supplied is a recoverable one twice in over three hours, and no more. Maybe it isn't so bad? Pete

Of course, but they are being seen locally to that gauge. You often only get controls being used when they can be assigned to keypresses and buttons and sent from elsewhere. There are a lot of switches in FS gauges which a purely local to a gauge. No. If you have event logging enabled and there are no events being sent, then the gauge doesn't use them. Buttons aren't relevant, not sure why you've turned that on too. The only other possibilities for this would be Mouse Macros or L:Vars. But I just tried both of those on the G1000 gauge and neither work. Sorry, it seems Microsoft did not design that gauge with hardware users in mind. Regards Pete

No, FSUIPC doesn't assign any mouse clicks. It never sends mouse clicks or movements. I really don't want to get involved in screen coordinates -- things move all the time. Sending mouse stuff is a real pain. Forget the screen. The screen isn't anything to do with it. You can assign almost any number of controls or keypresses or macros to one button or switch, and similarly almost any number of controls or macros to one keypress. But to do it you have to edit the INI file, adding the extra lines in there. I simply do not want the dialogues made more complex for such a feature. Regards Pete

I'm afraid FSUIPC isn't a general purpose hardware driver for any possible hardware interface boards out there. It doesn't itself drive any displays or indicators. Every hardware implementation is different, so how could it? The same really applies to inputs from switches and axes -- for those it relies on standard Windows joystick drivers -- or special cases like GoFlight and VRi devices for which additional input facilities have been included. If yuor interface board is a standard USB HID device then it may be possible to program it via Lua plug-ins using the HID extensions to the com library, but it is a programming job. How is FSUIPC seeing the switches in any case? Does the board come with any software? Regards Pete

If FSUIPC is sending -4096 and that doesn't set full reverse on your specific aircraft then there's something wrong with the aircraft. FSUIPC scales that -4096 value according to the maximum reverse thrust value given in the Aircraft.cfg file. This is the parameter which matters: [GeneralEngineData] min_throttle_limit=-0.25 //Minimum percent throttle. If that's 0 then the aircraft provides no reverse thrust. A negative value gives the proportion of full thrust (1) which applies in reverse, so -0.25 is 25%. the internal throttle vlaues are scaled 0 - 16384, so a -25% value is -4096. Some aircraft have more, some less. Use FSUIPC's axis logging to see what throttle values it is actually sending to the aircraft. Maybe the minimum input FSUIPC receives from your throttle axis isn't -16384 every time. For max reverse it needs to be at least as low as the calibrated minimum. Regards Pete

Well, if they are 'complete' then they're not "closed", meaning that they are not taken after FS was closed, or WideClient either. There's always a summary at the end after a normal close. The potentially important but missing log is the one from the only client for which the Server is showing as giving any errors (and only two isolated ones which would do little harm in any case), at least for the 3 hours or so covered by the server log fragment. The 12 hour session on the Client log fragment shows that your server session continued a lot longer, and the only errors that shows, after over 12 hours, are really those you might normally see if you closed the server untidily (i.e. without using the closure options in the clients so that they can close tidily too). Note that if you only get problems occurring after long periods like that, it may be indicative of a memory leak in one or other of the add-ons you are using. In fact, with FS9, there were a lot of memory leakages occurring from scenery elements such as autogen files, especially when they are placed in folders without a proper Scenery + Texture pair. I don't recall the exact details, not having used FS9 for over five years now, but i expect you can still find mention in the assorted Forums covering FS9. Regards Pete

Version 4.76 hasn't been released yet. I'm not releasing even 4.75 until the New Year, 2012. I wouldn't expect 4.76 before Summer 2012! Pete

The user manual does not list FS controls, only the controls FSUIPC added to fill in gaps. The list of FS controls is installed in a document (obscurely?) called "List of FS controls" or similar in your FSUIPC Documents folder, as listed in the Installation guide. Heading increment and decrement controls are named "Heading bug inc" and "Heading bug dec" so you should have been able to spot those easily in the FSUIPC drop-down assignments list. The course inc/decs are less obviously called "Vor1 obi inc" and "dec" and "Vor2 obi inc" and "dec" respectively. There is also an easy way of finding the correct FS control name: enable event logging in FSUIPC's Logging tab, then use the controls in a default aircraft using mouse or keyboard, then look in the FSUIPC Log to see what event it logged. It will give both name and number. Er, 'does not extend' what, to "many payware aircraft"? Sorry I don't follow you. FSUIPC has nothing to do with any aircraft, payware, freeware or default. It is an interface into FS. It manipulates FS values. I think this is in the User Guide, but for your quick reference: FS keypress assignments are overridden by FSUIPC assignments when they are applied, whether generically or only in specific profiles.. FS axis and button/switch assignments cannot be overridden, unfortunately. So you must either disable controllers in FS and use only FSUIPC, or ensure that nothing assigned in FSUIPC is also assigned in FS. Regards Pete

All of the errors you are seeing cannot be the responsibility of any application, but must be due to the network connection. Sumcheck errors indicate corrupted blocks, and such could be due to anything from bad memory at either end, bad network drivers, bad network interface, router, cable or switch. I've never seen such errors without there eventually being a component found faulty. Unfortunately you've only suppied log fragments -- if you'd kindly close everything down first before collecting logs it would be much more useful, as summaries are added at the end with a normal closedown. There are only two errors in the Server fragment, both in blocks from the one client, "PFD": And these two occur at widely spaced intervals -- 1hr 45 mins after it joined and then another 1hr 41mins later. Very strange, no? Is there something happening on that PC at such intervals? You don't bother to show the Client log for that PC, which is odd considering that's the only one of the three clients which the Server saw problems with, at least in the fragment you supplied.. The other partial log you provide is for the CDU: and the first error on that was a long way into the session: after which it didn't appear to recover. This sequence occurs a full 12 hours and 2 minutes into a session. Are you sure your server was still running FS at that time? I can't tell, you supply only partial data. You don't show any part of the WideServer log that far into your session! Regards Pete

Actually the use of L:Vars this way is a relatively new system and certainly not used by all add-on aircraft. It is commonly used with gauges written using XML rather that those more traditionally programmed in C or C++. The more usual way is via the "Mouse Macro" facilities built into FSUIPC. That works for aircraft gauges built using the Microsoft C/C++ Gauge SDK. Check the FSUIPC User Guide -- most of the work in discovering or making these is automated. If neither of these two techniques work, and there is no SDK provided by the aircraft author to interface his controls, then I'm afraid you might be out of luck. Regards Pete

I don't think any of the G1000 controls were ever hooked up in FSX, were they? I've never used any GPS in FS so I don't know, but you could try using the FSUIPC event logging when operating the G1000 in FS more directly and see what logging results you get, if any. Are there any assignments possibly for the G1000 in FS's own dialogue? I suspect there are a few controls tabulated and assigned numbers in FS's CONTROLS.DLL which I suspect were "good intentions" never realised. Regards Pete

You need a working network before you can expect WideFS to connect. Sorry, a log file for another product is for the Support of that product, so you need to go there. If you want help with my products I need to see the logs from my products -- the WideServer.log from the FS PC and the WideClient.log from the Client PC. That's why such logs are produced, so you can help me help you! WideFS can use TCP, UDP or IPX, or all three for different clients. IPX is not commonly used these days, but really only because it isn't installed by default on current Windows versions -- it is an optional install. But TCP or UDP are fine. Did he ever bother to read the WideFS documentation supplied? In particular did he look at the section early on in the User Guide about configuring the network? Yes of course. As documented it works automatically -- with no parameters needing changing -- only if all PCs are in the same Workgroup. If you want different workgroups then you must tell the client where the Server is, exactly as documented. By default Win7 and XP use different Workgroup names, It is best to make them the same. All my PCs are in a workgroup called "PETES". Why spend 7 hours searching forums but not bother to look at supplied documentation? It makes no sense! Pete

Hmmm. Sounds as if somehow the client's SimConnect installation got corrupted. Glad you solved it. Pete

That never used to matter until Microsoft changed something in Windows, because installers used to automatically get elevated admin privileges in any case. But equally it doesn't matter if either you've diabled UAC (User Account Control) or avoided installing FS in "Program Files" -- it is Windows' protection of the Program Files folders which causes the problems. No, it is just part of Windows' habit of mothering you, as if you didn't know what you were doing. Regards Pete

That looks a lot more sensible. Well you should -- if the throttle axis IN value reaches -16123 or less then the OUT will be sufficient to get full reverse as specified in the Aircraft.CFG file -- usually -4096 or 25%. What does the OUT value show in the calibration tab when the IN value is -16123 or less? Yes, you can do that if you prefer. As I said, that is generally how folks use the Saitek throttles. Regards Pete

Is the IP address of your Server PC definitely (still) 192.168.0.2 ? Maybe a spike blew your network. But didn't you say WideFS was connecting okay? Pete

If the total range is -14432 to -1056, how on Earth are you calibrating min and max to -16384 and +16383? You aren't making sense I'm afraid. That makes no sense either. Is your detente inside the range of axis movement, or at one end? If it's anything like the Saitek throttles there is no reverse range in any case. You can't use the axis for reverse in that case if you want the idle at a detente which is right at one end! That's how it is done on the Saitek throttles. But do you have such buttons on the CH? Pete

The FSUIPC log shows everything okay. Are you running ASE and IVAP on the same PC as FSX? If not check the SimConnect.xml file on the FSX PC and the Simconnect.cfg file on the client. If you are running FSX "as administrator, try it normal, and vice versa. Regards Pete

Those -16384 and +16383 values are actually beyond default minimum and maximum and in fact are the most extreme values possible on the most perfect axis. Perhaps your device is so perfect, but you would still be better off calibrating the extremes with the lever moved AWAY from the end stops, so you can always reach full thrust or deflection. That indicates that your axis is not always or not often reaching the -16384 value. Check your forward max thrust too -- I expect the same applies there! Axis inputs vary, especially at the extremes. Allow a little room at both ends as I say. Sending direct avoids posting a message to FS merely so that FSUIPC can trap it and alter the value via calibration before sending it on. By sending direct FSUIPC calibrates immediately then sends it to FS only once. In general it is better, but as you say some add-on aircraft need to see the FS controls. That's why there's a choice. The FSUIPC assignment to an FS control actually gives you no benefits over having the assignment to the same control in FS -- FSUIPC's calibration is identical in both cases. The only advantages then in FSUIPC assignments is that there are more FS controls on offer than in FS, and the assignments can be automatically switched for different aircraft or aircraft profiles. Pete

Not "WideFS" but "WideServer 7". You misread. And all that means in that the previously separate WideServer DLL, which had to be used for WideFS on FS9 and before, is built into the FSUIPC4 code for more efficiency on FSX (because FSX takes a heavier toll on the PCs capabilities). WideFS is still an extra purchase. The Server built into FSUIPC4 is not enabled unless you have a registration key. You don't buy "the latest version", you only buy FSUIPC3 or FSUIPC4. You are expected to always use the latest version whether you register or not, else you get no support. No, never. All updates are just replacing the DLL itself, nothing else. Yes of course. Pete

I have no idea how to do that in FSX or later. Sorry. Pete

Sorry, can you clarify this please, because I don't think it makes sense as you say it. You renamed which DLL file exactly? The DLL.XML as I said? The one next to your FSX.CFG file? If you did that then you have to reinstall FSUIPC4 because without the DLL.XML it will not be loaded in any case, so FSX would not then ask for its approval.. If you mean you did all that (please always be explicit), and then FSUIP4 works fine, I think you must have something else being loaded by the DLL.XML which is causing a conflict. Please show me that file in this case. And do please expand upon your original statement -- when exactly does FSX hang? If you did what I suggested then you wouldn't simply be able to "rename the DLL" back, as there would have been a new, smaller, DLL.XML file created by the FSUIPC4 installer. They are text files -- the FSUIPC4.LOG, the Installer's log and the DLL.XML and EXE.XML files are all text files. Just paste them into your message, like you'll see everyone else doing here. It is very difficult getting information from you. I fear this is going to take quite a long time ... Regards Pete

You mean it hangs? At what stage? Have you followed all of the hints in the FAQ thread I mentioned? So far it has not failed to run eventually on any user's system. Most of those initial start problems are due to a SimConnect bug which was never fixed by MS. If you have other programs being loaded by SimConnect it might be a good idea to stop them just to get FSUIPC approved. You can do this be renaming your DLL.XML and EXE.XML files, installing FSUIPC4 again, getting FSX working, then closing down FSX and renaming the two files back again. Once FSUIPC4 has been verified by SimConnect it loads fine forever after. The problem normally occurs before FSUIPC4 is even running -- though to check that see if there's an FSUIPC4.LOG file in the Modules folder. If there is show it to me, but from the very little you've told me so far I doubt there is. I might be able to help more but with no information it is very difficult. Regards Pete