KGJV

[Wasp]

It appears that the function "yaw = pht->GetMaxTurnRate(c_axisYaw)" isn't getting the proper value from the cores. "pitch = pht->GetMaxTurnRate(c_axisPitch)" seems to be working.

Can you see if this is a bug within ICE? If so, will all the cores have to be rebuilt?

[KGJV]

That's strange. Could be but I doubt it otherwise it would have been reported long ago.

could it be a rounding or conversion error ?

I've no alleg dev related stuff on any of my systems anymore so I can't really test anything. I'll look at ICE source if I see anything.

You could try comparing the output of ICE with the output of the server (IIRC, allsrv can dump a core to text) before and after changing a yaw turn rate value.

[Wasp]

QUOTE (KGJV @ Mar 13 2016, 07:37 PM) ....You could try comparing the output of ICE with the output of the server (IIRC, allsrv can dump a core to text) before and after changing a yaw turn rate value.

I have no idea what that means.

I did my tests, my findings are correct. The Yaw max turn rate is not being picked up by the function in wintrek.cpp.

The reason everyone else didn't report it is irrelevant. It's also very peculiar that this bug showed up right at the same time R5 came out with the whole change in ICG/ICE.

Is the Yaw the only problem with the cores / client? Weren't these values checked after the re-design of ICE & Cores?

[KGJV]

QUOTE (Wasp @ Mar 14 2016, 01:06 AM) I have no idea what that means.

I did my tests, my findings are correct. The Yaw max turn rate is not being picked up by the function in wintrek.cpp.

The reason everyone else didn't report it is irrelevant. It's also very peculiar that this bug showed up right at the same time R5 came out with the whole change in ICG/ICE.

Is the Yaw the only problem with the cores / client? Weren't these values checked after the re-design of ICE & Cores?

If you use an original core, 'untouched by ICE', do you have the issue too ?

The ICE code treats yaw exactly as pitch & roll. So unless the game expects a different scaling/unit for yaw , if yaw is bugged then pitch and roll should be bugged too.

This is how the UI in ICE is reading/saving the value:

Code: Select all

    DDX_Text(pDX, IDC_S4, pship->maxTurnRates[c_axisYaw]);
    DDX_Text(pDX, IDC_S5, pship->maxTurnRates[c_axisPitch]);
    DDX_Text(pDX, IDC_S6, pship->maxTurnRates[c_axisRoll]);

exactly the same code for all 3.

pship->maxTurnRates is defined the same as in Allegiance source code:

Code: Select all

    float               maxTurnRates[3];    //yaw, pitch, roll

So unless it's a "nasty memory corruption/side effect bug" I don't see how yaw could be 'bad' and not pitch & roll too.

[Wasp]

QUOTE (KGJV @ Mar 13 2016, 08:22 PM) If you use an original core, 'untouched by ICE', do you have the issue too ?

I don't know that you can load an untouched core into R7.

I have zero knowledge or experience with cores and their interaction with the game. It was only by my investigation into the x and y axis behavior that I stumbled upon this.

1. There is no question that the max yaw and pitch rate for the IC int is 1.0472
2. When putting that value into the Yaw axis value in Wintrek.cpp OR by forcing the Yaw value to equal the Pitch value, we get a different response.

Conclusion: IF the Pitch and Yaw were the same value, there would be no change in behavior.

Simple test.... Reverse Wintrek.cpp's Yaw and Pitch value and you'll notice right off that it's different....if they were indeed the same values, you wouldn't notice any difference.

[KGJV]

I just saw your other topic about this. I'll investigate this tomorrow.

[Wasp]

Thanks for your attention...

I truly hope I'm wrong, but I can see no other explanation for my findings.