NPC-entities facing problem

[Commander McLane]

I have a problem letting my freshly spawned entities face the correct destination and move towards it. Up to yesterday night I just thought I am a bad AI-scripter, but then I found something that lets me think something is broken.

I am working on an OXP inspired by Generation Ships (and Drew's story gave me the kick to finally start on it. The idea is older and has been roughly summarized here.

The actual OXP involves a Generation Ship spawned at a point fairly far away from the system center and heading towards the planet. So I gave it an AI that looked like this:

Code: Select all

{
	GLOBAL = {ENTER = ("setStateTo: HEAD_FOR_PLANET"); EXIT = (); UPDATE = (); };
    "HEAD_FOR_PLANET" = {
		ENTER = (setCourseToPlanet, "setDesiredRangeTo: 25600.0", "setSpeedFactorTo: 1.0", performFlyToRangeFromDestination);
		"TARGET_FOUND" = (setTargetToFoundTarget, "scriptActionOnTarget: set: mission_ghosts GENSHIP_FOUND", "pauseAI: 120.0", "setStateTo: HEAD_FOR_PLANET");
		"NOTHING_FOUND" = ("pauseAI: 10.0", "setStateTo: HEAD_FOR_PLANET");
		UPDATE = ("setDesiredRangeTo: 25600.0", "scanForNearestShipWithRole: player");
		EXIT = ();
	};
}

It worked. The ship was slowly heading for the planet, and when I came close the mission_variable was set, triggering the next stage of the mission.

Then I had the idea to introduce two other planets that would help the player to find the Generation Ship in the first place (like LittleBear did to help locate the victims in Assassins). Said and done, I figured out the positions of the planets and put the Generation Ship in-between. Problem: Now the ship is heading towards one of those two new planets. A quick look in the wiki reveals:

setCourseToPlanet

Selects the nearest planet it can find, reaching desired range 50 km from the planet.

Okay, my two new planets happen to be closer to the ship's position, so it's logical what happened.

But there must be other ways to make the ship head for the original planet. So a change to the AI:

Code: Select all

{
	GLOBAL = {ENTER = ("setStateTo: HEAD_FOR_PLANET"); EXIT = (); UPDATE = (); };
    "HEAD_FOR_PLANET" = {
		ENTER = ("setCoordinates: pwm 0 0 0", setDestinationFromCoordinates, "setDesiredRangeTo: 50.0", "setSpeedFactorTo: 1.0", performFlyToRangeFromDestination);
		"TARGET_FOUND" = (setTargetToFoundTarget, "scriptActionOnTarget: set: mission_ghosts GENSHIP_FOUND", "pauseAI: 120.0", "setStateTo: HEAD_FOR_PLANET");
		"NOTHING_FOUND" = ("pauseAI: 10.0", "setStateTo: HEAD_FOR_PLANET");
		UPDATE = ("setDesiredRangeTo: 25600.0", "scanForNearestShipWithRole: player");
		EXIT = ();
	};
}

Should do the trick, shouldn't it? -- Except that it doesn't! Whenever I come close to the Generation Ship it faces a direction roughly normal to the planet, slowly (very slowly!) disappearing into the void.

OK, thinks me, perhaps the coordinates are just to far away for calculating correctly? After all Selezen has used the same methods in his tgy.oxp for the patrol AI of his graveyard police, but of course in a relatively narrow area. And my Generation Ship comes into being at coordinates pwm 1864100 -4638900 -60200, that's five million meters away from the planet. So I modify the AI, setting the destination coords to one tenth of the total distance. So it's:

Code: Select all

{
	GLOBAL = {ENTER = ("setStateTo: HEAD_FOR_PLANET"); EXIT = (); UPDATE = (); };
    "HEAD_FOR_PLANET" = {
		ENTER = ("setCoordinates: pwm 1677690 -4175010 -54180", setDestinationFromCoordinates, "setDesiredRangeTo: 50.0", "setSpeedFactorTo: 1.0", performFlyToRangeFromDestination);
		"TARGET_FOUND" = (setTargetToFoundTarget, "scriptActionOnTarget: set: mission_ghosts GENSHIP_FOUND", "pauseAI: 120.0", "setStateTo: HEAD_FOR_PLANET");
		"NOTHING_FOUND" = ("pauseAI: 10.0", "setStateTo: HEAD_FOR_PLANET");
		UPDATE = ("setDesiredRangeTo: 25600.0", "scanForNearestShipWithRole: player");
		EXIT = ();
	};
}

But still the ship heads somewhere else. I try to give the ship some time to turn by inserting "pauseAI: 10.0" into the ENTER-part. No effect. I replace the performFlyToRangeFromDestination by checkCourseToDestination and put the "setSpeedFactorTo: 1.0", performFlyToRangeFromDestination in a "COURSE_OK". Nothing. I seperate the beginning state, where the ship travels and scans for the player, from a final state where it just travels. I try performFaceDestination together with the confirming AI-message instead of checkCourseToDestination. In the end I have got a rather complicated AI (compared to the beginning).

Code: Select all

{
	GLOBAL = {ENTER = ("setStateTo: START_JOURNEY"); EXIT = (); UPDATE = (); };
    "CONTINUE_JOURNEY" = {
		ENTER = ();
		UPDATE = ("setCoordinates: pwm 1677690 -4175010 -54180", setDestinationFromCoordinates, "setDesiredRangeTo: 50.0", "setSpeedFactorTo: 1.0", performFlyToRangeFromDestination, "pauseAI: 15.0");
		EXIT = ();
	};
    "START_JOURNEY" = {
		ENTER = ("setCoordinates: pwm 1677690 -4175010 -54180", setDestinationFromCoordinates, "setDesiredRangeTo: 50.0", performFaceDestination);
		"FACING_DESTINATION" = ("setSpeedFactorTo: 1.0", performFlyToRangeFromDestination);
		"TARGET_FOUND" = (setTargetToFoundTarget, "scriptActionOnTarget: set: mission_ghosts GENSHIP_FOUND", "pauseAI: 10.0", "setStateTo: CONTINUE_JOURNEY");
		"NOTHING_FOUND" = ("pauseAI: 15.0", "setStateTo: START_JOURNEY");
		UPDATE = ("setDesiredRangeTo: 25600.0", "scanForNearestShipWithRole: player");
		EXIT = ();
	};
}

Nothing. It looks as if the ship is heading to a completely random wrong direction. I am stuck.

Then I try to have a look at which destination coordinates are actually set. Fortunately there is the key_dump_target_state. So here is all information about my Generation Ship:

Code: Select all

[dumpState]: State for <ShipEntity Generation Ship 193>:
  [dumpState.entity]: Universal ID: 193
  [dumpState.entity]: Scan class: CLASS_NEUTRAL
  [dumpState.entity]: Status: STATUS_IN_FLIGHT
  [dumpState.entity]: Position: (4.99978e+06, -441.292, 520072)
  [dumpState.entity]: Orientation: (1 + 0i + 0j + 0k)
  [dumpState.entity]: Distance travelled: 21103.9
  [dumpState.entity]: Energy: 500000 of 500000
  [dumpState.entity]: Mass: 9.4667e+11
  [dumpState.entity]: Flags: isShip, hasMoved, isSunlit
  [dumpState.shipEntity]: Name: Generation Ship
  [dumpState.shipEntity]: Roles: ghost_from_past_1
  [dumpState.shipEntity]: Subentity count: 11
  [dumpState.shipEntity]: Time since shot: 100352
  [dumpState.shipEntity]: Behaviour: BEHAVIOUR_FLY_TO_DESTINATION
  [dumpState.shipEntity]: Destination: (4.49981e+06, -1180.1, 498050)
  [dumpState.shipEntity]: Other destination: (4.49981e+06, -1180.1, 498050)
  [dumpState.shipEntity]: Waypoint count: 0
  [dumpState.shipEntity]: Desired speed: 60
  [dumpState.shipEntity]: Fuel: 0
  [dumpState.shipEntity]: Fuel accumulator: 1
  [dumpState.shipEntity]: Missile count: 0
  [dumpState.shipEntity.ai]: AI:
    [dumpState.ai]: State machine name: ghostGenship1AI.plist
    [dumpState.ai]: Current state: START_JOURNEY
    [dumpState.ai]: Next think time: 370.386
    [dumpState.ai]: Next think interval: 370.386
  [dumpState.shipEntity]: Frustration: 0
  [dumpState.shipEntity]: Success factor: 500457
  [dumpState.shipEntity]: Shots fired: 0
  [dumpState.shipEntity]: Hull temperature: 60
  [dumpState.shipEntity]: Heat insulation: 1
  [dumpState.shipEntity]: Flags: has_ecm, escortsAreSetUp, proximity_alert

This reveals some important facts: (1) The entity is spawned at its correct coordinates: In my current system the absolute position (4.99978e+06, -441.292, 520072) translates quite exactly to pwm 1864100 -4638900 -60200 (of course by the time I reach the ship it has already travelled some 20000 meters). (2) Its destination is set to the correct coordinates: Destination: (4.49981e+06, -1180.1, 498050) translates to pwm 1677690 -4175010 -54180. (3) Nevertheless it is facing to another direction: Orientation: (1 + 0i + 0j + 0k). I find this important, because it's not some random direction, but exactly the z-axis. I guess every entity is originally spawned along this axis. And this means the ship hasn't turned at all. Nevertheless the FACING_DESTINATION-message has been received and it has started moving.

Something even more interesting: I'll give it another try. This time when I arrive the ship starts turning:

Code: Select all

[dumpState]: State for <ShipEntity Generation Ship 196>:
  [dumpState.entity]: Universal ID: 196
  [dumpState.entity]: Scan class: CLASS_NEUTRAL
  [dumpState.entity]: Status: STATUS_IN_FLIGHT
  [dumpState.entity]: Position: (4.99934e+06, -2025.3, 519948)
  [dumpState.entity]: Orientation: (0.690084 + 0.330817i + 0.278344j - 0.580404k)
  [dumpState.entity]: Distance travelled: 21211.6
  [dumpState.entity]: Energy: 500000 of 500000
  [dumpState.entity]: Mass: 9.4667e+11
  [dumpState.entity]: Flags: isShip, hasMoved, isSunlit
  [dumpState.shipEntity]: Name: Generation Ship
  [dumpState.shipEntity]: Roles: ghost_from_past_1
  [dumpState.shipEntity]: Subentity count: 11
  [dumpState.shipEntity]: Time since shot: 100354
  [dumpState.shipEntity]: Behaviour: BEHAVIOUR_FLY_TO_DESTINATION
  [dumpState.shipEntity]: Destination: (4.96949e+06, 3020.35, 544087)
  [dumpState.shipEntity]: Other destination: (4.49981e+06, -1180.1, 498050)
  [dumpState.shipEntity]: Waypoint count: 0
  [dumpState.shipEntity]: Desired speed: 60
  [dumpState.shipEntity]: Fuel: 0
  [dumpState.shipEntity]: Fuel accumulator: 1
  [dumpState.shipEntity]: Missile count: 0
  [dumpState.shipEntity.ai]: AI:
    [dumpState.ai]: State machine name: ghostGenship1AI.plist
    [dumpState.ai]: Current state: CONTINUE_JOURNEY
    [dumpState.ai]: Next think time: 365.46
    [dumpState.ai]: Next think interval: 365.46
  [dumpState.shipEntity]: Frustration: 0
  [dumpState.shipEntity]: Success factor: 38718.2
  [dumpState.shipEntity]: Shots fired: 0
  [dumpState.shipEntity]: Hull temperature: 60
  [dumpState.shipEntity]: Heat insulation: 1
  [dumpState.shipEntity]: Flags: has_ecm, escortsAreSetUp, proximity_alert

It turns out it makes an evasive manoeuvre:

Code: Select all

[dumpState]: State for <ShipEntity Generation Ship 196>:
  [dumpState.entity]: Universal ID: 196
  [dumpState.entity]: Scan class: CLASS_NEUTRAL
  [dumpState.entity]: Status: STATUS_IN_FLIGHT
  [dumpState.entity]: Position: (4.99849e+06, -1968.19, 520169)
  [dumpState.entity]: Orientation: (0.441492 + 0.558536i + 0.456877j - 0.533279k)
  [dumpState.entity]: Distance travelled: 22215.4
  [dumpState.entity]: Energy: 500000 of 500000
  [dumpState.entity]: Mass: 9.4667e+11
  [dumpState.entity]: Flags: isShip, hasMoved, isSunlit
  [dumpState.shipEntity]: Name: Generation Ship
  [dumpState.shipEntity]: Roles: ghost_from_past_1
  [dumpState.shipEntity]: Subentity count: 11
  [dumpState.shipEntity]: Time since shot: 100371
  [dumpState.shipEntity]: Behaviour: BEHAVIOUR_AVOID_COLLISION
  [dumpState.shipEntity]: Destination: (4.99366e+06, -1917.89, 520183)
  [dumpState.shipEntity]: Other destination: (4.49981e+06, -1180.1, 498050)
  [dumpState.shipEntity]: Waypoint count: 0
  [dumpState.shipEntity]: Desired speed: 60
  [dumpState.shipEntity]: Fuel: 0
  [dumpState.shipEntity]: Fuel accumulator: 1
  [dumpState.shipEntity]: Missile count: 0
  [dumpState.shipEntity.ai]: AI:
    [dumpState.ai]: State machine name: ghostGenship1AI.plist
    [dumpState.ai]: Current state: CONTINUE_JOURNEY
    [dumpState.ai]: Next think time: 395.47
    [dumpState.ai]: Next think interval: 395.47
  [dumpState.shipEntity]: Frustration: 0
  [dumpState.shipEntity]: Success factor: 499177
  [dumpState.shipEntity]: Shots fired: 0
  [dumpState.shipEntity]: Hull temperature: 60
  [dumpState.shipEntity]: Heat insulation: 1
  [dumpState.shipEntity]: Flags: has_ecm, escortsAreSetUp, proximity_alert

Note that the behaviour has changed to Behaviour: BEHAVIOUR_AVOID_COLLISION. There is nothing like that in its AI, so it must be hardcoded. Note also that in these two snapshots the Destination is much closer to the ship than the Other destination The interesting thing is that this evasive manoeuvre--but only the evasive manoeuvre--finally sets the ship exactly on its desired course to the planet, which doesn't change anymore afterwards:

Code: Select all

[dumpState]: State for <ShipEntity Generation Ship 196>:
  [dumpState.entity]: Universal ID: 196
  [dumpState.entity]: Scan class: CLASS_NEUTRAL
  [dumpState.entity]: Status: STATUS_IN_FLIGHT
  [dumpState.entity]: Position: (4.98051e+06, -1841.83, 519061)
  [dumpState.entity]: Orientation: (0.441492 + 0.558536i + 0.456877j - 0.533279k)
  [dumpState.entity]: Distance travelled: 43635.4
  [dumpState.entity]: Energy: 500000 of 500000
  [dumpState.entity]: Mass: 9.4667e+11
  [dumpState.entity]: Flags: isShip, hasMoved, isSunlit
  [dumpState.shipEntity]: Name: Generation Ship
  [dumpState.shipEntity]: Roles: ghost_from_past_1
  [dumpState.shipEntity]: Subentity count: 11
  [dumpState.shipEntity]: Time since shot: 100728
  [dumpState.shipEntity]: Behaviour: BEHAVIOUR_FLY_TO_DESTINATION
  [dumpState.shipEntity]: Destination: (4.49981e+06, -1180.1, 498050)
  [dumpState.shipEntity]: Other destination: (4.49981e+06, -1180.1, 498050)
  [dumpState.shipEntity]: Waypoint count: 0
  [dumpState.shipEntity]: Desired speed: 60
  [dumpState.shipEntity]: Fuel: 0
  [dumpState.shipEntity]: Fuel accumulator: 1
  [dumpState.shipEntity]: Missile count: 0
  [dumpState.shipEntity.ai]: AI:
    [dumpState.ai]: State machine name: ghostGenship1AI.plist
    [dumpState.ai]: Current state: CONTINUE_JOURNEY
    [dumpState.ai]: Next think time: 740.62
    [dumpState.ai]: Next think interval: 740.62
  [dumpState.shipEntity]: Frustration: 0
  [dumpState.shipEntity]: Success factor: 481162
  [dumpState.shipEntity]: Shots fired: 0
  [dumpState.shipEntity]: Hull temperature: 60
  [dumpState.shipEntity]: Heat insulation: 1
  [dumpState.shipEntity]: Flags: has_ecm, escortsAreSetUp, proximity_alert

I know something is wrong here, but I have no idea what it is. To me it seems the AI-handling is somehow broken. Or am I making some stupid mistake?

I should mention that I have a similar problem with the Hacker Outposts in Anarchies.oxp. They are spawned with spawnShip: at one of a couple of predefined pseudo-random positions in a system. I've done it that way because I want them to face the planet wherever they are. So I am using a spawn-dict in shipdata to define their facing_position as pwm 0 0 0. But they don't face the planet. Instead they are facing roughly along the witchpoint-planet-axis. Now I guess that this as well may be exactly Orientation: (1 + 0i + 0j + 0k) in absolute coordinates.

And this again indicates to me that something doesn't work properly with the set-up and especially the orientation of entities created by an OXP.

If the coders need more information, please tell me so. Ahruman already has a testcase of my new OXP with the Generation Ship, so he should be easily able to reproduce it. (Just that after sending it to you I continued fiddling with the AI, so the one in the testcase isn't the latest I posted here.)

[TGHC]

Just a thought, why not add the planets further away, so that the ship then heads for the nearest planet, ie the one you want it to.

This might be too simple, I don't understand any of the technical stuff above, so tell me to go forth and multiply if I'm talking rubbish.

[Commander McLane]

so tell me to go forth and multiply if I'm talking rubbish.

I would never do such a thing! I am from a generation where we still had respect for the elders!

But it is really no solution. I need the planets to enable the player to find that Generation Ship (and besides, they look nicely and I want the player to appreciate that). So the ship has to be somewhere close to the planets. Of course they could also be faaaar faaaaaaaaaaar away and just indicate the direction, but actually I love passing the first one, before I come near the second.

So putting them far away would really only be a last resort, if everything els has failed.

[Disembodied]

Could you use setDestinationToStationBeacon instead? At least until the ship is in close enough to the "main" planet to reliably find it as its target? Or am I talking rubbish?

Edit: or, at the risk of spouting more garbage, setCourseToWitchpoint?

[Commander McLane]

Could you use setDestinationToStationBeacon instead?

I have thought about that and could resort to it. I have however not tried it out yet and don't know whether it would work. Also there is a small chance that one of the kamikaze-pilots discussed here could destroy the station beacon. Where would my ship head then?

And after all: I still assume there is an underlying problem in Oolite, and this problem should be sorted out. That's why I put this thread in "Testing and Bug reports", and not elsewhere.

[Disembodied]

And after all: I still assume there is an underlying problem in Oolite, and this problem should be sorted out. That's why I put this thread in "Testing and Bug reports", and not elsewhere.

Ah... an excellent point. I tend to forget that other people aren't all in a state of delighted surprise when they get the program to do something approaching what they wanted it to!

[Commander McLane]

Okay, I got myself a BerliOs account and put it there. I hope the coders will look into it.

[Commander McLane]

Oh, I was just notified that the bug was assigned to Kaks.

@Kaks: I hope you can make something out of it.

[Kaks]

@Kaks: I hope you can make something out of it.

So do I!

There's a lot of 'delicate' code in there: when you try to fix one thing, it's extremely easy to break something else without noticing... I'll try to be very careful. (read 'slow in making any real progress'!)

Should get there in the end, though!

[Kaks]

From the better-late-than-never department:
I believe I found out what was causing this problem (facing_positon would be wrong in 50% of the cases).

Testing is under way to make sure I'm not completely wrong. If I'm right, it turns out I'd been looking at the wrong piece of code all along. Just stumbled upon this bug again purely by chance: as I was looking for something completely different, I noticed something that didn't look quite right...

[Commander McLane]

That's good news.

Good to know that another bug will be squashed.

[Eric Walch]

In your first post you mention several problems. One is that the ship goes into a "BEHAVIOUR_AVOID_COLLISION". That is an intended behaviour that temporarily overrules some of the other behaviours to avoid a collision. Specially with the generation ship it is more likely to happen.

There is one trick to avoid ships going into this behavior and that is to make it the primary target. Most behaviours have a check to not react on a primary target. Problem was that it was most, not all. e.g. face_destination ignored collision avoidance for primary target but fly_to_destination didn't. I couldn't find a reason why, so last weekend I made a change that none of the behaviours that can go into a BEHAVIOUR_AVOID_COLLISION will react on primary targets. Most behaviours already monitor the primary target and avoid collisions within their own behaviour. (e.g. attackers or scoopers)

It are specially the unmonitored secondary objects that ships should avoid automatic. e.g. a scavenger heading for a cargopod that is floating a bit to close to the station. It should get frightened by the station, but not by the cargopod.
Or a fight in the middle of the Tionisla graveyard: the target is monitored by the attack behaviour, but not all the monuments. I did some fights there there last weekend and none of the patrol ships hit the monuments during my first few tests. (This still has to be tested further though)

Last week is trunk changed a bit, so ships go sooner into avoidance mode and it really helps a scavenger from going for a pod floating a bit to close to the station. I hope this change has no side effects so it can stay in the code.

The only thing that scripters than have to remember is that a primary target will not scare of a ship, so when you want to navigate very close to a generation ship, just make that the primary target.

[Eric Walch]

I should mention that I have a similar problem with the Hacker Outposts in Anarchies.oxp. They are spawned with spawnShip: at one of a couple of predefined pseudo-random positions in a system. I've done it that way because I want them to face the planet wherever they are. So I am using a spawn-dict in shipdata to define their facing_position as pwm 0 0 0. But they don't face the planet. Instead they are facing roughly along the witchpoint-planet-axis. Now I guess that this as well may be exactly Orientation: (1 + 0i + 0j + 0k) in absolute coordinates.

I just revived this old bug. Kaks nearly squashed it, but not 100%.

In the original code the quaternion rotation was calculated in the wrong direction. After the rotation there was a check if the orientation was off by more than 90°. If yes, the ship was rotated a further 180°. So the ships only pointed roughly in the right direction as far as I see. Kaks fixed this but also removed the check for more than 90° off.

But there were two more underlying bugs in the code. The code that calculated the rotation had a bug that resulted in returning once in a while with the [1,0,0,0] quaternion instead of the correct one. That bug was squashed in 1.75.0.

I just tested your old 1.0 version of anarchies. 3 out of 4 outposts were oriented correctly. The one behind the planet still pointed 180° off. That one was caused by the rotation calculation. For a ship at that position it had to calculate a rotation from [0,0,1] to [0,0,-1] Rotation goes over the shortest route, but for a 180° rotation there is no shortest route. There are endless possible quaternions for such a rotation. All ending with the same heading, but with a different rotation along its heading. The code was written in a way it would do no rotation at all in that case. I think not rotating is always wrong, so I now will change it so that is just chooses a rotation axis when the two starting vectors are perpendicular instead of doing nothing.

With the change, I now get all four of your outposts aligned correctly in your old 1.0 version. I'll do a bit more testing, but I don't see a reason for bad side effects.

[JensAyton]

when the two starting vectors are perpendicular

Antiparallel, surely? Otherwise I’m misunderstanding the bug.

[Eric Walch]

Antiparallel, surely? Otherwise I’m misunderstanding the bug.

My bad english. I have had all the vector math at school in dutch. I still have troubles with some english equivalents of dutch math expressions.

I mend of course opposite pointing (180 degr) . You are right perpendicular is at a 90 deg angle.