Pete Dowson

And the answer is the same: Yes, but you'd need to do it by editing the INI file. You can have almost any nuer of lines referring to the same button action, and they are all obeyed in the order of their entry numbers, but the Options Dialogue only allows one assignment to "press" and one to "release". I'm not sure how having one button send two signals will help, but if it does you already have the answer, and it most certainly is the same question -- I cannot distinguish between having "two signals to the sim from one button input" from "two or more mouse macro actions to one joystick button input". Mouse macro assignments and all other assignments are just assignments, listed in the INI file, and as I've said, three times now, you can have multiple assignments to one button. Yes, you could do, but you'd need to use conditional actions based on flags. You'd set a flag when a button goes off (released" which is tested by the button assignment either side to decide whhat action to sdo on a "press". The "press" action for each position wuold depend on which button was just released -- the one to the left or the one to the right. Again this is by INI file editing. Details of conditonal actions and button flags are given in the documentation. Regards Pete

Can you please report this to Lockheed Martin support. There's no change in FSUIPC -- only the Installer needed changing. L-M will need to work out what is going on. It will be something in SimConnect. (In any case I can only make one install of 1.3 so I cannot even test that multiplayer.mode). One thing you could try is removing the SimConnectP3D.DLL file from the P3D Modules foder to force FSUIPC to use the ESP one installed by L-M in the Windows WinSxS folder. But I doubt it'll change as the DLL is merely a wrapper for the calls into the SimConnect-proper part of P3D. Regards Pete

No, sorry. The only thing which might work is to change the AI traffic density -- and in fact it is normally the AI which slows things down near airports. The drawing of the buildings etc may cause a slight stutter, but it shouldn't normally reduce fps much. It is the traffic which does. Yes -- in fact many of the things we could do in FS2000 gradually became impossible, or at least more difficult, as MS re-wrote parts using "object oriented" programming. Everything then gets hidden in black boxes. Regards Pete

What do you mean "incrementally"? Normally, with an axis for this, you'd use it continuously, not incrementally, with a "down" or "stowed" region (at one end), and an "Arm" zone. Then the rest continuous to full flight or ground detente -- FSUIPC offers "Arm" but not a separate "Flight" detente. Don't forget to reverse the axis ("REV") before calibrating, and get into the air before attempting to calibrate, because FS has the habit of deploying full speedbrake if you operate it on the ground. Regards Pete

Sorry, I don't have archives of minor versions and even if I did it wouldn't tell me anything useful because the record of changes is cumulative. Thre resolution of changes is as per the History document which you can see for yourself., Honestly, I can only work with information, and only RealityXP can say what the error from their program actually means. It cannot actually mean what it says. Regards Pete

I think it was -- I did try it once. But I can't check again now because I moved on to AS2012 which is Simconnect-only. Regards Pete

Yes, I wasn't trying to stop you, only saying that it perhaps isn't something to get overtly worried about ... yet! ;-) And, yes, I see it could be useful for other expansions of the Lua capabilities, so I hope you get it working satisfactorily. Regards Pete

I moved your support question to the Support Forum, else you'd get no answer. The "codes" you are talking about are FSUIPC offsets. Do you want FS controls or are you writing to offsets? If you are trying to control the DME sound then offset 3122 is okay and works fine, Just toggle or set or clear bit 1 (value 2). Or why not simply assign to the FS control -- DME Sound Set, or DME sound toggle? Pete

Okay. Let me know if you need help on the Lua/FSUIPC side. Also note that I am still hopeful that FSUIPC4 can provide direct offset mapping for all the PMDG 737NGX data. The facility is already programmed. I am only waiting for PMDG's okay, because of the worrying EULA. Regards Pete

But the "parent" is FSX, the same parent as for FSUIPC and all of its threads and all of the Lua threads. A function which starts a thread does not have to keep running. That would make threads useless. And, as i said, the collection of library functions which IS the DLL must still be ready and functional because it is passing back links to other functions within it to the Lua part. DLLs are simply run-time linked libraries, no more. The "CreateThread" function itself, which you call to create a thread, is in a Windows DLL and the thread it creates doesn't "die" just because the CreateThread function exits! Static libraries are the same as DLLs but linked at compile time and loaded with the program rather than later. If what you say happens really happens then no one could ever use threads! So, I think you are misinterpreting what is happening. Or maybe it's to do with these parts here: boost::thread thrd(startThread); thrd.detach(); [/CODE] which I don't understand as I don't know what they do. Maybe you shouldn't "detach"? What does that do? I only use the standard CreateThread function for threads. I don't use C++ so i don't understand this "boost:: ... " business I'm afraid. Regards Pete

Where are you seeing this? Do you mean the INput numbers don't change on half of the lever's range? If FSUIPC sees no change arriving from the device (or its driver) then obviously it cannot do anything with it. It has no control over what comes in. If you mean the output FROM FSUIPC to the sim, then it's to do with your calibration or other settings. If that's on input then it is your device or its driver. If you mean on output, then remember that "THROTTLEn_SET" controls only have positive values for forward thrust, negative means reverse, whilst the standard FS controls, AXIS_THROTTLEn_SET, only have forward thrust for all values, with -16384 being idle. I don't think it is the use of FSUIPC calibration which gives problems. the known problem is that it doesn't like THROTTEn_SET controls which FSUIPC's calibration normally uses. You can get around that by using the NRZ (no reverse zone) option, and setting "UseAxisControlsForNRZ=Yes" in the appropriate section of the INI file. You surely mean the option to send to FSUIPC directly. The NGX wants to see the FS controls I think. Ah, so was trhe first problem the Saitek registry bug? Pete

Yes, but you'd need to do it by editing the INI file. You can have almost any number of lines referring to the same button action, and they are all obeyed in the order of their entry numbers, but the Options Dialogue only allows one assignment to "press" and one to "release". That's surely the very same question as the first? The answer is the same -- yes, as above. Regards Pete

Sorry, I have no idea. Why is the child thread dying? Certainly FSUIPC's inbuilt Lua interpreter can know nothing about it. I think you need to try to find out what is happening with a debugger -- it must surely be to do with the thread code itself, which you don't show. Is it in a continuous loop, like a message loop so you get SimConnect messages? If it exits, it dies of course. The DLL cannot be getting unloaded on exit back to the calling Lua program because it is returning links to the procedures within it. So the DLL code is still in memory and the thread should be running. Regards Pete

As far as I recall, it isn't the Server you do anything with, but ASE. Just tell it you are using FS9. If you are running FSX's WideServer lives inside FSUIPC4. There's no change on the Server, and no difference between FSX and FS9 on he Clients. Pete

There's no "services" nor devices associated with FSUIPC whatsoever, unless it is referring to basic Windows serviices which you may have disabled? Otherwise I really don't know what you are doing as I've never heard of any such error message. Please refer to the thread about this in the FAQ subforum. Regards Pete

As you'll see from that other thread, the only ever other report of this problem was with 4.7xx. Please see what RealityXP says. Problems need to be fixed not by reverting to unsupported versions, but by working on a solution. Regards Pete

That product does not use FSUIPC and FSUIPC cannot stop another program finding a DLL, so I cannot see how that can be. Something else must be wrong, and rather than merely search for the answer why not report it to their support so that they can fix the problem? Incidentally, this evidently is not new, but rare. See this other thread where it was pursued at length, but never any answer from the RealityXP folks: http://forum.simflight.com/topic/70195 There's no way I can solve it without either the product itself or any involvement of RealityXP.. Please resport it to them and get some sort of response -- a reason for this strange error. Regards Pete

In that case, the only ways would be to use something like FSInterrogate (part of the FSUIPC SDK) to display things, or write a short Lua plug-in to read the offset, do the computation, and either display it or write it back to a different (user) offset for monitoring on screen. Regards Pete

Yes, the one that lists the longest match to its name. Don't forget you can shorten the names in the lists to a common sub-string, a part of the name which reliably identifies the type -- saves having enormous lists for different liveries. Regards Pete

Sorry, there's no way to do that in the way you state. You could make the common subset as one profile then generate the others using the "New, based on ..." option. Regards Pete

You might find more assistance with hardware building in the MyCockpits website, http://www.mycockpit.org/forums Regards Pete

Depends how you read it. In an Unsigned Byte, xFF is 255, in a Signed Byte it is -1. Unsigned values go from 0 to 255, signed values go from -128 to +127. Regards Pete

Good, hope it goes together well. Good flying! Pete

Sorry, I'm not sure what you are asking? Pete

It isn't a parameter -- if there was a parameter needed it woud follow a "," (comma) -- default mouse flag is 29 (left click). The "1" rather than an Xoffset value simply means it uses the mouse rectangle table and not an address from within it. It doesn't need it in that case. Why? Is there a problem? What programming are you doing to read it in the first place? Whatever language you are using should be able to divide by 128. I've not seen a useful language that cannot do arrithmetic. Regards Pete