Skip to content

Attacks per Round (Round Base file association) Info Dump

kjeronkjeron Member Posts: 2,367
edited November 2019 in General Modding
RNDBASE1.BMP - RNDBASE2.BMP - RNDBASE3.BMP - RNDBASE4.BMP - RNDBASE5.BMP
    These are the default files controlling when each attack (real, fake, or cosmetic) occurs each round, based on the creature's APR value prior to being modified by Haste and/or Slow effects.
    • APR values 1 and 1/2 use RNDBASE1.BMP.
    • APR values 2 and 3/2 use RNDBASE2.BMP.
    • APR values 3 and 5/2 use RNDBASE3.BMP.
    • APR values 4 and 7/2 use RNDBASE4.BMP.
    • APR values 5 and 9/2 use RNDBASE5.BMP.
    These files can be overriden, based on the creature's animation, by specifying a custom file through it's *.INI file, as some monster animations already do:
    [general]
    combat_round_0=RNDBASE1
    combat_round_1=RNDBASE2
    combat_round_2=RNDBASE3
    combat_round_3=RNDBASE4
    combat_round_4=RNDBASE5
    
    Each of these files is an 11x101 bitmap image.
    • Each row corresponds to the characters effective weapon speed [ 0 (top) - 10 (bottom) ] for that round.
    • Each column represents 1 tick (1/15 second) of time, excluding the final column, which isn't used, totaling 100 ticks (a combat round).
    • Red pixels mark the attack roll, and therefor when the attack actually counts.
    • Green, Yellow, Blue, Magenta, and Cyan pixels mark the beginning of the attack, and will generate 1 attack roll for each Red pixel following them until the next Green/Yellow/Blue/Magenta/Cyan/Teal pixel occurs.
      • Green pixels mark Attack #1.
      • Yellow pixels mark Attack #2. They serve no function in RNDBASE1.BMP.
      • Blue pixels mark Attack #3. They serve no function in RNDBASE1.BMP or RNDBASE2.BMP.
      • Magenta pixels mark Attack #4. They only function in RNDBASE4.BMP and RNDBASE5.BMP.
      • Cyan pixels mark Attack #5. They only function in RNDBASE5.BMP.
      • 1/2 attacks will always use the color with the highest attack # for each file, regardless of what order they may appear in the file.
    • Teal pixels mark the beginning of a cosmetic attack, these are ignored if cosmetic attacks are disabled.
    • Black and Grey are visual aids showing the length of the attack animation. (further effects unknown)
    Offhand attacks depend on whether the character makes a 1/2 attack.
    • Using RNDBASE1.BMP with: Offhand attacks don't occur.
    • Using RNDBASE2.BMP with:
      • (3/2 APR), Offhand attacks are governed by Green pixels, the 1/2 attack will use the Yellow pixels.
      • (2 APR), All attacks after the first Yellow pixel are offhand attacks, even if other colors proceed them.
    • Using RNDBASE3.BMP with:
      • (5/2 APR), Offhand attacks are governed by Yellow pixels, the 1/2 attack will use the Blue pixels.
      • (3 APR), All attacks after the first Blue pixel are offhand attacks, even if other colors proceed them.
    • Using RNDBASE4.BMP with:
      • (7/2 APR), Offhand attacks are governed by Blue pixels, the 1/2 attack will use the Magenta pixels.
      • (4 APR), All attacks after the first Magenta pixel are offhand attacks, even if other colors proceed them.
    • Using RNDBASE5.BMP with:
      • (9/2 APR), Offhand attacks are governed by Magenta pixels, the 1/2 attack will use the Cyan pixels.
      • (5 APR), All attacks after the first Cyan pixel are offhand attacks, even if other colors proceed them.
    A 1/2 attack will occur on every other of it's (color) pixel, not every other Red pixel.
    • If the number of it's (color) pixels is even: It will start with the first instance every round.
    • If the number of it's (color) pixels is odd: On the first round, it will start with the first instance. One the second round, it will start with the second instance (which is normally lacking, hence one less attack in the second round).
    • Each skipped instance still results in an attack animation, fulfills the "AttackedBy()" trigger, and counts as an attack to end Sanctuary/Invisibility. These are NOT the same as cosmetic attacks, which only result in the attack animation.
    Improved Haste and Slow do not alter how any of this works, they simply half/double the round timer.
    Normal and Weak Haste however do alter which file is used (in addition to halving the round timer):
    • (# APR + N Haste, 1/2 APR + N/W Haste, 1 APR + W Haste): Uses RNDBASE1.BMP as if 1/2 APR.
    • (1 APR + N Haste, 3/2 APR + N/W Haste, 2 APR + W Haste): Uses RNDBASE1.BMP as if 1 APR.
    • (2 APR + N Haste, 5/2 APR + N/W Haste, 3 APR + W Haste): Uses RNDBASE2.BMP as if 3/2 APR.
    • (3 APR + N Haste, 7/2 APR + N/W Haste, 4 APR + W Haste): Uses RNDBASE2.BMP as if 2 APR.
    • (4 APR + N Haste, 9/2 APR + N/W Haste, 5 APR + W Haste): Uses RNDBASE3.BMP as if 5/2 APR.
    • (5 APR + N Haste, #/# APR + N/W Haste, # APR + W Haste): Uses RNDBASE3.BMP as if 3 APR.
    ShinAquadrizztfearlessStummvonBordwehrGusindaBubb

    Comments

    • ShinShin Member Posts: 2,345
      Nice find! So with some pixel editing it would be possible to e.g. change the ratio of main- to offhand attacks?
    • kjeronkjeron Member Posts: 2,367
      edited November 2019
      Somewhat. You can add offhand attacks (with or without the expense of mainhand attacks), but you are still limited by which order the attacks will occur.
      The attached files are a sample for multiple off-hand attacks: For APR values using RNDBASE4 or RNDBASE5, it replaces one mainhand attack with an offhand attack (provided an offhand weapon is in use).
      • 7/2 APR will cycle: M-O-M-O - M-O-_-O (previous: M-M-M-O - M-M-O-_)
      • 4 APR will cycle: M-M-O-O - M-M-O-O (previous: M-M-M-O - M-M-M-O)
      • 9/2 APR will cycle: M-M-O-M-O - M-M-O-_-O (previous: M-M-M-M-O - M-M-M-O-_)
      • 5 APR will cycle: M-M-M-O-O - M-M-M-O-O (previous: M-M-M-M-O - M-M-M-M-O)
      • You would need one of these APR values prior to haste, while still not using normal haste (improved haste works though).
      Post edited by kjeron on
      bob_vengShin
    • bob_vengbob_veng Member Posts: 2,308
      hey that's truly excellent. the slight M/O imbalances are negligible. i forgot how p&p rules regarding this work, but to me this looks like an essential fix.
    • Sam_Sam_ Member Posts: 172
      :o What devil's magic is this???
      Permidion_Stark
    • AquadrizztAquadrizzt Member Posts: 1,065
      Excellent work as always, @kjeron.

      The fact that this system was implemented this way is so fascinating to me. I wonder what caused the design decision to store animation sequencing in .bmps instead of hard-coding or a .2da file.
    • BubbBubb Member Posts: 998
      Was looking through how the engine processes the different colors to see if there was anything I could add. Nothing major to note that you haven't already found, just some minor points that might be of some use:
      • black - Starts SEQ_READY if not already SEQ_READY, SEQ_SHOOT, or SEQ_ATTACK.

      • light grey - Sets "CGameSprite.m_startedSwing" to 1 internally. Starts either SEQ_ATTACK or SEQ_SHOOT for corresponding ability, (if not already playing).

      • dark grey - Sets "CGameSprite.m_startedSwing" to 0 internally.

      • white - Exactly the same as black, but it also destroys / frees the attack's current projectile if using a ranged weapon. This only appears in vanilla as a vertical line at the end of the BMP, and you are correct that this column doesn't appear to be processed. If white is placed anywhere else it will do the above, though.

      While "CGameSprite.m_startedSwing" == 1 the engine allows a small bit of range fudging when it comes to attacks. I assume this is to prevent a tiny bit of movement on the target's part from interrupting an attack, which would be annoying for the player.
      kjeron
    Sign In or Register to comment.