Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. I'm sorry, but the whole reason I implemented the Lua plug-in system was precisely to make this sort of expansion possible without continually impleneting new facilities in FSUIPC. Pete
  2. Really? Sorry, I didn't know that. How unique! So with three separate ND indications for the three, or preseumably 1+ILS one side and 2+ILS the other, rather than the more usual (for Beoing at least) both sides being able to select either as well as ADF1 and ADF2? FS itself doesn't actually handle such a configuration. So really what you want could only be done if such a method was provided by the makers of that model. Wasn't there some other package which provides an FSUIPC interface for the Level-D package? Pete
  3. Problems with the X-55 and X-56 series were fixed several FSUIPC releases ago, and certainly in the current versions, 5.112 or 4.971, which are the curren supported versions. What version are you using? Generally everything works best if there is NO Saitek software running at all. Best to uninstall it, then uninstall both X-56 units in Windows Device Manager -- including drivers when the option is offered -- then re-boot and let windows sort it out. Pete
  4. Where are you seeing that it is "not reading any values"? If part of the axis movement gives no change to the INput values, then there is no part of the actual axis there. The Saitak throttle quadrants are like that. The reverse area is marked in red, but pulling back there just presses a button. Users assign that butto to F2 to engage reverse thrust when pressed (with repeat enabled), then to a control to set idle thrust again on release. Pete
  5. Oh dear. Did you not see that 3110 is 8 bytes, not 4? ProSim can only write 4 bytes (=32 bits) at a time. 3110 + 4 = 3114. These offset values are NUMBERS, you can use arithmetic! (But take care, they are numbers in Hexadecimal, not Decimal, so counting 0, 1 , ,2, 3 .... 9, A, B, C, D, E, F). The description of 3110 covers the whole 8 bytes, TWO of your 32-bit U's), 3110 and 3114. With a normal program using these, they would both be written together, as one block of 8 bytes. If you write them separately, as you are forced t, then 3110 must be second because when FSUIPC sees that change it triggers the action with whatever parameter is in 3114 at the time. No. The x just means "hexademinal" instead of "decimal", that's all. The control number must be the parameter sent. I don't know what ProSim is writing to those offsets. If they are only Gates they are probably only open or closed, so I assume it will write 0 or 1. I don't know if there's a solution with ProSim. You'd need Prosim support for that. I suspect you will need to use a User Offset and use it for an event in a Lua plug-in to send the control which generates the keystroke. Pete
  6. As I said, THERE IS NO SEPARATE "ILS" COURSE AS OPPOSED TO THE VOR OBS. THEY ARE ONE AND THE SAME! There is absolutely no need for two separate values, and no aircraft I know of has such. The frequency is either ILS or it isn't, so the same course setting suffices! Those two controls for INC and DEC are all there are and all you need. Pete
  7. Thanks Hervé. So it will be included in at least the Runways.txt file from MakeRwys -- probably one of the XML files too. But not easily accessible in the Sim. Pete
  8. No. It will be a while yet. There might be a way of doing it which I have to research, but I won't have time for some weeks even to start the research. It will be stated in the Changes document, or here in the Updated Modules subforum, when anything is added. And the facility would have to be added back into the User guide -- though it may take a different form. Pete
  9. Is is provided by Simconnect? It never has been. Normally you need to looks at the charts. Pete
  10. If you read my first reply you'll see I said 3114 (first). First means write 3114 FIRST! As described in the Offsets documentation, the PARAMETER goes in 3114, the CONTROL into 3110. Please look again! If you can't set a value, what value is it going to send? Pete
  11. If you can make Prosim to send the correct values to offsets 3114 (first) then 3110, both 32 bit U, then you can in this way tell FSUIPC to send the keystroke. That's the easiest, but I don't know if Prosim can be told to send two things for one trigger. Otherwise you'd need to write a small Lua plug-in to read the "spare" offset and send the same control to 3110/3114. You must use the provided User Offsets to avoid clashes -- any from 66C0 - 66FF, as documented. Pete
  12. Something is wrong in your app then. There's no difference in reading any offset from any other. You just get what is there. Of course what it looks like depends on how you define it. I thought you only wanted altitude and heading? You've got those and more. FSUIPC only reads the airline/flight details for aircraft within its TCAS range, and that is in the TCAS tables. You'd need to search there for more details. FSUIPC's done the laborious part of identitfying the nearest. Pete
  13. You could do it using a Lua-plug which uses an event.timer for the required number of seconds and then checks the AGL before using the appropriate offsets to save a flight. Really, though, if you are getting pauses (presumably because you are using a PMDG or similarly compex aircraft which freeze the sim?) I'd recommend turning autosave off. Save flights now and then manually if you think your system is liable to crash. You don't need to go into menus, just press ; and enter a name. That's effectively all autosave is doing. And surely it is far better to suffer a pause knowingly, at a time of your choosing, that one imposed on you whilst you are busy flying? I could actually very easily add a HotKey assignment you could use to make FSUIPC do a Save, in the same way as Autosave but not timer based. To me that would seem to be far preferable. I've not used Autosave for years, not since sims became reliable enough not to keep crashing. That's the real solution. Pete
  14. The controls listed in FSUIPC are the FSX controls. with some sophisticated add-ons like those from PMDG, many of those will not ewrok because they implement their own systems. They DO publish an SDK, which is already included in your aircraft folder, in which most of their switches are usable via special "custom controls". They are listed towards the end of the file of type .h. you need to search for the switches you need to operate, work out the control number, then assign it in FSUIPC to <custom control>, and enter the number you arrive at. Sorry, I cannot be more specific. I do not use any PMDG aircraft. Pete
  15. For VB.NET you should be using Paul Henty's Client DLL for .NET. It makes your task much easier. I've moved your question to his sub-forum. Pete
  16. I've added the new Active Sky weather values to both FSUIPC 4 and 5. They are included in FSUIPC 4.971 and FSUIPC 5.112, both just released. The offsets are documented in the included Changes document, and actually follow on from those listed in the ASN Wx Radar document already installed in the FSUIPC Documents folder. Pete
  17. FSUIPC Versions 4.971 and 5.112, both just released, include new offsets providing data about the nearest AI aircraft. The offsets are documented in the "Changes" PDF included in the download ZIP. Note that the range values for these are separate, as they were actually supplied before: 736C for ground and 736E for airborne, both 16-bit integers. They are the values used for the title bar information in the recent version of TrafficLook. Pete
  18. They are standard FS controls. How individual aircraft react to them in up to them. All aircraft I know of, and especially all Boeings, have just the one OBS which is used for VOR NAV radial Selection and the ILS Localiser. There are certainly not separate values implemented for the two almost identical radio aid facilities. The ILC LOC facility takes the place of the VOR radial facility when you tune an ILS frequency rather than a VOR one. You never have both operating together for that reason. Pete
  19. MOVED FROM FAQ SUBFORUM! Please ALWAYS post Support Questions to the Support Forum! Offset 0374 is not supported in any revent FS or P3D versions. I don't think a method was provided for that. Did you search through the list of G1000 controls? If there's nothing there, then you could try enabling FSUIPC Event logging, then operate the button in the cockpit and see if any control is logged for it. Pete
  20. As you said, I can't really do anything with the crash log. I'm pleased that you've had so much success in any case, and as I said, I'm surprised that you can manage such long flights in any case. My impression from reading the Forums is that it is quite rare to get such flights done without a crash at some time. that's why autosave is so popular. I don't get crashes at all, but then I enjoy takeoff and landing, not cruising, so I fly 737 on short routes of max 2 hrs and usually 1 hr or less (cruise). It often takes longer to plan the flight and prepare the cockpit, and taxi about at large airports and queue (realistically) behind a few AI aircraft for takeoff! If I want to reach an airport a long way from base I plan a series of hops via interim airports, and re-boot the system between each leg for safety. The close log gets a long way through closing everything down. My best guess from the log is that one of the Lua threads didn't manage to properly close its dealings with a device before FSUIPC Terminated. The last thing FSUIPC did was to close the "Global" Lua thread, which is the one supporting Global variables. I know LINDA uses these a lot to share data. With the Global thread closed it would get "nil" returned to any query, so possibly there's a place in their code where this isn't checked. Though that shouldn't cause a crash -- unless it was used as a parameter for some Windows API call, or a call to one of its other DLLs dealing with devices. I've now got a couple of other facilities to sort out in FSUIPC5 (and 4) before I release an update. It'll probably be 5.112. Pete
  21. Ah, again you remind me at a bad time. Sorry, but the next 9 days I'm fully occupied with guests here, helping with technical issues -- one all the way from Melbourne in Australia and the other from Ireland, and not long after I'm away for 3 weeks in the USA. Nevertheless if i get a chance to look at it I will. Otherwise ask again mid- to kate Sepptember. BTW Rather than have copies made of those details, wouldn't just an offset giving the table entry number for the nearest be better? Also, the finding the nearest with them all moving all the time (and you also of course) would not always give the truly correct result. I'd only want to check at intervals. Pete
  22. Odd, as in the FSUIPC you have I now save the previous Log as FSUIPC5_Prev.Log. Pete
  23. After 13h? No, I don't think so! I've never heard of anyone having a session lasting that long in any case! That's increadible! Try doing than in FSX or P3D3! How did the FSUIPC5.LOG end? Pete
  24. You need to supply more information, lke: 1. Actual version number of FSUIPC5. 2. Whether you ASSIGN throttles in FSUIPC or in P3D. 3. If you assign in FSUIPC, what do you assign to (name of control)? 4. If you assigned in FSUIPC, did you disable controllers in P3D? 4. Are you calibrating in FSUIPC? If so did you follow all the numbered steps? Did you only assign one throttle? You sy nothing happens when you push "the throttle"? Both, or only one? Changing aircraft won't hcange what throttles do unless you are using profiles already. PMDG are much more problematic. You probably won't be able to do the same things on those as with default aircraft. That's where profiles come in, so you can have different settings for different aircraft. 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.