Jump to content
The simFlight Network Forums

Gypsy Baron

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Gypsy Baron

  1. How are you mapping the Kohlsman to the rotary? Direct "SET" will not work as the input needs to be scaled correctly. You could, of course, employ a Lua script to accomplish this. The normal FSX controls "Kohlsman INC" and "DEC" work when assigned to a button/switch. One could use the rotary to send those controls using the "ranges" function, creating a "null" range about the mid-point of the rotary and then an "UP" and "Down" range on either side with the "control to repeat while in range" option selected. I use this method for elevator trim as direct mapping results in too 'coarse' a setting. Also, you did not specify which A2A aircraft you are referring to.I am assuming the C172. Note also, that there is a separate Kohlsman function in the kap140 autopilot which can be accessed using the appropriate L:Variables. Questions regarding the A2A aircraft are best asked in the A2A forums where you might find that others may have asked the same questions.In any case, that is where to get definitive answers regarding A2A aircraft since much of the coding in the Accu-Sim aircraft is done 'outside' of FSX. Paul
  2. It appears that something is setting nthe "Delta" to 32767. That is the amount that the axis input must change before FSUIPC4 will 'see' a change and act on it. At least that is my understanding. Did you adhear to the assignment procedure and press "Delta" and then move the axis a small amount and press 'Delta"? Also, I would check the calibration of that axis before making the assignment to insure that nthe output moves 'smoothly' with the input. Paul
  3. It looks to me like you should consolidate most of those lua functions into one or two .lua files and use event triggers to activate the various functions. You should read the Lua Library PDF to get an idea of the various ways you can trigger functions in lua scripts. I usually wind up with one, or two at the most, lua files for each aircraft that needs special handling via lua scripts. This will save you a whole lot of ini entries to start all those scrips. Paul
  4. You can assign a button or switch to run or re-run a lua script. If you look at the FSUIPC4 Buttons + Switches tab and the drop-down menu for 'FSX command to send' or something like that, there will be entries for each lua script and the various options...run, kill, etc. The menu entries are listed alphabetically so scroll down to the 'l's :) Paul
  5. You should be referring to the Advanced Users Guide PDF as well as the Lua Library PDF. That is where the information for doing most everything resides :) To do what you want to accomplish sounds like all you need to do is scale the output such that the instead of a range of say 0 to 100 you wind up with an output range of 5 to 100. When you assign an axis, in the FSUIPC.ini file the assignment has the min and max values that were set in the FSUIPC calibration. You edit those values with notepad to have a higher minimum output for the axis. That would be very easy to accomplish and test. Another approach would be to use a small lua script to read the axis input and scale it before sending it to the mixture offset. Paul
  6. I, too, have been getting FSX crashes since Ver. 4.927a/b with the very same FSUIPC offset: Fault offset: 0x00013691 Paul
  7. FWIW, I also have been seeing FSX crashes with the fault module ID'd as FSUIPC. I do not have ASN installed or P3DV2. I first noticed the crashes occuring when I installed 4.927b. I've not been able to reproduce the crashes 'on demand' so haven't been able to devine what may be happening. The only observation I have been able to make is that these crashes seem to occur when I am using the switches on my dual Saitek throttle quads which are assigned via FSUIPC and also activate Lua scripts at times. As a result, I have backed out to an earlier version ( 4.924a ) until I can run further test flights. At the moment I have beta test obligations and online multiplayer mission flight obligations, neither of which can tolerate random crashing of FSX. I've not added any new aircraft/scenery/add-ons since the system was last in a 'stable state' and the onset of the random crashes. Once I am able to do some further testing with version 4.927b I'll enable the logging and hopefully something will show up there. My OS is Win7 Pro X64. Paul
  8. I use the auto assign letters option having once been 'bitten' by Windows reassigning the device numbers. My understanding and observations is that the GUID will NOT change for a given device even though it is reconnected to a different port. What WILL change if the number that gets assigned. With the auto assign letters option, the Joy(number) is replaced by Joy(letter) for a given GUID. Since the GUID will never change, the assignment mappings will remain fixed. Paul
  9. First off, you should probably have posted this in the main forum below instead of in 'User Contributions". More folks would see it down there. As a starting point, read the "FSUIPC Lua Library.pdf" to get an idea of what functions are available. You will most likely want to use Lua scripts to accomplish the software to hardware interface. For example, you would first read the current state of the L:Var into a variable. n = ipc.readLvar(“name”) "n" would now contain the value of the L:Var called out by "name" ( "L:some_variable" ) Then, depending upon what the output needs to be, you scale/modify "n" and then write it out to the offset that the hardware expects it to be. value = n ipc.writeSB(offset, value) ipc.writeSD(offset, value) ipc.writeUB(offset, value) ipc.writeUW(offset, value) Paul
  10. You would need to pass the current aircraft heading to the proper OBS or VOR so it would take either a small XML gauge or a Lua script to do it, I think. Here is the XML code for setting the various available KEY events: (A:Plane heading degrees magnetic,degrees) (>K:VOR1_SET) (A:Plane heading degrees magnetic,degrees) (>K:VOR1_SET) (A:Plane heading degrees magnetic,degrees) (>K:VOR1_OBI) (A:Plane heading degrees magnetic,degrees) (>K:VOR2_OBI) (A:Plane heading degrees magnetic,degrees) (>K:HEADING_BUG_SET) Here is a sample XML gauge to set the OBS1. Just change the "55" to the code for the key you would like to use. <?xml version="1.0" encoding="utf-8"?> <Gauge Name="B17G Flare Control" Version="1.0"> <Keys> <On Key="55"> <!-- Key 55 is 7 on the main keyboard --> (A:Plane heading degrees magnetic,degrees) (>K:VOR1_SET) </On> </Keys> </Gauge> Here are ther FSUIPC4 offsets for the various functions. You could use a Lua script to read in the aircraft heading and write it out to the offset you wish to set. VOR1_OBI_DEC 65662 VOR1_OBI_INC 65663 VOR1_SET 65716 <------ Sets OBS 1 VOR2_OBI_DEC 65664 VOR2_OBI_INC 65665 VOR2_SET 65717 <------ Sets OBS 2 Using offsets to obtain the Plane heading degrees magnetic,degrees you would need to read two offsets and subtract the magnetic variation: 0580 4 Heading, *360/(65536*65536) for degrees TRUE. 02A0 2 Magnetic variation (signed, –ve = West). For degrees *360/65536. Convert True headings to Magnetic by subtracting this value, Magnetic headings to True by adding this value. Using XML is much simpler! Paul
  11. In the past I have used the 'user defined' offsets as the 'output' for an internal L:Var. Read the L:Var and write it to the offset. Those offsets are 0x66C0 to 0x66FF The opposite direction can also be implemented...read a user defined offset and send that value to the appropriate L:var. Paul It seems Pete types faster than me :)
  12. Check the Com Library section of the FSUIPC Lua Library.pdf. I think what you will want is this function: n = com.gethidvalue(handle, "axis", str) I've never had the need to use the items in that realm so I can't offer any further insight into what additional steps you need to take. I suspect you will need to 'open' the device using one of these constructs: handle, rd, rdf, wr, initreport = com.openhid(VID, PID, unit, repno) Or handle, rd, rdf, wr, initreport = com.openhid(“vendor”, “product”, unit, repno) I'm sure Pete will be able to give you better direction on this. EDIT: Digging a bit more into the documentation, it may be as simple as using the ipc read facilities, specifically: n = ipc.axis(joynum, "axis") That appears to return the current uncalibrated value of the axis (U for you) of Joynum (1 for you). Paul
  13. You could assign a spare button/switch temporarily to kill the Lua script when pressed and to start the Lua script when released. I use this procedure all the time when I am creating and testing Lua scripts. If you look down the list of assignable commands in the Buttons + Switches drop-down menu you will see several options listed for each Lua script that is loaded. The kail snd start (or maybe run) are listed there. Paul
  14. How are you calling that Lua script? Are you using the event.key function? Does your script define this code in a function .. .. end context? I'm not certain if a space is required in the ("943E",MyData) but you might insert one in any case. ("943E", MyData) Just curious, I don't see those offsets in the "FSUIPC Offsets Status" pdf file. Where did you get them from. Paul
  15. Since I already use the top window bar to display my 'mode' for my controls (offset 0x66C0 - I have multiple 'modes' for each aircraft's button/switch assignments) I needed another way to display the VAS. The log to window is really not a good solution for me as that red text on grean background is extremely difficult to read! (Damn you Microsoft for not making the colors and font size user-definable!!) My soulution was to create a small Lua script that periodically reads 0x024C (ipc.readUD) and than sends the value to the Lua display window (ipc.display). The Lua display window can be positioned wherever you wish on the screen and the text color is white. One can set that display to occur at fixed intervals or when VAS gets below a certain amount or using an event.button or event.key function to allow the display to appear when a button/switch of key-combo is pressed. The display window can be set to remain active for a pre-assigned interval...1,2,3 etc seconds. My Lua script below uses the event.offset to execute the function "VAS" each time that value chages. I assign that value to a local variable, as I use it elsewhere as well, and then output the VAS value to the lua display when it becomes less than 500000. The display remains active for 2 seconds. function VAS(control, vas) vas_in = ipc.readUD(0x024C) ipc.writeLvar("L:VAS", vas_in) if vas_in < 500000 then ipc.display("VAS = "..vas_in,2) end end event.offset(0x024C,"UW","VAS") I have a 2D window for the RaytheonANR75 radar gauge installed in all my aircraft so it is often 'in view'. I used the local variable I used in the Lua script,'L:VAS", to display that value continuously at the top of the radar gauge window. Here is the xml code I inserted into that radar gauge. //------------------- VAS Display ---------------------- <Element id="VASReadout"> <FloatPosition>410.000,20.000</FloatPosition> <GaugeText id="VAS Readout"> <BackgroundColor>0x000000</BackgroundColor> <Bold>True</Bold> <Bright>True</Bright> <FontColor>0xffffff</FontColor> <FontFace>Arial</FontFace> <FontHeight>20</FontHeight> <GaugeString>%((L:VAS, enum))%!07d!%</GaugeString> <HorizontalAlign>LEFT</HorizontalAlign> <Size>70,70</Size> <Transparent>True</Transparent> </GaugeText> </Element> //-------------------------------------------------------------------- So, there are a couple more ways to 'skin a cat', as the saying goes :) Paul
  16. You will need to edit the FSUIPC4.ini file to do that I believe. In most of my aircraft-specific setions I have multiple functions assigned to the same button or switch. As many as 4 in some cases. If you are unsure of the coding needed. just assign each function separately in the Buttons + Switches menu, open the ini file and copy that entry to a temporary text file. Do the same for the other assignments, assigning the same button/switch and noting the ini entry. Then just copy and paste those assignments back into the ini file, changing the entry number, and you should be good to go. Here is a section of my assignments for the A2A B-17G. Note the entries for switches 14, 16 18 and 0 Those switches each have 3 functions when pressed. Button 2 also has multiple assignments as well. !2=//SET 2 STARTERS ENG 1 - 4 CLEAR START & MESH SET 4 PRIMER & PUMP - ALL MACROS 20=B66C0=1 PD,14,CM6:5,0 ;//STARTER ENG 1 - SET PRIMER TO ENG 1 MACRO 21=B66C0=1 PD,16,CM6:5,2 ;//STARTER ENG 2 - SET PRIMER TO ENG 2 MACRO 22=B66C0=1 PD,18,CM6:6,2 ;//STARTER ENG 3 - SET PRIMER TO ENG 3 MACRO 23=B66C0=1 PA,0,CM6:6,0 ;//STARTER ENG 4 - SET PRIMER TO ENG 4 MACRO 24=B66C0=1 PD,15,CM6:7,0 ;//MESH ENG 1 25=B66C0=1 PD,17,CM6:7,2 ;//MESH ENG 2 26=B66C0=1 PD,19,CM6:8,2 ;//MESH ENG 3 27=B66C0=1 PA,1,CM6:8,0 ;//MESH ENG 4 28=B66C0=1 PA,2,CM6:5,1 ;//CLEAR STARTER 1/2 29=B66C0=1 PA,2,CM6:6,1 ;//CLEAR STARTER 3/4 30=B66C0=1 PA,2,CM6:7,1 ;//CLEAR MESH 1/2 31=B66C0=1 PA,2,CM6:8,1 ;//CLEAR MESH 3/4 32=B66C0=1 PA,2,CM6:30,0 ;//SET PRIMER SELCT TO OFF 33=B66C0=1 PA,3,CM6:31,1 ;//ACTIVATE PRIMER 34=B66C0=1 PD,14,CM6:30,1 ;//SET PRIMER SELCT TO ENG 1 35=B66C0=1 PD,16,CM6:30,2 ;//SET PRIMER SELCT TO ENG 2 36=B66C0=1 PD,18,CM6:30,3 ;//SET PRIMER SELCT TO ENG 3 37=B66C0=1 PA,0,CM6:30,4 ;//SET PRIMER SELCT TO ENG 4 38=B66C0=1 PD,14,CM6:37,1 ;//SET FIRE EXT. SWITCH TO ENG 1 39=B66C0=1 PD,16,CM6:37,2 ;//SET FIRE EXT. SWITCH TO ENG 2 40=B66C0=1 PD,18,CM6:37,3 ;//SET FIRE EXT. SWITCH TO ENG 3 41=B66C0=1 PA,0,CM6:37,4 ;//SET FIRE EXT. SWITCH TO ENG 4 42=B66C0=1 PA,2,CM6:37,0 ;//SET FIRE EXT. SWITCH TO OFF Note that I alsom use a 'qualifier' arrangement for my assignments as I have multiple 'control sets' that re-define the functions of all the switches based upon the value in offset 0x66C0. That is my 'mode' number. That is one of the 'compound nutton' assignment methods. I suggest you have a good read of the "FSUIPC4 for Advanced Users.pdf" for the other possibilities. I reffer to that document dfrequently when setting up assignments for a new aircraft or 'enhancing' my current assignments. Note also, that I make use of MCRO files ( the CM6:xx ) entries above to access the local variables (L:Vars) of this aircraft for the non-standard controls. Note also that I use the entry in the ini file below to assign letters to my controllers. This insures that my custom coding will not be 'upset' if Windows reassigns the controller numbers due to a change to your systems controllers, usb hubs or addition of a new controller. This prevents a LOT of headaches should a renumbering occur!! [JoyNames] AutoAssignLetters=Yes Paul
  17. The code most likely uses "L:Variables" to activate that function and requires a parameter of 0, 1 or 2 to be passed to put the switch in the up, middle or down position. I never use mouse macros when I assign my buttons+switches but instead declare the L:Vars in a MCRO file and then pass the correct parameters. It may be possible to pass parameters in your case. You would have to probably use 2 switches unless you have a 3-possition switch. the 'off' (middle) position is probably set with a parameter of "1" if the code uses 0,1 and 2. It is also possible that the code uses 1,2 and 3. In which case a parameter of "2" would set the missdle position. Experiment with each parameter and observe the results. Paul
  18. Let me offer an approach to your modifier quaetion, I use a 'modifier' on all my aircraft to assign multiple controls to the switches on my Saitel Pro dual throttle quads. In some cases I have up to 9 assignments per switch. Think of them as 'modes'. It is simple and allows easy modification and addition of more 'modes' by editing the ini file and using 'cut & paste' actions. The technique uses one of the user-defined offsets to hold the 'mode' number. One switch is assigned to increment the mode number. Each press of the switch increments that number until it reaches the maximum mode number. It then goes back to mode '0'. You COULD have as many as 256 'modes' using this approach. :) The modifier is the "=B66C0=0" part of the assignment statement. The mode switch is defined once per aircraft and below is my top-right-most switch on my quadrants, A,4. I use the assign letters to the joysticks name option so mine are ID'ed as "A", "B", "C" etc. [JoyNames] AutoAssignLetters=Yes Here are the aissignmenys for the same switches on my 2 left-most switches on my quadrants, D,14, 15,16 and 17. [Buttons.Curtiss P-40] 1!==//------- Control Set 1 ----------------- 0=PA,4,Cx510066C0,x00030001 ;//CONTROL SET INC Max = 3 Step = 1 1=B66C0=0 PD,14,C66400,0 ;//Magneto - OFF 2=B66C0=0 PD,15,C66400,2 ;//Magneto - Left 3=B66C0=0 PD,16,C66400,3 ;//Magneto - Both 4=B66C0=0 PD,17,C66400,1 ;//Magneto - Right 2!==//------- Control Set 2 ----------------- 60=B66C0=1 PD,14,C66506,225 ;//Toggle GPS 61=B66C0=1 PD,15,C66506,440 ;//Toggle ANR-75 radar 62=B66C0=1 PD,16,C66506,14992 ;//Toggle AP Chart 63=B66C0=1 PD,17,C65910,0 ;//MAP - TOGGLE (Panel 5) 3!==//--------- Control Set 3 ----------------- 40=B66C0=2 PD,14,C66389,0 ;//Toggle Canopy 41=B66C0=2 PD,15,CM9:1,0 ;//Toggle Gunsight 42=B66C0=2 PD,16,CM9:8,0 ;//Klaxton Test Toggle 43=B66C0=2 PD,17,CM9:10,0 ;//Prestone Test Toggle 4!==//------- Control Set 4 ----------------- 60=B66C0=3 PD,14,C66506,225 ;//Toggle GPS 61=B66C0=3 PD,15,C66506,440 ;//Toggle ANR-75 radar 62=B66C0=3 PD,16,C66506,14992 ;//Toggle AP Chart 63=B66C0=3 PD,17,C65910,0 ;//MAP - TOGGLE (Panel 5) In your current case, simply define one button/switch to change the 'mode' and then just insert "=B66C0=0" in the top assignments and "=B66C0=1" in the bottom assignments. 0=P3,1,Cx510066C0,x00030001 ;//CONTROL SET INC Max = 1 Step = 1 Joy 3, button 1 1!==//------- first 4 of first set ------- 1=B66C0=0 R2,32,C65607,0 2=B66C0=0 R2,36,C65615,0 3=B66C0=0 R2,34,C66277,0 4=B66C0=0 R2,38,C66276,0 2!==//--- first 4 of second set ---------- 71=B66C0=1 R2,32,C65607,0 // NOTE: I see you have duplicated these commands in your 72=B66C0=1 R2,36,C65615,0 // second set. There is no need to do that. 73=B66C0=1 R2,34,C66277,0 //only add the 'modifier' to those switch assignments that are 74=B66C0=1=R2,38,C66276,0 //unique between 'modes'. The others you leave 'as 'is' buy only once. I ususally add my 'global' assignmentsd, those that remain the same in all modes, at the end of the 'Buttons.<plane name> section. Looking at your list again, I see vary few 'different' assignments so your implementation should be quite simple. This method lests you easily add more 'modes' by simply changing the 0=P3,1,Cx510066C0,x00010001 ;//CONTROL SET INC Max = 1 Step = 1 Joy 3, button 1 entry to: 0=P3,1,Cx510066C0,x00020001 ;//CONTROL SET INC Max = 2Step = 1 Joy 3, button 1 and then add the new lines, taking care to adjust the line numbers. 3!==//--- first 4 of third set ---------- 121=B66C0=2 R2,32,<new command> 122=B66C0=2 R2,36,<new command> 123=B66C0=2 R2,34<new command> 124=B66C0=2=R2,38,<new command> Good luck, Paul
  19. Hummm, now this is very strange. That value is staying set now. I have no explanation as to why it was reverting before but it definitely was. I would open FSUIPC and got to the Buttons + Switched tab and simply hit the 'Reload all buttons' option, then 'OK'. The tuning function stopped working and when I opened the ini file again, the entry had changed. I did this several times. It appears to be working just fine now. EDIT: OK, I can reproduce the behavior. It seems that the first time I changed the parameter was after I was already in FSX. I opened the INI file, changed the entry, saved the file and then hit the 'Reload all buttons' option, then 'OK'. This is what I do when changing button/switch assignments when testing or creating my 'aircraft specific' settings. For those operations, the new data is entered and retained in the appropriate section. I don't recall having had the need to change an entry in the "General" section while running FSX before so I never encountered this behavior. It would seem that when the ini file is re-written when FSX is running, the "General" section is retained as it existed at the start of FSX. I just closed FSX, changed the parameter, started FSX and then checked that the 'fix' worked. I reverted the value back to '4' while in FSX, reloaded Buttons + Switches and saw that the previous value of '0' was retained. So, it all comes down to when the value in the ini is actually changed. It must be prior to starting FSX. So, all is well and I learned something. :) Paul
  20. Hello, Pete, I just installed 4921g and changed the entry in the ini file: //TimeForSelect=4 TimeForSelect=0 But, as soon as I do a 'Reload all buttons' operation the ini file reverts back to the default value. //TimeForSelect=4 TimeForSelect=4 On further investigation I find: If I make the ini change and then start FSX the change does work as intended. I can tune the A2A C172 Nav radio Primary channel when that mode is selected. But, as soon as I reload the ini file, say whenmaking a change to asdsignments, etc during testing, the ini file entry reverts to the default value of '4'. This is undesirable. None of the other options that I have changed from default in the ini file are reverting to default. Only this new option. Paul
  21. Bad,boy, Günter, bad boy! :) Dan, glad you are up and running. Last evening I created an addition to my Spitfire Lua script to add the Radiator Lever axis assignment code just to insure that it was easily done, as I use the Input Configurator normally to assign that function. The main difference between my code and Günter's is an attempt to reduce the 'jumping back and forth' when going from one setting to the next due to any 'noise' on the axis. I also assign the axis to write to one of the user-defined offsets and then use an event.offset to trigger the lua function. Here is waht I came up with: function Rad_Flap(control, dummy) Rad_Lever_in = ipc.readSW(0x66C6) Rad_Lever = round(round((Rad_Lever_in+16384)/32768*10)/2) ipc.writeLvar("L:Eng1_RadiatorLeverPos", Rad_Lever) -- ipc.display("Rad Flap = "..Rad_Lever, 1) -- this line for testing only end -- rounds the integer function round(num) num = tonumber(num) if num == nil then return 0 end if num >= 0 then return math.floor(num+.5) else return math.ceil(num-.5) end end event.offset(0x66C6,"SW", "Rad_Flap") The 'double use' of the 'round' function seemed to reduce the 'stuttering' but did not completely eliminate it. Günter and I use slightly different approaches to arrive at the same result :) Paul
  22. There appears to be a missing "end" in the Spifire section. ------------------------------------------------------------- Spitfire elseif string.find(acftname,"Spitfire",0,true) then var = round(((ipcPARAM+16384)/32768*10)/2) --ipc.display(var) --ipc.sleep(50) ipc.writeLvar("L:Eng1_RadiatorLeverPos", var) end <----------- This is the missing 'end'
  23. I can confirm the above observations vis-a-vis the registered vs unregistered behavior. The radio 'direct tuning' works properly when the FSUIPC4 key file is removed, making it an unregistered version. With the key file present, the radio 'direct tuning' feature does not work. Checking the above situations by logging confirms the reordering of the KEY events. Paul
  24. I believe I set mine up to use simconnect. I'm far from my sim computer for the next several days so can't really check this. I do have a copy of Plan-G on this netbook that I have used in the past to connect to FSX over my wifi at home. In Plan-G, under Options I have "Simconnect" selected in the General box. I have the network mode set to IPv4. The local, internal IP for my FSX computer is set "" Server pipe/port is 500 Also, I believe there is an xml file required to be present that has to do with simconnect but I can't find it here at the moment. Ah, here it is... in the Plan-G manual item 20.3 on page 98. (page 90 by the bottom of the page numbers) The simconnct.xml is located on the computer that has FSX running on it. That section explains how to create/edit the simconnect.xml file. Good luck, Paul
  25. The reason you need to rescan is probably due to a noisy axis. That is what FSUIPC4 will see. I have an unused axis on an old joystick that is connected just to allow my old analog rudder pedals to be connected. I have to tell FSUIPC4 to 'ignore' that axis and then re-scan for the axis I am trying to work with. The joy names (letters) is an FSUIPC4.ini file entry that automatically assigns letters to your controllers instead of using the numbers, which are the default method. By using the letters, which are paired with the GUID of the controller, even if Windows reports a different number for a previously programmed controler (due to unpluging a controller or reinstalling FSX or Windows) the letters remain the same and all your programming will continue to work. In the FSUIPC4.ini file find the "JoyNames" sectionand insert the line below as shown: [JoyNames] AutoAssignLetters=Yes [/CODE] See page 26 of the FSUIPC4 User Guide.pdf that should be in your Modules\FSUIPC Documents folder. That will explain the whole operation and the Windows issues it corrects. Paul
  • 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.