UPDATED OXPS: Lave 1.70 & transports 2.45(new)

[Eric Walch]

oolite.version and related functions were introduced in 1.70, so there is no easy way to tell - from javascript - which pre-1.70 version of oolite you're running. As I was checking transports.oxp, I had 1.68 exit on syntax errors because I was declaring variables using 'let' (the officially sanctioned way to do so from oolite 1.70 onwards). Before 1.70, the only way to declare a javascript variable was to use the keyword 'var' instead.

Yes one of my JS scripts quitted on "let". I think pre 1.70 version check is useful right now, to still be able to run simple scripts on 1.69. but in the future those test will be impossible. By now I have translated my UPS slave missions and Solar missions into JS. For the solar missions I now have play-tested all missions, and the slave missions are in progress of testing and will be ready soon. Than I upload it so others can give their opinion on it. (In function it will be exact the same as the current release, but for scripters it could be useful to compare both versions). Future additions will only be in JS.

but pre-1.70 version testing will not be possible as both are not compiled because of syntax errors on 1.68 and 1.69. I think this will happen to all future JS scripts that are more complex. But for now I want to stay compatible with the stable 1.65 release. At the moment UPS next release works on 1.65 and 1.70 onwards. On 1.68 and 1.69 only 3 of the 5 mission series will be active so 75% of it stays playable on that versions.

[Ark]

Hi Kaks

I have noticed that a lot of times the woma full transports do not have escorts (Don’t worry this is old - checked it also with 2.1). Maybe is a coincidence, but if so is a very strange one. Why always the woma fuel transports and not the other transports of this oxp appear without escorts.

I think is worth investigating.

[Eric Walch]

I have noticed that a lot of times the woma full transports do not have escorts (Don’t worry this is old - checked it also with 2.1). Maybe is a coincidence, but if so is a very strange one. Why always the woma fuel transports and not the other transports of this oxp appear without escorts.

Difficult to investigate as Oolite 1.69 and 1.70 also have a bug with escorts loosing their mother sometimes after entering the system.

There are several ways to add escorts. When added the system also looks if it is a save system and sometimes decides to leave the escorts out. There is also an command to explicit add the escorts. But than one does not do the right checks and you sometimes end up with an double sets of escorts. (Of with only the maximum amount follow the mother and the others become hunters)

[Kaks]

Just double checked. Womas are created with between 1 and 4 escorts but, as Eric says, the escorts tend to wander off into the distance...

I'll find out exactly what Eric does to stop escorts pilots from reading poetry when their mothership is being attacked, but I'll be pinning all my hopes on 1.71 for the bugfix...

[LittleBear]

If you have a look at the randomhitsescortAI (cribbed from Eric's improved escort AI), you've got a basic AI that keeps the escorts with Mum. This one always attacks the player on sight though (as they only appear as henchmen to a random hits victim), but if you replaced this with some scanforThargoids / ScanforOffenders, states, they should guard Mum pretty well whilst staying with her. I think one of the problems with the standard escortAi is that it can get switched to planetpatrolAI. So the escorts often go "There's a criminal, lets go kill him", whilst Mum with her TraderAI keeps on heading for the Space Station. By the time they've killed the offender, Mum is out of scanner range and they can't find her.

[another_commander]

I'll find out exactly what Eric does to stop escorts pilots from reading poetry when their mothership is being attacked, but I'll be pinning all my hopes on 1.71 for the bugfix...

You can build right now from svn and test exhaustively if you want. There is a fix already there, and I would really like to know that it works as intended

[Kaks]

Will do!

[Kaks]

(partial) Success! In 1.70 I found out why the sidewinders were leaving the woma.
They were looking for a liner as their mother ship, and the woma hasn't got that role. I got the woma escorts to behave like escorts, apart from actually attacking anyone...

I compiled the latest svn, and I didn't seem to have much joy with my sidewinders, I tried the standard sidewinders with no luck. If they're set up as escorts, they simply don't want to fire at me, not even when I attack them directly.

It looked as if the escorts AI didn't want to change state. They seemed stuck at the FOLLOW_MOTHER ai state. That gave me an idea.... <various testing sounds - dark mutterings, mainly>

What I managed to find out eventually: when you spawn the escorts their AI doesn't use the ai defined within shipdata.plist, and whatever ai they use, it's pretty dumb - Wait, I can find out the name of the ai they use: they all use escortAI.plist.

Hold on.. yep! Tested a bit more, and escorts are stuck with auto_ai=yes, no matter what!!

The good news is, we've got a workaround with javascript. If you reset their ai to what it should be, after they're spawned, everything works.

In other words, when I changed my js code from:

Code: Select all

	system.legacy_addSystemShips('woma',3,1); //creates 2-4 sidewinder-woma escorts

to:

Code: Select all

	system.legacy_addSystemShips('woma',3,1);
	let s=system.shipsWithRole('sidewinder-woma');
	for (let i in s){
		s[i].switchAI('womaEscortAI.plist');
	}

Those babies finally started to show some sign of intelligence.

I haven't tried any other method, but no doubt some script.plist expert can figure out a way to do the same in legacy mode!


Crivens & fiddlesticks, that bug was stupidly hard to figure out!


I'll make sure everything works ok, then I'll update transports to a new, shiny, improved version, fully working under Oolite 1.70

@another_commander: I tried to track this bug down but I got lost in the middle of the code. I did manage to get the auto_ai stuck to off instead of on:
Inside [ShipEntity setUpEscorts], I added one line - from:

Code: Select all

		[UNIVERSE addEntity:escorter];
		[[escorter getAI] setStateMachine:@"escortAI.plist"];	// must happen after adding to the UNIVERSE!

to:

Code: Select all

		[UNIVERSE addEntity:escorter];
		if ([[escorter getAI] name] == @"nullAI.plist")
			[[escorter getAI] setStateMachine:@"escortAI.plist"];	// must happen after adding to the UNIVERSE!

After that, it wouldn't take any notice if I set up the auto_ai to true/yes/on.

Bah! So close, and yet so far. Hopefully you'll sort out the problems with my 'non-bugfix' in a vey short timel....


Cheers,

Kaks

[another_commander]

Do escorts work ok for you with non-script ships? If you encounter a normally populated convoy and fire at the mother does the rest of the group attack you? I hope it does

Edit: Also for the cases that the escorts did not work, try dumping the state of the mother ship for any scipt generated mother. Is the flag escortsAreSetUp set?

[Kaks]

This might be a really stupid question, but: is there a way to generate a 'normal convoy' or is it a matter of waiting long enough just outside the station?

Edit:
fwiw: in svn /trunk my scripted convoy has got the flag setup, but somehow escortAI doesn't seem to react when I attack the mother ship.

in 1.70 vanilla, the flag isn't set up

Edit2:

duh, the woma ai never asks the escorts to attack its aggressor, that would explain a few things!!

[another_commander]

I am not really sure. But the point is to not use any scripting commands to generate anything. So, what I was doing when testing was pick a dictatorship or confederacy system, jump in and start moving towards the planet, energy bombing / qmining anything that was coming my way until a convoy popped up. They are more frequent than one might think. If you want, you could modify the code temporarily to not remove the energy bomb after use, so you can blast anything you don't need right away. And with the testing I did, these normally populated escorts were responding immediately to attacks, both from myself and NPC ships. A verification of the correct behavior would be something I would like to have. If it works OK for normal ships, then obviously something is not getting set right when a script ship gets added to the universe.

Edit: Try this as well with the trunk version. In ShipEntity.m, method acceptAsEscort, line ca. 6741, comment out these two lines:

Code: Select all

if ([shipAI ai_stack_depth] > 2)
		return NO;

It might be that the AI of the scripted motherships is already at a stack depth higher than 2 when deciding whether to accept escorts or not, in which case we would bail out from acceptAsEscort, even if the escortsAreSetUp flag is set.

[Kaks]

ok, I'll try the nearest confederacy & will let you know. About the escorts being dumber than dumb, I think I just figured it out! (see Edit2 above)

Really, I should be looking more closely at these things!

[Kaks]

Results of testing with the latest - unmodified - trunk:

Met 2 pirate convoys, the flag was set for both mothership & escorts. Behaviour: as expected!

Also met 2 non pirate convoys, in both cases it looked as if the whole convoy was made up of escorts.... flags were set up for all. When I attacked one, they all ganged up on me. Excellent!

Seems like there's no problems with the standard roles now. All that's left is that auto_ai thing and the escorts won't be a problem anymore.

Result!

Edit: all the convoys were made of 3-4 ships each. I didn't change the stack check, the results seemed good enough already.

[Commander McLane]

@Kaks: Thanks for you investigative work, although many of it has been investigated before.

Yes, it is a long-known issue that all escorts get escortAI. And also the fix has been known for a long time. The trick is to switch their AI in the launch_actions. So you have to insert the following into their shipdata:

Code: Select all

		<key>launch_actions</key>
		<array>
			<string>switchAITo: [i]whateverItsNameIs[/i]AI.plist</string>
		</array>

Also the problem with this solution is known for a long time: If your escort happens to have turrets, these turrets will go missing in the process. The reason for this behaviour of launch_actions is not yet known, though. If you could find it out and fix it, I would be extremely grateful to you.

Or get your solution of making autoAI a default false for escorts (but for escorts only!) working. That would spare us the workarounds (and my Sentinel Asteroids would probably the daylight once...).

[Eric Walch]

I prepared yesterday a lengthy answer about escorts on Little Bears message an just for sending we had a power failure in the street. Me looking at a black screen in a black room and dark outside. AARGH!!*$%. No energy left to retype it. In the mean time there were a lot of posts in this topic.

But when interested, look in the wiki index and there you find a piece I wrote some months about escorts and to get them working. http://wiki.alioth.net/index.php/Escort_Instructions

The command I use is "setUpEscorts". But please do not use it for normal ships as the command is not mend to be used by scripts. (It has no fail save mechanism as official AI commands). Meaning every time you call it, a new set of escorts get added. Mom gets the maximum amount and the surplus wanders off. Also when the system had decided the ship should get escorts this command still adds another set.

But for target ships it is a good way to make sure there are always escorts. (To make it better script usable, the command needs an internal check for "escortsAreSetUp" and only set it up when false.)

There are more funny things you can do with escorts. Put in the death_actions the command "messageMother: MOM_I_DIED" and add a line "MOM_I_DIED" = ( your stuff) in the right state of mom's AI.

This might be a really stupid question, but: is there a way to generate a 'normal convoy' or is it a matter of waiting long enough just outside the station?

An easy way is to give some escorted traders an role trader(1000). That makes it likely only escorted traders get spawned near the withchpoint.