Corp AI uses Send a Message to rez Ping

[bobtheuberfish]

          Scenario: I, Runner, stole a _Send a Message_ from HQ. AI Corp, at 3c, decides between 3 unrezzed ICE to rez. AI decides to rez a _Ping_ on remote server 2 (_Snare!_ in the root of the server).

Why I think this is not the right tactic: Ping's main value comes from its "On rez" effect. Also, Corp had enough credits to pay for Ping. One of the other ICE on R&D or HQ should have been rezzed for free instead.

Suggestion: For Send a Message, AI should not consider Ping as an ICE to rez for free if it can pay for it normally.

chiriboga-log-2023-04-04T08_26_01.899Z.txt

Originally posted by @alexzhaohong in https://github.com/bobtheuberfish/chiriboga/issues/44#issuecomment-1495566264

[bobtheuberfish]

The AI's current reasoning for not using Send a Message (line 5004 of systemgateway.js) is: RezCost(params.card) < 0.3 * (Credits(corp) + 1) && !params.card.knownToRunner

That is, Send a Message will not be used to rez a piece of ice if it costs less than about a third of the Corp's credit pool, unless the Runner already knows what it is (in which case there is no value leaving it unrezzed).

I can see what you're saying about Ping. Perhaps we need to put an extra parameter on Ping (like AIRezWhenNotApproaching) which would have logic in it that the Send a Message implementation could call. If not defined for a card, it would act the same as if the function returned true. The function for Ping would need to check whether it is protecting the attacked server, in which case it might still be worth rezzing for the tag punishment.

[alexzhaohong]

Great solution, thanks! You decided to go with a method called AIRezForFree

I had to wrap my head around some boolean logic in this line, but once I got it, it matched up to your words you said on April 5th! Thanks

if (!card.AIRezForFree.call(card)) return false;