Leaderboard


Popular Content

Showing content with the highest reputation since 01/24/2017 in all areas

  1. 1 point
  2. 1 point
    NpCmoveAircraft is a Lua script in the Numberpad Control family of FSX scripts that can be used to move an aircraft to a new position. Each step includes prompts for the required input and format. User inputs include: The distance to move (NMs) The direction to move (degrees magnetic) The desired altitude (ft) The desired aircraft heading (degrees magnetic) The desired aircraft IAS (Kts) and landing gear position -- up (u), down (d) or fixed (f) Or - For any of the five inputs the user can simply enter a carriage return (Enter key) to signify No Change for that particular entry Prior to the move the aircraft can be on the ground or in the air. So, for example, NpCmoveAircraft can be used to simply turn an a/c around, move it to the other end of a runway, reposition it for another approach after landing, jump ahead in cruise, catch up to another a/c, etc. NpCmoveAircraft works with default FSX aircraft and many add-on aircraft that adhere to the standard FSUIPC offsets. A registered copy of FSUIPC is required to execute the NpCmoveAircraft Lua script. Simply copy the script to the Modules folder of FSX and use FSUIPC to assign a ‘hot key’, button or switch to activate the script. NpCmoveAircraft.zip
  3. 1 point
    Whatever you do, don't release it on Tuesday. "Bad Santa 2" get released on DVD Tuesday and I do not think I can take that much excitement in one day. I'll have to keep my glycerin pills handy :) RickyJ
  4. 1 point
    Your teasing us again, arnt you.:-)))) Russell
  5. 1 point
    Volker, Thanks for your effort, but as stated by BBQSteve these settings were no problem until this revision. My question was merely why that's the case. In the previous revision the map would take over focus in 2 situations : - A waypoint of the filed flightplan is reached - The autodownload takes place Now the focus seems to be also happening when the map simply moves in order to center the aircraft (that was definitely not the case before) I am beginning to think that the way it worked before was actually a 'bug' :p Anyway thank you for your time and support, at least I know what causes my 'problem' Thibault Dosunmu
  6. 1 point
    Hi, the easiest way is to check both combined: - 0x3365,1 if is in "Menu or Dialog" or 0x0264,2 if FS is paused - if so stop reading any other values In case any AC is different just calculate the volume with the % level, works very precise. But I actually don't know if Paul implemented a helper class for that, the other way was always easy enough. Thomas
  7. 1 point
  8. 1 point
    Just to clarify something about the P3D startup crash which is the main thing which folks are concerned with. Some folks are saying it was all okay in version 4.959 and want to go back o that. but if you refer to this thread http://forum.simflight.com/topic/82599-crash-loading-p3dvhttpforumsimflightcomtopic82599-crash-loading-p3dv34-reporte-fsuipc4dll34-reporte-fsuipc4dll/ you'll see, especially if you skip the first few messages which were different, that it was 4.959 which had the strt-up problems with P3D. It's a long thread with a long list of test releases going from 4.959a to 4.959m. The "m" version seemed to fix it for folks then, and it wasn't long ago. A couple of fixes to prevent LINDA crashing (due to a bug in LINDA now fixed i understand, to version 4.959p, it was relabelled 4.960 and released. The change between 4.960 and 4.961 was a minor one, to put the OOMcheck into its own thread to prevent a small stutter every 10 seconds when Windows was asked to tot up the memory blocks. It was also announced to support P3D3.4.22 which was released the same day, though in fact 4.960 already was 3.4.22 ready. So, i cannot revert back to 4.959 level as it will re-introduce the problems which have been fixed with a lot of blood sweat and toil. Well, maybe not blood. The only conclusion we can reach is that there's more than one cause for the P3D startup problems. I am pretty sure it only occurs if the preceding otherwise good session crashed on exit, or even hung as some have reported, Identifying what might cause that is the focus of my work on this. it isn't easy because it isn't crashing or hanging withing FSUIPC. As the log shows, FSUIPC is long finished and gone -- unloaded even. So if FSUIPC is causing it, it must be something it did whllst it was still there, even though nothing went wrong during that time. With the original problems it seemed mostly relating to the way Lua plug-ins were terminating or being killed, so most attention was focussed on that area and I now believe that's a good as it's going to get. So it's somewhere else. Since I can't reproduce the problem, and nor can Thomas, I'd like volunteer user testers please, to try experiments and gather information on the resluts. Those willing and able to help and who can definitely reproduce the problem (crash or hand on exit, mainly. There's no way for us, outside L-M, to debug the crash on start). please drop me an email: petedowson@btconnect.com. I'll post this as new new pinned thread too. Pete
  9. 1 point
    The log is fine and shows FSUIPC is working okay. Sorry, I've never heard of a bug where SimConnect doesn't pass on the menu selection. It isn't a function of FSUIPC, and most definitely not calling simconnect end when you close the system cannot in any way affect anything before you close the session. I can only think that the window is coming up behind. try using Windowed mode. If that works then it's a video driver problem. What else have you changed? Something, evidently. Pete
  10. 1 point
    Oh dear. Do NOT trigger it at all! It needs to be pre-loaded and actually running! It will get the button release by itself when it happens! If you want to start it for testing changes without reloading FS to make the [Auto] trigger, just assign "Lua <name>" to a spare keypress combination. When you make a change and replace the file(s), reload them by using the same keypress again. Check the FSUIPC log for any error reports. Pete
  11. 1 point
    Ah, 10 seconds is a good clue. There's nothing requested from SimConnect which is that long an interval. Try disabling the OOM checking. That asks Windows to supply the free memory and the maximum free block every 10 seconds. You can change that using the "OOMcheckInterval" parameter (it's in seconds), or disable it altogether using "OOMcheck=No". The only other one is the broadcasts by WindeServer to tell clients it is there. You can turn that off in the [WideServer] options with "AdvertiseService=No". If you don't use WideFS that won't be happening anyway (and your default INI won't have it enabled in any case). Pete
  12. 1 point
    Sorry, then. It works perfectly here. I don't know where to start working out what is different there. I'm tired and exhausted. i've been trying to do too much today. It's no good at my age. If anything occurs to me tomorrow i might have nother have a look, but my first guess is that you are still running the old version, as nothing has changed it at all. That makes no sense. You need to replace it and restart WideClient. Pete
  13. 1 point
    Hmm. I must still have an error there somewhere. I'll have a look when I get time. Sorry, I have much bigger problems to sort out first. Pete
  14. 1 point
    The Lua package for FSUIPC and WideClient is installed automatically for you in the FSUIPC Documents sub-folder in your FS Modules folder. It consists of the general introduction to the FSUIPC Lua facilities, a reference guide to the FSUIPC added library functions, and an extensive set of examples, some useful right out of the package. In this post you will always find the latest update, which will often be more up to date than the one installed automatically for you. Download it here: Lua Plugins Package This now contains: * the LuaFileSystem (lfs library) documentation * the new display library for WideClient * details of the gfd WP-6 and DIO facilities * the terminate event. * the ext library for handling external programs and windows--now extended with Shell, Keys and Message facilities. * the mouse library. * the new wnd library, for WideClient only * wideclient ButtonScreen functions ipc.setbtncol and ipc.setbtnstate * ipc.setowndisplay for speparate named, positioned and sized displays for each plug-in (FSUIPC only) * event.Lvar for monitoring named gauge variables (L:Vars). * ipc.SetFriction and ipc.RestoreFrictions, for manipulating SIM1's frictions in FSX/P3D * DynamicFriction.lua example added, courtesy Bob Scott. * Colour (red/white) parameter for the ipc.display function * event.textmenu for intercepting application screen text messages and displaying them locally, and also for displaying copies of application screen menus locally. (FSX SP2 and Acceleration only). * A full set of mouse events in the event library, with an example "mrudder.lua". * com.gethidbuttoncount for FSUIPC4 and WideClient * wnd.bitmap for displaying bitmaps (WideClient only). * event.offsetmask for events on bit changes within offsets (not FSUIPC3) * ext.hasfocus for testing which program has the current focus * ipc.get and ipc.set operate across the WideFS network (on the one workgroup) (This needs WideClient 6.999z1 or later and FSUIPC 4.958 or later) For FSUIPC's Offset references, if you don't need the whole FSUIPC SDK, the offsets documentation is included in these two PDFs: FSUIPC for Programmers (the offsets list is at the back and applies to FS9) FSUIPC4 Offsets Status (applicable to FSX, ESP and P3D) If you are interested in using the USB / HID / Joystick facilities you may find this little utility helpful too. It scans your USB connections and lists lots of details for attached HID devices: HidScanner Have fun! Pete