Live Events Discussion

Ah, true, my mistake, I thought he was refering to the remote ones, given the regular ones really don't do a lot other than get you concorded as you said.

After reading through here, I agree with some of the points said. Yes, players should be allowed to kill actors (the Amarr militia would have jumped at this opportunity, IMO), but on the other hand these actors should also be significantly harder to kill than players (make them on par with "boss" type NPCs in other RPGs). On the flip side, loyalist pilots should somehow be allowed to support the svyotd. If there had been constant RR on the dev actors, the loyalists would have gotten Suspect flags and simply would have been killed off before the actors were (assuming the actors had been vulnerable). Maybe this would have given the actors time to warp off or somesuch, but it's still pretty bad that the gankers wouldn't be able to be countered in spite of the fact that these are supposed to be government officials with top-of-the-line equipment, security, all while being escorted by a loyalist vanguard.

If there's going to be heavy player interaction, at least have it go both ways.

Or, you know, Slave implants. Those are a thing.

Goonswarm shennanigans aside here.

When I dungeon mastered games, I had players that constantly did things that were "not in the story". But, as a DM, I had the tools to create consequences for the player's actions that would effect the rest of the campaign.

Did I prevent them from doing what they wanted? No.

BUT - I would dare say if your group blew up a ship containing an important NPC, you would tee off that NPC. That NPC might know folks in NPC corps in empire space.

Goonswarm would find all members of member corps unable to dock in that empire's stations and any clones there terminated.

Tee an empire or NPC corp off bad enough, make them KOS to militia.

Live event planners need that kind of tool instead of invincible npcs.

Yea, Percentage would be silly, agreed there.
Target denier would also be a bit silly I agree, it was just a 'way to do things', as I don't claim to know every reasonable way providing a defence against alpha could be achieved.

But right now there is a problem with the lack of any mechanic to defend. So... if we flipped this scenario the other way around. Say the goons had ganked this target, then ganked the next one as well. Why should any of the 'good guys' bother to turn up when they can't influence events regardless. The goons will turn up or they won't and the target will die accordingly.

Not saying you are advocating this, but it is the flip side of the coin we have presently. Whichever way the Devs run it, either the gank is crazy (In theory it was gankable still, all be it needing 8 million alpha :P, but the number could be whatever), and the gankers stop bothering to show, or the gank is reachable, and the defenders stop bothering to show.

I believe that:
A: Any party wishing to destroy an event actor in space should have the reasonable ability to do so.
B: Any party wishing to protect an event actor in space should have a reasonable counter to those attempting to destroy the actor.

With that in mind, while there are some tools already mentioned that will enhance the EHP of another ship to attempt to protect from a suicide alpha damage gank, they are limited.

So I propose a new mod (These stats are just what I thought of in about 5 minutes looking at existing mods, they can be changed and tweaked):

Large Shield Reinforcer (Meta 0; skills at Lvl V)
Activation time: 2s
GJ: 30
Range: 10km (Not able to be modified by links)
Adds 900 Shield hit points (this is added on after rigs are considered.)
Fitting: 90 MW, 75 TF
High Slot

Large Shield Reinforcer II (Meta 5; skills at Lvl V)
Activation time: 2s
GJ: 45
Range: 15km (Not able to be modified by links)
Adds 1300 Shield hit points (this is added on after rigs are considered.)
Fitting: 120 MW, 80 TF
High Slot
There would be a new skill, same prerequisites as Shield Emission Systems. Same 2x training modifier, and attributes. The skill would reduce the capacitor needed to operate the module and increase the range. Tech II Reinforcer would require the skill to level IV.

And in various meta levels and scale accordingly. Repeat the process with medium and small ones. I doubt the small ones will be used much, though.
Do the same with armour. Nanites, baby, nanites.

These modules would also subject to a diminishing returns. Ideally it would take fifty of the tech II modules to increase the shield HP about 26k. Adding 75 of these modules would increase to 32k. This is added ~after~ every other factor is considered: leadership V, rigs, anything. It would still, of course, benefit from the resists of the target.

Here's how I think it would affect gameplay:
FC's of subcap fleets that lend themselves to anchoring on the FC: about fiftyish or so fleet members fit it and keep it active on the FC. This could be very useful in large null sec battles. I don't see it being too useful in small gang pvp, since alpha damage is much less of a factor there. It can also be used to help beef up the shields of a ship that is carrying particularly expensive cargo in high security. It will make a suicide gank harder, but not impossible, but dammit, if someone brings a thousand people, they deserve to get the kill. In the old contest between armour and a warhead, they warhead will always come out on top--eventually.
It can be countered. A pilot using remote reinforcement can be jammed, bumped off or cap drained. In nullsec battles, where I see this making the most difference and having the most usage, supercapitals can use remote ECM bursts on the FC and anyone that is using the mod will be in range of the burst. The enemy fleet will then have time to try and burn down the FC. The logistics wing will be out of range of the ecm bursts and still be able to apply reps (assuming the logi anchor knows what the heck to do).

Not sure if diminishing returns should apply. it doesn't apply to Plates/Extenders/Remote reps don't have diminishing returns, and it's hardly going to make a fleet invulnerable. 24k is hardly enough to make any different to a gank after all, and 50 of these would mean 10 cruisers completely dedicated to it. Maybe 2 Tornado's alpha straight through 10 cruisers efforts? Adding ships to the alpha fleet doesn't have diminishing returns after all, and thats what we are discussing a counter to it.
Cycle time should probably match shield reps at worst, and be longer probably. Otherwise your nerfing the module into the ground with cap use.

Wars in EVE, we don't live in a space fairing universe I didn't think I would have to point that out :P

It was a cut scene? So what, it was an event, its EVE, you go to an event expect EVE like things to happen. Why can't real players affect these things? For years CCP has given up on the NPC aspect of EVE and has focused on players making there own content.

I agree on your fairness point, I was more hinting towards the fact that everyone starts the same but depending on your actions, bonds with other players and personal ambition, you can rapidly make it all highly unfair for someone else.

Oh yea, the Devs will set the final numbers. But I counter with the question. How much damage to 175 drakes do?
I've seen some 500 DPS numbers tossed around recently for drakes, also seen higher.
So, 175*500 per volley. 9 seconds a volley (or there abouts, no overheating). 87.5k damage per volley. So, assuming 75% resists (Maybe low on a command ship, maybe not depending on the actual target.) Thats bought the command ship 90 seconds to live. With the efforts of 175 drakes that means each drake gives.... about 0.5 Seconds of life. Is 0.5s effort per drake (which means no Neuts on field, No remote rep spider tanking by the drakes, nothing like that) too much. Ok, Higher resists might push that even as far as 1 second per drake if we jump up to 87.5% resists.
So, this creates an interesting dilemna for the enemy FC. Does he primary the CS anyway, aiming to burn through, jam/cap/whatever the logistics. Or does he accept the CS is on field and giving boosts, and start gunning down the drakes instead. Or does he go for alpha volleys on the Logi's who aren't buffed because the buffs are all on the CS.
All the other ships in the fleet are still as vulnerable as they are now, and those 175 drakes are also all in range for a single Remote ECM burst as you said. So yea, it comes with strengths, but also comes with weaknesses at the same time.

Here is where a longer cycle time kicks in. If the cycle time on the remote buffer is longer than for most guns, the guns can switch targets and alpha a ship before it can be buffered, giving them a chance to slip through with good target calling & reactions by the fleet.

Sticher, I agree any module should be CCP designed, but if we debate a lot of the surrounding issues out on the forums before they get deep into the process, it makes their lives much easier. I've done Dev work on a smaller scale enviroment, and I know I found starting on a discussed issue easier than starting blank, because Blank I had to think of everything myself.

During those wars, Boosts weren't on grid though normally were they? OGB's are the common choice now. However the CS getting primaried right out the gate is one of the big concerns people raise about OGB being removed. I also agree it won't replace Logi, the point being it's just buffer. Buffer keeps you alive till Logi can rep you, not alive regardless.
And Drakes don't need to give up a gun to fit a remote mod. They have a utility high. Same as all the BC's do. So this expands the options for what they do with that utility high. So they will have identical DPS to no remote mod fitted (most likely anyway, depends on exact fitting for that) as with one. Meaning they can keep a couple of high priority friendly targets reinforced, and a decent number of DPS targets also locked.
It's not meant to be a be it all end it all mod, that I don't want, but a tactical mod for additional options, which in some cases is the better choice, and in some cases you want mixed options on, is a good thing.