Timing of pirate attacks in Korolov escort missions does not take nav path length into account

This is not usually relevant right now, but if Korolov escort missions never have new pirate attacks on the return trip is fixed, the return trip attacks happen much earlier than expected. Part of this is because it doesn't account for the time the freighter spends maneuvering, accelerating, and docked. But if the nav path is roundabout, the "return trip" attack could even happen before reaching the destination. I tried changing

			(setq chrRaidTransport (lambda (transportObj originObj destObj cargoValue)
				(block (travelTime roundTrip)
					; Figure out how many ticks it will take for the transport to
					; travel the distance
					(setq travelTime (sysCalcTravelTime (objGetDistance originObj destObj) (shpGetMaxSpeed transportObj)))
					...

		(setq chrRaidTransport (lambda (transportObj originObj destObj cargoValue)
			(block (distance lastNavPoint nextNavPoint travelTime roundTrip)
				; Figure out how many ticks it will take for the transport to
				; travel the distance
				(setq lastNavPoint originObj)
				(for i 1 20
					(block nil
						(setq nextNavPoint (sysGetNavPathPoint &svCorporate; originObj destObj (* i 5)))
						(setq distance (+ distance (sysVectorDistance lastNavPoint nextNavPoint)))
						(setq lastNavPoint nextNavPoint)
						)
					)
				(setq travelTime (sysCalcTravelTime distance (shpGetMaxSpeed transportObj)))
					...

and I think it's better.

However, freighters don't always follow the appropriate path, especially on the return trip.

the_shrike 1 Jun 2017:

One option might be to instead randomise the attacks to spawn at a particular distance along the route, rather than time. Thus rather than, say, 1/3rd of the time estimated for the route, it would trigger when the distance between the freighter and the destination dropped below 66% of the total (straight-line) distance. Taking the measurement from the current destination should in theory allow it to be used on both legs of the journey. This might result in clustering, but that can probably be acceptable as a random element.

nms 1 Jun 2017:

I thought of that, but it's a bit more complicated. You need a recurring event that checks the distance against the previously calculated distances (and whether you're on the return trip) and generates the appropriate attacks, or multiple different distance-based events. If you want to run additional code at those times, feel free to do that, but otherwise, I think my fix is good enough.

george moromisato 27 Jun 2017:

This is a good change, but I'm leaving this open so we can someday do a better solution.

nms 25 May 2018:

This is resolved, but see Add sysGetNavPathDistance to return the distance along a nav path to make it more efficient.

Resolve