Cannibal

I think that option is only available to Nvidia based graphics cards, no?

Just to play devil's advocate one giant departure between this game and the the way real things work is the inability to attach at more than one point! Fuel tanks for example should have no problem attaching laterally and vertically to other fuel tanks without needing rolls of space duct tape. I still haven't seen a solid answer on whether this limitation is due to the unity engine forcing the game to use a tree data structure, or just the unfortunate use of a tree structure rather than an adjacency matrix or something.

I agree with arq... while the number of transistors is still sticking close to moore's law (which is the definition of the law), clock rates are stagnant and individual cores are not speeding up more than a few percent per generation now. Amusingly Bob Colwell who helped design the P6/pentium pro saw this coming back in 2003, but intel execs ignored him https://www.youtube.com/watch?v=fuLKluXs1iA This video is an excellent watch.

I have managed to launch ~1500 part monstrosities, but it takes so long and the controls are so unresponsive that mechjeb is necessary to even get it off the ground My question was more aimed at understanding what is stopping the program from running better than it does currently. It sounds like they are boxed in unless unity decides to upgrade. I hope they will work around this by introducing some 'very large' scale parts and increase the strength of the existing ones so we can build things like the Saturn V without needing several hundred struts

Thank you for the quick response. I looked into it and found people on the unity engine forums clamouring for a PhysX version newer than 2009 I hope they get it as I would love to have it here too.

Hi there, I have been greatly enjoying KSP in general but found the large designs get pretty slow/laggy to get into orbit. I also noticed only one core was being used and that started me reading on why ksp is single threaded. From what I have read the limitation is that PhysX is used for physics simulation, and that PhysX is single threaded. A quick search led me to this page http://physxinfo.com/news/11327/multithreaded-performance-scaling-in-physx-sdk/ So as far as I can tell the 3.x releases of PhysX are multithreaded (go look for yourself). I am hoping that this means that the barrier to multi-threaded physics in KSP is gone, but don't want to get too wildly optimistic, so please tell me why I should not get my hopes up

unexpected weight of the nosecones is the least of their problems. Right now due to aerodynamics being a stub implementation you actually get worse rocket performance by putting nose cones on. Check out youtube

I have to disagree with your assessment. The game suffers badly from structural stability problems (attach main sail --> small silver tank --> other tank --> command pod and watch the rocket bend and flex like jelly at the connection between the silver and other tank), and will suffer bigtime from aerodynamic problems with the 10's of struts needed to stabilize a naked/rough edged payload since we don't have a stock way of putting a custom launch fairing around a payload. A proposal like this looks good now and will be an absolute necessity once realistic aerodynamics come in. Some real world examples of why flexible fairings are a necessity if realistic aerodynamics come in: 1) Proton rocket configured to launch a single dense object smaller than the central column (big diameter) 2) Proton rocket configured to launch 3 GLONASS M satellites side by side has a fairing slightly larger than the rocket body, but shown here wrapped in a thermal management sheath. 3) Proton rocket diagram showing it with an optional very large diameter fairing for a very wide payload

If you have a wide maneuver window and patience they can be extremely useful, even with heavier loads. I have a resource carrier probe I send ahead to planets and moons that carries liquid fuel, rcs, power and nuclear engines for the return journey of a manned pod later. It has ion thrusters that I used last night for a 7 hour capture burn at Eeloo. I literally left it running overnight, but that was several hundred m/s of delta V in only a few tons of mass (xenon + engine + power). Power is a big problem out by Eeloo though as most of it has to come from RTGs.

Arrgh you ninja'd me - thanks for being helpful (though I found it was alt, not ctrl?)

As always happens with such issues, I find the answer *after* asking. Seems the keyword I wanted was 'transfer' not 'docking'.... To answer this for anyone else who wants to know hold alt and right click on the two tanks you want to trasnfer between, choose in and out and it will begin automatically!

Hi there, I have spent 20 minutes searching the forums and every docking post I can find seems to deal with how to get docked in the first place since that is so fiddly! I can't find one discussing how to transfer assets between spacecraft and if it is possible with mono propellant. This is probably extremely simple but I can't find it. Thanks in advance.

Hi there, I have a very strange observation that I am hoping has a physical explanation since it is very frustrating and I would like to fix my spacecraft to remove it (if possible). What's happening is, I am in an orbit around the sun just outside of kerbin's orbit, and have matched inclination angles with Eeloo. If this is suboptimal that's fair but my intercept efforts from inside of kerbin's orbit were always being interfered with by the mun so I decided to remove that from the equation by just moving out of its sphere of influence. I am now in the process of raising one side of my orbit to intercept Eeloo about 15 degrees after its orbit has crossed that of Jool, and during the delta V burn really strange things are happening that I can't explain. I am using the Smart A.S.S. to hold the maneuver node under the reticle which works well, but as I increase engine power beyond 1/3 the ship will begin to pitch or yaw despite having symmetric thrust and symmetric weight distribution. Reducing thrust slightly allows the reaction wheels to keep up for a while but after a few minutes of burning I have to lower the power to 20%, then 15% then 10% and the Smart A.S.S. has more and more trouble holding the heading. Keep in mind this is a heading that should rotate about 1 degree/day since I am in an orbit only a little higher than kerbins around the sun. Eventually even if I kill all thrust the spacecraft rotates uncontrollably by either the Smart A.S.S. or by me manually! Now the really weird part. Suspecting this was a bug I did a quicksave then a quickload and guess what.... the forces are gone. The spacecraft can hold a heading again no problem. The only mods I have installed are mechjeb and build tools, no custom parts or other wackyness. The vessel is two probes docked together, one as a stage to carry them to Eeloo the other for the trip back with kerbals eventually, they are rotated 180 degrees relative to one another each with a large gyro unit and a large probe computer. Originally I thought the problem was related to the gyros fighting each other but disabling one spacecrafts gyros does nothing. Locking engine gimbals also does nothing. Please let me know what you think as this one really has me scratching my head.

Followup question - how do I mark this post as solved?

Verified to work - Thank you!

Hi there, When debugging rockets it's very helpful to see what went wrong when it's obvious something bad has happened (e.g. you see a tail fin fly off early in a flight...). In the demo on steam the "post mortem" was reported every time you ended a flight, but now that I have bought the pay version I can only see 'revert' unless something apocalyptic happens. How can I bring up the 'flight results' screen without blowing up the whole rocket?

Thanks for the positive reaction. I recently tried to build a model of the Delta IV heavy and this limitation bit me hard I tried to use the silver fuel tanks at the bottom, with orange on top, then silver again, but found that I couldn't attach the rocket both vertically and horizontally without resorting to nasty nasty kludges like 50 struts to 'tie' it together with metal twine... I'm a little surprised that the decision was taken to use a tree structure since even relatively simple vehicles like this one have multiple 'loops' in the connection structure. I wonder if it is in Unity/PhysX or in the KSP layer on top - I hope it's the latter so it can be corrected.

I completely agree that the number of control keys needs to be culled. Ideally all movement/rotation (rocket, vehicle, kerbal on EVA) should be handled with the hand in one position (WASDQE).

Hi there, I just picked up KSP last wednesday and have ploughed almost 40 hours into it already - it is a beautiful game even in this early rough form. I think it speaks to the part of me that loves to design and tinker (engineer by training). One thing that I find an absolute killer though is the way vehicles are internally represented (1 parent tree) is making it very difficult to build intelligent designs. The most common example is trying to build a lower stage that is a 'star' of fuel tanks (one in the middle, 4 around the outside held together by radial decouplers). The problem first shows up if you try to connect the outer tanks to the inner at more than one point to give it more structural integrity (without resorting to the kludge of struts everywhere). It gets even worse if you try to put a 2nd stage on and connect 2nd stage outer fuel tanks both vertically (to the stage below) and laterally (to the central column). The way ships are represented in the game it simply refuses to understand that things in the real world can be connected at more than one point, and often must be to be rigid/strong. (A different and possible better explanation is given here: http://forum.kerbalspaceprogram.com/showthread.php/25550-Attaching-objects-in-builder-to-multiple-mount-points) This is gloriously frustrating since the vehicle that results is either not robust, not functional, or both! I have enough background in design and programming to know that trees are very nice structures to work with, however they have shortcomings when describing a real world structure. An much more robust way of representing the ships is an adjacency matrix https://en.wikipedia.org/wiki/Adjacency_matrix Every element in the rocket would be a row of a matrix, where every column describes whether that object is connected to another. The colour coding represents different types of connections (e.g. direction of fuel flow). I did read somewhere that the 'engine' forces this limitation, but wasn't sure if the poster really meant the unity engine, or just the core of KSP on top of it.