Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. The PFC driver is identical except to make it recognise that FSUIPC7 is an EXE instead of a DLL. It needed to know because it attaches to FSUIPC and uses functions exported by it. If there's some built-in text which hasn't been changed then that's because it is built in, and is the same on FSUIPC5, FSUIPC6 and FSUIPC7. I could generalise that if so (to "FSUIPC"). But if you are referring to something being logged then tthat seems odd. So, can you please be explicit. Where are you seeing this? If you are getting the documented panels for PFC then the PFC driver is running okay. Otherwise you'd see nothing. I would just like to know if the indication is an incorrect run-time indication or an unchanged built-in text. Pete
  2. The object of the Rotaries Lua is to convert the two "real" button presses (one for each direction) as seen from your rotary into four "virtual" button presses -- two for each direction, one fast, one slow. Then you assign to those. The list of buttons you set into "Rotaries = { ..." tell the script which pairs of real buttons it should look for, whilst the resulting virtual buttons will be adjacent pairs (slow and fast) on joystick 64 or 65 for each real button. So your list of two { 0, 1 } is correct for one rotary which operates real buttons 0 and 1. The rotaries example was really provided as an example of programming a rotary on any kind of HID device connected to USB. With a joystick recognised by FSUIPC you will get the real button presses being seen as well as the virtual buttons programmed in this plug-in. The IgnoreThese facility John mentioned will help when assigning to the correct virtual buttons, avoiding confusing when trying to do the assignments. For a single rotary you will get your real button 0 converted to virtual buttons 64,0 and 64,1. and similarly your real button 1 converted to virtual buttons 64,2 and 64,3. The code in the plug-in copes with up to 16 rotaries, so would then use up all 32 buttons both virtual joysticks 64 and 65. Then in order to get a reliable fast versus slow turning recognition you will probably need to adjust the timings, i.e. these two: FastTimeLimit = 60 -- Adjust to taste Pollrate = 20 -- same as 50 times per second With those figures, if button pulses are seen less often than 60 mSecs apart they are counted as "fast", otherwise they are "slow". Note that if you enable Lua logging, as you have done, things will be much slower in any case! There's no harm in adjusting the poll rate too, as you have done. Note also that it is normal to assign whatever it is you want to both "press" and "release", because the rotary presses on one click and releases on the next. That would list two rotaries, one pressing 0 one way 11 the other way, and the other pressing 1 one way and 10 the other. The buttons you assign will be "virtual" buttons, not the real ones, and there will be 4, two for each direction. The Lua script is converting your real ones according to the speed you turn the knob. Pete
  3. I'm afraid MSFS cannot properly deal with on-screen displays and windows from applications. We are hoping Asobo will rectify this in due course. Best to enable normal logging and, if you want the results in real time, enable the FSUIPC console log. That's what i do. Pete
  4. Didn't you install it and read at least some of the documentation first? Purchasing something without not whether you need it or how to use it is a little foolhardy. It does advise you to download it and install it first. Anyway, there are lots of lots of threads about using FSUIPC with Honeycomb devices, including I believe a very informational turorial or guide. Check the FAQ subforum, User Contributions, and other threads headed about thesee davises. Pete
  5. It's built into the FSUIPC user interface. There's a section about it in the User Guide -- "User profiles for all control settings". Please do refer to it. Pete
  6. These are instructions for separate use of the LorbySceneryExporter. MakeRwys does it all for you -- it runs the exporter automatically. So just follow the MakeRwys instructions, not the Lorby ones! It doesn't need "Powershell". Just run it "as administrator". To avoid forgetting this, I simply right-click on the MakeRwys EXE, selection Properties-Compatibility and check "run as administator" there. After that it will always be okay. No, leave as it is. "REQUIRED" just means it's essential or the sim won't load. I don't think any normal scenery needs it or wants it. Sorry, I'm not checking your scenery. If it works, it's okay. That file is nothing to do with MakeRwys. As the log says, The CFG file being used is: "F:\P3D\MakeRwys_Scenery.cfg" I suggest you stop fussing and get on with flying. Your original problem was a corrupted P3D scenery.cfg file. You fixed that. Pete
  7. Just have two profiles, one for each controller set. You axis assignments and calibrations will depend on which profile you use. Pete
  8. Really this is a question for Lorby, as it is his program which cannot get over the problem with your corrupt Scenery.CFG file. You have these bad entries near the beginning of the file: [UK2000 Common Library] Active=FALSE [UK2000 Leeds Xtreme] Active=FALSE [UK2000 Newcastle Xtreme] Active=FALSE I've no idea how they got there, but as they are not [Area.nnn] sections they seem to stop the Lorby program in its tracks. Looking at the rest of the file it all seems to be default -- no add-on scenery there. So you might as well delete the Scenery.CFG file, then run P3D to let it generate a good one. I think Lorby's AddOnOrganizer program also has an optionto check and repair corrupt CFG files (but i'm not sure). Pete
  9. Okay, then it is definitely a long path name problem, and for some reason the method using \\?\ before the pathname proper isn't working. The last line before the crash is: ***** Processing MSFS official scenery (Asobo=-1) "\\?\D:\WpSystem\S-1-5-21-2263347563-3261326988-2989552293-1001\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\Official\OneStore\fs-devmode\Edition\templates\AssetGroups\SimObjects\airplanes\singleprop-empty\SimObjects\Airplanes\MyCompany_AssetName\" which, without that \\?\ part, is precisely 260 characters - the old MAX_PATH length. Looking at me installation, the next path after that would have been: "\\?\D:\WpSystem\S-1-5-21-2263347563-3261326988-2989552293-1001\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\Official\OneStore\fs-devmode\Edition\templates\AssetGroups\SimObjects\airplanes\singleprop-empty\SimObjects\Airplanes\MyCompany_AssetName\model\" which would be the longest name so far, and over the maxiumn path length that the Windows API normally handle. Oddly, though I also have MSFS installed with its data files on a different drive, my path for this is still via the C:\users folders, which appear to link to my E:\WpSystems folder where the data actually resides, thus: "\\?\C:\Users\Peter\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\Packages\Official\OneStore\fs-devmode\Edition\templates\AssetGroups\SimObjects\airplanes\singleprop-empty\SimObjects\Airplanes\MyCompany_AssetName\texture\" So, the longest path I'm getting is 244 (to which will be added the individual BGL file names, if the folder contains any scenery type files). I don't understand why your MSFS installation has succeeded in placing the data into your D:\WpSystems folder ywt not provided a link in the default :C\Users folder as mine has. What have you done differently, I wonder? The \\?\ prefix evidently doesn't work to allow the long pathnames (despite the MS documentation stating so). So I'm only left with two suggestions: 1. Make sure your Win10 is fully up to date. (Win 2004 or 20H2) 2. Try the registry edit. See https://www.howtogeek.com/266621/how-to-make-windows-10-accept-file-paths-over-260-characters/?utm_content=buffer5b5de&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer You might also ask in MSFS support forums why your installation doesn't work through links in C:\Users. Maybe there's a way of creating the links there. In fact, try this: In explorer go to C:\Users\Peter\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe Are the folders there? Can you click on them and see the folders and files within? If so, then the links are still working and there's an error in your UserCfg.opt file. This is a text file and, running an editor "as administrator" you can edit it. Find it here: C:\Users\Terry\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\UserCfg.opt The last line will be the one to change. It probably points to your D:WpSystems folder. Change it to: InstalledPackagesPath "C:\Users\Terry\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\Packages" If this doesn't work I'm afraid I'm out of ideas. Pete
  10. The only version it states here and on SimMarket that is for FSX and P3D 3 — ie FSUIPC 4. But you should download it, install it, and at least read some of the documentation before purchase, as it states. Pete
  11. Well, yes -- a lot of complicated work, indeed. Okay. Hope you can move on with your project now. Pete
  12. It isn't FSUIPC6. Your METAR is merely sent to P3D. It was complicated to implement the biary structure interface for FSUIPC as well. A proper METAR string has to be formed every time. To change only parts of the weather it has to read the current METAR, make the change in that, and send it back. In normal localised weather modes that involves realing with up to 9 weather stations around the aircraft! Ask folks like HiFi Simulations, authors of the best weather setting program out there (ActiveSky) how "easy" it is! Of course. Rain and Snow need cloud!!! I keep telling oyu this. you must add a cloud layer if you want precipitation etc. Sorry, but I would have thought that was obvious1 Pete
  13. One clarification in my reply about WeatherSet2: to make changes on an entry, or to add more layers, click on the field to be entered or changed and press ENTER. You'll get a little window in which you can enter all the details for that element of weather. Note also that if you select GLOB as the ICAO in the top right field, and the File menu mode is set to autorefresh, then the display will alternate between the weather at your current position and the GLOB weather. This won't happen in GLOBal mode. GLOBal mode will be set automatically if you make a change after setting GLOB. (And I think there's a bug in that it won't switch out of GLOBal mode once you do that -- you'd need to change out of that in P3D by selecting a theme or real weather). Pete
  14. Oh, one other thing. I'm guessing also that "VC" for "vicinity" is a bit meaningless for GLOBal weather. Global means the weather everywhere in the world, there's no localisation. For local weather changes you need to look at setting weather for specific weather stations, those around you as you travel. The specific weather at the aircraft will be derived from those by interpolation. The GLOBAL mode is primarily used for exact control at the aircraft for flight training purposes. Also, you might want to consider setting the DYNAMICS value so there's no delay with changes you make. Pete
  15. I couldn't find it initially, but here it is: IDDPP where: I - Intensity or vicinity flag:. -, + or VC. - means light, + means severe, and VC means vicinity. The + and - can be combined with VC. Leave out a + or - to mean moderate. For example: +VCTSRA means severe thunderstorm with rain in the vicinity. However, won't that also need some cloud? Run it and it will display the weather data. Click on fields to change them. What it can do is described in the Text document also included in the ZIP. No one else has ever needed more help. All FSUIPC does is call the SetObservation function is SimConnect, passing on the string you provide. It does not process that META itself. It will receive back the METAR as understood and implemented by SimConnect. For example, in the log extract I showed you, using my simple Lua plug-in test: 148188 NW_GLOBAL command, setting weather to global mode 148188 Setting Metar: "GLOB METAR 101208Z 27055KT +VCTSRA" 148188 Weather Mode now = Global 148719 Weather Read request (Global set) to area 1: ICAO="GLOB", Req=0 148719 Weather Read request (Nr Station) to area 5: Lat=51.47, Lon=-0.46, Alt=0.0, Req=1 148735 Weather Received (type 1 request, AtStation): "GLOB&A0 101208Z 27055KT&D304NG 100KM&B-1500&D1957 CLR 15/12 Q1013 " I've highlighted the METAR sent, and the one it resulted in within P3D. Your original METAR generated the surface wind of 55k at 270, as I said but the rest was obtained from the general GLOB default. I think you really just need to get a METAR together which is meaningful. Without clouds at specific altitudes I can't see how you can get severe thunderstorms and rain. You need some CB surely? Pete
  16. So, for some of those many years you've been using an out-of-date unsupported copy of FSUIPC3. You need to download and install FSUIPC 3.999z9 from FSUIPC.com. And where's the INI file showing your loading of the Lua file for your Bravo? Pete
  17. Well it won't have been the FSUIPC4 Installer. It only creates and uses the Modules folder in your FSX main folder. But, sorry: I only just noticed that you mentioned FS2004 (=FS9), which of course preceded FSX and needs FSUIPC3 not FSUIPC4. So can you explain this? Is your FSUIPC3 registered? Perhaps you should show us the FSUIPC.LOG file from the FS9 Modules folder. Pete
  18. Why? FSUIPC cannot use that and most certainly doesn’t install one there! Pete
  19. Do NOT add or edit the [LuaFiles] section! That is an automatic section created and maintained by FSUIPC. Show us the INI file you are using. Pete
  20. Sorry, I don't understand what you mean there, at all. Why haven't you explained "+VCTSRA"? Why haven't you checked whether your Wind value has been set, as it has here? Did you not see the sky clear? Why do you not answer any questions? I just cannot help you without some help from you! I suggest you check the METAR formats acceptable to P3D's SimConnect. FSUIPC has some fairly complex code it has to use to make the correct METAR strings from the NWI binary data interface. It was far from an easy job -- SimConnect has peculiar ways. And the weather reading format is different from the weather setting format. Most annoying. Try WeatherSet2 as I suggested a long time ago. I think the logging of Weather (which you inexplicably haven't bothered to show me) might show the METAR strings FSUIPC generates from the data you set in that program. And it works. Anyway, this is definitely all from my till tomorrow afternoon, earliest. Pete
  21. And you desire no clouds, something unexplained called +VCTSRA, and a surface wind of 55 knots at 270? Because from your METAR that's what I get. Where's the log entries corresponding to those I showed you? See my previous replies. I get the clear sky and the wind you set. I don't get +VCTSRA whatever that is. This is going around in circles. You are simply not help me to help you. I'm off-line now till tomorrow afternoon. Pete
  22. ALSO scans it, after completing the P3D scenery? Please show me the log file (Runways.txt). You'll need to ZIP it. I have both P3D5 and MSFS installed on this PC, and it only ever scans anything to do with MSFS when it is run outside of the P3D main folder (the folder containing Prepar3D.exe). It also uses Lorby's sceneryexport scanner, supplied in the ZIP to do the scanning -- MakeRwys does not make the list for P3d scenery itself. Note that, unlike MSFS scenery, P3D scenery can be placed anywhere at all. Perhaps you should look at MakeRwys_scenery.cfg (or run LorbySceneryExport,exe and look at its LorbyScenery.cfg). Pete
  23. Maybe, but 1. Where, in your 10 mSec loop, do the input values get changed? 2. You don't give P3D enough time to change the weather. Try sleeping for a couple or seconds after setting the weather. I still don't think your METAR is sufficient. You aren't setting any clouds, nor QNH. As a test of your META string I used this simple Lua plug-in : ipc.writeUW(0xC800, 5) ipc.writeSTR(0xB000,"GLOB METAR 101208Z 27055KT +VCTSRA") At least the METAR was not rejected outright. The sky cleared (of course) and the surface wind was set. Here's the Weather log showing this: 148188 NW_GLOBAL command, setting weather to global mode 148188 Setting Metar: "GLOB METAR 101208Z 27055KT +VCTSRA" 148188 Weather Mode now = Global 148719 Weather Read request (Global set) to area 1: ICAO="GLOB", Req=0 148719 Weather Read request (Nr Station) to area 5: Lat=51.47, Lon=-0.46, Alt=0.0, Req=1 148735 Weather Received (type 1 request, AtStation): "GLOB&A0 101208Z 27055KT&D304NG 100KM&B-1500&D1957 CLR 15/12 Q1013 " 148735 WX Received in (16 mSecs), WX request type 1, ICAO=GLOB 148735 >Change: Surface wind: to alt=1000ft, dir=270T, vel=55.0, gust=0.0, turb=0, shear=0, var=0.0 148735 >Change: Wind layer 1: remainder cleared 148735 >Change: Visibility[0]: range=62.1sm (100005m), from=-4920ft, to=1500ft 148735 >Change: Cloud[0]: remainder cleared 148735 >Change: Temperature[0]: alt=0ft, Day=15.0 C, NightVar=0.0 C, DewPt=12.0 C 148735 Results: FS98 Wind0: ground (82ft) to 915ft AGL, dir 269M, vel 55, gust 0, turb 0 148735 Results: FS98 Wind1: 0ft to 0ft AMSL, dir=0T, vel 0, gust 0, turb 0 148735 Results: FS98 Wind2: 0ft to 0ft AMSL, dir=0T, vel 0, gust 0, turb 0 148735 Results: FS98 AmbientWind at PlaneAlt=92: dir 270M, vel 55 148735 Results: FS98 Cloud1: type=0, from 0ft to 0ft (+/- 0ft), cover 0, turb 0, ice 0 148735 Results: FS98 Cloud2: type=0, from 0ft to 0ft (+/- 0ft), cover 0, turb 0, ice 0 148735 Results: FS98 Temp0: to 80ft, Day 15.0C, NightVar 0.0C 148735 Results: FS98 CurrTemp at PlaneAlt=92: 41C Please ignore the label "FS98". that's referring to the setting of the old (since FS98) offsets in FSUIPC. As I said earlier, I'm not sure what +VCTSRA means, but without clouds i cannot see how you expect thunder? However, the Sim is put into Global weather mode, and the surface wind you requested has been set. But how, in that loop, are those variables being changed? In other threads? I still think you may need to allow a little time for the chnge in weather. However, have you bothered to check the Wind afterwars. When you say "no change in weather", what are you starting with? Pete
  24. Now you are constantly asking P3D5 to set its position the aircraft 100 times a second, not giving it any chance ot do anything with the weather in any case. Why are you setting the same position etc 100 times per seocnd? Try without the rest. Just see if your METAR is accepted by P3D. Do nothing else! I suspect it won't be regarded as a valid METAR string, so ignore it. But you'll need to check that with a Simconnect log. (You've got FSUIPC weather logging turned off?) Please do refer back to my suggestions earlier today. Pete
  25. So you are setting Global weather mode and the same Metar 100 times a second, and then wondering why P3D doesn't get time to change? Just set Global once and only set weather when it changes. There's no sense in simply looping forever setting the same thing and certainly not 100 times a second forever! 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.