sherkaner

Okay, version 0.2 has been posted to add science cost to all first-level parts. It is now recommended that players manually start themselves with 30 science points (the minimum above zero the slider allows) in order to make their initial part purchases.

From Ted's part of today's devnotes: I assume you're on this, Kip.

I would just put your tree (with whatever name) into the GameData/TechManager directory, load up your save game, and then hit alt-F7 to switch to the tree you want. After that, the same game should remember I believe.

Right, that's my plan (now). Yeah, that is annoyingly still the case. I actually added a note to the command seat node explaining this. I have to assume that that limitation was put on the command seat to keep people from using it as a light-weight cheater capsule since the aerodynamics in the current game won't put a stop to using it at high atmospheric speed. But I also assume that limitation will go away in 0.91 with the aero revamp and part rebalance.

I do kinda like the idea of improving parts as you get experience with them. But I think that would be talking about a pretty fundamental rethink about the way KSP is structured and balanced, and I'm not sure it's really necessary (especially after having created my modded stock tree with existing parts and having it come out better than I expected). I would also be very much against parts updating themselves in-flight. What you launch with is what you're stuck with; anything else breaks immersion far too much for my tastes.

Okay, that is FANTASTIC -- I can't believe I missed it. I hope this thread may have served as some inspiration for where they're going. I'll keep supporting my mod tree at least until the next patch then. - - - Updated - - - Yeah, I had the same thought as I was working on the mod. I think that would make absolute sense, especially if the horizontal technology lines were color-barred or whatever, as suggested earlier.

I don't disagree, but I'm curious what sense do you mean "too many"? As in "makes the game too easy" or "is too confusing"? I have a little bit of worry myself about the latter at least. Even though I don't see a problem with allowing a player immediate access to, say, i-beams, you wouldn't really want to have a new player getting the impression that those are a necessary first purchase. But I'd tend to say that could be solved (in stock, not in my mod) with a dialog for new players asking if they'd like the game to start them with some parts (basically the current stock start node with basic rocketry parts). Okay, you've convinced me on that point -- I kept wanting to cater to absolute newbies who want to play the tree, but... newbies are not going to be finding this thread and installing a mod. So I'll work on an update that assumes a given amount of starting science. Should be easy.

I know it's probably too early to ask about balancing feedback, but at least I assume that nobody has any problems installing and using the tree initially?

Oh yeah, that would definitely be the way to go. The best I could do with the built-in tools was having a consistent icon across a technology, but I think if Squad picked something like this up, colored rows would make things very nice and clear. The science question is a bit of a different issue though. The only reason I kept the initial nodes free is that by default games don't start with any science and I didn't necessarily want to force people to create a custom game with some manually-chosen amount of start science. I'm not sure I completely understand what you're getting at though. Maybe post something over in that other thread? There might be a way of me doing something for now.

Well, without holding my breath, one of the reasons I really pushed to get this done quickly was the note from Ted on the dev team focusing on "balancing out the game" for the next update. That seems like an ideal time to look at the tech tree that I didn't want to miss. If anybody has a line on Ted, forward him this thread and my tree mod...

FYI, I've released a full stock replacement tech tree using TechManager that others might be interested in.

My not-so-secret hope is that they notice it, take it, improve it a bit, and roll it into 0.91. Honestly I don't actually want to maintain this as a mod, I just want to play the game with a tree like this!

Thanks, man.

I tried, but no. The only way to get a node to start unlocked is to set its type to "start", but unfortunately setting multiple nodes as "start" causes the game to treat all of them as the same node, and so all of them contain all of the start parts. It would be nice if nodes simply had a "start" flag -- another suggestion for TM/KSP. The only way to get around this would be to just collapse all of the first column nodes into a single start node, which immediately would fan out to the technology lines. I worry that doing it that way would make it less clear exactly what the rows mean though. As it is, you can clearly see that each start part is the beginning of a related technology row. - - - Updated - - - Yeah, that's what I mean. You mean that's a separate .cfg file than the one I'm creating for TM, right? Yeah, it's not surprising that there may be another way of doing it. But I didn't want to hold up doing this by diving into how to mess with part costs, let alone trying to balance things. If somebody else wants to take a shot at that, I would welcome it. - - - Updated - - - I went back and forth on that. The reason I didn't do that was twofold: I wanted to make this as straightforward for a newbie as possible so I didn't like the idea of having to follow more out-of-game instructions to make it work (even though I had to do that for the R&D tier limits) From a gameplay perspective, I kind of like the idea that the player would have free access to that whole range of starting parts so they can at least play a bit with each type of technology without feeling like they had "wasted" points on something. There node costs after the starting parts ramp up pretty quickly so I didn't think there would be huge game balance issue by giving people a range of foundational technologies. Plus you still have the cost to buy the part in most cases, even if the node is free. But I'd be open to reconsidering that choice if there's a strong opinion on it generally. When you created the new career, did you set the option for "No Entry Purchase Required on Research"? I notice that's the default on "normal" difficulty. If that option isn't selected, the parts do require the purchase for me. - - - Updated - - - That's the reaction I was hoping for. It really overstates the complexity of it when you see the whole thing without having played through it. I think it actually starts out quite approachable and simple, and it only gets complex to the extent that you the player want it to, part by part.

By the way, I've released my TechManager .cfg file for stock parts at its thread. Hope to hear feedback on it over there from everybody who's been following this thread.

BlueSky R&D has been released! See the beginning of the thread for details. While I'm at it, I also wanted to post a little info about creating .cfg files that can add to this tree, since it's a little tricky and not particularly documented. I find the most efficient flow is to start with the TED app. It's not perfect, but it lets you get the basics into a file MUCH more quickly than direct hand editing of TechManager .cfg files. Install that, point it at your KSP directory (so it has an up-to-date database of parts in your install), and start creating nodes. Obviously you'll want to read the help for TED (and TM), but here are some pointers: Add nodes by shift-clicking, and link nodes by cntl-clicking. Be aware that linking has a direction, so make sure your prereq node is selected first. If your prereq node is in a different tree (ie. my stock-parts tree), don't worry about it in TED -- you'll have to add it later. The "any parent" flag means that if the node has more than one prereq node, any of them can unlock it (as opposed to requiring all of them). Make sure to enter something into the "name" field that is unique -- both to nodes within your tree as well as the stock tree (or BlueSky). It can be as simple as "INTERSTELLAR_123". If you want to see what the selections for "icon" look like, take a look in your gamefolder at GameData/Squad/PartList/SimpleIcons Don't worry too much about the absolute position of your nodes in the field (assuming that you're going to create a block of nodes adjacent to the BlueSky parts -- if you want to mix them into the middle (not recommended), you'll want to figure out your coordinates to not conflict right away). The perlscript I have now (which I'll post below) will let you move the whole array around pretty freely. But you will want to get the node spacing accurate by entering round numbers directly into the coordinate fields in TED once you roughly have your layout and linkages. KSP won't draw a straight horizontal line between two nodes unless their coordinates are exactly lined up. When you're done, save the file off to a TechManager .cfg file, then open it up in a text editor where you'll need to do a few things by hand: At the top of the fie, change the "id" and "name" to something descriptive for your tree. "id" is what will show up in-game via TechManager For each node, change the "techID" to be the same as the "name" you created in TED. The default values will be KSP stock values that TED (for some reason) automatically puts in, and will screw up the contents of your node. It can probably be anything different, but I name it the same as the name just in case. If you have any items in the "PARTS" list for the node that includes an underscore, change the underscore in the name to a period. For example "awesome_part" would be "awesome.part". This is an odd bug that I don't understand, but it has proven true at least for all stock parts. For any nodes that need to reference nodes outside your tree, add them to the "parents" list for the node (see other nodes for formatting examples). I mentioned above to not worry too much about the absolute position of your nodes in TED. Now you'll need to get that right. If you open up my BlueSky .cfg file, you can see the range of coordinates that my nodes use. Figure out where your block of nodes want to go and how much you need to offset them in x and y to get it there. I've created a little perl script to let you easily make these changes for all files in your tree. I call it "posmath.pl" in the usage: [COLOR=#232323][FONT=Tahoma] [/FONT][/COLOR] [COLOR=#232323][FONT=Tahoma][SIZE=1][FONT=courier new]#!/usr/bin/perl[/FONT][/SIZE][/FONT][/COLOR] [COLOR=#232323][FONT=Tahoma][SIZE=1][FONT=courier new] [/FONT][/SIZE][/FONT][/COLOR] [COLOR=#232323][FONT=Tahoma][SIZE=1][FONT=courier new]# usage: cat inputfile.cfg | ./posmath.pl > fixedfile.cfg[/FONT][/SIZE][/FONT][/COLOR] [COLOR=#232323][FONT=Tahoma][SIZE=1][FONT=courier new] [/FONT][/SIZE][/FONT][/COLOR] [COLOR=#232323][FONT=Tahoma][SIZE=1][FONT=courier new]while (<STDIN>) {[/FONT][/SIZE][/FONT][/COLOR] [COLOR=#232323][FONT=Tahoma][SIZE=1][FONT=courier new] [/FONT][/SIZE][/FONT][/COLOR] [COLOR=#232323][FONT=Tahoma][SIZE=1][FONT=courier new] if (/pos = (([-\d]+),([-\d]+),([-\d]+))/) {[/FONT][/SIZE][/FONT][/COLOR] [COLOR=#232323][FONT=Tahoma][SIZE=1][FONT=courier new] $whole = $1; $x = $2; $y = $3; $z = $4;[/FONT][/SIZE][/FONT][/COLOR] [COLOR=#232323][FONT=Tahoma][SIZE=1][FONT=courier new] $new_x = $x; #changes to the x axis coord go here[/FONT][/SIZE][/FONT][/COLOR] [COLOR=#232323][FONT=Tahoma][SIZE=1][FONT=courier new] $new_y = $y; #changes to the y axis coord go here[/FONT][/SIZE][/FONT][/COLOR] [COLOR=#232323][FONT=Tahoma][SIZE=1][FONT=courier new] $new_z = $z; #changes to the z axis coord go here (not typically needed)[/FONT][/SIZE][/FONT][/COLOR] [COLOR=#232323][FONT=Tahoma][SIZE=1][FONT=courier new] s/$whole/$new_x,$new_y,$new_z/;[/FONT][/SIZE][/FONT][/COLOR] [COLOR=#232323][FONT=Tahoma][SIZE=1][FONT=courier new] }[/FONT][/SIZE][/FONT][/COLOR] [COLOR=#232323][FONT=Tahoma][SIZE=1][FONT=courier new] print $_;[/FONT][/SIZE][/FONT][/COLOR] [COLOR=#232323][FONT=Tahoma][SIZE=1][FONT=courier new]}[/FONT][/SIZE][/FONT][/COLOR] For reference, here is my entire tree with the full "canvas" visible. The x,y coord range of that canvas is roughly -4000-0, 0-2400. Get everything in the right place and your .cfg should now be ready to go. Make sure you've installed TechManager into your KSP install. Save the file, put it in your game directory at GameData/TechManager/ along with BlueSky's .cfg file and start up the game. You should be able to select both BlueSky R&D as well as your tree and if there are no conflicts and the dependencies are correct, you should see one combined tree I believe. Of course make sure the stock tree is NOT enabled as BlueSky completely replaces it.

Yeah, I actually don't think we should get too hung up on duplicating the order and timing of how technologies were developed in the real world (despite me being the one that posted that whole aerospace timeline as a model...). Basically I tend to think of the real world as a reference for one way that a player could choose to progress through the tree. In our world RTGs were developed early because the US had a huge emphasis on nuclear technologies in the 50s and had a lot of technological infrastructure to exploit our advantage in this area. The US also tended to focus on advanced aircraft in the 50s while the Russians got ahead of us for a while in high-efficiency liquid rocket design. All of these are paths a player could take in the tree. A US-in-the-50s approach would be to focus heavily on aircraft contracts and a few cheap solid booster ballistic rocket contracts to get money to upgrade the R&D facility early to have access to advanced aircraft, RTGs, and large-scale rockets a bit later. A Russia-in-the-50s approach would be to focus on lots of liquid rocket missions, get to orbit early and pull in the science, and use that to build very robust lifters based on broad coverage of tier1 rocketry technologies. - - - Updated - - - I do agree with this quite a bit. Ideally I would love to see a system where technologies mature and eventually even obsolete. But in putting together my tech tree mod based on the current parts, I don't think it's as bad as you think. Yes there ends up being a bit of a bias toward better=bigger, but I think that works out reasonably well in a Kerbal world. Could it be better? Absolutely. But I don't think it's 100% necessary to revamp parts and science to have a vastly improved tech tree. I'm hoping to have my mod done this weekend for all of you to try out to see if this is really the case.

I think this is a very important point, which I think most of us have been assuming but bears being stated explicitly. To me if you're going to have a "technology tree", the point should be providing an in-game structure that represents the ways the in-game technologies relate to each other from a development point of view (since it's too complex to simulate that procedurally). It's an R&D choose-your-own-adventure story. With that kind of tree in place, you're starting on with a solid foundation on which to balance the game with the costs to develop those technologies -- whether the costs are the current "science", or some sort of more complex mix of points from testing and exploration. And yes, I think this kind of tree will also suggest ways to rebalance the parts themselves more sensibly, as well as point out areas where additional parts would be interesting/fun/useful.

I'm not a fan of that idea. I see that ending up constraining the player more without any obvious gain in fun/realism/whatever. It seems like at any given point in the game, you would end up with limited options for how you gather the particular type of science you need to get the particular tech you want. It just doesn't seem like it offers much for the complexity added.

Another bit of feedback: I've found that the canvas that TED offers on which to create a tech tree is notably different sized than the actual available in-game canvas. It seems that the game's limits on X,Y coords is something like -4000-0, 0-2400 whereas TED's seems to be -3300-0, 0-2100. Also TED will allow negative Y values, which do not show up in the game at all.

We're most of the way to the intuitiveness of this with just the tree structure we've been discussing here. I like the idea of using testing as a method to R&D progress, but I don't think the science approach is inherently absurd. Sure it might be a little harder to come up with a rationalization for how landing on the moon helps research parachutes, but it's generally the "brute force" approach of throwing resources at a problem, whereas testing is more of the targeted approach. Both approaches happen in real life. In most cases, I think ideas that give players more options (without adding enormous complexity) are a Good Thing for a game like KSP. The tree we've been discussing here goes a long way with that. For unlocking nodes within that tree, the current science approach lets the player who wants to be very contract/mission focused derive a resource from that to progress their R&D. I think adding to that system with a "science discount" for using/testing a node's prerequisite is very nice for providing another play-style option for the player who is more interested in the R&D itself than they are having to go off and do contracts/missions to get the science to buy R&D nodes, or for the player who might be a bit "stuck" and needs a way to grind up their tech to progress further on contracts.

No, it doesn't. And that will be tricky. That's why the TM guy himself seems to have packaged a couple of popular mod sets into TM files. It will be easy to add to my stock tree -- just don't put nodes where I have my stock ones -- but there would have to be some coordination between others if you wanted to load multiple mod trees at once. If that becomes an issue, one idea here might be to reserve a big block of space to the side of the stock tree and break it up into zones that mod trees can fill. With my perlscript, it would be easy to make different versions of mod trees that use different zones. Not super-elegant, but it would work.

Yeah, while I know where you're coming from (especially seeing the whole tree at once), I actually think you may be pleasantly surprised when you're playing through it. Each part you unlock should open up 1-3 other parts which are directly related to the one you got and so I think you'll find that it has a very organic and intuitive feel. Once it's all unlocked it looks complex, but the structure actually has some meaning and you'll have worked your way through it as you built your space program. Plus I fully expect that people may not unlock everything (at least not until later in the game when it becomes trivial)! Since the nodes are mostly per-part, your map will be very dependent on what lines of technology you found most helpful for what you want to do. An aircraft-focused program will build up a technology tree very different from a manned rocketry program. The current tree essentially forces you to unlock everything as you go -- this one definitely does not. Of course I say all this not having played it yet, but that's how it feels to me as I build up my TechManager config to implement it. For newbies in particular, I hope this will be less confusing. As it is, you buy a node full of a grab-bag of parts which you then have to figure out. In this tree, everything is organized functionally and so if you figure out the first part in the technology line, you'll be in a good position to understand the following parts. For this reason, I'm actually going to the trouble of writing descriptions for each node that provide a quick idea for what the new part(s) do for you and so I think this tree will help newbies build up an understanding of the game as they progress.

It really should be quite easy for somebody else to add these (and I do plan to post some instructions here on how to go about it), but personally I plan to focus on adding the stock parts only. I really want this to be as newbie-friendly as possible, although I certainly will do what I can to make it extensible so others can add mods. - - - Updated - - - I'll take a look at your suggestions and take them into consideration. I definitely plan on making the intended tier level clear, one way or the other. I have a couple of ideas here.

Barring anything unforeseen, I should be able to release something by the end of this weekend. Oh, on that topic, it should be quite easy the way TechManager works. Basically I think you can simply create an additional .cfg file for each mod (or set of mods) that you like and TM lets the player load multiple trees at once, as long as they don't conflict. I need to test it out, but as long as you refer to the my node names where you want prereqs and don't physically conflict with node placement, this should work nicely to add on mod-based parts to the tree. Once I get my stock file done, it'll be easy for you to refer to and I've learned some tricks in making this that I'll share here to make it easier.