Ippo

Success! For the first time I was finally able to upgrade a perk using the GUI It still needs a lot of polish, but most likely it will be ready for 0.25, or shortly after (unless they pull the rug from under my feet and release a lot sooner than I expect them to).

Isn't the "hexcan mod" TAC LS? It's working fine for me, last time I checked.

I want to add that too in the end, but disabled by default for those that don't like it

For the first one, I recall reading something about flares in the Better Atmospheres thread, try to take a look there. For the second one, no idea.

I'm too small a modder to make a significant difference, but I'd use it if it didn't require significant changes to my workflow: currently it's just (build -> copy -> zip), if this required more than a couple steps or was difficult to automate, I wouldn't use it; it didn't require me to change my hosting: right now I'm hosting on kerbalstuff, and might use github as a backup. If I had to keep track of yet another channel, I wouldn't use it. That's really it for me. Then again, my projects have more developers than users, so we'll need the opinion of the real modders out there

RSS stands for Real Solar System: guess what solar system that mod is simulating... Mmm, I didn't think of that. I'll try later, now I have to leave for work, c ya!

Instead of just replying with irrelevant stuff that is not helping OP in anyway (I'm looking at you, Sirine), let's solve the problem, shall we? Ok, so we know 3 points for sure: Low orbit Geostationary orbit Moon orbit: since Kerbin has 2 moons, I'll try using both Mun and Minmus Here are the heights of those orbits, in kilometers: [TABLE=width: 500, align: center] [TR] [TD=align: center][/TD] [TD=align: center]RSS[/TD] [TD=align: center]KSP[/TD] [/TR] [TR] [TD=align: center]Low orbit[/TD] [TD=align: center]~ 200[/TD] [TD=align: center]~ 80[/TD] [/TR] [TR] [TD=align: center]GSO[/TD] [TD=align: center]35876[/TD] [TD=align: center]2868.75[/TD] [/TR] [TR] [TD=align: center]Moon[/TD] [TD=align: center]384000[/TD] [TD=align: center]12000 (Mun) 47000 (Minmus)[/TD] [/TR] [/TABLE] Let's plot the 2 series: The first series (assumin Moon = Mun) looks like a logarithm or a square root. I used MATLAB to fit them: the logarithm is a surprisingly bad fit, but the square root is just sweet (99.2% correlation): The second series (assuming Moon = Minmus) looks more like an exponential instead: in fact, it's a very, very good fit (99.8% correlation): So, to recap: if you assume that the Mun is the Moon, use 8.613 * sqrt(4.886 * x) if you assume that Minmus is the Moon, use 1344 * exp( 9.257 * 10^-6 * x ) P.S: It's =/= its. Except for the simulation of orbital mechanics. I heard it plays a pretty big part in the game. He IS playing vanilla. Pay attention.

Hamburgers just aren't very aerodynamic: hot-dogs, on the other hand...

Eheh one of my first GUI programs was a calculator for OGame, in VB. It had over 50 text fields and they were all referenced by name, each of them. Even before, when I was still beginning with quick basic, I routinely mixed data with code and you had to recompile everything to change the output because I didn't know how to open files.

You listed B9, but didn't list Active Texture Management... that smells fishy. My guess is that you are running out of memory, since you have both B9 and MKS, which are both pretty memory intensive, plus other parts, plus visual enhancements... Try using ATM, if that doesn't cut it, try to see if you can load it using the 64 bit game.

What's not working? I have at least half of those, not a single issue for me.

Well, everybody has started somewhere The very first thing you need to do is being comfortable at writing programs in C#. I personally haven't read it, but wikibooks has a book about C#. Let me repeat: this is a *fundamental* part if you intend to touch any plugin. Once that you are comfortable with C#, you will want to take a close look at this thread: those examples are basically the skeleton of every plugin you see here on the forums (including and *especially* mine, I wouldn't have gone anywhere without Taranis). At this point, it's time to learn how to work with git and github, since it's where most projects host their source. But you won't have to worry about this step for a while. Happy studying!

Because I didn't even know there was an older one that did it that way I don't know how to make it work that way right now. If I ever find out, maybe I'll change it (but don't count on it). Anyway, considering the license, I absolutely encourage people to modify it in any way they like. Pull-requests are also welcome. Just follow the license

I'd be very surprised if it didn't: take a look at the only line of code that makes this work. All the rest of the file (and it's still pretty short) is just stuff to draw the window. By the way: I know it flickers a lot, but as you can see, I'm already using Unity's smoothed framerate. There is basically no documentation on that, so I don't know how it is smoothed (I'm guessing a moving average over a handful of samples): if it *really* is a necessity to improve the smoothing, I might do it... but as far as I'm concerned this was the only release, ever.

A dll file contains compile code. The human-readable source code is fed to the compiler that produces machine code, stored in the dll along with some metadata. You can load a dll using some development tools, like MonoDevelop (which is free), but it can only show you the list of public members: you can't (*) retrieve the source code from a dll though, you will need the original source code if you want to edit it. (*) well... usually, not legally.

Zero: everything is still boxed in the other room until saturday I'll make sure to report back once assembled!

It's added by Github for windows when you create a new repo Also, the reason is that my new PC is here (well... its components) and I was curious to see how many FPS I can squeeze out of KSP on a 770

Dude it's literally one label and a button.

FPS Viewer A Frames Per Second indicator This little thing is so simple I'm not even going to bother making a proper forum post. It just adds a little window that will show your frames per second in game. You can bring it up by pressing LeftAlt + F at any time. Download from kerbalstuff, view the source code on github, the license is WTF Public License. All of this because I'm too lazy to install fraps.

This distinction is not really possible in my framework right now. Well, kind of: a failure module can easily define multiple failure modes, but they all share the same properties (MTBF, Life time, and Silent). In reality, it's possible to achieve the same result by defining multiple failure modules for each part, although it's not very clean for some other fine points. I'll see when later on I'll add more failures. Agreed, but I plan to do it only in the sense that the later a part is unlocked, the better it is. Parts won't get buffed by unlocking new nodes, because it wouldn't make much sense to me (imagine that SpaceX creates a new super-cool engine and their research retroactively improves the engines of the shuttle... not really plausible). Agreed. Disagreed: I think I already explained while I don't think it's a good idea somewhere in this thread, however it boils down to the fact that spacecraft components are not mass produced, or, at the very least, not in large enough quantities to make a significant difference. I will also go ahead and confirm that I won't be implementing a "quality" system that will let you pay in exchange for better stats: funds are anything but scarce, so you could just toss money at the problem until it goes away and I don't think it makes for good gameplay.

Yeah, that would be very cool but I don't even know if it can be done at all. However this window is available in all scenes, so you can check stuff in flight too, which is handy for repairs. If I ever find a way to hack into the astronaut complex though I surely will

Let me introduce you to the GUI that will let you manage the perks Also, if anyone has any suggestions to improve the layout, I'd like to hear them. I'm not a fun of the width of that window... then again, this layout makes sense (to me). P.S: disregard that CF client, it's a test window for CrewFiles that I forgot to remove.

Micro-update: I was working on Dang It! and realized that if (CrewFilesManager.CrewFilesInstalled && (CrewFilesManager.Server != null)) was starting to come up often in my code, so I added a shortcut: if (CrewFilesManager.IsReady) Just posting for completeness in case anyone wants to know the full changelog (really: that's it).

In the last days I have been messing with an apollo-style munar program. The various incidents quickly led the engineers at KSC to believe that the Mun must indeed be cursed: The early tests never reached orbit because of violent aerodynamic stresses (FAR) The first prototype was found to have a manufacturing error that made it unable to ignite the TMI stage (bug in KW) Finally, all the problems are resolved: Bill, Bob, and Jeb are the first 3 kerbals to reach a stable orbit around the Mun. Mission Control elects Bill and Jeb to pilot the LEM. The two bravely descend to the surface on a 2-staged lander. However, the fuel consumption seems anomalous: something is not right with the descent stage (*). The lander lands hard, destroying the descent stage; Jeb tries to escape using the ascent stage, but the crash is too violent: Jeb is unable to control the attitude in time, and the lander crashes, killing them both. Bill and Jeb become the first two casualties of the space program. Bob is ordered to return at the KSC: he will never fly again. The months passes and a new design is approved and tested. After 2 unsuccessful mission that highligted construction problems in the new launch stage, a new mission is launched, with the objective to reach the final resting site of the two astronauts. Tomner and Shelbald successfully land at the site, after some piloting difficulties to correct the LZ. But at this point, the engineers at KSC make a shocking discovery: too much fuel has been used to pick the landing site, and now the lander is unable to dock with the command module! The situation is bleak: it will take 21 days to recondition the launchpad (KCT), and the crew only has water for 8 days. The command module has plenty of fuel, but is unable to land to pick them up. With a rescue mission out of the question, the only chance of survival is some serious piloting. Shelbald takes off from the surface of the Mun, trying to meet with the CM in orbit. The fuel runs out before they can circularize, but it's enough: the closest encounter is 3 km... at 10 km from the surface. Now the two can only hope that the CM pilot will pull off a miracle. In the CM, Kiruki leaps into action: he first matches the velocity with the lander, and then sprints towards it at an unsafe speed of 200 m/s. There is no time for safety, at 4 minutes from the crash. He reaches the LEM and kills the relative velocity: when the CM stops, the two ships are separated by less than 20m... a close call that could have resulted in a crash. With no time to lose, Tomner exits the LEM and flies to the CM, to relative safety. Shelbald is up next: in the few seconds it took Tomner to transfer, the two ships have already drifted away by more than 100m. He reaches the CM, and the crew is finally safe: the CM circularizes, and easily performs the return burn. They return home safely, greeted like heroes. Meanwhile, the whole engineering department is fired and publicly whipped. * When I was building the LEM, KER died and stopped working. I ran the math myself... and apparently, I screwed up big time.

True that. W/e, I'm not really interested one way or the other. *shrugs*