Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. I've no idea about anything called Java or Javascript (though I know John has), but aren't these threads relevant? I doubt whether John can consider any special developments in FSUIPC itself with so much left outstanding in the basic needs for full MSFS support. Pete
  2. The same sort of thing has been happening with (mostly) add-on aircraft in FSX and P3D, especially PMDG aircraft. It seens some parts of the aircraft code handle other parts by using the user controls. To avoid filling up the log you can add a "DontLogThese" parameter like into the FSUIPC7.INI file. Check the Advanced Users guide. I don't think they would contribute to MSFS stability. It seems the latest version of MSFS is pretty unstable in any case. Pete
  3. You would need to write two programs -- a server on the FSUIPC7 PC, interfacing to it directly using the SDK provisions, and your Android program talking to it over a Network. If that makes it completely Windows compatible then maybe WideClient will run on it? If so you just need to register WideFS and write your program as for any normal Windows FSUIPC application. Seems unlikely though. Pete
  4. Yes, you can use it on an many PCs as you like, provided they are for your personal use. The license belongs to you, the user, not the PC. Pete
  5. Flight plan saving and loading with SimConnect doesn't work at present. We are awaiting a fix from Asobo. Judging by the reports on the P2A support forum, plans generated by P2A also appear to be incompatible at present. FSUIPC can't really do anything about this. We are totally dependent upon Asobo/Microaoft to continue development of their Beta-test stage product! 😞 The logs you show don't help. They just show FSUIPC7 closing down automatically because MSFS stopped running (and option in FSUIPC7). Instead you need to find the Windows crash data (in Event Viewer) and submit crash reports on Zendesk so that Asobo/Microsoft have a chance to fix things! Looking at the reports on the assorted MSFS forums, the latest release of MSFS is pretty unstable with or without add-ons like FSUIPC7. I'm avoiding it at present, sticking with P3D 5.1HF1. Pete
  6. \0 is simply a zero byte, so equivalent to 0x00. What you are sending with "\0\0\0\0\2" is in fact the value 0x000200000000 including the additional zero at the end of the string. Intel style processors use Lo-Hi order, so the first byte is the least significant. Your use of a string for this is reasonable and compact, so I wouldn't worry about what method you use. Well done on the detective work!! Pete
  7. Are you running FSX "as administrator"? If so you must also run any FSUIPC applications such as TrafficLook "as administrator" too -- otherwise they can't exchange information. Otherwise you need to state the version number of your FSUIPC4, and if it is up to date (4.975a) then show me the FSUIPC4.LOG and FSUIPC4.INI files (from the FSX Modules folder). Also the TrafficLook.INI file, which will be in whatever folder you use to run TrafficLook. You can put it where you wish. I have mine in a folder I created called "TrafficLook". Pete
  8. I think this is the known key code problem in SimConnect which Asobo is supposed to have corrected -- or perhaps that is a promise for the next update? John will confirm when the holidays are over. Pete
  9. We're entirely dependent i=on Asobo/MS fixing SimConnect. You need to add your voice to ours with Asobo/Microsoft, or report the deficiencies of the SimConnect load/save flight facilities via Zendesk. Pete
  10. TrafficLook works fine on both Win7 and Win10, and with any version of FSUIPC which provides traffic information -- ie FSUIPC4, FSUIPC5, FSUIPC6, and FSUIPC7 (though in the last case MSFS is woefully deficient at present in what it exposes). It doesn't matter where you install TrafficLook. it's a separate application which connects to FSUIPC on the same PC as FSX/P3D, or to WideClient on a WideFS client PC. Pete
  11. You need to supply more information! Which version of FSUIPC? Which flight simulator? What "file" are you opening? What do you mean by "cannot do anything" -- what are you expecting? If you've installed FSUIPC correctly there will at least be an Install Log file. If FSUIPC has started it will also have created a log file. Both those files will be useful for us to understand what you have wrong. Pete
  12. They don't need letters as they are not subject to getting different joystick IDs like real devices do which disconnecting and reconnecting or updating Windows. The joystick numbers are fixed -- 64 for offset 3340, 65 for 3344, etc. Those joystick IDs can't change! Ah, good question! Probably not, as I don't think FSUIPC7 starts operating the offsets system until it is connected. After all, it cannot supply meaningful data from an unconnected MSFS. But John would have to confirm. He might consider making an exception for the virtual button offsets as I can see it can be useful to be able to sort out all your assignments without the Sim actually running. Pete
  13. As documented, those offsets contain the Ground Altitude (above mean sea level), not your AGL! The AGL is the difference between that and your aircraft's altitude. Pete
  14. It would be possible using the COM and HID facilities in the FSUIPC lua libraries. But you'd need to do a bit of research. There are HID facilities to read axes and buttons, but nothing specific for displays of any sort -- as far as I know there's no fixed defined way for dealing with displays. The LEDs may be encoded in the HID data as "features" in which case they should be controllable via the com.writefeature call. I'm afraid, however, that you'd either need information supplied by the makers, or do your own investigation using a USB monitoring program whilst running their supplied software to operate the LEDs. Pete
  15. Yes, they are assignable -- that's really the point of them. They appear with Joystick numbers 64 to 72, each with 32 buttons 0-31. Pete
  16. FSUIPC applications use a library to let them read and write FSUIPC offsets. For C# I'd recommend you look at Paul Henty's .NET DLL for FSUIPC -- please see the separate sub-forum above. Paul is very helpful and will no doubt answer any other questions you have. I don't know whether it has any special functions for the virtual button offsets, but it is quite likely -- and even if not I think it's an easy library to use. Pete
  17. All that sounds like exactly what the virtual Buttons facility was invented for. You can have up to 288 buttons mapped to bits in the offsets 3340 onwards. Offset 29F0 also relates. Pete
  18. Just tried it, but from a Powershell command window (i unstalled Powershell a while ago and it takes on the right-click facility to open a folder in a command window). With Powershell it isn't quite like you have it. Just entrering MakeRwys />0 gives this error Suggestion [3,General]: The command MakeRwys.exe was not found, but does exist in the current location. Windows PowerShell does not load commands from the current location by default. If you trust this command, instead type: ".\MakeRwys.exe". See "get-help about_Command_Precedence" for more details. But following that advice, this worked fine, still giving me EDKP PS E:\Prepar3D v5> .\MakeRwys />0 So I tried using an old-fashioned command window by using CMD.EXE in the Start edit field to open the window. Now MakeRwys />0 generates the files without the EDKP runways! Very strange -- the command line parameter is not being passed to the program! Sorry, I've no idea why. Seems the old Command window facility isn't working as one would think. Pete
  19. Well it should, but I always find it easier to use a shortcut anyway. Note that in my shortcut the program pathname is enclosed in " ". maybe that is necessary because of the space in the path? Did you use " " around it in the command window? Pete
  20. I don't know what you have wrong (check your command line), but using a shortcut with the settings shown below gives me these two lines in runways.csv: EDKP,0100,51.192677,7.786882,980,104,1408,0 EDKP,0280,51.191677,7.792833,980,284,1408,0 Pete
  21. Okay, so it only cancels the first. Perhaps it should carry on and look for other matches. Never thought of cases like yours where there'd be multiple events for the same function. But I'll leave it to John to decide whether to change that. I assume there's no good use for doing it specifically one at a time? Mind you, I'm not even sure what order they'd be seen in -- probably first registered to last. Pete
  22. Just ZIP files to reduce the size considerably! Pete
  23. You say that, yet FSUIPC detects 719 ---------------------- Joystick Device Scan ----------------------- 719 Product= Controller (XBOX 360 For Windows) 719 Vendor=28DE, Product=11FF (Version 0.0) 750 Product= Controller (XBOX 360 For Windows) 750 Vendor=28DE, Product=11FF (Version 0.0) 750 ------------------------------------------------------------------- Oddly two exactly identical game controllers. (If you only have one, then the Registry is corrupted). That's where the Log ends. This is typical of a problem with a device driver, hub or joystick device. Please follow the steps John has been outlining. Pete
  24. No, I can't. If it is connected properly to the Bodnar board, then if it is functioning correctly AND it is of the type which uses the two output connections separately, one for each direction, then the Bodnar board will encode each direction separately in the Direct Input package as two separate button bits, hence two separate numbers. However, some encoders don't have such a tidy arrangement, but simply pulse both outputs in both directions, the only difference being how they are phased. FSUIPC can deal with that too, via conditional assignments as described about half way down page 23 in the FSUIPC6 Advanced User guide (and on a near page in other FSUIPC editions). But if you aren't seeing two different button numbers reported no matter which direction or how slow or fast, then it really has to be a connection error on the Bodnar board, or a faulty encoder. Did you ever check what Windows reported in its game controllers - properties display? In case you don't know how to do this, just under 'Devices and Printers', right click on your game controller's icon, then click Game controller settings and finally click Properties. You will get a display showing however many buttons and axes you have connected up on your Bodnar BU0836. As John said, FSUIPC can only handle whatever is reported via DirectInput. Pete
  25. I've moved your question from the FAQ subforum ,where is clearly states "Not for support requests" so it can be answered! Why do you say there is no offset for this? Check offset 0x2A90. That is the documented offset recording the value of "TAILWHEEL LOCK ON"! 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.