MOVED! (Mods Please Lock Thread) Community Career Framework - A Balance Mod Standards Cooperative for Career Games (A Community Recommended Mod List that Commits to Working Well Together in Career Games)

[legoclone09]

27 minutes ago, DMagic said:

I'm not really sure either, still.

I haven't seen a clear answer if the intention of this is to point to a set of configs (tech tree, re-balance [both stock and mod], contracts) and say that CCF builds off of those, or if the intention is to simply say that this and that are supported by, or are compatible with, CCF.

Well the main intention is really to have a community run, as in anyone can join and leave whenever they want, standardized career balance for stock, with everything standardized and all mods compatible. I think we'll try to use stock standards for it.

[Yemo]

2 hours ago, DMagic said:

I'm not really sure either, still.

I haven't seen a clear answer if the intention of this is to point to a set of configs (tech tree, re-balance [both stock and mod], contracts) and say that CCF builds off of those, or if the intention is to simply say that this and that are supported by, or are compatible with, CCF.

It seems to me that the tech tree is such a core component of career mode that you can't really provide any type of balance or progression without nailing that down first.

Some other aspects of career mode, such as contract packs (or, from the sound of it at least, nightingale's strategy mod), make more sense to leave them as suggested or recommended. It's easier to point to contract packs that focus or different types of craft, or that encourage exploration and progression in a certain way and just say that they are supported, without greatly affecting other aspects of career mode.

Imho part balance, tech progression and contract progression do have interdependencies, but can be separated easily if some connections are accounted for.

1. One of the 2 main reasons for this is, that parts in ksp are usually not pareto superior to other, earlier parts, with some noteable exceptions.
Parts further down the tech tree usually just increase the repertoire of available stat combinations.
And often the partial exceptions to this rule are major balancing problems.

Eg when an engine is just massively better than 2 or 3 earlier engines combined. While in reality progress often reduces or replaces choices, in ksp that is usually neither desireable nor unavoidable, it is just bad balancing, especially when procedural parts and/or tweakscale are used.

2. The other main reason is, that the currently available tech trees (including stock) are not radically different from each other, with the noteable exception of some starting manned, while others start unmanned. Though for part balancing, that exception is nearly irrelevant, it mainly affects contract progression. One has earlier girders, the other has later girders, but that has little to no impact on girder stat balancing.

SETI is now set up with modularity in mind, though some old remnants from the previous structure are not yet dealt with (like the SETI ctt starting with the HECS probe core and using the stock probe models in a different progression).

I would assume that you could install ETT together with SETI-BalanceMod without any major issues, except for the probe core stats as a remnant of the old SETI structure.
 

1 hour ago, legoclone09 said:

Well the main intention is really to have a community run, as in anyone can join and leave whenever they want, standardized career balance for stock, with everything standardized and all mods compatible. I think we'll try to use stock standards for it.

The problem is, that stock has no standards or reliable balance.

As an example, install tweakscale and procedural parts and take a look at the stock cylinder RCS fuel tanks. Scale all of them to have roughly the same dry mass and roughly compare their volume and total mass/fuel capacity. There is not even a hint of balance. You can tweak a procedural RCS tank to get a better understanding of the magnitude of the discrepancy. If that is not devastating enough, add the non cylindrical RCS tanks. While RCS tanks have the highest discrepancies, the liquid fuel tanks are not volume/dry mass/wet mass balanced either. Which might be acceptable in stock, but is just devastating when you play with procedural parts + tweakscale + fuel switch.

And those are just 3 stats (volume + dry mass + wet mass/capacity) for one part category (fuel tanks) for the stock parts alone.

When you take a closer look, you realize that KSP does not work because it is well balanced, or balanced at all. It works because the restrictions (funds/tonnage/dimensions/crash tolerances/heat tolerances/life support etc) are so lax/unimportant, that part stat balance is totally unimportant for nearly all design decisions.

edit: This is compounded by the low dv requirements and the early availability of asparagus staging. No one really cares in ksp whether you have to put 4 tons into orbit or 5, or pay 10k funds instead of 12k...

They do become visible in challenges though, where you notice that 12m/s Landing Struts are routinely replaced by the lighter 50m/s Small Landing Gear or 80m/s structural parts and the used engine and command pod selection is pretty limited.

Edited January 3, 2016 by Yemo

[Probus]

On 1/3/2016 at 3:18 PM, DMagic said:

It seems to me that the tech tree is such a core component of career mode that you can't really provide any type of balance or progression without nailing that down first.

Some other aspects of career mode, such as contract packs (or, from the sound of it at least, nightingale's strategy mod), make more sense to leave them as suggested or recommended. It's easier to point to contract packs that focus or different types of craft, or that encourage exploration and progression in a certain way and just say that they are supported, without greatly affecting other aspects of career mode.

I agree with DMagic.  The tech tree and its balancing and part placement is core to getting things the way we want them.  The ETT is just a start at spreading the parts out so that the player can pick their own gameplay.  Not only can you have a game heavily in space planes or rockets, it also needs to let you choose things like what method am I going to use to explore with.  Probes vs. Kerbals; Ion engines vs. Giant rockets vs. Exotic propulsion.  Also, what sub-tech types am I going to use: robotics, micro satellites, rovers, SRBs.  That was one of the things that became quickly apparent when building the ETT.

On a functional note, the ETT needs to be converted into a database for easier nose placement and tracking branches and parts by part pack.  Right now it is 2 years of module manager part additions with not much structural rhyme or reason.  The ETT was for my own enjoyment really.  I just thought I would share it with the community because I enjoyed it a bunch.

Edited January 6, 2016 by Probus

[inigma]

inviting @KSP_Jack to this discussion.

[Probus]

Did we die on the vine, or is this thread still active?

[inigma]

3 hours ago, Probus said:

Did we die on the vine, or is this thread still active?

Still active.

To recap:

I think we've identified three areas CCF needs to address: tech tree, contract packs, part balances.

That said, having one person do it all can be a bit overwhelming. So I suggest we decide among us managers who be responsible for each of those areas for CCF compatibility.

 

The three CCF areas are:

1. Tech Tree - There is a need to decide on a tech tree for the CCF project, or at least a base tree. ETT seems more open and free to pick and choose which technologies to acquire logically than SETI, but SETI is more directly pointed in the direction of story-type historical progression.  @Yemo and @Probus, would you guys be interested in coming up with a tech tree together?  If you guys have separate visions with your current trees, would coming up with a tech tree together be a better idea that CCF can start from?

2. Contracts - Contract Packs are starting to take off, and already there is some possible contract overlap in development that needs to be taken into consideration by Contract Pack modders (mostly the early contracts).  At the very least, I think we need to agree on a progression tree (as mentioned in the OP) so we know where Contract Modders can "claim a stake" so to speak - not saying that if I develop for Airplanes that someone else can't - but to be CCF certified, their pack might need to disable mine, or at least acknowledge my pack's existence, since I was first to cover a certain area on the CCF progression list, else a player may have more than one "Fly to 2000m" contracts. Not sure how to get around this, except to have all Contract Pack authors "claim" a part of the progression tree initially and start filling in the gaps and encourage others to do so. I can manage this aspect of the project. @nightingale, @linuxgurugamer @severedsolo or @tjsnh, would any of you be interested in managing this aspect of CCF or do you want me to run with it (by laying out a progression tree and listing your packs on the progression nodes that your packs cover?

3. Part Balances - Part balances need an experienced decider for the project. If anyone would like to take responsibility for at least managing the part balance input/feedback from participants in this thread, please step up. I recommend a Google Docs spreadsheet if interested in sharing the data you collect. We would essentially use that sheet as the recommended balance values and link it to the CCF OP. @Yemo or @DMagicis this something you'd be interested in managing?

@Yemo would you be interested in converting all parts of your balance mod into a base project for CCF?

[tjsnh]

FWIW - It's probably possible for contract packs to contain a modulemanager .cfg patch that would disable overlap contracts in other packs - but it might spawn a bit of a "turf war"

[nightingale]

4 hours ago, inigma said:

2. Contracts - Contract Packs are starting to take off, and already there is some possible contract overlap in development that needs to be taken into consideration by Contract Pack modders (mostly the early contracts).  At the very least, I think we need to agree on a progression tree (as mentioned in the OP) so we know where Contract Modders can "claim a stake" so to speak - not saying that if I develop for Airplanes that someone else can't - but to be CCF certified, their pack might need to disable mine, or at least acknowledge my pack's existence, since I was first to cover a certain area on the CCF progression list, else a player may have more than one "Fly to 2000m" contracts. Not sure how to get around this, except to have all Contract Pack authors "claim" a part of the progression tree initially and start filling in the gaps and encourage others to do so. I can manage this aspect of the project. @nightingale, @linuxgurugamer @severedsolo or @tjsnh, would any of you be interested in managing this aspect of CCF or do you want me to run with it (by laying out a progression tree and listing your packs on the progression nodes that your packs cover?

As the one doing the development on Contract Configurator, I'd prefer to stay impartial when it comes to managing this type of thing.

[Yemo]

23 hours ago, inigma said:

[...]

1. Tech Tree - There is a need to decide on a tech tree for the CCF project, or at least a base tree. ETT seems more open and free to pick and choose which technologies to acquire logically than SETI, but SETI is more directly pointed in the direction of story-type historical progression.  @Yemo and @Probus, would you guys be interested in coming up with a tech tree together?  If you guys have separate visions with your current trees, would coming up with a tech tree together be a better idea that CCF can start from?

2. Contracts - Contract Packs are starting to take off, and already there is some possible contract overlap in development that needs to be taken into consideration by Contract Pack modders (mostly the early contracts).  At the very least, I think we need to agree on a progression tree (as mentioned in the OP) so we know where Contract Modders can "claim a stake" so to speak - not saying that if I develop for Airplanes that someone else can't - but to be CCF certified, their pack might need to disable mine, or at least acknowledge my pack's existence, since I was first to cover a certain area on the CCF progression list, else a player may have more than one "Fly to 2000m" contracts. Not sure how to get around this, except to have all Contract Pack authors "claim" a part of the progression tree initially and start filling in the gaps and encourage others to do so. I can manage this aspect of the project. @nightingale, @linuxgurugamer @severedsolo or @tjsnh, would any of you be interested in managing this aspect of CCF or do you want me to run with it (by laying out a progression tree and listing your packs on the progression nodes that your packs cover?

3. Part Balances - Part balances need an experienced decider for the project. If anyone would like to take responsibility for at least managing the part balance input/feedback from participants in this thread, please step up. I recommend a Google Docs spreadsheet if interested in sharing the data you collect. We would essentially use that sheet as the recommended balance values and link it to the CCF OP. @Yemo or @DMagicis this something you'd be interested in managing?

@Yemo would you be interested in converting all parts of your balance mod into a base project for CCF?

ad1. From my point of view there is not much difference between ETT and SETIctt, with regards to compatibility towards contracts and part balance. The main thing compared to stock is just (the possibility of) starting unmanned and early availability of aircraft/rovers. As long as that is the case, picking one over the other or locking on a new one would imho just diminish versatility without any benefit. Which imho is contrary to the idea of a "community" balance approach. It also increases the entry hurdle for new tech trees. Therefore I propose just setting standards and the complying tech trees are then marked CCF compatible, just like part mods. Eg start unmanned or with aircraft or both and the respective alternative is only a few science points away from the start, or something like that.

ad2. Inviting @Nori

ad3. I only have limited time at the moment, but I can contribute to it. We should agree on some basics regarding that. Imho the way forward in this regard is, to set standards, use MM patches to apply those standards to the stock parts and then just mark part packs compatible, which comply with those standards. Eg standards like:

1. 1EC/s = 1kW = 1kJ/s
2. Tank volumes eg for liquid fule/oxidizer based on procedural parts
3. Some engine rebalance, along the lines of what @stupid_chris did for 0.24: http://forum.kerbalspaceprogram.com/index.php?/topic/68170-024x-stock-rebalance-v14-110914/
4. Torque rebalance, asking @Crzyrndm
5. Crash tolerance rebalance
6. Heat rebalance, see DeadlyReentry from @Starwaster
 

Adressing one after the other while keeping it modular is imho the key. Starting with some horribly unbalanced stuff which we can be adressed easily using MM for the limited number of stock parts, like the tank volumes. SETIrebalance does not do that at the moment, so I do not have MM files for that, since I use procedural parts myself.

[linuxgurugamer]

On 1/10/2016 at 11:52 AM, inigma said:

2. Contracts - Contract Packs are starting to take off, and already there is some possible contract overlap in development that needs to be taken into consideration by Contract Pack modders (mostly the early contracts).  At the very least, I think we need to agree on a progression tree (as mentioned in the OP) so we know where Contract Modders can "claim a stake" so to speak - not saying that if I develop for Airplanes that someone else can't - but to be CCF certified, their pack might need to disable mine, or at least acknowledge my pack's existence, since I was first to cover a certain area on the CCF progression list, else a player may have more than one "Fly to 2000m" contracts. Not sure how to get around this, except to have all Contract Pack authors "claim" a part of the progression tree initially and start filling in the gaps and encourage others to do so. I can manage this aspect of the project. @nightingale, @linuxgurugamer @severedsolo or @tjsnh, would any of you be interested in managing this aspect of CCF or do you want me to run with it (by laying out a progression tree and listing your packs on the progression nodes that your packs cover?

I don't have a lot of time.  I'd be happy to cooperate with this effort, would be very helpful for some stuff I'm doing.  Feel free to loop me 

[legoclone09]

Wht not only use Procedural Parts? The rockets might not look very good but it will be balanced.

[Randazzo]

I think "Community" is a somewhat of a misnomer for this project. It's setting up to be incompatible with pretty much anything that isn't a part of the project. If you start patching stock parts to adhere to these guidelines it will only create unnecessary conflicts with other parts packs unless those mod authors decide to go along.

There's nothing wrong with setting some specific guidelines for those who want them, but call it what it is, like "Less-ridiculous progression framework". You might want something catchier than that.

Edited January 11, 2016 by Randazzo

[DMagic]

@inigma: I'm not sure how qualified I am to handle anything related to part balance. I, uh..., don't really play KSP much, so I'm probably not a good judge for that kind of thing (my method for balancing science with Orbital Science is to not really try...).

I could take a look at the contract packs available and try to make some sense of those, though. I mostly keep up to date with Contract Configurator (and I'm only aware of a few contract packs that don't use it) so that could be something I can handle.

 

59 minutes ago, legoclone09 said:

Wht not only use Procedural Parts? The rockets might not look very good but it will be balanced.

I think the idea is to provide standards and configs to allow for stock and mod parts to work together and maintain some semblance of balance, rather than forcing one particular set of parts.

 

38 minutes ago, Randazzo said:

I think "Community" is a somewhat of a misnomer for this project. It's setting up to be incompatible with pretty much anything that isn't a part of the project. If you start patching stock parts to adhere to these guidelines it will only create unnecessary conflicts with other parts packs unless those mod authors decide to go along.

There's nothing wrong with setting some specific guidelines for those who want them, but call it what it is, like "Less-ridiculous progression framework". You might want something catchier than that.

I don't think anyone said that this project should be all-inclusive, there are probably plenty of mods that don't make sense for a somewhat stock-alike career mode. If people don't want to contribute they don't have to. And if people want to have a pack included that isn't already supported they can introduce their own adjustments. The mod author doesn't have to do anything, that's what Module Manager is for.

[legoclone09]

Well the reason for Procedural Parts only as I just suggested is because it is not possible to find the volume of a part in the cfg files without calculating it yourself and putting it in, which would not work for having all mods.

[inigma]

Testing an initial CCF logo. Tell me what you think.

[legoclone09]

39 minutes ago, inigma said:

Testing an initial CCF logo. Tell me what you think.

I like it! Maybe in a slightly different font, in italics, and red for top, blue for bottom, and I think CCBF (Community Career Balance Framework) would be a better name for the project.

Edited January 11, 2016 by legoclone09

[kcs123]

I don't think that using procedural parts or tweakscale for tanks/craft hull parts will have huge impact on gamebalance.
What is most of influence for progression is how powerfull engines is available to player.

For that reason tweakscale/tweakscale everything should be limited somehow. For example, you should be alowed to shrink down parts, but not to enlarge them on Level one Research center building. Level 2 building could alow enlargment of parts up to 200% or just slightly more, while level 3 building will have no limits.

Restriction should mostly be focused on engine size limitation, having one big procedural fuel tank or 4 smaller ones grouped together have a same influence if you have the same engine that can lift those.

For fuel/tanks fuselage, especially when come for procedural parts and tweakscaled parts one of important gamebalancing feature could be materials used to create those parts. Some materials could be lighter, some heavier, some provide better heating performance, some worse, etc. That area is still not covered well in stock game when comes to gamebalance of career.

[inigma]

On 1/10/2016 at 11:06 AM, tjsnh said:

FWIW - It's probably possible for contract packs to contain a modulemanager .cfg patch that would disable overlap contracts in other packs - but it might spawn a bit of a "turf war"

Not sure if it that would work out well. I think the better approach might be for CCF contract authors to simply code in a Requirement set to check for completion by Any contract of the same type, within the CCF family.

 

Requirement

{

   name = Any

   type = Any

       Requirement

     {

     my pack: contract

     }

       Requirement

     {

     his pack: contract

     }

}

and go on from there.

On 1/10/2016 at 2:08 PM, nightingale said:

As the one doing the development on Contract Configurator, I'd prefer to stay impartial when it comes to managing this type of thing.

No worries. I think CC makes it easy to already check if contracts exist from other packs as part of its requirement structure. Should make CCF compatibility rather easy to do when on considers similar contracts in other packs.

[inigma]

7 hours ago, Yemo said:

ad1. From my point of view there is not much difference between ETT and SETIctt, with regards to compatibility towards contracts and part balance. The main thing compared to stock is just (the possibility of) starting unmanned and early availability of aircraft/rovers. As long as that is the case, picking one over the other or locking on a new one would imho just diminish versatility without any benefit. Which imho is contrary to the idea of a "community" balance approach. It also increases the entry hurdle for new tech trees. Therefore I propose just setting standards and the complying tech trees are then marked CCF compatible, just like part mods. Eg start unmanned or with aircraft or both and the respective alternative is only a few science points away from the start, or something like that.

ad2. Inviting @Nori

ad3. I only have limited time at the moment, but I can contribute to it. We should agree on some basics regarding that. Imho the way forward in this regard is, to set standards, use MM patches to apply those standards to the stock parts and then just mark part packs compatible, which comply with those standards. Eg standards like:

1. 1EC/s = 1kW = 1kJ/s
2. Tank volumes eg for liquid fule/oxidizer based on procedural parts
3. Some engine rebalance, along the lines of what @stupid_chris did for 0.24: http://forum.kerbalspaceprogram.com/index.php?/topic/68170-024x-stock-rebalance-v14-110914/
4. Torque rebalance, asking @Crzyrndm
5. Crash tolerance rebalance
6. Heat rebalance, see DeadlyReentry from @Starwaster
 

Adressing one after the other while keeping it modular is imho the key. Starting with some horribly unbalanced stuff which we can be adressed easily using MM for the limited number of stock parts, like the tank volumes. SETIrebalance does not do that at the moment, so I do not have MM files for that, since I use procedural parts myself.

ad1 - great! at this point then, if you and @Probus can self certify that your tech trees allow for the progression in the OP, then you are welcome to be the first to claim CCF certification. If you do, let me know, and I'll post a new OP in Add-On Releases for CCF's formal CCF mod list and we can start moving this conversation over to the new thread there.

ad2 - great to have more eyes on this

ad3 - Feel free to setup a spreadsheet that outlines the basic areas to be filled in later. Call it CCF Standard Costs, Outputs, Rewards and Experience if you wish. Send me a link!

3 hours ago, Randazzo said:

I think "Community" is a somewhat of a misnomer for this project. It's setting up to be incompatible with pretty much anything that isn't a part of the project. If you start patching stock parts to adhere to these guidelines it will only create unnecessary conflicts with other parts packs unless those mod authors decide to go along.

There's nothing wrong with setting some specific guidelines for those who want them, but call it what it is, like "Less-ridiculous progression framework". You might want something catchier than that.

Actually Community is defined by those participating in the development of the CCF project. It's not a one-man show and is totally open to outside development - hence "community." Anyone may participate by contributing coding and development time. The progression framework exists for tech trees to certify compatibility with less-rediculous progression. The same for contract packs. Part balances are a different matter. Between community input and development in all three areas of Career progression and balance, CCF is born.

2 hours ago, DMagic said:

@inigma: I'm not sure how qualified I am to handle anything related to part balance. I, uh..., don't really play KSP much, so I'm probably not a good judge for that kind of thing (my method for balancing science with Orbital Science is to not really try...).

I could take a look at the contract packs available and try to make some sense of those, though. I mostly keep up to date with Contract Configurator (and I'm only aware of a few contract packs that don't use it) so that could be something I can handle.

 

I think the idea is to provide standards and configs to allow for stock and mod parts to work together and maintain some semblance of balance, rather than forcing one particular set of parts.

 

I don't think anyone said that this project should be all-inclusive, there are probably plenty of mods that don't make sense for a somewhat stock-alike career mode. If people don't want to contribute they don't have to. And if people want to have a pack included that isn't already supported they can introduce their own adjustments. The mod author doesn't have to do anything, that's what Module Manager is for.

Great! I'll add you on the contract 'team' to help get that ball rolling. I was wondering if we should start mapping the currently available (interested) contract packs for Career onto the progression framework to see what fits where, see what overlaps, and see what's missing. Thoughts?

1 hour ago, legoclone09 said:

I like it! Maybe in a slightly different font, in italics, and red for top, blue for bottom, and I think CCBF (Community Career Balance Framework) would be a better name for the project.

Great ideas. I'll redesign it later tonight.

[inigma]

55 minutes ago, kcs123 said:

I don't think that using procedural parts or tweakscale for tanks/craft hull parts will have huge impact on gamebalance.
What is most of influence for progression is how powerfull engines is available to player.

For that reason tweakscale/tweakscale everything should be limited somehow. For example, you should be alowed to shrink down parts, but not to enlarge them on Level one Research center building. Level 2 building could alow enlargment of parts up to 200% or just slightly more, while level 3 building will have no limits.

Restriction should mostly be focused on engine size limitation, having one big procedural fuel tank or 4 smaller ones grouped together have a same influence if you have the same engine that can lift those.

For fuel/tanks fuselage, especially when come for procedural parts and tweakscaled parts one of important gamebalancing feature could be materials used to create those parts. Some materials could be lighter, some heavier, some provide better heating performance, some worse, etc. That area is still not covered well in stock game when comes to gamebalance of career.

kcs123, go ahead and work with @Yemo on a CCF balance spreadsheet. I think you guys would work great together on these and other part balance ideas.

 

 

Thank you to everyone who has so far participated in this discussion. This will hopefully be worth it all in the end, and if not, then at least I hope we all learn something valuable about working together.  I appreciate your feedback, as well as do others reading this thread.

Here's looking forward to the start of something positive.

[linuxgurugamer]

34 minutes ago, inigma said:

No worries. I think CC makes it easy to already check if contracts exist from other packs as part of its requirement structure. Should make CCF compatibility rather easy to do when on considers similar contracts in other packs.

It does ( the AcceptContract and CompleteContract), but ModuleManager has no idea about contract packs.  This is why I'm now bundling a dummy DLL with my UnmannedMissions (and will soon add to others) so that MM can be used to modify contracts based on whether other contract packs are installed or not

Maybe we should make it part of the requirement that a dummy DLL be bundled for this reason.  Very easy to do, and I'd be happy to create a dummy dll for anyone who asks.

[RoverDude]

4 hours ago, Randazzo said:

I think "Community" is a somewhat of a misnomer for this project. It's setting up to be incompatible with pretty much anything that isn't a part of the project. If you start patching stock parts to adhere to these guidelines it will only create unnecessary conflicts with other parts packs unless those mod authors decide to go along.

There's nothing wrong with setting some specific guidelines for those who want them, but call it what it is, like "Less-ridiculous progression framework". You might want something catchier than that.

I concur.  Personally, I balance my stuff against stock, and where there is not a stock analogue, against the work of other modders that I enjoy working with (Nertea, etc.) and that has worked pretty well (it's also where we got CTT - who's very non-invasive nature I am a big fan of).  I am going to respectfully ask that alternate configs NOT be included for any of the USI mods, because alternate tech trees and rebalances have caused me support headaches in the past.

[inigma]

3 minutes ago, RoverDude said:

I concur.  Personally, I balance my stuff against stock, and where there is not a stock analogue, against the work of other modders that I enjoy working with (Nertea, etc.) and that has worked pretty well (it's also where we got CTT - who's very non-invasive nature I am a big fan of).  I am going to respectfully ask that alternate configs NOT be included for any of the USI mods, because alternate tech trees and rebalances have caused me support headaches in the past.

Then how would you like to see the CCF project be modified so as to accommodate the USi mods as part of its recommended/compatible mods? What would you like to see from a community based Career balancing project?

Edited January 12, 2016 by inigma

[Probus]

On 12/17/2015 at 1:37 PM, inigma said:

CCF - Community Career Framework - Community Standards for Balance Among Career Mods

Modular Progression Framework:

ground vehicles & boats > submersibles > aircraft > sounding rockets > unmanned rockets > probes > manned spacecraft > rover landings > manned landings > space stations > spaceplanes > bases > colonies > interstellar

• Research for each module family would offer components that are most rudimentary/basic first, dependent on having researched only historically related technologies offered in Progression Framework nodes before it.
• Contracts for each module family would offer targets that are not explored, closest first.
• Mods in all families would have balanced outputs, costs, and rewards vs all other mods in all families in order to self-certify as CCF compliant by adhering to the CCF Standard Costs, Outputs, Rewards and Experience worksheet (CCF SCORE - hey I like friendly acronyms)

The idea behind the Modular Progression Framework is to certify that balances will still exist if a career player removes any of the module families, such a player who cares not to start with ground vehicles or subs, and wants to skip straight to manned spacecraft but remove colonies and interstellar module families would still find a reasonably balanced and thus playable game.

As far as techtrees go:

I agree with all your bullet points.

I am definitely a fan of technical discipline progression.  But, for example, if by the above framework you are saying the player must HAVE to have aircraft before sounding rockets, I don't like that idea.  You can have sounding rockets OR aircraft. Alternately you could have sounding rockets AND aircraft. Its up to the player and split by disipline.

The flip side of that is you have to have aircraft if you are going after space planes.  If you want your entire space program to be unmanned then you should be able to.  If you want it all to be manned then you should be able to do that also.  Another example would be if you are only going to use solid rockets for exploration and bypass liquid rockets, the player can do that also (although I wouldn't recommend it ). 

The tricky thing is multi-discipline parts.  There is not an easy solution for that unless the branches happen to be close to each other.

We also don't want to have a million nodes.  I don't like adding new nodes to the tree, but there are going to always be exceptions.  I spend most of my Kerbal time balancing the tech tree and adding/updating part packs.

I am very, very open to modifications to the the Engineering Tech Tree, both in node placement and part placement.  I love when modders give me a module manager file with their part pack.  Saves me a bunch of time.  Right now just keeping up with existing part packs is a chore.

If the above meets CFF rules @inigma then I'm all in. 

Also, I would like for us to set up an IRC channel.  Are you OK with that inigma?  Maybe #CCF ?

Edited January 12, 2016 by Probus

[Probus]

Maybe #CCF ?