1.73 and the suicide ships

Screet · Post by **Screet** » Mon Apr 27, 2009 9:27 am

Solas wrote:
It's strange that warning distances need to be increased.
do the Devs know what could have changed to require this ?

Well, the warning distance increase just changed that ships did ram me. However, they do not benefit from it regarding buoys and ads or stations.

I wonder if those objects simply are not in the list checked for collision warnings as those ships did for sure get NO collision warning flag through to the AI even when they were virtually already touching the object in their path. That's the point where I'd look, I just need some time and an idea where to begin with.

Screet

Post by **Eric Walch** » Sat Jul 11, 2009 6:59 pm

I can confirm that buoys are still flown into pieces by launching ships under the current oolite 1.73 test. As chairman of the buoy repair company I don't have problems with this in general, but now the bug is even affecting our repair team. The problem is that something is tampering with the internal "destination" variable. This results in that launching patrol vipers load their new destination but still head straight forward. Flying close to the buoy and sometime killing it. But it also affected my own buoy repair ship. And because the bug was easier to track there I went on with that ship:

In the latest buoyRepair version I changed the code for the repair team from flying just 10 km straight ahead into:

Code: Select all

	"GOTO_POSITION_N" = {
		ENTER = ("setSpeedFactorTo: 1.0", "pauseAI: 10.0");
		RESTARTED = (setDestinationToStationBeacon, "setDesiredRangeTo: 10.0", "setSpeedFactorTo: 1.0", checkCourseToDestination);
		"COURSE_OK" = ("setSpeedFactorTo: 1.0", performFlyToRangeFromDestination);
		"WAYPOINT_SET" = ("setAITo: gotoWaypointAI.plist");
		"DESIRED_RANGE_ACHIEVED" = ("setStateTo: RELEASE_N");
		"ATTACKED" = (fightOrFleeHostiles);
	        "INCOMING_MISSILE" = (fireECM); 
		UPDATE = (setDestinationToStationBeacon, "setDesiredRangeTo: 10.0", "setSpeedFactorTo: 1.0", checkCourseToDestination, "pauseAI: 10.0");
		};

With my original version that worked perfectly. For the past half year with 1.72 I used the "setDestinationToStationBeacon" only once in the ENTER message and it always delivered the buoy on spot. (I uploaded this changed version with improved buoy dropping about a month ago).

Since I use 1.73 the repair ships just fly straight ahead until they crashed on the planet. I changed the code to the above so it is setting the beacon coordinates on every UPDATE with no improvement. Making an entity dump with shift-H showed that it has not the coordinates of the beacon as destination. (To make it easier for me I also dumped the beacon coordinate itself:

Code: Select all

  [dumpState.shipEntity] ShipEntity.m:8371: Behaviour: BEHAVIOUR_FLY_TO_DESTINATION
  [dumpState.shipEntity] ShipEntity.m:8373: Destination: (23353.1, 91754.1, 543966)
  [dumpState.shipEntity] ShipEntity.m:8374: Beacon position: (9491.92, 75154.3, 556296)
  [dumpState.shipEntity] ShipEntity.m:8375: Other destination: (10100, 3700, 1100)
  [dumpState.shipEntity] ShipEntity.m:8376: Waypoint count: 0
  [dumpState.shipEntity] ShipEntity.m:8377: Desired speed: 80
  [dumpState.shipEntity] ShipEntity.m:8379: Fuel: 70
  [dumpState.shipEntity] ShipEntity.m:8380: Fuel accumulator: 1
  [dumpState.shipEntity] ShipEntity.m:8381: Missile count: 0
  [dumpState.shipEntity.ai] ShipEntity.m:8399: AI:
    [dumpState.ai] AI.m:588: State machine name: buoyRepairShipNWAI.plist
    [dumpState.ai] AI.m:589: Current state: GOTO_POSITION_N

It puzzles me, but something is changing the "destination". Both for my ship and the launching patrols, although the patrols are not always affected. Other ships fly quite happy to their destination so it does not affect all ships.

Even stranger was when I logged the distance to destination. It became larger while it was in a fly-to mode. And even frustration messages were not send except to my own head.

Double checked with 1.72 and same oxp set: Here it dropped the buoy on the spot and the entity dump gave the right value for "destination".

Frame · Post by **Frame** » Sun Jul 12, 2009 9:59 am

Just out of curiosity,

Code: Select all

    [dumpState.ai]: Next think time: 28.906

in the trunk for planetPatrol.plist station launched vipers that just suicide impact on the planet surface...

does that mean that the Next AI action is in 28.906 seconds,

reading this, since i'm reading this and making logical assumptions

Code: Select all

[dumpState.ai]: State machine name: planetPatrolAI.plist
    [dumpState.ai]: Current state: GO_TO_COORDS
    [dumpState.ai]: Next think time: 28.906
    [dumpState.ai]: Next think interval: 0.125
  [dumpState.shipEntity]: Frustration: 0
  [dumpState.shipEntity]: Success factor: 8760.37
  [dumpState.shipEntity]: Shots fired: 0
  [dumpState.shipEntity]: Time since shot: 100026
  [dumpState.shipEntity]: Spawn time: 0.25 (27.983 seconds ago)
  [dumpState.shipEntity]: Hull temperature: 60
  [dumpState.shipEntity]: Heat insulation: 1
  [dumpState.shipEntity]: Flags: isFrangible, canFragment

so does that mean that its 0.25 / 27.983 * 28.906 = number in seconds, time until the next appropriate action is taken ?

Cheers Frame...

Post by **Eric Walch** » Sun Jul 12, 2009 1:05 pm

Frame wrote:
Just out of curiosity,
...so does that mean that its 0.25 / 27.983 * 28.906 = number in seconds, time until the next appropriate action is taken ?

Cheers Frame...

Think interval is always 0.125 when I am right. Next think time is current time added with this think interval. This is overruled by a pauseAI command that changes the next thinktime into current time added with pause value.

At that time the UPDATE is executed. In your example it takes 28.906 - 27.983 = 0.923 seconds before the next UPDATE is evaluated. Or better: rounded up to the next multiple of think interval what is 8 * 0.125 = 1.00 seconds.

Planet patrol reads every 7.5 seconds its destination.

---

For me, I added debug messages in my Oolite source that logged the "destination" variable immediately after setting the beacon position. At that moment the value was always correct, but with a target dump it was on every dump different. Something is messing with that variable. But it is very selective as docking ships that almost use a similar flight behaviour, are not affected.

To make sure it was not a "checkCourseToDestination" that affected the stuf I simplified the code to:

Code: Select all

	"GOTO_POSITION_N" = {
		ENTER = ("setSpeedFactorTo: 1.0", "pauseAI: 5.0");
		"DESIRED_RANGE_ACHIEVED" = ("setStateTo: RELEASE_N");
		UPDATE = (setDestinationToStationBeacon, "setDesiredRangeTo: 10.0", "setSpeedFactorTo: 1.0", performFlyToRangeFromDestination, "pauseAI: 10.0");
		};

The dumpstate however showed that the destination kept changing while it was correct immediately after every setDestinationToStationBeacon command.

Code: Select all

  [dumpState.entity] Entity.m:1053: Universal ID: 298
  [dumpState.entity] Entity.m:1055: Status: STATUS_IN_FLIGHT
  [dumpState.entity] Entity.m:1056: Position: (21183.1, 37880, 438596)
  [dumpState.shipEntity] ShipEntity.m:8371: Behaviour: BEHAVIOUR_FLY_TO_DESTINATION
  [dumpState.shipEntity] ShipEntity.m:8373: Destination: (25893.2, 39328.8, 437066)
  [dumpState.shipEntity] ShipEntity.m:8411: Spawn time: 24.3945 (20.2492 seconds ago)
----------
  [dumpState.shipEntity] ShipEntity.m:8371: Behaviour: BEHAVIOUR_FLY_TO_DESTINATION
  [dumpState.shipEntity] ShipEntity.m:8373: Destination: (22144.5, 36134.5, 433836)
  [dumpState.shipEntity] ShipEntity.m:8411: Spawn time: 24.3945 (27.5919 seconds ago)
----------
  [dumpState.shipEntity] ShipEntity.m:8371: Behaviour: BEHAVIOUR_FLY_TO_DESTINATION
  [dumpState.shipEntity] ShipEntity.m:8373: Destination: (21684.4, 42960.4, 437847)
  [dumpState.shipEntity] ShipEntity.m:8411: Spawn time: 24.3945 (42.7485 seconds ago)
----------
  [dumpState.shipEntity] ShipEntity.m:8371: Behaviour: BEHAVIOUR_FLY_TO_DESTINATION
  [dumpState.shipEntity] ShipEntity.m:8373: Destination: (25371.3, 37286.1, 435641)
  [dumpState.shipEntity] ShipEntity.m:8411: Spawn time: 24.3945 (69.2076 seconds ago)
----------
[dumpState.shipEntity] ShipEntity.m:8371: Behaviour: BEHAVIOUR_FLY_TO_DESTINATION
  [dumpState.shipEntity] ShipEntity.m:8373: Destination: (23760, 36225, 434443)
  [dumpState.shipEntity] ShipEntity.m:8411: Spawn time: 24.3945 (78.2903 seconds ago)
----------
  [dumpState.shipEntity] ShipEntity.m:8373: Destination: (21670.9, 36228.3, 433731)
  [dumpState.shipEntity] ShipEntity.m:8411: Spawn time: 24.3945 (187.391 seconds ago)

Thinking further at the problem I noticed the similarity between my repairship and the planetPatrol is that it are both ships that started existence with a launch. So I spawned my repair ship and the destination did not change anymore and the buoy was drop on the spot.

Launching in the past has something to do with it.

Post by **Eric Walch** » Sun Jul 12, 2009 1:26 pm

After thinking further I thought about an other common thing with both ships in combination with something new in Oolite: Groups

I targeted both the planetPatrol ship and my repairship and typed in the console:

player.ship.target.group.removeShip(player.ship.target)

This command removes the ships from the station group. And to my surprise, both ships altered course and did what they should do: The patrol ship started patrolling and the repairship dropped it buoy on the spot. The destination in the targetdump was not changing anymore and kept giving the right value for the buoy position.

Question remains how the group stuff affects the destination of a single member.

Screet · Post by **Screet** » Sun Jul 12, 2009 3:06 pm

Eric Walch wrote:
Question remains how the group stuff affects the destination of a single member.

That's interesting! Another point that should be looked at: These suicide ships do not get collision warnings! Probably also a bug in the group code, but may also be in the general code.

Screet

Frame · Post by **Frame** » Sun Jul 12, 2009 3:56 pm

Eric Walch wrote:
After thinking further I thought about an other common thing with both ships in combination with something new in Oolite: Groups

I targeted both the planetPatrol ship and my repairship and typed in the console:

player.ship.target.group.removeShip(player.ship.target)

This command removes the ships from the station group. And to my surprise, both ships altered course and did what they should do: The patrol ship started patrolling and the repairship dropped it buoy on the spot. The destination in the targetdump was not changing anymore and kept giving the right value for the buoy position.

Question remains how the group stuff affects the destination of a single member.

Bingo I can duplicate it... That also explains why the viper keeps rolling alot after being launched... it is trying to orientate itself at the same orientation as the station.

The Question is: did this get introduced when some sort of group error/behaviour was fixed in regard to the escorts...

however, after it was removed(via the debug console) from the group, it got "regrouped", with the station as the leader..... and began patrolling correctly...

So it is at launch somewhere, that it gets "locked" into suicide mode...

Frame · Post by **Frame** » Sun Jul 12, 2009 4:09 pm

something more, something odd

the group reads like this

before removing the ship from the group

Code: Select all

[OOShipGroup "escort group", 2 ships, leader: <StationEntity 0x9e521d0>{"Coriolis Station"}]

after remove it looks like this

Code: Select all

[OOShipGroup "escort group", 1 ships, leader: <StationEntity 0x9e521d0>{"Coriolis Station"}]

Notice the 2 ships, this is right after launch, the other data is taken right after remove... no other ships have had the chance of being deducted from the group..

is the same ship being added to the group twice somehow ?, causing these odd side effects ?

Post by **Eric Walch** » Sun Jul 12, 2009 4:53 pm

Frame wrote:
Notice the 2 ships, this is right after launch, the other data is taken right after remove... no other ships have had the chance of being deducted from the group..

is the same ship being added to the group twice somehow ?, causing these odd side effects ?

The whole group stuff if completely new in 1.73. It has more bugs that must be polished. Commenting out the line in stationEntity.m, that adds the patrol ship to a group, made it act as with 1.72. Also the ships went into behaviour_avoid_collision when coming close to them.

On the group stuff in the console: leader and ships are properties of the group, so you can see what those two ships are by using: group.ships and group.leader. With the station, the leader will be the station, the others are all the launching ships that belong to the station. (Group is not set for launching traders).

One of the oddities I see now it that when a ship is removed from a group, that ship still keeps the the group property. The whole group property should probably be removed for tat ship.

I still fail to see in the code how that effects the destination variable for that ship.

Frame · Post by **Frame** » Sun Jul 12, 2009 7:07 pm

Ok. is there anything special peculiar that the viper is called part of an "escort group" ?

and by that is it, tapping into the escort behavior state, and somehow missing the correct coordinates as in it is trying you act out as a escort for the station like when it is keeping the same orientation and crashing into the planet...

Post by **Eric Walch** » Sun Jul 12, 2009 9:28 pm

Frame wrote:
Ok. is there anything special peculiar that the viper is called part of an "escort group" ?.

I think it is just a default name for station groups. Maybe chosen wrong here. The real escorts groups are also a property of the ship with name "escortGroup".

There is another bug with pirate groups. In the past they were added as individual groups, each with an unique group ID. In the current build all populator added pirates are part of one big group. This results that attacking one pirate will send a groupAttack message to all pirates in the system. The player will hardly see it but it can happen now that an attack is stopped because the pirate switches to a very distant target and immediately loose it because it is out of range.

It was implemented wrong because this was the quickest way to change old groups to new groups. To do it right one must completely reorder parts of the populator code because in the current state is started a new group in the middle of a logic loop.

Was a challenge for me to do... It works now with the exact changes as in the past. When i now target a pirate group and as for its members I get only the names of the ships I actually see as a group.

I will test it a but further to see if I really did not alter any addition statistics and than commit it.

Post by **Eric Walch** » Mon Jul 13, 2009 9:25 pm

Frame, for your info. Mac users are a bit spoiled by the nice stuff Ahruman has put into the console. Target inspectors. These are very powerful floating windows with the main characteristics for a ship. It makes debugging of ship behaviour much easier than on other systems. Just to show you an example:

That also the reason for me to quickly spotting AI bugs as it takes just one keystroke to get the windows on screen. And by clicking the small "i" you open the inspector for other ships mentioned in that window.

its a marvellous job that Ahruman did here to speed up the process of bug squashing.

Diziet Sma · Post by **Diziet Sma** » Mon Jul 13, 2009 11:59 pm

At some point somebody (with more skillz than me) ought to port those features to the other consoles...

Post by **Eric Walch** » Sun Jul 19, 2009 7:52 pm

With revision 2254 the suicide ships should be history. Launching ships are no longer part of an "escort group" but from a "station group". This "station group" is just an applied name but internally they now are part of a _group and not an _escortGroup. Changing this was enough for the fix.

The station is now no longer influencing the destination and rotating of launching ships. Looking back in the code I see these new groups were added mid February, the start of this topic, so I assume all station ships (including carrier vipers) must have had this odd behaviour since.

For the GRS company this is good as well as bad news. Good is that the repairships now drop their buoy again on the spot. Bad is that there are less buoys to repair that generate income for the GRS cie.

All in all I think this new group behaviour is a good change. In the past it was just an ID of the group-leader that was attached to the individual ships, now they are part of an list that is much easier accessible.

e.g. in the past escorts were only linked by their mother. When their mother died, they became individual ships. Now former escorts react also on attacks of other group members after mum died. And for the station group: The ships are already put on the list when the launch instruction is given. This can be long before the actual launch.

-- ps.
On the buoyRepair subject. Last week I uploaded a slightly improved version. The launching repair ship now does not fly straight ahead to replace the buoy, but first makes a 90 degr turn and only after some times heads for the buoy position. This way no fast launchers hitting in the back of the ship. And with revision 2254 it is really following this flight path.

zevans · Post by **zevans** » Sun Jul 19, 2009 10:32 pm

Stuff is getting fixed at a serious rate at the moment, good one!