Starmade configs and you - bending the laws of nature.

[Admiralkio]

A lot of people are upset over power 2.0, but ignore that Schema conveniently allowed us to change our own configs with a text editor. This is a detailed study of blockconfig, and what the various change options.
I will not cover anything in the configs that is marked as old, or to be removed.
Before we continue, grab Notepad++ to edit this file. It's very, very useful for making it human-readable.

Starmade essentially just uses some very fancy math to work out how blocks work.

Some terminology, before we continue.
(LIN) Linear: A straight line, essentially. There is no number curve.
(EXP) Exponential: Increases by a factor of itself each time. As it goes up, it rapidly increases.
(LOG) Logarithmic: The inverse of EXP.

Starmade uses DOUBLE or LEVELED variations of all of these. If you've passed HS math, you know what these do. Some googling otherwise will help you.

Schema has also done a wonderful job providing comments within the blockconfig.xml file, so figuring these things out is even easier!

This is a ear-notes version, aka, line-numbers and a brief explanation. I will not hold your hand with this, because i assume you can read!
Anything aligned LEFT is old. Anything aligned CENTER is relevant.

Spoiler: Lines

5-114: Old power configs. Ignore these.

115-309: New power, new shields.
​

<ShieldLocalCapacityPerBlock>250</ShieldLocalCapacityPerBlock>
<ShieldLocalRechargePerBlock>25</ShieldLocalRechargePerBlock>
<ShieldLocalDefaultCapacity>0</ShieldLocalDefaultCapacity>

These variables determine shield capacity PER CAPACITOR, and recharge PER RECHARGER BLOCK, and the BASE SHIELD CAPACITY of a SHIP CORE.

<ShieldLocalRadiusCalcStyle>EXP</ShieldLocalRadiusCalcStyle> <!-- LINEAR, EXP, LOG -->
<ShieldLocalDefaultRadius>10</ShieldLocalDefaultRadius>

<!-- LINEAR -->
<ShieldLocalRadiusPerRechargeBlock>0.1</ShieldLocalRadiusPerRechargeBlock>

<!-- EXP -->
<ShieldLocalRadiusExpMult>15.0</ShieldLocalRadiusExpMult>
<ShieldLocalRadiusExp>0.3</ShieldLocalRadiusExp>

<!-- LOG -->
<ShieldLocalRadiusLogFactor>20.0</ShieldLocalRadiusLogFactor>
<ShieldLocalRadiusLogOffset>0.0</ShieldLocalRadiusLogOffset>

These variables control shield radius calculation: How it is calculated, and what each block increases the radius by. As you can see here, shield radius increases exponentially with shield recharge group size.

​

<ShieldUpkeepPerSecondOfTotalCapacity>0.02</ShieldUpkeepPerSecondOfTotalCapacity>

<ShieldLocalPowerConsumptionPerRechargePerSecondResting>0.4</ShieldLocalPowerConsumptionPerRechargePerSecondResting>
<ShieldLocalPowerConsumptionPerRechargePerSecondCharging>0.8</ShieldLocalPowerConsumptionPerRechargePerSecondCharging>

<ShieldLocalRechargeUnderFireModeSec>30.0</ShieldLocalRechargeUnderFireModeSec> <!-- how long after being hit a recharge nerf based on shield status applies -->
<ShieldLocalRechargeUnderFireMinPercent>0.5</ShieldLocalRechargeUnderFireMinPercent> <!-- minimum recharge under fire -->
<ShieldLocalRechargeUnderFireStartAtCharged>1.0</ShieldLocalRechargeUnderFireStartAtCharged> <!-- the nerf starts (100% recharge) at a shild this value percent -->
<ShieldLocalRechargeUnderFireEndAtCharged>0.20</ShieldLocalRechargeUnderFireEndAtCharged> <!-- the nerf reaches its maximum (ShieldLocalRechargeUnderFireMinPercent) at a shild this value percent -->


<ShieldLocalOnZeroShieldsRechargePreventionSec>10.0</ShieldLocalOnZeroShieldsRechargePreventionSec>
<ShieldLocalHitAllOverlapping>true</ShieldLocalHitAllOverlapping>
<ShieldLocalMaxCapacityGroupsPerLocalShield>20</ShieldLocalMaxCapacityGroupsPerLocalShield>

These variables control shield recharge, shield power consumption while recharging and at rest, how much they recharge under fire, how long they are down when shield HP hits zero, if overlapping shields are hit or not, and the max amount of capacitors block PER ship.
​

<ReactorRebootMinCooldownSec>15</ReactorRebootMinCooldownSec> <!-- cooldown to reboot active reactor when damage is taken to the active reactor -->
<ReactorRebootLogFactor>2</ReactorRebootLogFactor>
<ReactorRebootLogOffset>-2.5</ReactorRebootLogOffset>
<ReactorRebootCooldownInSecPerMissingHpPercent>15</ReactorRebootCooldownInSecPerMissingHpPercent> <!-- cooldown to reboot active reactor when damage is taken to the active reactor -->

<ReactorConduitPowerConsuptionPerSec>0.0</ReactorConduitPowerConsuptionPerSec> <!-- conduit power usage -->
<ReactorSwitchCooldownSec>10</ReactorSwitchCooldownSec> <!-- time in seconds to wait until active reacor can be switched again -->
<ReactorRechargePercentPerSecond>1.0</ReactorRechargePercentPerSecond> <!-- percentage of power capacity recharged per second -->
<ReactorRechargeMultiplierWhenEmpty>1.0</ReactorRechargeMultiplierWhenEmpty> <!-- multiplied with recharget when power was 0 last cycle -->
<ReactorMainCountMultiplier>1.0</ReactorMainCountMultiplier> <!-- for capacity, multiply amount of main reactor blocks with this (capacity = min(reactorBlocks, stabilization)) -->
<ReactorPowerCapacityMultiplier>100.0</ReactorPowerCapacityMultiplier> <!-- multiply capacity end result with this -->
<ReactorStabilizationMultiplier>1.0</ReactorStabilizationMultiplier> <!-- for capacity, multiply amount of main reactor blocks with this (capacity = min(reactorBlocks, stabilization)). stabilization is +1 for each optimal distance stabilizer, falls off when closer -->
<ReactorExplosionStabilityMargin>0.5</ReactorExplosionStabilityMargin> <!-- 1 == 100% stability. Anything lower than this value (ecluding the value iself) explodes-->
<ReactorExplosionStabilityLossMult>2.0</ReactorExplosionStabilityLossMult> <!-- multiplies stabilization loss factor for damage calculation -->
<ReactorExplosionCountMaxPercent>0.001</ReactorExplosionCountMaxPercent> <!-- max explosions per group, % of group size-->
<ReactorExplosionCountPerBlocksInGroup>0.1</ReactorExplosionCountPerBlocksInGroup> <!-- explosions per group, % of group size -->
<ReactorExplosionCountMax>10</ReactorExplosionCountMax> <!-- max explosions per group -->

<ReactorExplosionsPerSecond>2</ReactorExplosionsPerSecond> <!-- explosions per second -->
<ReactorExplosionRadiusPerBlocksInGroup>0.001</ReactorExplosionRadiusPerBlocksInGroup>> <!-- radius of a explosion based on the group's member count, minimum 1 -->
<ReactorExplosionRadiusMax>5.0</ReactorExplosionRadiusMax> <!-- capped at 64 -->

<ReactorExplosionDamagePerBlocksInGroup>5.0</ReactorExplosionDamagePerBlocksInGroup> <!-- damage of a explosion based on the group's member count -->
<ReactorExplosionDamageMax>10000.0</ReactorExplosionDamageMax> <!-- capped at max signed integer -->

<ReactorModuleDischargeMargin>0.9</ReactorModuleDischargeMargin> <!-- at which percentage of resting consumption available a module (weapon) starts to discharge -->

​

I literally don't need to explain these. Thanks, Schema!

​

<!-- LINEAR -->
<ReactorStabilizerDistancePerMainReactorBlock>0.5</ReactorStabilizerDistancePerMainReactorBlock> <!-- ReactorStabilizerStartingDistance + blocks * ReactorStabilizerDistancePerMainReactorBlock -->

<!-- EXP -->
<ReactorStabilizerDistanceExpMult>10.0</ReactorStabilizerDistanceExpMult> <!-- ReactorStabilizerStartingDistance + (blocks ^ ReactorStabilizerDistanceExp) * ReactorStabilizerDistanceExp -->
<ReactorStabilizerDistanceExp>0.333</ReactorStabilizerDistanceExp>

<ReactorStabilizerDistanceExpSoftcapMult>0.5</ReactorStabilizerDistanceExpSoftcapMult>
<ReactorStabilizerDistanceExpSoftcapExp>2.5</ReactorStabilizerDistanceExpSoftcapExp>
<ReactorStabilizerDistanceExpSoftCapBlocksStart>150000</ReactorStabilizerDistanceExpSoftCapBlocksStart>

<!-- LOG -->
<ReactorStabilizerDistanceLogFactor>1</ReactorStabilizerDistanceLogFactor> <!-- ReactorStabilizerStartingDistance + (Log10(blocks) + ReactorStabilizerDistanceLogOffset) * ReactorStabilizerDistanceLogFactor -->
<ReactorStabilizerDistanceLogOffset>1</ReactorStabilizerDistanceLogOffset>

<!-- LOG_LEVELED -->
<ReactorStabilizerDistanceLogLeveledSteps>true</ReactorStabilizerDistanceLogLeveledSteps> <!-- true: Optimal Distance only changes only at level change. false: linear between levels -->
<ReactorStabilizerDistanceLogLeveledMultiplier>10</ReactorStabilizerDistanceLogLeveledMultiplier> <!-- ReactorStabilizerStartingDistance + (ReactorLevel^ReactorStabilizerDistanceLogLeveledExp * ReactorStabilizerDistanceLogLeveledMultiplier) -->
<ReactorStabilizerDistanceLogLeveledExp>2</ReactorStabilizerDistanceLogLeveledExp> <!-- ReactorStabilizerStartingDistance + (ReactorLevel^ReactorStabilizerDistanceLogLeveledExp * ReactorStabilizerDistanceLogLeveledMultiplier) -->

​

Schema is even nice enough to explain the math formulae here. Calculators!

​

<ReactorStabilizerStartingDistance>-7.5</ReactorStabilizerStartingDistance> <!-- inital distance -->
<ReactorStabilizerLinearFalloffOne>1.0</ReactorStabilizerLinearFalloffOne> <!-- percentage of distance at which or farther away the stabilizer counts as 1 -->
<ReactorStabilizerLinearFalloffZero>0.0</ReactorStabilizerLinearFalloffZero> <!-- percentage of distance at which or closer the stabilizer counts as 0 -->
<ReactorStabilizerFreeMainReactorBlocks>10</ReactorStabilizerFreeMainReactorBlocks> <!-- amount of free stabilization added -->
<ReactorStabilizerDistanceTotalMult>2.0</ReactorStabilizerDistanceTotalMult>
<ReactorStabilizerGroupingProximity>3.0</ReactorStabilizerGroupingProximity>

<ReactorStablizationBonus2>1.0</ReactorStablizationBonus2> <!-- bonus stabilization stacking based on percentage of biggest in group -->
<ReactorStablizationBonus3>1.0</ReactorStablizationBonus3> <!-- bonus stabilization stacking based on percentage of biggest in group -->
<ReactorStablizationBonus4>0.8</ReactorStablizationBonus4> <!-- bonus stabilization stacking based on percentage of biggest in group -->
<ReactorStablizationBonus5>0.6</ReactorStablizationBonus5> <!-- bonus stabilization stacking based on percentage of biggest in group -->
<ReactorStablizationBonus6>0.5</ReactorStablizationBonus6> <!-- bonus stabilization stacking based on percentage of biggest in group -->




<ReactorStabilizerGroupsMax>20</ReactorStabilizerGroupsMax> <!-- max stabilizer groups used (ordered by size biggest first) -->

<ReactorStabilizationPowerEffectiveFull>0.25</ReactorStabilizationPowerEffectiveFull> <!-- reactor stab% (or lower) at which power efficiency is falling -->

​

Again, mostly explained by the cat-god himself. Reactor Stabilization goes from 0 to 1 in the code, it seems, so it's a decimal. 0.25 is 25%.

​

<ReactorLowStabilizationExtraDamageStart>0.9999</ReactorLowStabilizationExtraDamageStart> <!-- stabilization where extra damage starts -->
<ReactorLowStabilizationExtraDamageEnd>0.0</ReactorLowStabilizationExtraDamageEnd> <!-- stabilization where extra damage reaches max (and stays at that) -->
<ReactorLowStabilizationExtraDamageStartDamage>0.0</ReactorLowStabilizationExtraDamageStartDamage> <!-- extra damage (1+x) at start -->
<ReactorLowStabilizationExtraDamageEndDamage>2.0</ReactorLowStabilizationExtraDamageEndDamage> <!-- extra damage (1+x) at end (max) -->


<ReactorStabilizationEnergyStreamHitCooldownPerDamageInSec>0.0005</ReactorStabilizationEnergyStreamHitCooldownPerDamageInSec> <!-- seconds of reactor-nerf(cooldown) per damage hit on the stream -->
<ReactorStabilizationEnergyStreamHitMinCooldownInSec>0.01</ReactorStabilizationEnergyStreamHitMinCooldownInSec> <!-- minimum secs of reactor-nerf(cooldown)-->
<ReactorStabilizationEnergyStreamHitMaxCooldownInSec>60.0</ReactorStabilizationEnergyStreamHitMaxCooldownInSec> <!-- maximum secs of reactor-nerf(cooldown)-->
<ReactorStabilizationEnergyStreamHitMaxCooldownReactorEfficiency>0.2</ReactorStabilizationEnergyStreamHitMaxCooldownReactorEfficiency> <!-- power regeneration percent the reactor runs at during reactor-nerf(cooldown) -->
<ReactorStabilizationEnergyStreamDistance>-1</ReactorStabilizationEnergyStreamDistance> <!-- minimum distance at which stabilizer stream appears -->

​

...no explanation required! See. This is really simple, if you guys would read...
​

In case you need a file path:

Starmade/Starmade/data/config/blockBehaviorConfig.xml

 

[HerrColonel]

Good to have a post explaining config for 2.0 The quotes inside your spoiler don't display well though. Must be just a forum flaw.

Anyway if you think it address the issues players have with the power 2.0 you missed the point. Correct me if I'm wrong.

With the config I can't go back to old style reactors where power per reactor block goes up depending on max dim per group (AKA single lines or crosses of power for best efficiency). The amount of power per block (or if it goes exponential) isn't the issue, the issue is that we have a brand new system using a second kind of blocks for power (stabs) and designing power lost the depth it had in most players opinion.

With the config I can't get rid of those chambers tied to reactor output and replace them with the old passive effects.

With the config I can't go back to global shields.

With the config I CAN set base system integrity so high that I don't have to worry about it when I build. But the game will still make calculations about that when blocks are destroyed, making combat more laggy than it was.

If config allowed for something that look like power 1.0, at least one server owner would have made a server with it. And most of starmade's lost playerbase would be on it since that'll be better than staying on a discontinued version.

Schine said that power 2.0 was required because they had to clean up their code to be able to develop it further which is fine. But they also said they'll go back to the old power mechanics if the new system didn't reach its goal (Which pretty much everyone agree on).

That's why lots of players (I'm part of them) see the new power mechanics as a bad joke and quit because the game they were playing on, and hoped for, got taken from them. NOT because they can't read and didn't know config can solve all their issue

 

[Admiralkio]

I'm doubtful everyone agrees that power 2.0 is bad.

It seems to be an extremely vocal minority.

 

[HerrColonel]

Issues with the 2.0 Power System (Regarding the Goals of the New System)

You must be right. But that's because most of the playerbase quitted

 

[Admiralkio]

https://steamdb.info/app/244770/graphs/

There has been no significant change in starmade playerbase over the past 5 months that is not explained by historical data.

 

[Alphajim]

Issues with the 2.0 Power System (Regarding the Goals of the New System)

You must be right. But that's because most of the OLD playerbase quitted

That can be seen as a more realistic explanation. Now the majority like it, as old players aren't SM players anymore. And it's good as is, if they can find a game that suits them better then I'm happy with it.

Many of the new players I talk with haven't that much difficulties to understand how it works, except the basics and the little details. But it's not a big threat as we help them. The only one thing I constantly hear about is the integrity.

Schine has already planned that the playerbase won't be the same when reaching final stage. I wonder if they knew way before P2.0 that it would provocate this leaving wave.

 

[jayman38]

I admit that I and people like me are reluctant to change configs. Then we are effectively playing a different game than everyone else, and then our builds don't make sense in other people's universes. People like me try to build to the vanilla config to keep the build's performance similar across standard installations, including the vanilla installation that most new players will play with first. After all, it's the new players who are most likely to download random builds from CC, to help get their empire and building knowledge kick-started.

With that said, it can be real fun to play in your own config rules. I'm always hoping that there will be a few big config mods that become popular, to encourage builds in those popular-config universes.

 

[God mode]

Changing a few config values will not do much to improve the situation, especially if those changes are not made default.

That can be seen as a more realistic explanation. Now the majority like it, as old players aren't SM players anymore. And it's good as is, if they can find a game that suits them better then I'm happy with it.

Many of the new players I talk with haven't that much difficulties to understand how it works, except the basics and the little details. But it's not a big threat as we help them. The only one thing I constantly hear about is the integrity.

Most people who disliked it left, so now most people like it, so it's a good update? Come on.

 

[HerrColonel]

https://steamdb.info/app/244770/graphs/

There has been no significant change in starmade playerbase over the past 5 months that is not explained by historical data.

You're missing the point again. As Alphajim said old playerbase that left got replaced by new ones as the game keeps selling on steam. Would be nice to have these graph export-able on excel so we can look at stuff like the average amount of players over time, but I'm too lazy to make it manually.
Your point was: Criticism of 2.0 power is not legit, as all the issues can be fixed by tweaking the config, and it's not true.
Also a very interesting point of Jayman38 is: players tweaking the config is not a desirable thing in the long run because it splits the playerbase into different versions of the game and it prevents players builds to work as designed from one config to the other.

I think if you were that satisfied about the game you'd be playing it instead of asking people to stop complain about what they don't like. When a game is failing as hard as starmade is today you should know you're hurting it more than helping it.

 

[Admiralkio]

You can take that view all you want, but:

I'm most assuredly still playing the game that i'm telling people to stop complaining about.

Something reeks of alt account in this thread. Can't quite pin my finger on it, though.

 

[Alphajim]

Changing a few config values will not do much to improve the situation, especially if those changes are not made default.



Most people who disliked it left, so now most people like it, so it's a good update? Come on.

I didn't said that it make the update good. In fact, by "it's good as is" I talked about those who wisely chose to quit instead of wasting their time in a stupid "crusade" against devs. Not that one can't have his own opinion, but trolling around or asking to bring back the P1.0 are useless. The first is obvious on why it's stupid, the second is more because devs won't bring back the old power.

I agree with the fact configs are not a good way to go.

 

[Admiralkio]

The general idea of configs is that people can change what they want and form communities around their changes. If you want to tinker with the configs on your SP world, be my guest.

But, the point of 'oh, it'll mess with ships if they share them!'

Labels, are a thing.

 

[happahappa]

i'm still playing and i'm happy with the work of schine and schema. in the current dev builds, shit really gets done. stop trolling and stick to the topic!

nice work in explaining the basics of starmade configs.