S1gmoid

Well as many have said before me, it's leaking memory like a battered command pod leaks oxygen in orbit. The average uptime on OSX with a pretty minimal mod set (just FAR and the likes, no visual stuff) is maybe two hours. But don't let that discourage you, the auto-save feature makes this a minor annoyance and nothing more. And I do hope it will become more stable in 1.1.

Hey, Most orbital maneuvering math kind of assumes high thrust, approximating maneuvers with instant velocity changes. According to the KSP wiki, this is a good approximation of high-thrust maneuvers, but not quite for low thrust, like under ion engines... I'm wondering if there's some good source of information on planning such low-thrust orbital transfers... :)

Hey, thanks for the insight. I have since found the primer on numerical integrators by the guy behind Principia (the experimental n-body mod), and got a few answers from there. Yea, by the way overlooking drag is quite a huge limitation from a practical point of view. What first sparked my interest was that after building a pretty large lifter, with relatively low Isp, high thrust and a load of fuel, as it gobbled up its fuel mass, even turned somewhat sideways, the vertical component of thrust overwhelmed gravity, and the gravity turn reversed, leading to wasting all the delta-V in a near-vertical launch (and due to the huge bulk of the thing, it was nearly impossible to steer in the upper atmosphere). :)

[quote name='fisfis']I still don't agree with you. You are mixing multiple things together. If you are talking about linux kernel, take a look on it deeper. In stable version (and I consider KSP 1.y.z as stable as it is not noted in a different way) you can be always sure that:[/QUOTE] Okay I think I get it. You have a purely linguistic argument about what version numbers should mean. If KSP were called v12.2 as opposed to 1.0.5.2248, you'd be okay, right? ;) At many companies, major vs minor versions are purely based on marketing considerations. In reality, 1.0.5 is the 'major' version, and patchlevel 2248 is the 'minor'. Imagine that it's v105.2248. There, fixed. [quote name='fisfis']Modern approach is agile development, but the basics are still same and targets also. And the target is always satisfied customer, believe or not.[/QUOTE] I'm satisfied for one... many of us are.

Hey, I noticed that trying to do proper gravity turns requires some heavy trial and error, so I decided to create a 2-dimensional simulation of a gravity turn, assuming no active steering, except that the thrust is always applied in prograde direction. For now I'm assuming a vacuum, because it gets complex enough without accounting for changing thrust and drag. This is the model I wrote up: d[SUP]2[/SUP]s[SUB]x[/SUB](t) / dt[SUP]2[/SUP] = |a[SUB]thrust[/SUB](t)|*(v[SUB]x[/SUB](t)/sqrt(v[SUB]x[/SUB](t)[SUP]2[/SUP]+v[SUB]y[/SUB](t)[SUP]2[/SUP])) = (F[SUB]thrust[/SUB]/(m[SUB]dry[/SUB]+m[SUB]fuel[/SUB]-t*(F[SUB]thrust[/SUB]/I[SUB]sp[/SUB]))) * ((ds[SUB]x[/SUB](t)/dt)/sqrt((ds[SUB]x[/SUB](t)/dt)[SUP]2[/SUP]+(ds[SUB]y[/SUB](t)/dt)[SUP]2[/SUP])) d[SUP]2[/SUP]s[SUB]y[/SUB](t) / dt[SUP]2[/SUP] = |a[SUB]thrust[/SUB](t)|*(v[SUB]y[/SUB](t)/sqrt(v[SUB]x[/SUB](t)[SUP]2[/SUP]+v[SUB]y[/SUB](t)[SUP]2[/SUP])) - g(t) = (F[SUB]thrust[/SUB]/(m[SUB]dry[/SUB]+m[SUB]fuel[/SUB]-t*(F[SUB]thrust[/SUB]/I[SUB]sp[/SUB]))) * ((ds[SUB]y[/SUB](t)/dt)/sqrt((ds[SUB]x[/SUB](t)/dt)[SUP]2[/SUP]+(ds[SUB]y[/SUB](t)/dt)[SUP]2[/SUP])) - g[SUB]o[/SUB]*(R/(R+s[SUB]y[/SUB](t))) Now this is a bit more involved than we ever got during calculus class, and if I remember correctly, there probably doesn't exist a closed form expression for s[SUB]x[/SUB](t) and s[SUB]y[/SUB](t). Can someone point me in the right direction for programming a reasonably accurate numerical evaluation of this?

Okay so let me add a consideration. Software development is an exercise in compromises. From a feature development viewpoint, you have the following factors to consider: [LIST] [*]Frequency and predictability of releases [*]Amount and polish of features added [*]Maintainability of the codebase and QC [*]Backward compatibility / Long term ('enterprise') supportability [/LIST] These goals are directly antagonistic. You can never have all four. The old model was to disappear until you had 2 and 3 down. This is the mindset of "we'll release when we're ready". 4 was achieved by the lack of any major changes after release, as it was 'ready'. 1 is completely sacrificed. It's what gave us (didn't give us rather) Duke Nukem forever. With KSP, and most modern software including Windows 10, the Linux kernel (from the very beginning), Google cloud stuff, there is no such thing as 'ready'. Beta vs release doesn't mean 'features evolving' vs 'feature complete', it means 'probably unstable' vs. 'reasonably fit for everyday use'. Releases are frequent and predictable. The tradeoff is between 2, 3 and 4. Some companies choose 2 and 4 (typical in the financial sector), but they eventually drown in their own code, and have teams of six spending months on seemingly trivial improvements. At least they get paid a crapton. It's not an option for someone who does't sell a license for literally a million bucks (and a bad idea even if you do). So it comes down to 2 or 4. In gaming, expecting enterprise-style longterm supportability is like expecting a racehorse to pull a cart. I doubt it's even considered. People don't buy games for their SLAs. Most don't even expect them to have one. We buy them for the features. "The aero model is solid crap, but it's guaranteed to be backward compatible until 2020" would sound silly as a marketing slogan. So of course one will choose 1, 2 and 3. No 4. Love it or hate it, it is reality.

[quote name='fisfis']Man, this, what you describe, is not modern style, this is garage style. I rather don't want to see products you release.[/QUOTE] You misunderstand. This is not [I]my preference.[/I] It is reality. Look at it this way: [I]MICROSOFT[/I] is doing it, and getting away with it just fine. [I]GOOGLE[/I] has been doing it since day one. From a producer's perspective, risk is minimalized, as they get immediate user feedback, plus development is cheap and relatively frictionless when you don't need to marry your decisions for life. This is how consumer (and quite some enterprise) software is developed today. Garage seems to be pretty efficient. [quote name='fisfis'][COLOR=#333333]I want bug fixes! I don't need new stuf. I am fine with old one. But it must be working properly[/COLOR][/QUOTE][COLOR=#333333] ...you ARE aware that there are companies who are paying ~$3000 per month [I]per processor[/I] to get this sort of thing? Your expectations are unrealistic, and somewhat unfair to the developers.[/COLOR]

Hey thanks for the info Nathan. :) I'll look into it. By the way, is it toggle-able in RO, or do you have some mechanism to adjust for off-center mass during launch and burns?

Heya. Let me add some thoughts. So yea. Welcome to the world of modern day software development. You are flipping out because KSP behaves differently between versions... Well some people's whole job consists of making sure Windows 'security updates' don't crash the entire Intranet of the company they work for. The sort of stability you are looking for has never really existed outside nuclear facilities and the like. The stability of the 'good old days' was mostly due to lack of active continued development, and not better planning. Duke Nukem 3d was released, and that was it. Deathmatch maps and playing styles created for the first version continued to work as there never was another version. Then Quake came out and nothing worked. I'd suggest sticking with older versions if you don't want game balance and mechanics changes. It's quite clear that Squad's business model is not to release KSP and then disappear for 2 years while they build KSP2. Continuously evolving software is pretty much the global norm by now for various reasons. Get used to it. - a software engineer

Heya... I've been thinking about adding the ability to offset CoM to some capsules and experimenting with this... is there an existing mod that does something similar?

Hey, I have a question about the new cooked steering... Is it possible to lock only certain axes? I want to implement a gravity turn logic: turn to 85 degrees above the horizon East at 50m/s, and release yaw. Of course I can just release steering as it is, but for greater predictability, I guess it makes sense to keep roll and pitch locked, that way we're certain to end up in a nice equatorial orbit...

Hey, I'm looking into a way of making crew reports storeable without EVA, because it just feels broken as it is. One thing I started with was looking into was how ModuleScienceContainer is used... It has a config property called EVAOnly or simiar... When I tried setting it to false on the Mk1 command pod, I didn't notice any change in-game. Can anyone tell me what this does?

[quote name='A35K']Its actually a glitch where after you've escaped a planet into solar orbit, if you were not 'flying' this vessel when it escaped, the tracking station will say 'on escape trajectory from Sun' even though its clearly not. I think what happens is just before it was saying 'escape trajectory from (whatever planet you were orbiting), but then switches the name to Sun but 'forgets' to switch the description to 'orbiting'. I've had it happen several times, but it does not affect the actual orbit in any way. It's not anything new, I've had it happening since I began playing, in version 0.23.[/QUOTE] I'll probably post my savefile in a support thread to report the bug... If they haven't fixed it since 0.23, they probably don't know (or are too busy).

Well, also probe cores are very un-aerodynamic. I wouldn't dream of launching one without a fairing. (You probably need to install the Procedural Fairings mod to get usable fairings early in the game.)

Hey, nice tool... but it totally needs a force install button, for testing compatibility, and for cases when the modder posts in the forum that "by the way it works fine with 1.0.5", but doesn't update the metadata. (Happened on at least 1 count: Connected Living Space.) Having to install manually because CKAN is more bureaucratic than a vogon public notary is a bit of a pain. I'm not even sure how it calculates compatibility, several mods show up as compatible and installable, and yet under "Max version" they still have 1.0.4. Others that have 1.0.4 are disabled. Weird, looks seriously broken. Also, it would seem that a lot of plugins take ages to update in the repository, as in lots of days and still no update after the new release in the forum.