Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. You might find more assistance with hardware building in the MyCockpits website, http://www.mycockpit.org/forums Regards Pete
  22. 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
  23. Good, hope it goes together well. Good flying! Pete
  24. Sorry, I'm not sure what you are asking? Pete
  25. 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
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.