Determine the distance a ship can move in 1 turn

[harpy eagle]

Between max_fuel, motion_function, motion_speed, I'm having a bit of trouble figuring it out. Is there a simple relationship between "motion points" and euclidean distance, say, when a ship travels in a straight line?

Is there similarly a simple relationship between "motion points" and the angle of a turn?

[sven]

Between max_fuel, motion_function, motion_speed, I'm having a bit of trouble figuring it out. Is there a simple relationship between "motion points" and euclidean distance, say, when a ship travels in a straight line?

Is there similarly a simple relationship between "motion points" and the angle of a turn?

The core ship motion functions are one of (possible even the) oldest parts of the codebase. Thus, they involve a lot more C++ than they probably need to.

In theory, each ship has a motion_cost function, and that function can return whatever it likes for a given delta x, delta y, delta r combination. That cost returns how many motions points "aka fuel" a ship consumes changing from one position / rotation to another.

In practice, the motion cost functions currently in use are very simple. They all return

Code: Select all

dist+turn_mult*delta_r


So if you're moving in a straight line, you always consume motion points equal to the distance traveled. And if you're turning, you always consume turn_mult motion points per each 45 degrees worth of turn.

Turn_mult does vary for each ship, but not in an overly complex way.

ship.s>4 --> turn_mult=(25/4),

ship.s==4 --> turn_mult=0.7*(25/4), and

ship.s<4--> turn_mult = (25/4)/3.

[sven]

Code: Select all

dist+turn_mult*delta_r


The tricky thing, when one gets into ship motion, is figuring out what sort of delta_r is required to move from point A to point B; as that in turn affects the cost of move, and, thus, whether or not it's even possible for the ship to get from one place to another.

That's why the CloseAndAttack.lua logic uses C++ helper functions like find_min_facing_move_L2() to figure out what x,y,r combination to use to close on a given target.

[siyoa]

Thus, they involve a lot more C++ than they probably need to.
Turn_mult does vary for each ship, but not in an overly complex way.

ship.s>4 --> turn_mult=(25/4),

ship.s==4 --> turn_mult=0.7*(25/4), and

ship.s<4--> turn_mult = (25/4)/3.

so if this gets exposed to lua eventually, we can code in technology like inertial nullifier from MoO ?

[sven]

so if this gets exposed to lua eventually, we can code in technology like inertial nullifier from MoO ?

In theory, the system as-is should already be able to handle that -- but the code organization is nightmarish, and includes a bunch of C++/lua interop, so this is probably something I should write up myself, rather than leaving it to you guys. I'll add "inertial nullifier" to my TODO list

[siyoa]

I'll add "inertial nullifier" to my TODO list

[harpy eagle]

Another ship movement related question for you sven. In a mod I'm working on under certain conditions I want a ship to keep its current position but rotate to face it's target.

The way I've been doing it is to call find_min_facing_move_L2() but discard the x,y returned from that and use ship.x,ship.y instead.

It mostly works except very often it causes ships to wiggle in a weird way before turning back to face their target, and in some rare cases (seems like it only happens when ships are overlapping), they will turn away from their target.

[harpy eagle]

Actually now I'm finding the random wiggling can actually help the AI because of shield directionality, go figure

[harpy eagle]

Some more questions:

What is the r2 returned by find_min_facing_move_L2()?

Is there any way to use find_min_facing_move_L2() to move a ship towards a tracking object instead of another ship?

[sven]

Another ship movement related question for you sven. In a mod I'm working on under certain conditions I want a ship to keep its current position but rotate to face it's target.

There's an entirely undocumented function called "rotate_to_face(ship,target)" that should get you the minimum-cost rotation needed to face a given target. And unlike find_min_facing_move_L2, it should work with missile and fighter targets.

[harpy eagle]

Cool, I'll look at that. Although I do need to move towards tracking objects as well (they're two separate things).

If rotate_to_face(ship,target) just gets the minimum cost rotation, does that mean I need to check that the ship has enough fuel left? Or will it return a rotation limited by fuel like how find_min_facing_move_L2() seems to work?

[sven]

Cool, I'll look at that. Although I do need to move towards tracking objects as well (they're two separate things).

If rotate_to_face(ship,target) just gets the minimum cost rotation, does that mean I need to check that the ship has enough fuel left?

I believe you'll need to do the fuel check yourself. find_min_facing_move_L2() does an optimization over all possible moves to find one that uses as little fuel as possible, and it includes fallback logic for handling cases where the objective is not actually achievable; rotate_to_face just iterates over all possible rotations, and finds one that both uses the smallest amount of fuel and gets us into a state where we're facing the target.

[sven]

Although I do need to move towards tracking objects as well (they're two separate things).

It's been ages since I wrote this code, but, I've looked over the source to find_min_facing_move_L2(), and I believe the current restriction to ship targets is unnecessary. I've pushed a build to the Steam in_development branch that changes the function so that it will accept a target of any tactical object type -- let me know if you run into any issues with it.

[harpy eagle]

That's awesome! Thanks.

[harpy eagle]

Which revision is the change on? Just want to know when it reaches the public branch.