Stoney3K

Having pilots do stuff that probes can't gives pilots more of a reason to exist. There are only a few reasons where you would want manned missions over unmanned ones if you have the tech for it (aside from the cool factor), and having pilots with extra abilities is definitely one of them. It may also be a feature for the "Fly by Wire" avionics nose cone which became a bit obsolete when the remote guidance units came around.

I think what compounds the problem is that people are under the impression that Squad is closing their eyes on this issue which makes the game unplayable for them. Maybe in your opinion, Squad should put out a statement that this bug is being addressed or something? For 1.0.5 the biggest problem was high part count ships, now that has been fixed by moving to an entirely new game engine (no easy feat) and instead of applauding, people complain about the newer performance-breaking issue which pops up when they have hundreds of vessels in their save. Don't you agree that that may come off as a bit demanding? I only play save games with a few dozen missions going at once and I have never seen any garbage collection stutter happening, even with just 4GB of RAM. I've never seen the gameplay need for having more vessels in flight, if a mission served its purpose, I will return or terminate it.

For the sake of argument, Mono is compatible with the .NET CLR which is responsible for garbage collection. There is no way around the garbage collection aside from moving to another platform (which is impossible). The problem is caused by the Update() calls generating a lot of garbage, in particular, as @Padishar pointed out, the part.RequestResource() which is used by all PartModules that interact with the resource system (and that's a lot). Each PartModule will call at least one resource request per physics update, which creates a garbage object. Part.GetConnectedResources() is even worse since it returns a list of available resources, without any means of destroying them except garbage collection. Multiply the numerous calls to the resource system by a lot of parts, in a lot of vessels that are simulated on rails, and garbage adds up really quickly. I agree with you, that the action of moving resources through the ship is nothing more than adding and subtracting numbers. It's a completely linear operation, and should not requre any creation or destruction of new data objects which represent a single "slice" of resource that is used in that frame. Maybe a good solution would be to generate a resource I/O matrix for any craft that goes on rails, and simulate from there. After all, the only thing that will happen is resources being generated (through, for example, solar panels), being stored in fuel tanks or batteries, being processed in fuel cells or ISRUs (which consume one resource and generate another, in any given ratio), and being consumed by engines. One will add a fixed amount to the total available resource, the other will subtract. No need to create or destroy data objects. I'm not sure if the "original" .NET framework from Microsoft is more efficient when it comes to the garbage collector, but Squad would be unable to move over anyway. That's a decision that the Unity designers will have to make.

Also a good tip, if your station is manned, add ample ladders for EVA crew members to grab on to. I usually put ladder sections on my girders which hold the solar arrays. The tiny docking port (Jr.) is great for linking the girder parts together. Keep the solar arrays well away from the approach route for incoming ships. you don't want your ships to hit the arrays when they try to dock. And make sure that there is at most ONE torque wheel that's active on your station, otherwise, it will wobble like crazy and tear apart when you enable SAS.

Adding to that: You would need to match the inclination to make your orbital plane cross the target landing site, taking the rotation of the body into account. So your target orbit will need to 'lead' the landing site by a little, otherwise you won't be overhead when the body you're orbiting rotates underneath you.

I definitely support this, add some support for ground targets as well. It's impossible to see the KSC from orbit, let alone, land on it without any navigational reference. Figuring out the exact numbers for an orbit is almost impossible if you want to do everything by hand. I'm sure I can hit a 100x100km circular orbit from the pad, but there is no way I can do that with absolutely zero inclination. Having a "target orbit" at the correct position would allow you to correct your inclination by using the AN/DN nodes. A similar mechanism would be to have a "flight director" on the navball that you can set to a numeric heading/pitch/roll value and that the SAS can follow, so you can fly by the numbers without having to resort to a big autopilot system like MechJeb.

I hope you understand that your condescending tone towards other forum users and towards SQUAD (I am talking about sarcastic remarks in your very own thread start) is not really helpful for your case? If someone is wrong on the internet, help them along, Ad-hominems are really not very helpful. Even though you do have a valid point, such a tone will easily place you in the category of people just bashing SQUAD because they won't listen. I've read up on what @Padishar was investigating in the resource system, and the symptoms do match the issues described here, as well as the issue not appearing on identical systems, save for more memory. Point is, Squad can do nothing about the garbage collection happening, except advise users to install more memory, the only thing they can address is reduce the amount of garbage being created. The fact that KSP is programmed on .NET is a bit of a strike one, though. As far as I know from the internals of C#.NET, there is no function that allows you to explicitly get rid of a piece of data that you allocated or that was handed to you by another function call. So any data that is being used and is not declared locally on the stack, causes garbage, and that includes function parameters which are called by value. The only "fix" for that is to call as many function parameters as possible by reference, especially if they involve large pieces of data, but that is very invasive for KSP as well as a mod-breaking operation.

Does the Unity API have a means of explicitly de-allocating an object? Does C#.NET even allow that? I mean, I come from C/C++ land and I've trained myself to free() up anything I malloc()'ed in that cycle of processing. It's apparent that there is a certain amount of garbage that is being created every frame or physics cycle until it reaches a certain threshold, triggering the GC -- presto, stutter. Users with more memory would have less problems because they have more headroom for garbage creation (a bigger "trash can", if you will), but it will ultimately only delay the problem conditions, not solve them. Padishar talked about issues in the resource system, that could be why a lot of mods are aggravating the problem -- a lot of mods add their own resource definitions and if a lot of resources are requested and processed every cycle, garbage goes through the roof. So, possibly, a rework for the resource request system is in order, at the very least, something that doesn't create a ton of new objects on every single resource request. I suspect that a large save with a lot of fuel cells and ISRUs would have more problems than a large save with only solar panels and rockets, which are not being simulated while those vessels are on rails. I've seen a few profile graphs of someone with a massive station which has solar panels and batteries -- more than 50% of the entire CPU time was taken up by shuffling resources around, even though the station was in steady state. I think that warrants some attention to the resource system to start with.

I'm not saying that we don't have the tools to provide Squad with the information they need. My point is that, by claiming that SQUAD is ignoring the issue, the chances of this issue getting resolved will diminish rapidly. Squad never denied that the stutter issue exists (just as it never denied any problems with the ocean terrain rendering). At this point, the performance problem is just too specific for user's systems that they can't reproduce the conditions under which it happens. I'm saying: Stop claiming to know what the response of SQUAD is, and stop being judgmental about SQUAD. If the issue was easy to fix, they would have fixed it already. The fact that a certain save, in a fully stock game, with exactly identical system specifications, aside from installed memory, produces the issue in one case but not in the other, is a red flag that the program is in fact hitting a "memory wall" -- being notified by the system that memory (or more specifically, allocated address space) is running short and it needs to clean stuff up. In Unity and in any other .NET program, this will trigger the garbage collector. Squad cannot do anything about this happening, and even if they could prevent this enforced garbage collection, it would just mean the program crashes because it runs out of memory. The garbage collection being triggered is a symptom of being short on memory, and there are a few things Squad can do about that, to begin with, be more efficient with resource management and plug memory leaks, but that is something that affects major parts of the code. If the issue is such well-documented and reproducable, feel free to make a decent bug report about it. That gets it on the Squad development pipeline. http://bugs.kerbalspaceprogram.com/projects/ksp/issues

Can you check the memory usage in Task Manager for that save? Looks like the KSP process may just be hitting a memory wall and trips the garbage collector to prevent it from swapping.

I'm getting a bit fed up with people that whine about SQUAD doing everything wrong. If they release the 1.1 update too early, people complain about it being buggy and being released too soon. If they decide to delay the release to work out the bugs with the community through the prerelease, people are acting like spoiled brats because they feel entitled to play 1.1 even when it's not even done. Instead of getting support from the community, they're putting SQUAD between a rock and a hard place because they can never make the right decision. They will always alienate 50% of their community of paying customers. If we want to focus on the technical issue, start by putting a debugger on your KSP process and profile the living excrements out of it. A debugger can provide more information about the call stack than GCMonitor can, and can even trap the processes that generate the most garbage and thus trigger the garbage collector. Clearly there is a memory leak somewhere, but unless someone can positively confirm it is not caused by any mod (and yes, GCMonitor is a mod and it uses the legacy UI, and could therefore also be suspect) My flights have not been as elaborate so far so I have not hit any performance wall, so I won't be of any help when profiling.

People, don't forget, Squad will remain "head-in-sand" (I suspect they have other pieces of work to attend to as well) if we keep bashing Squad for every single problem we have with KSP. If they release too late, people will complain that it takes too long, if they release too early, people will start complaining about bugs being unfixed. Squad can never do the right thing when the nagging message board users are concerned. Please leave your sense of entitlement at the door and focus on the technical issue that may or may not be present. That is information that is valuable to Squad.

You're forgetting that an AI may have a totally different goal from the player. If the goal is "Get to the Mun first" as a contract, then such a contract would only become available once the player is (feasibly) within reach of doing so. It doesn't make sense to offer such a contract when the player only has the first tech node unlocked. An AI would only do just as good as a player would if it gets offered "Test the Kickback booster on a sub-orbital trajectory near the Sun" contracts just as the player would. It gets bogged down in grinding all possible test and tourist contracts that would be achievable in any given time, not setting any long-term goals unless it is offered a contract. A player can already think ahead and predict that it may get a "Fly by the Mun" contract in the near future, and budget for it accordingly. You can see the same behavior on Transport Tycoon's AI. Those will keep hunting for every possible subsidy which offers them a higher reward than regular, trying to get ahead by buliding microscopic networks with subsidised passenger runs, which pay almost nothing per completed run. When you play against those as a player, you can easily beat them by running heavy networks of bulk freight, which have a higher net payoff, but take more time and money to set up, but keep generating reward once they are running. An AI may not be the best option here but we need a competitive element to keep the game challenging and rewarding. You may feel a sense of accomplishment once you get your first payload into LKO, but once you have flown 100 payloads into LKO, the task becomes repetitive and boring, so you would rather have something that automates it and enables you to focus on different tasks. If I have the tech to build a lifter that can haul 100t of payload into LKO, I can reasonably expect my crew to build that lifter, attach any payload up to that 100t, and drop that payload into a predefined parking orbit without my intervention.

I'm inclined to agree that KSP is going through an identity crisis which is perhaps due to its "puberty" phase where more advanced features are being tested and fleshed out, until it becomes a full-featured game. KSP is a sandbox game which offers some railroading in the form of contracts to give the player a degree of challenge. But it's basically the same as buiding in SimCity or Transport Tycoon with unlimited resources enabled -- which can be fun, but it requires the player to role-play their own limitations if they want to have certain challenges. If they aim for KSP to be more like the classic "tycoon" style games, it means adding more challenges, more constraints and competition. Currently, the biggest thing missing from the career game is, as you say, time management, as time is pretty much an unlimited resource. You can warp forever without any penalty except contracts that expire -- no life support running out, and no competitor on your tail who chases you to get to the Mun first. Even a simple "leaderboard" style which records a player's achievements and succesful missions, which can be published online, can provide a sense of achievement and competition in lieu of a crude multiplayer mechanism.

Except for the fact that jets in will also get you nowhere except Kerbin, so from a science standpoint, jets and aircraft are totally pointless unless you can get them to space. The science payoff on Kerbin is just too little to warrant jet propulsion -- if I want to do a science mission on the poles, a sub-orbital command pod with chutes is a lot faster than flying a jet straight and level for 30 minutes flat. So I suspect part of the reason the Juno and other jets are so late in the game is because they hardly have a purpose.

I don't think taking human history as a tech template is going to work for Kerbals. Remember that the liquid rocket you talked about was ultimately developed to destroy a city, not to launch people into space. Rockets that reached orbit were essentially nothing more than warhead-shaped "capsules" that could hold a person and could be strapped to an ICBM. I don't think weapons of mass destruction should be a leading "story" element in the gameplay of KSP. Also, the first jet aircraft wasn't researched after the first rocket reached orbit. I fully support a historical backstory that tells the history of the Kerbals and their quest to reach space, but it should be kept in a fictional and peaceful Kerbal context.

To be fair, you CAN move around in circles around an object that is not in the center of that circle. However, you would need to maintain your flight path (with engines) to counteract the force of gravity that wants to change your flight path from a circle into an ellipse. You'd be hovering around the object with your engines in a circular path, so it would hardly qualify as an "orbit". Only if you're the USS Enterprise, with magic gravity-defying thrusters that allow it to move straight up and stay there forever.

Which makes the orbit no longer circular but an elongated circle: An ellipse. It would be easy to understand if orbits were rectangular: The long side being your Apoapsis and the short side being your Periapsis. You can only have a 'square' (circular) orbit with Ap = Pe (resulting in an eccentricity of zero). Changing your Ap or Pe will stretch or shrink one side of the rectangle, making it not a square anymore.

I wouldn't want a requirement where every single part in the tree needs to be unlocked through some kind of mission either. But it could be a very useful gameplay tool to "skip" certain parts in the tech tree for very rewarding parts (e.g. unlocking probe cores and solar panels early) or playing the missions as a means to get rewards in the form of parts that are not unlockable through science points. For the regular tech tree, players would have a choice: Grind for science, or play the (increasingly difficult) missions to unlock a series of parts. I like the railroading aspect of a career mode like playing a real 'space program' that is working towards an end goal.

I had a manned craft which was re-entering nose first into certain death because it had zero EC left, and I could re-enable the torque wheels with the ALT+F12 cheat, flipping my heat-shielded ass into the wind. Whether that allows you to regain control of a dead probe, I can't tell.

Agreed, it would be a lot less grindy in career and in particular in science mode when compared to the "earn money/science to complete contract to buy stuff you need to complete said contract" dynamic that is on career. I can see unlocking special parts through completion of contracts work very well, especially if there are parts that can never be researched. That would prevent players from researching the entire tree through science-mining and make for more varied gameplay. It would also give more sense to part testing contracts. Complete all of the contracts to test an experimental part under a certain set of conditions (fx. at the launch pad, in flight, in space, splashed down), and you earn the part. Especially in end-game, that would be more challenging than the "build a station on Duna that can house a million Kerbals and has an antenna" contracts that show up in the contract window right now. I enjoy science career the most, but only with a few mods that allow me to do a lot of different experiments (DMagic Orbital Science, SCANsat, Station Science) so I won't get bored of sciencing. A more "progressive" science career with experiment dependencies and "contracts" to unlock tech nodes and parts would be a great addition.

I believe it's a balancing decision. In the 1.0.5 lab mechanic, you could kick that report back around and ship it to a dozen labs so you can farm a crazy amount of science from that single piece of goo. In particular, it was possible to have a station with a lot of labs on there and feed them a single experiment, to mine hundreds of science points per day. There was no limit to that. Now you can only 'mine' the science from that experiment once (although it may be possible to process it again in another lab if you go back and re-do the experiment), so you lose the data, but in return, the science payoff is greater. It's just done to make science experiments more challenging instead of mining a lot of science points just by hauling a single goo canister to a dozen labs in the Kerbin system.

I find it useful to pull experiments from goo canisters and materials bays, so I can dump the experiment modules before re-entry or leave them in orbit. Also, a scientist can remove experiment results for those experiments and reset them so you can use them again later.

I can definitely see the balance decision in that. The point where electrical power on an SSTO is most necessary, is right at the point where you would close your intakes and switch to pure rocket mode. At that altitude and speed, your control surfaces become more and more useless and you need to rely on reaction wheels for control. You can't deploy solar panels at that point (only OX-STATs which cause a lot of drag and can heatsplode) so you're stuck with either heavy batteries and RTGs or fuel cells. Once in space, you can deploy solar panels to your heart's content. The issue becomes most apparent when keeping SAS on since SAS positively guzzles electrical power from the torque wheels, and there is no way to limit the amount of action SAS has on the craft. In most of my flights, my batteries run out halfway on the way up because SAS drained everything even though it only has to do a small amount of control to work. You can offset that with RCS, but that means squandering a lot of Monopropellant. The over-zealous SAS action is what causes the large EC consumption in the first place.

You can't warp faster than a certain factor in, for example, a low-altitude orbit like LKO, which is a pain in the backside if your transfer burn is 2 years ahead.