Scripting requests

[Svengali]

An AI method to attach a script to a ship.

For what do you need an AI method? And it is likely to break existing oxps by applying other scripts without checking things properly before - and this can't be done via AI.

[Kaks]

If you want to replace a ship's script on the fly it's probably better to use the shipSpawned world script event, you can also replace AIs in there too!

[Commander McLane]

As per the other thread I wasn't aware of shipSpawned as a world script event. Indeed, it's everything needed to attach whatever script to whatever ship. So consider the request moot.

[Commander McLane]

Would it be useful to have a general way for AIs to communicate with each other? Example: we have broadcastDistressMessage, which triggers ACCEPT_DISTRESS_MESSAGE in the AIs of certain ships in the vicinity.

Could we get a more general version of that? An AI method which triggers a certain message in the AI of another ship. The most general way would be something like "sendAIMessage: MESSAGE", which would send the message MESSAGE to the AIs of all ships within desired range. MESSAGE would be a freely choosable parameter, so you could send the standard AI messages, but custom messages as well. There could be the variant "sendTargetAIMessage: MESSAGE", which would do the same, but only to the active target.

This would certainly improve the scriptability of NPC-NPC interaction.

And I know that this is already doable via ship script. But it still wouldn't hurt to have it on the pure AI level as well.

[Eric Walch]

Would it be useful to have a general way for AIs to communicate with each other? Example: we have broadcastDistressMessage, which triggers ACCEPT_DISTRESS_MESSAGE in the AIs of certain ships in the vicinity.

Could we get a more general version of that? An AI method which triggers a certain message in the AI of another ship. The most general way would be something like "sendAIMessage: MESSAGE", which would send the message MESSAGE to the AIs of all ships within desired range. MESSAGE would be a freely choosable parameter, so you could send the standard AI messages, but custom messages as well. There could be the variant "sendTargetAIMessage: MESSAGE", which would do the same, but only to the active target.

The "sendAIMessage: MESSAGE" already exist in the code itself. It sends an AI message to 16 nearby ships. It is just not exposed to the JS scripting system. But I think it would be bad to expose it to the scripting system because it allows to write code that breaks everything. e.g. when it broadcasts a "LOST_TARGET" message during combat.

What also was already in the code since 1.65 was that normal "commsMessages" are send to 16 nearby ships. Only the counterpart: "receiveMessage" never did anything. Since a week that function now sends a commsMessageReceived to those 16 ships.

When you want that message going to one ship so others can't listen in, you can use the AI command "sendTargetComssMessage". And the JS commsMessage() now also accepts a target.

Yes, nowadays we are even faster than the requests.

[Commander McLane]

Good to know about the existing-but-not-working receiveMessage. Also good to know about commsMessageReceived. For NPC-to-NPC interaction it isn't really necessary, though. The sending ship can also simply target the desired entity and use this.ship.target.reactToAImessage or this.ship.target.AIState= in its script. So no need to analyse the commsMessage in the receiving ship's AI.

However, the scope of my request was to have a pure AI solution, without using additional JS-scripting.

Of course the whole thing could be misused in combat, but the already existing JS-solution can be misused as well, so that's not a real objection.

Anyway, I am just a humble scripting method requester, and have to leave the refusal or granting of the request to the powers-that-be.

[Kaks]

Well, using commsMessageReceived means that the broadcasting ship doesn't have to 'manually' send js instructions to all the ships in range...

The way we have it in trunk now, we need to either:

1) Select the ship we want to influence.
2) Specifically enable ships to be influenced - and only by specific messages.

I do agree with Eric that having a generic sendAIMessage: can lead to a lot of unintended consequences, i.e. ships that were never meant to receive the AI message could easily receive it by mistake, just because they're in range...

To make sure you've not disrupted other ships AIs, maybe ones created by other oxps for a specific misson, you'd have to go through all the ships in range one by one, and exclude ships that shouldn't get the AI message, something that's quite impossible to do via AI scripting.

Edit: in other words, that 'pure AI solution' would very likely require lots of js to make it actually work as intended. Lots of lots...

Personally, I'm happy to offload most of the thinking to js instead of the often trickier to program AI state machine (& I know I'm not alone in finding the AI a bit more complex to follow...), but I'm not that keen on making the js part 2 or 3 times more complicated that it needs to be.


In short, and to misquote the Admiral:

'No'. (at least IMO! )

[Switeck]

Would it be useful to have a general way for AIs to communicate with each other? Example: we have broadcastDistressMessage, which triggers ACCEPT_DISTRESS_MESSAGE in the AIs of certain ships in the vicinity.

Much to my surprise, broadcastDistressMessage only goes to Stations, Police or Bounty Hunters. (...and Bounty Hunters may have to be added by the populator instead of an OXP!)

Traders using route1patrolAI.plist would not react at all even if ACCEPT_DISTRESS_MESSAGE logic is added to their AI.

Was that done to minimize the cpu load?
It seems strange to me that ALL traders would totally ignore other traders getting attacked/killed right near them.

[Commander McLane]

Would it be useful to have a general way for AIs to communicate with each other? Example: we have broadcastDistressMessage, which triggers ACCEPT_DISTRESS_MESSAGE in the AIs of certain ships in the vicinity.

Much to my surprise, broadcastDistressMessage only goes to Stations, Police or Bounty Hunters. (...and Bounty Hunters may have to be added by the populator instead of an OXP!)

Why surprised? This behaviour is clearly documented, and nobody ever claimed it to be otherwise. It's the very definition of the method to only trigger responses in law-enforcement AIs.

Was that done to minimize the cpu load?

No, it was done because the very raison d'ètre of the method is to enable the actions of law enforcement ships. Therefore it is doing exactly what it is supposed to do. Thus nobody is going to change it.

Fellow traders are no law enforcement. It's as simple as that. If you want traders to react to attacks on other traders—which is a non-standard behaviour—you have to script it, which is perfectly possible. What you can't do is using a scripting mechanism which was specifically designed to do something else, and works exactly to its specifications.

[Switeck]

Why surprised? This behaviour is clearly documented, and nobody ever claimed it to be otherwise. It's the very definition of the method to only trigger responses in law-enforcement AIs.

It seems strange to me that ALL traders would totally ignore other traders getting attacked/killed right near them.

[Commander McLane]

Why surprised? This behaviour is clearly documented, and nobody ever claimed it to be otherwise. It's the very definition of the method to only trigger responses in law-enforcement AIs.

It seems strange to me that ALL traders would totally ignore other traders getting attacked/killed right near them.

Again, why?

Traders are not fighting heroes. Their priority is to get their cargo safely to their destination. Therefore running away from laser fire is the best strategy for survival.

If they were in the business for the thrill of the fight, they would have become bounty hunters in the first place.

If you want to change that behaviour for some traders, you are free to do it via JS-scripting. Personally I wouldn't find this a sensible change, though.

[Switeck]

Nevermind.

I just had a huge misunderstanding about intent and value of the "ACCEPT_DISTRESS_CALL" function.

Seems "scanForHostiles" needs to have its wiki entry updated and/or have its behavior changed to handle the bonehead behavior I mistakenly thought was related to this...which would then totally alleviate the need for other traders to "say" anything to each other.

[CheeseRedux]

It seems strange to me that ALL traders would totally ignore other traders getting attacked/killed right near them.

Again, why?

Traders are not fighting heroes. Their priority is to get their cargo safely to their destination. Therefore running away from laser fire is the best strategy for survival.

And sometimes the best strategy for survival is to help the other fellow instead of waiting for the pirates to finish him off, scoop his cargo, and look for their next victim.
There are documented cases where a flock of sheep have killed a wolf (or other predators).

Putting aside the "That poor fellow is getting killed, I've got to help"-factor, there are times when even the most self-preserving trader would look at the situation, weigh the odds, decide that the current victim isn't going to keep the pirates occupied long enough to stage a getaway, and act accordingly.

Should the game emulate those situations? In my opinion, yes.
Is it important enough to start fiddling with? That one I'll leave to those actually doing the work...

[Commander McLane]

Nevermind.

I just had a huge misunderstanding about intent and value of the "ACCEPT_DISTRESS_CALL" function.

Nevermind.

That's why I was trying to explain its intent in my words.

Seems "scanForHostiles" needs to have its wiki entry updated and/or have its behavior changed to handle the bonehead behavior I mistakenly thought was related to this...which would then totally alleviate the need for other traders to "say" anything to each other.

There you've lost me. What has scanForHostiles to do with either the ACCEPT_DISTRESS_CALL-message or the communication between NPC-traders? I don't understand the entire paragraph.

[Cmdr James]

The problem is that calculating the odds is quite difficult. Oolite does try to calculate the odds under some circumstances using

Code: Select all

checkGroupOddsVersusTarget

but I dont know how good it is.