Warfare & Tactics

You're a small POS away from armor repair bliss. Or a mobile depot anchored in a safe spot. Or at most 6 jumps from a non-FW system (Esesier). A significant majority of systems are within 3 jumps of a non-FW system.

Plus, "supply and distance" add geography to the map. And that's not a bad thing.

A 2 day old character in an atron with a single electron blaster and T1 ammo cant break a large rat, FIX THIS AT ONCE CCP

Indeed the rat is a dps check, but in reality its far more than that. Its all thats standing between us and the catastrophe that was post inferno alt plexing. You should learn how to stop worrying and love the rat .

Or, just get rid of NPC's entirely. Instead, have a minimum ship req for a complex timer to tick. Novice needs 1 ship, small needs 2 and so on.

To be honest, I don't like my idea, but I don't like yours either.

Generally I'm just confused over the necessity of a recurring dps check; I think having a tank check with a deadlier npc that spawns once or twice would be better than the current meta since it would force people to actually fit for combat rather than just lazily fly around and shoot the npc, and leave in your stabbed blaster atron when somebody lands on you since you don't know what dscan is.
I get that it makes sense for us to be engaged somehow in what we're doing in the plex, but I DON'T think the npc should bar us from flying certain ships or ship sizes that are properly kitted out for pvp.

All this brouhaha over the years about stabbed farming frigates can be solved pretty easily if you force THEM to take damage. The balance would be that you'd only have 2 NPC spawns; one at the beginning of the timer and 1 at the end. They would reset with rollbacks at a given time, and they would have adequate tracking, range, and damage to cause trouble for a frigate that doesn't fit tank and a prop mod.
They'd be a bit easier to take down, and you wouldn't have such a long timer disparity between defensive and offensive plexes. THAT'S what I'd like to see happen specifically.

What you are arguing for is what we have had before, pretty much word for word. Even you posted yesterday and admitted it was a bad idea iirc.

I guess the Farming Asssociation of Isk Leaches was unhappy with your performance as their lobbyist and have sent you back to redouble your efforts.



This would be a good catchphrase for you.

the only thing in o plex that needs fixing is the odd behaviour of the rats that go like 4k in a BC..
otherwise its fine.

D-plex on the other hand need to be fixed.. fuken hoards of 1 day year old fw alts in empty ships ...
something is not right about that.

What you need to realize is:
A few CCP peoples have toons sneaking about in FW - They don't need Mirana Bacons input.

So while Bacon might be doing a lot to promote ideas to them - they won't really listen as they have already formed their own opinions.

Make it so you have to lock up the button in order to run the timer, and it fires 100% ECMs in certain intervals.
Stabbed ships would increase the capture time cos locking it would take a while with sub 100 scan res.

TLDR; Expensive check still needs to happen to set the flag, resources (potentially more) still spent though may be spread out over time. Not the droids you're looking for...

The check for pods would be a meta check wouldn't it? "If player ship = pod" do not run button similar to "If player ship = destroyer, do not let player in Novice".. we're back to more efficient meta checks based on entity (ship) class.

In regards to the flag, I understand why that may seem faster but here's the issue:

There's still inherent overhead associated with this since it's on a per module basis. Now instead of doing the check while applicable (on activation of the gate) the check that needs to set the flag needs to happen on any high/low slot a player fits/unfits unless the flag is already set. So each time a player adds/drops a mod the check needs to happen. If we wait till the player closes the fitting screen than we're back to the full iteration over modules to set/unset the flag.

This also needs to happen across all ships currently being fit across the server since the game has no way of knowing which ships are going into FW space at any point in time (since this is a flag that needs to be set prior to gate activation).

We have the flag set, using more resources to set than before. We have an additional check at the gate/button to check this flag, although the gate check is now faster.

So -

1.) To set the flag we need to check all ships currently subject to fitting anytime a high or low slot mod is fit, server wide, on most if not all ship classes. We can save some overhead by not checking ships who have a current flag set when a module is FIT.

2.) We then need to check the flag when a ship enters a plex - this makes the gate check faster, but we've already spent the initial overhead in step 1, and probably used many more resources since we're now checking all ships across the server that are being fitted instead of just ships who are trying to enter a plex. (This is because you can't code for player spontaneity)

We could argue that maybe having the initial check take place on the first gate activation after a refit would free up some resources. I'm sure the fitting database has a change date column on it so logic could be developed to say "set the flag on the first activation after a fitting change, then just check the flag". That way we're only checking ships trying to get into gates, and then only doing an expensive check once per fitting, falling back to the flag after the initial activation. If a player swaps out a mod that flag gets reset and the expensive check happens on the next gate activation.

Even better we could potentially skip checking on every module if we place the logic related to setting the flag on the cloack/stab modules themselves. If a module can send a message to the ship telling it to set it's flag to N we reduce the overhead only to ships that have a stab/cloak module fit, which is approaching what you described. The module would also have to alert the ship when it's been removed in this scenario, which would get tricky... we'd need an onUnfit() or onRemove() event. This approach assumes that logic is even possible in this engine.

What I'm trying to get at is that even setting a flag is expensive because you're placing eligibility on the micro module level and not something more meta level like ship class. Even if overhead is not occurring at a particular point in time, those resources still get spent, and it's probably not worth the CPU cycles to go the micro route instead of using an easier check such as ship class.

double the rats in o-plex site with each tier level increase. eg. at T1, 1 rat spawns at once, at T4, four rats spawn at once. soloers and farmers would still be able to d-plex and o-plex at lower tiers but in higher tiers it would prevent farmer toons from having any impact on warzone control. seems more easily doable than creating new mechanisms to address cloaks and WCS specifically, which are only a problem in the first place because farmers are abusing them when the tier is high.