Berths, Docking Behavior, Etc.
Ok... I have successfully gotten every single docking point in FL to be usable by players and NPCs.
I couldn't get Moors working entirely to my satisfaction- the Mooring code is apparantly broken, and will not properly end with a fade-to-black transition to the Room/Transition scripts of Bases. We don't see this, because player-piloted ships can't use Moors. NPC ships that use Moors, moreover, use special, hard-coded behaviors that cause them to approach the Moor, reach the HpDockMount, and then reverse and seek a new Waypoint.
So I reversed this, got rid of every single Moor in the game, and then converted every ship that uses Moors to use Docks, with a gentle increase in the docking_spheres for everything, and with some modifications to the most troublesome HpDockMount and HpDockPoint entries in several CMPs.
The results are quite neat, so I thought I'd share this. It'll be in the next version of the XML Toolkit mod, so you can "steal" it directly, but I suspect that people will want to understand the theory behind it.
Basically put... FL uses the HpMounts to determine a host of behaviors, in lieu of the centerpoints of the CMPs and SURs normally used by the game engine.
HpMounts are used to determine the following things:
1. They are the point that must intersect a docking_sphere in order to complete a Berthing sequence.
2. They are the point used to determine the position of a ship CMP in any THN Scene.
3. They are used to offset the model when undocking from Stations, Bases, and other dockable locations.
As a result of this understanding, based upon several experiments, I think that my current solution could be improved. For example, there are some notable issues with large ships:
1. You have to move the HpDockMounts out quite a ways from Stations, or offset the ships' HpMounts so that they're far below the ship's centerpoint, so that they appear "above" the object they're un-docking from.
2. Because docking and un-docking reverse the position on the Z-axis of the game objects effected, it would be wise to have all HpDockMounts positioned so that they are as far away from the Dockable as the midpoint of the longest vessel in your mod. Otherwise, with certain geometries, it's quite possible that you will see ships spawning with some of their geometry intersecting the objects they're un-docking from
3. While putting the HpMounts significantly ahead of the ships decreases their problems with docking, it increases the problems outlined in (2), above. We should put HpMounts close to the true centers of our objects on the Z axis, 0 on the X, and position Y so that large things aren't buried in the "ground" in THN Scenes, nor appear inside of Dockables.
Lastly, I have done some physics hacking, and I think that I have arrived at the lowest stable steering values that should be used for ships that will be flown by NPCs. If you are careful about the AI you assign to these ships, their flight will look very natural, because of the damping effects caused by in the increased inertial values:
SHIP
linear_drag = 1
mass = 1000
steering_torque = 350000000, 350000000, 150000000
angular_drag = 1000000000, 1000000000, 1000000000
rotation_inertia = 300000000, 300000000, 300000000
nudge_force = 150000
strafe_force = 50000
ENGINE
linear_drag = 10000
max_force = 800000
Note that linear_drag counteracts Mass exceedingly quickly. This does mean that these ships accelerate and decelerate on a dime. This is masked with the rotation_interia values, however, which make spin acceleration quite slow, plus the low rate of top spin speed.
The nudge_force ratio to linear_drag is as high as it is because the Docking AI really demands it. FL's docking AI is about as smart as a drunken cockroach- it basically picks an approach, and if it runs into anything, it will make either a right or left-hand turn, do a full 360 at speed, and re-approach, using nudge_force to align itself. You don't want it any lower than 15M/S, even though this will occasionally result in odd behavior- FL's own defaults were similar.
Also note that the Z-axis torque is lower than the other values- this is to prevent ships from exhibiting bizarre-looking barrel-rolls, which look perfectly-reasonable with fighters but look silly with capships
At any rate, I know that most of this has been explained in one place or another before, but I decided to do a lot've experiments, and I'm satisfied that these values are about as low as you can go before NPC ships will start having problems. With these super-stiff steering values, large ships will act like they're large ships if collided with- ships with smaller values with spin and vector away from the impacts, but the large ships will continue on their way, as if they weighed millions of tons
I couldn't get Moors working entirely to my satisfaction- the Mooring code is apparantly broken, and will not properly end with a fade-to-black transition to the Room/Transition scripts of Bases. We don't see this, because player-piloted ships can't use Moors. NPC ships that use Moors, moreover, use special, hard-coded behaviors that cause them to approach the Moor, reach the HpDockMount, and then reverse and seek a new Waypoint.
So I reversed this, got rid of every single Moor in the game, and then converted every ship that uses Moors to use Docks, with a gentle increase in the docking_spheres for everything, and with some modifications to the most troublesome HpDockMount and HpDockPoint entries in several CMPs.
The results are quite neat, so I thought I'd share this. It'll be in the next version of the XML Toolkit mod, so you can "steal" it directly, but I suspect that people will want to understand the theory behind it.
Basically put... FL uses the HpMounts to determine a host of behaviors, in lieu of the centerpoints of the CMPs and SURs normally used by the game engine.
HpMounts are used to determine the following things:
1. They are the point that must intersect a docking_sphere in order to complete a Berthing sequence.
2. They are the point used to determine the position of a ship CMP in any THN Scene.
3. They are used to offset the model when undocking from Stations, Bases, and other dockable locations.
As a result of this understanding, based upon several experiments, I think that my current solution could be improved. For example, there are some notable issues with large ships:
1. You have to move the HpDockMounts out quite a ways from Stations, or offset the ships' HpMounts so that they're far below the ship's centerpoint, so that they appear "above" the object they're un-docking from.
2. Because docking and un-docking reverse the position on the Z-axis of the game objects effected, it would be wise to have all HpDockMounts positioned so that they are as far away from the Dockable as the midpoint of the longest vessel in your mod. Otherwise, with certain geometries, it's quite possible that you will see ships spawning with some of their geometry intersecting the objects they're un-docking from
3. While putting the HpMounts significantly ahead of the ships decreases their problems with docking, it increases the problems outlined in (2), above. We should put HpMounts close to the true centers of our objects on the Z axis, 0 on the X, and position Y so that large things aren't buried in the "ground" in THN Scenes, nor appear inside of Dockables.
Lastly, I have done some physics hacking, and I think that I have arrived at the lowest stable steering values that should be used for ships that will be flown by NPCs. If you are careful about the AI you assign to these ships, their flight will look very natural, because of the damping effects caused by in the increased inertial values:
SHIP
linear_drag = 1
mass = 1000
steering_torque = 350000000, 350000000, 150000000
angular_drag = 1000000000, 1000000000, 1000000000
rotation_inertia = 300000000, 300000000, 300000000
nudge_force = 150000
strafe_force = 50000
ENGINE
linear_drag = 10000
max_force = 800000
Note that linear_drag counteracts Mass exceedingly quickly. This does mean that these ships accelerate and decelerate on a dime. This is masked with the rotation_interia values, however, which make spin acceleration quite slow, plus the low rate of top spin speed.
The nudge_force ratio to linear_drag is as high as it is because the Docking AI really demands it. FL's docking AI is about as smart as a drunken cockroach- it basically picks an approach, and if it runs into anything, it will make either a right or left-hand turn, do a full 360 at speed, and re-approach, using nudge_force to align itself. You don't want it any lower than 15M/S, even though this will occasionally result in odd behavior- FL's own defaults were similar.
Also note that the Z-axis torque is lower than the other values- this is to prevent ships from exhibiting bizarre-looking barrel-rolls, which look perfectly-reasonable with fighters but look silly with capships
At any rate, I know that most of this has been explained in one place or another before, but I decided to do a lot've experiments, and I'm satisfied that these values are about as low as you can go before NPC ships will start having problems. With these super-stiff steering values, large ships will act like they're large ships if collided with- ships with smaller values with spin and vector away from the impacts, but the large ships will continue on their way, as if they weighed millions of tons