Trunk bug with thargoid missiles

[Eric Walch]

The code for "broadcastThargoidDestroid" has a long standing bug, that I just noticed yesterday. Back in 1.65 it used to be sent by send by ships with role "thargoid" only. Now it is broadcasted by anything with scanClass thargoid, including the targlets themselves. It seeds an additional check for also have a role of "thargoid-mothership".

Trying to test this bug with trunk showed a new trunk bug: Thargoids no longer fire tharglets. Instead oolite becomes very sluggish somewhere during combat with a thargoid and gets responsive again when the thargoid is killed. No error is logged but I suspect the sudden slowness of oolite is caused by not being able to fire the tharglets. Also firing the tharglet by the console fails: "PS.target.fireMissile()" returns "null"

[another_commander]

I cannot reproduce it on Windows. With latest trunk, the Thargoids launch their robot fighters just fine and PS.target.fireMissile() on a Thargoid Warship target also causes thargons to be launched. Are we sure this is not just a matter of having the missile_load_time set to 15 for Thargoids? I think that's a bit too long a time, to be honest and it is the default in current shipdata.plist. I tested with missile_load_time set to 0.5.

[Eric Walch]

I cannot reproduce it on Windows.

I also can not reproduce on trunk without oxps. I now identified the problem. Any older oxp uses "thargon" as missile role. 1.74 was still compatible with this, but not trunk. I have a freakyThargoid.oxp installed. That just overwrite the internal thargoid data with a shaderified one. Same does neolite.oxp. Both use "thargon" as missile and not the new "EQ_THARGON"

So the problem is in the compatibility code with the old "thargon" role that was not defined as equipment. In 1.74 there is a specific "thargon" equipment defined.

So better re-add the thargon as equipment or rework the code itself.

----

About the missile_load_time: 15 looks also a bit high to me. For real missiles it makes sense to not shoot them at once but for defense ships, it makes perfect sense to launch them as a swarm. I thought that the main complain in the past was that they launched to late and not that they needed more delay.

[Switeck]

Thargons can be launched quickly, because unlike missiles you cannot ECM them into impunity. (Even the ECM-resistant hardhead missiles will often fall victim to ECM, if you use ECM 5+ times over.)

So in my mod, I reduced the missile_load_time from 15 to 5 seconds. I had tested them set as low as 2 seconds but found that to be extremely painful...and Thargoids might hold back launching all their Thargons either due to limited fuel for them or because recovery was (nearly?) impossible.

I have seen Thargons crash into the Thargoids on launch, I attribute this to the speed differences -- the Thargons get "run over" by the Thargoid which is faster. Thargoids in earlier versions of Elite were not nearly as fast!

[Eric Walch]

I now reduced the problem to one line:

Code: Select all

- (BOOL) removeExternalStore:(OOEquipmentType *)eqType
{
	NSString	*identifier = [eqType identifier];
	unsigned	i;
	
	// if ([identifier isEqualToString:@"thargon"]) identifier = @"EQ_THARGON";
	for (i = 0; i < missiles; i++)
	{
		if ([[missile_list[i] identifier] isEqualTo:identifier])
		{
			// now 'delete' [i] by compacting the array
			while ( ++i < missiles ) missile_list[i - 1] = missile_list[i];
			
			missiles--;
			return YES;
		}
	}
	return NO;
}

When I remove the line

Code: Select all

if ([identifier isEqualToString:@"thargon"]) identifier = @"EQ_THARGON";

All thargoids are able to launch the thargoids , even when my oxps contain missiles with role "thargon". The missile in the slot is a "thargon" but the code renames it to "EQ_THARGON" and tries to remove that one from the list. It fails as the name of the missile in the slot is "thargon" and returns NO. FireMissile() stops the launch, missile_launch_time is not updated and the next update event the thargoid tries to launch the missile again. Apparently this loop takes so much time that the whole movement becomes jerky, though the FPS count still reads okay.

Do we need that line, or should the problem fixed elsewhere?

[Kaks]

Looks like I was trying to be a bit too clever, backwards compatibility-wise.

By all means, take that line out!

[Eric Walch]

By all means, take that line out!

Ok, I just deleted that line in rev 3752.

I also added my thargon changes I was working on when I came across this bug. I added a new AI command "thargonCheckMother". Internally it does the same as the old command: "scanForNearestShipHavingRole: thargoid-mothership". With as only difference that it first checks if his current owner is still present and in range. When it still has an owner in range, the actual scan is skipped.

This has as advantage that it does not need so many scans with every time the risk it will miss a mother ship when things become crowded. (All normal scans only look at 16 close-by ships and ignores any other ships when there are more). The change of a thargon loosing control in a crowded battle has become smaller.

One side product of this way of checking is that the original mother does not need to have the role "thargoid-mothership" to control thargons because it starts as an owner. That "thargoid-mothership" role will only be required to take control over thargons from other thargoids. For now I see it as a feature and not as a bug.

During testing my new code I also discovered two bugs in the old thargletAI.
- In the state LOOK_FOR_TARGETS was no check for control. It relied on the TARGOID_DESTROID message for this. But when the mother was killed outside scanner range the thargon never got notified. This is a very minor bug as whenever a target does come in range, it will start checking for control and become inactive than. But it did result in needless scans for drifted away thargons.
- However, when the thargon did receive the TARGOID_DESTROID message in the LOOK_FOR_TARGETS state, it was possible that there was still a pending NOTHING_FOUND message for the last non-thargoid scan. This message could than get read-out in the CHECK_CONTROL state were it would be interpreted wrong as having lost control.
I rewrote both states now to prevent this problem (and hope I did not introduce a new bug)

[Switeck]

Are Thargons, once fired, treated like escorts of the Thargoid mothership?
Or is the connection more...tenuous?