Starwaster

You know, in general, I don't. Not usually. But today I landed a flight right on the terminator between night and day. I landed my craft unintentionally right on the rim of a crater and half of it (the half opposite of me) was black with shadows. Did you see Apollo 18? I suddenly felt an intense creep out settle over me. I got my two Kerbals out, planted the flag and set up for immediate departure. Which was delayed when I had one of my Kerbals fly back to the lander and I overshot... and he bounced off the rim of the crater and started skidding towards the shadows. It would not have taken much at that point to freak me the **** out.

wow! not something I'd use but I am impressed.

Well if they aren't defined then you define them. RESOURCE_DEFINITION { name = VespeneGas density = 0.00007 flowMode = ALL_VESSEL transfer = PUMP } Then, to add the new resource as a possible tank configuration in the Default tank category: TANK { name = VespeneGas utilization = 0.995 mass = 0.0 temperature = -253 amount = 0.0 maxAmount = 0.0 note = We require more of it! } ta-da!

I suggest you try again. What are you clicking on? I clicked on 'Download Kethane 0.7.7' and it downloaded it. I tried that just now so the link is not dead..

I'm interested, if it lets me try TAC without those cannisters...

Fascinating! What sort of mass are you assigning a unit volume worth of batteries? (ElectricCharge)

omg look, the SWACC (Starwaster Asteroid Classification Committee) hereby decrees that Dres is a planet Case closed. (STAMP!)

Semni's JARFR trusses kinda cool looking but no proper texture support and they dont seem to use shaders properly. I think because of lack of proper UV mapping? not sure.

Yeah we'll make sure MFT shall not perish! Plus I have an idea for recovering resources for non-fillable tanks so they could be filled from inventory replenished by recovering craft. (i.e. land a tank of kethane, r ecover the craft via tracking station and the kethane would be added to inventory; that quantity would be available to,otherwise unfillable tanks)

ok dont see a problem with those beams, I've used them that way myself. (my concern in asking is that I've noticed recently that lots of stock parts have no defined breakingTorque or breakingForce defined which IS a problem) and I agree about the tanks; disregard the warning in the description they are totally edible!

as you're nearing space you've burned so much fuel (and therefore mass) that your TWR is much higher than at takeoff. press F3 at that point and see what max Gs you've sustained. Because you're at the point in your flight when you need to have throttled back alot. If using mechjeb or any tool thatnreports acceleration, keep it at 20m/s (not a hard and fast number but it sounds like that craft needs it) edit: also how are the tanks physically connected? just radially to each other? or is there a part in between? if so which part is it? And by OJ you mean the large orange tank?

I like these ideas, but by no means should it be a requirement for a connection to be established every time the satellite wants to map. The satellite maps autonomously and can store data in the absence of a link. If the complexity of a linkup is still desired then maybe the probe could map but not update until a linkup is possible? Though honestly I think idea A is better. B does sound cool but I don't need a map processed at all until I'm actually focused on that planet and if I have a lot of probes I don't want them bogging down my processor when I'm playing on another planet.

Banned for landing on Dres

Gilly definitely and its weak gravity and uneven surface can definitely be a challenge. If you use the KW Rocketry mod then I'd definitely recommend those big RCS pods. The thing about Gilly is that you'll be sitting there waiting for minutes for it to drift down those last few meters or so. If you try to use big landing engines to slow yourself you'll end up shooting back off into the sky. RCS can land even large craft on Gilly. If you use MechJeb, go into utilities and put the throttle at 2%-3% but by no means should you allow the autopilot to try landing unless you like watching rocket parts strewn about the landscape. If only using stock parts, put those linear RCS pod things fore and aft. Fore so that you can push yourself down to the surface if you're tired of waiting. Seriously, I once went to the kitchen for snacks when I was 10 meters from the surface confident I wouldn't be crashing when I got back

No, you don't have to rename it or anything just drop it in your modularfueltanks folder. the file assumes you have prior KW Rocketry support already. (imthink it's named kw_modularfueltanks.cfg? literally just gotmup, having cofffee and typing on my ipad so this is from memory) dammit how did i miss that?

Here's a patch file for the new KW Rocketry tanks. Also patched the engines to provide thrust again when using Real Fuels but didn't do anything about the thrust/weight changes in 2.5.2 as NathanKell is doing something with that. KW Rocketry ModularFuelTanks 2.5 configuration patch

Yes I saw that there was a new update today. Is that all that changed was the engines? Yes.

working on the new KW tanks. Doing it as a patch to the existing KW_modularFuelTanks.cfg file rather than standalone. For now anyway, If chestburster doesnt turn back up to update someone will need to take over so we can consolidate stuff I should have them ready soon. I think it's just 5-6 new tanks, the two russian styled tanks and the cone adapters? is that it or are there more?

Nobody has yet released updated mfs cfg for KW at all yet. Given chestburster's apparent absence, someone else will have to look into it. Which will probably be Nathan or I?

The second method is wasteful. The first method gets you escape velocity on a trajectory that is already on a hohmanns transfer. The only reason you'd even think about the second is if you wanted to compute a high energy transfer. (The intercept at x days after burn) In which case you're still better using one of the pork c hop plotters and burning from orbit.

ehxaustDamage should be exhaustDamage engines affected: 1mVestaVR1 1mMaverick1D 2mGriffonG8D 1mWildcat5 3mTitanI 2mSPS 3mWildcatXR 2mMaverickV 2mVespaVR9D

I see you all over the place

One of my faults is that although I'm usually a nice guy I sometimes get incredibly tactless. Nobody really cares if you use MechJeb or not. Or whether you are the last person to not-use it or whether or not you do or do not have a problem with anyone else using it. but have fun!

Wow that's a problem if it uses the same part names but player base is split between two versions. I'm thinking though, what happens if we take the thrustVectorTransformName out entirely? It should default to what the part is already using... Or maybe not. Can't hurt to try. I'll give it a shot later when I'm not too busy Edit: Ok! It's as I thought. If you omit any of the properties from the configs for ModuleEngineConfigs then it will apparently just use the original value from the part's ModuleEngines config node. I also notice that K&W STILL have not fixed the spelling on 'exhaustDamage' in this latest version. So I'm guessing you can stand your kerbals directly inside of a stock K&W Engine nozzle and they won't even get warm

I thought he was asking if the autopilot could deploy them. as far as using them with retros in landing I do that all the time, but I set landing speed to about 6 or highher depending on how sturdy the part is that has to make ground contact