enterPlayerWormhole not working in interstellar space

[Commander McLane]

EDIT: cause of bug found, thread title updated


Okay, we solved the first problem with this new method, by deleting the wormhole entry from my save file. And it does work with random ships with my followPlayerAI.

However, I can't get it to work with interstellar help, which is the place where I actually want to put it to work.

Again I put a test case on the box, this time the OXP only.

What's the problem? The NPC trader stranded in interstellar space won't follow me to the next system. Everything goes according to plan right to the point where I jump. In the target inspector everything looks exactly like when it is working with my previous test case. The ship doesn't die. But it doesn't emerge on the other side either. It's like it somehow gets stuck in witchspace.

What can cause this? I can only imagine that there is an important difference in the AIs, or something in the interference of AI and ship script. But I can't see it. I need the eyes of people who know what to look for.

So what do you have to do? Download and install the OXP. Make a misjump. I suggest you do that whilst cloaked. Get out of the ongoing battle to some quiet place. Summon an interstellar_help_gecko (has no hyperdrive and is therefore guaranteed to follow you, if you summon a more generic interstellar_help_trader he may want to buy fuel instead). Go through the process, which begins three messages by the NPC, and then needs to to get within 1000 meters of him. Fly gently in any direction, he will follow you. Press 'H'. Wait for him in your new system. If you're on a Mac, watch the think time in the AI inspector run and run forever (mine from the last trial is close to 1200 now). Finally: tell me what I'm doing wrong.



By the way: the NPC follows the player in state FOLLOW_PLAYER via performIntercept. According to the Wiki, if the NPC doesn't get closer after ten seconds (which it won't if you fly at high speed) it receives a FRUSTRATED message. Only that doesn't happen. Frustration doesn't grow, and no FRUSTRATED message is received. Don't know what's wrong with that.

Oh, and as far as I can see, the log contains absolutely nothing helpful.

[Eric Walch]

There is clearly a bug somewhere. However, ships work a bit different when entering a wormhole than you might think.

1) Ship is fully removed from the universe, meaning that also its AI is no longer updated and behaviours do nothing. When you have a script reference to it, you can still examine its properties.
2) The ship is added to a wormhole entity. This entity is updated and constant looks at the current time and the arrival time for the ships in it.
3) When the wormhole entity detects that it is time to spit out a ship, that ship is added to the universe again. The AI is set to the GLOBAL state and updating of the ship resumes.
4) When the wormhole entity detects that it has no ships left, it destroys itself.

The ship-status means that the ship was added to the wormhole. Seeing your description of the problem it seems it goes wrong in adding the ship to the new system. But Micha is the wormhole expert and might know were it could go wrong.

[Commander McLane]

I repeat: it works every time with the small test AI I posted before (and generic Oolite ship script).

It never works with interstellarHelpAI and interstellar-help-ship script.

And I don't see a fundamental difference in the AIs.

The ship scripts are of course different, but I don't see which negative effects the ship script could have. There is a script variable and a mission variable created when the player jumps out, and checked when the follower is re-spawned (which never happens, because he isn't re-spawned). Can this be the culprit? I have now even commented out the shipDied part from the ship script, because I didn't know whether it's called when I enter the wormhole and may screw things up.

[Commander McLane]

I got it (and in hindsight, as ever so often, it's painfully obvious)!

Of course there is a huge difference between the two cases I described. When I used my small test AI posted earlier, I was always in a system. This case worked.

But interstellar_help.oxp is about jumping out of interstellar space, so I tried it there (d'oh!). And it didn't work.

So now I had the brilliant idea to jump into interstellar space, spawn an ordinary trader, and try my test AI on him. Result: didn't work. Entering wormhole, but not exiting again.

So, the bug is: currently enterPlayerWormhole doesn't work in interstellar space. And I really could've seen that earlier. I was just too fixated on possible causes in my AI and script.

Updating the thread title as well.

[Eric Walch]

So now I had the brilliant idea to jump into interstellar space, spawn an ordinary trader, and try my test AI on him. Result: didn't work. Entering wormhole, but not exiting again.

I couldn't see a difference the the working example and your example, except that it might be the interstellar space. I was going to try the other way around and test your script in normal space . I had just finishes changing your script to make that possible. Not tested yet but I know the answer already reading your post.

On testing I noticed one minor bug: the gecko kept ramming the back of my BCC when following me. Maybe the range for interceptTarget should be set larger?

[Commander McLane]

On testing I noticed one minor bug: the gecko kept ramming the back of my BCC when following me. Maybe the range for interceptTarget should be set larger?

Yes, it certainly could. Or perhaps I could do something else on DESIRED_RANGE_ACHIEVED, instead of the momentary performHold and restarting the AI state? I had no better idea, perhaps you got one?

And what about the ship not getting frustrated even if you fly away from it constantly? Any thoughts on that?

[Eric Walch]

Or perhaps I could do something else on DESIRED_RANGE_ACHIEVED, instead of the momentary performHold and restarting the AI state? I had no better idea, perhaps you got one?

And what about the ship not getting frustrated even if you fly away from it constantly? Any thoughts on that?

InterceptTarget was ment to be used for missiles. When used for other ships it might bug. The internal code is:

Code: Select all

- (void) behaviour_intercept_target:(double) delta_t
{
	double  range = [self rangeToPrimaryTarget];
	if (behaviour == BEHAVIOUR_INTERCEPT_TARGET)
	{
		desired_speed = maxFlightSpeed;
		if (range < desired_range)
		{
			[shipAI reactToMessage:@"DESIRED_RANGE_ACHIEVED" context:@"BEHAVIOUR_INTERCEPT_TARGET"];
		}
		desired_speed = maxFlightSpeed * [self trackPrimaryTarget:delta_t:NO];
	}

As you see, very short. Not all behaviors are adding up frustration. This one also does not. Interesting is that it will set a new speed after the DESIRED_RANGE_ACHIEVED message. In that reactToMessage your AI changes behaviour to performHold. That command sets the speed to zero, but immediately after that the speed is set back to a value. But as said, this behaviour is ment for missiles, and those are blowing themselves up after reaching their destination
Some other AIs also use it for ships, but they continue with behaviours that constant control speed. PerformHold only sets the speed to zero in its first call.

probably you should use performFlyToRangeFromDestination. That code has a auto slow down when approaching its destination. It will also collect frustration and really stop when reaching its destination.

[Commander McLane]

probably you should use performFlyToRangeFromDestination. That code has a auto slow down when approaching its destination. It will also collect frustration and really stop when reaching its destination.

That's what the released version has. I am mainly experimenting with performIntercept, because the results of performFlyToRangeFromDestination are not fully satisfactory. If you fly slower than the NPC's max speed, it makes the NPC very wobbly, constantly heading for different points on the sphere around you. Perhaps I could reduce that by taking a very small desired range. But then the NPC would crash into the player if he stops. Still, I could try that and see if it gives a better optical impression than the bigger range in the released version (not actually that big, mind you: 500 meters; but I could try 200 or 100).

[Micha]

Re: Wormhole bug: the code works. kinda.

The problem is that the wormhole going from Witchspace to a System still uses as origin the player's original starting System.

ie:
S1 -> (WH:S1->S2) -> Witchspace -> (WH: S1 -> S2) -> S2

So the ship that's following the player does so, but takes the full time. If you wait long enough, it will eventually pop out.

[Kaks]

Re: Wormhole bug: the code works. kinda.

aka we'll try and fix it..

[Commander McLane]

Re: Wormhole bug: the code works. kinda.

The problem is that the wormhole going from Witchspace to a System still uses as origin the player's original starting System.

ie:
S1 -> (WH:S1->S2) -> Witchspace -> (WH: S1 -> S2) -> S2

So the ship that's following the player does so, but takes the full time. If you wait long enough, it will eventually pop out.

Which can literally take hours. Not good for creating the impression that the ship follows you.

[Micha]

Which can literally take hours. Not good for creating the impression that the ship follows you.

I may have expressed myself poorly.
What I meant is that the code works (ie, following ships -do- follow, unlike the other bug where they didn't) , but it's got this timing bug.

So as kaks said, we'll fix it.

[Commander McLane]

Which can literally take hours. Not good for creating the impression that the ship follows you.

I may have expressed myself poorly.
What I meant is that the code works (ie, following ships -do- follow, unlike the other bug where they didn't) , but it's got this timing bug.

Don't worry, that's how I understood it.

In fact, Ahruman wrote early on that if the ship is still visible in my inspector, it must emerge eventually. I just didn't wait for long enough, but that is because I expected the ship to emerge only a few seconds after myself.

By the way: is there a property of the saved wormhole which I could access in the JS-console, in order to find out when the ship is going to be re-spawned?

[Micha]

By the way: is there a property of the saved wormhole which I could access in the JS-console, in order to find out when the ship is going to be re-spawned?

No; wormholes don't have a JS presence at all, and the ship doesn't know anything about the wormhole it's in either. Both would need to be added - difficult during a feature-freeze

[Commander McLane]

I don't expect you to thaw anything.

I'm more than happy if a bug fix can be made.