sven wrote:
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.
Out of curiosity, is ship.s related to ship.speed_class at all?
Also, what is the signature for the motion cost function? I'm guessing it's ship.motion_cost(x,y,r)?
So if I wanted to implement a function that turned a ship to face a given target, would this work?
Code: Select all
local turn_costs = {
[1] = 25/4,
[0] = 25/4*0.7,
[-1] = 25/4/3,
}
function turn_cost(ship)
return turn_costs[(ship.s > 4 and 1) or (ship.s == 4 and 0) or -1]
end
function face_target(ship, target)
local r = rotate_to_face(ship,target)
if ship.motion_cost(0,0,r) > ship.max_fuel
local sign = r/abs(r)
r = sign * ship.max_fuel/turn_cost(ship)
end
local x,y = object_center(ship)
action.move_ships{ship, x, y, r}
end
-- elsewhere...
if to_target(ship, move_target) <= attack_dist
face_target(ship, move_target)
end
Although, I think there are two issues with this. The first is that it seems pretty equivalent to just do:
Code: Select all
local x,y,r,r2 = find_min_facing_move_L2(ship,move_target,attack_dist)
if to_target(ship, move_target) <= attack_dist
x,y = object_center(ship)
end
action.move_ships{ship, x, y, r}
Which involves far less assumptions - especially since we don't need to do our own inverse motion cost calculation.
The second is that either way, we need to pass an x,y into action.move_ships() to actually do a turn without moving. Which is problematic because using object_center() causes all kinds of motion weirdness (ships spinning around in strange ways). In the end I just ended up using ship.x, ship.y for x,y - which mostly works but causes that wiggle I mentioned earlier.