futrtrubl

I'm having some issues. Trying to add grabability and storability to the lights from Aviation Lights http://kerbalspaceprogram.com/aviation-lights-v1-2/ I've made a cfg with @PART[lightbeacon_amber] { MODULE { name = KASModuleGrab evaPartPos = (0.0, 0.0, -0.2) evaPartDir = (0,0,-1) attachNodeName = null physicJoint = false addPartMass = true storable = true storedSize = 4 attachOnPart = true attachOnEva = false attachOnStatic = false } } @PART[lightnav_blue] { MODULE { name = KASModuleGrab evaPartPos = (0.0, 0.0, -0.2) evaPartDir = (0,0,-1) attachNodeName = null physicJoint = false addPartMass = true storable = true storedSize = 4 attachOnPart = true attachOnEva = false attachOnStatic = false } } The lightnav_blue part shows up and is addable to containers and gains the KAS right-click menu in EVA. Unfortunately "grab"ing it in EVA does nothing and if I take one out of container it doesn't show up but there is a few seconds later an explosion some distance from the ship (on the ground). I am able to select "attach" on an already placed one and move it properly. More unfortunately the lightbeacon_amber part doesn't seem to get KASified at all. Never mind this issue, there was an invisible character in the name causing problems. Now it shows up but has the same behavior as above. Perhaps unrelated I was experimenting with "attachOnEva = true" and found that parts with that, like the RCS block (oddly the only stock part with that....), once attached to a kerbal are not removable. And finally for a feature request; I love that you added rotation to placing parts, but only in one axis. Could we get the full 3 axes? Edward

*poke poke poke poke poke* Ditto to what sumghai said. Just don't make me get the pointy stick.

Site isn't working for me on Chrome. "Oops! Google Chrome could not connect to ksp.freeiz.com Access a cached copy of ksp.*freeiz.*com" Tried using the IP address above directly with the same issue.

Which is what happened and why it works currently thanks to Pontiac.

Any update on an update? ;']

Love your mod! Two questions. I'm assuming that I can change a lights colour by changing the numbers after "color = " in the cfg files and edit a model png to make it's appearance match. These "color = " values are red, green, blue values between 0 and 1 right now I see they should be up to 3ish? Also would you consider adding a yellow light to the pack to align with the spacecraft section of http://en.wikipedia.org/wiki/Navigation_light which may become "standard" for manned and rendezvous capable spacecraft? Also wondering about the balance of these compared to stock. These give far less light than even the wide stock light (albeit omnidirectionally) and are far smaller, but weigh 2/3 and use 1/2 the power. Also they don't automatically get put in the light action group. Edward

Yup, I am aware of it and have it. Just saying that as part of a pack mainly for building spaceplanes it seems odd to have a port-side red light but not a starboard-side green light. Also those lights are much larger.

It may be a minor part of the mod but can we get a green omni light to go with the red one? Is there an easy way for me to make one myself? I looked in the cfg to see if there was something there I could change to make it but it looks like the colour is handled by the "lightName = light_N2" line in the module section so not something I could modify myself.

While Kethane is less dense (per unit, not per volume) everything else you said is incorrect. You actually SAVE mass in tanks. One KL-TL80 (the largest kethane tank, holds 16000 units or 32T) which has a dry mass of 3.25T fills one Jumbo 64 LFO tank ( the large orange tank) and one FLT-100 ( the small striped tank) which together have a dry mass of 4.0625. So you save 0.8125 in dry mass alone by hauling kethane instead of LFO. Secondly, like I said in my first post, you GAIN mass in the conversion process, the 32T of kethane becomes 32.5T of LFO saving you 0.5T of mass you need to haul. So in total for each large Kethane tank you haul instead of the LFO tanks to carry it's equivalent you save 1.3125T, thereby decreasing the amount of fuel used to haul it and therefor delivering an even greater percentage of your cargo. Edward

Mining on Minmus and shipping back to LKO is not all that fuel inefficient. dV wise the biggest burn is up from LKO to Minmus, but considering you are only sending your empty tanker ship that's not whole lot of fuel. On the return when your tanker is full and heavy you are able to aerobrake back into LKO and save a ton of fuel there. According to the deltaV map: Empty: LKO -> Minmus -> Capture -> Landing 920 + 80 + 240 = 1240 so only enough fuel for about 1400-1500dV while empty needed (margin for screw ups/inclination changes etc) Full: Launch -> Escape -> Circularize in LKO 240 + 180 + 100 = 520 so only enough fuel for about 700dV while full needed. Also you only need to size you fuel tanks to carry 1500dV while empty or 240dV when full, which ever is the greater amount of fuel and that depends on your ship and how much Kethane it can carry, if you carry a converter with you (since you can convert and refuel between burns on the return leg). I recommend shuttling Kethane and doing the major conversion at your fuel base since, if you use the heavy converter there, you are able to transport less mass as currently the LFO created is heavier than the Kethane it is made from and you are also able to convert it to other things as the need arises.

If a representative of an interstellar capably civilization isn't able to detect and avoid objects in space in an unknown area or to get in contact with the people they are visiting to get or at least approve a flight plan (and not get missiles thrown at them in panic) then it's probably for the best. Like those TSAs (Terminally Stupid Aliens) in that terrible movie Battleship (2012). You have impenetrable force-fields and interstellar capability and come expecting a fight but can't avoid (or survive) an impact with a satellite? Edward

Has anyone looked at retrograde orbits for mapping orbits? If I am thinking about it right this should allow 2 more orbits (over ground) for the satellite per rotation period of the parent body on an equatorial orbit. This should diminish to 0 at a 90 degree polar orbit but may be significant at the ~80 degree orbits recommended previously. Unfortunately I don't have the mathematical knowledge sufficient to test my theory.

1. This isn't a bug though I feel it is a negative feature. You have to go into Options from the main window to change the optimization type. I feel that having them separate adds confusion and people are still forced to set the optimization type before they go to that window since it can't be changed in that window and they would have to go back to the main window and even then have to go into options to change it. 2. I'm getting the same problem as mcirish3. The problem is that while the porkchop plot obeys departure time constraints the optimized results in the text box at the bottom do not. In my case a transfer from the Mun to Minmus with earliest departure/arrival at 3196800s gives a plot with an optimum departure at that same time (3196800s). The text box however says I should depart at 3117014.6652 sec UT which is earlier than the earliest allowable departure. 3. I initially tried my Mun -> Minmus transfer with earliest departure set to 3196800s and earliest arrival set to 0s. This caused the error "Matrix dimensions must agree." to pop up. That error message wasn't really helpful in telling me what I was doing wrong. Also I feel that the program should be able to understand when earliest arrival is before earliest departure and be able to deal with it without throwing an error. Lest it looks like I am only full of criticism I just want to say this is the best program ever! ;'] PS. Looking forward to being able to calculate flybys originating in orbit around the transfer central body. eg. LKO parking orbit -> Mun flyby -> Minmus.

I got it down to 1.0745t. 7 parts in 2 stages. On top an OKTO2 probe core, 2x ROUND-8 toroidal fuel tanks and a Rockomax 48-7S to push it. Under that I have a TR-2V stack decoupler, a FL-T100 fuel tank and another Rockomax 48-7S. You will have to do an efficient launch, not going over terminal velocity and doing an appropriate gravity turn. Finished in a 75km orbit with ~1unit of fuel left (~180m/s dV left) and about 1.5mins of battery. Edward