Chyort

Huge thanks for updating this for 1.1 Truly a must have mod.

Completely understand the delay, and agree entirely with it. But as far as contracts go, while weighted contracts are an improvement, could we possibly get something more user controlled? It would suck to do 200+ part contracts early game for funding because your broke, then get spammed with them long after you start pressing further out, and actually have cash. Something like, "We are interested in capturing an asteroid! Will anyone fund our endeavors? You get to pick the asteroid!" Or "We plan on landing on the mun. Taking bids on stuff involving the mun." Being able to advertise what we want to do and actually get some relevant contracts would be sweet. By contract type, body, or both. Something i was honestly hoping strategies would introduce, not the "Meh" feature we have currently. *Edit* after reading the rest of the thread i see the weighted contracts wont be as potentially punishing as i feared they might. But i would still appreciate some hands on control.

My part counts thank you.

Heat shield on one end, Airbrakes on the other to keep it angled properly as it skims the atmo(And you shouldn't have to dive as deep), and possibly radiators hidden in the heat shield's shadow to help magically keep everything cooler. That is what i would try anyways.

I figure i might as well throw this out there first. My previous post was never meant to throw wood on the fire, so to speak. It was simply about my confusion over how the stock radiators were released/handled. No more and no less. And my question remains as far as i can tell. If you go with B or B1 as it seems most people in the thread are requesting, How will that affect other mods that make stock-alike radiators or reactors that use stock heating? Rebalancing 1 stock engine to be more in line with your much larger pack is one thing, and it causes a fair degree of confusion by itself from what i have seen. What happens if you do the same to multiple radiators and, from the sounds of it, the stock heating system? Not trying to take a side at the moment, just looking for a little clarification i guess.

Can't say i am fond of the "Surprise!" moment where they reveal stock radiators in the 1.0.3 release... After mod makers dumped dozens of hours into fixing something that should have been in 1.0. Without even mentioning the fact that it was going to be in 1.0.3, so mod makers didn't waste their own time. Which is made even more confusing with rover recommending yours all while building his own. With that said however, it is stock now... If you go with B or B1 how will that affect other mods that add radiators/reactors/whatever that use stock? Which will cause less headaches down the road? I was waiting for 1.0.3 before starting a new save, so i honestly don't know the pro's/cons of both systems. I am just afraid of conflicts down the road.

Much better. Thanks

Dont get me wrong, I will use them either way but having something perfectly flat like that just feels wrong to me. Even a slightly bubbled top would sooth my spinal reflex of "Flat! Drag! Bad!" heh That might work better than a full sloped/shaped top too. Duno.

i normally design my landers to do sub-orbital hops, which with refueling tends to put them on the larger end of the scale. So dumping the legs is mostly out for me. Although, to be honest, very few places have an atmo at all. So it isn't a huge issue. And in my personal experience, fairings pretty much go out the window once you start getting up into this part-size range. Tuck the small stuff into service bays, and just eat the drag from the landing gear. Which is part of why i like the appearance of the smaller of the 2 i guess. *Shrugs* Any way you look at it though, having landing legs this size is a huge plus in my book, thanks for all the effort.

hah, i am starting to drool over those large landing legs. My only question though is why are the larger ones flat on the top? Seems like that would just create extra drag.

Skip the mun and go to minmus. Lower gravity makes it all so much easier, not to mention all the perfectly flat biomes. Yeah it takes a little more DV to get an intercept, but you save so much on all the landings. You don't even need landing legs most of the time, just balance on the engine. Personally i try to rush the gravity scanner as well, once you get that you can grab a report from high/low orbit over every biome with a polar orbit. Huge science without ever having to land, and if you throw it on a disposable probe with an antenna you don't even have to worry about bringing the ....... back.

From what i recall NF doesn't have vaporization. So odds are it is coming from real fuels, and his boiloff stuff.

It should be even easier now... Instead of shipping a 100+ton lander or whatever, You ship up an empty 20ton lander and use ore to fuel it after it is on eve.

Personally i would love to see that referenced in the first post. I am fairly sure most people are looking for exactly the same thing. I know i was.

gotta vote for #3 as well. With the old stock tree and nodes not showing up until stuff was unlocked, there was some degree of guess and check. "Ok, this node is junk, but there might be something after it!" So with CTT you ended up with possibly blank nodes that led to dead-ends. Annoying to say the least, and the best thing to do was to hide them entirely. But with the current tree showing everything at the start it is easy to see where you are going. And i would like to see CTT continue this as well. Seeing everything, even with empty nodes, is preferable. Not to mention it would be easier on modders. They don't have to unlock the nodes they want to use, and consider dependancies and everything else.

heh, Point.

There are a few mods out there to add science containers, and while i normally hate mods that try to throw in everything and the kitchen sink... A science container or 2 would fill out the core functionality, and remove a possible dependance on 2nd or 3rd party mods that may or may not be updated.

The bug/glitch/whatever is the fact that it tries to grab the same report twice. Which logically causes problems down the road with stuff working as it should. Dumping duplicate data would be one solution to the problem however. I seem to recall you mentioning the fact that you were thinking about adding a container just for probes/whatnot. Most experiments could be stored as pure data, the only exceptions being goo/scijrs/surface samples. So adding a stack/radial hard drive might be an easy, or at least logical, way to go about this.

few problems/issues 1) From what i have seen it doesn't work with probe cores. I was trying to send a probe up, to grab the transmit values but it just refused to work at all in my testing. 2) The minimum science doesn't always work. while sitting on the pad it keeps trying to collect a bunch of 0 science reports. 3) While running at higher time warps, and using "transfer science to container" my experiments sometimes get stuck. By that i mean, it runs the experiment once, pulls it into the command pod, and then runs it again. At which point it cant pull it into the command pod again, and the results stay on whatever device did the experiment. And because of that it cant run new experiments until i manually clear it. Still far better than trying to manually collect all these science reports though. Thanks for keeping this mod going, pretty much a required mod for me.

I vote for the ever classic FFF System. What could possibly be better for kerbals?

Human nature, is human nature. You give someone a large gas tank, they will try to find a way to fill it full. All the more so when it involves "years" of time before you can ever start filling up, and years more before you can really start to use it. The warp drive, jump beacons, or possibly EPL can reduce this a bit. But not everyone wants to use them. Personally, by the time i actually get enough K+ to start doing stuff with, i will have maxed out the tech tree and am swimming in cash. Which also usually means i am running out of things to do, making K+ itself less interesting to me.

The reason we drill spam is to avoid time warping decades away just to fill up the tank. Personally i am not looking forward to having drills wear out, or any number of other grinding things you might come up with. Making me deal with transfer windows and years long transit times is bad enough. Heh

I find myself with even more questions... REGOLITH_PLANETARY_RESOURCE { ResourceName = Karborundum ResourceType = 2 PlanetName = Sun Distribution { PresenceChance = 100 MinAbundance = 1 MaxAbundance = 5 Variance = 50 } } Assuming i am following the bouncing ball... Solar Karborundum should be 100%, but it is set as ResourceType = 2 meaning Atmo instead of Interplanetary. Which seems odd because the sun has no atmo. In fact i don't see any IntPl Karborundum. Next, are the interplanetary bands at fixed altitudes, or is that random as well? Trying to find a bands altitude when you don't even know if the band exists could be rather annoying. In the Jool SoI looking for karbonite could be bad enough, trying to find Karborundum in the Suns SoI could be insanity provoking.

New problem. Using hyper edit to place a test ship into low orbit of the sun(1500-2500meters). Collectors are getting 0 Karborundum. Test ship is simply 2 collectors, 1 reactor, 1 star lifter command, 5m sas, torch drive, and a Karborundum tank. Also, when i move the test ship to orbit around Jool, the collector peaks karbonite collection at around 300km. Which seems far too high(isn't it supposed to be atmo height +10%ish or so?), and also somewhat odd that it goes down the closer i get to the atmo.

Heh, i checked AVC before posting and K+ was still green. And K+ was last updated 9 days ago. It didn't occur to me the problem was in CRP. Thanks for the heads up however, i did manage to get it working.