Dendro implementation notes

[srliao]

This is to keep track Dendro implementation notes/thoughts:

Gadgets

Will need to implement generic gadgets to handle proper interaction with Bloom

type Gadget interface {
    OnAdded() // called when gadget gets created
    OnRemoved() // called when gadget either expires, or is destroyed
}

All gadgets need to implement combat.Target interface. This is to make sure gadgets can be added to the combat system. Gadgets should live for as long as it has durability or unless a duration is set.

Default implementation

Should provide a default template providing common functions that specific gadgets can build upon. Something like:

type Gadget struct {
    x, y int
    index int
    thinkInterval int
    onThinkInterval func() // this function to be called on think interval
}

func (g *Gadget) Index() { return g.index }
func (g *Gadget) SetIndex(idx int) { g.index = idx }
func (g *Gadget) Tick() {
    // per tick logic here
}

// any other basic stuff, etc etc

combat.Target refactor required

We should remove the following methods of combat.Target. These methods really aren't useful to gadgets. Only time these methods are used are typically on event hooks, which would check for type == Enemy anyways. In addition, combat.Handler doesn't actually need to know if a target is alive or how much hp it has.

    IsAlive() bool
    MaxHP() float64
    HP() float64
    AuraContains(e ...attributes.Element) bool

We can refactor combat.Target to the following:

type Target interface {
	Index() int         //should correspond to index
	SetIndex(index int) //update the current index
	Type() TargettableType   //type of target
	Shape() Shape            // shape of target
	Pos() (float64, float64) // center of target
	SetPos(x, y float64)     // move target
	AttackWillLand(AttackPattern) bool   // hitbox check
	Attack(*AttackEvent, glog.Event) (float64, bool)
	Tick()
	Kill()
}

This way AttackWillLand can handle any dead or alive checks. Alternatively change it so that dead targets are removed from the targets array. Only problem with this is that logging needs to be changed to log not by target index but by some sort of target key and target key cannot be duplicates.

Also AuraContains(e ...attributes.Element) bool can be moved to a different interface in combat, and the absorb check be changed accordingly:

type TargetWithAura interface {
	AuraContains(e ...attributes.Element) bool
}

func (c *Handler) AbsorbCheck(p AttackPattern, prio ...attributes.Element) attributes.Element {

	// check targets for collision first
	for _, e := range prio {
		for i, x := range c.targets {
			t, ok := x.(TargetWithAura)
			if !ok {
				continue
			}
			if WillCollide(p, t, i) && t.AuraContains(e) {
				c.Log.NewEvent(
					"infusion check picked up "+e.String(),
					glog.LogElementEvent,
					-1,
				)
				return e
			}
		}
	}
	return attributes.NoElement
}

Modifiers

In the current implementation, gcsim is treating auras as some sort of array of buckets attached to each target object. In reality, auras are just modifiers, which are fairly generic properties that are attached to just about anything. The name of the modifier forms a unique key, such that each target can only have on modifier of the same name. Depending on the properly set, reapplying a modifier with the same name when one exist can either replace, refresh certain properties, or do nothing.

Historically for each "aura" (or existing element), you just had one modifier. Usually something like FireModifier for attached pyro, or ElectroModifier for attached electro. This made our array of whatever buckets sort of work.

However with Burning, we are introducing 2 new modifiers (burning and burning_fuel) with elements attached BUT:

1. These modifiers do not introduce new element types
2. These modifier can coexist with other modifiers having the exact same element (namely Pyro)

This throws a bit of a wrench into our implementation because gcsim is treating modifiers as having a 1 to 1 relationshp with element types. To fix this we need to refactor the reactable.Durability and reactable.DecayRate slice to reflect modifiers instead. It should look something like the following:

type ReactableModifiers int

const (
	ModifierPyro ReactableModifiers = iota
	ModifierBurning
	ModifierBurningFuel
	// etc...
	EndModifiers
)

func (r ReactableModifier) Element() attributes.element {
	return attributes.Pyro // return whatever element each modifier contains underlying
}

type Modifier struct {
	Durability combat.Durability
	DecayRate combat.Durability
}

type Reactable struct {
	Modifiers [EndModifiers]Modifier
	self combat.Target
	core *core.Core
	ecSnapshot combat.AttackInfo //index of owner of next ec ticks
	ecTickSrc  int
}

This should allow us to have multiple of the same element. However, this also means that any code checking for existing pyro will have to check both reactable.Modifiers[ModifierPyro] and reactable.Modifiers[ModifierBurning] as both can contain pyro

Note on multiple of the same element

When a reaction occurs and there are multiple modifiers with the same element present (say ModifierBurning and ModifierPyro), all these modifiers will have their elements reduced. The amount of reacted durability is based on the modifier with the max durability.

For example, suppose we have a target with the following modifiers:

• ModifierBurning (40 pyro)
• ModifierPyro (20 pyro)

If we apply 50 anemo to this target, the amount of reacted durability (for the purpose of calculating the resultant swirl attack) is max(40, 25). However, both modifiers will have their durability reduced by 50 * 1/2 = 25 (i.e. reaction multiplier for anemo). So the result is, the target will be left with:

• ModifierBurning (15 pyro)

ModifierPyro here is fully removed. In addition, we will also get a swirl attack that has pyro durability of 1.25 * 25 + 23.75 = 55.

Currently, we have ModifierBurning and ModifierBurningFuel as newly introduced modifiers that have existing elements pyro and dendro respectively. These modifiers will be affected accordingly if they are present with ModifierPyro or ModifierDendro

QUESTION/TODO: it appears that ModifierQuicken gets treated as if it has element dendro even though it's technically a new element quicken??? Not sure what's going on here.

Quicken

Quicken is a new element. It behaves effectively as a dendro element for reactions. Can coexist with electro, dendro, and cryo (because there is no dendro + cryo reactions). Can coexist with burning (QUESTION: does it act as burning fuel in this case?).

Reaction multiplier

The reaction has a 1:1 multiplier between electro and dendro

Duration and durability

Quicken have different formula than normal "attachment". Existing code uses this function to handle attachment:

func (r *Reactable) attach(e attributes.Element, dur combat.Durability, m combat.Durability) {
	//calculate duration based on dur
	r.DecayRate[e] = m * dur / (6*dur + 420)
	r.addDurability(e, m*dur)
}

With Quicken specifically, the duration formula is changed to: 12 * dur + 360. So the decay rate is actually:

	r.DecayRate[attributes.Quicken] = m * dur / (12 * dur + 360)

Probably best to just not use the attach function call and leave as is. Realistically the attach function should be refactored to handle all cases.

Aggravate/Spread

When quicken reacts with electro or dendro, aggravate and and spread is triggered respectively. Both reactions adds to the AttackInfo.FlatDmg of the triggering attack.

Special note about aggravate/spread. The triggering electro/dendro attack is buffed, however, no durability is consumed on both the quicken and the applying electro/dendro. The applying electro or dendro will attach to the target normally coexisting with the quicken.

The amount of damage added follows the same base reaction damage formula but uses a different EM multiplier. Calculation should be as follows:

func (r *Reactable) calcQuickenReactionDmgBase(atk combat.AttackInfo, em float64) float64 {
	char := r.core.Player.ByIndex(atk.ActorIndex)
	lvl := char.Base.Level - 1
	if lvl > 89 {
		lvl = 89
	}
	if lvl < 0 {
		lvl = 0
	}
	// use 5 * em here instead of the usual 16 * em
	return (1 + ((5 * em) / (2000 + em)) + r.core.Player.ByIndex(atk.ActorIndex).ReactBonus(atk)) * reactionLvlBase[lvl]
}

func (r *Reactable) calcAggravateDmg(atk combat.AttackInfo, em float64) float64 {
	return 1.15 * r.calcQuickenReactionDmgBase(atk, em)
}

func (r *Reactable) calcSpreadDmg(atk combat.AttackInfo, em float64) float64 {
	return 1.25 * r.calcQuickenReactionDmgBase(atk, em)
}

Multiplier for aggravate and spread is 1.15 and 1.25 respectively.

Other quicken reactions

quicken behaves the same as dendro when reacting with hydro or pyro, triggering bloom and burning respectively

Bloom

Bloom is the reaction triggered when dendro reacts with hydro. This one is fairly straightforward. On reaction, a "seed" is generated.

The position of the seed (dendro core) appears to be distance 1 from the target, with a random 0 to 60 degree angle. Presuming this is 0 to 60 degree from x-axis on the cartesian plane (in game uses y). The seed then has an initial velocity and a deceleration. Needs more testing on this. For simplicty probably ok to just spawn randomly within 1 radius of target.

Seeds have a lifetime of 5 seconds. From spawn it should be closer to 6 seconds?

Bloom explode

If the dendro core does not come in contact with pyro or electro (simple attack collision check), it will explode on expiriy. Radius is 5. AttackInfo is as follows:

	atk := combat.AttackInfo{
		ActorIndex:       a.Info.ActorIndex,
		DamageSrc:        r.self.Index(),
		Abil:             string(combat.Bloom),
		AttackTag:        combat.AttackTagBloom,
		ICDTag:           combat.ICDTagBloomDamage,
		ICDGroup:         combat.ICDGroupReactionA,
		Element:          attributes.Dendro,
		Durability:       0,
		IgnoreDefPercent: 1,
	}
	em := r.core.Player.ByIndex(a.Info.ActorIndex).Stat(attributes.EM)
	atk.FlatDmg = 2.0 * r.calcReactionDmg(atk, em)

Burgeon

When the dendro core comes in contact with pyro, burgeon is triggered, dealing an attack with radius 5. AttackInfo is the same as bloom except with combat.AttackTagBurgeon, combat.AttackTagBurgeon and combat.ICDTagBurgeon

Hyperbloom

When dendro core comes in contact with electro, hyperbloom is triggered, dealing an attack with radius 1. AttackInfo is the same as bloom except with combat.AttackTagHyperbloom, combat.AttackTagHyperbloom and combat.ICDTagHyperbloom

Bloom/Burgeon/Hyperbloom self damage

All 3 explosions will trigger an additional attack that damages the player, with AttackInfo as follows:

	atk := combat.AttackInfo{
		ActorIndex:       a.Info.ActorIndex,
		DamageSrc:        r.self.Index(),
		Abil:             string(combat.Bloom),
		AttackTag:        combat.AttackTagBloom, // or AttackTagBurgeon, AttackTagHyperbloom
		ICDTag:           combat.ICDTagBloomDamage,
		ICDGroup:         combat.ICDGroupReactionA,
		Element:          attributes.Dendro,
		Durability:       0,
		IgnoreDefPercent: 1,
	}
	em := r.core.Player.ByIndex(a.Info.ActorIndex).Stat(attributes.EM)
	atk.FlatDmg = 2.0 * r.calcReactionDmg(atk, em)

Radius is the same as each respective type of explosion (i.e. radius 1 for Hyperbloom)

Burning

Probably the most complex reaction to date (way worse than EC or Freeze).... Introdues 2 new modifiers but no additional elements, which technically "breaks" the current implementation but thankfully I think should be ok implementing a hack solution. As long as Hoyoverse doesn't introduce any new reactions. See earlier note on Modifier refactor.

Reaction, Duration, and Durability

When dendro reacts with pyro, you get two resulting modifiers (or "elements" in our hack solution): burning and burning_fuel.

burning always has 50 durability regardless of the reacted amount. It also does not have a set duration. Instead, burning will last as long as both:

1. burning durability > 0, and
2. burning_fuel exists still

burning has element of type pyro and will react just like normal pyro. However it cannot be topped up by additional pyro application (makes sense since it's a completely different modifier). Any additional pyro application will merely coexist.

For our hack implementation, we'll just have to go with:

	r.DecayRate[attributes.Burning] = 0
	r.Durability[attributes.Burning] = 50

And then on tick we'll need to check for if burning_fuel is still present, and if not remove burning

burning_fuel durability has a 0.8x multiplier on the reacted amount. So for example:

• Existing: dendro 20, applied from a dendro 25 attack
• Applying: pyro 25
• Result: dendro (burning_fuel) 16

The duration formula follows the standard 0.1 * d + 7 in seconds, or 6 * d + 420 in frames.

In addition, the decay rate is subject to a minimum threshold of at least 10 durability per second. Effectively, you have the following for decay rate:

	decayRate := m * dur / (6 * dur + 420)
	if decayRate < 10.0/60.0 {
		decayRate = 10.0/60.0
	}
	r.DecayRate[attributes.BurningFuel] = decayRate

Note here I'm treating burning_fuel as it's own element i.e. attributes.BurningFuel when that's not actually the case here in game (see modifier discussion about).

burning_fuel refresh

Unlike other element attachment, when additional Dendro is applied to existing burning_fuel, it does not overlap but instead refreshes. This means that the existing burning_fuel durability/duration will be overwritten by the applying Dendro durability/duration. However, the existing decay rate is kept.

For example:

• Existing: dendro 40 (burning_fuel)
• Applying: dendro 25
• Result: dendro 25 (burning_fuel)

So you can actually "shrink" the amount of dendro (burning_fuel) aura per say.

Burning damage

While burning is active, every 0.25s it will trigger a spherical attack with radius 1, center on the target that is burning.

AttackInfo is as follows:

	atk := combat.AttackInfo{
		ActorIndex:       a.Info.ActorIndex,
		DamageSrc:        r.self.Index(),
		Abil:             string(combat.Burning),
		AttackTag:        combat.AttackTagBurningDamage,
		ICDTag:           combat.ICDTagBurningDamage,
		ICDGroup:         combat.ICDGroupBurning,
		Element:          attributes.Pyro,
		Durability:       25,
		IgnoreDefPercent: 1,
	}
	em := r.core.Player.ByIndex(a.Info.ActorIndex).Stat(attributes.EM)
	atk.FlatDmg = 0.25 * r.calcReactionDmg(atk, em)

TODO: it's possible that if burning ends early before the next tick happens then the next tick happens right away? not sure

POST STILL WIP

[srliao]

On burning_fuel, still not too sure if this should be a separate element. It makes the code messy because really this is just dendro and not a different element.

Maybe what we can do is (still not quite modifiers), instead of:

	r.Durability = make([]combat.Durability, attributes.ElementDelimAttachable)
	r.DecayRate = make([]combat.Durability, attributes.ElementDelimAttachable)

Where Durability is basically an array of length number of elements, add a new type say

type ReactableModifiers int
const (
	ModifierPyro ReactableModifiers = iota
	// .. regular stuff
	ModifierBurning
	ModifierBurningFuel
	// .. so on
)

func (r ReactableModifier) Element() attributes.element {
	return attributes.Pyro // return whatever element each modifier contains underlying
}

It's not very different from just adding it as elements but keeps elements pure and a 1:1 match with in game.

[srliao]

Updated original write up to include this

[srliao]

Some additional notes for Burning from Carrier5b5, translated by Koli

[srliao]

Some additional tests from @k0l11

25 dendro -> 25 pyro -> 50 pyro: https://youtu.be/_ZT07HU81xQ

Thoma Q lands roughly at frame 200 and ends roughly at frame 920, lasting ~720 frames aka. the full duration of a 50 pyro modifier. This shows that additional pyro application attaches to pyro modifiers and does not affect the burning modifier.