Tips and recommendations for GF rotaries?

[Dirk98]

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.

[Pete Dowson]

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

[Dirk98]

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.

[Pete Dowson]

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

[Dirk98]

Thank you very much, Pete, as always you give the best support far beyond the scope of the software that you developed.

Cheers,

Dirk.

[aua668]

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 steps

local lHDG = math.floor ( ipc.readUW(0x07CC) * 360 / 65536 + 0.5 )

lHDG = lHDG + ipcPARAM
lHDG = math.floor(lHDG  / ipcPARAM + 0.5) * ipcPARAM

if lHDG < 0 then
    lHDG = lHDG + 360
end

if lHDG > 360 then
    lHDG = lHDG - 360
end

lHDG = 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.

Rgds

Reinhard

[Dirk98]

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 steps

local lHDG = math.floor ( ipc.readUW(0x07CC) * 360 / 65536 + 0.5 )

lHDG = lHDG + ipcPARAM
lHDG = math.floor(lHDG  / ipcPARAM + 0.5) * ipcPARAM

if lHDG < 0 then
	lHDG = lHDG + 360
end

if lHDG > 360 then
	lHDG = lHDG - 360
end

lHDG = 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.

Rgds

Reinhard

Reinhard, 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.

[aua668]

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 steps

local lCRS = ipc.readUW(0x0C4E)

lCRS = lCRS + ipcPARAM
lCRS = math.floor(lCRS  / ipcPARAM + 0.5) * ipcPARAM

if lCRS < 0 then
   lCRS = lCRS + 360
end

if lCRS > 360 then
   lCRS = lCRS - 360
end

ipc.writeUW(0x0C4E, lCRS )
[/CODE]

ALT:

[CODE]
-- FSX_IncDecAlt.lua
-- V1.0
-- FSX generic implementation of the ALT increment by ipcPARAM steps

local lAltitudeFeet = ipc.readUD(0x07D4) / 65536 / 0.3048

lAltitudeFeet = lAltitudeFeet + ipcPARAM
lAltitudeFeet = math.floor(lAltitudeFeet / ipcPARAM + 0.5) * ipcPARAM

if lAltitudeFeet < 0 then
lAltitudeFeet = 0
end

if lAltitudeFeet > 60000 then
lAltitudeFeet = 60000
end

lAltitudeFeet = 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.

Rgds

Reinhard

[Dirk98]

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.