Oolite Bulletins

I was testing this: What happened when I shot the rock hermit, it would launch 2 defense ships...then at low energy it would launch 2 scavengers. I was expecting it to launch 4 scavengers. Apparently the 2 defense ships counted towards the max scavengers limit.
On the other hand, with the original rock hermit...a miner could already be launched; yet there can still be launched 2 defense ships. Despite this, the miner counts as a scavenger.

Ok, Switeck_mod_v0.3b.zip is out!
I've fixed the bugs with stop-on-a-dime NPC ships.
Stations AI (rockhermit and regular stations) should now react better.
http://www.mediafire.com/?u4op4ftpdyh3uvy


Getting other traders to help out in a fight is very hard from the OXP programmer's point of view.

scanForHostiles only targets NPC pirate ships already targeting them -- which they won't be if they're fighting you or other ships!
scanForOffenders only works well in corporate states, elsewhere it ignores offenders or even fugitives!
scanForThargoid works just fine...but only targets/attacks Thargoids.
scanForNearestMerchantman works for pirates to find non-hostile trade ships (and the player), but won't get traders to help other traders in any way.

Is there ANY way to reliably get traders (or NPC bounty hunters for that matter!) to attack pirates, even if the pirates are attacking other NPC ships?

Switeck wrote:

On the rock hermit, the default values are:
"max_defense_ships" = 2;
"max_scavengers" = 1;
...Yet they seem to subtract from each other in confusing ways.

Things could be confusing because internally there is only one counter for both miners and scavengers, and one other for both defence_ships and police ships. I think the logic is explained on the wiki page with the js station properties for those numbers.

The second one is:
Is there ANY way to reliably get traders (or NPC bounty hunters for that matter!) to attack pirates, even if the pirates are attacking other NPC ships?

Traders would fall out of character when they would do. When they are not threatened themselves, they just keep going to the station to deliver their freight safely. The only other AI only way is to add them as a group. That way they can send each other group attack messages and an AI can be written to respond to group members.

Eric Walch wrote:

Things could be confusing because internally there is only one counter for both miners and scavengers, and one other for both defence_ships and police ships.

From here: http://wiki.alioth.net/index.php/Station_Ships
The logic doesn't explain what I've seen. If too many Scavengers launch, defense ships won't launch. Likewise, if too many defense ships launch, sometimes scavengers won't launch.

Traders would fall out of character when they would do. When they are not threatened themselves, they just keep going to the station to deliver their freight safely. The only other AI only way is to add them as a group. That way they can send each other group attack messages and an AI can be written to respond to group members.

When a trader in a ship nicer than mine dies in a particularly stupid manner, I consider that out of character...and I see it a lot.
Usually, it's caused by them traveling directly into a pirate swarm which is currently killing other traders. By the time they broadcast a distress call, it's too late for them. Even if it's them alone versus 2 pirates, they'll broadcast a distress call...and continue towards the pirates.
Giving the traders some situational awareness as they head towards the planet...would at least give them the option of fight or flee, (using fightOrFleeHostiles?) with many choosing to flee.

I'm not "dead" and I haven't given up on this...merely delayed by v1.75.x changes and testing that to see what parts of my mod are redundant, depreciated, or irrelevant. Quite a few AI changes were made by Oolite's v1.75.x update, so likewise I have to review all the AI.plist changes to correct any inherited mistakes my versions had as well as pick-and-choose any new additions that might be helpful.

I noticed route1traderAI.plist still uses setTargetToStation for its "GO_TO_SUB_STATION" section. It seems to me that setTargetToNearestStation might be a better choice, so I'm using that in my version.

To achieve better game balance for ships...
I've reduced the price of the Boa 1 to 300k (from 450k) to make it more competitive with the Pythons and Boa 2s prices. You're still paying a big cost premium going from a Python (200k) to a Boa 1 (300k), so it's not a game breaker though it may mean anyone who already owns a Boa 1 will see it devalued a lot. This also means cheaper maintenance costs. 3rd party (Griff) Boa versions may not be affected by this, depending on how they set their prices. The Boa was supposedly created based on "lessons learned" from the Python, so it stands to reason that costs were kept reasonable and so was reliability.
The Fer de Lance also sees a big change -- instead of a likewise large price decrease, I gave it Military Shields and External Heat Shielding as "standard equipment" when you buy it. I don't know if the Extra Energy Unit would conflict with an optional Naval Energy Unit, so I didn't add either one of those.
I'm on the fence as to whether the Asp deserves a "free" Shield Booster. Unlike the Fer de Lance, the Asp is faster than most other ships and considerably cheaper than the Fer de Lance. (375k vs 485k)

Is there ANY way to reliably get traders (or NPC bounty hunters for that matter!) to attack pirates, even if the pirates are attacking other NPC ships?

Eric Walch wrote:

The only other AI only way is to add them as a group. That way they can send each other group attack messages and an AI can be written to respond to group members.

As for my attempts to get a small number of traders to actually attack pirates before the pirates attack them, I've got something partially working in tests but is a bloody mess hack-job that doesn't work as well as I'd like. Ah well, I guess that's the price you pay when doing the "impossible". With luck, I might even get it to work with police and bounty hunter ships.

Large-scale testing of these is hard, since once a furball starts it's hard to quickly tell which ships are even pirates. The traders do seem to be assisting each other, though I'm sure that's just happenstance.

Switeck wrote:

I noticed route1traderAI.plist still uses setTargetToStation for its "GO_TO_SUB_STATION" section. It seems to me that setTargetToNearestStation might be a better choice, so I'm using that in my version.

Be aware that this part of the AI code will be rarely used. I added it in the case someone added a second planet with a station and spawned traders in the vicinity of that planet. Traders always go to the nearest planet, but in the original trader AI they would go for the main station after arriving at that alternative planet. Till now I am not aware of an oxp that adds a station near other planets and uses plain traders to go there.

setTargetToNearestStation is a beter name for that command, although both do the same.

Switeck wrote:

I noticed route1traderAI.plist still uses setTargetToStation for its "GO_TO_SUB_STATION" section. It seems to me that setTargetToNearestStation might be a better choice, so I'm using that in my version.

It doesn’t make a difference; setTargetToStation is an alias for setTargetToNearestStation (see the bottom of whitelist.plist). That said, setTargetToNearestStation is preferred because it’s clearer.

I was worried that "setTargetToStation" would become depreciated going from v1.75 to v1.80
...and it was because that code isn't normally used that I figured it might not be checked/reviewed.

No old scripting/AI from a previous stable (or beta) version will be removed or deprecated in any 1.x version unless there’s a very strong reason (the only very strong reason so far has been for scriptActionOnTarget:). Aliases, where methods have just been renamed, will definitely not be removed.

Ok, good to know no OXPs designed for v1.75.x are likely to become depreciated for v1.x of the game due to removed methods/scripting/AI going forwards.

While testing various trader types, I'm also testing what they can end up fighting: pirates and Thargoids.

And what a mess my Thargoid/Thargon AI.plist files are at the moment!
Thargoids and Thargons often end up shooting each other because they bunch up in a long tailchase. The Thargoids in particular are huge targets, so friendly fire is much more likely with them than with pirates. So I'm trying to come up with code to reduce that in their "ATTACK_SHIP" section:(I removed other lines for simplicity and clarity.)

But that doesn't seem to work because:
"TARGET_THARGOID" = (performIdle, scanForNonThargoid); // STOP friendly Thargoids fire!
...doesn't work/exist.

I can do this:
"TARGET_FUGITIVE" = (performIdle, scanForNonThargoid); // STOP friendly Thargoids fire!
since all Thargoids and Thargons have at least a 50 credit bounty (minimum for fugitive rating)...but that unfortunately also means they quit attacking fugitive pirates!

Another method I can use, which is even more indirect...is see if there's even any non-Thargoids in range:
"NOTHING_FOUND" = (performIdle, "setStateTo: LOOK_FOR_TARGETS"); // no non-Thargoids around, quit attacking!
UPDATE = (scanForNonThargoid, "pauseAI: 10.0"); // 30 seconds is too long!
However that only helps if nothing else is around or is cloaked.

Thargons don't have a "ATTACKED" line anywhere, but they may still be fired as a missile at another Thargoid or Thargon and will persist in trying to kill those until they lose contact with their mother or the target gets out of range or the target dies.

Argh!...now my test Thargons are exploding and killing all the Thargoids whenever there's nothing else near them! Here's the Thargon's AI.plist:It almost seems like:
1.the LOOK_FOR_TARGETS section does a scanForNonThargoid, and returns "NOTHING_FOUND" and them jumps to the CHECK_FOR_CONTROL section.
2.CHECK_FOR_CONTROL section inherits this "NOTHING_FOUND" and does becomeEnergyBlast. (Maybe even before bothering to check "scanForNearestShipHavingRole: thargoid"?)

In this situation, it is statistically impossible for the Thargons to pick 16 random ships near themselves and *NOT* pick at least 1 Thargoid Warship. There's only the Thargons, Thargoids, and my cloaked ship within scanner range. And there is fewer than 10 Thargons. I tried thargonCheckMother and scanForThargoid instead of "scanForNearestShipHavingRole: thargoid" and got the same result. Super-unstable Thargons that explode almost at random.

It looks like that is what I'd have to do to reduce Thargoid friendly fire appreciably.
Even the original thargoidAI.plist in v1.75.2 trunk seems very vulnerable to it.

I really wanted Thargons to loosely follow Thargoids around if there's nothing in range for them to kill. I was kind of hoping for "bugs flying randomly around a light" effect.
I even tried separating the actual "follow Thargoid" part into its own section in the hopes I could insulate it from bleeding an incorrect and unwanted "NOTHING_FOUND" to the "scanForNearestShipHavingRole: thargoid" results in "CHECK_FOR_CONTROL". Of course that didn't work either. Not only did the Thargons refuse to follow the Thargoids around, they hardly moved at all! Just brief 1-3 second moves followed by 10-60 seconds of sit-and-spin. Then if/when there were no non-Thargoids nearby even for a moment, the Thargons would randomly explode.

I'm not convinced even pairing up the AI with a JS script would work for random + loose trailing of a friendly unit. Asides from standard escort behavior, (which is totally inappropriate for Thargons) I'm beginning to think that the only way you can get 1 ship to follow another is if it's trying to KILL the lead ship. Regularly (about every 5-15 seconds) telling the chase ship to move towards the lead ship doesn't seem to work.

The AI state engine has considerable limitations on what actions can be done at the same time. As I've mentioned previously on this thread, it's possible for police ships and bounty hunters to patrol and look for pirates/offenders/thargoids...but to also have them search for escape pods (and other cargo pods for the bounty hunters) to recover pretty much causes a fail because the scanForLoot section disrupts the patrol destinations. Even a scanForLoot and scanForHostiles can't be in the same section without making a mess because of the conflicts over the "TARGET_FOUND"/"NOTHING_FOUND" results.
And if the NPC ship is in lots of special sections for more than a second, then each one of those probably also needs "ATTACKED" and "INCOMING_MISSILE".

My dabbling with "hitchhikerAI.plist" traders that reuse other ship's wormholes is something else I may have to drop due to complexity/conflicts. I only want them to use another ship's wormhole a fraction of the time. They often fail to reach a wormhole before it collapses...strange things happens if they get there just moments too late -- they just disappear!

I read on another thread that there could be a problem with escorts arriving before their mothership after piggy-backing on your wormhole. The escorts can't find the mothership, (which probably arrives a second later) and they quit escorting and wander off. What a pain! Would adding a delay if exiting a wormhole before checking for the mothership help?

Switeck wrote:

It looks like that is what I'd have to do to reduce Thargoid friendly fire appreciably.
Even the original thargoidAI.plist in v1.75.2 trunk seems very vulnerable to it.

I can confirm that there are friendly fire incidents with Thargoids leading to epic battles, which unfortunately look totally silly.

I think the problem is that in the core code, at the end of the -setTargetToPrimaryAggressor, the aggressor is added inside -addTarget: without any kind of check as to whether it is actually a friendly ship or not. I am thinking of adding this code inside - (void) addTarget:(Entity *) targetEntity in ShipEntity.m: which will allow the addTarget method to return without doing anything in the case of friendly ships accidentally hitting us. I run a couple of tests in witchspace, generating something like 30 thargoids and decloaking in the middle of the bunch (and then running like mad). The Thargoids seemed to not be going into civil war after that.

Edit: Actually, I think it's probably best to put the friendly check inside -setTargetToPrimargyAggressor. addTarget is used in the code also for things other than combat targets.

another_commander wrote:

Edit: Actually, I think it's probably best to put the friendly check inside -setTargetToPrimargyAggressor. addTarget is used in the code also for things other than combat targets.

That would probably be the best 1st step, but I am worried friendly fire+target fixation might indirectly also occur as the result of a groupattack message...though no doubt such conditions would have to be very convoluted. Either escorts hit the unit and they or it passes along a groupattack message before they give up...or some such nonsense. Always seems like there's something that slips through when the "easy route" to programming is taken.

Thanks Thargoid, I've already taken a brief look at your To Catch A Thargoid (TCAT) OXP. I'm at a bit of a loss how much of the scripting is needed for the friendly fire check, but will look at it again as well as the AI in Hired Guns and guardian drones in Aquatics. I'm still quite the newbie when it comes to scripting. I'm currently intentionally avoiding using scripts in my mod, because I just want to see how MUCH can be accomplished without it. Yes, I know that seems strange...but I'm also not as "comfortable" or skilled with scripts as I am with the AI state engine. My Misjump Inducer OXP has only a very simple script and even it caused me all kinds of headaches trying to get it right. I'm still not sure how badly it will mess up other OXPs. With Switeck mod OXP, script conflicts are probably far more likely due to how far-reaching its current changes already are.

another_commander wrote:

Edit: Actually, I think it's probably best to put the friendly check inside -setTargetToPrimargyAggressor. addTarget is used in the code also for things other than combat targets.

I also think that adding it in setTargetToPrimargyAggressor is the best location. This command already has a random component in it when used from within a combat situation, that makes that it is not always setting a target and current AI code should already be prepared for that. And it still leaves the option to deliberately start a thargoid-thargoid war by using other commands for targeting. (setTargetToFoundTarget or by using JS for setting a target)

I am not sure if we need the police check, as this is already dealt at other places in the code. But, doing it all in one place is probably clearer for the future.