FlowerChild

Hype train design contest while we wait?

Far more appropriate theme music for the thread IMO http://youtu.be/YRwvXJEdUWA

Rowsdower, with the focus on moddability in .24, did you guys happen to make the career mode tech-tree more moddable as well? As far as I can tell there's no way to currently modify many aspects of the tree (like add additional nodes, or create additional dependencies between them, or what have you) while adhering to Squad modding rules, so I've had my fingers crossed that this might be something that would be added

Empty pod + probe core is also an option.

I suspect this may come down to: "We keep getting tech support requests from people saying their liquid engines aren't working". "Ok, why don't we set the throttle to 100% by default?" "Then we'll get tech support requests from people saying their engines keep blowing up" "Ok, let's set it to 50%" Granted, I think it would probably be better to instruct players that there is a throttle and how to use it (I'm not sure masking the problem by crippling the player's rocket at 50% thrust instead of emphasizing the problem by having the engines not work is wise), but I suspect the above was the reasoning behind it

Hehe...nice job on pulling it off a Mun landing at that low a tech level Dave. Looks like I was wrong in thinking it would be impossible with a 125 ton mass limit Didn't expect the low-tech crew transfers in order to be able to use multiple ships to do something like that, but certainly makes sense and I don't really view it as a balance issue on my end given the difficulty involved in doing it.

Woot! Congrats on hitting your target Dave

<cries> Ok...I really need to do something about that

Just wanted to drop a quick note saying that with the most recent release of BTSM, the instructions you have in your OP for compatibility with it should no longer be necessary. Finally figured out a way to edit the stock experiments without creating duplicate entries for them, so your experiments should load just fine without players having to perform any additional steps.

Oh wow. Thanks for sharing that man. I hadn't noticed it either and it's an extremely valuable piece of info

Just as a forewarning Dave, I know you prefer to avoid spoilers, but in this case it's an entirely out of game thing that may muck up your discovery process for no good in-game reason: Processing of the asteroid resources is the next thing I'll be working on. So, if you do it now, it won't work. If you wait a release or two, then it will I included the resource itself earlier than the functionality to process it as I need to initialize all that data when an asteroid is first encountered, and didn't want to muck up people's saves later on when I included it.

Yup, that's basically the same stuff I ran into while working on my code. For BTSM though, it's not a big a deal mind you as if I initialize my tracking variable based on discovery info when the asteroid is first loaded, then I am sure to have the right info from that point forward. Given BTSM is the kind of thing that you tend to play an entire save with, rather than something you install on a game already in progress, this was an effective solution for me, other than for the initial release where people updated and thus potentially already had asteroids loaded in their saves that didn't go through my initialization process and thus defaulted to class C based on discovery info. Anyways, yeah, feel free to take a look at what I did for it. I decided to take a look at your system to get a better idea of the actual mass ranges, and have been keeping records of the mass of all asteroids I come across (I'm using those values to also generate resources consumed by other parts in my mod), so I'll let you know if I spot any other discrepancies as I move forward. The other asteroids I've encountered so far seem to fit into your ranges, but I'm still dealing with a small sample size. Was just a fluke that I seemed to get two that were so close to the max and min values of Class B and C.

Just a small observation: I've been thinking of different methods of evaluating asteroid class for use in BTSM, so I decided to take a peak at your weight based classification code and noticed one small thing that I wanted to point out in case it helps: I've had a B-class weigh in at 44.1 tons, and a C class weigh in at 46.2, so I suspect the dividing line between the two rests closer to 45 tons than 50. Currently I'm initializing my own class tracking variable when asteroid parts are first loaded so that they don't wind up being overwritten when the vessel docks, but that obviously has problems in that asteroids spawned without the mod installed will wind up being evaluated as C-class when it is. And just on this point as I glanced over the thread: I'm already modifying stock EVA experiments within BTSM, so feel free to check out the code there if you'd like to see one method of doing it.

Just a quick point here: it's worth checking the stats and description on that part as I've completely repurposed it from what it is in vanilla. Because yes, it is silly, and I decided to come up with a completely new role for it so that it will hopefully make a bit more sense Glad to see the above reports man! Made for a good read with my coffee this morning

Oh wow. Yeah, a fair amount has changed since then. Just wanted to point out that if the complexity of going straight to Eeloo is becoming a bit of a kill-joy in terms of your enthusiasm about pursuing it, that there are now other sources of science available that you can probably accomplish in much less time, and which may open up the possibility of making your Eeloo mission less daunting as well. Capping an A-Class asteroid for example is a pretty straightforward affair that I doubt would take you more than a couple of hours. I know for myself with my first one, not knowing what I was going to really be facing, I just threw together a quick rocket fully expecting to fail but hoping to get a better impression of what was required, and wound up succeeding on my first attempt with plenty of dV to spare, much to my own surprise. Heck, I even managed to set it up in a nigh perfect equatorial low orbit to boot Anyways, just suggesting it as a fun little thing to do if you're on a tight time budget that may help get you a bit closer to your final goal. Right now you seem to be heading towards trying to accomplish it with what I would consider to be the absolute minimum tech, and I could see that being rather discouraging.

You might also want to take a look at some of the changes in the latest releases Dave. I've put some work into smoothing out the transition between techs 8 & 9 that I think will help ease you into your Eeloo mission without it being such a gigantic hurdle to cross. For example, with the node you purchased, you now have access to a fuel processing unit you can use to setup a refueling station en route. You also have access to asteroid redirect missions which may make it more feasible to purchase a 2nd tech 9 node before tackling the Eeloo trip. Anyways, you weren't the only one that hit a bit of a wall in your save (happened to me too), so I've been actively working towards resolving that and making the transition smoother.

On this point, just in case you missed it in the BTSM thread: the current versions of the mod are backwards compatible with those from .23. I haven't done a save-breaking release yet, so restarting for .23.5 content isn't really a necessity at this point.

If you look at the initial screenshots, the solar panels are resting under the external fuel tanks and he needed to ditch them to extend the panels.

Ah, gotcha. Thanks for the info! And yup, I realize there are a number of issues with a raycasting system for this kind of thing, and also know there was talk of switching over to a system more akin to what's used in FAR for determining which parts are shielded in general. Was wondering if this was that change or another

To clarify: does this mean that DR now requires FAR to be installed to function?

I think they can yes. The trick there though is that Sandbox represents the end of the career game, and likely where players will spend most of their time. As a result, it's also the place where you want them to have access to the most variety in creating their own designs to keep things interesting. Thus, I think if they went wrong with the NASA parts, it's by putting such a power boost in such a limited number of parts at the end of the tree, which severely narrows down the effective part choices available in the end game of career (and thus in sandbox). By doing this, they're effectively sucking all the variety out of sandbox play and relegating most of the parts they spent so much time on up until now to being middle-game temporary solutions in career mode. So, to my mind, what would have made more sense is to build a small number of weaker parts at the beginning of the tree which are quickly outclassed and forgotten about (maybe with a visual filter toggle in the VAB to not display obsolete parts). This approach leaves a much wider selection of effective parts for the player to choose from at the end (and in sandbox). To my way of thinking, you basically want the part selection to blossom at the very end of the tech tree so that it's the point at which the player has the most variety at their disposal, not for it to wither down to a small selection of parts so that it becomes the least creative point in the game. But to put the question another way: how can they not balance sandbox at the same time given it's the end state of career mode? It seems to me then that you can't balance career without balancing sandbox.

Leave me out of this please I am unwilling to deal with this stuff in BTSM for reasons I've clearly stated over there, but that has absolutely nothing to do with vanilla, nor should it be a factor in a conversation about vanilla.

No, there's not. I think the only mention of it anywhere as "planned" is on the wiki, and that's community maintained. I think the point I made about fearing the community is particularly relevant too. I can't remember the last time a "balance" change meant a significant reduction in player power, and that would tend to indicate that "balancing" is only occurring in one direction. This is obviously not a good thing in terms of the long term viability of the game, and would put something like aero on the chopping block given players are bound to complain about the reduction to their ever increasing big bag of power. Also, not sure how many people noticed this title as one of their GDC talks: But man, to me that title reads like it could easily be a support group for game designers suffering from community abuse

We seem to vastly differ on the definition of "quickly" I'm honestly not even certain if Squad plans to do anything with aero or not. I'd absolutely love them to and would be performing a little dance of joy if they announced .25 was the "aero update", but at this point I suspect that wouldn't have enough mass appeal to actually happen. Asteroids are sexy. Aero is not, even if it has a far more significant impact on the quality of the game. I also worry that they may have fallen into that dangerous design space of fearing their own community so much that the only direction they're willing to balance in is that of giving the player more power, and aero would most certainly not fit into that.

Well, I think if I clarify my line of reasoning here you might get a better idea of why I'm concerned about all this (and no, I am unlikely to change my mind ): What I fear this represents is an overall design trend on Squad's part to simplify rocket design to the point of triviality in pursuit of a mass market audience. I think if you look at the new easy to assemble kit-rocket parts in combination with stuff like the excessive joint reinforcement, as well as Squad's own statements about wanting to make KSP easier for new players to wrap their head around, you'll understand why I'm thinking that way. So yeah, what I'm worried about is not that this is simply a feature that needs more tweaking or what have you to get just right, but is basically an intentional effort to dumb the game down to make it easier. I think that would be a shame, as IMO rocket design and the sense of accomplishment that comes along with pulling off stuff like getting crazy payloads into orbit is a fundamental aspect of what makes KSP fun. If anything, I think the game really needs more such considerations to heighten that sense of accomplishment (such as a more interesting aero model), not less, as many of the rocket design constraints previously in place were largely artificial (such as the need for crazy strutting and a computer capable of handling it). What I feel we're kinda heading towards is the equivalent of Bridge Builder where there's no chance your bridges will ever collapse anyways, because that would be "too hard". Of course most players will love more powerful parts. Of course they will love easier to construct rockets...at least initially. However, they may also find themselves growing quickly bored of a game that provides no meaningful challenge in the long term if things go too far. Anyways, that's my 2 cents. Given that we're in alpha I think that a large part of the value Squad gets out of having so many people playing their game is that it opens up the potential that people will spot problems with it while they still have time to correct them. To me, this represents a big potential problem that I feel compelled to point out, and if it is an overall design trend as I fear it might be, I think it also stands a good chance of alienating the core audience that has made KSP such a success to begin with.