Tsuki

Epthelyn read my second post. And no Garry's mod is not a good example to compare to. no need to change game engine, just physics engine: in my 2nd post I mentioned Rawbots that also uses unity had changed from stock physX to bullet physics engine(while still using unity) quite late in the development (so clearly its not impossible). One thing with unity is that altho you get ready solutions for most the usual game's challenges(ex: phsyX engine), you are by no means forced to use them, and using other solutions is only a question of effort vs. benefit. And IMO in KSP's case it would totally be worth the effort... but thats just my opinion. I do not want 10s of thousand parts, even 1000 parts running smoothly would be great, and if performance is scaled with modern hardware, would be even better. Remember making a usable space station and docking with it with a SSTO or any vessel while keeping total part count <300 demands some really ugly and not particularly useful designs (unless going heavy with mods to reduce part count). And 300parts already eats performance so much is not really enjoyable. bonus: this is coming to bullet 3.x but even without this new rigid body solvers bullet is faster.

This is one of my problems, why the need of "integrated physX engine" which is sadly, the worst (performance wise) option. What I am sugesting is to drop the default PhysX engine, and use something else (bullet engine for example). Rawbots swaped from physx to bullet engine, mid development: I know is no small task, but it is doable. EDIT: vexx32 there were many discussions on forums and irc, and one of the argument that kept popping out was how it is not possible to viably paralellize rigid body solvers, and hence pointless to offload physics to GPU.

This statement itself is quite contradicting.... It is sad that ONLY 1000 parts bring the game to crawling speeds, even 300 parts make the game perform very slowly. And this is bad performance, compared to what modern PCs with decent physics engines can handle. There are games that can handle (with a decent framerate) up to 1k "parts" and techdemos that can handle way more. But yeah I do understand swapping a physics engine is no small task but there are unity wrappers for bullet physics(another physics engine) that shows considerable performance boost compared to physx and there are games that managed to swap the engine mid development. IMO the only thing KSP needs is better physics performance, everything else is of secondary importance... (but that just my opinion) Also about claims that there is no benefit on offloading physics simulation on GPU: http://gpuscience.com/cs/real-time-opencl-gpu-110k-rigid-bodies-simulation-on-radeon-7970/

only this two wishes: * droping stock unity's physX for a better physics engine... * aerodynamics and a little dream i know it will never happen: dropping patched conics orbit calculation to something more Newtonian (ex: http://forum.kerbalspaceprogram.com/threads/49121-On-Newtonian-trajectories-vs-patched-conics)

This is the thing i made a while back. I would put it in a flagship category. Armaments: none (altho it could defend itself by crashing probes or docking tugs into an enemy as it has many) DeltaV: practically infinite, as its capable to refuel itself with kethane miner. Carries: * SSTO plane for atmospheric Survey * Robotic Kethane miner * Lander with rover (capable of return from duna or smaller) * Comms satelites to form a Tetrahedral multi-satellite continuous-coverage constellation * Kethane and mapsat probes Bonus: was put in orbit without cheats (no hyper edit or overpowered mods), altho not in a single launch, it took 4 launches to get it done.

I will probably get yelled at for thread necroing, but really noticed it only now and im very fascinated to how far you actually taken this proof of concept, at least mathematically and computation wise. Sadly I am almost certain that squad will never implement this (won't go into ranting ), however maybe the idea to make it a mod is not that farfetched. IMO if there is still interest from asmi and Mattasmack I might try to research the possibility how to replace the default conic simulation, if there is any. Since i think this might be the biggest problem of it. I would so much love to see this model in KSP the patched conic orbits are soooo boooring..... Also some people concerns about "game is hard as it is for newbies" IMO it was already nicely explained how it wouldn't affect them by much, inside new SOI(where orbits are calculated by conic patches) there would be no difference than it is now, as for the space outside sois... how many newbies would need stable out of SOI orbits -.- (you would not put your first station @ 5000km for god sake)

Thanks for the idea, now i might use my tow-plane setup, as the space-planes are usually expensive:

I see many of you uses space planes and air breathing engines, i opted for grasshopper design, its not the cheapest, but it gets 20t into orbit quite fast and is all recyclable (except the boosters do not get aoutorecycled although it should.. bug?) pre-launch with ~20t payload After successful landing: the cost per launch is around 100k but i consider it acceptable for 20t payload.

I have some problems with auto-recycle. When i use a small solid booster with one large chute it looks like it works OK(altho i only get a message for one booster instead of 2) sugestion:do not replace the UI dialog for recycle value with new one, but if a dialog is already present, just add the new value to the existing dialog. The bigger one is, i do not get any auto-recycle when i use double liquid booster: fuelTank.long,liquidEngine2,parachuteLarge,radialDecoupler2,fuelLine. I drop this two boosters way later, and it has an Ap higher than the point of release, and i never get any recycle popup. I checked the logs and the drag seems ok, but there is never a: "*MC* Recycling vessel: enough parachutes!" after it. the full log of the release of this stage looks like this (i think i got everthing) Am i missing something or is it a bug? Also thanks for the great work you putting into this fork.

Not sure if it was already suggested but it would be awesome: Uppon launch the weight and CoM of payload is calculated and when the rocket is spawned the fairing and what is inside counts as 1 or 2 parts, and only when you "decouple" the fairing the mass is changed back to the correct one and payload is "spawned" and attached to where it should be. The idea is to reduce the part count on launch, without any drawbacks. Even if your rocket accidentally disassembles inflight, you just do the same, if the fairing is "opened" you just spawn the payload. Sure there could be some problems if you have cockpit in the fairing with a kerbal in it. But i think it should be easy to do a workaround, since the payload should be passive when inside the fairing.

The problem i have with the version 0.2.3 is that sometimes after using KAS on my ship i will be unable to go back to space center, or end flight, and the game will not autosave. When pressing [,] it kindof looks like the ship is doubled, where one ship is controllable and the other is not (ex: i press [ vessel is switched, but i still see the same ship, however i am unable to control it, pres ] and i switch back to the actual ship, which is controlable). I am not 100% sure is KAS fault, i also have FAR and kerbal engineer mod. But this only happens on the ship that has KAS and after using the KAS. Any ideas about it?