I have the key to One Eyed Willy

Wasp · Post by **Wasp** » Wed Mar 09, 2016 3:54 pm

...or sort of. I think I'll need higher minds on this one.

As many of you know, I've been chasing the elusive bug for some 6+ years now. Something just didn't seem right and the controller precision was lost ever since the introduction of R5. Well, R5 brought so many changes and the "bug" was so subtle, I figured it could be anything causing the problem from input lag to frame rate management or too many hooks or too much crap in the game loop,...

Anyhow, long story short,...while playing around with madpeople & Imago's formula in wintrek.cpp, (Trac ticket #88) I found that if I changed

Code: Select all

yaw = pht->GetMaxTurnRate(c_axisYaw)

to instead use the pitch max turn rate...

Code: Select all

yaw = pht->GetMaxTurnRate(c_axisPitch)

that the problem went away.

Using the pitch max turn rate for both pitch and yaw values, the deadzone feels correct and more round. The precision at very slight input is returned to normal.

btw, Rix still behaves the same as before with this change in place.

My question is this: Given that an IC Int turns the same speed regardless of the angle of pitch/bank, how is it that when using the "yaw = pht->GetMaxTurnRate(c_axisYaw)" we get a different (value returned?) than when we use "yaw = pht->GetMaxTurnRate(c_axisPitch)" in it's place?....makes no sense to me.

If only I knew how to code,..I can find bugs, I just don't know how to fix them.

Wasp · Post by **Wasp** » Thu Mar 10, 2016 3:17 pm

Is it possible that the client is not getting the ships max yaw rate from the cores?

Was there a change in the core layout when R5 was issued?

Could it be that the core is written incorrectly and thus preventing the Maximum yaw rate value from being returned or if the value returned IS correct, then perhaps the formula being applied to the axis' are incorrect??

Code: Select all

//What is the maximum desired rate of turn for this field of view?
//Use the same calculation as for turrets.
//Keep in sync with wintrek.cpp's FOV by throttle
                            
static const float  c_minRate = RadiansFromDegrees(7.5f);
static const float  c_maxRate = RadiansFromDegrees(75.0f);

float zoomMod = fov / s_fMaxFOV; 

const IhullTypeIGC* pht = trekClient.GetShip()->GetHullType();
{    
float pitch = pht->GetMaxTurnRate(c_axisPitch);
float maxSlewRate = c_minRate + (pitch - c_minRate) * zoomMod;
    if (pitch > maxSlewRate)
        js.controls.jsValues[c_axisPitch] *= maxSlewRate / pitch;
}
{
float yaw = pht->GetMaxTurnRate(c_axisYaw);
float maxSlewRate = c_minRate + (yaw - c_minRate) * zoomMod;
    if (yaw > maxSlewRate)
        js.controls.jsValues[c_axisYaw] *= maxSlewRate / yaw;
}

Could this be a problem in the core(s)?

Wasp · Post by **Wasp** » Thu Mar 10, 2016 6:12 pm

I'm starting to believe this formula is incorrect AND I believe that the cores are not passing the X max turn rate to the client.

Wasp · Post by **Wasp** » Thu Mar 10, 2016 6:48 pm

The code WAS changed!!

Not being a programmer, I'm only guessing here so take this with a grain of salt...

I suspect ticket #88 was created because of the X Max Turn Rate (problem?) and then the slew rate formula was changed to correct that bug?...so we now have two problems?...

Here is the original MS code:

Code: Select all

//What is the maximum desired rate of turn for this field of view?
                                //Use the same calculation as for turrets.
                                //Keep in sync with wintrek.cpp's FOV by throttle

                                static const float  c_minRate = RadiansFromDegrees(7.5f);
                                static const float  c_maxRate = RadiansFromDegrees(75.0f);

                                float   maxSlewRate = c_minRate +
                                                      (c_maxRate - c_minRate) * fov / s_fMaxFOV;

                                const IhullTypeIGC* pht = trekClient.GetShip()->GetHullType();
                                {
                                    float               pitch = pht->GetMaxTurnRate(c_axisPitch);

                                    if (pitch > maxSlewRate)
                                        js.controls.jsValues[c_axisPitch] *= maxSlewRate / pitch;
                                }
                                {
                                    float               yaw = pht->GetMaxTurnRate(c_axisYaw);

                                    if (yaw > maxSlewRate)
                                        js.controls.jsValues[c_axisYaw] *= maxSlewRate / yaw;
                                }

Since we know a max turn rate of 1.0472 is set in both the X and Y max turn rates within the core (for IC Ints), we can hard code those values so that yaw = 1.0472 and pitch = 1.0472

when we do that OR if we simply tell the yaw = pht->GetMaxTurnRate(c_axisPitch), which is equal the yaw value in this case, we get a proper behavior in the x axis.

BAM!

Terran · Post by **Terran** » Fri Mar 11, 2016 4:02 pm

http://i.imgur.com/Ot87GQF.gifv

Wasp · Post by **Wasp** » Fri Mar 11, 2016 4:22 pm

If the X rate is messed up as I suspect, I wonder if any other values are not getting through.

Wonder how this affects torque and speed when applying a non slewed motion in one axis as opposed to the other axis...

If this is verified, it needs to be addressed immediately.

Post by **BackTrak** » Sun Mar 13, 2016 6:26 pm

I've put this fix into a new R7 version and put that onto AU. To test it, you will need to ensure that you have "Use DirectX 7 (R4 Engine)" checked in Preferences in the ACSS launcher. I didn't want to mess with the launcher before SG time, so for now this is just going to be miss-named in the launcher. I'll update it in the next week or two to say "Use Prototype Client Features" so that it's more generic.

How to tell if you're running the prototype:

Launch allegiance, and from any screen, press escape. The version should appear as:

FAZ R7 Build # 16.03.13

This is the 2015/03/13 build that I just made today.

Note, this build is just R7 with Wasp's change in it, and no R4 engine or other modifications.

Wasp · Post by **Wasp** » Mon Mar 14, 2016 12:08 am

You d'man!

thnx

KGJV · Post by **KGJV** » Mon Mar 14, 2016 2:11 am

what core and ship do you use that clearly exhibits the issue ? I'll set up a debug session tomorrow.

is trac down? i can't access #88 to see the history.

Wasp · Post by **Wasp** » Mon Mar 14, 2016 2:27 am

KGJV wrote:QUOTE (KGJV @ Mar 13 2016, 10:11 PM) what core and ship do you use that clearly exhibits the issue ? I'll set up a debug session tomorrow...is trac down? i can't access #88 to see the history.

The best way to see this difference is when using a joystick (of course) when you are moving swiftly from one point to another when you are closest to the deadzone. In the case where you have a Y axis value that differs from the x value, you get a stair climbing effect when you try to execute a slanted maneuver, ie...high left to low right slope...the x values are coming in (slewed) at the maximum of 67.5 degrees per second (as per the limit dictated within wintrek.cpp) and the y values are (in my theory) coming in (slewed) at 60 degrees per second (as per the core).

If what I'm observing is true....we have the x axis slewing a 67.5 (no core limit) degrees while the y axis is slewing 60 degrees per second (core limit set at 1.0472).

Launch two versions of allegiance in windowed mode, one with the hard wired 1.0472 value in the x and y and one where the pitch equals the x and the x equals the x (both being null values if my theory is correct)...launch the training mission of both games. Once the game is started, don't move, just zoom in at the base in front of you and move the joystick. Do this with both running clients and you can clearly see that the fig using the X values from the core is far more sensitive (slewing 67.5 degrees per second) than is the other client where you have 1.0472 in both axis max turn rate values.

I know this is difficult for you to detect, it took me forever to zero in on this, but if you put these two running clients side by side and switch back and forth between the two, you'll see it as clearly as I do.

Trac ticket #88 was the turn speed restriction in cockpit view "bug"....meaning, that while not in cockpit view, your ship turned at the fastest rate allowed by the client...ie...67.5 degrees per second or something to that effect as I recall. I think it was that if you hit F10 or whatever, you could go external view and turn your ship faster than in cockpit view.

Trac was taken down however, PKK was kind enough to give me a back up (which I haven't put up 'yet') and if you need, I have all the copies of alleg source going back as far as the original code.