`model_maybe_fixup_subsys_path` is beyond borked

[Baezon]

And honestly I'm not sure how to fix it. Here's an exerpt, this is after loading a model it goes through all the path which have a valid subsystem as their 'parent'

// ensure that the subsys path is at least SUBSYS_PATH_DIST from the 
// second last to last point.
void model_maybe_fixup_subsys_path(polymodel *pm, int path_num)
{
	...

	model_path *mp;
	mp = &pm->paths[path_num];

        ...
	
	index_1 = 1;
	index_2 = 0;

	v1 = &mp->verts[index_1].pos;
	v2 = &mp->verts[index_2].pos;
	
	dist = vm_vec_dist(v1, v2);
	if (dist < (SUBSYS_PATH_DIST - 10))
	{
		vm_vec_normalized_dir(&dir, v2, v1);
		vm_vec_scale_add(v2, v1, &dir, SUBSYS_PATH_DIST);
	}
}

// SUBSYS_PATH_DIST is used as the distance that a subsystem path should terminate from the actual
// subsystem.  We don't want to rely on the model path points for this, since we may need to be 
// changed.
#define SUBSYS_PATH_DIST	500.0f

Basically the 0th point, is pushed away from the 1st point, until it's at least 500 meters away. Even setting aside why tf this is being done, paths start away from the ship and go towards the ship. So is 0 and 1 supposed to be the "last/second-to-last"?? If this is meant to be affecting the distance the path terminates from the subsystem (even making the assumption the last index point is at the subsystem's position) it should be num_points - 1 and num_points - 2, and for that matter the rest of the point too, since we're potentially introducing a 'kink' in the path by waggling around a point in the middle.

Additionally, this is completely invalid for fighterbay paths, yet modeler's intuitively expect to put the fighterbay subsystem as the parent to their bay paths, making (just one of) those paths subject to this manipulation. I'm not sure how, or if, destructible fighterbays work, but that might require that they put the fighterbay as the parent.

[Baezon]

After thinking about it some more, I think preserving the existing behavior is probably preferable. Not just for backwards compatibility reasons, but making sure the path points furthest from the ship are sufficiently far from the ship, so ships can painlessly get onto them, is a good idea instead of trying to manipulate points near to the ship, which is a very dicey prospect, and the documentation ought to be clarified from whatever nonsense it was originally on about.

The fighterbay issues still stand though.

[Goober5000]

Well, that's... something.

As a side note, this has to be the reason that ships departing into hangar bays flew so far away when they ran the "alt1" pathing behavior. See #3853 and its comments. Whether by accident or intent, the "normal" path behavior somehow avoids getting snagged by this.

I would be curious to see how ships would depart into fighterbay when running the alt1 behavior when the farthest point is not moved.

[Baezon]

I recall that coming up before, I believe that is due to alt1's intentional lack of shortcutting the path, making fighterbay departures much longer than normal.

The noted behavior here, was actually noticed in fighterbay arrivals, since I believe those do not shortcut, the ship will follow their unusually long bay paths all the way out to their end.