perk

Every single particle accelerator experiment ever shows that your idea that this drive breaks energy momentum conservation by the amount required to explain the anomalous thrust is bogus. for your moving the goalposts again and again: read up how linear particle accelerators work, there are several types with resonant cavities which have exactly the standing wave and gradiant behaviour (to actually accelerate the particles, no gradiant no acceleration) you desire.. but i guess you will still close your eyes, quote some technobabble and belive that there lives a plesiosaur population in the trevi fountain in rome since its construction, that went unnoticed so far.

every single particle accelerator experiment since the dawn of accelerator physics.... the amount of new physics you "propose" is so huge it just doesnt fit the data: https://atlas.web.cern.ch/Atlas/GROUPS/PHYSICS/CombinedSummaryPlots/SM/ATLAS_i_SMSummary_Table/ATLAS_i_SMSummary_Table.png and no, one box that twitches when electrocuted in atmospheric conditions does not invalidate trillions upon trillions of precisely measured events in hundreds of accelerators in vacuum under precisely controlled gradiant fields, where energy momentum conservation holds true to such a certainty that this whole idea is totally ludicrous...

Ok, thank you for your reply, now i am convinced that you are a troll, and can be safely ignored.

Why do people with 0 knowledge of physics insist on being the most knowledgeable people on physics in the world? And a close second for questions i really can't answer right now: Why should physical reality conform to your wishful thinking?

This is a very straightforward bug, and easy to replicate: build something larger than the launchpad diameter, place TT18-As on the perimeter of the craft, such that it intersects a special point in the ramp leading up to the launchpad, "launch" it, and watch that LSE get missplaced (and either tear your craft appart or get decoupled from the rigidity forces of your craft) as you can see the selected LSE was missplaced from the game during loading of the launchpad, luckily the craft is so rigid it didnt get torn appart like all my tries before, and therefore a screenshot of the problem could be made: 2 more pics showing the placement and destruction this can cause here: http://imgur.com/a/M3lHq

Well i went ultra stock, no mods/addons etcpp of any kind.. just did a simple ball type design and lifted it in one go it has 80 mk-2 crew cabins and 1 lab so space for 322 kerbals 1387t at liftoff 334t in orbit around kerbin that would give: 322*100=32200 +334*100=33400 +320*200=64000 (if you still consider mk2 modules comfortable as you did in the last entry that scored highly) +500 -1387*2=2774 = 127326 *0.25=31831.5 http://imgur.com/a/8tDXf

When i tried to replicate my problem for the video i realized i was most likely wrong about the range of velocities, but non the less the soi and precision problems are huge: after the first change of the maneuver node to 941.2 m/s it should give an encounter (it is right between v_min v_max for the encounter) but it flickers out. After that i just show how slightly changing speeds around that critical speed totally brakes the maneuver node as it now wildly fluctuates even the delta v for the maneuver it self all by its own. To explain a bit more: the spacecraft is in the SOI of kerbin on a kerbin escape course, and since the "escape" vector in the kerbol frame is really imprecise at that point, the orbital maneuvers in the kerbol frames glitch out. Now it got even weirder.. while i changed nothing but the maneuver node in the video, my current path resolved from an escape from kerbin to a bound orbit with a little over 126m meters apoapsis. The craft has 132 parts and 83 tons, which seems part of the problem. From what i am understanding about the game that is not even big, how do others cope with those huge discrepancies?

Since 0.9 i more often encounter a problem with plotting paths into other SOI, not only on the boundery, but already at setting up the maneuver node, by continuously changing the prograde delta v i cover a region that should in its entirety lead to an encounter (change of SOI), and it shows the encounter paths for some values, but in that whole spectrum of delta v (lets call it v_min to v_max for the encounter) there are regions where the shown path flickers between "orbit around kerbol without encounter" and "path before and after the encounter", fast forwarding to the SOI change usually leads the path to be resolved into an actual encounter, even if the flickering effect stopped on the "no encounter"-version. This is badly conveyable in screenshots but maybe i can capture a small vid of it later today. This behaves like a precision problem, but as i described, it is not bound to a particulary hairy maneuver with 0.1 m/s making the difference of encounter or not.. its a range of several m/s where it flickers between the states (even after stopping ship parts movement with hitting fast forward)

The environmental impact of a fuel is not determined by the fuel type alone, but by its origin and fuel cycle. The proposed hydrogen cycle you are commenting on was: create solar/wind/tidal etc electricity, use that to get hydrogen from water, and then recombine that hydrogen in an other place to regain that energy. Its just a temporary storage medium of the electric energy, that is generated renewably. There is no impact like the one you are suggesting, since the produced water was already water in the atmosphere a couple of days-months before. The big difference to fossil fuels is that their carbon was removed from the atmosphere for millions of years, and it took millions of years to remove them in the first place. So noone should be suprised that that can change the climate.

Is there any ETA for resource collection in stock? So far i have avoided modding, but maybe i should finally get my feet wet...

I totally second your statement, even though i like building small "efficient" stations and outposts for the different celestial objects, it annoys me that they are useless after the fact. Servicing contracts really sound like a good idea to fix that.

It is not really installed, it came as a zip package from the site, i unzipped it to C:\Program Files (x86)\ksp0.9 so the executable resides in C:\Program Files (x86)\ksp0.9\KSP_win the output_log: https://www.dropbox.com/s/frayixg13qjhoh2/output_log.txt as you can see nothing in that log happens on any other partition let alone harddrive than C:\, still it always starts them all :/

- I have a couple of older harddrives for data storage in my system. - KSP 0.9 is downloaded and unzipped into a folder on my primary ssd. - System is a 64 bit Windows 7 - In usual operation of my system all my harddrives are idle and not moving. When i start KSP they all start up spinning, which (due to their age) takes a while, and not only prolongs the starting process of KSP unneccessarily (as it waits until all hdds are spun up) but it also puts strain on those drives i don't want. So my questions are: is that call from KSP to the operating system, that causes the spin up of all hard drives, really necessary for the way the startup process is currently coded or can you change it?