CS: Quickfire Initiative: Rebalancing StarMade

[Reilly Reese]

You seem to have overlooked the part before the comma?

I don't even know what you're trying to reference anymore. The section I quoted was separate and did not have a comma in it.

 

[StormWing0]

The Rock, Paper, Scissors thing with Cannon, Beam, Missile VS Armor, Shields, Systems; works fine until you start adding new weapons with no relation to the others such as Mines, Pulse, Flamethrower, Electrical Arcs, Hacking, etc.

 

[Nauvran]

The Rock, Paper, Scissors thing with Cannon, Beam, Missile VS Armor, Shields, Systems; works fine until you start adding new weapons with no relation to the others such as Mines, Pulse, Flamethrower, Electrical Arcs, Hacking, etc.

we already have mines and I already listed a lot of reasons why it would be a terrible idea.
Anyone suggesting that system, without putting a severe limit to how much each type of weapon is better or worse, can go fuck themselves

 

[Valiant70]

All weapons types should be amazing but in different situations that arent able to completely nullify one weapon type.
each weapon type needs a proper interesting advantage and disadvantage not a rock paper scissor solution.
If thats your solution then you really dont have any imagination.

All the best pvp games I've played have had some kind of rock/paper/scissors mechanic, especially the old ones designed for a smaller number of players with out all the modern window dressing and monetization gimmicks. R/P/S prevents stale mate and keeps things moving.

There isn't any problem with having a R/P/S mechanic. The problem comes when it trumps all other factors. As others have suggested, 15% seems like a good sweet spot for making the bonuses meaningful but not overwhelming. Following R/P/S should not turn the tide of battle 100% of the time. It's a factor that can indeed keep things moving, but at the same time this isn't RuneScape.

To put it another way, having R/P/S turned against you should put you in a bad position, but not an unwinnable one.
[doublepost=1566143681,1566142782][/doublepost]

• Disabled stabilizer distance and side-based bonuses. (for now.)

While I understand it's been disabled to make things easier for testing I certainly hope it's re-enabled by the time you put it to release. This is the only mechanic that keeps the relationship between ship size and power output sane. It's the only thing preventing shells from being filled entirely with power and weapons.

Stabilizers are generally a harmful mechanic. In their current state the facing mechanic has issues where it can be exploited to make stick ships extremely efficient, but even with the less stick-forming and more balanceable BY_ANGLE version that Schema put in as a config option recently, it still punishes the wrong players.

Stabilizers were conceived as a way to make sure that ship "sizes" (whatever that even means) tracked with power availability. Presumably this was because Lan and Schema saw that most competitive ships were packing in systems inside their hulls, leaving no gaps except for maybe minimal interior. The problems with trying to "fix" that are threefold.

1. Not everyone agrees that ship filling was even a problem.
   Many players were happy with the creative freedom to do whatever they wanted with their interior space, whether they be creative builders or veteran PvP experts. The scaling restrictions imposed by stabilizers posed little more than an annoyance. Additionally, having less exposed block surfaces meant better GPU performance (granted, that won't be an issue post-universe update due to new optimizations).
   
   For the record, I personally don't like filling up ships at all. I don't hate it enough to sacrifice balance and creative freedom, though.
   
   
2. There's nothing about systems that inherently forces you to fill up your ship.
   The actual main reason for ship-stuffing is the excessive mass of armor. For any given volume of armored hull you would want to make use of the full capacity for systems, because that volume cost you a fair bit in mass on its own. Even pre power 2.0, competitive ships that didn't bother with the largely useless and overweight armor at all would sometimes have sizeable gaps in their systems compartments. The other reason, of course, is that there's no incentive to create interiors or anything. That one only Schine can fix with a crew system, and trying to force space inside ships is no substitute.
   
   
3. ...But what is ship size really, though?
   Trying to define the size of a ship isn't really meaningful, or at least not easy, and no stabilizer mechanic can do it. Presumably the metric we're usually thinking of when we say "size" is internal volume, and that is nigh-impossible to measure in a performant way. It also is not really feasible to try and measure the volume using some sort of placeable system simply from a logical standpoint. You'd need blocks covering the entire inner surface of the hull or something. :P
   What you get instead with stabilizers is a very rough, dimension-based approximation of volume that runs into various problems depending on the situation. The simplest example is that there can be a very obvious difference between a 500x500 caltrops shape and a 500x500 cube, or a 500x500 octohedron vs. a 500x500 sphere, but a stabilizer distance system will think they're the same thing.
   A PvP builder won't care about this as they'll just use the shape that is most mass- and therefore thruster power-efficient. Creative builders are the ones who get the proverbial shaft, with the quirks of the system producing various inefficiencies in their ships that can't be avoided because they want to use a given ship design that they feel is aesthetically pleasing, or because it looked super cool on TV.

Stabilizers do nothing for their intended purpose, but there is one thing they do well: Keeping ships from being nothing more than a mass of block-blobs. To keep this function, the distances could easily be reduced to... perhaps a couple of times the width of a spherical reactor. Maybe a little less than that. Combine that with the BY_ANGLE mechanics, and you should have something that isn't a detriment to the game.

The result I expect is that some shape is added to ships, but that reactors no longer dictate the shape of the entire ship. Builders can then bunch 2-6 stabilizers around their reactor, or place them throughout the ship. Some builders will enjoy this.

 

[Nauvran]

There isn't any problem with having a R/P/S mechanic. The problem comes when it trumps all other factors. As others have suggested, 15% seems like a good sweet spot for making the bonuses meaningful but not overwhelming. Following R/P/S should not turn the tide of battle 100% of the time. It's a factor that can indeed keep things moving, but at the same time this isn't RuneScape.

To put it another way, having R/P/S turned against you should put you in a bad position, but not an unwinnable one.
[doublepost=1566143681,1566142782][/doublepost]

That was literally my suggestion with the 15%

 

[Nosajimiki]

Ive notied removing rp is great for adding design freedom. Chamber mass keeps me picking and choosing my features, but leveling a chamber is meaningless now. The game really needs chambers to be 2-3 times smaller, but you need to add another chamber for every level for no RP to really work.

Also, comments about distanceless stabs and system cramming are not well thought out. Bricks may be more ballenced than they were, thanks to new armor, but still suffer just as many shortcomings as before. Stab distance just makes RP building far more restrictive.

 

[The Quickfire Initiative]

The Quickfire Initiative is now running the latest dev builds with beam armor mechanic changes. Please update your clients to the DEV branch to use our configs and join the test server.

 

[Edymnion]

Glad to see that we're able to expand into some user input again. Looking forwards to what comes out of it!

 

[Dr. Whammy]

I originally thought the "Quickfire Initiative" was an in-game player created faction. Then I read for a while and found out what it really is... (Face palms)

Just when I had all but lost hope, here you all are; Schine and the community back at it again. This literally brought a tear to my eye. I'm sorry for ever doubting you.

I can't wait to try out some of the new dev. configs.

 

[DeepspaceMechanic]

I finally got to doing some tests with these configs (in devbuild 0.202.2). I'm sharing my trivial results and impressions for those who didn't bother to experiment even this little.

So the smallest possible stabilizer-free reactor is now a 10-block reactor (previously it was 40). Above that you'll need exactly one stabilizer block for every reactor block, regardless of placement, to be able to use 100% of the reactor's power output. All in all, I like the current absence of both the distance-based penalty and the facing-based bonus system of stabilizers, even though it will take some time to get used to the heightened level of uselessness of stabilizers. (Yes, it would be nice to turn the power system into something more elegant with changes that go beyond just configs, but we all know at this point to be careful about what we wish for, and that the game probably wouldn't survive another power overhaul, right?)

Love the changes to the chamber system. Required chamber size 10% of reactor size; chamber size step ups at 100 block reactor size increments; less RC requirements, so more active chambers possible at once. Wonderful!

Regarding thrust, in the more comprehensive version of the QF changelog it says that "It is also an effort to make speed caps feel more intuitive: with our baseline speed cap and thrust settings, 1.0 TWR = 100 m/s speed, and 3.0 TWR = 300 m/s speed".

Don't know if these should be taken as approximations, but anyways, here are my findings (tested with a very small and a somewhat larger ship):

1.0 TMR = 108.8 m/s
2.0 TMR = 184.1 m/s
3.0 TMR = 262.5 m/s

3.0 TMR + Top speed chamber Level-1 (adds 10% of the chamberless top speed to the previous value) = 288.8 m/s
3.0 TMR + Top speed chamber Level-2 (adds 10% of the chamberless top speed to the previous value) = 315 m/s
3.0 TMR + Top speed chamber Level-3 (adds 15% of the chamberless top speed to the previous value) = 354.4 m/s


Still have to experiment with shields and weapons.

 

[EricBlank]

Haven't gotten to touch the new configs yet (cell phone data cannot download new versions of the game or configs yay rural living).
I did love the linear reactor chamber levels and chamber size growth. In my experience it made planning and comparing things easier than the exponential formula, I can do the math in my head, and I like that.
Biggest gripe I think some chambers needed more work. Jump inhibitors use too much power; in the last config version it was impossible to have a functional jump inhibitor ship with the highest level chambers because it uses more power than the reactor is capable of providing, leaving no room for thrusters, weapons or shields of any sort. At lvl 5 or so it left 40% power leftover after the inhibitor? Its a huge power draw at any stage, but the higher levels were free in terms of RC cost. On the flipside of that, its possible to build a permacloaked craft with maxed out chambers that has more than enough power left over to be a capable combat craft in it's own right. In fact I combined maxed out cloaking with maxed out scanning, made a perfect scout ship that still had power left over for decent weapons and shields to make a fighter that can handle ships around it's own size. So definitely gotta go through and make sure all the chamber combinations are working correctly, aren't too overpowered, etc.

I would also suggest going over how ship scanning and stealth work together; last I knew it was mandatory to have a stealth drive in pvp to prevent the enemy from being able to see your reactor and target it, which was hurting other viable alternatives. QF made the stealth drive super cheap in rc cost, but you'd still have to have it. If you made it it's own specialty scanner chamber, pvp meta would just adjust to demand that chamber + stealth drive to counter. I don't like removing a mechanic, but it is a pain in the ass and I can't think what to do about this aspect of pvp meta.

Only other thing was the high alpha weapons are surprisingly low-alpha. Like that strategy is totally unavailable as of the last QF config. Tbh I feel it should be available, and work needs to be done to allow it to be balanced and have it's own counters and drawbacks.

Oh, and the thread totally devolved into a bunch of nitpicking, arguing, even some name-calling by several parties. In fact this thread did too this last page. Nobody wants to voice their opinion or ideas if it's going to be nitpicked or just flat out lost amongst the aruments, we're losing good minds and a large portion of the community to exactly to this kind of behavior, guys, try to be cool for a change and consider the merits of other people's ideas, not just how it differs from yours.

 

[Scypio]

Don't know if these should be taken as approximations, but anyways, here are my findings (tested with a very small and a somewhat larger ship):

1.0 TMR = 108.8 m/s
2.0 TMR = 184.1 m/s
3.0 TMR = 262.5 m/s

Be sure to change the server.cfg (this one doesn't get overwritten everytime because it would mess up your world's files) and clean up your cache manually (just to be sure).

Only other thing was the high alpha weapons are surprisingly low-alpha. Like that strategy is totally unavailable as of the last QF config. Tbh I feel it should be available, and work needs to be done to allow it to be balanced and have it's own counters and drawbacks.

As said several times this is not a good game design to have alpha weapons. I said we (i) are open to talk about it and we also explained our opinion in our thread and why it was done this way. Because "alpha weapons doesn't feel like alpha" is not something helpful at all. What do you qualify as alpha ? What type of weapon ? And so on.

 

[DeepspaceMechanic]

Be sure to change the server.cfg (this one doesn't get overwritten everytime because it would mess up your world's files) and clean up your cache manually (just to be sure).

I replaced the contents of my testing install's server.cfg with the server config found at the Quickfire Github repository, and cleaned the cache.

New thrust test results (tested with tiny ship):

1.0 TMR = 123.3 m/s
2.0 TMR = 208.6 m/s
3.0 TMR = 297.5 m/s

3.0 TMR + Top speed chamber Level-1 = 327.2 m/s
3.0 TMR + Top speed chamber Level-2 = 357 m/s
3.0 TMR + Top speed chamber Level-3 = 401.6 m/s

 

[Scypio]

New thrust test results (tested with tiny ship):

1.0 TMR = 123.3 m/s
2.0 TMR = 208.6 m/s
3.0 TMR = 297.5 m/s

Sounds better, isn't ? With a bigger ship that you can really pin point the correct moment where you get round tmr you should get better numbers.
However yes, your point stands. 3.0 will never be equal to 300m/s exactly. Because of how the game is made in term of configs. To put it simply everything (config wise) is relative to 2.5 tmr so we have to work from that. And even knowing this there was some rounding stuff that made me become crazy at that time. So configs are approximately 100 m/s for 1.0 tmr. You'll have to deal with it until schema does something about it. And that is not likely to be coming soon because honestly 297.5 is close enough to 300 for the moment. There is a lot of stuff that needs to be done before this detail.

 

[EricBlank]

As said several times this is not a good game design to have alpha weapons. I said we (i) are open to talk about it and we also explained our opinion in our thread and why it was done this way. Because "alpha weapons doesn't feel like alpha" is not something helpful at all. What do you qualify as alpha ? What type of weapon ? And so on.

Ideally anything up to 16s reload time. I'm not scared of higher really, 30 seconds wouldn't be bad. We have both shield chambers for high and low damage protection, I thought they could be better put to use if there was such a thing as high and low damage in your own weight class, and to add an extra element of strategy to consider your opponents armament choices and factor them into your own.

I did see all the arguments and posts regarding why you really don't like the idea, but I'd like it to be implemented and balanced anyway, because it breaks up and counteracts the DPS vs shield recharge meta/strategy youve created. Id love to see other strategies too like e-warfare, but that will require new game features we don't have.

 

[Scypio]

We have both shield chambers for high and low damage protection, I thought they could be better put to use if there was such a thing as high and low damage in your own weight class, and to add an extra element of strategy to consider your opponents armament choices and factor them into your own.

Remember old weapons in the previous power system ? Everyone had a beam beam ion to drop other's shields. What choice was there at that moment ? Either bring one to compete or don't and be at a disadvantage.

Low damage chamber and high damage chambers aren't tied to low and high rate of fire weapon. That would be terribly reducting for theses chambers. Since the effects are ratio from the total capacity, you could, for example, lower your total capacity to have your opponent's weapons always triggering your high damage chamber. Or on the contrary invest a lot on shields to have the low damage chamber always triggered.

But hey. It's a complete new ship you need to build and it will be like a gamble. Either be right and win or don't and accept your fate. That's more than just pressing a few buttons in your chamber tree.

 

[Az14el]

Liking building with the QF changes so far, can finally build both compact & strong again without having to expand a ship hull too much for good stability & power;weight.

Inhibitor being 30% RC is a weird choice, they're often pretty critical to get a decisive combat outcome unless there's some gentlemans agreement not to run, whether or not people actually run into eachother is much more of a server side thing and shouldnt impact inhibs!
The cost ramps up a good bit which really seems like enough to me.

 

[EricBlank]

Sorry it took so long to reply, work and finding a new house (hopefully with internet access!) has been kicking my ass.

I totally understood that the shield high/low damage reduction chambers were tied to shield capacity. What I meant by changing strategy is more changing from a low damage reduction chamber (when an opponent is using something like a 100% Cc) to a high damage reduction chamber (if they were using a 100% Cb combo) But, actually, I have been thinking about ways to make my ships more modular and easier to modify on-the-fly, such as sections that are explicitly meant to be cut out, replaced or filled in.

There was talk of balancing higher alpha weapons with an overall efficiency penalty, which isnt a bad idea tbh. Say, 90% of the expected dps or 115% power consumption at 100% secondary support, that sort of thing.

---

Anyway, I've been messing around with the configs as they are on the dev build, and noticed some problems I hadnt before:
Firstly, the Beam weapon, in any of its combinations, doesnt appear to be able to damage armor. Like, at all. It works just fine against systems or shields, but armor seems to be totally immune to beam weapons.
Cannon and missiles dont seem to have this issue.

Then, I've messed with the shield damage reduction chambers a bit. I've found with a particular setup that three identical ships are not behaving as I expected (I could be bonkers here).
One of them has high damage protection. When hit with a Cb weapon from identical ship, it takes ~33% (of capacity) damage per shot
The copy without a damage reduction chamber takes ~29% damage per shot
The copy with a low damage protection chamber takes ~43.5% damage per shot

It's a bit bewildering, why a hit that clearly counts as "high damage" and thus is increased by the presence of a low damage protection chamber, also triggers a damage increase when the same ship is fitted with a high damage protection chamber instead of the expected reduced damage (I figure ~1/3 of capacity per shot should qualify as "high damage"? Seems high enough to me, but I havent been directly involved in writing the configs, I dunno whats going on behind the scenes on that one), and why a ship that has neither chamber is actually taking the least damage.

These are the ships I used in this test: 00Dumb_Base_Bb.zip
They were designed such that the shields use exactly 30% reactor power for recharge, the thrusters use ~15% (Didnt measure them) and the single weapon uses ~50% - when recharging the weapon, it sits at around ~96% usage for the B/b variant while thrusting, 107% for the C/b variant (is that intentional?)

I havent actually tested how it responds to a Cc or other low-damage-per-projectile weapon just yet, I got distracted looking at a new apartment today, so this is by no means comprehensive "science," its just a first experiment yielding results contrary to the hypothesis.

 

[Az14el]

^ beams are working fine versus thick advanced armor from my testing, 40k/tick beam has no problems taking out 5+ thick layers of it

was testing with beam-missile & beam-cannon though, possible it could be a beam-beam thing i suppose

 

[SchnellBier]

Just a friendly reminder that the configs in the dev build are always a bit outdated. If you find any weird behaving things you should consider testing it again on the quickfire server.