Thargoids firing in random directions

[Commander McLane]

I always had the feeling that something's not right with Thargoid lasers, but now I've captured it on a screenshot.



A lot of the time Thargoid lasers don't fire anywhere near their target. In this example there is a battle in witchspace going on. It's a lot of Thargoids against one Behemoth and its two escorts. The navy ships are very close together, at least at the beginning of the battle. Nevertheless there is a lot of Thargoid fire in a lot of directions, and only in some cases vaguely in the direction of where the naval ships are.

The Thargoid Warship highlighted here is one example. It has targeted the Behemoth below, and is in state ATTACK_SHIP. But, as clearly visible, it is not only firing with the wrong laser (the one heading away from the Behemoth) and therefore in the opposite direction of where it should fire, but even if we'd imagine the green dots going to the opposite direction they would be almost 60 degrees off. And it fired a lot of shots this way (always exactly in the same line, roughly just backwards to its movement), and not a single one in the correct direction. The same is true for most (but not all) Thargoid ships in this battle, and in any battle.

The ship highlighted here is an OXP Thargoid. I can't say whether the built-in Thargoid behaves better.

[Switeck]

I can attest to the built-in Thargoids acting the same way, even when I slowed them down by 0.1 LM! (0.4 LM from 0.5 LM)

[TGHC]

He probably hit the wrong button in panic.

[Cmdr Radan]

it's a cunning alien ploy to make you feel safe, then.....wham !

[Eric Walch]

It is no bug, but intentionally. Ships are only firing when they are heading at a target. For normal lasers this is calculated, for thargoid lasers the code uses just some random number to signal it is on target. That is the reason thargoids keep firing, even when making turns. When flying towards or from a target they are regularly on target so hits will be there always, but with thargoids they may also fire when making turns.

I assume this is done this way to make a visible difference between the two.

[JensAyton]

It is no bug, but intentionally. Ships are only firing when they are heading at a target. For normal lasers this is calculated, for thargoid lasers the code uses just some random number to signal it is on target. That is the reason thargoids keep firing, even when making turns. When flying towards or from a target they are regularly on target so hits will be there always, but with thargoids they may also fire when making turns.

But surely it’s shooting using -fireDirectLaserShot, and therefore should be shooting directly at the target (with an error of up to about 8°) regardless of relative orientation?

[Eric Walch]

But surely it’s shooting using -fireDirectLaserShot, and therefore should be shooting directly at the target (with an error of up to about 8°) regardless of relative orientation?

I always noticed random shots, even in 1.65. Probably I read the code with in my mind that it should be sometimes random. But re-reding the code it is intended to always shoot in the global direction of the target. All code seems correct but I had my doubt if the calculation of the quaternion itself was always correct. So I added following code:

Code: Select all

	Quaternion		q_laser = kIdentityQuaternion;
	Vector q_laser_cross = fast_cross_product(kBasisZVector, r_pos); // kBasisZVector is vectorForward of kIdentityQuaternion
	double q_laser_angle = acosf(dot_product(kBasisZVector, r_pos));
	quaternion_rotate_about_axis(&q_laser, q_laser_cross, -q_laser_angle); // rotate vectorForward to r_pos.

	Quaternion		q_laser2 = quaternion_rotation_between(r_pos, kBasisZVector);
	OOLog(@"dumpState.thargoidEntity", @"quat1: %@, quat2: %@", QuaternionDescription(q_laser), QuaternionDescription(q_laser2));

q_laser2 is the way Oolite currently calculates the quaternion and q_laser is calculated by rotation of the identity quaternion. I logged both results before randomisation The result should be the same, but was not always:

Code: Select all

[dumpState.thargoidEntity] ShipEntity.m:7561: quat1: (0.794043 - 0.597819i - 0.110034j + 0k), quat2: (0.794043 - 0.597819i - 0.110034j + 0k)
[dumpState.thargoidEntity] ShipEntity.m:7561: quat1: (0.772979 - 0.627878i - 0.090952j + 0k), quat2: (0.772979 - 0.627879i - 0.090952j + 0k)
[dumpState.thargoidEntity] ShipEntity.m:7561: quat1: (0.722108 - 0.690482i - 0.0423704j + 0k), quat2: (0.722108 - 0.690482i - 0.0423704j + 0k)
[dumpState.thargoidEntity] ShipEntity.m:7561: quat1: (0.487414 - 0.835378i + 0.254108j + 0k), quat2: (1 + 0i + 0j + 0k)
[dumpState.thargoidEntity] ShipEntity.m:7561: quat1: (0.526448 + 0.816298i + 0.237717j + 0k), quat2: (0.526449 + 0.816298i + 0.237717j + 0k)
[dumpState.thargoidEntity] ShipEntity.m:7561: quat1: (0.5261 + 0.816444i + 0.237988j + 0k), quat2: (0.5261 + 0.816444i + 0.237988j + 0k)
[dumpState.thargoidEntity] ShipEntity.m:7561: quat1: (0.525694 + 0.81663i + 0.238248j + 0k), quat2: (0.525693 + 0.81663i + 0.238248j + 0k)
[dumpState.thargoidEntity] ShipEntity.m:7561: quat1: (0.525411 + 0.816741i + 0.23849j + 0k), quat2: (0.525411 + 0.816741i + 0.23849j + 0k)
[dumpState.thargoidEntity] ShipEntity.m:7561: quat1: (0.521813 + 0.821227i + 0.230861j + 0k), quat2: (0.521813 + 0.821227i + 0.230861j + 0k)
[dumpState.thargoidEntity] ShipEntity.m:7561: quat1: (0.515604 + 0.829072i + 0.216317j + 0k), quat2: (0.515604 + 0.829072i + 0.216317j + 0k)
[dumpState.thargoidEntity] ShipEntity.m:7561: quat1: (0.437887 + 0.898787i - 0.0208951j + 0k), quat2: (1 + 0i + 0j + 0k)
[dumpState.thargoidEntity] ShipEntity.m:7561: quat1: (0.360759 + 0.49472i - 0.790636j + 0k), quat2: (1 + 0i + 0j + 0k)
[dumpState.thargoidEntity] ShipEntity.m:7561: quat1: (0.553631 - 0.349388i - 0.755924j + 0k), quat2: (0.553631 - 0.349388i - 0.755924j + 0k)
[dumpState.thargoidEntity] ShipEntity.m:7561: quat1: (0.669551 - 0.491976i - 0.556472j + 0k), quat2: (0.669551 - 0.491976i - 0.556472j + 0k)
[dumpState.thargoidEntity] ShipEntity.m:7561: quat1: (0.732027 - 0.525676i - 0.433361j + 0k), quat2: (0.732027 - 0.525676i - 0.433361j + 0k)
[dumpState.thargoidEntity] ShipEntity.m:7561: quat1: (0.752756 - 0.530676i - 0.389539j + 0k), quat2: (0.752756 - 0.530676i - 0.389539j + 0k)
[dumpState.thargoidEntity] ShipEntity.m:7561: quat1: (0.763936 - 0.532033i - 0.36516j + 0k), quat2: (0.763936 - 0.532033i - 0.36516j + 0k)
[dumpState.thargoidEntity] ShipEntity.m:7561: quat1: (0.777968 - 0.533047i - 0.332607j + 0k), quat2: (0.777968 - 0.533047i - 0.332607j + 0k)
[dumpState.thargoidEntity] ShipEntity.m:7561: quat1: (0.77995 - 0.534211i - 0.326031j + 0k), quat2: (0.77995 - 0.534211i - 0.326031j + 0k)
[dumpState.thargoidEntity] ShipEntity.m:7561: quat1: (0.785578 - 0.539619i - 0.302784j + 0k), quat2: (0.785578 - 0.539619i - 0.302784j + 0k)

Sometimes the current code returns (1 + 0i + 0j + 0k) (the identity quaternion)

It happens here:

Code: Select all

Quaternion quaternion_rotation_between(Vector v0, Vector v1)
{
	Quaternion q;
	OOScalar s = sqrtf((1.0f + v0.x * v1.x + v0.y * v1.y + v0.z * v1.z) * 2.0f);
	if (EXPECT(s))
	{
		OOScalar is = 1.0f / s;
		q.x = (v0.y * v1.z - v0.z * v1.y) * is;
		q.y = (v0.z * v1.x - v0.x * v1.z) * is;
		q.z = (v0.x * v1.y - v0.y * v1.x) * is;
		q.w = s * 0.5f;
	}
	else
	{
		// Is this actually a problem?
		q = kIdentityQuaternion;
	}
	return q;
}

I think that sqrtf((1.0f + v0.x * v1.x + v0.y * v1.y + v0.z * v1.z) * 2.0f) is guaranteed to take the sqrt from a positive number. It can only be zero as lowest value but that would be very rare.

[Eric Walch]

Somehow the EXPECT is not doing that I should expect. I added a few log lines in that function and it writes than:

Code: Select all

[dumpState.thargoidlaserRotation] OOQuaternion.m:194: scalar: 0.884222, vec0: (0.268211, 0.746385, -0.609075), vec1: (0, 0, 1)
[dumpState.thargoidlaserRotation] OOQuaternion.m:208: scalar invalid
[dumpState.thargoidEntity] ShipEntity.m:7562: quat1: (0.442111 + 0.844114i - 0.30333j + 0k), quat2: (1 + 0i + 0j + 0k)

Or more clearly the value for 's' is logged as '0.884222' but it still ends up in the else part of the if statement.

[JensAyton]

Hah. EXPECT(foo) expands to __builtin_expect((foo), 1). The first parameter to __builtin_expect() is a long. Implicitly casting a float to a long truncates it.

Try if (EXPECT(s > 0.0f)). (Really EXPECT() should be changed to __builtin_expect((foo) != 0, 1), but I don’t want to do that at this point in the release cycle.)

[Eric Walch]

Hah. EXPECT(foo) expands to __builtin_expect((foo), 1). The first parameter to __builtin_expect() is a long. Implicitly casting a float to a long truncates it.

Try if (EXPECT(s > 0.0f). (Really EXPECT() should be changed to __builtin_expect((foo) != 0, 1), but I don’t want to do that at this point in the release cycle.)

That did it. THe EXPECT macro was a bit orkish for me.
I'll change it in the code.

I see that the routine was also used in the JS command rotationTo. That one probably never worked correct either than. I never used it but should have, as it is much more efficient than the method I used to rotate a quaternion for getting a starting quaternion with a fixed vectorForward.