What career mode means for mods.

[asmi]

They don't need in the tech tree, only part mods need to be. I guess it will work for both career and sandbox without anything special.

That's my guess as well, but I would like to get official confirmation.

[PolecatEZ]

Even with the restrictions in place, there's no reason these modders can't just plop their new parts down on the very first tech node to become available. With 45 nodes and 160-something parts, it's obvious that nodes can have multiple parts.

I'm not saying that the devs should change their minds on this, just saying that this isn't a valid reason to support them sticking with their current idea.

I interpreted the idea to mean that they would restrict what went into the career mode while they were themselves balancing the system, as the presence of popular mods that will inevitably show up may heavily skew their test results when trying to construct campaign play. This makes perfect sense from a game design testing perspective. Its hard enough to balance your own catalog of parts without random additions. Mod makers may need to be satisfied with having their parts-based stuff in sandbox mode for at least the start of the testing period. Global mods may be a different animal, or they may also be restricted.

[Majiir]

Testing is exactly what the QA and Experimental Testing phases are for. Even if they need to collect data from players over a long period of time, they can filter out data that comes from modified tech trees.

Moreover, it's impossible to prevent mods from doing bad things every now and then. There will always be someone who makes an overpowered part or doesn't understand the value of progression in gameplay. The best thing about mods is that they're not controlled by the game developers, and that coin has two sides: you can install whatever mods you want, and you don't have to use any mods at all. If someone releases a mod that so egregiously misuses the tech tree, then don't play that mod. This simply isn't a problem. (It's also nothing new with tech trees. We don't keep mods from changing thrust values just because someone could make an overpowered engine!)

I strongly encourage Squad to revise its thinking on this.

[Fractal_UK]

Moreover, it's impossible to prevent mods from doing bad things every now and then. There will always be someone who makes an overpowered part or doesn't understand the value of progression in gameplay. The best thing about mods is that they're not controlled by the game developers, and that coin has two sides: you can install whatever mods you want, and you don't have to use any mods at all. If someone releases a mod that so egregiously misuses the tech tree, then don't play that mod. This simply isn't a problem. (It's also nothing new with tech trees. We don't keep mods from changing thrust values just because someone could make an overpowered engine!)

I strongly encourage Squad to revise its thinking on this.

I agree with Majiir on this.

I was previously very excited by 0.22 as a mod maker because of the potential that the tech tree actually offers to us in terms of design. Many of the parts in my mod fall into categories that would be towards the end of upper end of the tech tree and in order to not make the game too easy, I've had to constrain the advantages by other means, particularly resource availability. This certainly offers a partial solution but a tech tree represents both a superior alternative and a compliment to such methods.

Ultimately, the arrival of a tech tree itself is by no means an unprecendented step for a game and there are plenty of examples where such things have been implemented in games that offer excellent mod support, examples and inspiration for the developers can be drawn from such games.

The ConfigNode system in the game already seems ideally suited to creating technologies, all we need is another folder alongside the parts and plugins for unique technologies. Define the techs something like this:

TECHNOLOGY{
techid = exciting_technology
prereqid = boring_technology
name = Some Exciting Technology
description = ...
cost = 100 
}

Job done, everyone happy.

Edited October 1, 2013 by Fractal_UK

[Tiberion]

I think its perfectly reasonable to release the first iteration of the tech trees without modular support to see how the UI and gameplay features are accepted by the wide audience before taking the extra time to add in the moddability features. There could be minor changes to the core structure or a major overhaul required based on how things go. Not only would the time spent on the modularity be wasted, but it would be a major pain for the modders if their work balancing against the original system was worthless.

That probably won't happen, but I think its fine to delay the 2nd layer of the system until they're sure.

As for relaying on the test team to provide said feedback... no. That's a perfect way to set yourself up in an echo chamber and only hear the feedback you're expecting. Every KSP player is a wonderful flower, and I have seen things broken in some amazing ways after a pretty thorough testing period.

[Captain Sierra]

As someone who has been hard at work on something some might call OP (though I am trying to balance it), I'm gonna agree with Fractal here. The tech tree opens up a whole new realm of balancing options to work with. I think restricting the use of mods would hurt development a lot. This is a mod heavy game. It's easy to work on and has an amazing mod community. If anything, Squad ought to be encouraging modders to slot their parts in the tech tree. Then they can see how mod parts interact. After all, we all know how simple errors make big bugs (at least I do ).

As far as adding new nodes to the tree, I do forsee problems if every modder decides to add custom nodes. It would massively upset the tree. Perhaps, by opening the tree to mod support outright, devs can see what parts aren't fitting well and what other hidden nodes might be necessary to help the modding community which they helped to foster and grow categorize their stuff better.

[PolecatEZ]

As someone who has been hard at work on something some might call OP (though I am trying to balance it), I'm gonna agree with Fractal here. The tech tree opens up a whole new realm of balancing options to work with....

And that's what I'm trying to say about game design being a critical skill, case in point. In this example, mod creator assumes that things later along on the tech tree would necessarily obsolete earlier items and that simply placing more powerful or imbalanced stuff toward the end would be "balancing." A "tier" system where tech levels continuously obsolete certain parts and relegate them to just clogging up your catalog wouldn't be very desirable and doesn't fit this form of open game play.

Restricting use of mods in a brand new area temporarily while they balance out a new and shiny game play feature would not be unreasonable in any way. Players will still happily download your mods on their own merits and happily tick along in sandbox mode...and with all the more reason to do so unless they really like just playing stock in "career mode." This won't hurt your millions of dollars in profits from making your mods.

[dlrk]

Personally, I like career mode, but I wouldn't play KSP without mods. They have to be implemented.

That might change when stock equivalents to KW Rocketry, Kerbal Engineer Redux, FAR, and Deadly Reentry are implemented.

[Majiir]

Not only would the time spent on the modularity be wasted, but it would be a major pain for the modders if their work balancing against the original system was worthless.

Modders know that new systems are less stable. Moreover, we have no expectation that the API or game balance remains stable between updates. Modders can choose to avoid the R&D system if they're worried about things changing underneath them. For the vast majority of modders who aren't scared of such changes, access to the system would be valuable precisely so we can make balancing iterations while the R&D system is still in flux.

As others have mentioned, it will require little to no effort to support mods if the system was properly designed to begin with. (If it's really been architected such that mod support is difficult, Squad needs to seriously reevaluate their design process.)

As for relaying on the test team to provide said feedback... no. That's a perfect way to set yourself up in an echo chamber and only hear the feedback you're expecting. Every KSP player is a wonderful flower, and I have seen things broken in some amazing ways after a pretty thorough testing period.

Sure, but you can get a lot of good feedback from a QA process. They shouldn't need to dramatically change anything right after release.

[Tiberion]

I have no doubt its been designed with modding in mind. That doesn't mean support for that needs to ship with it. That would just be more things to test. Release the 1.0 version and it get functional, and then open it up.

The one thing that QA won't give Squad is playstyle feedback - what choices people are making, how they are and are not using the new systems. Most of the systems I have seen added have been adjusted once they were bounced off the public. Sometimes subtly, sometimes not so much.

[Tiberion]

To be clear, when I say "support for mods" I mean mods to the tech trees, not allowing mods into the default tree (which is happening)

[Majiir]

I have no doubt its been designed with modding in mind. That doesn't mean support for that needs to ship with it. That would just be more things to test. Release the 1.0 version and it get functional, and then open it up.

Can you articulate why it's necessary to keep it closed to mods? There's a large portion of the playerbase that plays stock, especially in the few weeks following a release (when mods haven't yet updated). If it's really about testing the waters, doesn't adding mod support only help that?

[Tiberion]

It's not that its closed, its that the moddable features are not added yet, and I am arguing that is okay. There is already a huge new system being added that needs play-testing, and taking yet more dev time to create the open API and then send that through QA and closed testing (with the inherent stability and security issues attached to such a system) might actually hinder the development process. Especially if they are already pretty far along on this 'update'

It's not that they won't add the API, just not for this update. Why is that so troublesome?

[Garek]

Wait, Maxmaps said the system will be open to mods, didn't he? Modders can add their parts to stock r&d nodes, or to those "hidden" nodes which probably are for stuff like 3.5m parts or Autopilots (MechJeb, kOS,...) or Fairings which aren't in the stock game, but in some very popular mods. The only thing Maxmaps said won't be possible is modding which nodes are there. I see the argument that this is needed to prevent mods blowing up the r&d tree by e.g. each adding there own 3.5m node. But I would trust modders to stick to the stock/hidden nodes where reasonable - and where not, the choice is between possible tec-tree-explosion and parts not being able to fit in the tree. Of course, if doing that needs serious extra work, I can understand if it moves to a later update, seeing how big .22 is already getting.

[HeadHunter67]

I would honestly be surprised if some enterprising modder doesn't find a way around this whole process, anyway. Even if Career mode was closed to mods at first (which seems unlikely), it's all just code - and if you can write code to keep stuff out, you can write code to allow it in.

So the more relevant discussion is in the "where does this fit?", and that's a matter that is beyond just one party - Squad can't answer that question for every mod, and modders can't make an informed decision on the matter without seeing the framework in which they'll have to work. Until then, this all seems academic.

[John FX]

The way I read it was "We have made a node system and put it out as quick as we could. This is how it works, there are fixed nodes because that is more simple. Feel free to try to put your own nodes on if you like but this is not supported right now because we have just released this and want to keep it simple to make sure it works and identify problems more easily. We are mod friendly and may change this later but not right now thanks"

Edited October 9, 2013 by John FX

[boomerdog2000]

Agreed. It seems similar to incremental programming. They want to make sure the base tech tree works before throwing all the mods in. They're obviously not ignoring modders since they put hidden nodes in.

[Belkaland]

How will Career Mod deal with Mods? New coding for the parts that allow it to be incorporated into the Tech Tree? Or will it have them blocked in Career mode?

Personally hope it'll be allowed in via new coding!

[HeadHunter67]

Probably in the same way as has been discussed in this thread, further down the very same page as your post.

[Aphox]

As far as I've heard, players will be able to place mod and stock parts among tech nodes through .cfg modifications. So, while career mode doesn't directly interact with mods by itself, a few modifications here and there can allow placement of parts in existing nodes, but players won't be able to create their own or change how the progression system works. *without plug-in assistance

And yeah, there's currently a discussion about it as pointed out in HeadHunter's post.

Edit: merged to old thread.

Edited October 13, 2013 by Aphox

[mach1]

I will definitely use mod parts in career and I will also be editing mod parts to better fit into my idea of how the tech tree should look. I might even take the time to create different MechJeb parts with blacklisted features that will progress through the tech tree.

that would be awesome.

[katateochi]

I will definitely use mod parts in career and I will also be editing mod parts to better fit into my idea of how the tech tree should look. I might even take the time to create different MechJeb parts with blacklisted features that will progress through the tech tree.

I hope that when you do that you will share your edits/thinking with us. It would be really nice if we (the mod devotees) work together to form a common mod tech tree, at least for the more main stream mods (B9, KW, NovaP, KAS, IR, etc).

[Specialist290]

Something that was on my mind when reading this discussion: How will the new system work with plugin-based "partless" mods like Kerbal Alarm Clock and FAR? I think it's been asked before, but I didn't see anything that addressed it earlier in the thread.

[HeadHunter67]

Since the tech tree (at least in its present configuration) only deals with parts, it's reasonable to conclude that any mod content aside from parts will be totally unaffected by the new R&D system. There's no reason to expect differently.

[TaranisElsu]

Something that was on my mind when reading this discussion: How will the new system work with plugin-based "partless" mods like Kerbal Alarm Clock and FAR? I think it's been asked before, but I didn't see anything that addressed it earlier in the thread.

Part-less mods like KAC and FAR should work in career mode, and should work from the beginning.

For some others, like my Fuel Balancer mod, I'm hoping for a way to query the current research progress and only enable the mod if a certain node or tier has been unlocked. My Fuel Balancer does not use a part, but I figure the functionality should not be available from the beginning. Instead, the functionality should be added to the ship computer after unlocking it.