Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. They certainly don't do anything in the sim's built-in systems implementation. But there may be an indication internal to the specific aircraft implementation. I'm afraid i don't know that add-on aircraft so I couldn't say, but you could see if there's a local variable (L:Var) for them. You can list them using an assignable control in FSUIPC, or log them as they change using a Lua plug-in supplied in your Example plug-ins ZIP file. Pete
  2. I've no idea what this "npm" package is. Are you hoping someone here might be familiar with it? Maybe the authors have their own support places? You can write to offsets in FSUIPC by assigning buttons or keypresses to "Offset ..." controls, of which there are variations for different value sizes and formats. Pete
  3. Offset controls are NOT "custom controls", but are actually listed for selection in the drop down list, with all the other named controls, as Offset ... Please do READ what you are told. We are really trying to help, but you do need to read what we say. Here's what John said: So, scroll to that control in the list (or just enter "o" to get there faster). The offset entry field will be there when you select that control, but I think for the offset in hexadecimal (as A000 is) I think you may need to enter it as xA000. Pete
  4. There's no graphic elements whatsoever in FSUIPC7. It might be related to the loading on SimConnect, which FSUIPC and many other add-ons use. Whatever is causing it, it is a matter for Asobo, so i recommend to report using the proper MSFS bug reporting methods. Pete
  5. Did you go through to the payment stage where the discount is applied? If you did and it wasn't applied, you need to raise a ticket with SimMarket. This forum is software support, we can't deal with sales questions here. Pete
  6. Just ZIP files for attachment! They are simple text files and do ZIP up real small. Pete
  7. Thank you. But please supply the FSUIPC6.INI file as well so we can see your settings. Pete
  8. Sorry, I am still lost. What "tutorial" are you talking about? And what is "cbxGate.text"? Are you sure you are not still posting in the wrong Forum? Pete
  9. This looks like a matter for ProSim -- I'm not sure where ProSim gets its information from, whether direct from MSFS via SimConnect or from FSUIPC (maybe that's to do with the SimConnect or FSUIPC setting in ProSim's options), but either way ProSim's support does need to explain this. Ground and Air traffic aircraft are placed in different tables in FSUIPC offsets. You could try using the program TrafficLook to show the traffic data being stored. Get this here: Possibly when the data first arrives the "on ground" indication isn't supplied. but I am sure that by the time you are in a position to receive TCAS warnings (after taking off, surely) that the proper status of all the AI traffic will have been established. This: seems to imply that it is, indeed, some sort of timing problem. I think ProSim can solve this if you ask. Pete
  10. When you say "nothing" do you mean the assigned offset never changed even though it should? Well, the two must match to make sense. Did you try the default, the 8-byte floating point "double" ("DBL" in Lua)? For that you just omit the type altogether, so 6=A32NX_AUTOPILOT_HEADING_SELECTED=66C7 and read it in Lua with x = ipc.ReadDBL(0x66C7) Pete
  11. Ah, so it is a facility in a simulated aircraft, not in your own cockpit, and a simulated potentiometer not a real one you are connecting! Which aircraft is that? Isn't this "lights_potentiometer_set" control listed for assignment in the drop down for axes? All controls ending in "_set" should be. Otherwise I'll have to ask John to look. Pete
  12. A number stored in computer memory is represented by a number of bits ("binary digits") which are either 0 or 1. A byte is a collection of 8 bits and can store a numeric value from 0 to 255. In order to represent negative numbers one of those 8 bits is used as an indicator as to whether the number is above zero (positive) or below zero. This reduces the range to -128 to +127. But the bits look the same either way -- it is how you interpret the bits. Hence signed or unsigned. So something representing an angle like heading be seen as -180 to +179 or 0 to 359. I don't know what you've done to get your numbers, so I cannot help. I'd need you to show me, as I said. What produced that weird log you showed before? If FSUIPC is running, then there's something wrong then. John will need to help you there. The INI file is next to FSUIPC7.EXE itself, in the folder you told the installer to install it into. If you don't remember where you put it and FSUIPC7 won't run then either do a search with Windows Explorer, or install it again and this time choose a folder you can remember. I create a folder called "FSUIPC7" to put it in. Pete
  13. How are you connecting your potentiometer to the computer? If you wired it through something like a Leo Bodnar BU0836 card then connect that to the PC via USB, it will be seen as an axis by both Windows and FSUIPC, and you can assign it as you like. I don't know about cockpit lighting though. I don't know of a simulated aircraft which has adjustable cockpit lighting, so perhaps you are talking about controlling real lighting in your built cockpit using some control in FSUIPC, but in that case I can't see where a potentiometer comes into it. You need a DtoA (digital to analogue) ciruit instead? Perhaps you could explain in a little more detail exactly what it is you are trying to achieve? Pete
  14. You are reading an UNSIGNED value as SIGNED! Just read as unsigned and you'll get 0-359. I don't know what the rest of your posting is supposed to show. It isn't a log I recognise, and makes no sense anyway. Why did you post it? You need to show us the FSUIPC INI file and the LOG as John requested. Pete
  15. Good. So all the error meant was that FSUIPC closed whilst ProSim was still trying to access it. With FSUIPC client applications like ProSim, there is no harm in starting them separately as you were doing, but you usually need to close them BEFORE closing the sim to avoid them complaining about the connection. (There are so programs which detect the Sim closing so automatically close themselves, maybe be option). Pete
  16. If this the command line then it is no wonder it couldn't run. That says "run G:\ProSim737" (which is presumably a folder) with the parameter ProSim737.exe. Assuming the path is correct you need just G:\ProSim737\ProSim737.exe. You don't even need any " as this contains no spaces. Pete
  17. First, can you explain why you are posting this question here? Are you using one of the programs we support? I think really you would be better off posting in a more general programming forum, like https://www.fsdeveloper.com/forum/ Second, the amount of a file you read in a program is up to you to control. If you are searching through a file the fastest way is, of course, to read it all into memory first. But you could just read a small part at a time -- one line even. It's entirely up to you, surely? Third, 320 Mb is nothing to worry about in these days of memory measured in Gigabytes. The only think you'd need to worry about is if you have a memory leak, where memory to allocated is not being freed. Pete
  18. The reason for my row of ??????? was to show that the error made no sense! I was surprised! FSUIPC7 has nothing to do with "diskettes". John's answer is the one to follow. Pete
  19. Strangely the official windows System Error code list https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499- lists this error as: ERROR_WRONG_DISK 34 (0x22) The wrong diskette is in the drive. Insert %2 (Volume Serial Number: %3) into drive %1. ??????? Pete
  20. Which download page are you referring to? Our programs are available in the Download Links subforum within this forum: https://forum.simflight.com/forum/142-download-links/ As it's part of this Forum and you are posting here, it cannot link to someplace else. Maybe you have some sort of virus or other malware interfering with Forum access in your PC. The other main place for out software is http://fsuipc.com/ Pete
  21. This sounds like there's no proper entry for P3Dv4 in the registry. Not sure how you managed that but the easy way to fix it is to use Windows Settings - Apps to uninstall just the Prepar3D v4 Client, then rerun just the "Install_Client.msi" file which you'll have in the original downloaded ZIP for V4. That'll just replace the main V4 module/exe and update the registry. It won't harm or change anything else, and you can do it retaining your P3D registration (such an option is offered). Otherwise it's a little more messy -- editing the Registry yourself. All that's the best way as it will also assist many other installers which need to find installations via correct registry entries. The other way would be to copy the FSUIPC6 folder from the Prepar3D v5 Add-Ons folder to the Prepar3D v4 Add-Ons folder. hat would actually work with no further action, and use your same settings (the one FSUIPC6 install folder) for both. If you still really want different settings for each then you'd need to edit the Add-on.xml file to change the path accordingly. That's in an entry like this: <Path>E:\FSUIPC6\FSUIPC6.dll</Path>. Pete
  22. And is there then an entry in the Event Viewer explaining why? The first thing FSUIPC does if it is loaded is create the log, so if it got as far as being loaded it would have replaced the one you have with an empty one at least. That really doesn't change anything in FSUIPC -- replacing the code module withthe exact same code module. But maybe since the date on the file would change Windows cleared its error flag. Aha! For a Windows-enforced crash like that (which wasn't clear to me before, sorry), this FAQ subforum entry by another user deals with the registry fix for it: It didn't occur to me to refer you to this because there's been no sign of a crash actually in FSUIPC -- the only one you found was in AIPlayer. Pete
  23. L:Vars ("Local Variables" as I think of them) are mostly the plane's own internal controls or status indicators. Not all of them will change switches etc -- some are more really outputs -- status indicators or memories. You have to try them to see how they operate. Pete .
  24. It is not a good idea to try to use an offset which is already being handled by FSUIPC. Whatever value to put there or receive will be overwritten. Use one of the User Offsets (66C0-66FF). Then assign your switch to an Offset Byte Set or Offset Byte ToggleBits control with your chosen offset and an appropriate parameter. For On I assume you'd Set 1, for Off probably Set 0, or for a toggle button ToggleBits with parameter 1. Pete
  25. The value in 0818 is the altitude lock value * 65536. Look 59906 Monitor IPC:0818 (U32) = 125844848 59906 SimRead: 0818="AUTOPILOT ALTITUDE LOCK VAR:3" FLT32: 1920.23999023 Now see: 125844848 / 65536 = 1920.2399 The offset is in the same format as most of the other Autopilot values. It is NOT a FLT32. That's only how SimConnect supplies it. Like most FSUIPC offsets it is converted for compatibility with past versions of FS (dating back as far as FS98). With event.offset there's no need to do any ipc.read in any case. The value is supplied as one of the two parameters. 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.