Mob CC Protection

So, now that we know the Tank will in fact have a decent amount of CC, and that CCs seem to (at the moment), combine 'raw', i.e. you can expect that Status A doesn't PROTECT from also getting status B, it just upgrades to Status C...

How do people prefer mobs to experience CC chains?

Let's assume that the same area from the Tank Showcase was undertaken by a larger party, but instead of adding the other four archetypes, you just added 4 more Tanks.

Functionally you could just 'make sure mobs never get to do anything' if they have no CC Protection. But on the other hand, it might feel bad to 'CC a mob, then be unable to CC it again to stop a big ability because you just did that'.

Any opinion on how this should be approached?

We have not received permission from Songcaller to share the quoted post.

"Functionally you could just 'make sure mobs never get to do anything' if they have no CC Protection. But on the other hand, it might feel bad to 'CC a mob, then be unable to CC it again to stop a big ability because you just did that'."

Just verifying that you're implying this is fine for you.

Same as players. And if you know that the mob has some strong ability - do better and don't just constantly CC it.

We have not received permission from George_Black to share the quoted post.

Secondary splinter Topic created for higher priority topic.

In the meantime, may I assume that you are okay with Mobs having immunities? Any additional detail? Should Lord Oakenbane have full immunity to tripped for example? Or do you mean a faster CC immunity buildup? Is that type of 'boss' not on the level you're referring to?

NiKr wrote: »

Same as players. And if you know that the mob has some strong ability - do better and don't just constantly CC it.

I expect that your answer to this question will be complex, but I must ask it anyway.

What do you want to happen when an unrelated party CCs your boss to trigger its immunity when they think it is about to unleash on you soon?

I will only ask that you don't consider the situation where any mob has CC protection from anyone who wasn't the original one to engage with it, because I don't think we have time for that rabbit-hole.

Azherae wrote: »

What do you want to happen when an unrelated party CCs your boss to trigger its immunity when they think it is about to unleash on you soon?

I will only ask that you don't consider the situation where any mob has CC protection from anyone who wasn't the original one to engage with it, because I don't think we have time for that rabbit-hole.

Aren't these two contradictory though?

As for that situation, I'd probably prefer some, at least, small threshold of threat for those CCs to work. Maybe even a dmg threshold requirement. Cause it would mean that the 3rd party was present near the boss for some time and even made some aggressive actions (I'd prefer if those counted towards threat even if they were aimed at other players, I wrote out my idea in the Guild Bombing thread). And if the OG raid didn't address their competitors in any way - that's on them.

But yeah, letting anyone just CC your mob/boss would probably become a fairly big issue. On the other hand, people wouldn't be able to just help others by CCing a hard mob chasing a weaker player, but I think this is the stuff you were asking me to avoid thinking about, so I'll let it go

I

We have not received permission from Spif to share the quoted post.

What are you counting as a 'longish immunity timer'?

I had some reason I was analyzing why I don't like the initial Break Bar implementation concept, but I got caught up in something this weekend and forgot the specifics...

I may have an 'objection' to it later.

If anyone wants to help me remember, it started at 'A Break Bar would still require Immunity in order to be effective if it can be depleted by multiple Tanks all using their abilities especially if not all need to be in the party/raid'. I went about three steps past there (recognizing that this has an easy design solution, then finding a player exploit in that solution, then countering the exploit, and then finally the part I forget now is the 'this ends up going against a design principle').