Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. You posted a support question in a subforum instead of in the Support Forum, so I've moved it so yuo will get an answer. What version of FSUIPC3? Did you follow the instructions from the Installation and Registration guide exactly? I would need to see both the FSUIPC log file and the Install log file (both from the FS Modules folder) to help any further. You can paste them into a message here. Regards Pete
  2. If you mean that the ID's of the joysticks change, then you should investigate the facilities in FSUIPC for letters assigned to those joytsticks. FSUIPC then keeps track of any changes. There's a chapter in the user guide dedicated to this -- search for "letters". Bearing in mind we are only talking about button or key asignments, there's no reason at all for those to ever change if you used Joy Letters as just mentioned. Regards Pete
  3. No, it is built into FSUIPC3. Well you could read the fuel levels and prevent them being increased instead by re-writing the previous lower values each time you see this happening. Pete
  4. Only by splitting that Lua program up into separate ones for each function. Then you'd see "lua XXX" for function XXX and so on. But if all you are doing is sending control numbers why no do it by simple assignment in the [buttons] section of the INI? Yjr control numbers, like 69775 and so on, are the numbers which follow the "C" in lines like 1=P1,1,C65602,0 The parameter there is the 0. Pete
  5. But I still don't understand. By "virtual joystick" do you mean it is somehow creating all those axes for you and you somehow operate the axes from buttons? Why do you need SPAD when Saitek buttons and axes are seen directly in any case? What is SPAD doing for you? Pete
  6. The revision to the assignments when you change to lettering is done automatically. All you needed to do was edit the JoyNames section, as per documentation. The format of the button assignments is detailed in the Advanced User's document not in the User Guide as it isn't really intended to be edited by all. Regards Pete
  7. I don't understand how you can miss the SubForums? They are the first thing you see when you come to the forum, right at the top! There are subforums called Announcements, FAQ, Download Links and User Contributions. Being new here I would have thought they were the very first things you saw -- how do you not see them? They are there explicitly to attract the attention of new visitors so they can look for solutions to their problems before adding new messages to the Support Forum. itself! Regards Pete
  8. They wouldn't change normally -- they will change if you sometimes unplug devices then plug them in again. The ID is assigned by Windows for connections it finds in the order it scans its USB hubs etc. Best to use the Joy Letters facility so that FSUIPC can keep track. There's a section on this in the User Guide. Regards Pete
  9. I don't know what SPAD does exactly. Is it using FSUIPC? Are you assigning the rudder, yoke etc in FSUIPC? What does SPAD have to do with these? In FSUIPC Logging tab enable Axis event logging. And also show me the FSUIPC4.INI file. If the log is very long just show the last section before the "freeze". Pete
  10. FSUIPC4 is for FSX and Prepar3D. It cannot work with FS9 or before. The facilities regarding weather from ASE are not applicable to FS9 in any way whatsoever. You do not need to use DWC in FS9 to get around wind shift problems, so there is not need for FSUIPC to supply clients with weather from ASE. I think you have got yourself rather confused. This thread and its complete subject is solely concerned with FSX and ASE/AS1012's DWC mode. Regards Pete
  11. If you mean the FSUIPC "slopes" graph, ignore that part of the graph it isn't relevant to throttles. It relates to things like ailerons, elevators and rudders, and the lower half then is always a mirror image of the upper. That makes no sense for throttles hence the lack of effect in the unused half. I can't see why that should upset you. Pete
  12. Any information about this "freeze", like version of FSUIPC? Version of FSX (SP1, SP2, Acceleration?). Any logs of FSUIPC? Does the Windows Error log show anything? What is SPAD exactly? An external program or another DLL? Is it that Saitek driver? What is the difference between SPAD "working in default" and "as virtual joystick"? Still no solution? Since when? This is the first post of any such problem! Pete
  13. Why not check the SDK first? There are examples. What are you on about? The Download Links subforum, which is where I pointed you to,, has several threads full of non-empty download links! Please do read what is written! Why should there be a separate SDK for FSX? FSUIPC has been going since FS95, with compatibility all the way through. Why would I produce identical SDKs for each version of FS? It wouldn't make any sense! Why? That's just a utility program provided by Pelle Liljendal to assist you in understanding how FSUIPC offsets behave. It is written in Delphi and is an example of an FSUIPC-interfacing application. Sorry, you seem to be going off half-cocked in all directions. Sit down, review all the files, read them all, look at the VB example. Start again tomorrow. Pete
  14. The PMSG NGX controls or events are nothing whatsoever to do with offsets. The list of PMDG controls is in the ".h" file installed in the PMDG NGX SDK when you applied the most recent update from PMDG. If you want offset lists, which are an entirely different matter, you need to download the FSUIPC SDK). Well, normally control numbers are obtained automatically from the control names listed in the assignment dropdowns. For the PMDG ones, though, which FSUIPC doesn't know, you'd need to edit the INI file directly and insert the control number. Easiest way is to assign to any FS control, then edit the INI file, find the line in [buttons] where that button is assigned, and change the number after the "C". The format of button assignments in the INI file is detailed in the Advanced Users guide. Pete
  15. Thanks for the testing. It looks like I'll have to remove this check: 167763 **** SimConnect appears not to be receiving requests! Re-connecting now ... **** 167872 SimConnect_Open succeeded: waiting to check version okay [/CODE] It's was this which crashed P3D on occasion too. I've no idea why. All it is doing is turnng a specific SystemEvent notification (4secs") on and off alternately, to ensure it knows SimConnect is actually receiving requests. This was to get around a previous case which showed that SimConnect can get into a state where it is still continually sending data, so FSUIPC detects no stall, but doesn't act on anything it is requested to do. I'll remove it for now. Seems to do more harm than good. Regards Pete
  16. Same place as you find FSUIPC and all my other programs. either on the Schiratti site, or in the Download Links subforum here. How did you find this forum? Regards Pete
  17. Seems that's a quirk of the way the 737NGX is programmed, then. FSUIPC's mouse macros don't always work. maybe it would with appropriate parameters, but you'd need to experiment to find those. Now that the SDK is published with all the control numbers available for every single function, why not use that instead? You only need to assign to the appropriate control number. I assume by recall you mean pressing on the Annunciator panel? There are two controls defined for that: #define EVT_SYSTEM_ANNUNCIATOR_PANEL_LEFT (THIRD_PARTY_EVENT_ID_MIN + 349) // #define EVT_SYSTEM_ANNUNCIATOR_PANEL_RIGHT (THIRD_PARTY_EVENT_ID_MIN + 437) // where THIRD_PARTY_EVENT_ID_MIN is defined as 69632. I'll leave you do do the addition! ;-) Pete
  18. The flight number provided by FS for sleeping planes is actually the one embedded in their AIRCRAFT.CFG file, which would be the same for all instances of that aircraft, so it isn't useful and in fact is downright misleading. So FSUIPC suppresses it in that state. The flight number becomes available after the aircraft has submitted its plan and obtained "clearance". That's usually so close to push-back and taxi that effectively you don't often see the flight number until the taxi stage. Regards Pete
  19. Mouse macros are simply direct calls into Gauge or DLL code in the aircraft concerned, and once made do not involve any "clicks" at all, so I realy don't understand what you mean. If the aircraft you are using uses different DLLs or Gauges when you are in different modes, then you cannot use the same macros for each mode. For instance it is quite possible that some add-ons have different gauge files for 2D mode compared to VC/3D mode. But i don't see how the number of screens ever becomes a factor. Maybe the support forum for the aircraft you are using can help? Regards Pete
  20. To what "references"? FSUIPC4.DLL is an FS module. It can't be run separately or attached to by other programs other than by the defined IPC ("inter-process-comunications") interface. Please see the FSUIPC SDK. It is not an "assembly" or "COM compoanent" and you cannot link to it directly. Please refer to the SDK. You seem to be severely misunderstanding something. Pete
  21. Oh, I wish you had tried 4.812f (from a link earlier in this thread). That changes things in the exact area you are experiencing problems with, and it is that version I nbeed checked, not 4.812. :sad: Pete PS Here, I'll repeat the link: FSUIPC4812f
  22. Only in FS9 and before, with FSUIPC3 or earlier. It was never a facility in FSUIPC4 . The text line options in FSUIPC4 only apply to messages written to that display via FSUIPC from applications. You have some option set differently, or maybe the message window position corrupted in the Flight or CFG file. Pete
  23. FSUIPC4 has nothing to do with FS's ATIS. It can't stop it or help it or do anything with it at all. Pete
  24. 4.812f would be better. If FSUIPC4 was the only SimConnect using application running, then it could be that a reconnection attampt is being made with the re-linking which it used to do (before 4.812e) and Simconnect.dll is reloading into a different part of memory. At least that's one theory which has been postulated with the Prepar3D crash. I don't actually see how that could have caused the crashes, but avoiding the re-linking did help. However, the common factor with all of them so far has been the "SimConnect stalled" or similar message being logged first, but you say this didn't occur. Or isn't that what you mean by That's a little ambiguous. By "connection to simconnect" do you mean the first one, the normal one, or is it actually a re-connection? Else why mention it at all? If it was a re-connection what was the actual message? It is rather a shame no one reported this with FSX until now, and sadly at a time when you can't help check things. I cannot support folks who return to older versions, so it has to be fixed! Now that it appears fully resolved on Prepar3D, the only place is was reported till now, I was about to build a new release, 4.82, but now it looks like that is on hold until you return from travelling or someone else who experiences this trns up out of the blue! :sad: Pete
  25. Good. They are probably inevitable on a crash. Theuy are only logged for information reasons, when you have "LogExtras" specified. Those don't mean so much and i might suppress them in any case. The checking for SimConnect not receiving requests from FSUIPC is only bypassed in P3D. If that ever gets resolved I'll put it back in. In all cases, the re-linking to a Simconnect DLL is now only done when the Simconnect Open fails -- this usually means a Simconnect mis-match or other serious SimConnect problem. In other cases I now just close the connection and re-open it, re-establishing all the requests. 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.