
ark1320
Members-
Posts
675 -
Joined
-
Last visited
-
Days Won
17
Everything posted by ark1320
-
John, thanks for the info. I had tried some presets (like View Left) but they send the same K event as in my Lua script above and didn't work. I will have to work with the Asobo default view bindings I think. Regards, Al
-
Using FSUIPC7 in the usual way I have tried assigning both keys and buttons to different cockpit views such as View_Up, View Down, View_Left and View_Right without success. It could be I'm suffering another "senior moment" (more like a senior day in this case 🤔 ). I have also tried using calculator code and presets, all to no avail. I frequently use a little Lua script to test things, and an example is below. I know the script runs because the test message at the end of the script is displayed as expected. When this script runs, just as when I try assigning a button or key to a view, nothing happens as far as the view from the aircraft is concerned. I have tried different aircraft with the same result. Other FSUIPC7 key and button assignments are working. The Asobo control bindings for the views also work. If you have an idea on what I might be doing wrong or overlooking, or you have successfully assigned a key or button to execute a "view command" using FSUIPC7 ver 7.4.16 without the same key or button also being assigned to a default Asobo view command, please let me know. Thanks, Al Here is my Lua test script: ipc.execCalcCode(" (>K:VIEW_LEFT) ") -- view left ipc.sleep(2000) ipc.control(65680) -- view left ipc.sleep(2000) --*************** Window to Display Test Message ***************** w = wnd.open("MSFS_Test", WND_FIXED, 20,90,600,20) -- Script uses FSUIPC Window (wnd) library for message display -- These set the colors and font to be used. -- The size "-1" means the largest font to fit 1 line(s) inside the window wnd.backcol(w, 0x000) -- black wnd.textcol(w, 0x6C0) --green wnd.font(w, WND_ARIAL,-1) wnd.clear(w) -- clear window wnd.text(w, " MSFS TEST SCRIPT " ) -- Getting this message shows code above ran ipc.sleep(2000) wnd.clear(w) -- clear window
-
It might also we worth checking that AUTO-RUDDER under Assistance Options > Piloting didn't get turned on. I have found that sometimes some of these sim assistance settings get automatically reset for some strange reason. Al
-
MSFS Garmin GFC 500 AP: Synch the HSI heading bug to current heading
ark1320 replied to Guido's topic in FSUIPC7 MSFS
Just to be clear, this Lua script will not sync the heading bug to the aircraft current magnetic heading in all cases. For example, if the NAV/HSI is in GPS mode, the value in offset 0x2FA8 seems to be the bearing to the next GPS waypoint in the flight plan, which may not be the current aircraft magnetic heading. Al -
MSFS Garmin GFC 500 AP: Synch the HSI heading bug to current heading
ark1320 replied to Guido's topic in FSUIPC7 MSFS
-
MSFS Garmin GFC 500 AP: Synch the HSI heading bug to current heading
ark1320 replied to Guido's topic in FSUIPC7 MSFS
I don't have the GFC500 AP, but the below works with the Flysimware Lear35, and with the C414 which has a Garmin 605 AP. A user defined preset: SYNC_HDG_BUG_TO_CURRENT_HDG#(A:PLANE HEADING DEGREES MAGNETIC, degrees) (>K:HEADING_BUG_SET) or basically the same thing as a one line Lua script called SyncHeadingBug.lua ipc.execCalcCode(" (A:PLANE HEADING DEGREES MAGNETIC, degrees) (>K:HEADING_BUG_SET) ") Al -
I don't have the FENIX A320 aircraft, but I see FSUIPC7 makes LOTS of Fenix Presets available for assignment to a key or button, so suggest you look through those to see if there are some that you can make use of. And yes, Lua scripts are also a possibility if you can determine what the relevant Fenix A320 control variables (e.g., Lvars, Hvars, etc ) are for the functions you are interested in. Al
-
Help with Controls - testing with SET_EXTERNAL_POWER
ark1320 replied to DaveSCUSA's topic in FSUIPC7 MSFS
Ah, a hex mask. That makes perfect sense, I should have realized that, and it explains why the offset byte value 00000001 gets toggled to 00000000, and vice versa. Thanks John. Al -
Help with Controls - testing with SET_EXTERNAL_POWER
ark1320 replied to DaveSCUSA's topic in FSUIPC7 MSFS
Did some experimenting to see if I could figure out how assigning an input event to an offset worked ... I assigned the input event ELECTRICAL_ExternalPower_1 as an unsigned byte to an available offset A080 in the general section ( I don't fly the Longitude so I don't have a specific profile for it ) of my FSUIPC7.ini file as shown below: [InputEventOffsets] 1=ELECTRICAL_ExternalPower_1=UB0xA080 Then in the FSUJIPC7 key assignments window I assigned the U key to toggle the bit(s) in that offset as shown below: Somewhat to my surprise this worked -- after restarting FSUIPC7 the U key did toggle the Longitude's external power on and off. I defined the offset as a byte because I thought the input event goes between 0 and 1. Although this worked, there are couple of things I'm not sure about: - I found the Parameter value of 1 is required, I assume because this external power function seems to need a circuit index of 1. Or is the Parameter being used in some other way? Maybe I missed it, but I didn't see anything in the manual that explained how the Parameter value is used in an Offset operation like this. - I think of the input event as toggling between 0 and 1. But if byte A080 holds a decimal value of 1, which would be 00000001 binary, then toggling those bits with the offset toggle bits operation would give a value of 11111110 binary, not 00000000 = 0. So not sure how this all works. Al -
Help with Controls - testing with SET_EXTERNAL_POWER
ark1320 replied to DaveSCUSA's topic in FSUIPC7 MSFS
If it helps the investigation here, I tried both of the above (assigned a different key to each one) and they both work to toggle the Longitude's external power on and off. Al -
Help with Controls - testing with SET_EXTERNAL_POWER
ark1320 replied to DaveSCUSA's topic in FSUIPC7 MSFS
I think that would be very useful. Al -
Help with Controls - testing with SET_EXTERNAL_POWER
ark1320 replied to DaveSCUSA's topic in FSUIPC7 MSFS
I have no experience with the Longitude, but it seems from the log file entry for the VC button that works you need two parameters both equal to 1 to turn the ext power on. The USB key function that doesn't work seems to be using parameter values of 0 and 1 (which I think is the reason for the two entries), which turns the ext power off. The SDK shows this: So, for example I found: ipc.execCalcCode(" 1 1 (>K:2:SET_EXTERNAL_POWER) ") will turn the external power on, and ipc.execCalcCode(" 0 1 (>K:2:SET_EXTERNAL_POWER) ") will turn the external power off, where the red 1 is the circuit index value (based on the systems.cfg file entry) and the green 1 and 0 are the On & Off data values. However, I subsequently noticed there is an existing FSUIPC7 Preset called LONGITUDE TOGGLE EXTERNAL POWER SWITCH -- why not just assign a key to that (with no repeats)? Also, be aware that not all sim parking places/gates have external power available. Al -
Black Square King Air 350- "PITCH TRIM AP/YD" и " AP ENG" FSUIPC events ?
ark1320 replied to SMN204's topic in FSUIPC7 MSFS
Hi John, Just curious on how you make use of the open console window as suggested above. Entries in the window go by so fast I'm not able to really see what is happening. Is there something I should be doing to make better direct use of an open console window? Or is the idea just that if it looks like maybe something happened in the console window when you activated a button or clicked with the mouse, then you should go open the log file to see if you can find something related to your action? Thanks, Al -
Yes, of course! Thanks for catching that.
-
John, How does the control ipc.control(0x1151) work? Does it automatically detect if auto-save is active and if so, disables it. But if auto-save is disabled, the control will activate auto-save? Or do you write a 1 or 0 with the control to toggle auto-save on and off? Is there a way within a Lua script to detect if auto-save is running (active)? Thanks, Al
-
I added ignoreDevice=0xFFFF,0xFFFF into the [Joy Names] section of the FSUJIPC7.ini file and then reran the FSUIPC7.7.4.12 installer and started the sim. The Fulcrum yoke worked. BTW, the Logitech joystick was not plugged in, so that's why it was "missing". Al FSUIPC7.ini FSUIPC7.log InstallFSUIPC7.log
-
John, The above FSUIPC7.exe file you posted has fixed the Fulcrum yoke issue for me. Thank you. Does this give you the info you need, or would you still like me to go back and reinstall ver 7.4.12 and then insert IgnoreDevice=0xFFFF,0xFFFF into the [Joy Names] section of the FSUJIPC7.ini file to see if that works also? Al
-
For some reason the latest version of FSUIPC7 will not recognize my Fulcrum yoke, so the FSUIPC7.ini file shows "Missing Joystick". I have had this yoke for well over a year and this has not been a problem before. If I use an older version of FSUIPC7.exe the yoke works as expected. The FSUIPC7.log file shows this: 422 Product= Fulcrum One Yoke 422 Manufacturer= Vitaly [mega_mozg] Naidentsev 422 Serial Number= MMJoy2-Fulcrum-03 422 Vendor=0000, Product=0000 (Version 0.1) 422 **** Ignoring device with VendorId=0000, ProductId=0000 **** What suddenly trigger this type of problem? Older log files show the Vendor and Product 0000 Ids did not cause a problem. The complete FSUIPC7.log file is below. Thanks, Al FSUIPC7.log
-
Hmm... Interesting, I have been installing FSUIPC7 there for years without a problem. Until today I did not realize there were install options between using MSFS .bat and the EXE.xml file. I guess previously the installer defaulted to the EXE.xml option which I use, but now defaults to using the MSFS.bat file. I only included my MSFS.bat file above because I saw you had requested it from a previous poster -- I didn't realize that was an install option. So I have selected the EXE.xml option and all is working now, thanks very much for your help. Al
-
An exclamation point at the start of a line also works to indicate a FSUIPC7.ini file comment, for example: ! PY,1,C66289,0 -{SYNC_FLIGHT_DIRECTOR_PITCH}- no longer used I have been using the ! to comment FSUIPC.ini files for years, but now can't find a reference to it, and don't know where I first saw this. 🤔 The # stands out better than the ! so maybe I will replace all the ! with # to comment out whole lines, and use the ; just for inline comments as I do now. Thanks for the info, John. Al
-
Generally, Avars and Lvars require the > only if you are trying to write (store) a value into them. K events do usually have a > before the K. In this case I think of the > as meaning "activate" the event. Sometimes, but NOT in presets or calculator code, the > symbol will be replaced with > meaning "greater than". I'm not sure what the 60 represents in the above, but note that one radian is about 57.29 degrees, so 10 degrees is about 0.17 radians. Also, often you can change the units a variable uses, so you may be able to write the Avar (A:ELEVATOR TRIM POSITION, radians) as (A:ELEVATOR TRIM POSITION, degrees) which may be more convenient in your particular application. Al
-
Some observations: 1. Min and Max should be min and max. 2. According to the SDK, the value of (A:Elevator Position, number) goes only from -16K to 0. 3. Given the range of (A:Elevator Position, number) above, unless the Elevator_Angle_Trim value is less than - 16255, (L:Elevator_Angle_Trim, number) 128 - -16383 min will be -16383 and then you are putting that into (A:Elevator Position, number). It will then get more negative from there when the preset repeats and it seems you will almost immediately exceed the negative range of (A:Elevator Position, number). Don't know if that is OK. 4. Given the range of (A:Elevator Position, number) above, (L:Elevator_Angle_Trim, number) 128 + 16383 max will be 16383, and then you are putting that into (A:Elevator Position, number) which supposedly has a max value of 0. And the value you are putting into (A:Elevator Position, number) will get more positive when the preset repeats. Don't know if that is OK. 5. It would seem the Lvar (L:Elevator_Angle_Trim, number) located after the Min and Max operators is missing a > before the L: (unless I misunderstand what you are trying to do). 6. I have some timing concerns about trying to update an Lvar and them immediately using the new Lvar value in the next operation in the same preset. I would have to test that to see if it would work reliably. 7. While the presets are updating the value of the Avar (A:Elevator Position, number), I assume the sim might be doing that also, so how the dual updating will work is not clear to me. Any needed corrections to the above are welcome. Al
-
Johm, Above worked for me, tried it 3 or 4 times. Question: If at some point auto-tuning doesn't work and values are set manually for the startup parameters, the next time FSUJIPC7 starts will those manually set parameter values be over written by the auto-tuning, or does the auto-tuning code check the FSUIPC7.ini file for those parameters? Thanks, Al
-
Problems with COM-Frequency assignments with FSUIPC
ark1320 replied to jonas_llubi's topic in FSUIPC7 MSFS
Yes, that's what I meant by the current com freq spacing (channel spacing) -- 8.33 or 25 KHz. Thanks, Al