spawnShip: broken in 1.70?

Commander McLane · Post by **Commander McLane** » Thu Feb 07, 2008 11:33 am

It seems that the spawnShip: method is (partially) broken in 1.70, in a way I don't understand.

I am using it in Anarchies.oxp to spawn the Hacker Outpost. Just as I am (finally) preparing the release of the OXP (actually I wanted to upload it today) and making some final testing I can't get the Outpost to spawn.

I do meet the Henchman, who in his AI has the scriptActionOnTarget: spawnShip: anarchies-hacker-outpostn (n ranging from 1..4). He does send me a commsMessage and performs the AI-method.

It gets even stranger: The Hacker Outpost is surrounded by an Asteroid Field, which is created in the setup_actions of the Outpost. The Asteroid Field is created, it is there. Which means that the shipdata of the Hacker Outpost is read by the engine and at least the setup_actions are executed. But the Hacker Outpost itself does not appear, it is not in the entity dump.

I thought of a falsely named dat- or png-file, because I recently renamed them all to make them unique. But they are all in order. And if I spawn the Hacker Outpost with addShipsAt:, it does appear.

*****

Second thought: On release of 1.70 Ahruman asked for feedback on whether launch_actions, setup_actions, script_actions and death_actions work correctly. So could it alternatively be that the thing broken is not the spawnShip:, but the setup_actions? So the very setup_actions that do spawn the asteroids, prevent the Hacker Outpost from being spawned?

Commander McLane · Post by **Commander McLane** » Thu Feb 07, 2008 12:12 pm

Turns out it is a mixture of two problems:

1) Other members have elsewhere reported a problem, that (I don't recall exactly) some actions work on a first ship that is spawned with a certain role, but do not seem to work on a second or third ship, spawned later. If I recall correctly, the underlying issue has to do with the cache. As far as my Hacker Outpost is concerned: It is spawned (once) after the cache has been flushed. If I quit the game, restart again using the existing cache and try to spawn it again, it does not appear. If I quit again and then restart with holding SHIFT, the next time it does appear. This happens regardless of the method used, with spawnShip: the same as addShipsAt:.

2) There is, however, a second problem, which I realize only now that I could successfully spawn the ship: It doesn't appear at the coordinates specified in its spawn-directory, but exactly on the witchpoint (the witchpoint buoy is actually visible within the Hacker Outpost). This means that not only the JavaScript-equivalent legacy_spawn doesn't work properly in 1.70 (as reported elsewhere), but the legacy method spawnShip: doesn't work properly as well and seems to have just the same bug.

Post by **Eric Walch** » Thu Feb 07, 2008 5:55 pm

Commander McLane wrote:
2) There is, however, a second problem, which I realize only now that I could successfully spawn the ship: It doesn't appear at the coordinates specified in its spawn-directory, but exactly on the witchpoint (the witchpoint buoy is actually visible within the Hacker Outpost). This means that not only the JavaScript-equivalent legacy_spawn doesn't work properly in 1.70 (as reported elsewhere), but the legacy method spawnShip: doesn't work properly as well and seems to have just the same bug.

Bets test is to load a OXP with a known workin spawnShip: the ringpod.oxp at Lave.

Just installed it and launched a commander Jameson. The rings are there in 1.65 till 1.69 but not with 1.70.

Ark · Post by **Ark** » Thu Feb 07, 2008 6:31 pm

Is it possible this to be connected with the bug i have reported in ringpod oxp? https://bb.oolite.space/viewtopic.php?t=4124

Commander McLane · Post by **Commander McLane** » Fri Feb 08, 2008 7:13 am

Eric Walch wrote:
Best test is to load a OXP with a known workin spawnShip: the ringpod.oxp at Lave.

Just installed it and launched a commander Jameson. The rings are there in 1.65 till 1.69 but not with 1.70.

So it is broken in 1.70. Thanks for the quick test!

*sigh* So I will for the time being and for the sake of being able to release it replace the spawnShip: methods in Anarchies with addShipsAt: methods.

This means my Hacker Outposts won't get the correct orientation. But on the other hand, they didn't get it with spawnShip: as well (because I think the orientation key is somehow broken, as mentioned elsewhere).

Post by **Kaks** » Sun Feb 10, 2008 1:24 am

I'll have a look, I've had some luck with the source code so far, I might be able to figure what's happening here...

I'll let you know what I find!

Post by **Kaks** » Thu Feb 14, 2008 12:39 am

Success!!!

Yep, found out what the problem was, and the solution is already on svn. Ringpod.oxp now works flawlessly with trunk.

The problem would stop the orientation key from working properly, and the spawn position would not be where intended.

If you can compile from trunk, give it a go!

Commander McLane · Post by **Commander McLane** » Thu Feb 14, 2008 10:39 am

Thanks! That was quick work.

And BTW: Congratulations to your promotion to "Commodore"!

I'll have to wait for 1.71, though, as I cannot build.

Another question: Does it fix another problem with orientation as well? I want to have a ship fly towards the planet with setCoordinates: pwm 0 0 0, setDestinationFromCoordinates and performFlyToRangeFromDestination, but the ship in question does not fly to the planet, but parallel to the internal z-axis instead. I can't use setCourseToPlanet, because there is another scripted planet closer to the ship than the original planet.

JensAyton · Post by **JensAyton** » Thu Feb 14, 2008 12:17 pm

Commander McLane wrote:
I'll have to wait for 1.71, though, as I cannot build.

I’m sure you could if you tried. It’s not really very hard, at least under OS X. :-)

Post by **Eric Walch** » Thu Feb 14, 2008 5:01 pm

Commander McLane wrote:
Another question: Does it fix another problem with orientation as well? I want to have a ship fly towards the planet with setCoordinates: pwm 0 0 0, setDestinationFromCoordinates and performFlyToRangeFromDestination, but the ship in question does not fly to the planet, but parallel to the internal z-axis instead. I can't use setCourseToPlanet, because there is another scripted planet closer to the ship than the original planet.

I have never seen a problem with this. Dictators.OXP is using this coordinate settings to fly his ships to the station. And they always go right on target. But maybe it needs a distance as now it could use any random distance. (actually last used value )

LittleBear · Post by **LittleBear** » Thu Feb 14, 2008 5:44 pm

Could use:-

setTargetToSystemStation, "setDesiredRangeTo: 5000.0", setDestinationToTarget, performFlyToRangeFromDestination

To make sure he goes to the main station rather than a nearby OXP planet. Admitadly thats not quite to the main planet but close enough! Or set the range further away and then have him set to the Planet (which will now be the Main Planet as the nearest one) when desired range is reached.

Commander McLane · Post by **Commander McLane** » Wed Feb 20, 2008 6:24 am

Using the station (or rather the station buoy) is the workaround I am currently using. Only problem: what happens when the buoy is accidentally blown up?

And I want him to go straight to the planet from a big distance. When the player arrives at the ship he shall be able to see that it's headed for the planet. I'll try again, but I'm sure it doesn't work as I want it to.

Post by **Eric Walch** » Wed Feb 20, 2008 8:29 am

Commander McLane wrote:
Using the station (or rather the station buoy) is the workaround I am currently using. Only problem: what happens when the buoy is accidentally blown up?

And I want him to go straight to the planet from a big distance. When the player arrives at the ship he shall be able to see that it's headed for the planet. I'll try again, but I'm sure it doesn't work as I want it to.

I think going to the main station is in this case just enough. It will even better than going to the main planet from a far distance. The command setCourseToPlanet is not directing you to the centre of the planet otherwise all ships would collide with each other at that point. It calculates a point away from this centre. And the farther the ship is from the planet, the larger is the spread of co-ordinates the command setCourseToPlanet returns.

And when you want to land on the planet, you could use the aegis check. When the ship passes a border of 3 planetary diameters it sends an eagis message to the ship AI: AEGIS_CLOSE_TO_PLANET The station will always be within this eagis.

This is normally used to switch course to the station, but you could use it otherwise.

Commander McLane · Post by **Commander McLane** » Wed Feb 20, 2008 11:00 am

Eric Walch wrote:
I think going to the main station is in this case just enough. It will even better than going to the main planet from a far distance. The command setCourseToPlanet is not directing you to the centre of the planet otherwise all ships would collide with each other at that point. It calculates a point away from this centre. And the farther the ship is from the planet, the larger is the spread of co-ordinates the command setCourseToPlanet returns.

So could be that it is working after all, but gets a coordinate so far away that it is effectively going in a right angle to the planet? In my case the ship is spawned roughly 5,000,000 meters from the planet.

Post by **Eric Walch** » Wed Feb 20, 2008 6:14 pm

So could be that it is working after all, but gets a coordinate so far away that it is effectively going in a right angle to the planet? In my case the ship is spawned roughly 5,000,000 meters from the plane

t.

The centre (0,0,0) is not the planet but the station I think. The co-ordinate it gets is always within the aegis of 3 x planes radius.