TrackIR switch flipping

Allthough i find the idea good by itself, i think it might take you way longer to get to a switch than by the current way it's implemented.

I think that largely depends on how fast you can use the button-cursor-keys.

And then it's the question what takes you longer: looking down, leaving throttle or stick to grab your mouse, not move your head, aim and click or tapping 2 or 3 buttons a number of times.

At least the later has the option to get used to it. As I posted before, after a few flights you know that 3 times right 2 times down + click means you have switched from hi to low rate of fire, without you having even to look down.

All are great ideas. The eye-tracker in the future will be the best option, but for now, being a product of high cost, non-commercial, and not entirely accurate, although there are more precise, it is not feasible.

The idea that speak of Skipper, I find it very interesting, my English is bad and do not know if the will have understood correctly, but what I have understood me as a very interesting alternative.

The best thing would be that these solutions were added, and could choose which to use, alone or in combination.

On the original idea of PhoenixBvo, it has been said that there is a problem with the 3D, because the pointer would go up and down. The solution is easy, creating an invisible mesh of simple shapes, a panel that would not have many bumps, a flat surface, and these problems would not exist.

Sorry for my english.

All are great ideas. The eye-tracker in the future will be the best option, but for now, being a product of high cost, non-commercial, and not entirely accurate, although there are more precise, it is not feasible.

 

The idea that speak of Skipper, I find it very interesting, my English is bad and do not know if the will have understood correctly, but what I have understood me as a very interesting alternative.

 

The best thing would be that these solutions were added, and could choose which to use, alone or in combination.

 

On the original idea of PhoenixBvo, it has been said that there is a problem with the 3D, because the pointer would go up and down. The solution is easy, creating an invisible mesh of simple shapes, a panel that would not have many bumps, a flat surface, and these problems would not exist.

 

Sorry for my english.

I think the problem still does exist, Legolasindar. :(

Your description is the basis of my idea. But the problem with TrackIR is, that the mouse only has a relative position. If you point it at the middle when looking forward down, it obviously points at different switches as if you look left and right.

The other way around, if you want to use a small switch, you have to compensate with the mouse for the movements of your head, g-forces and effects, etc.

Now, think about flying a flying at NOE between buildings, turbulences shake the pilots-view, maybe the rotor is damaged and shakes you even more and you realize you have forgotten to activate that ejection-seat. And now have fun to hit that small switch on the right-backward panel of your cockpit. :crash:

Don't you think BS is going to be a bit more complex in terms of the amount of functions compared to ArmA?

...................

comparing Arma with DCS is like chalk and cheese, imo

I just use smoothing mode and up the sensitivity on my TIR.. no problems holding a steady view then, whilst still having snappy movement if needed.

I've got your ideas, and I have translated into images. I have used the cockpit of the F16, that I know much more than the Ka-50. It is just a draft example, the quality of the menus, the failures of controls or lack of switches are harmless.

I include two examples, one similar to the Armed Assault and other more graphic.

First you press MENU BUTON

When press 2 option, is AUX Left Console, you see this menu.

And you select Chaff and Flare with numbers keys, you see next menu.

And now press next option.

The menu does not ever go away unless we return to press the MENU button. So the selectors with several options or rotational, as the HDG are clickable several times.

OTHER EXAMPLE

This example is much more graphic and clear that we are pressing. After selecting the MENU panel, the hearing can be set at such a panel, to make it easier schedule highlighted, or can it over the panel, without being fixed the hearing, which already requires more programming.

First start same MENU.

But when press panel number button panel is highlighted.

And now when press button, the panel is highlighted specific, displaying the options with numbers.

Sorry for this large post, and my bad english.

In the first instance, we see the behavior of the pointer, marked in green, if you used the mesh real, for the pointer.

In the example that I propose, we use a simple mesh for the movement of the pointer, this way the pointer will not affect the movement of the head, nor dance by the buttons, has a simple and effective movement, the only thing that varies button pressed, the view is that we use, but to be glued to the dashboard, the variation is almost zero.

The scheduling of a simple mesh, and the implementation is easy.

In this picture (I am indeed a Picasso), we see as my system has that little problem of perspective, but it is so low that we will see no seldom, and when it happens one need only move the mouse slightly.

EDITED: Clarify that in my last picture, the picture I made, that is not the Green Point your mouse is the button that crosses in the middle of the line of vision you press the lever. Ie the button that crosses the line of vision actually is a lever that moves when you press the left mouse button.

Sorry for my bad english and I hope that I've managed to explain well.

Excellent post & great pictures to explain our ideas! :thumbup:

The method is similar to the communications-menu.

Another way to implement this and how my original idea was:

Taking your starting point - we choose panel 5.

Now the cursor hops to the upper left button or switch on Panel 5:

Now I push cursor down 3x and Cursor right 1x and the cursor hops to this switch:

Now I click toggle and the switch moves to the next position.

Once I memorized the keycombination Panel 5, 3 down, 1 right, click, I can actuate the switch with just 3 keys in a matter of milliseconds, without even having to look down. It's much more like letting your fingers fly over the controls rather than having to stare down at the switches.

And this macro can also easily be mapped to any HOTAS-button for more common switches.

In the first instance, we see the behavior of the pointer, marked in green, if you used the mesh real, for the pointer.

 

In the example that I propose, we use a simple mesh for the movement of the pointer, this way the pointer will not affect the movement of the head, nor dance by the buttons, has a simple and effective movement, the only thing that varies button pressed, the view is that we use, but to be glued to the dashboard, the variation is almost zero.

 

The scheduling of a simple mesh, and the implementation is easy.

 

In this picture (I am indeed a Picasso), we see as my system has that little problem of perspective, but it is so low that we will see no seldom, and when it happens one need only move the mouse slightly.

 

Sorry for my bad english and I hope that I've managed to explain well.

Great artwork indeed :thumbup:. You think of really sticking the cursor to the cockpit. Even with a simplified mesh, that is still much more complicated than what I tried to explain in post 17 (sorry, I don't have time now to visualise the explanation as well as you did):

The cursor is a vector (= arrow) pointing from the viewport (pilot head) out into the cockpit. As you rotate your head, this vector rotates with it. This makes it harder to keep pointing at something in the pit.

Solution: stop the vector from rotating with your head.

It can still be moved in azimuth and elevation by the mouse, but those angles are relative to the cockpit now, not to the screen/viewport/pilot.

Effect: as you rotate your head the cursor keeps pointing in the same direction. Only moving your head up/down, left/right or forward/backward (translations) causes some cursor movement in the cockpit, but that will IMO be much less of a problem than the rotations.

Advantage: It uses virtually no extra cpu time, the only thing you need is a coordinate frame rotation (multiply by a direct cosine matrix). And it should be very easy to implement into an almost finished product, giving us more chance of actually having it :smilewink: (pleassssseeee ED :)).

What I say to the mesh simple, it is very similar to what you say in the 3D esphere.

You comment on the problem with your idea and the solution can not understand, because of my limited English.

But I think both are great solutions, which do not require high performance to the CPU.

The way to an easier method of using a dinamic 3D cockpit (clickable) is no doubt these ideas, or derived from them.

P.D: Clarify that in my last picture, the picture I made, that is not the Green Point your mouse is the button that crosses in the middle of the line of vision you press the lever. Ie the button that crosses the line of vision actually is a lever that moves when you press the left mouse button.

After I upload the picture I thought that he had not explained well.