Initial mavuika implementation#2301
Conversation
Removed C2 extending initial cast. C2 extension corrected to 6s.
Changed from 10f to 2f after in-game testing.
Syntax fix from previous PR?
- Add C2 DMG% buff when party member takes damage within field - Delay adding field by 1f after final Burst hit to avoid self-triggering
- Reapply remaining sanctum DoT ICD after burst
- Remove normal attacks resetting the boolean for whether skill had been reused - Rename boolean for skill reuse to make more sense - New function to remove field since it is used in several scenarios - Skill recast function now uses character skill tracking variable for skill duration
- Fixed burst casting skill if starting with skill off cooldown. - Set burst status to apply on cast to handle actions that can interrupt the burst being used before first hitmark. Will need to evaluate best way to cancel the first queued attack. - Removed old burstCast tracking variable.
- remove / 100 as well
- implement a1 - implement a4 - implement skill damage mitigation and self DoT - fix burst frames because no basis on sheet - fix burst punch/kick state for iframe semantics - move asc/cons checks into the functions - move c2 to its own event sub - rename remove field to pick up field
- two vars instead of array for flat dmg ratio
- fix c4 icd not being hitlag extended - adjust c4 heal message - c4 heal target should always be dehya
- fix slow punch hitmark - fix burst interaction with attack/skill during punches - add dash -> jump interaction during burst leading to kick - refactor jump canceling burst punches - min 6 punches idle, max 10 punches <C6, max 15 punches C6 applies now - remove burstFrames for constant - cannot cancel before first punch so simplified burst func
- doesn't really matter right now because burst punch/kick do not have hitlag
- fix frames - fix sac pickup timing to happen right before redeploy instead of on action start - remove unnecessary hitlag info for non-hitlag attacks - adjust c2 flag reset to be a bit more future-proof - fix skill damage DoT having icd (should have no icd)
Atk Speed did not apply accurately, adjusted animation length to account for attack speed. Hitmarks were moved up slightly (more accurate) to assist with BoL logic in configs.
Updated frames for Skill and Attack actions.
Added frames for plunge for bike and non-bike version. Support for walk-jump into low_plunge.
Comment update on CAF Delay
Only one left, not sure how to solve.
Fix nested statements to cap allowed hold duration to various limits.
CAF was double-adding partial CA durations when forced into final hit.
Recast can queue faster than normal skill use, so this extends the normal skill frames out of plunge to match total frame times. The ratio is slightly skewed, but I think it's the lesser of two evils. Fixed CAF timing again.
Based on testing, A4 is affected by hitlag.
| if a.Target.Type() != targets.TargettableEnemy { | ||
| return | ||
| } | ||
| if c.StatusIsActive(c6IcdKey) { |
There was a problem hiding this comment.
Does this status have a function, since the ring can only trigger once every 2 seconds? Or is it just an extra sanity in case the ring hit interval is somehow decreased?
Or does the cb from QueueAttack get called for every target hit, so this is required to prevent multiple triggers from a single ring hit in aoe?
| } | ||
|
|
||
| func (c *char) Jump(p map[string]int) (action.Info, error) { | ||
| if !c.StatusIsActive(player.XianyunAirborneBuff) && c.armamentState == bike && |
There was a problem hiding this comment.
Leaving note for reference for plunge code review. If Mavuika has Xianyun Airborne Buff, Mavuika will do a Xianyun-buffed jump, no matter whether Mav has bike armament state or not.
Updated the valid target check to align with what it's actually checking. Changed bool for final hit to be more intuitive with the conditions triggering it.
Add support for biked plunges with XY buff.
jwalk-511
left a comment
There was a problem hiding this comment.
Review is not done, just leaving comments so far as a starting point (Notably, I have reviewed all functions called by BikeCharge from line 121 to 147, and functions called by those functions, recursively. But I have not reviewed functions only called by BikeCharge after line 147, including HoldBikeChargeAttack and CountBikeChargeAttack)
|
|
||
| func (c *char) buildValidTargetList() []HittableEntity { | ||
| enemies := c.Core.Combat.EnemiesWithinArea(combat.NewCircleHitOnTarget(c.Core.Combat.Player(), nil, 8), nil) | ||
| hittableEnemies := []HittableEntity{} |
There was a problem hiding this comment.
Very small performance optimization:
Initialize hittableEnemies with a capacity equal to the number of total enemies, so the array under the slice doesn't need to be reallocated every time you append to the slice (on line 485)
| case *geometry.Circle: | ||
| enemyRadius = v.Radius() // Rt | ||
| default: | ||
| return false |
There was a problem hiding this comment.
It might be better to throw an error here rather than return false. If a non-circular target is ever added, this would cause Mav to silently "skip over" them, doing know damage, which would be hard for an end user to figure out.
There was a problem hiding this comment.
Added error saying Mav needs circular hitboxes for CA calcs.
| if g == nil { | ||
| continue | ||
| } | ||
| switch g.GadgetTyp() { |
There was a problem hiding this comment.
Can you try to future-proof by adding a default case that checks if a gadget is targetable and adds it to the gadgets list if so (similar to the Tea Lotus)? Or raises an error if you think any new gadget type would need custom handling
There was a problem hiding this comment.
I might be interpreting this wrong, but it looks like all gadgets are targettable, so a default case would be handling pretty much every other gadget type and may not know if something is "new" unless the current case select has every gadget type explicitly handled. I think either way would require a bug report in the future, but I might be missing an easier solution here.
There was a problem hiding this comment.
I think you're right; I was assuming that most gadgets would have some flag indicating they shouldn't be targeted by player abilities but if that isn't present then it isn't a super huge issue.
It could only possibly matter if some future character can create a gadget that can be hit by any other character, which is a rare case anyway
There was a problem hiding this comment.
Generally if a player cannot hit the object, there is no reason to actually code the object as a gadget.
| c.Core.Tasks.Add(func() { | ||
| c.bikeChargeAttackHook() | ||
| }, bikeChargeAttackStartupHitmark-1) |
There was a problem hiding this comment.
-
I think this needs to be called immediately. If a target moves/dendro core spawns between this frame and bikeCASH -1 frame, then no change would be made to the bikeHE list.
-
If it doesn't need to be called immediately, then you can pass
c.bikeChargeAttackHookdirectly rather than an anonymous function that calls the same function.
There was a problem hiding this comment.
Went with the first option, since cores could be missed in the scenario you described.
Updated docs for Mavuika's actions and params. Added bike dash handling for specific frame counts. Added an error when a target has a hitbox shape that does not work with the CA calculation. Changed hook timing to capture dendro cores that spawn during windup. Updated comments. Fixed CAF not meeting the minimum CA duration if used as the first action. Added 'buffered' param to allow for delaying CA after burst in order to proc N0 triggers.
lint bugfixes
Add note about approximated aoe
Added hitlag and aoe information.
.generated.jsonfiles)mode_gcsim.jswith shortcuts for syntax highlighting