Bug with Escort-Role?

[Eric Walch]

Until 1.71 there was a bug in Escort-Role that made that those ships didn't escort. (Only Escort-ship did work.). This is corrected in 1.71. However, I have sometimes extremely long hangs on hyperspace jumps since introduction of 1.71. What actually is happening, is that the system keeps adding ships near the entrance point. This forces me to quit Oolite.

When I look into the logfile it starts logging when it reaches the maximum amount of ships for the system. After this I get messages that ship "xxx" can't be added because the maximum amount of entities is reached. When looking at the names, it always were escort ships of the military Leviathan from Military Fiasco. I once waited very long and than it started moving with an enormous amount of purple blibs at the entry point. (Movement was to slow to be able to target one ship but it must have been a few hundreds of his escorts.)

Last week I renamed the escort role from military-escort to militaryEscort. I haven't seen a hang since, but have to play longer to be sure the name triggers this effect.

My question to other players is: Have others seen this behaviour also? And if yes, had they military Fiasco installed or not?

[Commander McLane]

Haven't seen this yet, and I have military fiasco installed.

Probably your change is sensible, because I think the engine will also recognize the string 'escort' within the 'military-escort', which could then lead to problems?!

[Eric Walch]

I forgot the most easiest test: Just add the "leviathan" by script. This also lets the system hang. The name of the role has nothing to do with it.
The military version is just a plain ship, even without ant script that could cause it to bug. Ill look further into it now I know to look in which direction.

[Captain Tylor]

I had really long hangs going into hyperspace and leaving stations. This was when I installed realistic shipyards and all your ads here. I removed all but 2 of your ads here and realistic shipyards. Didn`t hang after that.

[Eric Walch]

I narrowed it down. It probably happens since Military Fiasco 2.4 In that version I changed the handler this.shipSpawned into this.spawnedAsEscort

Code: Select all

this.shipSpawned = function()
{
  this.ship.switchAI("militaryFiascoEscortAI.plist")
}

this.spawnedAsEscort = function()
{
  this.ship.switchAI("militaryFiascoEscortAI.plist")
}

And the culprit is the line were I change the AI of the escort ships. By doing it with the new handler, the code is executed in the middle of oolites setUpEscorts function. Somehow this AI change is messing things up with the code and the escort counter. Although I don't see how.

[Frame]

I narrowed it down. It probably happens since Military Fiasco 2.4 In that version I changed the handler this.shipSpawned into this.spawnedAsEscort

Code: Select all

this.shipSpawned = function()
{
  this.ship.switchAI("militaryFiascoEscortAI.plist")
}

this.spawnedAsEscort = function()
{
  this.ship.switchAI("militaryFiascoEscortAI.plist")
}

And the culprit is the line were I change the AI of the escort ships. By doing it with the new handler, the code is executed in the middle of oolites setUpEscorts function. Somehow this AI change is messing things up with the code and the escort counter. Although I don't see how.

During the writing of the original Rock Hermit Locator with the legacy scripting for 1.65 and 1.68. It was reported to me that ever since it was installed, Tesco Stations and Con stores spawned 3 times at witchspace exit...

What i narrowed that down to back then was that the spawning of rock hermit bouys, from inside the AI.plist file somehow got "mixed" up with script.plist. this was the only possible scenario as the tesco stations and con stores was spawned from the script.plist file..

I presume, something similar is happening to your script, and to avoid it in a similar way to what i did, would be to add a timer that fires after 5 seconds and only once, after the this.spawnAsEscort. has triggerd, as i back then added a pauseAI: 5 to solve the problem...

Cheers Frame...

[Eric Walch]

I presume, something similar is happening to your script, and to avoid it in a similar way to what i did, would be to add a timer that fires after 5 seconds and only once, after the this.spawnAsEscort. has triggerd, as i back then added a pauseAI: 5 to solve the problem...

The solution for me is to use the shipSpawned handler again. That one fires at the first update event after spawning. The spawnedAsEscort is fired already inside the while loop of setUpEscort as shown below:

Code: Select all

	while (escortCount > 0)
	{
               ....... (deletion)
		
		[escortAI setState:@"FLYING_ESCORT"];	// Begin escort flight. (If the AI doesn't define FLYING_ESCORT, this has no effect.)
		[escorter doScriptEvent:@"spawnedAsEscort" withArgument:self];
		
		if (bounty)
		{
			int extra = 1 | (ranrot_rand() & 15);
			bounty += extra;	// obviously we're dodgier than we thought!
			[escorter setBounty: extra];
		}
		else
		{
			[escorter setBounty:0];
		}
		[escorter release];
		escortCount--;
	}

And as more people will try to change the AI with this handler in the future, I think this bug should be removed from Oolite. Probably this can be achieved by moving the line that fires the handler after the [escorter release]??