thyriel

Sounds like my place satellite contract yesterday Target orbit was only half a million meters further out then mun, and somehow my first try of using muns gravity to raise PE ended in coming three times in a row out of muns SOI and getting captured again shortly after leaving it.

Wow didn't expected that long responses, thanks I'm going into details of your thoughts and questions tomorrow when i'm at my PC again. Just a quick response to two of them: That's how it works in real life. You have a given Voltage, things consume Watts and that produces an Ampere usage. If you hang too much on one fuse, it will break. That may be true today, but Apollo 13 had a hard time reactivating the capsule without exceeding the ampere limit - which was btw when i had that idea, while watching the movie).edit: The goal should somewhat be that you can't activate all 10 experiments at once (which real life rovers and probes can't do too) - and that it becomes tricky building small satellites, not like now that the little explorer probe has 4 comms, 3 mapping devices and half a dozend other stuff. And if you break that rover by activating everything, you need to send a technician (or perhaps another rover) to repair it.

The mercury redstone was a suborbital rocket, so why should it ?

On a quick test it seems indeed that scientists give no bonus at all. Retrieving Goo on launchpad with scientist or pilot: both give 7.0 + 0.7 + 0.15 science, both transmit for 30%.

I think currently there's only the height contracts and explore contracts that matter in that case. So just don't go anywhere before you have a contract for it

I have not written any code myself for years now, but i've been thinking about this idea since a while now. How hard would it be splitting the "electricity" resource into "ampere" and "watts" ? "Watt" would be what electricity is now and ampere would work like the waste resources in life support mods (=represents an electrical fuse). Whenever something is consuming watts, it increases the ampere being drawn from the electric system (and obviously lowers it when its turned off). If it's exceeding the limit bad things could happen, like loosing control until a kerbonaut repairs it (=replace the fuse) or so. Calculations would be pretty easy too, asuming the system has a fixed voltage the amperes can be directly calculated. What i'm unsure is how that system would work with certain part mods. I know there's quite a couple of them around that have incredible electricicity usage compared to stock parts, so probably it could end up with being unplayable with them or being dull easy with none of these parts. I would welcome any kind of input, especially if there's maybe more "side effects" i haven't thought of yet that could make it much more complicated then it looks like now.

The question is what timespan is needed that it can be called a "stable orbit" ? In the end no orbit is stable, they all drift slowly away from each other, affect each other and so on (just look at the whole Jupiter system, his moons are playing a very interesting gravity game to each other, doing weird things like loosing constantly mass to the ring systems)... And as a funny sidenote, Earth "currently" has a second moon, since at least 775 years and for around the next 165 years "2014 OL339" - it's officially a quasi-satellite, but hard to say after how many years in an orbit it can be called stable

I thought it could work like this: If the current system would stop warp, it additionally checks how many percent are left. if its for example more then 30% it doesn't stop warp. That shouldn't affect any long time missions (as long as i didn't forgot to give them something to eat) but prevents killing warp on short flights where the basic lifesupport in the capsule will easily be enough.

lol And then i could add the SNASA Logo http://theblaze.dk/wp-content/uploads/2013/11/sticker375x360.u1.png and perhaps later an alternative Texture for Kerbals http://img.desmotivaciones.es/201107/BS_SNASA_1.jpg

Orbit Kerbin contract is easily done with the FASA Explorer Parts. I'm currently even doing satellite contracts around Kerbin and Mun with that, only alteration i made to the design is that the Explorer I Fuel tank has an additional Medium Explorer Fuel tank, The probe some FASA solar panels, and i set the x3 and x1 solids to 5% max thrust (deactivate and activate via rightclick, not really intended to be used that way but it works) - except solar panel everything needed is in the first 3 techtree nodes.

Most times for me that only happened when SAS was still activated.

Not really, look at the numbers above It's only ~180m/s difference between east and west launch.

Nice mod, i really liked the idea of TACLS but all that resource management made it pretty complicated. Will give this a go instead and look how it is the long end One thing i mentioned right at the begining with it: The warp kill and warning treshhold should be based upon percentage of the maximum LifeSupport available on the ship and not hardcoded values. Took me a while realizing what prevents warping at all on suborbital and orbital flights

Not sure why, but since the last repo update some mods are missing at all (neither in All list nor in incompatible). FASA, USI Exploration pack for example.

The IUS Booster Second Stage is somehow overriding the new SAS system in career mode. As soon as it's on the vessel activating SAS acts like i would have a level 3 pilot, even if a level 0 scientist is piloting the ship

Was anyway interesting to see the dV differences with mechjeb If anyone's interested: All flights where done with mechjeb (ascent: 100km orbit, 1.2km turn start, 1.5TWR, 100km turn end, 15° final angle, 90% shape), NEAR and deadly reentry until 90° inclined circular geosynchronous orbit (2878.75km) [TABLE=width: 500] [TR] [TD][/TD] [TD]A[/TD] [TD]B[/TD] [TD]C[/TD] [/TR] [TR] [TD]dV left[/TD] [TD]3294[/TD] [TD]2555[/TD] [TD]1951[/TD] [/TR] [TR] [TD]difference[/TD] [TD]739[/TD] [TD]604[/TD] [TD]1343[/TD] [/TR] [/TABLE] A) Ascent directly to 90° (N), raise Ap, circularize Ascent to 0° (E), raiseAP, 90° inclinitation @Ap, circularize C) Ascent to 0° (E), raiseAP, circularize, 90° inclination So as expected, most efficient way is launching directly into the target inclination. Being already in orbit the most efficient way is to have a high Ap and low Pe. (Will try what happens to dV usage when Pe is lowered to zero right before changing inclination). dV difference between changing inclination at circular 100km orbit or at geosync. orbit is nearly 3k m/s. EDIT: I tested this now too: A) same ascent path as above to 100km orbit - East: 4454 dV left - West: 4278 dV left = 176 m/s difference same as above but start turn at 15km - East: 4321 dV left - West: 4048 = 273 m/s difference Somehow i expected a lot more dV difference between low and high altitude turn.

Thanks Btw would be great to have CKAN itself in the repos list to see updates. Wouldn't need to install anything just for something in the program to see when a new update is available.

Somethings wrong with the NEAR installation from CKAN. it says 1.3.1 available, 0.90 compatible, but it downloads and installs 1.3a (which is 0.25 version). Had to replace it with manually downloaded NEAR. (repo is from now, no old NEAR installations before that)

Is there anything planned for a realism overhaul version that uses NEAR instead FAR ?

Probably would be better raising the version number for the hotfix-hotfix, i think else CKAN isn't recognizing that there is an updated version available.

Thanks, i should have mentioned that i ment atmospheric for that case That's pretty interesting now Somehow i mostly tend to make course corrections (even big ones like changing inclination) better soon then late. I always thought it's generally the lesser fuel usage. Would be pretty interesting now to test if a north or a west high orbit is cheaper via direct launch, or eastern orbit with low Pa, high Ap and then turning at Ap... think i gotta install mechjeb and take a look

too much delta-v for landing on kerbin Btw for that calculation of droping stages in VAB above i just had an idea: If it's possible to readout parts that are placed in the VAB inactively (not attached to the vessel), would it be possible to make two informations in the "email", one test for the active vessel and one for the inactive ? That way it would be enough to just detach the part i want to know if it has enough chutes, click the button and voila

Just a couple of days ago i have thought about how the first astronauts must have felt sitting in that small capsule completely relaying on someones calculations to know where he will end (and not crash into the moon or get lost into space). Must have been an awkward feeling somehow...

Clicking the homepage link for Universal Storage crashes CKAN (v1.3.0.0). I guess it's because the "http://" is missing. Btw a great feature would be an option to force removing directories upon deletion. I use DDS loader and convert all textures, currently that makes CKANs uninstall feature not really useable.

Probably would have been to much difficulty increase at the same time together with SAS changes.