So just looking at the issue of transferring fleets around the cluster using cynosural travel rather than star gates, the simple issue is that cynosural travel will take you too far too quickly. There are few strategic or tactical decisions to be made: get a cyno alt into the destination system (or pay someone to get you there), light the cyno, and moments later the fleet has travelled 7 light years bypassing a dozen star gates.
Strategy and Tactics
Cynosural travel should involve strategic and tactical decisions. Cynosural travel should not be useful for tactical deployment such as dropping a capital fleet on top of a bunch of ratting battleships (i.e.: "hot drops"). The ratters deserve to have some indication of what is coming: if only to add to the trepidation as they sit there warp scrambled and neuted by the scouting party. There should also be some amount of time in which reinforcements can be called, or attempts can be made to run away before the avalanche of capital mayhem descends upon the grid.In my opinion, there should be two time restrictions to Cyno travel: one based on a beacon being lit and warmed up (i.e.: there should be a lead-time associated), then the engines of the ships performing the jump or bridge should require spooling up: first the jumping fleet needs to wait until the beacon is bright enough for their ship to lock onto, then they need to activate their jump drives and wait for the process of ripping a cynosural hole through space-time to complete (i.e.: there should be a processing time dependent on ship size, character skills, and ship modifications). Once a jump is initiated, it should not be possible to abort it without destroying the beacon or the jumping ship.
There should be mechanisms in place to improve the range and reduce the spool up time of jump drives: for example, a staging POS might have a special structure fitted which reduces the cynosural noise of a particular region of space (i.e.: the grid around the station), allowing ships in that space to lock on to a cynosural beacon sooner. That tower might opt instead to fit a cynosural agitator, which increases cyno lock-on time but reduces jump drive spooling time (and jump bridge recovery time along with that).
A Grid Has Cynosural Noise
Which leads me to define the idea of cynosural noise. Every “grid” will have its own cynosural noise level. This noise level represents a state of cynosural agitation of that grid, something akin to the vibration of a bell or the heat of a body of water. This cynosural noise will be increased any time cynosural activity takes place (lighting a beacon, jumping or bridging onto or from that grid), and the noise level will be raised steadily over time by the presence of special purpose devices such as cynosural agitators, but reduced over time by the presence of cynosural dampers.When performing a jump or bridge, the game mechanic must take into account the local and remote grid. The local grid is the grid where ships are jumping from, the remote grid is where ships are jumping to (that is, local and remote are from the perspective of the jump drive, not the cyno beacon). The cynosural noise level will determine how long it takes jump drives or bridges to lock onto a cynosural beacon, as well as impact upon the recovery rate of bridges — the noise level of source and destination grids will both negatively impact on cynosural lock time while bridge recovery rate will be negatively impacted by the noise level of the destination grid, but positively impacted by the noise level of the source (i.e.: it's easier to bridge a fleet from a noisier grid to a quieter grid than any other scenario).
Imagine the cynosural space of a particular grid being like a bell. At some point in time that bell is quiet. Then someone lights a cyno beacon: they have tuned that bell and the bell has started ringing in a clear tone. The jump drives of other ships in the fleet will hone in on the sound of that bell ringing. Then when they jump to the grid they, too, ring the bell. But the jump drives don't ring the bell cleanly: they stir the bell with their own tones and induce discordant tones that start to obfuscate the cyno beacon's clear ring. Cyno dampers are effectively dampers that slow down the ringing of that bell. On one hand, the more a bell is ringing the easier it is for something on the surface of the bell to leave it. On the other hand, the more a bell is ringing the harder it is for something to see the surface of the bell in order to land there.
Regular cyno generators produce such a loud and clear ringing that anyone can lock on to that tone as long as they are aware of what tone to listen for. Typically, the listener would be in fleet with the sender and the “frequency” would be dialled in. It is possible to scan these “frequencies” to find the cynosural beacon of someone who is not in your fleet of course. This is why cynosural field beacons will show up in the overview of systems where a cynosural field scanner and fluidic router relay are available: the scanner is constantly looking for cynosural fields produced within this system and the fluidic router relay is used to communicate tactical information to all ships connected to it. In the meantime, covert cynosural field generators use advanced technology (similar to spread spectrum frequency hopping radio encryption) to produce a ringing of the cynosural field that is only detectable by those who know that secret ring pattern.
Covert cyno generators use a slightly different technique for producing the lock-on tone, which cannot be jammed. Covert cynos will still be subject to the constraints of local cyno noise, i.e.: lock-on times and covert cyno bridge recovery time will be impacted by local and remote noise. The difference in technology is best described as the difference between GSM (time domain multiplexing) and CDMA (spread spectrum, frequency hopping). Lore-style technobabble aside, the impact will be that covert cynos will lock faster and recover faster, so you'll be able to get a squad of 12 recons through a covert bridge faster than 12 HACs through a regular cyno, from the same source grid to the same destination grid.
Bridges should involve an initial spoolup time and an extra period of time to compensate for the mass of ships using the jump bridge. Thus a fleet might choose to wait a longer time before sending any ships through in order for an “anchor” ship such as a heavily buffered battleship to bridge first, then send in a swarm of logistics frigates and cruisers to buy time for the next battleship to jump through. Alternately, the fleet might send through a swarm of interceptors and logistics frigates in order to lock down some high value targets as soon as bridging is possible, which will then hold the enemy fleet long enough for the battleships to enter the field. Ships opening up a bridge should be required to "fall through" the bridge when that bridge is being closed.
The jump bridge stability might be indicated to pilots on field through a “thermometer” gauge displayed alongside the bridging ship in their UI: thus as a swarm of frigates passes through, the stability might be impacted by a few percent. As a battleship activates the bridge, we'll see the “thermometer” dip by 50-80%, then recover slowly. Further ships will be unable to use the bridge until it has recovered sufficiently for that ship's mass to be accommodated. The recovery rate will be positively impacted by local grid noise, but negatively impacted by destination grid noise (the difference in agitation levels impacts the rate of cynosural flow). Jumps and bridges over longer ranges will have an increased impact on bridge stability and local cynosural noise.
The consequence of cynosural noise is that bridging or jumping to a noisy grid will take longer as more ships are bridged or jumped onto that grid: the "thermometer" will take longer to rise. The attacking fleet might decide to jump in a large number of capital ships as a form of denial: making the grid particularly noisy means the enemy will not be able to reinforce with capital ships quickly. The enemy might jump their capitals off-grid then warp on-grid, but that will be subject to warp bubbles.
Cynosural Adjustments
Left to itself, the cynosural noise of a particular grid will tend towards zero as the energy of agitation is leaked out through the cynosural equivalents of radiation and conduction. Typically, cynosural noise decays with a half life of about six hours. Infrastructure upgrades are available which will increase cynosural noise through an entire system (Cynosural Jammers), but also reduce cynosural noise in a particular location (Cynosural Quiescence Enhancers), or provide static Cynosural beacons (Cynosural Beacons on POSes). Thus the sovereign of a system can effectively dictate where regular cyno travel is possible within systems they control.These POS structures and supercapital fittings would perform functions with cynosural travel & noise similar to sensor and weapon modules: enhance the “signature resolution” of a jump drive or bridge, enhance the “rate of fire”, or enhance the “optimal range”. Supercapitals will be able to fit modules (high slots? rigs?) which emulate the effects of cyno related POS structures and IHUB upgrades.
It may be possible, for example, to agitate a grid to the point that even a quiescence-enhanced Titan will take an hour to lock on to a cynosural beacon. The compensation for this is that the POS jump bridge on that grid will be able to bridge a decent fleet of battleships in a couple of minutes (assuming fuel is available).
Wing Clipping
One of the essential aspects of a rebalancing of cynosural travel will be to clip the wings of these cynosural-capable birds. At present, the jump range of most capital ships is such that shipping freighters full of material from Jita to the fringe of nullsec is a routine operation.I would reduce the maximum range of a cynosural jump to about the same as currently enjoyed by black ops battleships. This is simply to help control the mobility of capital fleets.
Thus ends my ranting on cynosural travel. Have at thee!
This comment has been removed by the author.
ReplyDeleteMarlona Sky has an interesting proposal, flipping the problem around to focus on the character rather than the equipment: Cancers of EVE Online: Teleportation.
ReplyDelete