marach

KSP is multithread ready (according to the patch notes) but Unity's multithreading isn't stable so it isn't used from what I can work out...

Oh for a version of FRAPS you could set to record a key press event -.-

not far 2.5km iirc or something like 20 seconds on stage 5

simulation time should stay constant within the bounds of reaction times, though due to how it works real world time difference could be as much as an order of magnitude between the fastest and slowest machines able to handle KSP

I just realised I might have an a8-5500 (oc'd though) lying around here somewhere I'll check later.

yup set to 0.03, variance will be caused by small things in how the game runs. If you work from the game time slow down caused by the physics engine (clock turning orange/red) being able to keep it in the green will speed up the overall simulation time.

I've run it a few times average time that run was probably my tightest timing for staging i'll do another run in a couple of minutes to ensure that run didn't bug ::edit:: last couple of runs are within the error margin, did notice the clock was green by stage 10 though

Ask and ye shall recieve stock 6350 fps only

Which is what they are doing btw, they have done some minor performance (and some not so) tweaks but they have yet to do a performance pass I'd expect the first one of those to be just before RC1. And for those talking x64 the unity x64 code bugs out on how complex KSP is they are in contact with Unity though and working together to fix it

not to mention its fun to do...

It uses physx and no they have said multiple times they do not plan to move over to another engine.

It's suprisingly possible with just jets to get the your speed and altitude so high that a hiccup puts you up and out of the atmosphere you kinda need them then for reentry

if not for the intakes I would have gone even higher you can do decent stability with just the standard deltas upto about 20km with 2 engines pumping it forward

FTFY. Actually the version Unity uses is so old it doesn't have the multithreading optimizations added (if it had just been 1 version higher...) Unity however doesn't want to break it's old webplayers (for some stupid reason). The limitation of Physx GPU mode only working with NV cards is also a major headache (as I've stated many times NV could do worse than remove this artificial limitation) a growing group in the Unity community are moving over to a bullet based solution and Unity itself seems to have noticed this going so far as to hire a bullet implementer...

Yes it will matter in much the same way as RCS placement matters and for much the same reason

I have a question how many of the people complaining about the new SAS are asparagus pancake builders and how many of them are conventional style builders? My asparagus builds are awful with this SAS they need IRS on nearly every fuel pod to be effective. My old school conventional rockets work perfectly without even an added reaction wheel

Except that's just the date for 0.100

If you're not using the gamedata folder in 0.20+ your modding wrong... as an added bonus this folder usage means we should see a built in mod manager some time fairly soon.

Oooor you place your return point down range X miles and use a chute for initial breaking (cutting it away a second or so before you start your landing burn ofc). You'd still have a smaller max payload due to the fuel you'd want to keep in the first stage for landing but no need for a straight initial climb etc and costs wouldn't be increased that much (especially if the refurb and check point is at the landing site) sure you'd see the first stage turn around go up a little due to having to move it back to the launch site but since it takes time to mate first and second stage anyway the increase wouldn't be astronomical.

Even Pre-glass there was still a LOT of displays on the shuttle the glass cockpit just replaced a bunch of analogue devices with digital versions and MFD's

The odd part is I was experimenting with this style in KSP last night (damn near identical even) doesn't work so well in KSP due to the lack of SRB gimbal...

The ECA sacrifices a LOT of space to allow it to hit GTO, the thing is that still doesn't change the fact the numbers on the image are wrong no matter how you look at it. I suppose you could make a satellite dense enough to require the ECA to reach LEO but I don't think it would weigh just 10t if you did

Hmm isn't the Ariane V's LEO tonnage light about 11t? Payload to LEO G: 16,000 kg ES: 21,000 kg The ECA (which I assume you were using the numbers of) is a GTO only rocket. For LEO you want the ES

Out of interest have any of the Shuttle mods tried adding gimbals to the SRB's like in the real world?

Because of a limitation in PHYSX not of the game itself. PhysX is an ass of a physics engine, unfortunately it's cheap and easy to put into a game engine (hell NV will even pay you to put it in and infact DID pay for it to be in Unity). Now if you switch out physX for something like Bullet or Havok you see instant performance increases (both of these are properly optimized and threaded). On top of that Unity still uses PhysX 2.something from an era when it still used unoptimised instruction types (X87 instead of SSE etc) and is single threaded (can be made multithreaded but you have to pay for a source licence to do so which is rather expensive). Now add all those together and KSP could be the most heavily threaded program you've ever seen and it would STILL lag like hell due to the physics being stuck as a single thread. Now teams out there HAVE integrated Bullet into Unity infact here watch this. Now first note the sturdiness of the structure using bullet (look no more wobble!) next note the speed it's running at actually here check the speed of this... thats 500 objects in freefall using bullet.Now I know this is a small dev team but looking at all the improvements it brings, I think you'll agree, they need to spend the time and move over to a new physics engine. Theres even a good chance the Rawbots team will share their wrapper with them saving them a LOT of coding time.