Tweaks to eliminate the "one speck wonder" block phenomenon (transporters, hyperspace, and now early-game shield)

[Nyrin]

Most players are familiar with the quirk once they unlock Xanion: a 0.5x0.5x0.5 transporter block (or even smaller!) does everything a bigger block would, so you just throw the block in as a token inclusion and call it done.

2.0 changes make this more of a thing: relative nerfs to hyperspace core improvement make it even *more* likely that you'll just include a single speck of Avorion for rift passage, and the shift of shield boosters to flat bonuses now make it appealing to have single-speck shield blocks in Naonite and perhaps Trinium space to acquire a meaningful shield with no real block or processing investment.

I think it'd be great if building these tiny "on/off" switch blocks weren't a good way to go. To that end, making the behavior of corresponding subsystem upgrades work as "matching function" to blocks would help:

• For shield boosters, switch to a capped +% boost rather than a completely flat boost. E.g. "+300% shield (up to 200000)" -- you'll still need some block investment to take full advantage of the booster
• For transporters, allow blocks to logarithmically increase range (like hyperspace cores) and have a rarity-decreasing minimum "base range from blocks" requirement for the corresponding transporter subsystem: e.g. uncommon transporter subsystems may require 20-30 cubic blocks of transporter volume before they can start working work, but a legendary one may only require 4-8 thanks to its awesome efficiency (though you could still use bigger ones for better range!)
  • To complement this, more advantages for increased transporter range would help, e.g. improve r-mining/r-salvaging operation efficiency based on transporter performance (e.g. as an input like the "time to find asteroid" variable)
• For hyperspace cores, cap or scale subsystem bonuses based on block investment and scale rift passage with the size of your Avorion core:
  • Total +range and -cooldown from subsystems should be limited (capped or scaled) -- if my ship has no hyperspace core at all, I shouldn't be able to put in three subsystems and have +20 range, and bigger cores should progressively make these subsystems more valuable
  • How far you can travel through rifts should be purely based on the size of your Avorion hyperspace core. E.g. a 0.5x0.5x0.5 Avorion hyperspace core shouldn't let you fly through anything, while a bigger one (as scaled by subsystems) should be an advantage for easy travel
    • This could further be reflected in efficiency bonuses to operations around/across rifts, making it beneficial to have a "big enough" Avorion core to navigate

The end goal would be to make it feel like scaling these blocks up in your ships always had purpose and value and to get rid of the silliness of a massive, 120-fighter r-mining operation being optimally powered by a cargo transporter with a volume of one cubic centimeter.  

[An Ning]

Overall, I like the ideas.

 

Honestly, though... I never understood the cargo transporter thing at all.

My miners can clearly hold the items -because my fighters have not changed since I put the transporter on my ship. Why do they need something on the carrier in order for them to grab what they are mining?

 

 

Now, if fighters could only hold 1 item, and had to run back to the carrier to drop things off then go out again to grab more, and the transport system  basically showed them vectors for "fly in this direction and drop it and we'll grab it", enabling them to not have to return to the carrier...then that would make more sense.

Ideally, I think the transport system should have to be on the fighters themselves as well as the carrier -make it some kind of short-range teleporter or something.

 

Edited September 5, 2021 by An Ning

[FuryoftheStars]

6 hours ago, An Ning said:

Ideally, I think the transport system should have to be on the fighters themselves as well as the carrier -make it some kind of short-range teleporter or something.

Essentially, that’s exactly what it is. However, as the blocks you put into the fighters typically don’t matter, you instead just put everything on the carrier.

[Nyrin]

Yeah, if we actually "built" the fighters and didn't just allocate stat points to them to tweak what the input turret spits out, it'd make a lot of sense to have capabilities (like fighter loot transport) depend on what was put into the fighters. As it is, though, fighter designs are just decorative skins and I imagine it'd be a *big* game rework to change that.

I do like the idea of having fighter pickup behavior scale to transporter distance. Increasing the power of your transporter to increase your raw harvesting efficiency would feel a lot less arbitrary than a binary on/off switch with the yellow ship warning.