Xaiier

0.24.2: worked fairly well, though the random crashes existed 0.25: got much worse than 0.24.2, so bad a lot of modders disabled their mods for x64 0.90: we don't know, but unlikely to be much better than 0.25 as there is very little SQUAD can do directly to fix such issues Currently the hope is that Unity 5 which is due out soon will have a lot of fixes for x64 and when KSP moves to that version of the engine x64 will become more stable.

Career mode as it is isn't really balanced at all, and where it is balanced, it's intended more for new players learning the game. As such, many have noted that it is quite easy to abuse the system. As career mode develops, we will likely see changes intended to prevent such things, or mods that provide such balance. Until then, the best way to approach it is to choose not to abuse the system. You could choose to directly edit the save file to give you money, and that's not all that far from abusing broken aspects of the contract system, but neither of those ends up being fun. For now at least, put limits on yourself to play as you find it fun, and as career mode comes closer to being finished (with wonderful additions like the Fine Print mod) balance will start to become a priority.

Ah, I see what you mean. Nevertheless, that isn't a solution, as higher forces and such won't behave even close to properly. The wobbliness results from minor errors in calculation over the timestep period, such as two parts which have slight relative motion. Over a longer timestep (required by the physwarping) these errors become more noticeable and can compound on themselves.

Necro aside, this won't work because Unity works on a PhysX version that runs on CPU only. It's unlikely that will change due to the Nvidia exclusivity of PhysX GPU physics.

Technical accuracy aside, this is a good idea, but it isn't really feasible as an addition to the stock game. The problem with your concept is that while it 'works', it also increases the already heavy physics load. In many cases this won't help the overall speed, because the extra lag will counteract the speed. This is also why the stock game can't do this, as intentionally overtaxing the physics engine and causing lag isn't a good operating procedure. As such, the stock game decreases the physics precision by the same factor of warp to maintain a constant physics load throughout. This is what causes the "crazyness" you describe, but it also severely limits the maximum warp due to overly inaccurate physics. That being said, it's entirely possible to throw caution to the wind and do so anyways, and I made a mod specifically to do so (See my sig). It gives you the capability to toggle an alternate 'hyper-warp' mode which you can set to try to perform physics warp speeds of up to 100x, and also allows you to reduce the physics accuracy down to 0.25x like the stock 4x does, among other things. To an extent this works, and it is possible to attain physics warps well beyond the normal stock limits without any loss of precision or significant lag - assuming you have a powerful computer and a small ship. Also, welcome to the forums!

I'm a fan of this thread, and I bet a lot of the modders (some of which have blocked x64) would agree. It's been shown that any attempts to generalize removing x64 checks end badly, as they negate the purpose of those checks and only add complications. This method is the right way to go, it raises the bar past the level of the people who most often cause problems, puts the responsibility on the user, and even offers an opportunity to learn more about modding/programming in general.

You aren't approaching this problem correctly. Very rarely do mods themselves cause game slowdown/fps drops, rather it's large ships (the physics) that cause that. With this many mods, the more likely issue is crashing due to using too much RAM. For that, you can use ATM, run on linux to use 64 bit, or just cut down on mods to keep the used RAM down.

How about these?

I know, right? How dare they spend hours of their free time providing free mods for you to use and expect you to use them properly! Its quite obvious only Alienware (best computers) can run x64 fine, everyone just needs to suck it up and get one! Silly modders, why don't they just spend more of their time fixing x64 bugs too! Yeah! There's totally not a clearly laid out reasoning for doing it, they must just be jealous! It's so unfair, what right do they have to the mods they spent hours working on! Yeah, theres totally no issues with x64, silly modders need to get their stuff together! /sarcasm Extra note: none of the above was meant seriously, please don't take it as such

http://forum.kerbalspaceprogram.com/threads/98608

Please read the following threads to answer your question. http://forum.kerbalspaceprogram.com/threads/92200 http://forum.kerbalspaceprogram.com/threads/52841 http://forum.kerbalspaceprogram.com/threads/95565

This exists nearly to your spec in the Kessler Chaos mod. Sadly it hasn't been updated in awhile.

If maximum time warp isn't fast enough for you, you could always get my mod (see sig) and boost the warp rates. It's got its own time-skip methods or it can work with Kerbal Alarm Clock

Actually, to echo what others have said, more RAM might get you a small improvement. Before I built my current computer, I played on a MacBook Pro, and there was a ton of swap going on while playing KSP. When I upgraded the RAM, I noticed a significant boost to the FPS, because it no longer had to swap.

These are pretty cool! I remember doing this same thing with those weird pattern things that would make 3d stuff show up. My only problem is that I have to lean way back to get it to work without being blurry, and the images are quite small, but making them bigger doesn't seem to help either.

Welcome! You might be able to grab SelectRoot and change your vessel in the VAB, and then launch it and do a save file edit to swap the new ship into place in orbit. Changing the root part on an already launched vessel is more complicated, though would follow the same principle, but I haven't seen anything that can do it.

I think to an extent, these cases are things that don't really happen that often in designing rockets and such. It's generally assumed that when two parts are connected they become one and are appropriately supported, and so snapping along part borders would ruin that element of the visualization. That being said I can definitely see the argument to include the snapping, but it would require precise balance to prevent it from being too annoying. FAR's aerodynamic disassembly is probably the closest thing we have right now to structural failures like this, and it can definitely be cool, in moderation. Also, I totally kept mashing "Close" in the last screenshot and wondered why KSP wasn't responding...

I'm going to assume its a i3-3227U since that fits the bill. To be brutally honest, that's a terrible CPU, especially for KSP. With (currently) single threaded physics, its entirely understandable that it slows to a crawl with very few parts. Not to mention that its likely also running on integrated graphics, which means graphics could also be contributing to the slowdown. That being said, Unity 5 is coming out soon, and it offers potential for a number of performance enhancements, and there is also quite a bit of KSP that could eventually be optimized much better. In the end though, you do seriously have to consider the possibility that no, you won't be able to run KSP well on your laptop. While KSP is more forgiving than most on the hardware side, it is a quite intensive game and you cannot expect to run well on anything.

Or you could install my mod down in my sig and change those annoying warp limits

Oops, my bad, didn't update the number there. It works fine in 0.25.

There is this: http://forum.kerbalspaceprogram.com/threads/72212

City of bridges eh? Hello neighbor!

As insightful the rest of your post is... ...this just doesn't seem right. I've never seen reference to anything like this within Unity. Do you have a source?

A lot of these are a result of the Unity GUI system being a pain to work with. They might come eventually, but fiddling with all the window code trying to get everything to line up nicely is a very tedious

The floating origin method of keeping the vessel at (0,0,0) and moving everything else is simple. Having two vessels at (0,0,0) but far from each other is impossible. It would require you to have a completely different instance of the game-world and physics engine in order to process each ship. Multiplayer bypasses this by having multiple clients running Each client can process it's own primary game-world and send that data to others for them to display at a distance.