Player Features and Ideas Discussion

Well, that's a nerf...

Guess after that nobody can rightfully complain about OP cloakers in their System anymore.

Yup if they live long enough to get there.

I do hope CCP read these.

It's been noted that having your cloak status available to both sides of an engagement technically would give the cloaker an advantage, as he'd know in advance (within 2 seconds) when to expect to decloak. The campers on the other hand would only know it's within the next 60 seconds. This does put him at some advantage.

It's logical and balanced to have it this way. There are many combat scenarios where the pilot who engages his commands first is at an advantage due to the opposing pilot needing some amount of extra time to respond to the actions. This is just another one of those scenarios. You wouldn't complain that the guy uncloaking in your gate camp was able to get his alpha in on you first. So why complain that he can activate his cloak first?

Let's assume all was even for arguments sake; this advantage explained above suddenly ceases to exist. The chance of 1 gate camper catching 1 traveler is now the same as the traveler successfully escaping.
Now let's consider a gate camp where a handful or more of players will have enough scan res to instalock the traveler.
If each individual camper has an even shot at tackling the traveler, we can assume that a gate camp of even half a dozen competent pilots will be able to take down the vast majority of travel-fitted ships passing through.
Under consideration of the size of most gate camps, this would not be balanced as your chance of success when traveling would be far below 50 if crossing even 1 gate camp (assuming they are competent pilots).

Or maybe it's some thing with the session timer on SiSi... Maybe that thing just got the wonkers out of jealousy for is big TQ brother...

A short history of cloaking:

Prior to the 2011 winter expansion (Crucible I think) cloaking device reactivation delays were not preserved through session change timers. This enabled covert ships to warp to 0 on gate, get decloaked, immediately jump, and then perform the MWD/cloak trick as soon as they load grid.

In an undocumented change in Crucible, the reactivation delay timer became preserved through session changes. Most covert capable ships have a reactivation delay of 5-10 seconds depending on the ship. The timer simply expires while you are making the jump and loading grid. Therefore it is rarely noticed except on bombers, which have a 15 second reactivation delay.

In short, be patient young paduan. When you load grid zoom out, look around, and decide on a safe path before trying to warp away or burn out of a bubble.

But... it would be nice if we had an in-game indicator to show that the cloaking device is not available.

Up!

The solution to the another problem with cloaking module spamming is to implement global cooldown (GCD). I don't know if it is exists in current internal game mechanics, but implementing global cooldown of 1 second will prevent situations like these. Then, for the risky modules like cloaking devices, creating a column in the items database table, named: "GCDActive" and putting "1" for mis-clickable modules should do the trick.

So, the result is, when you start spamming your cloaking device and when it is actually hit by server, your cloaking module starts glowing out green, but global cooldown kicks in. As I told in my first solution, when global cooldown is active on a module, simply making cloaking device greyed out aka "disabled" for the duration of the global cooldown will prevent mis-usage of de-activating it accidentally in most cases. During GCD, you will see your module glowing green but disabled (not be able to be clicked for 1 second)

Hidden timers suck.

Fighting the UI and/or latency rather than other players sucks.

There are a few cases where the UI can encourage spamming, which I feel is a flaw in the UI- it's presenting you with something that should be clickable, but making it's activation based on hidden parameters. This is especially bad with something on a context menu (e.g. titan bridge).

One big improvement would be to have countdown rings similar to the current cycle rings we have to indicate how long until a reload completes or a cloak becomes usable again.

Another would be to allow a limited amount of queuing, for example, if you try to lock a ship that is invulnerable, start locking as soon as that invulnerability drops (easy mode for insta- ships I suppose, but takes wrestling with the UI and latency out of the equation somewhat, so overall an equalizer).

The UI could implement 'spam' detection and prevent rapid clicking/pressing from resulting in a rapid activation/deactivation (require a short pause to send a deactivation).

This suggestion is actually a specific case of wider suggestion that gets spammed over and over again (and I support it):

We need cooldown / reactivation / reload / repair time indicator for mods.

Thanks in advance CCP.

Not to be mean against anyone, but discussion is leaning in wrong direction. Trying to cure a problem with workarounds is not what we are looking for. Even tough there are other indicators that can tell you if it is ok to cloak or de-cloak, there actually is no preventing mechanism for de-cloaking again in case you're spamming cloaking device in an emergency situation.