Bug: Player can Lead a Group, but AIs Don't Like It

[Ngalo]

Found that it's possible to create a ShipGroup with player as leader, but JS AIs attached to the group then throw exceptions because the Oolite Priority AI Library is written to assume that group leaders have an AIScript, and the player is the only ship which never does (not even oolite-nullAI.js).
Surely either the player should be able to lead a group without problems, or it should be completely invalid to create a ShipGroup with a PlayerShip as leader?

[another_commander]

Setting the player as group leader seems to be a pointless thing to do, since there is no proper way to communicate with NPCs and do the leader thing as one should. So, setting the player as the leader of a ship group has been disabled in the JS interface. Attempting to do this will result in the emission of a warning. This will be already active in tomorrow's nightly.

If anyone has a really good reason to reinstate this functionality, better speak now, as release of 1.84 is now closing in. We can consider adding player group leadership capabilities in the future, which is something that would probably require a general revision in most JS AIs.

[Cody]

... release of 1.84 is now closing in.

Not quite yet, please - I'm relocating next week and will probably be without a computer and/or comms for a few days!

[Norby]

In coordinatesForEscortPosition the position of the leader could be useful. [wiki]Fighters[/wiki] use this way and also a player.ship.escortGroup.addShip(fighter) call. If it is disabled then these must handle in if(owner==player.ship), not a big problem but imho better if not disabled.

[another_commander]

My main worry is that, if it is not disabled, whenever an exception due to a missing player JS AI happens, the script that triggered it stops executing and this can be problematic. Can you try tonight's nightly and see how it works for you?

[Norby]

Figthers seems ok with 1.84, EscortDeck needed a fix what I uploaded now so it could be disabled.

I found many of these in my log:

Code: Select all

ball turret weapon range of 7500 for subenitity of ship griff_prototype_boa-NPC is too high, using 7200.0.
ball turret weapon range of 7500 for subenitity of ship aquatics_destroyer is too high, using 7200.0.
ball turret weapon range of 7500 for subenitity of ship aquatics_mantaRay-military is too high, using 7200.0.
ball turret weapon range of 7500 for subenitity of ship aquatics_piratePlatform is too high, using 7200.0.
ball turret weapon range of 7500 for subenitity of ship aquatics_kraken is too high, using 7200.0.

I do not know why 7200 is better as a limit. Can not be 7500 for compatibility?

[another_commander]

Following a discussion in the devs internal mailing list, we have reverted the disabling of the player as group leader. The correct fix for this problem is obviously to adjust the AIs in such a way so that a player can be handled as both group leader and/or group member. However, this is not something that we can do three days (or so) prior to release and disabling the player as leader would make an OXP solution impossible. Therefore, we will consider it a known issue for the time being and try to resolve this post-1.84, but in the meantime, anyone who feels like having a go at the JS AIs and making a fix-up OXP is more than welcome to do so.

@Norby, regarding the warnings with turrets, the value of 7500 was hard-coded in the past, but the 7200 is calculated based on the turret weapon characteristics. I don't think it's a big problem and, in my opinion, it is best not to fall back to hard-coded values again.

[Ngalo]

OK. I was trying to make a 'Tactical Comms' OXP using phkb's BroadcastCommsMFD as the UI and Ramirez' Resistance Commander OXP as a guide to the sort of functionality needed, and it seemed I could save a lot of work if I could use existing AI library functions like behaviourFollowGroupLeader and conditionLosingCombat with the player as group leader.

I wouldn't expect any action on this in 1.84 or 1.85, but if you want to make player-NPC collaboration easier in future versions it may be worth actually giving the player ship an AIScript (even if it does nothing, can't be switched and is only a 'dummy' script which doesn't receive event handlers and is no use for a priority AI controller). This way, other scripts could still write data to variables like oolite_intership for NPCs to read if appropriate, for instance to ensure your wingmen get a consistent assessment of your role.

Is this idea worth considering?

[Ngalo]

Have started trying to fix this by OXP. Initial problem solved, but a new one has come up (and been temporarily patched at least): my wingman seems to be at perpetual red alert, so the standard version of conditionInCombat always returns true.

No idea what's causing it.