Pete Dowson

In that case there should be no problem. I can only think there is something wrong with the controls themselves? Pete

All SimMarket keys are obtained from your account on SimMarket. I have never had a key sent to me! The term "deleivered" simply means you need to go to your account to retrieve the details, and, for some products, do the download. Pete

What are you writing for 120.0? It should be just the 16-bit value 0x2000 There's no "string", so nothing to terminate. It is just a simple 16-bit value, a number, not a string! Pete

There's nothing which makes FSUIPC "run at too slow data transfer rate". It deals with inputs from devices when inputs from devices arrive. If all of your controls are "stuttering" I think you must have a problem with your USB system. Maybe you are routing them all through an unpowered hub, or similar? Try connecting everything direct to the PC. Many folks have said that, but when they checked the version number they were well out of date. Only version numbers mean anything. "newest version" means nothing. Pete

FSUIPC does not work properly in P3D2.2 (and could actually cause it to crash) unless you apply the P3D patch to get it up to build 10438. This is clearly stated in the top pinned thread in this Forum and in the download Links subforum where you will also find a link to where you can get the P3D update. Pete

FSUIPC is sending PAN_VIEW controls to FS at the same speed at which it sees changes, and is smooth here, just the same as when assigned in FS. Maybe your "delta" is set incorrectly? It should be 1 for a POV hat. The value is displayed in the axis assignment tab, and it's the first number after the axis name (i.e. the first number after the first comma) in the assignment line in the INI file's [Axes] section. FSUIPC will ignore changes in the axis value less than the Delta. BTW make sure you are using a current version of FSUIPC -- 4.934 is the oldest supported for FSX. Pete

I don't know VB at all, let alone VB.Net, but there must be a way of telling Windows that you want the current folder, the one which MakeRunways is normally run from, is the main P3D install folder. It needs to be there because that's how the program works out how to get to the correct Scenery.cfg file. The Windows API function I use to run programs is CreateProcess, which is defined as follows: BOOL WINAPI CreateProcess( _In_opt_ LPCTSTR lpApplicationName, _Inout_opt_ LPTSTR lpCommandLine, _In_opt_ LPSECURITY_ATTRIBUTES lpProcessAttributes, _In_opt_ LPSECURITY_ATTRIBUTES lpThreadAttributes, _In_ BOOL bInheritHandles, _In_ DWORD dwCreationFlags, _In_opt_ LPVOID lpEnvironment, _In_opt_ LPCTSTR lpCurrentDirectory, _In_ LPSTARTUPINFO lpStartupInfo, _Out_ LPPROCESS_INFORMATION lpProcessInformation ); The parameter "lpCurrentDirectory" provides the path in which the program is to think it is executing in. for MakeRunways this must be the main FS or P3D folder. Regards Pete

PMDG products for FSX have nothing whatsoever to do with FSUIPC and there is no way one will interact with another. You must go to PMDG support. Pete

This is a facility i remember very little about, and i've never been a helo user.. So let me first check things according to the documentation. First, the usual essential information, missing in your question. Is this with FS2000, FS2002, FS2004, FSX, or P3D, and which actual version of FSUIPC? And "HELI" is the current Profile? Is it only pitch trim you want, no bank trim too? If so, is the elevator axis calibrated through FSUIPC? The facility only adds the value to the current control axis -- elevator or aileron, as appropriate, and sends it on to FS accordingly. Well it could hardly not do so, as it is write enabled.. 3338 is a read-out, not a value you write to. Is offset 0BC2 zero ? That's the elevator trim indicator, and the place used by FSUIPC. And how are those functions called? Have you tried using logging to see what happens to the elevator axis? FSUIPC logging tab, axis event logging. The parameter for the axis named "KEY_AXIS_ELEVATOR_SET" should have whatever value you have in offset 0x0BBE subtracted from it. This will occur whenever the elevator axis changes, or 0xBBE is written to. The axis value used is the one from offset 0x0BB2. (If that offset is written to, the same adjustment is applied). Pete

Don't PMDG provide any information to help? I'm afraid any aircraft which is programmed to do all these things outside of the standard FS systems is only usually accessible through devious means -- FSUIPC does provide ways of finding out and maybe accessing things differently. For information OUT of the aircraft (as opposed to control of parts of the aircraft), really the only likely area is the use of the facilities in the Lua plug-in functions to obtain the values of "L:Vars" (local panel variables). You could investigate those using the FSUIPC assignable control to log lvars, or the more comprehensive sample Lua plug-in installed for you which also logs them, but in real time, i.e. as they change. However, not all aircraft implementations use local variables. It depends on how they are implemented. Pete

Sorry, I don't really understand any of this. Have you tried using FSUIPC's logging and monitoring facilities for the offsets? Does the helicopter react to the controls or values you are using without worrying about a Lua plug-in? You are lucky I answered this -- the thread title is about FSUIPC version 4.1 which is long unsupported. Please start new threads for new questions. Pete

There are no offsets for the PMDG 777. It doesn't use FSUIPC and there's no implementation similar to the 737NGX to map the values from its Client Data, if indeed it supports that option. Pete

First of all, you are very much out of date with version 4.86. The currently supported version is 4.934. Please update if you want support as I cannot support old versions. Second, FSUIPC's assignments and facilities obviously won't be available to you if you get such an error and respond "No" to the question "do you want to run this software". If you do run it and it does get loaded, then it NEVER forgets the assignments and settings you made -- they are stored in the FSUIPC4.INI file in your FS Modules folder, and would only ever be lost if you deleted that file. Third, if FSUIPC is being loaded there will be an FSUIPC4.LOG file generated each load in the FSX Modules folder. Please check. If it is there and you still get nothing, show me that file. If FSUIPC is not being loaded at all then the problem is probably the well-known SimConnect timing bug. Please see the FAQ subforum for several threads about this which give further help. Fourth, when Windows does show and error such as the one above, it will have an entry in its application logs. Please use the Windows event viewer to find those details and tell me what they say. but ONLY with the latest FSUIPC version, please, not an unsupported old version. If you have mixed assignments between FSX and FSUIPC this means you have not disabled controllers in FSX, and FSX will therefore often make automatic default re-assignments whenever it thinks that the controllers are reconnected or new. Unfortunately it seems this happens not infrequently with Saitek gear, which seem to give problems for many. As far as reassignment in FSUIPC is concerned, it is best to use the Joystick Lettering facilities to prevent changes in Windows ID numbers causing incorrect cross-assignments. There's a chapter about this in the User Guide. Pete

You aren't checking the content of the message? It looks like you are using an old version of WideClient, before this facility was added! Pete

The "event.textmenu" function is only available in WideClient. you have to place the Lua plug-in into the same folder as WideClient -- it will automatically run any Lua programs it finds in its folder. You can of course get FSUIPC to run WideClient automatically using a parameter in the INI file's ]Programs] section. You will need to specify the PCs IP Address (or, better, name) and Protocol=TCP in the WideClient.INI file, because the automatic broadcast reception won't occur on the same PC. The msgs parameter is a table with n entries. If you want to read the first line you need to refer to msgs[1] not msgs, but first check that n > 0. Otherwise your idea sounds okay. Pete

GSX sends its messages direct to SimConnect. It doesn't use FSUIPC. Offset 3380 is only used by FSUIPC applications to display messages. There is a facility in WideClient which will divert GSX messages for use or display on another PC. The facility is by a Lua plug-in to WideClient. The details are in the Lua library document, see the event.textmenu function. There's a parameter needed in FSUIPC4's INI file too -- it is all described there. If necessary, you can run WideClient on the same PC as FS by setting its "ClassInstance" parameter to a non-zero value. (Of course you need a WideFS registration). Pete

Reading messages? From what programs? Offset 3380, along with the control at 32FA, is for FSUIPC application which wish to display messages on the FS screen. It isn't capturing FS's own messages -- or at least, it certainly isn't doing so in FSX or P3D. I don't know VB, but the code fragment you included in your post seems to be trying to read the control value at 32FA as 128 byte message when, in fact, 32FA is a 2-byte control value for the application writing the message. I think you need to refer more to the Offsets lists and descriptions! Pete

Yes, use "event.offset" for the offsets giving you the user-operate control positions (not the A/P controlled values of course) -- look around 3328-3338. Those are the control inputs which are prevented from going through to FS. Pete

Add-on replacement avionics systems like Project Magenta, SimAvionics and ProSim737 do such things already. You could do it with a plug-in, using some reasonably simple Lua programming. you'd need to work out the logic, then monitor the appropriate offsets and disengage when appropriate. I guess the same would apply to autothrottle too, when, for example, the throttle levers are moved manually. I expect the more sophisticated add-on aircraft will also do these things already (PMDG especially?). Pete

Apart from the worrying intrusions of the "Axis flaps set" controls, it mainly looks like it isn't calibrated. With a different way of assigning you need to Reset and re-do the calibration properly. Pete

And? What did you see as a result? It looks better, but I can't analyse it without knowing what I'm looking for! Did you re-calibrate afterwards? I think you'd need to. Something is still sending the occasional Axis flaps set control I see. Pete

YOU have something odd going on there. There are two different Flaps controls operating, AXIS_FLAPS_SET, and FLAPS_SET. I suspect the PMDG code is doing some preprocessing of the AXIS_FLAPS_SET control before FSUIPC sees it and calibrates the values. There are two possible ways to stop that. The first, and probably best (as it is far more efficient in any case) is to change the assignment mode to use "Direct to FSUIPC Calibration". This is more efficient because instead of having the control sent to FS to be intercepted by FSUIPC (just as if it were assigned in FS in the first place), it merely gets passed directly to FSUIPC's calibration routines. The removes two messages per change from the Windows message queue and also prevents the PMDG code from seeing the control first. The other way would be to assign directly to the Flaps set control in the first place, instead of the Axis Flaps Set control. This still means it would go to FS first, and so be just as inefficient, but would probably defeat interference by the PMDG code. The downside of either of these methods might be that the PMDG flaps don't then operate at all. I can't see that happening -- it depends how they've coded it all. But if this is the case you have no alternative but to leave the assignment as Axis flaps set, and cancel calibration (ie press the RESET button on the calibration option so it is no longer active). Pete

Oh dear. S8 = signed 8-bit byte, range -128 to +127! No use for any of the offsets being used, except maybe the handle index 0-8. The others are all 2 byte, or 16 bit, so an S16 type would be correct. I'm afraid your log is useless again. :-( And the reason the log is so big is that you are logging the current flaps angles as they are changing. They aren't relevant -- we are trying to track down the control input jumping. Just monitor 0BDC as S16 0BFC as U8 for each of the flap notches, with the axis and event logging still enabled. Pete

Well, the assignment method is a little deeper than I needed. I just wanted to know if you assigned in FSUIPC and if to by what method and to which control. The log is unfortunately no use because you haven't monitored the offsets as I requested -- see the right-hand side of the Logging tab. Pete

All throttle quadrants are alike as far as FSUIPC is concerned. They are just a collection of levers inputting hopefully nice smoothly changing values into FS. After assigning each axis in whatever way you wish (in FS or in FSUIPC, it doesn't matter), just calibrate each in turn, following the numbered steps in the FSUIPC user guide. Do this first with a default aircraft, as some of the more sophisticated add-on aircraft need special care. If you want more specific assistance you will need to be more specific in your questions. You will also need to state things like the version of FS you are using, version of FSUIPC, and aircraft being dealt with. Pete