Jump to content
The simFlight Network Forums

ark1320

Members
  • Posts

    603
  • Joined

  • Last visited

  • Days Won

    14

Everything posted by ark1320

  1. My FSUIPC6.ini file has somehow ended up with two "General" sections, one headed by !1=![General] and one headed by just [General]. I would guess this is not normal and don't know how it happened. Are the entries under !1=![General] actually being used? Should I delete one of these General sections? Thanks for any advice on this. A;
  2. OK, I understand, thanks very much for the feedback! Al
  3. Can an instruction like event.key() be used inside a processing loop to act like an interrupt in other languages? I would like to detect a key stroke while a while true do loop is processing, and after the function associated with event.key() has finished, I want the processing loop to continue. Thanks, Al
  4. I assume the above means all single and double floating point values are noted as such, and all others are integers. Thank you, very helpful! Al
  5. Some offsets specify the numerical format of the value in the offset, but others do not. Just for example, the offset for Indicated airspeed shows: 02BC 4 IAS: Indicated Air Speed, as knots * 128 So the question that comes up is should this 4 byte (32 bit ) value be read using ipc.readSD(), ipc.readUD(), or ipc.readFLT()? Since the format is not specified for this offset (while the format for some other offsets are) is there an implication that any of the above ipc.read instructions will work and the Lua interpreter will make the necessary conversion, or do you have to read and display the value to see what it looks like, or what? Would appreciate any general guidance for these type of situations. Thanks, Al
  6. AutoThrottle_TJ.lua, AutoThrottle_TP.lua and AutoThrottle_CRJ.lua are simple PID (Proportional, Integral, Derivative) implementations of an Autothrottle for TurboJet, TurboProp, and the AeroSoft CRJ aircraft, respectively (the Aerosoft CRJ is somewhat of a special case because of unique throttle coding). These scripts work reasonably well on the Flysimware Learjet35A, Falcon50, MU-2, and on the Aerosoft CRJ aircraft. I have been told the Autothrottle.TJ script works with the Aerosoft DC-8. I'd be interested in hearing how these scripts work on other aircraft. There are parameters at the top of the scripts that you can experiment with if necessary for a particular aircraft. The TurboJet and TurboProp scripts assume standard FSX or P3D throttle coding and should work for aircraft with up to four engines. To try out an autothrottle put the script in your modules folder and use FSUIPC in the usual way to assign a key or button to the appropriate script to activate it. When activated a window will open asking for a target IAS between 50 and 500 Kts. Of course you need to use a target IAS that is reasonable for the a/c. If the A/T is running you will need to call the script again to change the target IAS, or to turn the A/T off by entering a * instead of an airspeed value. You could also use the FSUIPC LuaKill option to quickly exit a script. It is best that the AP is on and the a/c is stable and reasonably close to your target IAS when the A/T is activated. If you ask for large IAS changes it can take a while for the IAS to finally settle down. When the A/T is running you will see a green bar across the top of your screen with the target A/T IAS. Note that you can grab the right side of the green bar with your mouse and resize the bar down to a small display. You can also drag and reposition the green bar to where you want it. AutoThrottle_CRJ.lua AutoThrottle_TJ.lua AutoThrottle_TP.lua
  7. That was it, and I don't even know where those particular quotes came from -- I only have one quote key on my keyboard. I guess it was the font I was using at the time. Thank You, John! Al
  8. Members 5 213 posts LocationColorado, USA Report post Posted 15 minutes ago I can't get the simple Lua test script below to work. I have assigned a key to load the script, and IF I comment out the event.button line, the script at least loads and I get the "Loaded" message. However, with the event.button line in, apparently the script does not even load since I do not get the "loaded" message, and there is no response to a button push. The event.button joystick arguments of 1, 1 are the joy# and button# I get in the FSUIPC6 Button and Switches window when the corresponding button is pushed. I have also tried replacing the first 1 argument with its joy letter in quotes, "J", but that does not seem to make any difference. Below are the joystick assignments from the FSUIPC6.ini file. I cannot figure out what I'm doing wrong. Thanks for any ideas. Al Win10/64 P3D4.5HF3 FSUIPC6.08 [JoyNames] AutoAssignLetters=No J=Logitech Extreme 3D J.GUID={EC24C380-3676-11E3-8001-444553540000} R=Saitek Pro Flight Rudder Pedals R.GUID={F5D4F4C0-FF57-11E5-8001-444553540000} Y=Saitek Pro Flight Yoke Y.GUID={F5D4F4C0-FF57-11E5-8002-444553540000} B=BU0836A Interface B.GUID={D89CA0A0-B3FD-11E6-8001-444553540000} 1=Logitech Extreme 3D 1.GUID={EC24C380-3676-11E3-8001-444553540000} 2=Saitek Pro Flight Rudder Pedals 2.GUID={F5D4F4C0-FF57-11E5-8001-444553540000} 3=Saitek Pro Flight Yoke 3.GUID={F5D4F4C0-FF57-11E5-8002-444553540000} 4=BU0836A Interface 4.GUID={D89CA0A0-B3FD-11E6-8001-444553540000} Lua Test Script function Taxi_Test(a,b,c) ipc.writeSTR(0x3380, " TAXI "); ipc.writeSW(0x32FA, 4); ipc.sleep(4000) return end -- Main program ipc.writeSTR(0x3380, " Loaded "); ipc.writeSW(0x32FA, 3); ipc.sleep(3000) event.button(1,1,3, “Taxi_Test”)
  9. I tried turning on VSync and TB but unfortunately still get the flickering. I don't use ViewGroups. Al
  10. I did post on the L-M forum and they reported they are aware of the problem and are working on it. I've now determined the menu flicker rate is proportional to FPS. When I have FPS locked at 30 in the sim I get the flicker about every 11.6 seconds. If I lock the FPS at 60 and use a default a/c so I can get about 60 FPS on average, the menu flickers about every 5.7 seconds. If I lock the FPS at 15, the menu flickers about every 22.8 seconds. So double the actual FPS and the flicker rate doubles; half the actual FPS and the flicker rate is half. I have VSYNC and TB off. As for the Enhanced Atmospherics (Beta) texture option, I also get small white flashing at times. I guess that's why it's only a Beta. Al
  11. Pete, thanks for the info. I am using the latest version of the log lvars script and "Message Text" is ticked. I think the issue is there is something strange going on display-wise with P3Dv5HF1 on my system. I use the sim in window mode, and about every 11 secs or so the P3D menu bar across the top of the screen is apparently being updated for some reason because the menu labels like Options, Tools, Views, World, Navigation, etc flicker, although the aircraft display itself does not flicker. A couple of other users have reported this as well on the AVSIM P3D forum. So I suspect this updating may be interfering with the log lvars display, and using the ipc.setdisplay(SET_PCTS, 10,10,20,20) in the log lvars display loop lets the script regain control of the display window. Putting ipc.setdisplay(SET_PCTS, 10,10,20,20) outside the display loop, such as at the top of the script, does not work. At least that's my theory for now. I have been using FSUIPC for many years and really do appreciate the wonderful support you, and now also John, provide -- none do it better! Al
  12. I have been unable to get the log lvars.lua script to completely work in P3Dv5 HF1. I am using the add-ons.xlm method with FSUIPC6 and have set up an identical structure to that which I use in P3Dv4.5 HF3 where the log lvars script does work. I wondering if some change between P3Dv4.5 HF3 and P3Dv5 HF1 is causing a display problem , or if I'm doing something wrong. When I try to run the log lvars script no window opens on the screen (although I do get a log lvars.log file). EDIT: I have now found that if I add the instruction ipc.setdisplay(SET_PCTS, 10,10,20,20) before the existing ipc.display(disp) instruction in the log lvars.lua script I do get a scrolling lvar window display. So apparently the added instruction is triggering the display somehow (or maybe it is a positioning issue). In any case, this is not needed in P3Dv4. Are some of the window display 'rules' different in P3Cv5 HF1 compared to P3Dv4.5 HF3? Thanks, Al
  13. Hi Tom, Thanks for clearing things up for me. As you said, the key question when setting up the add-on xml structure is to ask yourself "where does the FSUIPC6.dll expect files to be?". So in case it helps others, here are two structures that I found work where the overall add-on is called FSUIPC6 in the Prepar3D v4 Add-ons ( or Prepar3D v5 Add-ons ) directory. Structure 1 So here all the FSUIPC6 files are on the same level as the add-on.xml file itself, along with the two Lua files (I've only shown two of my 50+ Lua files here). In other words (and as you said) the contents of the 'old' modules folder is simply moved to the same level as the add-on.xml file. In this case the add-on.xml file looks like this: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <SimBase.Document Type="AddOnXml" version="4,0" id="add-on"> <AddOn.Name>FSUIPC6</AddOn.Name> <AddOn.Description>Flight Simulator Universal Inter-Process Communication version 6</AddOn.Description> <AddOn.Component> <Category>DLL</Category> <Path>FSUIPC6.dll</Path> </AddOn.Component> </SimBase.Document> Structure 2 Here all the FSUIPC files and Lua files from structure 1 have been moved inside a Modules folder, and so we need to change the <Path> entry to point to where the FSUIPC6.dll file is. The add-on.xml now looks like this: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <SimBase.Document Type="AddOnXml" version="4,0" id="add-on"> <AddOn.Name>FSUIPC6</AddOn.Name> <AddOn.Description>Flight Simulator Universal Inter-Process Communication version 6</AddOn.Description> <AddOn.Component> <Category>DLL</Category> <Path>Modules\FSUIPC6.dll</Path> </AddOn.Component> </SimBase.Document> In both structures above the FSUIPC6.dll, FSUIPC6.ini and Lua files are all 'together' at the same level as the FSUIPC6.dll file expects -- just as you advised. I happen to prefer the structure with the Modules folder. It seems a bit neater to me, probably because I have a lot of Lua files. If you see any issues with the above please advise, and thanks again for the help! Al
  14. I use a lot of Lua scripts and am trying to figure out how best to use the add-on.xml method with the scripts. Do I need to move all the Lua scripts out of the 'typical' models folder in the sim's directory to the add-on.xml location in the documents directory? I tired to simply point to the sim's modules folder with an add-on xml component entry like: <AddOn.Component> <Category>Scripts</Category> <Path>C:\P3Dv4\Modules</Path> </AddOn.Component> but that didn't work. I also tried to add a modules folder to the FSUIPC6 add-ons file structure but that also didn't work. What is the best way to incorporate Lua scripts with the add-on xml method? Thanks, Al
  15. Hi Thomas, Thanks for the reply. I do understand the numerical precision differences in the offsets, but I don't think the above quote is correct. The P3D SDK shows the max values for both NAV CDI:index and HSI CDI NEEDLE as + - 127, and for both NAV GSI:index and HSI GSI NEEDLE as + - 119. So given numerical precision aside, I think there is a typo in the FSUIPC5 documentation for offset 2AB0 which is currently listed as 2AB0 4 NAV1 glideslope needle (GSI), 32-bit float value, –127.0 up to +127.0 down. According to the SDK the values should be + - 119.0. In summary, the lateral needle range is + - 127, and the vertical needle range is + - 119. Or else I'm really not understanding something. Thx, Al
  16. The FSUIPC5.15 Offsets Status documentation shows: 0C48 1 NAV1 Localiser Needle: –127 left to +127 right 0C49 1 NAV1 Glideslope Needle: –119 up to +119 down 2AAC 4 NAV1 course deviation needle (CDI), 32-bit float value, –127.0 left to +127.0 right 2AB0 4 NAV1 glideslope needle (GSI), 32-bit float value, –127.0 up to +127.0 down Two questions regarding the above: 1. Are offsets 0C48 and 2AAC essentially the same except for the number format/precision? and likewise 2. Are offsets 0C49 and 2AB0 essentially the same except for the number format/precision and the range specified in 2AB0 should be + - 119 as in 0C49 (i.e., the + - 127 in 2AB0 is a typo)? I do realize full scale CDI deviation for a VOR signal is 4 times that for a localiser in terms of degrees, but I'm assuming the sim accounts for this and both full scale deviations will be represented by the + - 127 values. Thanks, Al
  17. Ok, understand. My scripts do make good use of both the single line and multi-line display facilities. As an aside, although there is almost no meaningful information available yet, I fully expect the ability to write scripts will be just as important in the new MSFS sim as it is in P3D. So I'm really hopeful that in about a year or so from now I will be able to go on line and BUY the new FSUIPC6 for MSFS at SimMarket!! Best, Al
  18. Hi Pete or John, I am using Win10, P3Dv4.5, and FSUIPC5.15 A lot of my Lua scripts display values either on the 'green bar' display, or in a simconnect window. For a particular Lua script, I am trying to find a way so that the value it displays remains displayed and is not overwritten by the displays of my other Lua scripts. In FSX there was the 'setowndisplay' option, but unless something has recently changed my understanding is this does not work in FSUIPC5 because there is only one simconnect display window shared by all scripts. Is this still the case or is there a way to prevent a value displayed from one particular Lua script from being overwritten by the displays of other Lua scripts? Thx, Al
  19. I now have a new update! It seems HIDMacros WILL work with the latest version of P3D4.5 (which includes HF2 I assume) if you make sure to run HIDMacros in Administrative mode. I discovered this after spending most of the day trying some other more complicated SimConnect file approaches that have worked for others to get HIDmacros to work with P3Dv4. Maybe Lockheed Martin made some changes in the latest P3D update ? Al
  20. To update and close the loop a bit for anyone else who tries HIDmacros, it turns out it does work pretty much as expected with FSUIPC in FSX. However, I have NOT been able to get it to work in P3Dv4.5 which was the sim I was initially trying it in. Al
  21. Unfortunately, I have not been able to get HIDmacros to send an altered keystroke to FSUIPC. For example, I can get HIDmacros to send the n key when the A key is pushed on the 2nd keyboard, but although Win10 does get the altered keystroke (n), FSUIPC grabs the original key (A). Al UPDATE 23Oct19: HIDmacros does seem to work with FSUIPC in FSX, but NOT in P3Dv4.5.
  22. Reinhard, John, Thanks very much for the info! I played with HIDmacros a bit. One thing I discovered is it initially seems FSUIPC grabs (traps) a key stroke before HIDmacros does, which presents some problems because, if I understand it correctly, FSUIPC either 'takes some action' based on the key if it has been assigned, or passes it directly on to the sim (P3Dv4.5 in this case). So neither FSUIPC or the sim sees the result of the HIDmacro modification. I will keep experimenting a bit. Al Edit: Now, if a future version of FSUIPC could distinguish between two keyboards/keypads that would be VERY useful indeed! 😉
  23. OK, thanks John. I was hoping it might be possible to make use of the Vendor and Product ID info that a USB HID device provides in order to distinguish between two different keyboards, or between a keyboard that includes a numberpad and a separate external numberpad, especially if the devices were from different manufacturers. Al
  24. I'd like to use two keyboards to increase the available key control inputs without having to use key combinations. Is there a way, perhaps using Lua scripts, to distinguish the inputs from the two keyboards? Thx, Al
×
×
  • 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.