Pete Dowson

Use the "Panel id toggle" (or the separate open and close) control, with the parameter equal to the ID of the panel. The panel ID is found in the panel.cfg file as the parameter "ident=" in the relevant [WindowN] section. I assume you are talking about the 2D cockpit, as the virtual cockpit doesn't work with specific views unless you do "pan sets" or whatever with specific angles. The view controls (View left, etc) are all "sticky". Normally the hat "off" action sends a view reset to reset the view to the front. All you need to do is program the 8 directions with views and not program the release to do a reset. Regards Pete

Sending by PM. Pete

None without seeing the logs. Sorry. Pete

If you are interested in following this up further (please?), I have added a lot more logging to FSUIPC in an interim version 4.292. This provides logs like this: 298687 Wind values set: 32.5 8.2 +0.1 [32.6 8.1 +2.0] 298734 Wind values set: 32.8 8.0 +0.3 [32.8 8.2 +2.0] 298797 Wind values set: 32.5 8.2 +0.4 [31.0 8.3 +2.0] 298812 Wind values set: 32.2 8.3 +0.5 [31.0 8.3 +2.0] 298875 Wind values set: 31.9 8.2 +0.6 [31.0 8.1 +2.0] 298937 Wind values set: 31.6 8.3 +0.5 [31.0 8.3 +1.2] 298953 Wind values set: 31.3 8.4 +0.4 [31.0 8.5 +1.2] 299000 Wind values set: 31.6 8.3 +0.2 [31.8 8.4 +1.2] 299062 Wind values set: 31.9 8.4 +0.1 [32.6 8.9 +1.2] 299062 Wind values set: 32.2 8.6 -0.0 [32.6 8.9 +1.2] 299094 Wind values set: 32.5 8.7 -0.1 [32.6 8.9 +1.2] 299156 Wind values set: 32.2 8.8 -0.0 [32.5 8.9 +1.6] 299172 Wind values set: 32.5 9.0 +0.1 [33.8 9.0 +1.6] 299219 Wind values set: 32.8 8.8 +0.3 [33.8 8.4 +1.8] 299281 Wind values set: 33.1 8.7 +0.4 [33.8 8.4 +1.8] 299297 Wind values set: 33.4 8.6 +0.5 [33.8 8.4 +2.2] 299344 Wind values set: 33.7 8.4 +0.7 [33.8 8.4 +2.2] 299406 Wind values set: 33.4 8.6 +0.8 [32.1 8.5 +2.2] 299406 Wind values set: 33.1 8.4 +0.7 [32.1 8.5 +1.1] 299453 Wind values set: 32.8 8.6 +0.5 [32.1 8.8 +1.1] 299500 Wind values set: 32.5 8.7 +0.4 [32.1 8.8 +1.1] 299516 Wind values set: 32.2 8.8 +0.2 [32.1 8.8 +1.1] 299562 Wind values set: 32.5 9.0 +0.1 [33.9 9.4 +1.1] 299625 Wind values set: 32.8 9.1 -0.0 [33.9 9.4 +1.1] 299625 Wind values set: 33.1 9.3 -0.2 [33.9 9.4 +1.1] 299687 Wind values set: 33.4 9.4 -0.3 [33.9 9.4 +1.1] Here the number on the left is the elapsed time in milliseconds, and the numeric columns after (which are tabbed) are: Direction (degrees T), Speed (knots), Vertical speed (knots) then in [] the three corresponding Gaussian-distributed (hopefully) targets. You'll see that the targets are recomputed whenever they are met OR when the smoothed wind changes enough to invalidate the previous target. this is done individually for the three components. You will find that although the speed or direction can sometimes change maybe by 2 or 3 units in a second, they do so via a number of smaller increments -- maybe 20 or 30. I think that's dependent upon frame rate. Maybe you are getting such a good frame rate that I am applying the increments too quickly, but i doubt that -- however, you would be able to see from this. Most certainly the increments used ARE affected by those turbulence divisor values, so they determine how fast things change. I don't really want to have to put time constraints in this as the computations are done "in line" between a call from the Weather module in FSX to the Sim engine (SIM1). All the results I get here are, so far, in accord with the way it was designed and follw guidelines on turbulence emulation I have stuied. they are also exactly what the expert in PMDG says would be right. Anyway, let me know and I'll supply a link to this version and instructions on enabling the logging. Maybe I should do some statistical analysis on the data and log that too, though I'm not sure what would be useful at present. You also will find it useful to use the FSUIPC monitor to display the actual ambient windspeed and direction on screen in real time (more accurately than the Shift+Z or ND wind indicators, but from the same values). Do this by Monitoring 2DE0 (direction) and 2DE8 (speed) both as FLT64's, and checking "FS window" (all this on the right-hand side of the FSUIPC Logging tab). Regards Pete

The files in the SDK cover FSUIPC3 and 4, and you don't actually need any source file for C/C++ as I supply a ready-built library for the interface. The source for the library is inside the SDK in a separate ZIP. Pete

FSUIPC 1 cannot load at all in FSX and has no chance of working. In fact I don't think it'll work in anything but FS98 and FS2000. You must install FSUIPC4 for use with FSX, you have no alternative at all. I'd like to know where you got FSUIPC 1 from in the first place. It hasn't been available anywhere for many years! I suspect that you are in fact using FSUIPC4 after all and just don't know much about what you are doing. Take a look at the options screen, or in the Log, or just right-click on the DLL and check Properties-Version. Certainly Project magenta will not run with FSUIPC 1 nor on FSX without FSUIPC4. Pete

Yes please, and leave PollInterval to default for now. Thanks! Well it might be the FSUIPC logging which has the major effect -- it is slowing the feed-in end. And presently, if it sees that Exception 2 from SimConnect, it turns on more of its logging whether you like it or not. Let's look to the future, with 4.291. I've sent another report to my contacts in Microsoft and will chase the underlying problem separately. Regards Pete

You do NOT use FSUIPC4 for FS2004 or before, only for FSX. The current version for FS2004 and before is 3.81. no other version is supported from versions of FS before FSX. If you are using FSX you must use FSUIPC4 as there is no way FSUIPC3 (or 1) will work on FSX. They mean exactly what they say, of course. They are in English. And you showed the code where they are set. Look: // create the file-mapping object m_hMap = CreateFileMapping( (HANDLE)0xFFFFFFFF, // use system paging file NULL, // security PAGE_READWRITE, // protection 0, MAX_SIZE+256, // size szName); // name if ((m_hMap == 0) || (GetLastError() == ERROR_ALREADY_EXISTS)) { m_dwResult = FSUIPC_ERR_MAP; this->Close(); return FALSE; } The "Failed to create a file mapping object" message is error FSUIPC_ERR_MAP, so the CreateFileMapping call to Windows failed, and the "IPC request contains bad data" message is the error FSUIPC_ERR_DATA from this code: if (dwError != FS6IPC_MESSAGE_SUCCESS) { m_dwResult = FSUIPC_ERR_DATA; // FSUIPC didn't like something in the data! return FALSE; } You should have easily worked all that out yourself. If you got the second error the most likely problem on the first is that you've tried to Create the same file mapping twice, so got "ALREADY EXISTS" returned. Pete

Maybe I can offer an explanation of sorts: So far, all the evidence, the logs I've seen, and all the investigation over the weeks, are all leading to one conclusion: that it is possible to overload SimConnect to the point where it corrupts data. I suspect that there is a cyclic buffer somewhere which is overfilling and trampling over data. In all the cases for which I've seen SimConnect logs for so far, the one common happening, a number of seconds before the hang/crash, is a failure like this: > 200.92873 [ 0, 8175]TransmitClientEvent:ObjectID=0, EventID=65764, dwData=-10402, GroupID=1, Flags=16 < 200.92882 [0] Event: Group=2 EventID=65764 Data=-10402 > 200.92885 [ 0, 8175] < 200.92886 [0] >>>>> EXCEPTION=2, SendID=8175, Index=0 <<<<< Unrecognized Data Received. [ 0, 8175] Here you see a command from FSUIPC sending SimConnect a valid Axis event (65764 happens to be "AXIS RUDDER SET", but it could be any axis). The line following is the confirmation from SimConnect that this was okay and accepted. But the next two lines show rubbish in the buffer that SimConnect is reading from -- the "8175" is supposed to be a unique sequence number, assigned by the SimConnect DLL when it sends the request to FSX (via Named Pipe or TCP/IP), but here it is the SAME ID as the previous good one! And it has no valid data, no actual request, associated with it. SimConnect (the part in FSX itself) rejects it with error 2, unrecognised data. Okay .... but thereafter things go from bad to worse ultimately hanging FSX. I have reported all this to Microsoft when I first analysed it, but so far no reply. Anyway, in one of the increments since FSUIPC 4.28 I added detection of the Error 2 and then automatically turned on lots of extra error logging. This was to try to see if it could possibly be anything i was doing. I'm guessing now that in your test with 4.287 this extra logging did get turned on, but it was self-defeating in that it slowed the SimConnect traffic up enough to either avoid, or seriously delay, the crash. This is one of the troubles with logging -- Heisenberg's Uncertainty Principle, you can't observe something without changing the outcome! :-( Anyway, in 4.291, with direct assignments to FSUIPC calibration, I'm avoiding using SimConnect events altogether EXCEPT for mapped axes (that is, for example, Throttles 2 3 and 4 when you pa 1 to 4). If I do what i'm doing for those I get FSX into a very tight loop, as I have to intercept the originals for axes which I'm supposed to be replacing. Hope this is clear? Regards Pete

FS provides separate fuel selectors for each engine, so it makes sense. "Fuel selector all" simply means setting the fuel selector, for the specific engine, to use fuel from all tanks. The fuel selector in FS switches tanks, not engines. Sorry, I don't understand what you are talking about here Fine, but I think in FS you have to switch each fuel selector to off with separate controls. There doesn't appear to be one which operates them all simultaneously. It doesn't matter so much -- if you always want to operate them together on one button, do as I suggested. Why, when it can be done as it is for the few who might need it? Has it? What is its name? It was the FSX list I referred to when you asked, and I didn't see it. Regards Pete

For FSX there's an interim update now available for testing: http://fsuipc.simflight.com/beta/FSUIPC4291.zip This uses an improved method for axis assignments routed "direct to FSUIPC calibration", avoiding SimConnect altogether, and by reports so far (it's only been half a day though) it is fixing problems folks have been having with SimConnect data corruption causing FSX to eventually crash. The change which might benefit those using multiple joystick axes for the same FS control surfaces is that this version does arbitrate for the maximum deflection when "direct to FS calibration" is being use. (It cannot do it for routing via FS controls because there's no way to add source data, differentiating inputs, that way). I think this will make the old method, of assigning extra axes to otherwise unused FS controls, redundant, at least for FSX. I may look to see if I can apply the same change to FSUIPC3, but no guarantees on that. Regards Pete

Test it on the default 737 autobrake first. If it works on that but not the PMDG one it means PMDG have implemented their own system. You'd either need to find the keyboard shortcuts for it, if any, or possibly see if the new FSUIPC mouse macro" facility works on that switch. You don't need to "restart FS2004" to test any assignments out, they should operate immediately you "OK" out of the Options. Regards Pete

Sorry, I've really no idea unless you tell me the name of the control you are using. For Mixture setting there is a generic one for all engines as well as individual ones for each of up to 4 engines. The mixture operates the starter idle/cutoff levers on jets. For props the mixture is either a true fuel enrichment/cutoff lever or a condition setter. Fuel selectors are for switching where the fuel comes from, not specifically for curtting off the supply -- that's always done with the mixture control. And you surely want a separate switch for fuel selection so that you can balance the tanks. There's no "switch all fuel selectors together" control (it wouldn't make sense, really, because you'd often need selector 1 set to tank 1, 2 to 2 etc), but in FSUIPC you can assign as many controls to the same button as you like. Best to program the first as usual, in the dialogue, then edit the INI file to add the others. They'll operate in the order you place them. The control numbers are listed in the "List of FSX controls" installed in your FSX Modules folder, and the format, if not obvious, is described in the Advanced Users guide. Note that once you have multiple or conditional assignments programmed in the INI you cannot again edit that button in the Options dialogue. (This is to avoid confusion and making a mess! ;-) ). Regards Pete

I suspect FSC needs direct access to your FS scenery library and so on to build its database. It would use ordinary file/folder sharing for that, not WideFS. Pete

Okay. I've modified it so that it still uses SimConnect but just for "mapped" axes (e.g. throttles 2, 3 and 4 when only using one). This otherwise causes a loop with interception followed by re-transmissions ad infinitum. Download this and try it, please: http://fsuipc.simflight.com/beta/FSUIPC4291.zip Please also still do the other checks I've mentioned in this thread. Thanks, Pete

Hmmm. No mappings, so I'm not really sure which aspect caused the loop -- but it will be something I missed, posting the control and intercepting it and re-posting etc. That's what was happening here. Anyway, I've worked through it logically and re-written the relevant part. I've re-tested all the combinations I've had time to do this evening and will continue tomorrow, but meanwhile maybe you'd like to try it. http://fsuipc.simflight.com/beta/FSUIPC4291.zip Regards Pete

Sorry I don't know it. You will want to talk to Eaglesoft support I think. However, I doubt if they use FSUIPC offsets if they've implemented their own A/P. I've still no idea whether you are talking about FSX or FS2004 or even FS98, nor which version of FSUIPC, so if you do come back for more, please do state a little more detail. Regards Pete

No, sorry, you misunderstand. Mapping isn't registered in the [Axes] section but in the [JoystickCalibration] section. I'm referring to the mapping of, for example, a throttle to 4 throttles, or Throttle 1 to 1,2 and 2 to 3,4, etc. All the mapping facilities are in the calibration section. you are confusing "assignment" and 2mapping". I cannot induce a problem UNLESS I set some mapping. Immediately i set mapping I get exactly the same symptoms as you. that's why I wanted to see your joysdtick section, not your Axes. Thanks, Pete

Whilst changing this might be an improvement, I think it's a red herring. I've managed to reproduce your symptoms -- by Mapping my one throttle to 4 throttles. Everything works fine but as soon as i do that, hang ... It looks like something I'm now doing is causing a loop when any single axis is mapped to more than one. I assume you have some? Perhaps you could show me your [Joystick] section parameters -- not all, just the section you use by default. I'll look at this later, after dinner. it may not be tomorrow till I have it solved. Regards Pete

Looks like it is in a tight loop repeating similar axis controlsI'm wondering if this is also what causes the problems for some folks with Simconnect. Look: 324477 *** AXIS: Cntrl= 65923 (0x00010183), Param= 16384 (0x00004000) PROP_PITCH1_SET 324528 *** AXIS: Cntrl= 65923 (0x00010183), Param= 16384 (0x00004000) PROP_PITCH1_SET 324578 *** AXIS: Cntrl= 65923 (0x00010183), Param= 16384 (0x00004000) PROP_PITCH1_SET 324628 *** AXIS: Cntrl= 65923 (0x00010183), Param= 16384 (0x00004000) PROP_PITCH1_SET 324679 *** AXIS: Cntrl= 65923 (0x00010183), Param= 16384 (0x00004000) PROP_PITCH1_SET 324729 *** AXIS: Cntrl= 65923 (0x00010183), Param= 16384 (0x00004000) PROP_PITCH1_SET 324779 *** AXIS: Cntrl= 65923 (0x00010183), Param= 16384 (0x00004000) PROP_PITCH1_SET 324830 *** AXIS: Cntrl= 65923 (0x00010183), Param= 16384 (0x00004000) PROP_PITCH1_SET 324880 *** AXIS: Cntrl= 65923 (0x00010183), Param= 16384 (0x00004000) PROP_PITCH1_SET 324931 *** AXIS: Cntrl= 65923 (0x00010183), Param= 16384 (0x00004000) PROP_PITCH1_SET 324981 *** AXIS: Cntrl= 65923 (0x00010183), Param= 16384 (0x00004000) PROP_PITCH1_SET 325032 *** AXIS: Cntrl= 65923 (0x00010183), Param= 16384 (0x00004000) PROP_PITCH1_SET 325082 *** AXIS: Cntrl= 65923 (0x00010183), Param= 16384 (0x00004000) PROP_PITCH1_SET 325141 *** AXIS: Cntrl= 65923 (0x00010183), Param= 16384 (0x00004000) PROP_PITCH1_SET Since the value in each case is the same (16384) is shouldn't really be continually sending them. I'm guessing that the raw value for this axis is actually jittering more than the Delta, and so feeding different values to the calibrator, and that is seeing them all in a dead zone and so setting the max (16384). Fine. but it looks like i am missing the final check that says "if I sent this before don't send it again". I'll check. Look out for another link -- I'll remove 4.289 for now. the next one will be 4.291. Thanks, Pete

Strange. It works fine here. The main difference is that it is simpler -- the axes sent "direct to FSUIPC calibration" are then posted directly to FSX without using SimConnect. It's much much more efficient, using much less processor and resources -- the same method was used in FS2004 and before. I haven't used it before with FSX because i was "trying to be a good boy" and use the "official" SimConnect routing. I'm at a loss at present. Have you anything to show me, like an FSUIPC4.LOG for example? Does it still lock up with your version of FSUIPC.INI not using "direct to FSUIPC" assignments? Pete

Sorry, the calibration part only sees one axis. the arbitration isn't there. you need reasonably matched axes, as you do with the other method. Pete

No idea what the "55X" is (is that an add-on aircraft -- for which, FS2004 or FSX?), but usually the VS will reset itself to zero if the altitude it is supposed to gain is the one already reached. You probably need to set a target altitude, then set the VS value. Not sure about the VS mode itself, I don't think the default A/P has more than one vertical mode, so there's not a lot of difference between FLCH and V/S -- you adjust the V/S yourself or leave it to the default (like 1800 fpm). If you really do mean a sophisticated add-on aircraft with its own autopilot, then you'll need to check its documentation for its way of handling things. I doubt that it takes note of default A/P values such as those supported by FSUIPC. Pete

Download this and try it, please: http://fsuipc.simflight.com/beta/FSUIPC4289.zip It has the arbitration i mentioned. It also avoids using SimConnect for direct-assigns, so hopefully it won't cause other problems. I'll not release it formally till I know. Thanks, Pete

I've made a version of FSUIPC4 which avoids using simConnect altogether when you assign axes in FSUIPC for "direct to FSUIPC calibration". I'm hoping that this will stop these crash/hang problems, but since i've never been able to reproduce them I cannot tell. Download this and try it, please: http://fsuipc.simflight.com/beta/FSUIPC4289.zip Sorry, temporarily removed whilst I sort a potential hang out with Mapped axes. Look out for a link to 4.291 in the next 24 hours. Please also do the other checks I've mentioned in this thread. Thanks, Pete