StarManta

Was addressed by point D in my original post - if either power reserves or fuel reserves drop below 1%, it drops out of timewarp.

1) The phrase "taking advantage of this" implies that this would be cheating or unfair, but I don't see how. If anything, the fact that we're currently unable to thrust simultaneously with two indepedently-controlled ships is unfair in the other direction - an artificial limit imposed by the game for performance/gameplay simplification reasons. 2) I didn't say that you'd necessarily be able to switch away from a ship while accelerating, only that you could timewarp during it. Given the conditions I proposed under which the ship would revert out of timewarp, it would still be sensible to make the player stay focused on the ship for that time. I believe that that is not so much the "whole point", more of a logical result of the way it is implemented. However, there are at least two exceptions to its predetermined-ness: SOI transitions as noted, and collisions with terrain. This would simply be another exception.

Thanks, I agree with your alteration. That's basically what I had in mind, but it didn't occur to me that the mass of the ship would have to factor into that.

Also, data transmission should obey timewarp properly. Say I have a piece of data that takes 100 mbits to transfer, but my craft only has enough battery to transmit 50 of it. (I pulled those numbers out of the air, just roll with it) If I try to do it normally, it will fail - it gets partway through, runs out of power, and cancels. OK, that's annoying, but it seems like a pretty realistic design limitation: In order to transmit large pieces of data I need power storage, seems sensible. BUT, now I can cheat. I hit transmit data, and before it starts, jump to 100x time warp... power generates much faster, but the transmission uses power in real-world time. If the need for power is an intentional limitation, then don't let me cheat it!

The problem with ion engines is a problem with the rails physics system - specifically, that to thrust at all you have to have the ship focused and not 'on rails', limiting you to 4x time. Anything proposed in this thread is going to be a stopgap at best. The proper solution would be a low-thrust-allowed time warp added to the rails physics system. The 'low-thrust-compatible time warp' is probably not an easy to implement feature so I've made it its own thread instead.

(Inspired by a discussion in the 'easy-to-implement' features thread regarding the annoyance of using ion engines.) Ion engines are unused because KSP requires you to have a craft focused and in only physics time-warp while it's thrusting. In most scenarios, this is sensible, because thrust can destabilize unbalanced ships or tear apart flimsy ones. However, it makes ion thrusters - even the massively-overpowered ones that we have in KSP - so annoying to use that they're crippled. I would propose enhancements to the rails physics system to fix ion thrusters (and then ion thrusters can be nerfed down to more realistic levels). Specifically, with this system, thrust can be used while on rails (e.g. in time-warp) as long as.... A. The thrust force is below a certain threshold (which nukes and ion thrusters would be) B. The thrust vector is stable over X seconds and aligned with the COM within some tiny variation (probably 0.1 degrees or so) C. No changes in throttle are permitted during timewarp (this way, the player must start the engines and THEN timewarp, so that they may not take advantage of timewarp to thrust super-fragile ships) D. Power and the relevant fuel tanks are both above, say, 1% of capacity (this way it drops out of timewarp before the engines cut off outside of player control, in compliance with C) E. SAS + Reaction Wheels are engaged Thoughts?

I love it. While we're at it, - Let's stop making the scroll wheel mess up my maneuver when I'm trying to zoom out. No one has ever intentionally moused over the widget and used the scroll wheel to change the maneuver. - You know how you can click on the AP/PE node and 'lock' it so that it displays whether you continue to mouseover it or not? Do that for all nodes, so that I don't have to continually mouse back and forth between the maneuver node and the ascending node or closest approach.

Yes, each satellite has about 10kg of maneuvering fuel. It's not a lot, but if used judiciously, it's more than enough to get them spread around their orbit evenly. The tiniest spurt of prograde thrust can change their 90 minute orbit into a 90-minute-1-second orbit; it will fall 18 seconds behind its neighbor per day, and in about 5 months, it'll be on the opposite side of the orbit from its neighbor. (I've heard it will be months until they are in their final positions, so I suspect this is precisely what they're doing.)

It's definitely not charring - if the rocket was that burned all around it wouldn't have survived. It's soot from the engines. It didn't stick to certain parts of the rocket because the LOX caused ice to condense on the surface of those parts.

Er... what? You get a rep penalty for taking the contract and failing it, but are you saying you get one for declining it in the first place?

I can't believe no one has challenged this statement. That's ridiculous. The theme among all of the reasons this statement is wrong is planning. If you have every single aspect of your space program planned from here to the end of time, then maybe your statement can be correct. If you can perfectly calculate your delta-V for every mission with little fuel wasted (whether by hand or by mod), then you may not have a use for a place to stash surplus fuel left over after launch or at the end of a mission. If your ships never have an emergency that requires you to quickly deliver them fuel before they crash into the Mun or get ejected from the system, then sure, you won't need that fuel stash around the Mun. If every new craft design you come up with works perfectly on the first go, then you wouldn't see any benefit from having a single design fine-tuned for efficiently launching to a station at a known and practiced orbit, at which point it can be refueled for the rest of its journeys elsewhere. If all of those conditions describe you, then you won't benefit from having a space station.

One of the features just added in Unity 5.3 (released last week) is potentially huge for KSP, and has so far gone mostly unnoticed: multiple display support. It's now possible that we could have one display always showing our map view!

I'm with Choctofliatrio - the main source of fun in the missions comes from combinations. I will look over the available missions, and choose a list of missions that I can achieve in a small number of launches, or even a single launch. And getting those all squeezed onto one vessel is the fun. The first few tourism missions are a challenge because you don't yet have the tech to build a proper rocket, and stacking two capsules on top of each other is harrowing to say the least. Eventually that gets routine, you get more science, and you unlock parts that make it easier... but now instead of them being tedious and mundane, I make it harder by accepting 3, 4, 5 tourism contracts at once, and getting as many done simultaneously as I can. If a "test X thing at X feet" comes along, I try to figure out where on my rocket I can put that thing so that it can be tested without interfering with the rest of the mission. I'm really not sure what your complaint is here. "I love X, but now X is a part of the game, so now I hate X"? Or is your complaint in the way the temperature information is presented?

Obviously you still need the physical memory there, but there's few things more infuriating than having a 16GB machine and can only effectively use 3GB of memory. In 32-bit mode there is a "ceiling" - "you're just plain not allowed to have a computer that is able to do X". Calling 64-bit a "band-aid" solution is certainly wrong. It's more like an inevitable requirement, in the long term. Reworking the way resources are loaded is the band-aid - if you keep adding plugins and textures (and KSP players do) you can optimize all you want, and eventually you'll still run out of memory. That's not to say it SHOULDN'T be optimized (obviously, it should be both optimized for memory usage and compiled for 64-bit, in a perfect world), I think you just have those concepts backwards.

Hm. I wonder how they are doing that without Unity being fully 64bit. The only thing I can imagine is that they must be using this hack, which according to that poll (mind you, I haven't dug through the rest of that thread yet) has a 25% "catastrophic failure" rate, which is not great for a publicly distributable game... (hopefully if that failure rate is not compensated for somehow, they will be releasing the 32bit "standard version" alongside a 64bit "risky but all the plugins" version for the people that need it.

Got a link?

The only reason not to is that upgrading to a new version of anything has the potential to create lots of work. But consider this scenario: the upgrade to U5 takes so much extra work that, for 2 months, Squad is consumed with nothing but getting KSP working under U5 (This is probably an extreme worst case scenario; I'd predict a couple of days would be more likely). In other words, let's say that in that one release, KSP adds no new features except the PhysX upgrade and 64-bit that you get "for free" with U5. ....even with no other features, wouldn't that still be one of the biggest, best KSP releases ever?

Unity (the engine KSP runs on) has version 5 coming out soon (most likely this fall?), and it seems like many of the announced features/improvements are things that KSP has been begging for for quite some time. - 64-bit! Finally, run all the mods your heart desires without the need for texture reduction packs or anything! - New version of PhysX, including better utilization of multiple cores Unity's quote: "From what we’ve seen so far, it’s reasonable to expect a doubling in performance generally just as a result of having a better code base and improved multithreading. In some instances, the improvement is dramatic, with up to tenfold improvements." Given KSP's reliance on complicated physics, I would expect it to be on the high end of that scale. - Physically-based shading This is harder to explain, but the important point is that PBS makes it much easier to create shaders and materials that just look far better for realistic rendering. This will have a dramatic impact on the look of the game, for the better. In short, by the end of this year, a version of KSP that runs at double the framerate while looking better and running every mod you could want is not at all out of the question, IMHO.

Have you tried [ ] to switch the view to nearby stuff? In my experience you can still view debris that way. However, you still won't be able to control it unless it has a drone core on it.

Recently recovered after spending a couple of years stranded in Duna orbit.

There must be a mechanic to limit what Lexar is suggesting. I would suggest something simple: After a certain amount of time, the science part "maxes out" on its science potential, and its results must be transmitted or returned to Kerbin for recovery. You can choose to transmit sooner for a proportional amount of Science. How I imagine such a system working: 1. Launch satellite into orbit. 2. Click "Start long-term experiment" on the science part 3. Go somewhere else, timewarp for a while, do some other missions, whatever 4. The part throws up a message "the science part on craft XYZ is ready to transmit results". If Kerbal Alarm Clock is ever integrated into the core game, it should use a window like that. You could optionally forego this message entirely, but still allow KAC to set an alarm for it in future versions. The player just has to come back to the satellite of his own volition in that case. 5. Upon returning to the satellite, you will now see "Review Results" just like if you'd observed the part before. You can now transmit your science. Naturally, this bit of science is much larger and takes more time/power to transmit, but gets you MUCH more Science in return. BONUS: Now, let's imagine that this part requires a large, continuous supply of electricity, and Kerbals to be present. Suddenly there's a purpose for space stations! Since these long-term experiments are much more trouble, it's only sensible to want to return them for recovery (as opposed to repeating them 5 more times to be able to broadcast the results), so you'll want to build a space station with habitation modules and tons of solar panels, and docking ports, and just dock the long-term science part to it for the duration of the experiment. MUCH cheaper to launch repeated science missions then!

If you want less clicking, then assign a hotkey to trigger all of your science things at once. If you don't want to return the vessel to Kerbin to recover it, you're gonna have to do some busywork.

Obviously separators come first, then solar panels. Once you have those, you can get anywhere and do anything. So, at that point, unlock all the science parts to get the most out of where you can go.

Not sure if this is really the right place to post this, but I thought I'd post about this event on the forums here. For anyone near Columbus, Ohio, you should join us here for some KSP fun! It's Monday night at the campus bar, Ruby Tuesday Live. There will be playing KSP in public (and/or watching rookies blow up some rockets on the big screen), with space-related movies and TV shows and such up in the background all night. Facebook event page

Having a different terrain map doesn't affect performance at all.