Backgrounding…

Sorry, no post today.

I'm working on part 4 of the Canned Heroes series, which should be ready within a day or two at most.

***

Stay tuned.

Canned Heroes (part 3)

[Continued from part 2]

Understanding backup clones.

The four major changes in cloning 2.0 relative to medical/backup clones are:

• You can no longer remotely spawn your medical clone in any station you've ever visited or your corp has an office in. To install a medical clone, you need at least proper standings with the medical facility owners (1.0 with most NPC corps), and to bring a CryoCanned clone on location.
  
  
• Backup/medical clone are no longer different in nature from jump/generic clones. Any installed clone can potentially act as a backup clone by being bound to the character's mind-backup contract.
  
  
• Backup clone contracts are now subject to a weekly fee proportional to the grade of your backup clone contract (about 1% base price) without which you'll enjoy only a reduced protection against skill point loss in case of podding — backup clone upgrades become less expensive, though.
  
  
• The potential loss of skill points on death without sufficient coverage is much harsher than it used to be — this is partly eased by new ways to help ensure your backup clone protection remains sufficient at all times.

Canned Heroes (part 2)

[Continued from part 1]

Generic clones vs Backup clones.

All clones are grown generic, and are exact replicas of their original at the time of cloning.

Whether a given clone is upgraded to the status of 'backup' clone depends solely on the arrangement between the pod-pilot and a specific medical facility to be the default recipient of the pilot's ultimate mind-scan after a freaky pod malfunction.

• A 'blank' clone is a frozen clone (with or without implants), stored in a CryoCan or Pod.
  
  
• A 'generic' clone (a.k.a Jump clone) is a 'blank' clone hooked up to a medical facility, ready to be thawed out on short notice.
  
  
• A 'backup' clone (a.k.a Medical clone) is a 'generic' clone hooked up to a medical facility with whom owners the pod pilot has subscribed a 'backup' contract in the event of his death.
  

To prevent contestations over which medical facility claims the (often hefty) rebirthing fee, and the legal nightmarish complications of multiple freshly activated clones all claiming to be the legitimate 'self' concurrently, pilots are allowed only one such 'backup' contract with a unique station's medical facility at any one time — medical facilities on supercapital ships being a recent and largely outlaw-ish development fall in a grey area.

As long as the uniqueness of a pilot's body-mind association is maintained, the law sees no issue with keeping more than one spare clone handy:

• Pod pilots are allowed to grow and store in CryoCans an unlimited amount of 'blank' generic clones.
  
  
• Pod pilots are allowed to have a total of up to 6 ready-to-roll clones, including both 'generic' and 'backup' clones (based on Infomorph Psychology skill level).
  
  
• Pod pilots are allowed a single 'backup' clone subscription with station-bound medical facilities at any one time.

Canned Heroes

[Editor's note: Wow, the wall'o'txt struck back, so I added a short version as intro, then you can dig in if you feel like more.]

Teh Skinny:

• Clones become actual bodies (like corpses, but slightly less dead), which you can move around in coffins cryostatis containers. They are grown-on-demand in medical facilities for about 10% of the price of a matching medical clone, and it takes time to bake one (about a day).
  
  
• MedClones and JumpClones are no longer different animals: a 'backup' clone is a regular clone that you bind to your brain-insurance.
  
  
• Medical/backup clones can now be bound to Clone Vat Bay-capable ships, potentially turning those into your respawn point as long as they are in space, Clone Vat Bay active, and you have enough fresh clones in their medical bay.
  
  
• Medical/backup clone contracts are now billed to you on a weekly basis, to the tune of roughly 1% of your medical clone grade price.
  
  
• New death penalty for the uncaring: stuck in limbo !
  
  
• You get to play in new and creative ways with your body(ies) — other people too.

See below for the non reading-averse version.

Real-time tactics

Here be everything about Tactical Maps, and general improvements to the UI and features relative to the management of real-time-tactics aspects of EVE

Everything Real-time Tactics:

• Fleet Dynamics: Why they suck, Part 1 and Part 2
• Fleet Management: because poor fleet management results in retarded tactics.
  
• The nature of PvP in EVE, Part 1 and Part 2.
  
• Intelligence Services: a possible implementation of fog-of-war and real-time intel distribution in TacMaps.
• See also Exegesis (feature).
  

Everything TacMaps

• A flash from the past: Wargames and maps go together like gum and hair, so tightly is their history entangled… except in EVE.
• Tactical Maps: an ongoing series on putting gum in EVE's hair (Part 1, …).
• Strategic overview: reading the territory on the sovereignty map (and CCP's first baby-step in that direction)
  
• CCP is all over it ! (as of 2007, then it fell in a crackpipe, seemingly)

Toll booths

[Editor's note: Well, TQ is dead by now, and the announced dt is to be at best 19h long… I'll go check how EVE looks in a couple days after the inevitable post-patch kinks are worked out.

No big posts until then, I'm afraid, as I'm doing non-EVE stuff in the next two days, unless I find time to spare to go for a full breakdown of the patch notes, which I've read and researched a bit by now, and I must say there is a majority of nice-smelling stuff in there — botched sovereignty mechanics aside.
 
In the meantime, I have this old bit of fodder I exhumed, and  which would fit nicely in the new pet-heavy resident-friendly landscape of Dominion sovereignty system.]

Jump Bridges 

 …are a cool feature,

and one of the few places where holding sovereignty actually makes a difference in the relationship one has to the environment, compared even to cyno-jammers, whose raison d'être is to help defend sovereignty, thus echoing the pre-Dominion circular joke of fuel discount on POSes that are deployed only to hold sov.

Problem.

As interesting as the ability to basically create your own custom gate network may be, jumpbridges are also a royal pain to operate and maintain for their owners.

One of the main grudges logisticians and officers hold against bridges is the lack of control over who can use them: anyone with + standings and the knowledge of a unique shared password per bridge (ergo anyone with + standings, really) can jump through at will as long as the bridge has fuel in the tank.

Which brings us to the second and most frequently sore spot: fueling and attached costs and workload.

Long story short, only members of the alliance owning the POS/bridge can be allowed to top up a bridge fuel tank with Liquid Ozone, but since they have very little control over who can use the bridge, these tend to run out quick. This is made worse by the absence of any logs stored or relayed by the bridge about who jumped through when and in what ship class.

Solution: 

Toll booths.

Without even considering — for now — changing the access management system that rules over bridge use, simply add the option for the bridge to demand fuel before activating.

Either you have enough fuel, or you pay in ISK.

In practical terms, on right-clicking to jump through a bridge, you'll see a dialog pop up with a warning and two quotes, going roughly like this.

Warning: 

This installation needs fuel to displace

your ship through the magic spacetubes.

Do you want to allow this bridge to take Liquid Ozone

from your cargo bay, or do you prefer to pay in cash ?

Liquid Ozone required: {insert number} units

Cash price: {insert number} ISK

[Rape my bay !] [Rape my wallet !]

• If you don't have enough LO or ISK at the ready, the number will be red-colored and the [Rape my…] button will be greyed-out.
  
  
• Assuming you click on either available option while sitting in activation range, your cargo bay or wallet will be syphoned for the required amount of fuel or ISK, and you'll jump through.
  
  
• If both buttons are greyed-out, you can't jump until you beg somebody for ISK, or get enough Liquid Ozone in your cargo bay.

The base ISK price per Liquid Ozone unit should be defined on a per-bridge basis, and a profit margin could discretionarily be added at the POS owners discretion, to compute the quote from ActualFuelRequirements+Margin(%).

Standings and alliance affiliation could be used to compute a discount or mitigate the overtax, much like is done on Outposts' station services.

Simple way to limit abuse of bridges, stop them from running dry, and maybe even make a buck on them to recoup the operation costs.

ttfn,

Happy expansion all !

***

Soft hat on.

No filler today, I'll be busy watching clouds.

If you have nothing better to do, go read the patch notes for Dominion, that should keep you awake at night until the expansion hits the fan.

See you after the bang.

DevBlog #718 — New EVEmail in Dominion

This a Dev Blog, about EVEmail finally becoming usable. That's pretty much it.

OK, ok: that's a big deal, for we're coming a long way on this one. So here's the skinny:

The new EVEmail, barring overlooked bugs, will do what you'd have expected it to do from about day one of EVE, but not just that.

Through linking to API and client-side storage, it will make EVEmails, mail alerts and mailing lists a convenient enough exchange medium that we may actually use them.

It's like getting tap water versus a crank-and-bucket well  in the backyard: it's only a few paces closer to home, but that's a huge difference.

So, all together: Yay for new EVEmail !

***

Drone herding

Droonies are the reason many a EVE player has found himself mumbling in his sleep or waking up in cold sweats, as they're probably the most fickle, hard to balance and messy factor in EVE combat, ever since mines and missile splash damage have been removed from the game.

Fighters epitomize the drone problem. They cost an arm, or at least a good cruiser worth of ISK and minerals, deal and soak about as much damage as a NPC cruiser, and have the AI of a 1980 digital alarm clock for brains, and yet, they're overpowered.

At the heart of the issue lies the fact a single pilot finds himself in command of a disproportionate total sum of firepower, not because drones are 'too good' as such, but because the drone paradigm has been 'One Ring nerd to bring them all and in the darkness bind them' since the beginnings of EVE.

This mixes badly with the nature and mythos behind Carriers and Motherships which call for the ability to deploy not one or two lonely drones, no matter how tough and full of teeth they are, but swarms of them.

Judgement day, or something.

This is it: the Dominion expansion page is up, and the official deployment news, too.

Not that's it a big surprise, obviously, but I'm curious about what will really make it through the initial release, or be held back at last minute, and you certainly can't trust the features page for that, since half the dev blogs linked there are obsolete already.

My plans ? I'm checking out the NPC sovereignty pockets in otherwise conquerable 0.0 regions, and I'm prepping to go all UO on the simpletons that will throw ISK at upgrading their space. EVE is taking a turn for the stupidest, and I shall embrace it as long as I bother to log in.

Enjoy your last weekend of pre-arena EVE, folks: you'll want to hang on to the memories.

Supercapitals overhaul

[Editor's note: I'm going to try a new format today: I'm sparing you the usual wall'o'txt by boiling down this entry to the key changes… The important details you'll either have to trust are covered, ask about, or wait for followup entries to address.

That saves you headaches, and leaves me with stock material for next time I run dry on inspiration for the daily filler.]

Problem:

Titans and Motherships are sexy on paper, everybody can see the shine of supercapital vessels in a space-op' — they're a standard feature of the genre.

Unfortunately CCP released those with nothing but very nice art to support their existence, and have since then been groping around like eggnog-plastered tweens haphazardly trying to reach second base during the carols on Xmas eve. The results have been predictably messy and embarrassing for all involved.

Defining Supercapitals:

To begin with, they must be huge: that's a given.

Part of being super is they must be rare, different, and exotic compared to more pedestrian merely-capital boats.

They are intended as GiantDicks, flagships for the pride of their fleet.

Flagships.

By nature, a flagship is a morale booster, a spectacular display of your fleet's confidence in its might, and a frightening wonder for the enemy to behold and quiver before. They should also, as the crown of the enemy's military might, be what your own admirals and fleet commanders look forward to topple, sending the signal to the troops under their fallen standard that this battle is lost to them.

Because there are, to date, only two classes of SuperCapitals, with no new ones in sight, it isn't too much to ask that each get their own unique-yet-complementary flavor, and aren't just large-and-superlarge variations on the same design, or on 'regular' capitals.

Another requisite of flagships is that they must make a difference in the battlefield, beyond just being ostentatiously large, yet must not put other ship classes out of a job by doing the same-stuff-only-more that non-super boats do.

Solution:

Titans and Motherships must certainly help win battles, but not as main weapons. They will act as enablers to support conventional and capital vessels, and help make a better use of fleet ships.

Repair systems overhaul.

I know there are a lot of things in EVE gameverse that fail the basic common sense test, and I can live at peace with lore and backstory inconsistencies in a game where the most interesting stories are those the players write through their actions, rather than by roleplaying on a script. Some design misses however are enough to damage the gameplay, in addition to their being ridiculous.

Problem(s):

…arise when major game mechanics simply fail internal consistency tests, and Repair systems are among the worst offenders.

If cheap tech 1 modules can readily convert energy from ships' capacitors into engineered matter (to remotely or locally repair structural damage suffered by armor and hull), and can restore a ship integrity without any source of raw materials, not only are we far past the point where technology is indistinguishable from magic (which could be OK), but one must wonder why industry still needs to bother with any raw materials, when ship reactors provide a readily-available, seemingly infinite and everlasting supply of energy-and-thus-matter at low cost.

Plainly said: magick matter-generators are cause for serious cognitive dissonance in the face of the need to mine asteroids.

Solution:

…already there: it's called nanite paste, a NPC repairing material source, and a very nice ISK sink that can be reused in a myriad of interesting ways.

The action figure gap.

Through all the sources I skim/surf/browse/read on a daily basis about R-POWs and the making thereof, there is a constant divide I couldn't help but notice: any given writer, critic, academic, pontificating game designer or wannabee will refer to EVE-Online either very frequently or absolutely never.

I'm not talking about reviews of Marshmallow Cluedo Online™, the puzzle game, here. My eye is on bona fide MMO design discussion platforms, where you can read massive articles and opinion pieces about issues such as player-driven economy, dual-currency systems, or large scale PvP warfare without so much as a passing wink at EVE.

Conversely, many EVE-centric sites — and not just the fanboyish ones — will ignore a large selection of fairly well-known and significant titles when doing comparative analysis of features across MMO*.

At first, I chalked that on the widely shared preconception that PvE-oriented players and hardcore PvP nerds don't mix unless forced to, and plainly said, on the notion that each consider the other group as an aberration of nature not fit to mention in polite company.

But as even the blogs from well-know advocates of hardcore PvP in MMO*, famous for their massive rants in favor of unforgiving games that give players something chewy to bite on, manage to simply leave EVE out of the picture 99% of the time*, I must admit I got stumped for a while…

Then it hit me…

It's the avatar, stupid !

The great divide is not between hardcore PvP sandboxes and theme-parks railed rides, it's between men-in-tights and mechazoids. Some people will simply not acknowledge as part of the same ecosystem worlds where you run around with an action figure representation of your in-game self, and those where your game presence is embodied in a spaceship, giant mecha, or race car.

I'm not sure what it says about the meandering and crafty ways of immersion in game worlds, just yet, but I'm willing to bet the introduction of ragdolls in EVE online will make it more relatable overnight for the fraction of game designers and critics who up to then couldn't see it as a proper MMO*.

***

[* Yes, that's a grand total of 7 results on a search for "EVE Online" in entries between 2004 and now on Psychochild's blog, I'm not making this up…]

EVE is broken, yet…

With me being back in the proverbial armchair and buttocks-deep into game design again, I've come to remember how grateful I've been over the years for the very existence of EVE, and how I still should remain grateful for it to this day.

Sure, EVE has it wrong on a grocery list of levels, the gameplay is terrible (at least relative to its stated ambitions), the community is an embarrassment of Palin-esque proportions for the human species, and the public faces of CCP, through its developers and PR mouthpieces don't do much to help it, yet…

My perpetual concern that the failings of CCP are somehow poisoning the well for future PvP sandbox MMO* aside, EVE has one great feat going for itself and the genre: it exists, and is alive, profitable and steadily growing 6 years after public release — and that has to count for something.

Whenever one gets into a discussion about the viability of design concepts tied to the whole sandbox-PvP thing, EVE provides the likes of me with a simple point-and-smirk, one-click rebuttal to the boilerplate argument that 'PvP games are doomed to fail, period'.

So…

My heartfelt thanks to the people @CCP for making, running, maintaining this game. For being a bunch of clueless monkeys and overall asshats griefer frattards, you're still family. Despite everything, you're the living proof we don't belong in museums just yet — we just are a bit slow to evolve.

With love,

AcD.

Late to the party ?

A friend pointed me to this, which somehow had escaped my attention until now — thanks, B.

It's basically a starting EVE-like game, only with mechas, and on the ground, done by a Hungarian team.

This looks interesting, if only because it offers another, and fresh perspective on the same defining elements as EVE, which very few games have really tried to tackle, to date.

Also… mechas !

On a bright note, compared to EVE's, Perpetuum's gameverse and backstory make perfectly good sense, and earnestly avoid some of the most ridiculous non sequiturs clichés of space op'.

Not that it matters so much in a pew-pew game, but there's always that.

On the downside, the character's portraits should not be gazed upon if you have a weak stomach… they are uncannily (and not on purpose I suspect) disturbing.

***

Will Perpetuum make it ? I don't think so, unless it gets a massive injection of capital and/or talent to help it reach critical mass and differentiate from what is comparatively the 800 pound gorilla in that small niche.

WTF!?

Before you go all internet lawyery on those guys for the blatant ripoff of your favorite intarweb spaceship game, read this first, take a walk around the block breathing through your nose a  few times,  then go check your game design history (about UO and BattleMechs/Tech, notably) to get some perspective on how much of EVE is truly unique, original IP.

***

DevBlog #717 — Capital ships in Dominion.

Let's be fair, one can't bash CCP for coming up with utterly stupid designs they bullheadedly rush towards Tranquility, and not salute the comparatively sensible decision to put a pin in at least some of it, and go back to the drawing board.

So… watch me while I laud CCP Nozh for his feat of un-retardedness in Dev Blogging.

Yes, the very good news is: broken Motherships will not be replacing Apocrypha-era Titans as the WTFsoloPWNmachine 2.0 of Dominion (although there's a good chance they'll still be re-christened SuperCarriers, for the LULz).

The other good-looking news is: the re-balancing of  XL weapons seems sensible, at least on paper — Minnie dreads with their dual weaponry will probably remain slightly behind the DPS curve compared to their peers when sieged (although even that remains to be seen in the light of late/post-release fixes), but they enjoy a slight advantage in flexibility, compared at least to Amarr, when engaging moving targets.

Finally, Titans figure how to use those XLs gun slots that until now were shelved in favor of utility modules, with a hefty enough damage multiplier to warrant locking non-blues. Combined with the new death-ray superweapons replacing Doomsday devices, this turns titans into extremely expensive yet not entirely pointless gunboats with logistical superpowers, which isn't so bad a placeholder to wait until they get re-written for good, hopefully (optimist hat on).

***

Droonies

Hello y'all… my name is Largely Irrelevant, and I am a pet-lover.

Phew… that sure feels good.

Ever since my early days in MU* and P&P RPGs, and through my time in CRPGs and MMO*, I've kept a fond spot for the critters.

Pets make for for cool player-toys and handy roleplay props, while GMs and writers can use them as crafty devices to steer back players on course in much less anvilicious ways than the insufferable NPC-in-party would allow.

[Featured articles linked at the end of this post]

Pets rock !

The appeal of semi-autonomous tools/toys/weapons/sidekicks is both obvious and subtle: pets extend the player's character reach, enable to probe and explore otherwise inaccessible or overly dangerous areas, and often are the ace up one's sleeve in combat, but just as importantly — if done right — they connect player characters to the environment and gameverse.

Pets are half-player, half-NPC by nature, and as such they can convey information and immersive clues a PC hardly could — without robbing the players from control over their in-game self, at least in part.

A pet can sense danger and refuse to advance further down a path way before players can spot the enemy, or rush for a waterhole after a long hike through desert terrain, leading you to feel your own character parched lips for a second… the list is endless.

They can also go horribly wrong in the blink of an eye if not kept on a short leash…

See what I did here ?

Moving on.

In computer games, and especially MMO*, pets have fantastic potential, but also open a huge can of worms, the kind that makes balancing PvP between ranged and melee characters look like a 'tie your shoes with your eyes open' sort of dare.

How pets are gained, lost, raised, healed, developed over time, their philosophical nature and the mathematical minutiae of their handling, all are nightmare fuel for designers and coders.

Make the pets too good, and their master player character soon vanishes behind its limited role as a remote-control interface for a CritterOfDoom™. Make the pet suck, and you'll see no end to the whine of people whose class is otherwise gimped to balance for a useless feat.

In short, pets in computer games, MMO especially, tend to file under awesome but impractical, and thus are often relegated to the vanity trinkets category, much like an epic mount that couldn't run and is afraid of crossing shallow creeks.

Droonies…

In EVE, believable pets are an exclusive of major 0.0 alliances, and mostly played in the metagame space. The closest to familiar critters we get would be with drones, the no-name, brain-damaged, cannon-fodder-lag-generating scourge of EVE.

Because I'm such a pet-lover, I still like drones quite a bit. In fact, my oldest EVE toon is/was a drone specialist, thanks to a happy coincidence of me rolling the toon based on the comical racial description for Intaki, and ending up with ridiculously high memory. Being a roleplayer and all, I figured it was a sign, and made my way to lvl 5 on every drone skill available over the years.

…are vermin.

Even though they're about the simplest form of pet one can imagine, EVE drones share many of the qualities and liabilities of their kind: mainly, they clog the server pipes while failing repeatedly to do what they're supposed to.

Meanwhile, they steal player jobs by filling roles suited for light ships, and easily eat enough processor cycles and bandwidth to support another session or two, but to the difference of a player multi-boxing, they don't bring another subscription revenue in the coffers to make up for it.

Why CCP bothers with them at all would be a mystery, if not for the aforementioned fact that pets (and thus drones) are inherently desirable and cool — end of story.

Making a niche for droonies.

For all their misfortunes, drones are a long standing feature of the EVE arsenal, and they even are a defining element for one of the 4 main racial playstyles. Entire classes of ships, not just Gallente, and ranging from frigates to SuperCarriers™ are built around the purpose of carrying and deploying drones.

Although the entire drone interface and control scheme is in dire need of a serious makeover, the worst issues with drones are found on the side of capital and supercapital ships built as drone-boats, namely Carriers and SuperCarriers.

Defining the exact role of those ships and balancing them has always been problematic: being drone-centric, they are automatically gimped or overpowered in direct proportion to the drones they pack, and the most obvious ways to make drones useful overlap with roles that coulda-oughta-shoulda been filled by player pilots.

Articles.

In the posts linked below, you'll find proposals to make a niche for droonies and drone boats (of capital and regular size), and to improve both the gameplay and relevance of drone-shepherds in ways that don't put frigates and cruisers pilots out of employment.

***

Everything Droonies: all the articles tagged as Droonies-related, to date.

• Drone Herding: a first look at drone management overhaul.
• Supercapitals Overhaul: Introducing new support Fighter types (Mothership section)
• Repair Systems Overhaul: a glimpse at revamped Logistics Drones.

DevBlog #714 — dominion upkeep and upgrades

Catching up on Dev Blogs, I found the mouth for Dominion's sovereignty overhaul has spoken again, although no cute flowcharts this time…

After the giant whinethread, the Upkeep costs have suffered a big hit of the nerfbat, in addition to a healthy boost granted to the weakest type of PvE upgrade (more mini-plexes spawns) both of which were obviously things to do, and arguably the right reaction (although it's still pouring fresh water down a leaking barrel, design-wise).

A welcome — if overdue — change is the announced reduced price of tier 2-3 upgrades for Outposts: the tier 3 are currently so stupidly pricey that spawning another tier 2-upgraded outpost is actually running cheaper than upgrading from tier 2 to tier 3, limiting the instances of tier 3 upgrades to a count of roughly 0 to date. Only question being: who'd want to sink more ISK in high end outposts when they basically can't be defensible anymore ?

Other changes are less enlightened: the halving of the online time of SBUs (from 6 to 3 hours) is not so bad, as it hastes a bit the pace of Stargate contests, but the reduction on the random factor variation applied to reinforcement timers (for Outposts and HUBs) fosters blobbery even more than before.

Where CCP designs smarts really shine however, is with the "Usage indices": now decoupled from the actual Infrastructure Upgrades that support the boosts on PvE/industry resources.

The intended goal of this significant change to the model is to allow the conquerors of a well-developed solar system to be able to readily deploy their own Infrastructure HUB and PvE upgrades to replace those they've just destroyed, as the Usage Indices that determine which PvE/Industry upgrades can be installed/onlined will persist for a little while (couple days at most) after the previous landlords's HUB has been wiped out.

This is… wait for it… awesome ! Broken™ !

As I pointed in my very first look at Dominion's planned overhaul of sovereignty benefits:

Interestingly, assuming CCP goes for the option of not allowing capture of the 'Upgrade center' and instead decides to have it go poof on sovereignty shift, it may be more interesting for an invader to entirely ignore sovereignty and be content to focus on seizing outposts, leaving for the defender to pay Upkeep bills while the attackers milk the juicy NPCs and roids attracted by the now-homeless defenders' system upgrades.

Unless I missed something, this approach would remain entirely viable in this last revision.

Although the invaders have to somewhat 'suspend' sovereignty immunities in order to seize an Outpost (by spamming SBUs on 51% of the gates long enough for the Outposts to be captured) there is no indication (from the published Dev Blogs) this would magically destroy or disable the Defender's TCU or Infrastructure HUB permanently, until they actually get shot at.

There's a giant and obvious loophole here: it looks like it's perfectly practical to invade en masse, scare the lemmings away by stealing their outposts, but leave sovereignty and HUB alone, then for the squatters-conquerors to reap the benefits of the upgraded space at zero cost, while leaving for the evicted faction to pick up the tab of Upkeep Costs… Or did I miss something ?

Yes, I know there's this line in Seleene's previous Dev Blog:

Sovereignty is a requirement to have an Infrastructure Hub and it is not be possible to have a scenario where a system has an Infrastructure Hub and no sovereignty.

But unless the actual game mechanics support Abathur's statement, it's about as imperative and effective as asking ore-stealers to "Leave my cans alone !".

Assuming I fail reading comprehension, or it's just something that didn't make it into Dev Blogs, but really is addressed in the ruleset, that still leaves the possibility to invade a system with 800 peeps, not bother with capturing shit (maybe just screw a bit with gates and SBUs for dramatic effect), and mine / rat away at no Upkeep Costs, then head back home (say NPC 0.0 stations nearby).

I'm sure this is CCP's idea of 'dynamic, cerebral sovereignty warfare', and people will just jump at the irresistible opportunity to spend bazillions of ISK developing and maintaining infrastructure for others to (ab)use, when they could more easily go rape the small-alliance neighbours instead — because we know how kindhearted and caring blobbing alliances are.

Quoting myself once again:

Strong defensive and industrial benefits should come from developing high levels of sovereignty and infrastructure, which should incur heavy penalties for local PvE resources.

Keep true-sec as it is, significantly boost base wealth in conquerable null-sec, make loot/spawn tables adjust dynamically (downward) based on local infrastructure, average population, local and surrounding sovereignty 'score' (which conversely boost and enable industry/defense perks), and you have a system that gives the edge to small-medium alliances built on a well-coordinated mix of PvPers and industrialists over sprawling herds of PvE hunter-gatherers, while forcing codependency between both styles, and creating interesting friction areas in the interstitial, richer wild lands.

Funny-in-a-sad way, how easily this doomed race against design cracks could have been avoided by simply having local PvE resources adjust the other way around relative to player sovereignty and infrastructure, but have no fear: slapping patch after patch over leaky pipes is a proven way to make spaceships fly happily forevah.

Madness, baby, madness.

Gaah.

I didn't really fluke yesterday… I was sort of late to begin with — which I saw coming a mile away — then… this happened.

Even the most devious compulsive spacenerds among the five of you shall admit that's enough eye-bleeding content for two dowmtimes, at least ?

*sinks hands in bowl of ice chips*

Commandeering (part 2)

In part 1, I covered the essentials of Commandeering and FoF Tuning mechanics, the various states Of Ownership (Owned, Abandoned) and Tuning (Controlled, Neutralized, Challenged), and delved into some specifics about Ship Commandeering, which the main use most players would have for this feature.

This entry is about understanding how Tuning contests are resolved, complete with some examples of the typical targets for Commandeering. If you haven't read part 1 of Commandeering, now may be a good time, and likewise you may want to have a glance at the FoF Tuners article, or at least keep it handy in case things get too hairy.


Anatomy of a target.

• Tuning Strength Modifier (TSM): It modifies the base NTC (to compute ETC), boosts Passive Tuning Recharge (if available) and increases the output of FoF Tuner modules.
  Defaults to x1.00, can be increased by skills, sovereignty benefits, special rigs and upgrades, etc.
  TSM suffers from no stacking penalties of various sources applying to the same object.
  

All potential targets for Commandeering share a base set of attributes, many of which are subject to TSM.

• Nominal Tuning Charge (NTC): Expressed in Tuning signal points (Ts), it is defined by the item type and can't be modified. NTC is used as base score to compute the ETC below and sets the threshold that must be reached to Challenge or gain Control over an object.
  
  
• Effective Tuning Capacity (ETC): Basically the NTC plus applicable Tuning Strength Modifiers, this is the maximum charge the object can hold while Controlled — default value is equal to NTC.
  Formula: ETC=NTC*TSM
  
  
• Base Passive Tuning Recharge (bPTR): Expressed as n% of the NTC,  with n defined by item type, it is used as base value to compute the PTR below.
  
  
• Passive Tuning Recharge Rate (PTRr or PTR): expressed in % of the object ETC or in absolute Ts/cycle, it indicates how much an object will self-recharge per PTR cycle while between 0.0 Ts and ETC.
  Its value in absolute Tuning Charge output is indirectly modified by Tuning Strength modifiers as they increase the object ETC (constant percentile of a larger quantity), and directly as they increase the % value (higher fraction at constant quantity).
  PTR may be activated or inhibited by the Sovereignty/Ownership/Control status of the object.  
  Formula: PTRr(ETC%)=bPTR*(ETC/NTC)*TSM (or bPTR*TSM^2)
  Formula: PTR(Ts/cycle)=bPTR*ETC*TSM (or bPTR*NTC*TSM^2)
  
  
• Passive Tuning Recharge Cycle (PTRc): expressed in seconds, it is set by the item type and can't be modified.
  PTRc is used to resolve the Control state of an object, in addition to the potential change in Tuning charge from PTR.
  [Note: since PTR(r) is a per-cycle value, PTRc directly affects its Ts/sec output, which is calculated thus: PTR/PTRc=PTR/s]

PTR boost is applied at the beginning of each cycle, while the Control state check of an object and the effect of FoF Tuners apply at the end of their respective cycles. This means if an object reaches its NTC (or is brought to 0.00 Ts) within its cycle, the Control state change will kick in right before the beginning of the next PTR cycle, possibly canceling (or enabling) Passive Tuning Recharge for the new cycle.


Control state changes.

The Control states of an object reflect which (if any) entity currently is in position to use it, and possibly Own it.
There are three possible Control states (Controlled, Neutralized, Challenged), and three potential contest types allowing to transition between Control states.

As can be seen above, it is possible to transition between any two Control states both ways, except between Challenged and Controlled.
Moving from a Challenged state to a Controlled one can be done through a single transition/contest,  but a move from a Controlled state to a Challenged one will require a first transition to a Neutralized state, then another from Neutralized to Challenged.

From a Neutralized state, the current Defender/Owner of the object (if any) may regain Control through a single transition/contest, while a Contender must first tune up the target to its NTC once to Challenge it (which resets the target's tuning charge to 25% NTC), then up again to change its state from Challenged to Controlled for the Challenger's benefit.

Here's the breakdown of transitions:

• Controlled => Neutralized: reduce the target's tuning charge to -0.00 Ts (any party but Controller)
  
  
• Neutralized => Controlled: tune up the target to NTC (Defender/Owner only)
  
  
• Neutralized => Challenged: tune up the target to NTC (current Contender only) — resets the charge to 25% NTC in favor of the new Challenger.
  
  
• Challenged => Neutralized: reduce the target's tuning charge to -0.00 Ts (any party but Challenger)
  
  
• Challenged => Controlled: tune up the target to NTC (Challenger only)

From a practical standpoint, Commandeering a currently foreign-Controlled target requires to feed it roughly 3-4 times its NTC worth of FoF Tuning signal of your frequency (not accounting for PTR, and assuming no active interference from other parties): 1x to 2x NTC to Neutralize it (depending on applicable TSM), then 1x NTC to Challenge it, and finally 0.75x NTC to win the challenge and takeover Control.

For the Defender of an object under attack, successfully tuning the object up to its NTC once while still Controlled or Neutralized will be enough  to regain full Control over it. Once the object is Challenged however, the Defender (if Ownership hasn't been lost already) will first have to change its state back to Neutralized before attempting to re-claim it, typically without the help of PTR (disabled by the Challenged Control state).

Commandeering Targets.

[Editor's note: NTC for many structures are expressed in xDreadnoughts NTC as an indicator. Those are provisional numbers meant to give a rough feel of relative NTCs, and are very much still in the air at this stage.]


Ships

• Vulnerable:
  
  
  • Defender FoF Frequency: always.
    
  • Attacker FoF Frequency: anywhere, while Structure≤95%, Shields<15%, Armor<15%;
    
    
• State changes: Ownership inherited from Controller, with provisions (see The fine Print).
  
  
  • Abandoned: after 3min without a pilot.
  • Challenged: disables modules and jump drive (if any).
    
    
• NTC: Based on ship class, variation between classes roughly proportional to Capacitor size.
  
  
  • ETC: NTC*TSM
    
    
• PTR: always on, except while in a Challenged or Abandoned state, set to the current ship Defender FoF frequency.
  
  
  • PTRr: 3 to 15% ETC/cycle, based on ship class, further modified by TSM.
  • PTRc: Frigs, Dessie, Cruiser (T1, T2, Fc): 20s. BC, BS (T1,T2, Fc): 30s. T3 Cruisers: 30s. Freighters (T1/T2): 45s. Capitals: 60s. Supercaps: 90s.
  • -PTR: While Abandoned, -0.1% NTC/cycle.
    
    
• TSM: affect ETC and PTR.
  
  
  • FoF Tuning skill: +5% per level.
  • Sovereignty: all sovereignty TSM apply.
  • Rigs: yes, tbd.
    
    

POS control Towers

• Vulnerable:
  
  
  • POS Defender FoF Frequency: always but while Reinforced.
    
  • Neutralization: while Shields<50%, post-Reinforced mode. Requires to be Planetary Defender or for the Planet to be Abandoned.
  • Commandeering: While Structure≤95%, Shields<50%, Armor<15%, post-Reinforced mode. Requires to be Planetary Defender, or Solar Defender (if the Planet is Abandoned). If both Planet and Solar are Abandoned, Commandeering is FFA. 
  • NPC space: Requires the POS Defender to be a valid War Target of the Attackers to lift sovereignty immunities. Rest is similar to 0.0 POS.
    
  
  
  
• State changes: Ownership inherited from Controller, with provisions.
  
  
  •  Controlled: Enables Strategic Modules (subject to sov requisistes).
    
  • Abandoned: triggered on entering Challenged Control state.
  • Challenged: disables (Offlines) Strategic Modules (if any).
    
  
  
  
• NTC: ≈ 10x Dreadnought NTC.
  
  
  • ETC: NTC*TSM
    
    
• PTR: always on, except while in a Challenged/Reinforced state, set to the current POS Defender FoF frequency.
  
  
  • PTRr: 1% to 3% ETC/cycle, based on Tower Type, further modified by TSM.
  • PTRc: 300s.
    
    
• TSM: affect ETC and PTR.
  
  
  • Sovereignty: requires Planetary Sovereignty to enable Sovereignty TSM from other tiers.
  • Tuning Array: +20% TSM
    
    
    

POS Modules

• Vulnerable:
  
  
  • POS Defender FoF Frequency: always but while Reinforced.
    
  • Neutralization: while Modules Shields<50%, Armor<50%, or anytime while the POS tower is Abandoned, offline or destroyed.
  • Commandeering: While Modules Shields<50%, Armor<50%, post-Reinforced mode.
    If the POS tower is destroyed, offline or Abandoned, Commandeering is FFA. 
  • NPC space: Requires the POS Defender to be a valid War Target of the Attackers to lift sovereignty immunities. Rest is similar to 0.0 POS.
    
  
  
  
• State changes: Ownership inherited from POS control tower.
  
  
  •  Controlled: Allows to use/access/take the module and its contents, as if rightfully Owned.
  •  Owned: Allows to use/access/take the module and its contents, while not Controlled by a third-party.
  • Challenged: disables (Offline) if the module is of a Strategic type (tied to Sovereignty), or simply denies use/access/take to everyone.
    
    
• NTC: ≈ 1-8x Dreadnought NTC (depends on type).
  
  
  • ETC: NTC*TSM
    
    
• PTR: status inherited from control tower if present. Disabled if tower is offline, Abandoned or Destroyed, or if the module itself is offline or incapacitated.
  
  
  • PTRr: 1% to 5% ETC/cycle, based on module Type, further modified by TSM.
  • PTRc: 100s.
    
    
• TSM: affect ETC and PTR.
  
  
  • Sovereignty: requires Planetary Sovereignty to enable Sovereignty TSM from other tiers.
  • Tuning Array: +20% TSM
  
  

Stargates

• Vulnerable:
  
  
  • Neutralization: always. A Stargate doesn't require to be damaged for any party to Neutralize it.
  • Commandeering: Requires the sister gate on the other side of the jump to be either  Neutralized (and fed the same  FoF Frequency) or positively charged (for the same FoF frequency) for Tuning Up to work on the target Stargate, unless one is the Owner of the target Stargate, in which case the sister gate being in any state but Controlled by a third-party is enough.
    A Stargate doesn't require to be damaged for any party to Commandeer it.
    
  • NPC space: Requires the Stargate Owner to be a valid War Target of the Attackers to lift sovereignty immunities. Rest is similar to 0.0.
    
    
• State changes: Ownership inherited from Solar/Constellar Sovereign, with provisions.
  
  
  • Controlled: Builds Occupancy requirements, also enables TacticalDataStreams for the Controller, and modifies the Stargate PTR.
  • Neutralized: Disables SearchlightEffect for the Defender.
    
  • Challenged: Denies all Occupancy/Ownership benefits to the Owner.
    
    
• NTC: ≈ 10x Dreadnought NTC.
  
  
  • ETC: NTC*TSM
    
    
• PTR: requires  Solar sovereignty to benefit the Stargate Controller, or Constellation Sovereignty  (if the Solar is Abandoned) — PTR depends on Ownership. PTR is also disabled while the Stargate is Challenged, and halved while it is Controlled by another Faction than the DCC Defender.
  
  
  • PTRr: 1% ETC/cycle, based on Tower Type, further modified by TSM.
  • PTRc: 90s.
    
    
• TSM: affect ETC and PTR.
  
  
  • Sovereignty: System Sovereignty is required to receive other Sovereignty TSM, or Constellation Sovereignty with Neighborhood rules active if the System is Abandoned.
    

Dungeon Control Centers (Planetary/Solar)

• Vulnerable:
  
  
  • Neutralization: while Occupancy requisites are met, barring Sovereignty immunities.
    A DCC doesn't require to be damaged for any party to Neutralize it.
  • Commandeering: while Occupancy requisites are met, barring Sovereignty immunities.
    A DCC doesn't require to be damaged for any party to Commandeer it.
  • NPC space: Requires the Dungeon Defender to be a valid Factional War Target of the Attackers. Rest is similar to 0.0.
    
  
  
  
• State changes: Ownership is decided by Controller of the Dungeon Control Center.
  
  
  • Controlled: Grants DCC and Dungeon Ownership, with attached benefits.
    
  • Owned: Grants Planetary or Solar sovereignty, respectively. 
    Planetary Ownership reduces Occupancy requirements to Neutralize or Commandeer the local Outpost  while the DCC is Controlled by its Owner, and grants an exclusive to the DCC Owner on Commandeering the Oupost while the DCC remains Controlled or Neutralized.
    Ownership allows to access/take/manage the DCC, and may also tame local NPC drones (with sufficient sovereignty benefits).
  • Neutralized: Planetary DCC, while Neutralized, open their respective Outpost to Neutralization by attackers (barring Capital Sovereignty Immunity). Neutralizing a  DCC also disables SearchlightEffect for its Defender.
  • Challenged: Lifts DCC, Dungeon and Planetary or Solar Ownership/Sovereignty and attached benefits, switching the respective Ownership/Sovereignty to Abandoned.
  • Abandoned: Allows any party to vie for sovereignty on equal Occupancy footing.
    An Abandoned Planetary DCC opens the local outpost to Neutralization/Commandeering by any party that meets Occupancy requirements minus Planetary Sovereignty.
    
  
  
  
• NTC: ≈ 10x/20x Dreadnought NTC (Planetary/Solar).
  
  
  • ETC: NTC*TSM
    
    
• PTR: PTR is active while the DCC is Owned plus Controlled or Neutralized,  and disabled while the DCC is Challenged or Abandoned.
  
  
  • PTRr: 2% (Planetary), 1% (Solar)  ETC/cycle, modified by TSM.
  • PTRc: 300s.
    
    
• TSM: affect ETC and PTR.
  
  
  • Sovereignty: requires Dungeon Ownership to enable Sovereignty TSM from other tiers.
    

Dungeon Mass Drivers (Planetary/Solar)

• Vulnerable:
  
  
  • Neutralization: while Occupancy requisites are met, barring Sovereignty immunities.
    A DMD doesn't require to be damaged for any party to Neutralize it.
  • Commandeering: while Occupancy requisites are met, barring Sovereignty immunities.
    A DMD doesn't require to be damaged for any party to Commandeer it.
  • NPC space: Requires the Dungeon Defender to be a valid Factional War Target of the Attackers. Rest is similar to 0.0.
    
  
  
  
• State changes: Ownership inherited from Dungeon Control Center.
  
  
  •  Controlled: Allows to use the DMD as if rightfully Owned but at the expense of its Tuning charge (based on mass) if not the Owner (subject to ship class restrictions based on possible Sovereignty Immunities). Also renders the attached Defensive structures susceptible to Commandeering by the Controller if not also the Owner.
    
  • Owned: Allows to use the DMD at all times at no cost and without restrictions, may also tame local NPC drones (with sufficient sovereignty benefits), and allows to Tune Up or Neutralize attached Defensive structures.
    
  • Challenged: disables TacticalDataStreams, and prevents manual control of the attached Defensive structures by the Defender (but not their FoF Tuning).
    
    
• NTC: ≈ 5x/10x Dreadnought NTC (Planetary/Solar).
  
  
  • ETC: NTC*TSM
    
    
• PTR: status partly inherited from Dungeon Control Center. PTR is disabled while the DMD is Challenged, or Abandoned (as a result of the DCC being lost), and halved while the DMD is Controlled by another Faction than the DCC Defender.
  
  
  • PTRr: 2% (Planetary), 1% (Solar)  ETC/cycle, further modified by TSM.
  • PTRc: 300s.
    
    
• TSM: affect ETC and PTR.
  
  
  • Sovereignty: requires Dungeon Ownership to enable Sovereignty TSM from other tiers.
  
  
  

Dungeon Defensive Structures

• Vulnerable:
  
  
  • Neutralization: By any  faction while Modules Shields<50%, Armor<50%, or while the structure itself is Abandoned, or the DMD/DCC it's attached to is Abandoned (or destroyed).
    By the Dungeon Defender at any time, while charged positively for a foreign Faction FoF frequency. 
    
  • Commandeering: By the Controller of their DMD/DCC — a Commandeered DSS will revert to Neutralized if the state of the DMD it's attached to changes to Neutralized, Challenged or Abandoned.
    DDS don't require to be damaged for any party to Commandeer them.
  • NPC space: Requires the Dungeon Defender to be a valid Factional War Target of the Attackers. Rest is similar to 0.0, except DDS can't be stolen.
    
  
  
  
• State changes: Ownership inherited from Dungeon Control Center.
  
  
  • Controlled: Allows to use/access/take the DDS as if rightfully Owned, burning the DCC fuel reserves all the while. If the DSS Controller is not the Dungeon Defender, it will only attack in self-defense unless manually operated by a Pilot. 
    
  • Owned: Allows to use the DDS in automatic mode, or manually operated by a  Pilot, while the DDS is Controlled (or Neutralized) by its Owner.
    
  • Challenged: disables TacticalDataStreams, and prevents manual control of the DDS  by the Defender (but not their FoF Tuning). The DDS will still operate in automatic mode for the Owner benefit while Challenged, however.
  • Abandoned: Can only happen as a result of the DCC being lost and brings the structure offline. The DCC can then be Neutralized and Commandeered by any party, and subsequently unanchored, or re-onlined for the new Dungen Defender's benefit.
    
  
  
  
• NTC: ≈ 1-8x Dreadnought NTC (depends on type).
  
  
  • ETC: NTC*TSM
    
    
• PTR: status partly inherited from Dungeon Control Center. DDS' PTR is disabled while their DMD is Challenged, or Abandoned (as a result of the DCC being lost), and halved while the DMD is Controlled by another Faction than the DCC Defender.
  
  
  • PTRr: 1% to 5% ETC/cycle, based on module Type, further modified by TSM.
  • PTRc: 100s.
    
    
• TSM: affect ETC and PTR.
  
  
  • Sovereignty: requires Dungeon Ownership to enable Sovereignty TSM from other tiers.
    
  
  
  

Misc.Anchorables

Include: Anchorable Bubbles, Secure Cans, Freighter Cans, Construction and Upgrade Platforms

• Vulnerable:
  
  
  • Neutralization: By any  party while Structure≤95%, Shields<15%, Armor<15%.
    By the current Controller/Owner at any time, or by anyone while Abandoned, both regardless of damaged state. 
  • Commandeering: By any  party while Structure≤95%, Shields<15%, Armor<15%.
    By the current Controller/Owner at any time, or by anyone while Abandoned, both regardless of damaged state. 
  • NPC space: Is a Criminal Act unless the object Defender is a valid (Factional )War Target , falls under Kill Rights, or belongs to the same Corp/Faction as the FoF Tuning frequency applied. Legality is generally the same as for ships Commandeering.
    
  
  
  
• State changes: Ownership set by Control state.
  
  
  • Controlled: Grants Ownership to the Controller, unless the last Owner was a Corporation belonging to the Faction that Commandeered the Anchorable, in which case Ownership is left intact. 
    
  • Owned: Allows to Neutralize a foreign FoF Tuning, or Tune Up the object at all times.
    
  • Challenged: Lifts Ownership under the same rules as Control does grant it (see above) resulting either in conservation of Ownership or Abandonment of the object.
  • Abandoned: Allows anyone to Neutralize or Commandeer the object.
    
    
• NTC: ≈ varies wildly (depends on type).
  
  
  • ETC: NTC*TSM
    
    
• PTR: Special — Misc.Anchorables can't benefit from PTR, but indefinitely conserve their tuning, Ownership and Control state unless Abandoned.
  
  
  • PTRc: 100s.
  • -PTR: While Abandoned, -0.1% NTC/cycle, exempt from TSM modifiers.
    
    
• TSM: affect ETC.
  
  
  • Sovereignty: any Sovereignty TSM that applies to ships applies to Misc.Anchorables belonging to that Faction.
    

***

I left out Outposts from this one, because: it's already an insane wall'o'text  and me fingers hurt ; Outposts call for diagramms (you got one today already, and I hate making those) ; I am the starving.
So this will be for Part 3, with other stuff I may have forgot/left out.