Stealth dice cannot perform trip attacks.

[danlangford]

input

game 3
fight
player 0 5 2.5
tdY!-1:1
tdY!-1:1
tdY!-1:1
tdY!-1:1
tdY!-1:1
player 1 5 15
2:2
7/13-7:7
7/13-7:7
7/13-7:1
7/13-7:1
ply 2
max_sims 100
min_sims 5
maxbranch 400
surrender off
getaction
quit

output

l1 p0 best move (5.0 points, 100.0% win) attack trip - (888)1:1 -> (0)2:2  TURBO 6
stats 2/5-100/400/0.50 Time: 2.000000 s Sim: 15780  Sims/Sec: 7890.000000  Mvs/Sms | 143.0/5.0 | 1.2/50.0 = 42914
action
trip
0
0
swing Y 6

website error

Stealth dice cannot perform trip attacks.

website description for Stealth skill

Stealth: d | These dice cannot perform any type of attack other than Multi-die Skill Attacks, meaning two or more dice participating in a Skill Attack. In addition, Stealth Dice cannot be captured by any attack other than a Multi-die Skill Attack.

[pappde]

Looking at BMC_Die::RecomputeAttacks():

    // TRIP
    if (HasProperty(BME_PROPERTY_TRIP))
        m_attacks.Set(BME_ATTACK_TRIP);

...

    // stealth dice
    if (HasProperty(BME_PROPERTY_STEALTH))
    {
        m_attacks.Clear(BME_ATTACK_POWER);
        m_vulnerabilities.Clear();
        m_vulnerabilities.Set(BME_ATTACK_SKILL);
    }

Since the die is flagged as "td" it is both Trip and Stealth. Is the "Stealth" rule for "cannot perform anything other than Skill" is a higher priority rule than the other properties on the die? Or is it a special rule just for "Trip Stealth"?

In BMAI, the same pattern affects other button properties that "enable" an attack, such as Speed Stealth, Shadow Stealth, and Berserk Stealth.

Three possibilities A) website bug B) BMAI bug specific to Trip C) BMAI bug for all cases

In case (C) the BMAI code would be updated something like this:

    // stealth dice
    if (HasProperty(BME_PROPERTY_STEALTH))
    {
        m_attacks.Clear();
                m_attacks.Set(BME_ATTACK_SKILL); 
...

In case (B), we would instead specifically exclude attacks that Stealth supersedes (though this seems vague). E.g.

  m_attacks.Clear(BME_ATTACK_TRIP)

[jl8e]

It's a deliberate choice by the site. Stealth's attack prohibition was decided to be controlling. (I don't agree, but I didn't win the argument.) Since it was the other way on the old site, it's not technically a BMAI bug..

Stealth should override all special attack types, I'm pretty sure.

[danlangford]

Wow, this is interesting. On one hand it does sound like it is an implementation detail, and other sites have done it different ways. On the other hand there are no other sites currently. This is an interaction that BMAI needs to be familiar with. I’m now starting to think about a config option to specify a rule set. Then any implementation specific things can at least be more clearly isolated and understood for what they are.

On Thu, Jul 13, 2023 at 7:07 AM Julian @.***> wrote:

It's a deliberate choice by the site. Stealth's attack prohibition was decided to be controlling. (I don't agree, but I didn't win the argument.) Since it was the other way on the old site, it's not technically a BMAI bug..

Stealth should override all special attack types, I'm pretty sure.

— Reply to this email directly, view it on GitHub https://github.com/pappde/bmai/issues/46#issuecomment-1634213699, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFQDVGSV5XHCXWQO7EAGZDXP7XI3ANCNFSM6AAAAAA2G4YVFU . You are receiving this because you authored the thread.Message ID: @.***>

[pappde]

It does seem there needs to be a config option either to designate a rules set, or at least for this specific rule. In this case, it sounds like the behavior toggle would indeed be m_attacks.Clear() [All] so that nothing supersedes Stealth. Of course, that means that some combinations of dice would make the die useless.

In the meantime, the quickest solution would be a compile-time config (e.g. #ifdef STEALTH_PRIORITY). Not sure if this is a blocking issue.

PS: A fancy solution might be to associate a "priority" to each rule so we know which overrides which, but not needed right now.