OTC and targeting mechanics are inter-independent?

[nick87720z]

Expected Behavior

I expected, that mechanics affects targeting in both H/V direction. And OTC handles only target selection for turrets (probably missile locking as well). According to what I just discovered, turret rotation speed is reflected at visible turret rotation too, and thus visible horizontal rotation should not be instant (this is first thing, that I discovered after looking how different vertical weapon rotation is).
Both OTC and turret mechanics must present to be useful. Complete removal of one should make another useless.

Actual Behavior

It seems, despite naming, OTC controls horizontal aiming only, while turret mechanics - vertical. I got successfuly working horizontal aiming with removed mechanics. Of course, no vertical correction was done, and thus I discovered, that most (at least first) targets at first level are placed slightly lower (so that all shots go above without correction), though not enough to let player ship just pass above. I remember, that something changed in auto-aiming since 1.4.0 (difficulty?), but could not find what, before these observations.

Steps to Reproduce the Problem

1. Try with missing OTC - vertical targeting works. Aiming speed depends on mechanics.
2. Try with missing mechanics (but with OTC). Horizontal auto-aim works, (re)aiming instantly, but no vertical aim (shots go above all starting enemies).

[viewizard]

Turrets targeting in H/V direction should depends from OTC. Turrets tracking speed depends from installed mechanics. I'll check OTC, probably, some kind of bug.

[nick87720z]

Oh, wait. First case to reproduce doesn't work. Indeed, with missing OTC targeting doesn't work in both H/V. I assumed first true from second, without special check (strange, I thought I checked it).
But second case is true.

[viewizard]

Hmm... I can't reproduce second case with "Weapon Targeting Mode" set to "Sim" (see Difficulty for Pilot Profile). All works fine for me.
Could you pls provide me with your configs with profile/ship/fit/mission, when I can reproduce this issue for 100%?

[nick87720z]

Don't turrets rotate to sides, when OTC is installed, but no mechanics?
I did not try live git version yet. Current is 1.4.1.

[viewizard]

Turrets should not rotate on 1.4.1 without mechanics too.
In case of "Weapon Targeting Mode" set to "Sim":
https://github.com/viewizard/astromenace/blob/master/src/object3d/space_ship/space_ship.cpp#L1303
https://github.com/viewizard/astromenace/blob/master/src/object3d/space_ship/space_ship.cpp#L1358
https://github.com/viewizard/astromenace/blob/master/src/object3d/space_ship/space_ship.cpp#L1366
https://github.com/viewizard/astromenace/blob/master/src/object3d/space_ship/space_ship.cpp#L1377
https://github.com/viewizard/astromenace/blob/master/src/object3d/space_ship/space_ship.cpp#L1387
so, if you don't have mechanics (GameTargetingMechanicSystem == 0), you multiply angle on zero all the time.

[nick87720z]

Did not inspect code yet (though it seems there is no other way), but I also tried manually built version, first from v1.4.1, then from master. With master I also tried first with -O2 -march=native, than with -O0.
Last times I tried only one case - mechanics is completely sold (no even geared variant), and second OTC (1 target, horizontally enabled). Horizontal rotation works, with instant rotation speed, though no vertical rotation.

Btw, it is not even necessary to have enemies to test targeting - asteroids are enough. It is easiest to notice when firing, and if weapons are at big side distance (e.g. two rear positions) - though they are hidden under rear hull parts, projectiles show how they target. In case of asteroids - projectiles focus at some point above selected target. Previous method I tried - just visually watching weapons at front slots. Though it also allowes to notice instant rotation, there are usually too much targets in range, so weapons rarely turn to big angles (only in very begining of first mission).

I created separate pilot for test. First time made it to full difficulty (150%), but last time tried to turn to minimum all besides controls and enemy armor (less than 100%). Though I'm not sure wether it can affect this bug.

Edit: For each rebuild I create new build dir inside srcdir, runing ./astromenace from inside it (just after make). Of course, it used same user config as if runing system-installed app (~/.config/astromenace) - hope there are no other conflicts with system version.

[nick87720z]

Tried some code analysis - it seems no need to go far to see where is difference.
There is notable difference between x and y angle calc code - these two blocks:
https://github.com/viewizard/astromenace/blob/master/src/object3d/space_ship/space_ship.cpp#L1357
https://github.com/viewizard/astromenace/blob/master/src/object3d/space_ship/space_ship.cpp#L1374
Since they duplicate for opposing direction, one is enough. I only in trouble understanding, what block is for what orientation (H/V). I expected to be x->H and y->V, but Max/Min values are used in 'y' calc, which seem to be more like limits for horizontal direction (looks like vertical limit is same).

For now in search for correction.

Edit: I suspected, reason is that 'z' transformation must be handled as well, but it doesn't help (vertical speed breaks by breaking code for any of 'x' or 'y' coordinates).

[nick87720z]

It seems, that horizontal orientation doesn't follow TargetingSpeed at all (probably all code about NeedAngle_y has no effect). Even with this:
float NeedAngle_y = sharedWeapon->Rotation.y + 40.0f * 0 * TimeDelta;
It rotates horizontally.

[viewizard]

It seems, that horizontal orientation doesn't follow TargetingSpeed at all (probably all code about NeedAngle_y has no effect).

This code works only with OTC 3 and 4 (MOTC). Just make sure, you test it in proper way.

[nick87720z]

o_O How? I learned slighter deeper - as far as I understand, x,y,z in sModel3D::Rotation should be angle in different planes, is not it? (btw, first time I misinterpreted sVECTOR3D Rotation as rotation matrix). Does it means, that code, implementing turret rotation physics (rotation speed) depends on used OTC? I though, OTC goal is to assign targets, via GetWeaponOnTargetOrientation() call as in switch block above. Is not it?

I don't know now, where to search. Thought about sharedWeapon->SetRotation() call, but only found cWeapon->SetRotation(), which clearly should be common, including for ground turrets, which never experienced instant rotation.

[viewizard]

OTC routine provide end rotation angle to target
https://github.com/viewizard/astromenace/blob/master/src/object3d/space_ship/space_ship.cpp#L1329
After that, you need rotate gun to target. You can do it with some speed, or (if you have Arcade mode) instantly https://github.com/viewizard/astromenace/blob/master/src/object3d/space_ship/space_ship.cpp#L1397
and after that rotate gun https://github.com/viewizard/astromenace/blob/master/src/object3d/space_ship/space_ship.cpp#L1402

So, in case if you have OTC 1 or 2, after OTC routine https://github.com/viewizard/astromenace/blob/master/src/object3d/space_ship/space_ship.cpp#L1355 you don't have horizontal angle changes, since OTC 1 and 2 don't provide horizontal precision.

this code smell, but I don't have time now to refactor it.

Does it means, that code, implementing turret rotation physics (rotation speed) depends on used OTC?

No.

...
float TargetingSpeed = static_cast<float>(GameTargetingMechanicSystem);
...
float NeedAngle_y = sharedWeapon->Rotation.y + 40.0f * TargetingSpeed * TimeDelta;
if (NeedAngle_y > NeedAngle.y) {
    NeedAngle_y = NeedAngle.y;
}
...

As you can see, rotation speed depends from GameTargetingMechanicSystem, but not from OTC. OTC only provide end rotation angle.

[nick87720z]

float NeedAngle_y = sharedWeapon->Rotation.y + 40.0f * TargetingSpeed * TimeDelta;
if (NeedAngle_y > NeedAngle.y) {
    NeedAngle_y = NeedAngle.y;
}

This is right that code, which I described as meaningless (telling about meaningless of NeedAngle_y and NeedAngle.y change). Meaning, that even if I replace TargetingSpeed with 0 (or just add * 0 without removal of original text) there and proper repeat for reverse direction, it still rotates. Only for similar block for 'x' rotation - it makes same effect as full getting rid of turret drive (i.e., turrets don't shoot right to asteroids below, instead shooting to point above it).

I'm probably going to do some debugging (just rebuild with flags -O0 -g3 -ggdb3).

[viewizard]

Ah... I finally understand what you mean. Looks like only Arcade mode works all the time. Will fix it.

[viewizard]

I was able to reproduce this one time, but can't reproduce this again (for now). Looks like some time https://github.com/viewizard/astromenace/blob/master/src/object3d/space_ship/space_ship.cpp#L1397 don't work proper and some time don't care about real WeaponTargetingMode status.

[nick87720z]

Found the fix, before even trying to debug. Hint: swap signs between comparisons:
if (sharedWeapon->Rotation.y < NeedAngle.y) {
if (sharedWeapon->Rotation.y > NeedAngle.y) {
I came to this after doing more tests like:
NeedAngle.y = Rotation.y, NeedAngle.y = sharedWeapon->Rotation.y, gradually moving them inside blocks. Could take long time if I began debugging :D .

Edit: Strange, that rotation still didn't work. Weapons would just rotate out of enemies. Btw, best test moment is when first long alien sequence moves in some horizontal wave, so weapons constantly rotate.

[viewizard]

Yeah, I also found this :))
I see same, but correct logic in code above https://github.com/viewizard/astromenace/blob/master/src/object3d/space_ship/space_ship.cpp#L1277 but have no idea why this one is wrong.

[nick87720z]

Looks like place for optimizing. Bit ops could be used to treat ally and player as some common class (more exactly - two fields, faction number and player/or_not field).

Edit: Or even have same OTC check for ally, with them using only basic OTC - I have seen them sometimes hitting asteroids.

[nick87720z]

First change, that are found (from start):

commit 944259eccba54f3e644ec765db75ac3df353943d
Author: Mikhail Kurinnoi <[email protected]>
Date:   Tue Oct 16 13:09:43 2012 +0000

    Fixed bug with planets rendering, alpha test added. Revised all code connected to objects rotation, changed to right-handed coordinate system (default for OpenGL). All scripts revised. Fixed bug
 with weapon targeting with custom weapon angles.

Looks like it can't show more exact info due to some massive changes near to end - too hard to look all of them.

Does it mean, that it depends on OpenGL implementation? Of so, should not GL allow to check this (coordinate system) type?

[viewizard]

This should not depend from OpenGL implementation for sure. That was one of "fix all around" commit I did, that should be not allowed in any project for sure.