KSP-RO / ProceduralParts

A continuation of StretchySRBs, which is a continuation of StretchyTanks
71 stars 79 forks source link

SRB overhaul needed #269

Open Chryseus opened 4 years ago

Chryseus commented 4 years ago

After looking at the tech progression and comparing procedural SRBs to stock parts it's pretty clear that they are way over powered giving anywhere from a 30% to over 100% increase in delta v for the same size, this largely appears to be down to the much larger sea level ISP of 250, the best stock SRB only has 210s and lower tech ones such as the thumper or RT-10 are quite a bit lower.

Reducing the sea level ISP to 200 helps quite a bit but you're still getting a big delta v advantage with early rockets, one option would be to limit the maximum size/volume but then you end up with a fairly significant difference in size.

I can think of two possible solutions, ISP upgrades as you progress though the tech tree or allowing limited user adjustment of ISP with a large cost premium for high ISP, although the latter would not help with a science game.

Lafreakshow commented 4 years ago

This doesn't just affect SRBs, All parts are more or less off in terms of balance. Some are too strong, some can't keep up with their stock alternatives. But the SRB is definitely the most noticable.

Ideally, Procedural parts should be more flexible than stock parts while being about on par in terms of stats. So I would propose to keep the values in line with stock limits but allow them to be a bit larger or smaller than stock parts allow at that point,. You can still see that this is how it was planned but over time many parts have drifted out of balance. A problem is also that Stock itself is far from balanced so it's dificult to decide which stock parts Procedural Parts should orient themselves off. Ideally one would go and look a the averages for a given technology level, then look for outlier among the stock parts, adjust for them and add increase by a bit so that Procedural parts are at all points in the game slightly stronger than the stock average.

I personally see an issue with balancing a mod perfectly along stock lines. If Stock and Mod parts are equally useful then why even use mod parts? Procedural parts has the advantage of being very flexible and the texture changing feature is a big plus too but I still think that PP should be slightly above stock in "desirability" so that there is a good reason to use them, but not so good that stock parts become useless.

An idea I had was to maybe allow procedural parts to be much more flexible in terms of shapes and size limits but give them slightly below average performance. As in, for example, the procedural tank can be considerably larger or smaller than other tanks available at the given tech level but it holds a bit less fuel per volume or has noticeably higher cost. This could even be justified in-universe as standardised, mass production ready parts tend to be cheaper than custom parts and less flexible matierlals are often more resistant, allowing for thinner walled pressure vessels but perhaps in limited shapes and sizes So according to this idea Procedural parts should be unbalanced in a certain sense. having them on the exact same level as stock parts doesn't make much sense to me.

Everyone who knows me even slightly knows that I'd very much like to have all these possibilities available, ideally configurable on a per part basis. But that of course also means a lot of work. Balancing the parts to fit in Stock alone is a lot of work already. So my concrete proposal here iwould be to balance the parts so that they have slightly less performance, are slightly more expensive but considerably higher flexibility than stock parts at any given technology level. This is a compromise between keeping them in balance with stock parts while still giving them their own unique niche.

In any case, this is just the rough idea regarding this topic I have in my head. Specifics would need to be worked out.

Chryseus commented 4 years ago

I agree there needs to be a cost to having the ability to precisely design a stage, as it stands the only real reason to use other tanks is for aesthetics, having them as a lower cost option would encourage their usage, as for SRBs having an ISP in the mid range would also encourage usage of the stock boosters, although scaling part cost with ISP would be a more flexible option.

Swamp-Ig commented 4 years ago

Heyas! So when I designed these parts many years ago I had a spreadsheet that plotted out the size/volume/power of each stock part and aimed to limit the parts in career mode to mostly match.

Like you say, the stock parts aren't balanced anyhow so it's hard to be consistent.

The limits were all set up in a file somewhere, and they can be hand edited for a particular purpose.

On Wed, 5 Aug 2020, 06:01 Chryseus, notifications@github.com wrote:

I agree there needs to be a cost to having the ability to precisely design a stage, as it stands the only real reason to use other tanks is for aesthetics, having them as a lower cost option would encourage their usage, as for SRBs having an ISP in the mid range would also encourage usage of the stock boosters, although scaling part cost with ISP would be a more flexible option.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/KSP-RO/ProceduralParts/issues/269#issuecomment-668846245, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABQGMTJQI5LEPCCC34BU57TR7CAMLANCNFSM4PURU6TA .

DRVeyl commented 3 years ago

Tweaking the ISP values at start is an easy enough MM patch.

Making them use the PARTUPGRADE system to unlock different ISP can probably be done in the custom Load method, which should get a shot at each of the applied UPGRADEs. A little extra complexity because the data is in the SRB_BELL subnode, and I'm not familiar enough with how PARTUPGRADEs apply to nodes versus key/value pairs.

Adding any thrust limits / modifying thrust1m https://github.com/KSP-RO/ProceduralParts/blob/master/GameData/ProceduralParts/Parts/Tanks/4SRB.cfg#L258-L263 would be very simple.

Cost scaling shouldn't be hard. Right now it is scaled by thrust and [KSPField] public float costMultiplier = 1.0f; Adjusting that value via PARTUPGRADE would be trivial. Adjusting the cost scale to be based on ISP and thrust is also a simple code change. So doing these things isn't to hard, the question is more what should be done.