Oolite v1.73 - Apr 19 2009, Win XP. Police behaving oddly

Griff · Post by **Griff** » Mon Apr 27, 2009 6:28 pm

Oolite v1.73 - Apr 19 2009, Windows XP. Police behaving oddly after fight
There seems to be something odd with the police behaviour, i'm using a script to spawn pirates outside the main station when i launch, after the pirates have attacked me a few police launch from the station to help fight off the bandits, I'm noticing that after the police have destroyed their target pirate they seem to want to fly back to the station and dock.
They fly fairly close to the station then stop moving forward but continue to pitch & rotate as if they are trying to follow a flight plan.
i've targeted 2 faulty viper and pressed shift and h to write data about them into the log
Here's the first viper's log info

Code: Select all

[dumpState]: State for <ShipEntity 0x72fdf80>{"GalCop Viper" ID: 228 position: (62417.8, -9358.06, 348212) scanClass: CLASS_POLICE status: STATUS_IN_FLIGHT}:
  [dumpState.entity]: Universal ID: 228
  [dumpState.entity]: Scan class: CLASS_POLICE
  [dumpState.entity]: Status: STATUS_IN_FLIGHT
  [dumpState.entity]: Position: (62417.8, -9358.06, 348212)
  [dumpState.entity]: Orientation: (0.494344 - 0.688954i - 0.512759j - 0.134334k)
  [dumpState.entity]: Distance travelled: 9961.06
  [dumpState.entity]: Energy: 180 of 180
  [dumpState.entity]: Mass: 33764.4
  [dumpState.entity]: Owner: <StationEntity 0x13c3f90>{"Icosahedron Station" "Icosahedron Station" ID: 139 position: (63412.4, -15151.1, 345475) scanClass: CLASS_STATION status: STATUS_ACTIVE}
  [dumpState.entity]: Flags: isShip, hasRotated, isSunlit, collisionTestFilter
  [dumpState.shipEntity]: Name: GalCop Viper
  [dumpState.shipEntity]: Display Name: GalCop Viper
  [dumpState.shipEntity]: Roles: <OORoleSet 0x414ed88>{defense_ship oolite-viper police}
  [dumpState.shipEntity]: Primary role: defense_ship
  [dumpState.shipEntity]: Script: <OOJSScript 0x13ed7d8>{"griff_explosion" version 1.0}
  [dumpState.shipEntity]: Subentity count: 3
  [dumpState.shipEntity]: Behaviour: BEHAVIOUR_FACE_DESTINATION
  [dumpState.shipEntity]: Target: <StationEntity 0x13c3f90>{"Icosahedron Station" "Icosahedron Station" ID: 139 position: (63412.4, -15151.1, 345475) scanClass: CLASS_STATION status: STATUS_ACTIVE}
  [dumpState.shipEntity]: Destination: (63647.9, -13013.1, 340781)
  [dumpState.shipEntity]: Other destination: (0, 0, 0)
  [dumpState.shipEntity]: Waypoint count: 0
  [dumpState.shipEntity]: Desired speed: 0
  [dumpState.shipEntity]: Fuel: 0
  [dumpState.shipEntity]: Fuel accumulator: 1
  [dumpState.shipEntity]: Missile count: 1
  [dumpState.shipEntity.ai]: AI:
    [dumpState.ai]: State machine name: dockingAI.plist
    [dumpState.ai]: Current state: GO_TO_COORDS
    [dumpState.ai]: Next think time: 107.093
    [dumpState.ai]: Next think interval: 0.125
  [dumpState.shipEntity]: Frustration: 0
  [dumpState.shipEntity]: Success factor: 0
  [dumpState.shipEntity]: Shots fired: 0
  [dumpState.shipEntity]: Time since shot: 100071
  [dumpState.shipEntity]: Spawn time: 29.265 (77.843 seconds ago)
  [dumpState.shipEntity]: Hull temperature: 60
  [dumpState.shipEntity]: Heat insulation: 1
  [dumpState.shipEntity]: Flags: pitching_over, canFragment
[gameController.exitApp]: .GNUstepDefaults synchronized.

Closing log at 2009-04-26 15:45:18 +0100.

That's a normal mapped griff viper but it uses the same AI as the built in police, here's a built in oolite viper

Code: Select all

[dumpState]: State for <ShipEntity 0x48c78b0>{"GalCop Viper Interceptor" ID: 214 position: (63601.6, -12977.4, 347746) scanClass: CLASS_POLICE status: STATUS_IN_FLIGHT}:
  [dumpState.entity]: Universal ID: 214
  [dumpState.entity]: Scan class: CLASS_POLICE
  [dumpState.entity]: Status: STATUS_IN_FLIGHT
  [dumpState.entity]: Position: (63601.6, -12977.4, 347746)
  [dumpState.entity]: Orientation: (-0.265085 + 0.933411i + 0.0878784j + 0.225278k)
  [dumpState.entity]: Distance travelled: 18436.9
  [dumpState.entity]: Energy: 280 of 280
  [dumpState.entity]: Mass: 43245.4
  [dumpState.entity]: Owner: <StationEntity 0x13a6d28>{"Icosahedron Station" "Icosahedron Station" ID: 137 position: (63412.4, -15151.1, 345475) scanClass: CLASS_STATION status: STATUS_ACTIVE}
  [dumpState.entity]: Flags: isShip, hasRotated, isSunlit, collisionTestFilter
  [dumpState.shipEntity]: Name: GalCop Viper Interceptor
  [dumpState.shipEntity]: Display Name: GalCop Viper Interceptor
  [dumpState.shipEntity]: Roles: <OORoleSet 0x60f3190>{defense_ship interceptor oolite-viper-interceptor wingman}
  [dumpState.shipEntity]: Primary role: defense_ship
  [dumpState.shipEntity]: Script: <OOJSScript 0x6745fc8>{"oolite-default-ship-script" version 1.73}
  [dumpState.shipEntity]: Subentity count: 15
  [dumpState.shipEntity]: Behaviour: BEHAVIOUR_FACE_DESTINATION
  [dumpState.shipEntity]: Target: <StationEntity 0x13a6d28>{"Icosahedron Station" "Icosahedron Station" ID: 137 position: (63412.4, -15151.1, 345475) scanClass: CLASS_STATION status: STATUS_ACTIVE}
  [dumpState.shipEntity]: Destination: (65182.2, -11323.7, 342495)
  [dumpState.shipEntity]: Other destination: (0, 0, 0)
  [dumpState.shipEntity]: Waypoint count: 0
  [dumpState.shipEntity]: Desired speed: 0
  [dumpState.shipEntity]: Fuel: 160
  [dumpState.shipEntity]: Fuel accumulator: 1
  [dumpState.shipEntity]: Missile count: 3
  [dumpState.shipEntity.ai]: AI:
    [dumpState.ai]: State machine name: dockingAI.plist
    [dumpState.ai]: Current state: GO_TO_COORDS
    [dumpState.ai]: Next think time: 196.313
    [dumpState.ai]: Next think interval: 0.125
  [dumpState.shipEntity]: Frustration: 0
  [dumpState.shipEntity]: Success factor: 0.99999
  [dumpState.shipEntity]: Shots fired: 0
  [dumpState.shipEntity]: Time since shot: 119.328
  [dumpState.shipEntity]: Spawn time: 33.954 (162.328 seconds ago)
  [dumpState.shipEntity]: Hull temperature: 60
  [dumpState.shipEntity]: Heat insulation: 1
  [dumpState.shipEntity]: Flags: isFrangible, canFragment
[gameController.exitApp]: .GNUstepDefaults synchronized.

Post by **Micha** » Mon Apr 27, 2009 7:30 pm

both of those ships are trying to face their destination. Someone else mentioned recently that there might be a problem with that function.

Post by **Eric Walch** » Mon Apr 27, 2009 8:11 pm

Micha wrote:
both of those ships are trying to face their destination. Someone else mentioned recently that there might be a problem with that function.

There are two types of problems with it.

A) A real bug. The ship is doing nothing at all. According to the code it should turn into the destination direction on every update. But that bug is not happening with Griff.

B) A constant overshooting of the target direction. On every update it rotates at maximum rotation speed in the desired direction. At low frame-rates this starts to become a problem. At low frame-rates the rotation angle per frame is larger and agile ships easily overshoot their target. For me it helps a bit to go into full screen mode. Oolite now allows less background activity and my frame-rate rises a bit. Ships suddenly are facing destination an fly further.

For the buoy repair station that was frame-rate for me also a problem as I work on a low end computer. I gave all ships belonging to the station a rather low turnrate. They become a bit sluggish but overshooting for the docking ships stopped with me.

The code already has special movement procedures when in the safety zone of the station but maybe the face destination needs extra code to avoid this overshooting near the station. (I already looked intensively in this part of the code a year ago but could not find an easy place to add extra code without disturbing general movements.

Post by **Micha** » Tue Apr 28, 2009 8:48 am

Wouldn't the solution be that instead of checking on each frame wether the desired facing/position has been achieved and, if overshot, to try again, to instead 'snap' to the desired position/facing?

Ie, (in 1D), if a ship is at position 5, and it's trying to get to position 10, with a velocity of 6 units/frame it'd actually be at position 11 on the next frame, and has overshot. If I understand correctly, in the current system the ship would have to reverse velocity and try to achieve it's desired position again, possibly overshooting again.

Instead, why not just 'snap' the ship to position 10 on the next frame. The player will never notice - he'd just assume the ship had slowed down to 5 units/frame.

Post by **Eric Walch** » Tue Apr 28, 2009 1:59 pm

Micha wrote:
Instead, why not just 'snap' the ship to position 10 on the next frame. The player will never notice - he'd just assume the ship had slowed down to 5 units/frame.

Yes, it needs something like that. It means a slowdown of rotation speed when near target direction. Somehow it will also look more realistic.

For directional changes, the code looks at the desired distance to target and the real distance to target. From this it calculates a maximum angle where is should stay within to arrive at a spot within the target area. When it is not on target, it rotates always at maximum speed in the desired direction, without bothering this rotation could be to much. The rotation angle is always maximum rotation speed multiplied with the passed time between updates.
At this point there should be a check to use a slower rotation speed when coming close to target. But the calculation should not be too accurate and never end exactly on target or every ship will go to the same spot. This last is not a problem for the docking itself but it is for travelling to e.g. a station.
I think when overshooting it just should turn to a position that will bring it halfway the target direction. And when not enough the next update will again half the gap.

There are two places in the code were such a check can be added. In the general code for rotating or only when near the station. I am not sure what the most efficient place will be as the problem is not limited to docking alone. And I always thought this was a problem of low end machines that will solve itself as newer computers are all more powerful. But now I think the more powerful a computer is, the more oxp's are installed, so also fast computers might end up with low frame rates.

Post by **Micha** » Tue Apr 28, 2009 2:32 pm

Hmm, not sure I'd subscribe to the 'not exact' method of flying.

IMHO it would be better to make setting the destination inexact but flying to it exact. Or possibly adjust the exactness as a function depending on range to destination - but within 10/15/<scanner range>km it should be exact.

In either case, I think the calculations should not calculate by how much and for how long to rotate, and then hope the next update nails it, but rather calculate the exact desired facing and then during each frame, calculate how far the ship has rotated to the desired heading since the last update depending on inertia and maximum rotation capabilities of the ship and set the ship to the calculated (possibly intermediate) facing.

I don't like watching ships twiddling around on the spot trying to get to their destination because they're always over/under-shooting by a fraction, it just looks silly (IMHO).

Post by **another_commander** » Tue Apr 28, 2009 3:23 pm

One observation: In plenty of occasions, I have seen ships launching from station, then stopping and start rotating together with it for ever. A status snapshot reveals that all of them have not only BEHAVIOUR_FACE_DESTINATION, but also their AI set to dockingAI.plist. I can understand this in the case of the Vipers described by Griff, but I fail to see why a ship that just launched gets a dockingAI state. I honestly think that something else is going on here, also due to the fact that I cannot see any changes between the code for facing destination between 1.72.2 and 1.73. And in 1.72.2 we did not have this issue. This is something that will probably require some time to investigate.