addShipsToRoute using a too wide radius?

[Commander McLane]

According to the Wiki the addShipsToRoute method adds a ship to a route, "within scanner range of this position" (although it isn't exactly clear what 'this position' means in the context).

Anyway, my expectation was the ships would be added within scanner range of the exact line between the two end points specified.

However, this isn't the case. I just spawned six ships using addShipsToRoute. Two of them were added outside the scanner range of someone flying close to the middle of the corridor, namely:

Code: Select all

> system.addShipsToRoute("flying_dutchman_runner", 1, 0.25, "wp")
[[Ship "Cobra Mark I" position: (9152.73, -37698, 109562) scanClass: CLASS_NEUTRAL status: STATUS_IN_FLIGHT]]
> system.addShipsToRoute("asteroid", 1, 0.25, "wp")
[[Ship "Asteroid" position: (32762.1, 4983.98, 135037) scanClass: CLASS_ROCK status: STATUS_IN_FLIGHT]]

I am play testing FlyingDutchman.oxp, and was wondering why I never met the just spawned ship en route to the planet. Only then I took a closer look at its spawning coordinates and continued to test with asteroids instead.

As a scripter, when using addShipsToRoute and addGroupToRoute, my intention is to spawn something which the player will be likely to meet on his way to the planet (or the sun). If one third of the time he won't, the methods become essentially useless for me. Therefore I would plead for reducing the spawning radius of the methods to 25600 meters from the straight line. Maybe 30000. But almost 39000 meters like in the first example is too much.

[Switeck]

I was using these in testing:
system.addGroupToRoute("pirate", 9, 0.1);
system.addGroupToRoute("thargoid", 9, 0.;

...And they have the same problem. The 9 ships aren't in scanner range of each other and typically wander off in different directions as a result, not giving each other support like I hoped.

[DaddyHoggy]

Ah, got to love those stray, accidental emoticons...

[Commander McLane]

I was using these in testing:
system.addGroupToRoute("pirate", 9, 0.1);
system.addGroupToRoute("thargoid", 9, 0.8 );

...And they have the same problem. The 9 ships aren't in scanner range of each other and typically wander off in different directions as a result, not giving each other support like I hoped.

Not even being in scanner range of each other is of course really serious.

Note, by the way, that using your syntax the Thargoids cannot be expected to be close to the centre of the corridor. If you don't specify the route by adding "wp" as a fourth argument, the ships will be spawned along the line between witchpoint and main station, which is not the same as between witchpoint and planet. You won't notice a difference between the two in the first case, because at 10% of the distance the two lines are pretty close together. But you will notice at 80% of the distance, where the difference will be much more than a scanner radius, if the station sits sideways of the planet.

[Switeck]

Hardly mattered in that case, though thanks for pointing it out...as I have it really screwed up from doing that elsewhere.
(The Thargoids would still be close enough between the end of the shipping lane and station to catch traders heading to station. I didn't want them to die really fast, so if they miss some/most of the traders that's fine.)

[Eric Walch]

Therefore I would plead for reducing the spawning radius of the methods to 25600 meters from the straight line. Maybe 30000. But almost 39000 meters like in the first example is too much.

I agree. I also noticed that some of the ships were never met. I did look in the internal C-code itself and there it used:

Code: Select all

[self addShipsAt:pos withRole:role quantity:count withinRadius:SCANNER_MAX_RANGE asGroup:YES]

That ranges always seemed correct to me, so I thought I was imagine things. However I never looked to closely at the resulting radius after spawning.

And I think that the groupToRoute should place the ships from one command together as a group. Now they are individually randomised. Therefor I use the command:

Code: Select all

system.addGroup("Foo", 3, this.randonPositionOnRoute(), 5E3);

this.randonPositionOnRoute = function ()
{
    var end = system.mainPlanet.position;
    end.z -= 2 * system.mainPlanet.radius;    
    return Vector3D.interpolate([0,0,0], end, Math.random()).add(Vector3D.randomDirectionAndLength(20E3));
};

So, the normal addGroup command with a custom function to calculate the route.

[JensAyton]

By the way, “E3” is nerd speak for “times a thousand”. :-)

[Eric Walch]

By the way, “E3” is nerd speak for “times a thousand”.

Yes, I am lazy and hate to count zeros. I find it more recognizable for long numbers when re-reading the code. The same does my electricity supplier on their invoices. Although they use 'k' instead of '000'.

[Commander McLane]

Anyway, apart from nerd-speak and work-arounds, is this going to be fixed?

[Eric Walch]

Anyway, apart from nerd-speak and work-arounds, is this going to be fixed?

If the bug is found. Seeing the code it is clearly intended to only spawn within scanner range of the centre-line of the route. Some months ago I looked already at the code but it all looked okay. Yesterday I looked at it in more detail. I still don't see why it can create positions outside the range.

Conclusion it might get fixed, but there is no guarantee it is found. Maybe one of the others can spot were it goes wrong?

[Commander McLane]

My first idea was that it is somehow happening twice:

First there is a point created within scanner range of the central line. Then the ships are spawned within scanner range of this point. That would effectively put them within twice the scanner range of the central line.

Could that be?

[Eric Walch]

My first idea was that it is somehow happening twice:

First there is a point created within scanner range of the central line. Then the ships are spawned within scanner range of this point. That would effectively put them within twice the scanner range of the central line.

Could that be?

Yes, that was what I also thought but didn't found it. I just found it. The routine that calculates the fractional position in the route already adds a variation of scanner range to the position. On that result a new range is added. Now its found it can be fixed.

I didn't expect that a function like:

Code: Select all

pos = [self fractionalPositionFrom:point0 to:point1 withFraction:routeFraction];

would also randomise the result with scanner range.

This double randomisation also means that it was possible that ships were added inside a planet/sun because the route was only shortened with 1x scanner length. So it was clearly not intended to happen this way.