Hello,
I just coincidentally noticed that the above four skills share a CD... but why? As you can't switch jobs during battle it seems a bit weird to me? Is there some logic behind it which I don't understand?
Hello,
I just coincidentally noticed that the above four skills share a CD... but why? As you can't switch jobs during battle it seems a bit weird to me? Is there some logic behind it which I don't understand?
They tell me DT music sounds a lot like Jazz. Meanwhile I'm sick and tired of the conventional fixed style jazz. (I'm just making a pun here...)
It's probably some nonsense on the back end, I vaguely remember enochian or life of the dragon sharing a cooldown with I think vengeance when they were still their own buttons.
Yeah this. It happens with most Jobs. It probably has something to do with the back end coding. All the Healer "2 min" CDs share a slot as well. Like Passage and Summon Seraph and Temperance. Blow all your CDs on a Healer (since they don't require a target or combat) then swap to literally any other Job and you'll see their Abilities with their CDs ticking.
Not sure what causes it, but it's definitely a thing. Probably something to do with the way character data and abilities are stored in "slots" on the backend. Passage of Arms and Temperance are in the same "slot", so using one causes both to go on CD. The real fun part is, sometimes the CDs don't even match. Like a 2 min CD on one Job could be a 90 sec on another, so if you use the 2 min one first, then swap to the second Job, you might see a 90 sec CD ability with more than 90 seconds to tick before it refreshes.
Sounds like some jank with the coding of jobs that causes it. Completely talking out my ass here but maybe they share some skill ID between jobs which tricks the system into thinking its on cooldown.
I'm just taking a wild guess, since I can't be sure how the game handles cooldowns and I'm only a novice when it comes to programming, but I imagine it's a way of conserving memory and processing. The fewer timers the game has to keep track of per player in the server, the more processing can be used for other things, (like having more players, mobs, npcs, or active FATEs in a zone). So instead of the game having to potentially track every cooldown for every skill for every job for every player in the server, which can easily reach into the thousands for a single zone, it can limit it to say, 40-50 cooldown timers per player and have skills on different jobs share the same cooldown timer.
One thing to note is that it's not a good idea to just "create" timer objects on the fly, since that requires processing to instantiate the timer into memory, more often than not these things have to be "pooled" into memory beforehand when the program is started so as to not only keep the program running smoothly, but to make sure that the program doesn't end up using more memory than intended. Otherwise we could have potential shenanigans where you could get hundreds of players in a zone spamming all their cooldowns to create new timer objects in memory for the game to track, potentially eating up lots of memory and causing that zone's server to crash.
https://en.wikipedia.org/wiki/Object_pool_pattern
I'm sure someone much smarter than me with better knowledge on this would be able to think of a better explanation for why cooldowns are shared (or at least able to better explain what I poorly attempted to say), this is just the first thing that came to mind with my small bit of experience with Unreal and Unity behind me.
Last edited by TheDustyOne; 05-14-2023 at 04:05 PM.
This post on another thread is generally along the lines of what I've seen offered before as an explanation whenever this question gets asked:
The cooldowns persist so that you while you're overworld questing you can't burn all your powerful instant attacks, change jobs away and back, and then burn all your powerful instant attacks again. So the cooldowns need to be kept track of even after you switch jobs.
But if the cooldowns weren't shared, then you could ostensibly burn all your instant attacks on RDM, then switch to DNC and burn all your cooldowns, then switch to NIN, then to .... etc.
It wouldn't happen very often, if at all, but the SE devs have always been at the extreme end of software design conservatism. They plan for the highest possible volume of data access and transfer, and the highest possible computational commitment, and take steps to minimize both, even when such extremes would be unlikely. Ergo limiting the number of cooldowns each player can have going at once by sharing them between jobs.
Working as intended. Most jobs have a "big cooldown." They don't want you hopping on a job like say... MCH and popping two guaranteed crits for Air Anchor/Drill and then go on WAR and use Inner Release for Primal Rend and 5 FCs and then GNB using Double Down, etc etc etc. It might not seem like something players would do, but there was probably a time/place where this could have been exploited.
An addendum to my previous comment just to clarify: I used the example of blowing all your cooldowns on multiple jobs, but the recast sharing isn't about overworld balance or power; it's about how much memory your recast timers take up. If the timers weren't shared, you could blow all your cooldowns on every job, and end up using a hundred or more recast timers at once. Multiply this by the number of logged in characters and you have an obnoxious amount of memory devoted just to keeping track of recasts.This post on another thread is generally along the lines of what I've seen offered before as an explanation whenever this question gets asked:The cooldowns persist so that you while you're overworld questing you can't burn all your powerful instant attacks, change jobs away and back, and then burn all your powerful instant attacks again. So the cooldowns need to be kept track of even after you switch jobs.
But if the cooldowns weren't shared, then you could ostensibly burn all your instant attacks on RDM, then switch to DNC and burn all your cooldowns, then switch to NIN, then to .... etc.
It wouldn't happen very often, if at all, but the SE devs have always been at the extreme end of software design conservatism. They plan for the highest possible volume of data access and transfer, and the highest possible computational commitment, and take steps to minimize both, even when such extremes would be unlikely. Ergo limiting the number of cooldowns each player can have going at once by sharing them between jobs.
My favorite historical example of this was in ShB when Minor Arcana had a recast of 1s but it shared it with, among other Abilities, Blood Weapon, No Mercy, and Sneak Attack, so if you used any of those you would put an AST Ability on a recast 60 times longer than it was meant to have.
Last edited by Rongway; 05-16-2023 at 08:43 PM.
Error 3102 Club, Order of the 52nd Hour
That's probably spot on. For each character, they probably assign a certain number of timers. And in order to keep it limited, each job is probably assigned certain slots in the timer list to limit the total number used at any one time.An addendum to my previous comment just to clarify: I used the example of blowing all your cooldowns on multiple jobs, but the recast sharing isn't about overworld balance or power; it's about how much memory your recast timers take up. If the timers weren't shared, you could blow all your cooldowns on every job, and end up using a hundred or more recast timers at once. Multiply this by the number of logged in characters and you have an obnoxious amount of memory devoted just to keeping track of recasts.
Just as people already mentioned, they are part of the same CD group or whatever, yet another spaghetti code. Be glad that it doesn't break like gap closers. If you use all 3 stacks of DNC's gap closer and swap to DRK for example, then Plunge is at 90 seconds cooldown and behaves like ability without stacks. Once cooldown passes, you go from null stacks straight to 2.
|
![]() |
![]() |
![]() |
|
Cookie Policy
This website uses cookies. If you do not wish us to set cookies on your device, please do not use the website. Please read the Square Enix cookies policy for more information. Your use of the website is also subject to the terms in the Square Enix website terms of use and privacy policy and by using the website you are accepting those terms. The Square Enix terms of use, privacy policy and cookies policy can also be found through links at the bottom of the page.