escorting problems again

[Commander McLane]

I think handling escorts is an issue that has popped up here frequently. Now I have my share with it and am asking for help.

Here's my problem: In Anarchies.oxp there are "Hacker Outposts", gangs of hackers living on modified asteroids (and Killer Wolf made an awesome model for that!). Now the idea is that the outposts should be located in an asteroid field (easy to do), but some of the surrounding asteroids are modified as well. They are "Sentinel Asteroids", asteroids with two ballturrets mounted on them which will be a nasty surprise for anybody who should attack the outpost.

To make them by putting two ballturrets (borrowed from gwxstations.oxp) on an ordinary asteroid (borrowed from the game) was easy. But to make them work gives me a headache!

I'll explain:

- If I set the sentinel asteroids up as escorts they appear without fault, but in this typical escort-like wing-formation behind the outpost, which means most of them are way too far away from the outpost to be of any use as a defense (the ballturrets only fire when their target is in a range of approx. 5000 m).

- Also everything set up as escort by default automaticly gets escortAI (that's an issue already discussed on the boards, IIRC). And worse: they immediatly set their AI to route1patrolAI and enter the FLY_TO_WITCHPOINT-state, which means they don't recognize the outpost as their mother.

- However they of course don't get very far, as their maximum_speed is 0. And they somehow seem to remember that they were escorts (and I have no idea whatsoever why they remember that, because there is no exitAI-method used in route1patrolAI), because when I attack the Outpost or one of them, they all set to interceptAI and start to attack me. That at least is some good news.

- But that works only if they are set up as escorts, which is the bad news.

- If I add or spawn them in any other way I can't get them to behave like escorts. I gave them an AI that first lets them offer their services to the outpost. But their suggestEscort-calls to the outpost (the technical stuff: scanForNearestShipWithRole: hacker_outpost, TARGET_FOUND = suggestEscort, ESCORTING = performEscort) remain unanswered (they continually send out the suggestEscort-message, but never get the ESCORTING-message), so they never actually start escorting. That means they don't respond at all to anything that happens to the outpost.

- I even made them start escorting without an offer before (scanForNearestShipWithRole: hacker_outpost, setTargetToFoundTarget, performEscort). No effect, they don't do.

- I thought, perhaps it may not be possible to escort a station, so I modified the outpost, giving it the role "carrier" instead of "station". No effect.

- I also tried to have the escort asteroids respond by other ways, like ACCEPT_DISTRESS_CALL or OFFENCE_COMMITTED. Nothing so far, they remain passive and peaceful.

- To make things worse, they don't even recognize themselves as a group. So if I attack any of them directly, that one sets its state to ATTACK_SHIP and fires at me. But all the others (and of course the outpost) stay completely unimpressed.

So for now I don't really know what to do and where to go. Specific questions I have are:

- Are there perhaps some more methods for mother-escort-communication that are not documented in the wiki? Something like callForEscort or requestEscort on the mother's side? Or at least an agreeToSuggestEscort? Because it seems there is only suggestEscort on the escort's side, and we can't script anything in the mother's AI to make her react to that suggestion.

- Can I do anything to make a couple of entities that have been spawned with "addShipsWithinRadius: sentinel_asteroid 8 wpm X Y Z 4000" into a group? Something like "scanForShipWithRole: sentinel_asteroid, TARGET_FOUND = setUpGroup"? So that they would respond to groupAttackTarget? For now they behave like single entities without any group-feeling.

Any help or hints will be very much appreciated!!!

[Charlie]

This issue is a pain isn't it?

This may ( or may not ) be a helpful suggestion but I don't seem to have had as much trouble with this as many...

Possibly just blind luck on my part ( or maybe my chronic lack of play-testing means I haven't noticed )

Because I'm a control freak I've tended to do my own custom AI's in .oxp's with escorts, carriers etc that only ever reference routines within that .oxp

It may also be blind luck has lead me to do .oxp's a bit different from the majority causing me not to run into this issue.

Orb.oxp relies very heavily on the escorting system & so far I've not noted any issues. ( To a lesser extent the same seems true of my other .oxp's using this feature )

In short - I've no idea how to help, but luck may have buried the answer inside my later .oxp's if you want to try the tedious job of comparing my code with yours ( and others )

Kind Regards

[Commander McLane]

Just having a look into Orb.oxp.

And I am wondering how it actually works. Haven't tested it yet though.

One example: The OrbBase has escort-ship OrbFleet. But there is no ship with the entity-key OrbFleet. That's a role, so there shouldn't be OrbFleets as escorts at all. The same goes for the Trb and Arb and their escort-ship OrbEscort, which again is no entity-name but a role.

...

Okay, I have put the Orb.oxp (downloaded half an hour ago) in my addons-folder. Fired up Oolite and the first thing I get is this:

ERROR ***** could not parse /Applications/Spiele/Oolite/AddOns/Orb.oxp/Config/script.plist as a NSDictionary.

So how has anybody seen any Orb yet? Or did everybody correct the script.plist first? Have a look into it.

...

Analysis: There are a couple of }, and ); missing, but where? I guess the whole thing is meant as four independent conditions, because a STATUS_LAUNCHING inside a STATUS_EXITING_WITCHSPACE inside a STATUS_LAUNCHING inside a STATUS_EXITING_WITCHSPACE obviously makes no sense at all (but that's the current syntax in the script). So I'm going to add on pair of closing brackets after each of the conditions. (And I'm starting to get an idea on why:

Oolite REALLY does not like what I've done here...

.)

...

Anyway, as I already have started Oolite I launch my ship, pause the game and press "0" for an entity dump. Interestingly enough despite of the script.plist not being valid there are some Orb-ships around. Three Orb and one Crb, to be precise, in whatever way they may have been called.

Ah, the entity-list gives some information about that:

2007-03-21 12:42:24.322 Oolite[1441] -> Ent:67 <ShipEntity Crb 195> mass 1315.45 <AI with stateMachine: 'route2sunskimAI.plist' in state: 'HEAD_FOR_SUN'>

As the Crb has sunskim-trader among its roles it may just have been called by the engine as one of the sunskimming ships. Also its AI points into that direction.

But the entity-list reveals yet some more facts:

2007-03-21 12:42:24.322 Oolite[1441] -> Ent:63 <ShipEntity Orb 197> mass 899.02 <AI with stateMachine: 'escortAI.plist' in state: 'FLYING_ESCORT'>
2007-03-21 12:42:24.322 Oolite[1441] -> Ent:64 <ShipEntity Orb 196> mass 899.02 <AI with stateMachine: 'escortAI.plist' in state: 'FLYING_ESCORT'>
2007-03-21 12:42:24.322 Oolite[1441] -> Ent:65 <ShipEntity Orb 198> mass 899.02 <AI with stateMachine: 'escortAI.plist' in state: 'FLYING_ESCORT'>

So the Orb may well be escorts of the Crb (although I don't know how they are spawned, as there is no setUpEscorts or deployEscorts in route2sunskimAI). But (as in my problem as well) they have just the default escortAI, not their custom OAI!

So much for now. I'll have a deeper look later and will continue to report my findings.

------

And still: How do I get my Sentinel Asteroids to work?

[JensAyton]

I installed the OXP, saw the error message, looked at the plist and went “help! help!”. Sorry.

Oh, the shipdata.plist is also broken. Line 1241 (<string>3.0 0.0 -2.2</string>) should be after line 1238 (<key>weapon_position_aft</key>).

Edit: I’ve prepared a cleaned-up version of script.plist.

[Commander McLane]

Thanks, Ahruman, in the meantime I have fixed the script.plist myself. However I hadn't yet spotted the error in the shipdata. Just was wondering why when first running Orb.oxp I got a funny error about laser_color as well.

But my main question on the programmers level is: If both script and shipdata are broken, how does it come that there are people (well, at least Charlie himself, but also others) who have successfully run the OXP? Is Windows more forgiving towards broken plists than Mac OS? On my Mac, if a plist, especially script.plist, is not valid, the oxp doesn't run. Period.

@ Charlie again: I have followed the Crb and its escorting Orbs. The Orbs have escortAI, that's all. When the Crb started sunskimming the escorts broke loose, switched to dockingAI (state ABORT) and headed for the planet. As in state ABORT a ship doesn't react to an attack I could take out two of them easily. I followed the remaining one to the station, where it attempted to dock (state GO_TO_COORDS), but then aborted that again. I guess it would have done that infinitely, so I killed it as well.

The bad news for you in all that: As you say the Orbs are heavily relying on escorting. But that doesn't work, because all the escorts get escortAI instead of the custom AIs you intended for them.

On the other hand there is some hope for me, although I don't yet understand why it works with the Orb: I had the strong feeling that my Hacker Outpost and its Sentinel Asteroids cannot communicate because they all are (obviously) CLASS_ROCK. Now that can't be an obstacle, because also all your Orb-ships are CLASS_ROCK, and the Orbs unless my asteroids did remain in escortAI after being set up. What I have to figure out yet is how they actually were set up in the first place, because--as I have said above--route2sunskimAI doesn't do that.

BTW: The information on the broken plists should perhaps be posted in the Orb-thread as well?

[JensAyton]

When a plist is broken, Oolite falls back on a hacked-together custom parser for XML plists (which I’ve started referring to as the “homebrew parser”). This is more lenient, primarily in that it accepts plists with messed-up dictionaries, but it doesn’t attempt to mend them.

Future versions will be more explicit about this, and the homebrew parser will spit out warnings about bad dictionaries (as well as printing errors from the standard Foundation parser). Even futurer versions will do away with the homebrew parser entirely.

There are differences in what the GNUstep and OS X Foundation parsers will accept. I’m not sure exactly what the differences are, though.

[Charlie]

I installed the OXP, saw the error message, looked at the plist and went “help! help!”. Sorry.

Oh, the shipdata.plist is also broken. Line 1241 (<string>3.0 0.0 -2.2</string>) should be after line 1238 (<key>weapon_position_aft</key>).

Edit: I’ve prepared a cleaned-up version of script.plist.

Ah - yet another bug! Something else to sort for the next release... Thanks for digging.
Yes the script.plist is broken ( forgot to take it out of the release version ) there won't be a script.plist in the next one.
Quick question: “help! help!”? - Hard to follow or just that bad?
Apologies: I've been labouring under the assumption that if a .oxp works as intended it must be ok or would not run @ all! Didn't realise there are 'degrees of brokenness'. I've been in the habbit of leaving broken bits in place if they don't affect function as a 'reminder to self' to do something with them - maybe I should stop doing this?


@Commander McLane: -Orb.oxp not working as I intended eh? Bugger. Sorry if you've wasted a bunch of time with no help @ the end of it.

For your interest - as you asked...
How does the role thing work in this .oxp? Hmmm, no doubt I'll discover I'm wrong again but as it seems to work maybe not.
Each ship is given one of three-ish roles:
It's name ( same as entitiy key )
It's role within the orb-fleet ie. OrbEscort, OrbFleet, etc - with a probability value.
A role taken from a standard OOlite object.
So
When Oolite spawns an object such as an alloy it may spawn an Orb object instead. ( v.v. low probability )
With this 'hook' I then start a probability-based cascade spawning objects/ships I want to appear in that circumstance.
If it has escorts it's AI ( at least that's what I intended! ) does a 'setupescorts' for it's entry in the shipdata.plist
But I want varying ship types doing the escort thing! Sooo I use the role rather than the entity-key.
=>eg OrbEscort role is called instead of an entity-key - Oolite picks anything with that role based on the probability defined for that role for each ship.
This way I get variation in 'who escorts what' more-or-less for free.

Your comments do point to my having the same touble as yourself - it's just I didn't notice...
I'll have to do some digging now - esp as in-game things for the most part seem to be working as intended:
Preferentially chasing Thargoids.
Swarming behavior. ( to an extent - still working on it )
Completely 'flipping-out' & attacking anything in sight if they've been given a hard time.
among others...
( worth mentioning I'm running my 'current beta', not the released verion - not sure how much of the above applies... )

My apologies that instead of helping I've only succeeded in hijacking your thread.

Kind Regards.

PS
It's just occured to me: The Orb ships you found will have the default AI's because Oolite called them via its own system-populating routines. ( you found them - they didn't appear as a result of a 'large energy release' )
I scatterd a few standard Oolite roles among the ships at lowish priority so they would crop up a little even if you didn't blow anything up! Because of this you may even find to odd 'dead' Orb ship laying about ( lights off ) because Oolite has picked one as a 'rock' + associated lack of AI.

Maybe there is some help here after-all.

[JensAyton]

I found a problem in, I believe, OrbWaypointAI.plist earlier. Lots of missing quotation marks.

The “help! help!” was a combination of weird indentation and a lot of blank space on the second-last line (which wrapped in my editor). Not a big issue, just enough that I couldn’t be bothered to deal with it at the time.

Maybe there should be a command-line option to Oolite to try to load all the plists in an OXP for verification, now that it provides semi-useful diagnostics for bad plists.

[Commander McLane]

@ Ahruman: Well, on my machine a broken script.plist will lead to it not being executed at all. I usually test new ships etc. by a very short script.plist, that spawns them close to the station on STATUS_LAUNCHING, so that I don't have to fly around much or jump first. And it's very easy: If there is a quotationmark, a comma or a bracket missing (to name just the most common typos), the entity just isn't there. That (together with the "cannot parse..." in the console) is the most secure hint to a broken script.plist. I think Oolite is more forgiving to typos in the shipdata.plist, but I can't say to what extent.

@ Charlie: some more points:

As Ahruman already said, also OrbWaypointAI is broken. Haven't looked into it by now.

When Oolite spawns an object such as an alloy it may spawn an Orb object instead. ( v.v. low probability )
With this 'hook' I then start a probability-based cascade spawning objects/ships I want to appear in that circumstance.
If it has escorts it's AI ( at least that's what I intended! ) does a 'setupescorts' for it's entry in the shipdata.plist
But I want varying ship types doing the escort thing! Sooo I use the role rather than the entity-key.
=>eg OrbEscort role is called instead of an entity-key - Oolite picks anything with that role based on the probability defined for that role for each ship.
This way I get variation in 'who escorts what' more-or-less for free.

Roles: Some of the Orb-ships indeed have common roles (hunter, miner, etc.), but mostly without any probability. That means that your ships have the same chance to be e.g. spawned by a rock hermit as a miner than any of the default ships. So there is no "low probability". Is that really what you intend?

Escorts: I guess what you explain here is what you intended to do, but it is not what you did.

Sooo I use the role rather than the entity-key.

No, you don't, you use the entity-key. Throughout your shipdata.plist you don't call escorts with their roles, but with their entity-keys. The method you use is this:

Code: Select all

<key>escort-ship</key>
<string>OrbFleet</string>

You are just using the wrong method here. <key>escort-ship</key> calls for an entity-key, not a role. And there is no entity-key OrbFleet. If you want to call escorts with the role OrbFleet you have to use another method, the method escort-role.

Code: Select all

<key>escort-role</key>
<string>OrbFleet</string>

Then this will work as you intended. So just find and replace every "escort-ship" with "escort-role", and you will be fine.

[Charlie]

@Ahruman, Commander McLane:

Thanks for the comments:

A few in return just to clarify:
OrbWaypointAI is broken: oh-well more fiddling, didn't obviously affect anything so I didn't notice. ( again )

<key>escort-role</key>, <key>escort-ship</key>: Hmmm, as you say wrong <key> used where I've wanted to call a roll rather than ship ( not all the ships are called by roll, the smaller ships do call their escorts by specific ship ) I'll change the relevant ones - thanks again...
I wonder if these keys are interchangeable within Oolite ( even if not intended ) as it seems to work anyway!

Standard roles included within this .oxp - apologies, we're looking @ different code! Me: what I'm working on, You: what I've released ( I think true of OrbWaypointAI.plist too )
( this behavior is just for variety - you come across the occ dead Orb or one intergrated into GapCop society. Most Orb appear via a different method )

Back on topic:
FWIW
My belief about the escort-problem is that in general when Oolite's standard calls are used it assigns default AI for that role, but if you abstract the process from Oolite's control you get your own AI...
Evidence?
As you've noticed Orb ships/escorts called as a result of: miner sunskim-trader etc appear with the standard AI, but Orb called as intended do use their own AI ( broken or not! )
Why do I think this? Because they all speak a torrent of Orb-gibberish in-game. ( when called via the 'orb-method' ) With the exception of some death-actions Orb-comms are generated by the custom AI. ie standard AI = no Orb-speak... ( or worse still English! )
( Orb-speak will be toned-down a lot in the next release )

Assuming I've not missed the point my hope is this may be the answer to your difficulties...
What I'm uncertain about is how this 'abstraction' seems to work in this .oxp, given this behavior is unintended good-fortune...
Is it because all my 'normal' ships are spawned via the death-actions of the whitehole, warphole objects which in themselves are rare substitutions for some types of debris?
or
Is it because the 'normal' Orb ships have their own custom roles. ie If my role is Trb or OrbFleet, Oolite assigns my own AI. If my role is one of the standard ones ( pirate, miner, escort etc ) Oolite may well assign a standard AI in keeping with that role...

Hopefully the second is true as it's fairly easy to set up custom roles ( and not use any of Oolite's ) if you want to be sure of using your own AI.
If the first, that's a pain as ensuring the use of a custom AI will mean spawning an object for the sole purpose of blowing it up so you can get the ships+behavior you want via its death-actions.

[JensAyton]

@ Ahruman: Well, on my machine a broken script.plist will lead to it not being executed at all. I usually test new ships etc. by a very short script.plist, that spawns them close to the station on STATUS_LAUNCHING, so that I don't have to fly around much or jump first. And it's very easy: If there is a quotationmark, a comma or a bracket missing (to name just the most common typos), the entity just isn't there. That (together with the "cannot parse..." in the console) is the most secure hint to a broken script.plist. I think Oolite is more forgiving to typos in the shipdata.plist, but I can't say to what extent.

The laxer “homebrew” parser only handles XML property lists, so if there are brackets and commas missing it doesn’t apply. There is no difference in strictness between script and shipdata, other than that shipdata is usually XML and script is usually OpenStep format.

[Charlie]

@Ahruman:
You mentioned in a previous comment something about a future update having a command-line switch for a 'debugging-mode'.

This would be great!

I'm by nature quite lazy & this would help reduce my 'near enough is good enough mistakes'.
Also
Apart from trying to do something new / interesting a large part of writing this .oxp is a learning process - many mistakes to be made. Anything to help weed these out is good.

@Commander McLane:
I hope somewhere in all this you've found an answer to your question - sorry this thread has ended up more about my errors than helping you.

Regards to both.

[Commander McLane]

Unfortunately I am still working on the escorting problem. No solution yet.

The bad news for you, however, is, that, as far as I have understood your work in Orb.oxp, it will not do at all what you are intending it to do. And that it actually does something is only partly due to your programming.

As soon as you take out the script.plist, which is the only part where Orb ships are spawned as Orb ships with Orb AIs, there won't be any ships at all with Orb AIs. None of the ships spawned as a result of the game engine populating the Ooniverse with traders, miners, hunters, splinters and so on will have a custom Orb AI, nor will their escorts have. If you don't believe me, test it yourself: Fire Oolite up, launch, jump to another system, pause the game and make an entity dump by pressing 0 (zero). Your logfile will show a complete list of all entities present in the Ooniverse at that time, together with the information which AI they are currently using and which state within that AI they are currently in. The overwhelming majority of Orb ships will have escort AI in the state of LOOK_FOR_BUSINESS. If you continue the game for another minute or so and make another entity dump, they will have changed their AI to route1patrolAI, because they haven't found any mother to offer their escort service to. Without the script.plist there won't be a single Orb ship with a custom Orb AI. It just doesn't happen, and I'm sorry to say that.

[Charlie]

Hmmm, I'm happy to be proved wrong but I wonder if we're typing @ crossed purposes...

Without the script.plist there shouldn't be any Orb hanging arround @ all!
( or at least not many - some will crop up sans correct AI as you noticed - can't avoid this though I'd like to. There will be less of this in the next release when I strip out most of the trader, sunskim-trader, hunter, etc role entries. )

Why bother put so much work into a .oxp that doesn't spawn any ships??

Orb only appear when someting BIG goes bang... ( They need the energy to enter this universe. )
Specifically, something goes bang, debris produced: splinters, alloys etc. Some of this debris is ( rarely ) spawned as a WhiteHole or WarpHole... ( The bigger the explosion, the more debris, the greater chance of Orb turning up )
These have a very low energy so more often than not the explosion will cause these to blow up too...
When one of these blows up: Then and only then are Orb ships spawned + their various escorts. This is how this .oxp is supposed to work. The likelihood of Orb turning up is very, very small unless something BIG goes bang.
Some Orb do have the wrong AI, ( generally those spawned directly by Oolite ) but playtesting this .oxp shows that it does work as advertised:
Why?
1) Orb-speak - The ships clog up the comms with their gibberish which is only produced by the custom AI ( apart from the odd death-action )
2) Their behavior in-game is pretty much as I wrote the AI to function.

Thanks for your help, ( certianly Orb.oxp is still a long way from prefect ) I'm sorry I've not been much help to you in return...

If you want to see an example of this .oxp in action: go find something BIG like a Thargoid carrier & blow it up. ->WhiteHoles + WarpHoles spawned followed by a bunch of Orb ships doing what they are suppoed to ( for the most part ) - Honest!