sherkaner

Ugh, I'm kind of stopped now actually. I'm finding a lot of weirdness in TechManager when trying to define a tree that's totally different from stock. It seems like most people are just using it to rearrange stock nodes or add on mod parts, but not really the dramatic stock parts reorg that I'm trying. So I think I'm running into problems others haven't seen. Hopefully I hear back from the developers.

Hope this tool is still being developed. I'm having some issues creating a tech tree for TechManager: Each node has a "techID" attribute which Tree Editor doesn't seem to populate properly. I found a bunch of stock-looking values in those, even though I had created completely custom nodes from scratch. Loading this file caused a bunch of unwanted parts to show up in my nodes. I hand-changed the techID values and everything started behaving normally. It seems that a number of part names are incorrect, at least in 0.90. I'm not sure if they've changed. But this is causing various parts to not show up in nodes they're attached to. I don't have a comprehensive list, but for example Tree Editor uses "Large_Crewed_Lab", but I believe this is supposed to be "Large.Crewed.Lab". Is an update to the parts list in the works to fix these? Edit: Actually I'm not sure about #2 above now. Although the part names are different in the .cfg file TED spits out compared with, say, one of the .cfg trees that come with Tech Manager, when I try to hand edit them in my file, they still don't seem to show up in the game! I have no idea why this would be. Any ideas? The more I look at this, the more I think it's an issue with TechManager not TED though

I'm pretty confused by the behavior of .cfg files in some cases -- basically it seems like parts appear in nodes where they're not actually listed in the .cfg file. For example I load up the KSPI .cfg file. In "node5_supersonicFlight" there are 6 parts listed, but in the game that node lists 12 parts! I can't figure out how those other 6 parts are getting in there. This has to be related to the issue I'm having creating a fresh .cfg file where I'm not actually sure how to include certain parts because they don't seem to appear in the KSPI or NearFuture files (even though they do appear in those trees in the game). For example, I can't find the part name for the Mk2 Cockpit, which shows up in that node I mention above, but isn't actually listed in the .cfg file for that node. Help!

Yeah, a bit. I did move them up, but decided that I wanted the player to go from the cylindrical LF/O tank to a cylindrical monoprop tank before branching off into the radial monoprop tanks. Yeah, I'm looking forward to it too. I've been making some progress of making a .cfg file for Tech Manager. Since this tree is going to be pretty damn big, I've been using the little Tech Tree Editor app that somebody else made. It's working, but there's some bugginess making it a little difficult; it's definitely going to take some real time. Nonetheless, I'm getting it to work and I've already gotten the Pods, Habitats, Labs & SAS section pulling up in the game. Once I get it done, I'll post another dev thread with it yeah. Although I'm hoping Squad is still paying attention to this suggestion thread, as deep as it is now...

Ehhh, the RC-001S has more capability (has reaction wheel as well as extra direction hold features) and costs a lot more than the OKTO2. I don't entirely disagree with your reasoning, but as the parts stand there's no question that the thermometer is just a simply better instrument than the Goo, so from a gameplay point of view, I think the order I'm using has to be the way it is. That said, I'd be in favor of Squad rethinking the nature of science instruments to feel less silly, in which case that ordering would be rehashed. True.

By the way, a side thought occurred to me while I was putting this together: A possibly interesting "very hard mode" option using this tech tree could be to not actually allow the player to choose the pathway through the tree by researching a part directly, but instead just give resources to one of the four R&D "departments" (the 4 color groups I have on the left) and have the actual part unlocked within that department as a result be random. New developments would still have to follow the pathways of the tree, but which branches you take wouldn't be under your direct control, but come as the result of what the boys in R&D happened to come up with. So you'd still be able to focus your effort generally, but you might have to adapt your plans if your team ended up making you really good at certain things you weren't quite expecting. Definitely should only be an option for very experienced players, but it seems like it might be neat.

Okay, version 2 of the per-part tech tree: I think I worked in nearly all of the suggestions made, as well as some other tweaks and fixes. I even took at shot at the wings, although it still feels pretty bogus -- at least it's something though. I'm going to start trying to beat this into a .cfg file -- I'm pretty hyped to actually play this.

1. True, agreed. 2. Good point. It seems like a not-insignificant gameplay change to have people starting with the super-small parts, but I see what you mean. 5. Ah, right. Level 3 prereqless it is. 7. Uuugh. If anybody can cut through that and tell me if my intake tree could be done more sensibly, please post it up. But this also seems like a thing that should (I would hope) be reworked along with 0.91 aero. 8. Agreed. 12. Agreed. 13. Sensible, I'll put that back. For the sake of the .cfg file, I may also redo that whole section for the realities of the current science system (ie. Goo needs to come first) as much as it annoys me. I'll post a new version soon.

Gah, don't give up, I want to hear it!

By the way, I looked into the piloting abilities of the various drone cores and actually (mostly by accident), I think I've gotten the order just right. Stayputnik has nothing, QBE has only basic SAS as does OKTO, HECS adds prograde/retrograde hold, then heading into R&D level 2 OKTO2 adds radial/normal hold, and then beyond to the RC and Mk2 cores that add the rest. By the way, I imagine that probe cores in this system will be -- even if available early -- be quite pricey since piloting skills are at a premium. Given that even basic SAS is a big deal now though, I imagine the costs for go up to even QBE may be pretty significant.

Actually I agree with you, I think I'll move solar panels in a bit deeper. Not much though to be honest -- to me it's kind of silly to have to strap batteries all over a craft for lack of basic solars. I don't really see how that makes the game any more fun, or poses any interesting design challenges to the player. I don't see what you mean. Well, I would be shocked if that ability doesn't go away in 0.91 with the aero revamp. Clearly the chair is not meant for atmospheric traversal ultimately. For rockets? If so that's news to me (although perhaps you're right), and would indicate that jet engines probably need some rebalancing as a part. I expected somebody to mention that, and you're right. I made the assumption (without saying so until now) that the thermometer's science return would be scaled back significantly to be placed where I have it. I'm actually assuming that *all* of the science instruments are going to go through a pretty enormous rebalancing as I don't think they make a whole lot of sense right now. So that part of my tech tree is probably the least immediately-correct section in the entire thing. You're right, but I'm not going to concern myself about that too much. I'm more interested in getting the general flow of the R&D right, and the costs can trivially be adjusted later to fit it. That said, I'll at least try to come up with some sensible costs with an updated .cfg file, but don't expect me to put a huge amount of thought into fixing the overall game-pacing problem.

First, thanks a lot for looking in detail and giving these suggestions. I'm going to reply here with my thinking on these, although I'm not very defensive at all about any of them. My thinking is generally based on a combination of gameplay and what I'll call storytelling (ie. in-game realism) reasons. Gameplay: Although I like the idea of having the stability enhancer much earlier in the game, I thought it would be good to have it at least not in that set of first-column parts (which again, I might even consider to be starting freebies). Storytelling: I figured that R&D would apply radial decoupler technology to the stability enhancer's breakaway. Yeah, I struggled with that and you'll see that I applied a similar chain to a variety of parts (nose cones, rover wheels, docking ports, fuel tanks, liquid/solid engines...) for the following reasons: Gameplay: The medium version is the one that the player is really going to need to use first, and so I considered the smaller and larger ones to be variations on that. I didn't want to start them with a smaller part that could be confusing by not being immediately useful. Storytelling: I head-canon'd my gameplay choice by saying that both miniaturization and up-sizing the nominal medium part would take R&D work, with the medium being the nominal case on which other versions would be based (since it would be needed first practically). See #2 See #2 Hm, I just sort of found it in that category and didn't give it much thought (beyond adding that input line from the OKTO on the idea of it requiring some control tech). But yeah, it doesn't seem very connected. Perhaps I'll just make that a prerequisiteless level 2 part? Holdover from an earlier version that I forgot to delete. Oops. Early on I thought that there might be a requirement of developing the cockpit to prove "Mk2 technology" before any other Mk2 parts, but I did away with that. Unless I'm failing to understand something (very possible), I thought that was the most advanced intake part, looking at the specs. It's quite small, strong, radial mounted, and sucks as much air as the whole Mk1 fuselage intake. The intakes kind of confused me though to be honest. You'll notice I didn't even include the XM-G50 because it makes no sense to me. But I'm very open to guidance on a better way of structuring the intake tree overall. Hm, in retrospect, no really good reason. Maybe I'll pull the Stratus-V parts back into level 1 as branches off the FL-R25 or even the FL-T200? Mostly storytelling: They're similar-looking radial tanks. But especially with #8, maybe those are just prerequisiteless level 3 parts. Gameplay: I wanted to avoid having the RCS thrusters in the first column since they won't be useful to a new player immediately (but I did want them available quickly). Storytelling: The Rockomax 24-77 serves as a proof-of principle for smaller thrusters not based on big LV-style motors with big bells, but quickly gets spun off into a separate chain of monopropellant and LF/O thrusters. Gameplay: The Vernor is pricier and uniquely provides LF/O RCS functionality. Storytelling: Actually I didn't pay attention to this -- really I should have the Vernor follow from the LV-1R (ie. compact radial LF/O engine), not the O-10 (monoprop based). The O-10 feels like it should follow only from the LV-1R as well, as a monoprop-based derivative. I'll change that. I went back and forth on that. Storytelling: It seemed "cute" to have it dependent on advanced electrical technology, given how ion engines work. But yeah, I could have it be a prerequisiteless level 3 part if it seemed onerous to force the player to plunge through battery tech to get there. I still sort of like it as is to make it feel more unique, but I could be convinced. Storytelling: I vaguely was classifying the science instruments into "direct measurement" and "sample observation" and in my head canon the gravioli detector was using some kind of substance as a detection intermediate, sort of like those huge underground water pools for neutrino detection. But my feeling on this (and the science tree organization in general) is super super weak. With all that said, honestly if you disagree with my reasoning on any of these, I'd tend to defer to your judgment as I'm not yet as deep a KSP player as you or many others. So definitely let me know and I'll work on a rev of this that I can use as a basis for a tech tree .cfg file for us to play with (although of course any of you guys would be able to mess with a .cfg file that I make anyway).

Oh yeah, agreed. The only reason I'm talking details here is that it actually seems like I might be able to put something together to play with now. But for Squad, I hope this will mostly just show that this idea is a good one and can be balanced out to be a more satisfying approach than what we can currently.

Ah, yeah, I do actually. They're basically just screenshots from the KSP wiki, but for convenience here you go: http://www.filedropper.com/kspparts

You make some good points, and I there are a couple of places where I sort of wanted to have multiple prerequisites (the LFB KR-1 was one in particular). But I just felt like there weren't enough parts to justify forcing people into building out whole branches just for a prerequisite. I think if Squad were to add a lot more endgame parts, that's where I'd be most in favor of it to make people work a little harder for really awesome high-tech stuff. But it might be interesting to try. Basically anywhere that I have multiple input lines to a part, it would be easy enough to create a version of a tech tree that treats those as prerequisites rather than options. I might try both. True, I might be able to split up the procedural parts a bit that way, within R&D level 2, good idea. The non-procedure stuff (that I'm lumped into R&D level 1) is where I'm just totally baffled. But I think those are also probably the ones likely to change a lot -- especially with the mention that Squad's looking at aerodynamics soon. So just for the sake of playtesting this tree for now, I'll probably just throw all of those into one or two nodes and call it a day. That was my feeling mostly also, and pretty much what I have in the diagram I think. Any in particular there that you'd disagree with? I'll definitely start trying to get this dumped into a tech tree .cfg file in the coming days. Keep the input coming!

I debated on the processing lab. I kept it in habitat just because it does contain Kerbals and so purely R&D wise I thought of the main development of the lab (as opposed to its usage) would be more similar to pods and landing cans. And yeah, I need to look into the QBE -- good point. I was making the assumption that it was very basic (and cheap), but I'm actually not sure with 0.90. I probably need to do some sandbox play with the new probe cores in general before I settle that branch. Yeah, that's going to be interesting. Clearly each node is going to have to be much cheaper than current (since you're only getting one part generally), but because the player can be very selective, you can probably make the parts somewhat expensive. I'm open to suggestions, if somebody with more career experience wanted to mark up my tree with costs...

Okay, here's the tech tree I've been working on incorporating all stock parts. It's in linear format, but of course it could be wrapped into an explosion format. Of course I think we're all expecting Squad to modify, rebalance, and possibly add parts during beta, but I was surprised how well this worked out even using today's parts -- vastly better than the grouped tree we have today for providing flexibility and a sense of guiding a "real" R&D program, while still providing challenges and tough choices: Note: New version of this diagram now posted later in this thread here. Yeah, it's huge. The guiding principle here is the "per part" nodes concept we've been discussing where each part type essentially has its own branch in the tree with a sequence of branching nodes for more and more advanced versions. I've tried to stick to that philosophy pretty closely, but here are a few additional background notes: If you look at the first parts in each category on the left, I think those provide a very nice cross-section of basic parts that will provide players with many choices but not be too "overpowered" or get the player in trouble researching useless parts. Basically with those you can create a basic rocket, plane, or rover and do a little science. I think these might even be parts to just give the player outright. You'll see that I sometimes have multiple inputs to a single node -- these are meant to be multiple options of getting to that part, NOT multiple prerequisites. I did this in places where there were "realistic" feeling different ways you'd get to a certain technology by different paths, and also to add flexibility in places where -- for example -- both spaceplanes and rockets could use a part and I wanted to avoid forcing somebody to dig through a tree branch they'd otherwise be uninterested in. While I generally stuck to "one part per node", I do group a few parts together that were so similar that making them separate nodes seemed ridiculous. I basically punted on the wings section, describing in general terms what I think should be at the different R&D levels. These were the only parts that seem so "broken" currently that organizing them was almost nonsensical. The pre-procedural wing/fin parts just make no sense, but I wager all of that is about to change soon anyway. I could use some input on the structural (i-beams, girders, etc.) parts. I haven't had much opportunity to use those yet, so I'm not sure how well my choices play out. But generally I think these parts should be available sooner rather than later. Anyway, looking forward to hearing what people think, and maybe after I make some revisions I'll work on getting this into a .cfg for TechManager so we can play it. Personally I'm super-excited about playing a career with something like this tech tree. I can imagine a lot of very different-feeling programs being played through this tree to a high level with very different sets of technologies unlocked. And as an engineer, this to me feels like something much closer to the organic way that real technology developments evolve and arrive at solutions from different angles.

Ah, nice, it looks like the .cfg files that KSP/TechManager use are fully flexible for defining nodes as well as parts within, so totally doable for me to create the tree we're talking about. Might even be able to have it in "explosion" format. It'll take me some time though. I'll get the diagram up first later this evening.

Yeah, I need to look at this mod more and figure out how much I can define. I'm really hoping to do away with the default nodes and define nodes that almost always contain one part. Stock parts only obviously. Not sure if the mod is that flexible though. Either way I'll post my tech tree diagram organized that way so you guys can critique.

I've been playing with taking the current parts and actually dropping them into a tech tree like we're talking about (I'll probably post that here soon). Among other things I'm realizing as I work through it, I think a "starting node" really may not be necessary. I think the main purpose of starting node parts is so that you don't have players making bad choices with their starting science that leave them unable to do anything, but in practice I'm finding that with just a few logical dependencies you end up with a set of initial choices of parts that are *very* flexible in letting the player choose what they find interesting, but don't easily let you "waste" science on stuff that doesn't work. Alternatively, it also seems like you might just give all of the entry point parts to a player off the bat to encourage them to play around without feeling like they have to make choices they can't undo. I don't think it would be so bad to give them the parts to build a very very simple rocket, plane, and rover automatically. Plus I'm just overall finding that (surprisingly to me) even with the current stock parts you can create a pretty satisfying tree that feels both realistic (ie. the dependencies feel like meaningful progress on a part type rather than arbitrary) and seems like it would balance out gameplay wise. I'm liking it so much, I may take a shot of putting it into a config file for the custom TechManager mod so I can play a career with it. I'll definitely be interested in feedback from you guys first though.

I'm a big fan of more early game aircraft, but honestly I think starting it at the jet age makes a lot of sense. The basic jet engine should be moved to the bottom of the tech tree along with a fixed wing, gear and mkI cockpit. But I think propeller-driven flight goes a bit unnecessarily far -- what would they offer that a simple jet engined craft wouldn't? Or if you want to take a historical perspective, we came out of the WWII with both liquid/solid rockets and jet engines so it makes for a nice sensible technological starting point.

I very much like the Stayputnik as a simple early game option. I do agree that it should show up earlier in the tech tree however -- ideally right at the start of the game where it makes the most sense as an alternative to endangering Kerbals on high-risk test missions. But I've used it for a lot of stuff, like the orbital rescue mission, as someone else said.

Precisely what I was poorly trying to describe. I think that's perfect.

Oh yeah, fair enough, I wasn't expecting it to be fully fleshed out. But still, the starting point seems pretty darned limiting, which surprised me. I just hope that their vision for the system is to be much, much​ for granular in how Kerbals get XP.

Katateochi's idea does offer an interesting way of gently having technology "eras" like I was talking about a bit earlier in this thread. Basically our general scheme here gives you a lot of flexibility in what you research, but the limited number of "slots" means you can't go *too* far in any particular area. Although to do that, I think you'd want to have the "slot" unlocks be across the board, rather than per-tech-type. Otherwise, as Kipard says, it's just a different name for spending science to get the next part you want. In fact a pretty obvious idea would be to have one's general technology level -- whether implemented in slots or some other way -- tied to the R&D center building's upgrade level. (In in-game terms, once you upgrade your R&D generally, you now have better materials, design techniques, etc. that allow you to go beyond certain limits for all of your part types.) That's sort of what that building upgrade does today, but it makes a lot more sense with the techsplosion tree since the current tech tree sort of limits how far you can go in any area already by "virtue" of its somewhat nonsensical groupings. With a fully flexible tree, having that limit on technology era makes more sense. That would be sweet -- good and interesting gameplay choices with that. You can pick un-gimballed engines, which would be perhaps cheaper to obtain as well as build, for an earlier advantage but later on in a career you'd end up having to start investing in more fins or reaction wheels to provide stability.