Player Features and Ideas Discussion

Hi Ranger, I agree with your logic, anything that gets black ops on the field more is great. Can you think of a way to fit that into the "squad range" vs. "wing range" vs. "fleet range" mechanic?

I guess one alternative is to make it a pure numbers check. The only thing with that is potentially you get this cluster **** situation where 249 peeps are all trying to tether to the say the same carrier or super-carrier and having to re-try when they get rejected. It's not that big a deal, especially if the tether range is 10 or even 15km from the ship. It's likely that you'd just clump the tether-jumpers up and have the fleet orbit the jumpers at say 5km, then you can reach any tether-jumper pretty quickly.

Yeah, it kind of all depends on if that aspect of the mechanic ends up being as proposed or not. They could base things off of mass (like a wormhole) or a certain number based on ship class (1 BS = 2 cruisers = 4 destroyers = 8 frigates... or any combination of the above up to the total amount your ship is rated for), or any number of other ways.

However it goes it would be fairly transparent to the fleet members. They simply try to tether, and are either successful or not and are notified of such.

To the members of this thread in general, ease of power projection is a big issue in EVE. Things need to be toned down a bit. As counter intuitive as it may seem, making fleet movements more difficult would actually inspire more serious conflicts in EVE, because if you are going to move major assets into battle you will now need to be serious about it. Less "play fighting" and more "serious business"... not to mention encouraging folks to actually occupy the area's they control. If you aren't in the right position for defense, you may not be able to move those large defensive fleets into position nearly as easily as you can today. You could easily find your capital assets and support fleet fighting a desperate holding action until the bulk of your reinforcements arrive via conventional gate travel.

Easy fleet movements trivialize combat, whether by making their normal staging areas unimportant, or making the ability to effectively engage (and far more importantly, the ability to retreat at will) far too easy.

Your decisions should matter, and have potentially serious consequences. Likewise cynoing in a fleet should have advantages (as they do now) but also draw backs that need to be considered.

Except that if this were done (hopefully in conjunction with a similar revamp of jump bridge mechanics) it would make defense more difficult as well.

Currently it is a trivial matter to cyno in a large defense fleet without the need of even risking your capital assets.

So yeah, if you don't also nerf jump bridges into the ground then iis massively overpowered for the defender, they can reinforce easily with 0 risk. GG, you've just made null even more stagnant.

And how do you do a similar jump bridge revamp? make the tower also jump to dest? it's such a terrible idea to a non-problem.

That's a good criticism. Perhaps you could address it by making a jump bridge a weak enough target that a moderate sized gang can quickly incap one (say ~15-20k aggregate DPS incaps in 5 minutes). Then a roaming gang could snap the link allowing time for a fleet to start a siege.

A side effect of that would be you've just created roaming gang small scale hit and run objectives too.

It sounds quite awesome, but it would need different titans and possibly some timers to prevent people from going step A: get an iteron and an auguror so you can tehter-jump in, get recharged, jump out again - before they even know what happened.

This is great:
'jump squad/wing/fleet'
That does sound awesome.



I believe that it was intended to say: 'The signature AND mass are influencing the jump costs in a way that roughly equalizes the sideeffects of tank-modules'

A couple points:

One of the major "discussions" about nullsec is force projection. The ability to rapidly move a force across several regions of space makes controlling several regions much simpler. This change would pretty much expand the force projection tools (primarily found in jump bridges and titan bridges) to any Joe Plumber with a carrier. People complain about hot dropping now... imagine how this changes when you can do it so much easier. Additionally, with the obnoxiously large structure HP and the RF timer mechanics, I fear this change would enhance force projection to become a major problem.

Now, your drawback, of putting the blingy ship in a "risky" situation is nice, and helps offset the increased force projection... a little. The truth is though, and this is especially true in lowsec, holding down a supercap can be quite a challenge. And you probably don't know this, but you can cap fit a carrier to passively recharge enough cap to jump out before it's invulnerability timer (from jumping in) expires, making them invulnerable lowsec hotdrop logistics.

Next, there is the issue of range. A titan can jump 3.5 ly base (*2.25 w/ skills). A BO BS has similarly limited range. A Carrier has a 6.5 ly base, and can hit beyond 14.5 LY with skills. Those number might not mean much to you, but the range of a carrier is huge. A titan in the middle of Venal is going to reach all of venal, and some of the systems in the neighboring regions of Branch, Deklein, and Tribute. Put a carrier in that spot, it will hit moreless all of Venal, Deklein, Tribute, and Brach, as well as some systems in those neighboring regions of Pure Blind, Vale, Tenal, Fade, and Lonetrek. Frankly, that's simply waaaayyyyy to much range to bridge ships, even if it is only 9 ships!

Interesting objection. I don't think it's really useful to dismiss the idea based on an assumption that it's going to be buggy. We have to assume that the ideas we have will be implemented without bugs or else we can always just say, "no, what if bugs?"

Except I'm using a currently existing bug in the most analogous system in place (I bet it would use much of the same code). Given that the bug hasn't been fixed in quite a while it's surely buried in ~legacy code~ that can't be touched. Until it's demonstrated that the current system is reliable, introducing a separate system (which would likely share some code) that adds even larger problems when it fails isn't a good idea.