Just when I thought I was out...

[Roberto]

Cheers guys - yes, I've just discovered it works with the role (I thought I tried that combination earlier on today, but I guess not!). I've also discovered that ships are loath to attack cargo; I've altered the target's scanClass to CLASS_BUOY, and that seems to have done the trick. I'm assuming there aren't any hidden consequences to creating extra buoys - I've already added an extra one to the system, and that hasn't caused any problems I'm aware of.

*EDIT* You could have "jettison"... though I guess that won't describe what's happening in all cases.

[Commander McLane]

No worries I've been tweaking for hours and finally got things how I want them:

Code: Select all

{
	GLOBAL = { 
		ENTER = (); 
		"EXITED WITCHSPACE" = ("setStateTo: GO_TO_STATION");
		EXIT = (); 
		UPDATE = ("setStateTo: CHOOSE_DESTINATION"); 
	}; 
	"CHOOSE_DESTINATION" = {
		ENTER = ("rollD: 3"); 
	        "ROLL_1" = ("setStateTo: GO_TO_STATION");
		"ROLL_2" = ("setStateTo: STEERING"); 
		"ROLL_3" = ("setStateTo: STEERING"); 
		EXIT = (); 
		UPDATE = (); 
	}; 
	"STEERING" = {
		ENTER = ("rollD: 10"); 
	        "ROLL_1" = ("setCoordinates: pwm 142653.45 -27832.78 57463.84", setDestinationFromCoordinates, "setDesiredRangeTo: 100.0", "setSpeedFactorTo: 0.9", performFlyToRangeFromDestination);
	        "ROLL_2" = ("setCoordinates: pwm 143166.81 -29220.01 59293.16", setDestinationFromCoordinates, "setDesiredRangeTo: 100.0", "setSpeedFactorTo: 0.9", performFlyToRangeFromDestination);
	        "ROLL_3" = ("setCoordinates: pwm 143971.92 -27108.34 58484.39", setDestinationFromCoordinates, "setDesiredRangeTo: 100.0", "setSpeedFactorTo: 0.9", performFlyToRangeFromDestination);
	        "ROLL_4" = ("setCoordinates: pwm 143581.45 -27807.32 59565.06", setDestinationFromCoordinates, "setDesiredRangeTo: 100.0", "setSpeedFactorTo: 0.9", performFlyToRangeFromDestination);
	        "ROLL_5" = ("setCoordinates: pwm 142959.56 -28632.24 57902.22", setDestinationFromCoordinates, "setDesiredRangeTo: 100.0", "setSpeedFactorTo: 0.9", performFlyToRangeFromDestination);
	        "ROLL_6" = ("setCoordinates: pwm 143780.75 -27055.29 59093.81", setDestinationFromCoordinates, "setDesiredRangeTo: 100.0", "setSpeedFactorTo: 0.9", performFlyToRangeFromDestination);
	        "ROLL_7" = ("setCoordinates: pwm 144091.70 -27321.55 57644.63", setDestinationFromCoordinates, "setDesiredRangeTo: 100.0", "setSpeedFactorTo: 0.9", performFlyToRangeFromDestination);
	        "ROLL_8" = ("setCoordinates: pwm 142990.44 -28428.13 59655.61", setDestinationFromCoordinates, "setDesiredRangeTo: 100.0", "setSpeedFactorTo: 0.9", performFlyToRangeFromDestination);
	        "ROLL_9" = ("setCoordinates: pwm 142287.39 -25442.38 52039.16", setDestinationFromCoordinates, "setDesiredRangeTo: 100.0", "setSpeedFactorTo: 0.9", performFlyToRangeFromDestination);
	        "ROLL_10" = ("setCoordinates: pwm 143891.75 -24652.42 53534.86", setDestinationFromCoordinates, "setDesiredRangeTo: 100.0", "setSpeedFactorTo: 0.9", performFlyToRangeFromDestination);
		"DESIRED_RANGE_ACHIEVED" = ("setStateTo: PREP_FOR_DEPARTURE");
        	"ACCEPT_DISTRESS_CALL" = (setTargetToFoundTarget, "setAITo: taranisTrafficFightAI.plist"); 
       		"OFFENCE_COMMITTED" = (setTargetToFoundTarget, "setAITo: taranisTrafficFightAI.plist"); 
        	"INCOMING_MISSILE" = (fightOrFleeMissile, setTargetToPrimaryAggressor, broadcastDistressMessage, "setAITo: taranisTrafficFightAI.plist"); 
        	ATTACKED = (setTargetToPrimaryAggressor, broadcastDistressMessage, "setAITo: taranisTrafficFightAI.plist"); 
		EXIT = (); 
		UPDATE = (); 
		RESTARTED = ("setStateTo: PREP_FOR_DEPARTURE");
	}; 

The EXITED WITCHSPACE thing works as it should, and ships about to depart will turn to one of the ten sets of coordinates (all out of the "firing line" between the dock and the billboard) before heading out to jump range (which I've increased to 23.5km, as a couple of Morays, for some reason, were still getting stuck!). I removed some checkCourseToDestination/COURSE_OK/pauseAI stuff for the sake of smoothness; now ships slow to a near-stop, before turning again to head out. They always go in the direction of the sun - or rather, just to the side of it - which I guess is where Oolite likes its witchspace-entry coordinates to be!

Now to sort out the randomly appearing Frigate's "weapons testing" AI...

I am wondering if this is actually working as you want it. I myself have experimented with "setCoordinates: pwm x y z", setDestinationFromCoordinates, "setDesiredRangeTo: n", "setSpeedFactorTo: t", performFlyToRangeFromDestination, but in reality the ship did not move to the coordinates specified (in my case it was pwm 0 0 0, and the ship wasn't even roughly heading towards the planet). In fact, it only moved along the internal z-axis. Kaks thinks he may have fixed the underlying orientation problem and I've sent him a testcase right now.

But it would be interesting (and puzzling) to know that in your example the ships actually go to one of the coordinates specified. So, are you positive about it? Or is the last part of your post

They always go in the direction of the sun - or rather, just to the side of it - which I guess is where Oolite likes its witchspace-entry coordinates to be!

an indication that something very similar to my problem is also wrong in your case?

[Roberto]

It's definitely working - I've seen several ships emerge from the station, head immediately for one of the ten points specified, slow down and then head off again to the witchspace coordinates (roughly in the direction of the sun).

*EDIT* It seems the witchspace coordinates aren't always over on that side - I've just seen a Moray charge off to some very distant point in the other direction (having been given a "head start" by the turn coordinates it chose)! Morays, eh?

Sometimes I've found that if I put stuff in ENTER it doesn't always happen - could that be the issue?

[Commander McLane]

Hmmm. I think I had put it in ENTER. Yes, indeed, I had. So putting it in UPDATE would have saved me a lot of trouble? But then I don't want it to be repeated on every UPDATE.

Anyway, for now I'm first waiting what Kaks tells me.

And there is another facing problem that has to be sorted out anyway.

[Eric Walch]

Hmmm. I think I had put it in ENTER. Yes, indeed, I had. So putting it in UPDATE would have saved me a lot of trouble? But then I don't want it to be repeated on every UPDATE.

The ships in Dictators.oxp use the next state to go to thje special station:

Code: Select all

 "HEAD_FOR_FACTORY" = {
		ENTER = ("setCoordinates: wpu 0 0 0.3", setDestinationFromCoordinates, "setDesiredRangeTo: 2500.0", "setSpeedFactorTo: 0.6", checkCourseToDestination);
		"COURSE_OK" = ("setSpeedFactorTo: 0.7", performFlyToRangeFromDestination);
		"WAYPOINT_SET" = ("setAITo: gotoWaypointAI.plist");
		"DESIRED_RANGE_ACHIEVED" = (dockEscorts, "setAITo: dockingAI.plist");
		UPDATE = ("pauseAI: 10.0");
		EXIT = ();
	};

I haven't followed one but had always the impression they also found their station.

[Commander McLane]

I had used the COURSE_OK message, but it also didn't work.

Anyway, I definitively have to return to this one. If there are more ideas how to solve it, please keem them coming.

[Roberto]

Today's question: landing on planets!

From the Wiki I gather that setCourseToPlanet tends to cause crashes (it certainly crashed my test ship), but ships with the role "shuttle" will disappear rather than crash. Therefore I'm thinking I should give all of my ships that might go to the planet a secondary "shuttle" role, but with a very low probability (say, 0.000001). Does anyone have any better solutions to landing? If not, I'll go with that.

[LittleBear]

I think with any ship if you tell it to landOnPlanet in AI when it gets to its desired range from the planet that will work without necessarily giving it the role shuttle.

[Roberto]

Hmm - well, it goes to the planet, but even with the secondary role "shuttle(0.000001)", my test ship is crashing into it rather than disappearing...

[Eric Walch]

I think with any ship if you tell it to landOnPlanet in AI when it gets to its desired range from the planet that will work without necessarily giving it the role shuttle.

That command works, but the trick is to know when to apply it. Giles introduced (1.65?) the AI message:

"APPROACHING_SURFACE" = (landOnPlanet);

But is had a bug that the message came at about 1m before collision. To late, but I think it will be fixed in 1.71

Use setCourseToPlanet. this command will by itself set a appropriate range. Than:

"DESIRED_RANGE_ACHIEVED" = (landOnPlanet);

will do the trick. (look into the fallingShuttleAI). Or look inside the extra OXP that I included with the last few versions of UPS. There I put a variation of this fallingShuttleAI that makes a turn, just before landing. Optical that looks more like a landing.

Just crashing into the surface only works with primary role "shuttle" as you by now discovered yourself.

[Roberto]

I didn't realise that the order in which you list a ship's roles makes a difference! But clearly it does: ships vanish as opposed to blowing up as long as the "shuttle" role is listed first. What a mysterious beast Oolite is!

@Eric
Had a look at that AI - think I'll leave mine as is, though, as ships seem to be coming in at a reasonable angle anyway (after a pointless 15km-odd retreat in some cases!), and I'd rather they went in smoothly than stopped to face upwards (unless your ships are turning at speed somehow?).

[JensAyton]

I didn't realise that the order in which you list a ship's roles makes a difference! But clearly it does: ships vanish as opposed to blowing up as long as the "shuttle" role is listed first. What a mysterious beast Oolite is! :)

Mysterious… yes. Or possibly buggy. In 1.70 and later, it should check the primary role, but some such checks were order-dependent in earlier versions.

[Roberto]

These AIs are getting pretty complicated! I realised that ships that hyperspaced out within the fighting AI would be stuck constantly hyperspacing, so I've added an "EXITED WITCHSPACE" option within that to trigger standard docking. And if they get attacked *again*, they go to a duplicated set of "attack" states that'll revert them to docking (rather than booting them out of the AI) when they're done!

Theoretically you could have a dogfight stretching all the way across a galactic map! But I'd better test it...

[Roberto]

@Ahruman
When you say the primary role, what does that actually mean? Here I'm dealing with ships that are generated by the role taranis_testship, but in shipdata have:

Code: Select all

		<key>roles</key>
		<string>shuttle(0.000001) taranis_testship</string>

*EDIT* This would be useful to know for scanForNearestShipWithPrimaryRole, which I've been using (unthinkingly)!

[JensAyton]

According to the JavaScript documentation (obviously this should be explained on the shipdata.plist page too):

The main role of the ship; the role for which it was created. For instance, if a ship’s shipdata.plist entry specifies the roles “pirate trader(0.5) escort”, and a ship of that type is spawned to be a trader, its primaryRole is "trader", its roles is ["escort", "pirate", "trader"] and its roleProbabilities is { "escort":1, "pirate":1, "trader":0.5}.

This only applies in 1.70 and later. In earlier versions, the “primary role” would be the only role tracked by an individual ship (except when it wasn’t), and some checks, such as the shuttle thing, were done by looking a the entire roles string from shipdata.plist (using slightly different methods in each case). The role set + primary role mechanism was introduced in 1.70 to unify this, and provide a standard way to handle “metadata” roles like tharglet (which is never used as a primary role, but causes special handling for any ship that has it in the role set). Shuttle should possibly be handled by checking the role set, but it seems weird to me that a ship with roles = "trader shuttle", if summoned as a trader, should be immune to crashing into planets.

Anyway, APPROACHING_SURFACE will work in 1.71.