is collision avoidance horribly broken?

[Cmdr James]

I have been looking at escort behavior, and have noticed both that esorts seem to fly into each other (at least the liberator does, but that might just be due to its size) and also about half the ships launching from stations seem to go straight into the buoys.


Is anyone else seeing these things happening often?

[another_commander]

The ships going straight to buoys are traders with exitingTrader AI. If I remember correctly, the bug is the result of trader AI being assigned to a ship before it has been added to the universe, during its launching queue up phase. Because of this, getWitchSpaceCoordinates fails to check scanner correctly and does not see a station. As per the code in the method, if no station is found, then the ship accelerates on a straight line and ends up hitting the buoy.

The bug can be fixed by assigning the exitingTraderAI to the ship right after it has been added to the universe. Probably other ships may have similar issues, but it is immediately visible with the traders, because their AI requires a ship to be properly inserted to the universe before it can be used.

[davcefai]

Recently I've noticed that the beacons disappear while I am heading for the station. Probably because of this bug.

[Eric Walch]

Recently I've noticed that the beacons disappear while I am heading for the station. Probably because of this bug.

Known bug for version 1.71. You can fix it by installing "buoyRepair.oxp". See link below.

[davcefai]

Neat! Look forward to testing it later.

Suggestion:

Since your expensive fleet of tugs is not going to be occupied full-time, why not accept charters to tow abandoned vessels to the nearest shipyard?

You could sell a transmitter which, when activated, would summon a tug to the scene. The tug would then tow the ship and charge a hefty fee for doing so, say 50% of the price the shipyard will pay for it.

[Eric Walch]

Suggestion:....You could sell a transmitter which, when activated, would summon a tug to the scene. The tug would then tow the ship and charge a hefty fee for doing so, say 50% of the price the shipyard will pay for it.

Giles planed it that way (not towing, but flying in a new pilot) But I think it takes too much time for the NPC ship to arrive and the player will not wait that long.

But there is made a start of salvaging derelicts with: Dredger 2.0

[Cmdr James]

I tried adding

Code: Select all

"LAUNCHED OKAY" = ("setStateTo: HEAD_AWAY_FROM_PLANET");

to the last line of "HEAD_AWAY_FROM_PLANET" in exitingTraderAI.plist, and it seems to fix the behaviour of traders leaving the station.

Is there a problem with doing this, or should I commit the change to trunk?

[Eric Walch]

According to AC is the main problem that getWitchspaceEntryCoordinates is not seeing the main station and therefor is flying straight ahead. I thought he once mentioned he fixed this.

When your AI fix works, it means that issuing the command later than original does fix the problem. Only drawback is that once the command getWitchspaceEntryCoordinates starts working again as with versions before 1.71, the ship could act strange. Both times it than will get coordinates based on the rotational position of the station. And those two will be different.

When it is a timing problem you could also try to move the content of the ENTER message from the GLOBAL state to the UPDATE moment like:

Code: Select all

GLOBAL = {ENTER = (); EXIT = (); UPDATE = ("setStateTo: HEAD_AWAY_FROM_PLANET"); };

I tested it and it works like your fix. But I think it will be better as it keeps working well when the underlying bug gets fixed.

[Cmdr James]

The problem is that the AI uses the ships scanner, and it is run before the ship is added to the universe.

Because the ship is not in the universe, you cannot get anything sensible from its scanner. I am not too sure that this will get fixed any time soon. It seems logically correct that before a ship is in flight, its scanner does not work properly, and moving the AI to a later phase of the launch sequence is really just a work around for defective AI. I think AI should pretty much always "work", and be resilient to things like this.

I think the correct way to fix this is to make the AI work differently. I think that the ship should only look for what to do after it is launched. Its probably not right to have the ship decide on its behaviour before it is put in the launch queue -- it could be a long time before it launches, and things might have changed by then.

There is a line in the lunch code which notifies AI that they have launched, "LAUNCHED OKAY", which is a good indicator that it is ready to start doing things like looking at the scanner.

It might also be a good idea to make the AI clever enough to only do getWitchspaceEntryCoordinates if it doesnt already have some that it knows about. I think this can already be called multiple times, for example, if the ship goes into FLEE, and then reaches safety, then it will go back into global, which sets state to HEAD_AWAY_FROM_PLANET, which will redo all this stuff.

[another_commander]

According to AC is the main problem that getWitchspaceEntryCoordinates is not seeing the main station and therefor is flying straight ahead. I thought he once mentioned he fixed this.

I have not fixed it yet, because the fix I have in mind is just a hack - and a bad one at that.

When your AI fix works, it means that issuing the command later than original does fix the problem. Only drawback is that once the command getWitchspaceEntryCoordinates starts working again as with versions before 1.71, the ship could act strange. Both times it than will get coordinates based on the rotational position of the station. And those two will be different.

When it is a timing problem you could also try to move the content of the ENTER message from the GLOBAL state to the UPDATE moment like:

Code: Select all

GLOBAL = {ENTER = (); EXIT = (); UPDATE = ("setStateTo: HEAD_AWAY_FROM_PLANET"); };

I tested it and it works like your fix. But I think it will be better as it keeps working well when the underlying bug gets fixed.

I think I would prefer this fix for the moment. But in reality, the best way to fix this would be to check the code and find out what is the real reason for the trader (and possibly other) ships not being in the universe when their AI is started. Moreover, find out how come this same code was working fine before 1.71 and seems to have issues now.

[Cmdr James]

The Ai is assigned and started in launchTrader (or launchEscort, etc.), which simply puts the ship in a launch queue, but does not launch or add the ship.

The ship is added to the universe and launched in launchShip -- which then fires LAUNCHED OK.

I think, but dont know for sure (sorry, too lazy to investigate properly now), that it previously worked by having duplicate launch methods each of which set up the ship and launched it without preconfiguring a ship and queueing it, and then using a generic launcher.

[Eric Walch]

The Ai is assigned and started in launchTrader (or launchEscort, etc.), which simply puts the ship in a launch queue, but does not launch or add the ship.

At this point the code never changed. In update the ships are read out from the launch queue. There are a few lines different, but I don't think that has influence.

For now I think you are right with using the "LAUNCH OKAY" to redo the commands. But instead of "setStateTo:" you can also copy the contents of the ENTER message to the "LAUNCH OKAY" massage. That is the code that you actually want to be executed.

[Commander McLane]

There is a line in the lunch code...

Good! What's on the menu?