Pete Dowson

Your post crossed with my last. Please refer back regarding WideFS. Regarding the SimConnect files, you need to say where they are too, really. The CFG file on your Client should be in your "My Documents" folder. You have: [SimConnect] Protocol=Auto Address=192.168.1.54 Port=500 MaxReceiveSize=4096 DisableNagle=0[/CODE] I would try this: [CODE][SimConnect] Protocol=IPv4 Address=GRETEL Port=500 MaxReceiveSize=4096 DisableNagle=0[/CODE] And the SimConnect XML file looks wrong to me. To start with you have two entries trying to use the same port (500). Only one will win, and if it's the "local" one then you won't get a remote connection in any case. Try this: [CODE] <?xml version="1.0" encoding="Windows-1252"?> <SimBase.Document Type="SimConnect" version="1,0"> <Descr>SimConnect</Descr> <Filename>SimConnect.xml</Filename> <Disabled>False</Disabled> <SimConnect.Comm> <Disabled>False</Disabled> <Protocol>ipv4</Protocol> <Scope>global</Scope> <Address>192.168.1.54</Address> <MaxClients>64</MaxClients> <Port>500</Port> <MaxRecvSize>4096</MaxRecvSize> <DisableNagle>False</DisableNagle> </SimConnect.Comm> <SimConnect.Comm> <Disabled>False</Disabled> <Protocol>auto</Protocol> <Scope>local</Scope> <Address></Address> <MaxClients>64</MaxClients> <Port></Port> <MaxRecvSize>4096</MaxRecvSize> <DisableNagle>False</DisableNagle> </SimConnect.Comm> </SimBase.Document>[/CODE] I'm assuming your GRETEL's IP address is 192.168.1.54. If not change that, or even try GRETEL. Regards Pete

Ah, right. You never said that. The Client log just shows that it doesn't know where the server is and so is waiting for a Broadcast: Broadcasts don't travel between separate Workgroups, so you probably haven't named them the same on the two PCs. ********* WideClient Log [version 6.86] Class=FS98MAIN ********* Date (dmy): 20/03/12, Time 20:38:13.668: Client name is HOLLY2 140 LUA: "C:\Program Files (x86)\WideClient\Initial.LUA": not found 203 Attempting to connect now 1217 Trying to locate server: Need details from Server Broadcast 1217 Failed to connect: waiting to try again 3260 Attempting to connect now 68484 Trying to locate server: Need details from Server Broadcast[/CODE] The Client INI file you included does have these parameters included: [CODE]ServerName=GRETEL Protocol=TCP[/CODE] which should certainly have made it try to connect to that PC. If I use your INI file here and run WideClient with it I get this Log: [CODE]********* WideClient Log [version 6.954] Class=FS98MAIN ********* Date (dmy): 21/03/12, Time 13:01:26.626: Client name is LEFT 1609 Attempting to connect now 1625 LUA: "C:\Temp\Initial.LUA": not found 4171 Trying TCP/IP host "GRETEL" port 8002 ... 4171 Error on client gethostbyname() [Error=11004] Valid name, no data record of requested type[/CODE] Obviously it won't actually connect because I have no PC named "GRETEL", but this is detected okay and logged. I know my WideClient.exe is a later version that yours (you can get updates from the [b]Download Links[/b] subforum), but there's most certainly not been any change in how this sort of things behaves in [i]many[/i] versions over [i]many[/i] years. Therefore I can only conclude that the WideClient LOG and INI files you supplied do not actually come from the same run of WideClient. The log shows that the ServerName parameter is being totally ignored, and I don't believe that is possible. If you are using the same install of WideClient for FS9 with success, show me the Log and INI from that -- obviously it should be[i] exactly[/i] the same for FS9 and FSX at the Client end. [b]You don't need to run FS9 or FSX or even have the Server switched on[/b] to see whether there's any difference, because there can't be, not at the stage when Wideclient is looking for the Server! It can't guess whether there will be FS9 or FSX at the other end! OK. I see you are not quite understanding. WideFS is a facility for extending the FSUIPC interface to other PCs, not running FS, on a Network. That's all it is meant to do. The FSUIPC interface was devised in FS95 days, as FS5IPC, and in FS98 as FS6IPC. I made it universally apply to all versions of FS from FS98 onwards. FS[size=5][b]U[/b][/size]IPC provides an interface for applications to read and write things in FS. WideFS was added quite early on to allow some of the jobs done by such applications to be moved onto other PCs, to take the load off the FS PC and to allow distributed functions in the more complex cockpits. Project Magenta was the main need of this at the time with 5 or 6 PCs being optimum for its full operation. Microsoft eventually saw the usefulness of such facilities, and decided that they should be part of FSX, not be dependent upon a third party program like FSUIPC. In other words they were replacing FSUIPC and consequently also WideFS. They did discuss it with me before they did it, and I was looking forward to a nice returement -- or so I thought at the time. I made a version of FSUIPC (FSUIPC4) which simply interfaced TO SimConnect as a sort of bridge to FSX for all the existing FSUIPC applications, but confidently expected all new applications to use SimConnect directly, and for FSUIPC use to therefore wither away. The situation now with FSX is that SimConnect is used by many, but not all, of the newer applications, but most of the older applications are still going strong too -- probably because there's still around 50% usage of FS9, even after, what, nearly 9 years! Regards Pete

So if all the devices are handled that way, wouldn't it be best for users to stop FSUIPC scanning them all the time? Actually, although that was tested (i.e. no LINDA.EXE running) once, it was with an earlier test version of FSUIPC which had a bug in the extra bits, so it needs checking again with 4.811d. Derek, can you do that please? See if the crash still occurs with the Run command for LINDA.EXE removed from the INI file? No, there is no memory limitation as such, other than the 4Gb total process memory of a 32-bit process -- obviously all the Lua threads are part of the FSX process. And the fact that the crash doesn't hasppen when I use more logging -- specifically Lua tracing, with a message per line occurring -- which will use MORE memory, not less, realy indicates some sort of timing problem That the crash occurs in DINPUT.DLL, and only when using the FSUIPC options, is really weird. It smalls of a bad device driver or a clash.The only think different about entering/exiting the FSUIPC options (i.e. where it is crashing) to its normal device scanning is it closing and re-scanning of each of the DirectInput devices it is using. Apart from the options, the only other time it does these things is on initial loading -- before LINDA is running -- and on closing FSX. The constantly changing values which Derek sees in the FSUIPC axis assignments dialogue is rather odd. Is this likely to be LINDA or something to do with one of the devices, like the Leo Bodnar boards? If only I could reproduce it here we might make some progress. But the fact that Derek seems to be the only one with the problem is pointing rather to a special combination of things which is going to be difficult if not impossible to recreate sufficiently well. Regards Pete

Giving up so easily? I can still look at those two files if you wished. And, I strongly disagree with your FS9 / FSX comparison, but the choice still remains, luckily enough. ;-) Regards Pete

The Leo Badnar cards, connecting through USB, look like regular joysticks with up to 8 axes and 32 buttons, so FSUIPC's buttons & switches tab will see them easily and you can assign there. There is a selection of assignable controls in the dropdown for manipulating FSUIPC offsets -- set, clear, toggle, increment, decrement, etc. Please check the documentation. There are examples too. All the offset control names start with thr word "offset" so easy to find. When opening the drop-downs just press "o" to get to the 'o's' -- or even "o f f" in quick succession. The offsets available for general use are x66C0 to x66FF inclusive. And you use them by assigning to the offset controls. Please check the documentation about this. There's at least one example in the User Guide. Pete

Ah, yes, because it ia axis "Q", the second POV not "P", the first. Sorry. The recognition of POVs as as set of 8 buttons, 32-39, derives from original FS98/2000 practice, and in those days only one POV was recognised by the system in any case. Glad you sorted it out with the correct controls in any case. Regards Pete

And you said: That is very very disappointing. It is most certainly not a problem with simultaneous calls arriving in DINPUT.DLL from FSUIPC -- the varios parts are now linterlocked. So it is starting to all point to whatever it is that Linda.EXE program is doing. I find it's role in this completely mystifying -- like why is it necessary to have that separate process running in order to use the joysticks? No, it most certainly is not! That sounds like part of the problem. Does it stil happen without LINDA.EXE running? If so it is faulty hardware -- bad joysticks or connections or maybe drivers. If removing LINDA.EXE from the equation stops that then the question in as above only more so -- what on Earth is that process doing? Does it happen on all axes? (Use the "ignore" option to work through them). Regards Pete

Sorry, but i'm completely bemused by what you are wanting to do here. You are using the POV as an Axis but mapping it to keystrokes? Why such a complex round-about method? First, the FS keystrokes are merely mapped to FS controls -- Zoom in and Zoom out. Just assign to the controls directly. Second, FSUIPC can treat the POV as a lmited tyoe of axis, or as a set of buttons. If you want to use the Zoom In and Zoom Out controls it would be far far easier to assign the POV in the Buttons tab, directly to the correct controls. If you did want to use an axis for Zoom, then consider using the View Zoom Set control instead, as a direct axis assignment. That's a little more complicated as you'd need to scale the axis input values suitably to get a decent zoom range. There's another recent thread about that here inn the Forum somewhere below. BTW you can always find out what controls to use by using the Event logging facilities (FSUIPC's Logging tab), operating the facilities on screen or with the keyboard, and seeing what gets logged. You can even do that in real time by enabling the console log window, and running FSX (temporarily) in a smaller Wndowed mode. Pete

It's starting to sound like a hardware problem. That's correct, isn't it? Why mention it? Paste them into a message is best. You mean it timed out. Both ends operate a timeout -- WideClient expects to here from the server at least every few seconds, otherwise it will re-connect. the Server expects to hear from each client every 20 seconds or so, otherwise it assumes it has gone away, switched off or something. It would be waiting for a reconnection. There's nothing timewise which can cause this in WideFS. I have a cockpit system with 8 clients and it runs all day with never even a reconnection let alone a failed connection. Something is going very wrong on one of your PCs. See if it runs longer without the wireless connection also running. If so it might be something to do with having two parallel TCP/IP operations going on. I think you'll need someone who knows a lot more about networks than I to help sort that out. Regards Pete

I don't think any of those are real errors or crashes. It looks like some add-on your are running (not FSUIPC4) is doing a manifest probe to detect the version of Simconnect to connect. I used to do that with FSUIPC as well, but changed a couple of years ago to a direct connection, by-passing the Side-by-Side connection which produces such spurious entries which otherwise occur if you want the software to work with more than one version (i.e. FSUIPC works with RTM, SP1, SP2 or FSX, plus ESP and Prepar3D versions of SimConnect). However, seeing that, it may well be that one of the other Simconnect clients is causing the clash and resultant crash. You should do a process of elimination of the other add-ons you are running. There should be an entry in the Applications event log for the crash itself. It will state FSX.EXE as the process and give you the module name, the code offset, and the crash code. None of that information is provided in the case of a specific library version not being found. this reminds me. Remember way back at the beginning I suggested this: "Maybe a SimConnect log will show something -- see the FAQ thread on that." Did you ever get around to getting one of those? Regards Pete

I don't think I'll be any better. It isn't my subject or my software. And why the SDK? You need just to install SimConnect on the client, not the whole SDK. Both are out of date. Current supported versions of FSUIPC are 4.81 and 3.999. not that its anything to do with your current query. I'm pretty sure that, like WideFs, SimConnect doesn't care at all about file sharing. It isn't relevant. Well those are the only relevant files, assuming of course that you've actually installed Simconnect on the Client. Have you? Why report that here? It isn't at all relevant to SimConnect. Why? WideFS doesn't use SimConnect, it is totally irrelevant. I can if you like look at your SimConnect ini and xml files, but it isn't really my job to support SimConnect. I don't mind trying to help, but i think you are really in the wrong place. Regards Pete

Yes, but if they were his current details they wouldn't have done any good in any case -- his current surname isn't listed at all as a purchaser. Regards Pete

There's something very wrong if it isn't visible. Certainly your original posted here, with the line numbers corrected, was visible. I don't think you've shown me anything else. Don't forget, if you change files whilst FS is running you MUST press the "reload" button in the relevant FSUIPC options screen to get it to re-scan your changes. Why is that? If you want to manipuiate FS options via menus it is by far the best and easiest way to do it! The Lua file, once in the modules folder, is assignable just like any macro. What is your fear? There's hardly any "digging" involved! What is so worrying? Look at the examples i told you about. Try them out - though maybe they need adjusting for a German menu. They are much less obscure than macros, I assure you! Regards Pete

Well, they are processed into tables for efficient execution internally, so if they are invalid thay won't be tabulated and won't appear. But the file you posted earlier worked fine, as I said. You will be lucky to get away with all that in a macro, because some of the keystrokes won't be seen in the menu. The best method for such things is to use Lua. The ipc library in Lua contains the "ipc.keypressplus" function which is explicitly designed for this sort of thing. See the two examples, "Fuel737.lua" and "Payload737.lua" in the Lua plugin examples provided in your FSUIPC Documents folder. Regards Pete

That's only because it can see the FSUIPC4.DLL in your modules folder. There's no other record it checks. Full installs are needed for folks who've not had FSUIPC before, or who have reinstalled Windows or moved to a different PC. It is also the only way to ensure you have the correct relevant documentation and other files to match that version. The individual updates, for interim versions, are just the DLL and a list of changes. Regards Pete

Every part, every character, MUST be exactly the same as was notified to you when you bought the Registration key. If you've lost that you can find it all in your account on SimMarket. I would recommend that you use copy and paste to avoid making any errors. I've no record of any purchase made in the name you are using here (at the end of the last message). So I've no way of checking. You only just asked, and I'm telling you! You must get the information correct. There's no alternative. You don't need to Register FSUIPC in order to use the Air Hauler. Registration only opens up all of the user options, it doesn't enable any add-on programs. Linking to your computer (which I wouldn't know how to do in any case) won't help if you don't know your name, email and key. Those are the only things you need. Get them off your other computer if they are still there -- they'll be in the FSUIPC.KEY file. Regards Pete

Sorry, why do you want to do that, and what's a sync point? Pete

Just download it, open the ZIP, then read the instructions you find inside. What else? Pete

Well, I tried your exact macro here, with the same names and numbers, and it sent all 13 keypresses okay. I've actually modified FSUIPC ready for the next version to accept 01 to 09 as well, and that works too. How are you telling where it finished? Are you logging Keys and Buttons? I don't know what the sequence is supposed to do (I've not examined the actual keystrokes), but if you are trying to invoke an FS menu and then operate within it you will probably have to use a Lua plug-in instead of a macro, as when the FS menu takes over any keypresses not already in the keyboard buffer will not be seen by the dialogue. FSUIPC is effectively frozen until the menu dialogue exits. Lua plug-ins don't have that problem because they run simultaneously. There are some examples of menu-operating plug-ins in the set supplied and installed with FSUIPC. Perhaps also you ought to tell me what version of FSUIPC you are using, as it might be different to mine? The currently supported versions are 3.999 and 4.81. Regards Pete

The details will be in the Windows error logs. In Win7 just go to the Start button, enter "event viewer" and press Enter. In the display window that comes up the Windows Logs entry will contain the error details in the Applications folder. Search for the relevant event which will be an error with a red exclamation icon. You can double click it and copy the data for pasting back here. I've moved on since 4.811, so if the crash is in FSUIPC the module address wil be wrong. The current update is FSUIPC4811d. It changes almost daily whilst I'm helping someone else solve a problem with LINDA and the PMDG NGX. Regards Pete

Instead of doing that, I'm trying something else. I'm assuming that the problem is that two things are calling the DirectInput functions in Windows at the same time, or close, and that the routines being called are simply not re-entrant so get themselves in a mess and crash. To prevent this I've put interlocks on the three routines in FSUIPC which perform such access. Please download 4.811d and try that for me: FSUIPC4811d Regards Pete

There are lots of solutions to this to suit different needs and it has been discussed endlessly here in the Forum. PMDG are just saying these things because it isn't their job to support hardware anyway and they don't want the hassle. The only known problem is how they handle throttles. Just assign in FSUIPC or FSX to the normal Axis controls (Axis throttleN set), and calibrate in FSUIPC with "no reverse zone" set and "UseAxisControlsForNRZ=Yes" set in the INI file (see the FSUIPC Advanced User's manual for explanations). You can get reverse by programing the button on the Saiteks as discussed in many places. Regards Pete

Yes, so it is definitely some sort of timing-dependent conflict which is occurring. They are extremely difficult to nail -- the very method I used with the Lua tracing to determine which Lua library action is responsible evidently slows things down enough to avoid the conflict. I'm going to have to think about how i can get more information again. I could of course simply stop (suspend) all HID and Joystick device interaction in Lua whilst FSUIPC options are active. However, this would then prevent some of the flexibility Lua programs have of interacting with menus, virtual buttons, and joystic calibration, which would be a shame. You said that without anything in the "actions.lua" script the crash no longer occurs. I've looked at that and it seems to be full of LVar reads and PMDG NGX controls sent, -- I don't see anything in there which might interact with devices at all, only FS innards, so really it shouldn't come into it. But maybe the device interaction there is hidden in some of the calls. I don't understand where the LINDA.EXE GUI comes into the equation. They said "Without GUI your joysticks programmed in LINDA will not work". This implies that the EXE is doing some of the HID or Joystick accessing. I need to understand that part, because that must surely be where this conflit is occurring. If it's in the FSUIPC Lua libraries, then I really do need to narrow it down to the Lua library function which is being executed at the time of the crash. I had hoped that Lua trace would do this, but it slows things down too much. I'm afraid that if I log all calls into the library functions the same might occur. But I'll take a look. Maybe a little more explanation about the run-time joystick role of LINDA.EXE would be useful, and perhaps some pointers to where in the mass of complex Lua code I might look to possibile clashes. They mention memory issues, but I really doubt that any problems of actual memory usage are arising -- after all the memory use with the tracing enabed would have been greater, not less. Regards Pete

I've already implemented it and tested it here, and it works fine -- quite efficient in fact. But I cannot release it until I have the legal part sorted. According to Ryan at PMDG it's gone up to big boss Robert Randazzo for his decision, but I think he must have referred it to his lawyers. Maybe they will allow, maybe not. I don't understand why there should be a problem, but I can't take the risk I'm afraid. I can't afford legal actions against these folks and extradition from the UK to the USA to sit in a prison for two years awaiting trial, as happened recently to another poor old man like me, just isn't something I would look forward to! Regards Pete

In the email accompanying the log you sent, you said: I've looked at the log which, had the crash occurred, could have been very useful, as it is logging the path through the assorted LINDA lua files AND, more importantly, probably, the NGX_AUTO file -- both of which appear to be running simlutaneously all the time. However, not only don't you get the original crash, but there is also no sign of the problems shown in the earlier log. i.e. the two trapped and logged crashes. Might odd, because I made no changes in that area. I tend to suspect that the Lua tracing is slowing down the execution of the Lua files sufficiently to prevent whatever clash was occurring. To check that, could you just revert to the previous value for LogExtras? i.e. LogExtras=x200000 just to see if it is indeed the timing, or something else has changed. Maybe, if it was, say, a corruption of something in memory, the recompilation with this extra logging has moved things sufficiently to make something else corrupt instead! Very worrying! Regards Pete