Dirk98 Posted June 19, 2012 Report Share Posted June 19, 2012 Guys, could you share your recommendations for programming and fine-tuning GoFlight rotaries (like those on RP48, 166A VRP and many others) via FSUIPC interface? I use GF rotaries for "in-game" rotaries in many add-on planes, like Wilco's 737, iFly 737 and many many others. In principle I know how to assign them in FSUIPC's Joy#/Btn# interface or directly to FS controls when supported, so this is not my question. The problem sometimes is that the resulting movement of the "in-game" rotaries, that require special programming via keystrokes on many add-on aircrafts, is not that smooth, compared to, for example, to generic hdg, crs, alt rotaries supported by default fsx. Is there any fine tuning in FSUIPC for this matter, like a different polling interval and maybe some others? Again, for example, I noticed on some rotaries it's not a very good idea to use different assignments on the slow and fast rotate, but use instead the slow rotate on the both. Please share your methods. Thanks, Dirk. Link to comment Share on other sites More sharing options...
Pete Dowson Posted June 19, 2012 Report Share Posted June 19, 2012 Guys, could you share your recommendations for programming and fine-tuning GoFlight rotaries (like those on RP48, 166A VRP and many others) via FSUIPC interface? I use GF rotaries for "in-game" rotaries in many add-on planes, like Wilco's 737, iFly 737 and many many others. In principle I know how to assign them in FSUIPC's Joy#/Btn# interface or directly to FS controls when supported, so this is not my question. The problem sometimes is that the resulting movement of the "in-game" rotaries, that require special programming via keystrokes on many add-on aircrafts, is not that smooth, compared to, for example, to generic hdg, crs, alt rotaries supported by default fsx. Is there any fine tuning in FSUIPC for this matter, like a different polling interval and maybe some others? Again, for example, I noticed on some rotaries it's not a very good idea to use different assignments on the slow and fast rotate, but use instead the slow rotate on the both. Please share your methods. I don't use any GF ones myself, but generally for dual speed rotaries like those you should at least program both speeds to do whatever it is you need doing, and to both "press" and "release" -- i.e. 8 assignments per rotary, 4 in each direction. You should also try to avoid assigning to keystrokes if at all possible because they are slower to process through Windows into FS and build up to make a queue which will induce overrun. FS controls are best, or the PMDG 737NGX equivalent where available. I don't know what the Wilco and iFly models can use I'm afraid.. Most decent hardware implementations of things like MCP display updating use an internal copy of the value and send an updated value instead of using INCs and DECs. Then they update their own local copy of the value from FS only when there hasn't been a button input for a while -- say half to one second. This gives the smoothest result by far and is the closest equivalent to what you are comparing it with. It can be done for FSUIPC by using Lua plug-in programming, but it isn't suited to non-programmers. If the problem you have is simply that it appears to be missing some rotary "clicks" then, yes, you can increase FSUIPC's button pollng rate. There's a parameter in the main Buttons section of the INI file for that. But it will always be a compromise, for performance. Regards Pete Link to comment Share on other sites More sharing options...
Dirk98 Posted June 19, 2012 Author Report Share Posted June 19, 2012 Very informative answer, thanks, Pete. Just a couple of questions yet: 1. You mentioned 8 assignments per rotarty, 4 in each direction. Sorry, I don't quite understand here as I always dealt with 4 assignments per rotary, 2 in each direction, i.e. dual speed (normal and fast). What are the extra ones that you mentioned? I guess "Control sent when button pressed" and "Control sent when button released". Could you please give an example of using the latter one for programming a rotary? What could be useful to put in there ("released" window)? 2. Usually when I can't use FS controls in an add-on plane and I don't want to use keystrokes assignments (offered by the developer) I use Mouse Macros (L/R mouse buttons, wheel fwd/back). Is using of Mouse Macros generally faster than assigning to keystrokes (if offered by developers)? This may be particularly important for rotaries. H/w buttons are not really a problem. 3. You mentioned the use of Lua plug-in programming for FSUPC, does LINDA provide something similar? I'm thinking of studying LINDA but if it's just a different GUI for FSUIPC, I'll stick to using FSUIPC interface. Sorry, I may well be wrong here in my understanding of what LINDA really is. Thanks, Dirk. Link to comment Share on other sites More sharing options...
Pete Dowson Posted June 19, 2012 Report Share Posted June 19, 2012 1. You mentioned 8 assignments per rotarty, 4 in each direction. Sorry, I don't quite understand here as I always dealt with 4 assignments per rotary, 2 in each direction, i.e. dual speed (normal and fast). What are the extra ones that you mentioned? I guess "Control sent when button pressed" and "Control sent when button released". Could you please give an example of using the latter one for programming a rotary? What could be useful to put in there ("released" window)? The same as in the "press". You are forgetting how a rotary encoder works, or perhasp you don't know. Each click either makes contact or breaks it, so it is either a "press" or a "release". It isn't like a button which is only "pressed" when you press it. A rotary encoder can stay pressed or released depending where it was when you stopped turning it. So, if you don't program both press and release you are only using half the "clicks". 2. Usually when I can't use FS controls in an add-on plane and I don't want to use keystrokes assignments (offered by the developer) I use Mouse Macros (L/R mouse buttons, wheel fwd/back). Is using of Mouse Macros generally faster than assigning to keystrokes (if offered by developers)? Yes, they will be as they make direct calls into the gauge code. They don't even send any messages, and they don't call SimConnect or send keystrokes. Just direct execution of the same gauge code which would have been executed if you'd clicked the mouse on the switch instead. 3. You mentioned the use of Lua plug-in programming for FSUPC, does LINDA provide something similar? I'm thinking of studying LINDA but if it's just a different GUI for FSUIPC, I'll stick to using FSUIPC interface. Sorry, I may well be wrong here in my understanding of what LINDA really is. LINDA appears to use a mixtures of all sorts of things, but, yes, particularly Lua plug-ins. However, i don't know much about it and I certainly don't know if it implements value storage and updates as opposed to using INC/DEC controls. It probably varies. LINDA has its own suport forum I think. Best ask about such things there. Regards Pete Link to comment Share on other sites More sharing options...
Dirk98 Posted June 20, 2012 Author Report Share Posted June 20, 2012 Thank you very much, Pete, as always you give the best support far beyond the scope of the software that you developed. Cheers, Dirk. Link to comment Share on other sites More sharing options...
aua668 Posted June 20, 2012 Report Share Posted June 20, 2012 Hi, Here an example for a routine I am using with GF rotaries to set the heading. You can call this routine with different ipcParam values (+1, -1, +10, -10, etc.) for the various speed levels. I am assigning just the LUA script with the parameter for button press and for button release via the FSUIPC interface to the rotary: -- FSX_IncDecHdg.lua-- V1.0-- FSX generic implementation of the HDG increment by ipcPARAM stepslocal lHDG = math.floor ( ipc.readUW(0x07CC) * 360 / 65536 + 0.5 )lHDG = lHDG + ipcPARAMlHDG = math.floor(lHDG / ipcPARAM + 0.5) * ipcPARAMif lHDG < 0 then lHDG = lHDG + 360endif lHDG > 360 then lHDG = lHDG - 360endlHDG = math.floor ( lHDG * 65536 / 360 + 0.5 )ipc.writeUW(0x07CC, lHDG )[/CODE]Maybe you can use this as an example for your needs. Similar functions can be used for CRS, altitude etc.RgdsReinhard Link to comment Share on other sites More sharing options...
Dirk98 Posted August 13, 2012 Author Report Share Posted August 13, 2012 Hi, Here an example for a routine I am using with GF rotaries to set the heading. You can call this routine with different ipcParam values (+1, -1, +10, -10, etc.) for the various speed levels. I am assigning just the LUA script with the parameter for button press and for button release via the FSUIPC interface to the rotary: -- FSX_IncDecHdg.lua-- V1.0-- FSX generic implementation of the HDG increment by ipcPARAM stepslocal lHDG = math.floor ( ipc.readUW(0x07CC) * 360 / 65536 + 0.5 )lHDG = lHDG + ipcPARAMlHDG = math.floor(lHDG / ipcPARAM + 0.5) * ipcPARAMif lHDG < 0 then lHDG = lHDG + 360endif lHDG > 360 then lHDG = lHDG - 360endlHDG = math.floor ( lHDG * 65536 / 360 + 0.5 )ipc.writeUW(0x07CC, lHDG )[/CODE]Maybe you can use this as an example for your needs. Similar functions can be used for CRS, altitude etc.RgdsReinhardReinhard, I've just found this older thread for something else, I never saw your valuable addition to it, thank you very much! I will try to experiment with your lua example and I humbly hope you'll be available for some more questions.Much thanks,Dirk. Link to comment Share on other sites More sharing options...
aua668 Posted August 14, 2012 Report Share Posted August 14, 2012 Hi, As Dirk asked me per PM to post similar code samples for CRS, ALT etc. here are some examples. They follow all the same scheme. CRS: -- FSX_IncDecCrs.lua-- V1.0-- FSX generic implementation of the CRS increment by ipcPARAM stepslocal lCRS = ipc.readUW(0x0C4E)lCRS = lCRS + ipcPARAMlCRS = math.floor(lCRS / ipcPARAM + 0.5) * ipcPARAMif lCRS < 0 then lCRS = lCRS + 360endif lCRS > 360 then lCRS = lCRS - 360endipc.writeUW(0x0C4E, lCRS )[/CODE]ALT:[CODE]-- FSX_IncDecAlt.lua-- V1.0-- FSX generic implementation of the ALT increment by ipcPARAM stepslocal lAltitudeFeet = ipc.readUD(0x07D4) / 65536 / 0.3048lAltitudeFeet = lAltitudeFeet + ipcPARAMlAltitudeFeet = math.floor(lAltitudeFeet / ipcPARAM + 0.5) * ipcPARAMif lAltitudeFeet < 0 then lAltitudeFeet = 0endif lAltitudeFeet > 60000 then lAltitudeFeet = 60000endlAltitudeFeet = math.floor(lAltitudeFeet * 65536 * 0.3048 + 0.5)ipc.writeUD(0x07D4, lAltitudeFeet)[/CODE]By using the offset documentation provided by Pete it should be easy, to extend this to other functions if necessary.RgdsReinhard Link to comment Share on other sites More sharing options...
Dirk98 Posted August 14, 2012 Author Report Share Posted August 14, 2012 By using the offset documentation provided by Pete it should be easy, to extend this to other functions if necessary. Rgds Reinhard That's exactly what I'm trying to attain, thanks Reinhard! Cheers, Dirk. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now