KrazyKrl

Lots of the issues you are having are a limitation of the engine that KSP is built off of, Unity version 4. Squad can't really support x64 addressing, due to Unity itself being buggy in x64 builds. x64 support on Linux platforms is fine for some reason though. KSP is essentially written as a mod for the Unity engine, and inherits any deficiencies that are in the engine itself. Some problems can be worked around, but programming a game is a very complex process. And you did sign on for early-access. Problems are to be expected. Everyone is waiting for the Unity 5 engine, it should bring some much-needed stability and performance enhancements (hopefully.)

I'd rather have them tweaked a bit. ScienceGuy MkIV: Science containers activated (and crew reports gathered) by ScienceGuy MkIV Are subject to ((ScienceGuy level + 1 ) * (5%(Or some other science bonus)) This would make the bonus science scale with the ScienceGuy's experience. ScienceGuy MkV: Science Rules mode activates, enabling ScienceAlert type functionality; and extra science lab options relating to samples taken (or goo containers, etc.)

The contracts bit sounds amazing, but the administrative strategies are a little lame to say the least. As a placeholder, they work. But the current strategies are very flat for gameplay, for something as quintessential as the Administration Building. I have a thread here about it... (Repeated again for posterity).

I think that forcing DirectX11 breaks so many things, that it causes KSP to not load a large chunk of what should be loaded. And inadvertently causes a reduced memory footprint because of the missing files. I really doubt DirectX11 has some magical "half memory use" algorithm. It sounds like something is breaking internally.

I wouldn't limit KAS to just engineers. But limit some actions to only engineers. Imagine some sort of "follow me" command for kerbals on EVA. Where you have your crewmates cooperatively carry a large gigantor solar panel from storage. But only the engineer can actually attach it.

Rule #1: Top of rocket should be on top at least some of the time.

If we ever get submersibles (and by extension, interplanetary submersibles) I say that K2 is fine for Kerbin's highest mountain. The deepest part of Kerbin's ocean could be called "The Kraken Abyss".

What do you mean live? This is KSP. Just remember, airline pilots have a 100% success rate. We never left one up there.

Thought of this in another thread, I think it warrants its own thread for discussion.

Of course, contract chains would be amazing when they are added; it's only inevitable with the current progression of KSP. Creating, maintaining, and resupplying; a set of satellites and a Munar base from one of the corporations would be nifty for progression.

I don't see why contract-specific data collection wouldn't be possible. It would allow contract, and science, collection around already science depleted locations. I could see something like applying a contract(or several) to each launch, just like you attach a flag to it. This way, you could get some limitations implemented. -Max DeltaV limitation(to limit excessive craft sizes. Maybe something like 4000m/sec if atmospheric only, if orbital then ((Transfer DeltaV (from LKO) for each contract + 4500m/sec DeltaV for orbital launch) + 40%(dependant on difficulty slider) leeway DeltaV). - Max Weight limit according to the rocket equation, with some leeway settable through difficulty options. - Possibility of DeltaV/Part limitations per contract, per stage. - Something like "here's some parts in lieu of extra up-front funds(of course, the parts are surplus or something at a lower price than the funds they replace), but you MUST use these parts in your launch system somewhere Just extra stuff that makes "contracts" more into actual contracts. As a bonus, your rep could even remove(or make less strict) requirements, and limitations, on contracts. Also it adds something else to add to the admin facility.

Mouse/Keyboard. I used to use my wired 360 controller, and it worked amazingly well. Although I needed to use some joystick virtualization software to get it to work reliably with the Unity engine. If only the joystick switches didn't wear out so quick...

(Thread necromancy aside, this thread is still valid...) I'm not sure why Squad hasn't implemented some sort of dynamic texture management and linking before, but I have a weird feeling that they will add it with the new Unity 5 engine; once Squad gets their hands on the new engine. The only problem then becomes "I'm crashing in the VAB/SPH" instead of "I'm crashing at load". Dynamic texture loading only solves 32bit, and only in niche cases(offloading the memory allocation to another game module). This is why x64 exists, it is the only reasonable solution for MOREDATAS in programs.

I already know for a fact that Squad said that they weren't going to implement multithreading at any level, unless they can get it directly from their Unity toolchain.

Pretty much everything you listed is already on the "Do not suggest" list. I hope these features will be implemented Soon.

It would be nice to also take a "telemetry" report when activating the device to be tested under the proper conditions. You can already take crew reports, why can't the parts generate reports themselves? An added bonus would be a "partial completion" of the mission, with a proportionally smaller payout. If you just send the telemetry of the test back, you get partial credit. But if you land (and recover) both the telemetry data and the component used in testing, you get full credit. The contracts system does need some additions though. Hopefully they will be here Soon. Like launch vehicle mass limits, part limits, and DeltaV limits. Along with a required retrieval of mission data... Along with some tweaks to rewards, it would make the contracts system amazing.

I think that the KR-2L contract is a little excessive in rewards. (iirc, this is normal difficulty.) I would love to see the contracts system have a few more requirements tied to it. Something along with the orbital requirements, "Max Craft Mass" and "Max Delta-V", and maybe even "Max Part Count"

I would like to see a reasonable Delta-V limitation on contracts. It would require something to denote which contract you are going to claim with the current launch though, and I'm not sure how multi-launch vehicles would be rectified.

If getting to orbit is easy, you're overbuilding your rockets; and wasting resources doing so. KSP without some sort of stock Kerbal Engineer addon is very hard to build an efficient rocket. Getting to orbit is always easy, it's getting to orbit without wasting a bunch of resources that is the problem. Now, if career mode had something like part manufacturing time cooldowns... So just shoving a mainsail and a large orange tank under your Mun lander probe that's only 2t would be a waste of resources.

I think that a simplification of each intake having a maximum operating altitude(defined by atmospheric pressure), and a maximum speed(Air speed * Air Density) would be plenty. Air breathing engines in KSP need work anyhow; they currently work nothing like actual jet engines.

EVA for transferring Kerbals via impassible docking ports is sort of implied. KSP is still in its infancy, I have a feeling complete IVA space journeys will be possible later. It's just that the game program architecture isn't complete enough yet to support all parts with IVAs, and interconnectedness. Making a reasonably sized space station would be awesome, if you can explore space from a vessel in space in a universe in a game in a computer in a room on a planet in space. Let squad finish the major stuff, like career mode, and game memory management; before adding something as cool, and as moderately useful, as IVA interconnectedness.

I can see it now... A 2 seater that's as long as the FL-T800. You need to stick all those snacks in there somewhere, it goes to space. I can't even think of a reasonable way to use it.

I think that the Stayputnick and other alternative technologies should upgrade to the features of the highest tier of its class of item. I.e. Stayputnick without SAS, then after an R&D upgrade, it gets replaced in the VAB/SPH with Stayputnick MkII "Even more stayingput" model. This would enable a different form factor probe core with SAS, dependent on the mission; while still being useful later. Via tweakables in the VAB/SPH, you can revert the part to the Stayputnick MkI hardware, and lose SAS.

Seems like a roundabout way of asking for random failures. Now, if the reliability build quality slider affected overheating and ImpactResistance... You push your engines above 60% without a thrust limiter they get damaged due to heat. You damage your unprotected, undeployed, solar panels during MaxQ on ascent. You damage your command pod because you needed that .5t to get under some load requirement; and you hit the ground hard.

At the UI level (what the player sees). They should have an as simple as possible view of the game world. Limiting to only a few combined resources also causes the entire chain to not require additional convertors.