Docking-Functions are not waterproof

[unbekannt1984]

Hi,

 

Avorion/data/scripts/entity/ai/dock.lua function flyToDock is not waterproof. Well, there were issues in the Goods Hauler Mod, that could have been prevented by adding something as stupid as the following in the code:

    -- New in Avorion 0.20.x: Transporters
    -- A Transporter with software makes real docking impossible - No fallback here
    if (ship.transporterRange or 0) > 0 then
        -- We're doomed; How close do we need to get?
        local range = ship.transporterRange
        -- range should be 350 => 3.5km for highest quality transporter-software, 50 => 0.5km for lowest

        local dir = normalize(ship.translationf - station.translationf)
        local Distance = (range - (ship.radius + station.radius))
        local target = station.translationf + (dir * Distance)

        if (Distance >= 0) then
        -- just make sure we don't crash into the station, before we move there
            ShipAI(ship):setFly(target, 0)
        else
        -- Well, don't try to park inside the station
            return false
        end

        if station:isDocked(ship) then 
        -- We've reached our destination, shutdown the engines and get back to business
            ShipAI(ship):setPassive()
            return true 
        end
    else
    -- Continue old style docking

[koonschi]

I'm afraid you'll have to be more specific than "It's not waterproof" and "there were issues in a mod". I also can't see where in the docking code your code fragment would be placed.

[unbekannt1984]

Hi koonschi,

 

I'm afraid you'll have to be more specific than "It's not waterproof" and "there were issues in a mod". I also can't see where in the docking code your code fragment would be placed.

just like every ai-faction freighter, Goods Hauler is using DockAI.flyToDock.

 

If you put the code I posted in Line 25 of Avorion/data/scripts/entity/ai/dock.lua, transporters and normal docking should work if any Entity is using DockAI.flyToDock.

 

"It's not waterproof" means, that a ship with transporter got stuck, if it was using DockAI.flyToDock.

[koonschi]

You'll have to adjust the mod to match the new API of the docking script.

[unbekannt1984]

Hi koonschi,

 

You'll have to adjust the mod to match the new API of the docking script.

no, I used exactly the code I posted. I just called DockAI.flyToDock in the end (so it uses that old function, if there is no transporter on the ship).

[koonschi]

I don't understand what the issue is.

[Shrooblord]

I think I understand the issue. Allow me to paraphrase:

If you put the code I posted in Line 25 of Avorion/data/scripts/entity/ai/dock.lua, transporters and normal docking should work if any Entity is using DockAI.flyToDock.

 

"It's not waterproof" means, that a ship with transporter got stuck, if it was using DockAI.flyToDock.

 

Given the following case:

- AI Ship has a Transporter Block in its BlockPlan() and a Transporter System installed

- AI Ship attempts a Docking run with a Station

 

EXPECTED:

- AI Ship approaches Station until it is within range of the Transporter, then "Docks" virtually by using the Transporter System's functionality.

 

RESULT:

- AI Ship attempts to Dock normally with the Station, but gets confused because of its Transporter System and gets stuck, doing nothing, and getting stuck attempting to Dock, but not Docking, nor interrupting its Docking procedure, thereby halting completely, jamming up the Dock and itself.

 

WORK-AROUND:

- Using the script unbekannt1984 proposes, above, you can have AI Ships approach the Station as per normal, until they get into virtual "Docking" range using the Transporter functionality. At that moment, they can use the Transporter to Dock from a distance.

- Using an if-else condition, you can check for whether or not the ship has a Transporter to begin with, and if it doesn't, use the classic, currently-implemented Docking method (i.e. fly to light-line, tractor beams, Dock, etc.).

 

====

 

I haven't tested this myself so I can't be terribly sure, but I think that's what the problem is unbekannt is trying to explain. Correct me if I'm wrong, 1984.