To Devs: Regarding trimmer

[Brainless]

...

So please work out a exact instruction in pseudo programming language

and I will try to rewrite it for autohotkey.

 

Here my explanation of the algorithm.

At moment CTPM works in this way:

int JoyX, JoyY, JoyZ; // Real Controls coordinates
int SimX, SimY, SimZ; // Simulated Controls Coordinates
int DeltaX=0, DeltaY=0, DeltaZ=0; // difference between real and simulated controls

bool TrimmerPressed;
enum t_controls_state {TrimmerDeactivated, TrimmerActivated, WaitToCenter} ControlsState;

ControlsState = TrimmerDeactivated;

while(Exit==false)
{
   GetRealControls(JoyX, JoyY, JoyZ, TrimmerPressed);

   switch(ContolsState)
   {
   case TrimmerDeactivated:
       SimX = JoyX + DeltaX;
       SimY = JoyY + DeltaY;
       SimZ = JoyZ + DeltaZ;
       if(TrimmerPressed == true)
       {
           ControlsState = TrimmerActivated;
       }
       break;
   case TrimmerActivated:
       SimX = JoyX + DeltaX;
       SimY = JoyY + DeltaY;
       SimZ = JoyZ + DeltaZ;            
       if(TrimmerPressed == false)
       {
           DeltaX = SimX;
           DeltaY = SimY;
           DeltaZ = SimZ;
           ControlsState = WaitToCenter;
       }
       break;
   case WaitToCenter:
       if ((JoyX == 0) && (JoyY == 0) && (JoyZ == 0))
       {
           ControlsState = TrimmerDeactivated;
       }
       break;
   }

   DoSimulatorStuffs(SimX,SimY,SimZ, TrimmerPressed);

}

 

And I want this little addition:

 

int JoyX, JoyY, JoyZ; // Real Controls coordinates
int SimX, SimY, SimZ; // Simulated Controls Coordinates
int DeltaX=0, DeltaY=0, DeltaZ=0; // difference between real and simulated controls

bool TrimmerPressed;
enum t_controls_state {TrimmerDeactivated, TrimmerActivated, WaitToCenter} ControlsState;

ControlsState = TrimmerDeactivated;

while(Exit==false)
{
   GetRealControls(JoyX, JoyY, JoyZ, TrimmerPressed);

   switch(ContolsState)
   {
   case TrimmerDeactivated:
       SimX = JoyX + DeltaX;
       SimY = JoyY + DeltaY;
       SimZ = JoyZ + DeltaZ;
       if(TrimmerPressed == true)
       {
           ControlsState = TrimmerActivated;
       }
       break;
   case TrimmerActivated:
       SimX = JoyX + DeltaX;
       SimY = JoyY + DeltaY;
       SimZ = JoyZ + DeltaZ;            
       if(TrimmerPressed == false)
       {
           DeltaX = SimX;
           DeltaY = SimY;
           DeltaZ = SimZ;
           ControlsState = WaitToCenter;
       }
       break;
   case WaitToCenter:
       if ((JoyX == 0) && (JoyY == 0) && (JoyZ == 0))
       {
           ControlsState = TrimmerDeactivated;
       }
     [b]  else[/b]
[b]         if(TrimmerPressed)
        {
            DeltaX = SimX - JoyX;
            DeltaY = SimY - JoyY;
            DeltaZ = SimZ - JoyZ;
            ContolsState = TrimmerActivated;
        }[/b]
       break;
   }

   DoSimulatorStuffs(SimX,SimY,SimZ, TrimmerPressed);

}

[PeterP]

Thanks!- this is very accurate - will see what I can do.

[Bucic]

[youtube ]4l_LhCRIRgo

 

A vast majority of these manoeuvres depicted above flown as such.

 

I'm still not sure what this video shows. For example you move your stick 20% left, trim and don't re-center, in a second the game adds (reads) 20% to your actual 20%, you end up with a 20%->40% jerk and this is supposed to be desirable or positive in any sense? Survivable rather.

 

That's for one. Two - I can clearly see the trim bump behavior I've been experiencing and reporting here http://forums.eagle.ru/showthread.php?p=1342096#post1342096 An outright bug if you ask me.

[159th_Viper]

I'm still not sure what this video shows.

 

In that case I'm afraid my usefulness is at an end. As for a possible Bug........Nope, not sure at all about that myself :)

[Dejjvid]

You are bumping all over the place every time you trim Viper, that is what Bucic is writing about, and many other players have complained about. You are fighting the AP all the time, if you can't see that you are bouncing back and forth, i suggest you try to hold the trim down, manouver, then release. Do two identical tracks, then compare.

[159th_Viper]

....You are fighting the AP all the time....

 

As per a previous post by EB:

 

Any pilot input is "absorbed" by the AP. The 20% is actually irrelevant while the pilot is providing input into the controls, exactly because he is not fighting the AP. The AP does not attempt to correct the pilot's own input.

 

This is key - the AP receives two separate sets of signals: one set from the pilot's controls and one set from the stability instrumentation. This allows the AP the "gauge" that the deviations it is receiving from the instrumentation are due to the pilot's input. Really, it doesn't "gauge" anything, but the two signals merely cancel each other out, leaving the AP with nothing to correct.

 

Example: I input left cyclic. The AP begins to receive two signals - one from the controls, telling it that the cyclic has moved to the left and by how much and one from the instrumentation, telling it that the aircraft is banking to the left and deviating from the previously trimmed position. The AP wants to bank the helicopter to the right to bring it back to trim, but because the controls signal is proving it with left cyclic input, the result is no input from the AP onto the helicopter.

[Nate--IRL--]

As per a previous post by EB:

 

This does not occur in DCS. The AP will try to correct for Pilot inputs to maintain the set attitude.

 

EDIT:- EBs explanation would probably closer apply to FD mode though.

 

Nate

Edited November 30, 2011 by Nate--IRL--

[Dejjvid]

If it isn't the AP bumping your heli in your track, you have an ogre hanging from your stubwing trying to get loose...

[Yurgon]

Yes, you got it right.

 

As for you misunderstanding, how on earth was I supposed to phrase it otherwise, keeping in mind the context of the discussion and the OP's problem of 'locked controls'? In any event, no worries - bygones.

 

Going over your posts, it just seemed to me that you said the same thing in the same words over and over again. Rephrasing it or going at it from another angle might have helped; it took me at least one post of my own to figure out what you meant by "no need to re-center".

 

OK - you tell me how the controls are going to be 'locked' with CPTM box unticked - I missed something there. Always willing to be enlightened though.

 

My bad. When mentioning "the same problem" I was thinking of bumping, but I didn't write that.

 

Again, capable of misinterpretation, especially to newcomers to these boards: There is no good reason for you holding the trim button depressed for any length of time for normal flight. As such any mention of 'not accidentally releasing the trim button' is irrelevant when employing the 'Trim-Immediate-Release' method.

[...]

Apart from the penalty imposed by one method, there is no difference. Why subject yourself to the penalty?

 

There is clearly the issue of "bumping" (you may not notice it and it may not affect you, but it exists and is an issue or even a problem for others). AFAIK, CPTM was introduced because of the bumping effect that could appear if the controls are not centered quickly enough. Let's look at it like this:

 

[TABLE]|benefit|penalty

CPTM off|no control locking|bumping may occur

CPTM on|no bumping|locking may occur

[/TABLE]

 

Your solution is to eliminate a penalty by switching from one method to the other, but you neglect that the desired benefit is lost as a consequence.

 

The OPs suggestion, on the other hand, aims at reducing the penalty imposed by one of these methods while retaining its full benefit. IMO that makes sense.