Skip to content

GetRandomAvaliablePlayer

This method obtains a suitable player party member index using the regular targetting rules.

private int GetRandomAvaliablePlayer(bool nullable)

Parameters

  • nullable: If true, this will use an alternative targetting scheme that may return -1 meaning to not target anyone. There is an overload without this that behaves the same as if false was sent. NOTE: The true version has broken logic, see the section below for details.

Procedure

The logic depends on nullable's value

nullable is true

If forceattack isn't -1, it is returned.

Otherwise, there will be attempts to find a random player party member to target. Each attempt involves generating a random one using uniformly random probabilities between each of them. For the target to be accepted, its hp must be above 0. The amount of times this is attempted is the amount of player party members. If a target is accepted it is returned, otherwise, -1 is returned and the caller has to handle this logic since no one will be targetted.

Problems with nullable true logic

There are some issues with this logic compared to the nullable false version which are bad enough to be considered broken:

  • This scheme fails to account for the front player party member meaning it does not matter who is in the front
  • This scheme fails to account for the LeafCloak medal even when it is equipped meaning it does not matter if it is equipped on someone or not
  • This scheme may not return a valid target which may force the caller to abort the attack or to try again, but there is never a guarantee that an accepted target is returned
  • This scheme fails to account for the eatenby (Only would have mattered for a Pitcher enemy, but they do not use this targetting scheme under normal gameplay)

However, some enemies intentionally uses it in their action codes. The following enemies involves it at least once as part of their DoAction logic:

  • WildChomper (via SpitSeed)
  • ChomperBrute (via SpitSeed)
  • VenusBoss (called directly and via ShakeSeed)
  • TANGYBUG (via ShakeSeed)
  • SeedlingKing (via ShakeSeed)
  • BeeTurret
  • BeeBoss
  • FalseMonarch
  • MidgeBroodmother
  • UltimaxTank
  • MotherChomper

Despite the game using it under normal gameplay, it is highly recommended to never pass true to the nullable parameter. It fails to account for too much and it can lead to undesired logic where the caller might not be able to find a suitable target.

nullable is false

If forceattack isn't -1 and the player party member coresponding to it doens't have an eatenby, it is returned.

Otherwise, there is an infinite loop that starts:

  • A random partypointer element (a playerdata index) is generated by generating a number from -2 (inclusive) to the amount of player party members (exclusive) clamped from 0 to the amount of player party members (this essentially biases to target the first party member more)
  • If the player party member's hp is 0 or its eatenby exists, the target is rejected and the loop restarts
  • Otherwise, if the player party member has the LeafCloak medal equipped, the target is rejected, but this can only happen once: if another target passes the hp and eatenby checks, it is automatically accepted and returned
  • Otherwise, the target is accepted and returned

The overall targetting odds are as follows:

Amount of player party members Who has LeafCloak? Odds front Odds second Odds third
2 No one 3/4 1/4 N/A
2 Front 9/16 7/16 N/A
2 Second 15/16 1/16 N/A
3 No one 3/5 1/5 1/5
3 Front 9/25 8/25 8/25
3 Second 18/25 1/25 6/25
3 Third 18/25 6/25 1/25