Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BRD: does not work with logs processing due to job resources being tracked on the BRD job, but that makes it hard to execute and track on a class being buffed #40

Open
Amarantine-xiv opened this issue Feb 22, 2024 · 6 comments

Comments

@Amarantine-xiv
Copy link
Owner

Maybe just have the resource append if it's not in the dict? A hack, but it would work....but there would just not be an appropriate JobResourceSetting.

@periodically-au
Copy link
Collaborator

Yeah I noticed something like this too last night. I didn't spend a long time debugging it tho, but I can look into a potential fix.

@Amarantine-xiv
Copy link
Owner Author

I think the issue with BRD is that the songs (Mage's Ballad, The Wanderer's Minuet, Army's Paeon, Radiant Finale), either consume or give job resources (coda), and job resources are only tracked by the jobs that "own" the skills (BRD in this case). Because of this, when Radiant Finale is applied to a party member that is not the BRD, that party member has no idea how many codas were consumed when casting Radiant Finale. Only the BRD will know.

I think the soln to this could be to explicitly tag skills that are party buffs, and have them be distributed to the party on cast (with the owning class knowing how many job resources were used).

This could be fixable from the logs processing side, but I wonder if it'd be complicated. I'm looking into this issue.

For now though, I might just make Radiant Finale use the full 3 coda buff so at least it doesn't crash. But this is very wrong, and wrong even in an opti setting since I believe the BRD opener uses a 1 coda Radiant Finale.

@periodically-au
Copy link
Collaborator

without giving a lot of thought, this is definitely possible to check in the log processing if I can just input some SkillModifier later to set the 6%

I can just check between finale casts to see how many songs got used. It might not be efficient but I wouldn't need to do a lot of looking.

@periodically-au
Copy link
Collaborator

periodically-au commented Feb 23, 2024

You can also maybe do something lazy and assume first is a 2% and later usages are 6% for a quick fix that won't need much to change until I find a nice way to get coda tracking.

Another idea is assume song usage based on usage time: it's around every 40s so any cast after 0:41 is a 4%, after 1:21 is a 6%, etc.

@Amarantine-xiv
Copy link
Owner Author

Yeah, all of these are possible and should work.

I can just check between finale casts to see how many songs got used. It might not be efficient but I wouldn't need to do a lot of looking.

Yeah I think we can do that. Let me check in a hack on the skill side to make that work (you'd have to specify something like "2 Coda, Buff Only" as the condition. The format should be "X Coda, Buff Only". The current implementation of Radiant Finale will keep track of the actual codas you have, in case you do something stupid like use the same song twice before a Radiant Finale (so you don't get credit for 2 codas), but that bookkeeping doesn't need to be done on other party members.

I'll post back when the hack to make the skill side of Radiane Finale work with the "X Coda, Buff Only" thing.

@Amarantine-xiv
Copy link
Owner Author

Amarantine-xiv commented Feb 23, 2024

Hack for BRD Radiant Finale is in.

The conditions added are:

"1 Coda, Buff Only"
"2 Coda, Buff Only"
"3 Coda, Buff Only"

This is not quite gramatically correct, but it makes counting codas and generating the string less annoying.

They are canonicalized, but that just makes the comma separated effects in alphabetical order....which should be exactly as above. You could call the simulator's Utils.canonicalize_condition(...) fn, I suppose, if you wanted to make sure.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants