Kerbal Space Program

[Ulminati]

Groovy. I built a whole kethane space plane just for Eve, but since I couldn't easily test it, it was a massive failure. Eve is the definition of "not worth it"

Eve is what seperates Protato from Potato.

Get Kerbal Engineer (link) and use the deltaV map posted earlier. Kerbal Engineer will tell you how your deltaV and TWR looks on different planets.

Also, Jet engines don't work on Eve. Not sure about Kethane engines. Only Kerbin and Laythe have oxygen for non-liquid-engines.

 

[Absalom]

Eve is what seperates Protato from Potato.

Get Kerbal Engineer (link) and use the deltaV map posted earlier. Kerbal Engineer will tell you how your deltaV and TWR looks on different planets.

Also, Jet engines don't work on Eve. Not sure about Kethane engines. Only Kerbin and Laythe have oxygen for non-liquid-engines.

Kethane had a special jet turbine, just for Eve. Which of course didn't work with action groups. I've done a successful landing + return before, it just was such a goddamn hassle that I don't even want to bother anymore.

That is a nifty plugin, however.

 

[Hellraiser]

Speaking of potato I should plant a flag on Gilly, the scoreboard reads 2:0 in favor of Gilly after all.

 

[Absalom]

Speaking of potato I should plant a flag on Gilly, the scoreboard reads 2:0 in favor of Gilly after all.

I have bad memories of that moon when I tried to kethane mine it ugh.

 

[Ulminati]

 

[Absalom]

How do the probe bodies docking change the state of lights? Do they have a battery that only powers that light? Or is it the lights undocking nodes, but how do they do that? Still, cool

 

[Ulminati]

I haven't looked at the craft file, but I'm guessing the lights are keyed to the action groups to give a visual indication of which engines are active. electricity is a shared resource across the entire vessel. There's no way to power some lights and not others that i'm aware of.

 

[Absalom]

Like I understand redstone circuits in MC and logic gates, sure. But I'm not sure how this functions as all that. Cool I guess though

 

[Ulminati]

Action group decouples docking port. Seperation force shunts probe body to the other docking port. Fuel lines go from docking port to engine. Engine fuel is inside probe.

 

[The Vanished One]

I never paid attention to the KSP development history, and I'd subconsciously assumed it was going well and fast. I was wrong.

http://forum.kerbalspaceprogram.com/showthread.php/32463

http://forum.kerbalspaceprogram.com/showthread.php/34313

Let me preface this by pointing out something people seem to forget. Squad is not working on this game because it's a labor of love. It's not a free mod. It wasn't a gift. Squad is absolutely no different from the development team who made Mechwarrior Online, Tribes Ascend, Sins of a Solar Empire, Minecraft, or the team that's currently working on Planetary Annihilation. Their team is also no smaller than most of these. This community has a chronic problem of fanboyism, people who have become exceptionally emotionally attached to the game and are willing to pour praise on the developers for everything they do, like every patch is a gift from god we should be thankful for. Do you think these people would be worshiping every patch Crystal Dynamics releases, the team behind Tomb Raider? Some people have this almost religious obsession with indy games, that because they aren't "evil publisher backed", therefore everything they do deserves to be defended to the death and they should never get criticism.

So let me ask this: What does Squad have to actually show for the last seven months?

I'll be honest, at this point in time, I honestly don't even care what Squad is working on any more. I care more about what the addon developers are doing, because their progress is better, their features are better, they seem to spend more time actually working on the game, and they've contributed significantly more to any interest myself - and probably many others - have in this game. As far as I'm concerned, 0.18, released last November, was the last time Squad actually did anything worthwhile. Development could've stopped since then and I wouldn't even have noticed. The team has grown in size considerably, and yet its progress seems to have slowed to almost a stop. Patches are no longer something I look forward to - all they're going to do is break my plugins - which at this point matter more than any Squad features - and give me nothing new or exciting.

Let me give you an example of what I consider to be a growing case of ineptitude:

- We were told .20 would include a system for 'modding' parts via changes in a separate .cfg, so you can change fuel tank values without messing with the original part.cfg. Not only was this system broken and not fixed in either of the 0.20 hotfixes, but a member of the community had to work with their primary code monkey to fix it.

- Remember when 'tweakables' were announced ages ago? Probably at the end of last year or maybe early this one? That same guy who fixed 0.20's broken feature for them also had time to implement the tweakable system for fuel tanks.

- Both of these features were developed and released inside of one week. He then also practically remade from scratch reentry heating, another promised feature we have yet to receive, in just a few days.

Christ on a cracker, three features we were promised months ago, some even longer than that, and it took a guy not even getting paid by Squad a week to make all three.

This makes me wonder whether granting alpha access is actually a bad idea in general, as it keeps people happy even in the absence of clear deadlines, and makes the devs complacent.

 

[Absalom]

Lol the modders have added in more than Squad. But it is a game about rocket science so I'm inclined to give them the benefit of the doubt.

And I always thought the kerbal forums were a little... off.

 

[Ulminati]

That's the problem with back-end improvements. KSP has gotten a lot more stable, a lot less processor intensive, migrated to a new version of unity and had its codebase overhauled so it can run natively on Linux and Mac. Implementing something like that has a high probability of breaking shit elsewhere and bug hunting can be extremely time consuming.

But because it doesn't add bulletpoints to some imaginary checklist of features, idiots assume nothing happens.



Overgrowth had a similar problem once. The developer would do weekly videos going over what he'd done that week in the current alpha. (You should totally watch them by the way. They're interesting despite the furry content). But eventually he made a video announcing he'd stop the weekly update schedule and just post things whenever he felt it was time. The reasoning for this was that a weekly update schedule encouraged him to focus on small, highly visible fluff features. In turn, well-known issues requiring large-scale cleanup of the codebase were piling up and untouched because they would result in several weeks of "this week I am still debugging the engine" updates.

 

[Absalom]

The linux compatibility will come in handy when I eventually man up and drop the Windows bullshit entirely.

Hopefully now that the base engine is optimized the content updates can go faster. The only thing that really irks me is apparently they're planning on removing the "End Flight" option when you hit ESC. Dunno why you'd do that honestly

 

[The Vanished One]

Here's a thread on the subject if you'd like to go through it.

http://forum.kerbalspaceprogram.com/showthread.php/29779

I only read a fraction of it. Apparently, the reason, or one of the reasons, is that some people sometimes mistakenly end flights they didn't want to. I did it once, as well, but I quicksave frequently so no big deal.

 

[Hellraiser]

People don't realize that every time you add or change something in the code something breaks and that implementing anything is mostly fixing and optimizing shit. The more complicated the code is the more likely something is to break.

They worked on bringing everything to work with the new version of unity and on linux support since January. Then they worked on coding in the rover wheels, new animations for kerbals and the particle system which allowed dynamic re-entry effects, that was done in March. They ironed out the post 0.19 release bugs and worked on rover seats, the knowledge database, flags, memory optimization and fixes, normal mapping for planetary terrain, craft filtering, the root part restriction change and how mods are loaded. All that got released in 0.20 in May, not that impressive as far as content goes but that's a lot of coding that had to be done, fixed and optimized before it could be released.

Adding a new part of an existing part type/function is piss easy compared to that, because the framework for it already exist, after you do the art assets you just need to copy paste the part code from another engine and change whatever values are appropriate. When you get stuff like rover wheels, the control seats, resources or even the re-entry effects there's a shitload of code needed for those features that simply did not exist. If it didn't require so much new code those features would be added eons ago.

Still they're closer rather than further away from actually finishing the thing, the deadline to finish the game by the end of the next year seems likely to be met. The three biggest features they'll spend the most time on implementing before they can say they finished the game are a new aerodynamics model with re-entry heat+shielding (possibly will require payload fairings if they want a fairly proper implementation), career mode (needs working mission generation, kerbal training and working kerbal stats, research and tech tree, discovering celestial bodies) and resources. They decided to shift focus from resources to career mode which isn't surprising since that part requires the most new features to be done while not being implemented at all in any form yet.

 

[Absalom]

I'd love payload fairings. And I know man its the unsung part of software development is making shit work. Their forums are a bit saccharine tho. Screenshots of Ulminatis mission are coming up, hopefully I don't leave any boneheaded errors in them

 

[Absalom]

My first attempt I forgot the fucking mono propellant on the lander so I had do everything over (long story) so I only have a few screens from the lander and mother ship rendezvous

Laythe lander. 10 tons, has 3000 Δ so the mothership is going to have to tow it to Laythe.

Lander with mother ship. Mother ship has around 4000 Δ with everything attached so I may have to use aerobrake (which I dislike doing.) Hopefully as payloads are dropped I get more bang for my buck. To further this end, Bill is going to have to go back to Kerbin so I don't have to tow the lander back home. Why can that cupola only seat 1? I used a probe core as the root part for the mother ship hoping the cupola would be empty but I guess they changed that in the update.

You can also see the 4 probes for the Joolian moons, they are rather uncreative but they host all scientific instruments available as well as 4 antennae.

Rover on the launchpad. 1.5 tons with 220 Δ, enough for a Bop landing. I plan on using the Bop probe to tow this thing into orbit and deorbit burn.

Launch was successful, and I finish my OIB 100kmish away from the mothership. Though as I'm slightly ahead I need a slightly higher orbit for the mothership to catch up.

This is when I realized I forgot about the electrical issue. Stationary solar panels are great for rovers since they're (hopefully) always pointed up, but during the rendezvous I realized I'm slowly losing charge. Planning of craft orientation becomes key, though I only need 2 orbits to get within 5km of the mothership. Thank god the probe/tug has moveable panels.

Probe successfully docked with MS. I decided to try using mechjebs docking autopilot, and surprisingly, it worked. Though it used 85% of my RCS fuel. Will I have enough to dock the probe with the rover in Joolian orbit? In the spirit of C&C, I decided against reloading and doing it myself. I am a freak and actually enjoy docking, anyway.

Part 2, when I enviably fail from inadequate planning, is coming later.

 

[Hellraiser]

Looks pretty good so far. BTW Kethane got update, now it's not just officially compatible with 0.20 but also they added two new parts. A big stack mounted drill with some nice particle effects and what I think is a kerbal blender, don't ask.

 

[Ulminati]

and what I think is a kerbal blender, don't ask.

Does it turn them into fuel? Does this mean Soylent Kethane is Kerbals?

 

[Hellraiser]

Does it turn them into fuel? Does this mean Soylent Kethane is Kerbals?

I think it does judging by the comments in the Kethane topic, didn't find the time to check it out yet though.

 

[Absalom]

The fuck kinda name is Burhat, anyway? Go on EVA I wanna try something

*click*

I WANNA BE A... rocket fuel?

150 units of kethane? That's 20 oxy and 20 fuel! Totally not worth it.

Ulminati As I've taken on your mission, your mission is follows: Landing and return from Eve, powered wholly with Soylent Kethane

 

[Ulminati]

I don't use plugins, nya :3

 

[Absalom]

Actually the kethane jet turbine had the possiblilty of making it super easy. Oops! So now it's landing and return from Eve with all stock parts and no refueling

 

[Burning Bridges]

I wonder how you guys normally get to Moho?

In my first attempt I managed a flyby at ca 5 million km. It was actually hard enough to just get the encounter. But at the breakneck speed (>12.000 m/s) a bit like making two bullets hit the other in flight. To slow down and stay in Moho's SOI another ca 5.000-7.000 m/s were needed, and there was only a short time window (like 30 minutes game time). I didn't make it of course, and the mission did not give any results except some images of Moho crossing the Sun

Hm, I had actually tried to do everything right. Under normal circumstances and on a normal planet it is very easy to just slow down when I enter the SOI, but Moho must be extremely hard. DeltaV is probably not the problem, for unmanned probes one can get such deltaV easily. But I think it must be done extremely efficiently or even the most powerful spaceships will fail.

So how are you doing it? I heard that you can use Eve to slingshot to Moho? I read that the inner planets must be approached on a retrograde orbit?? Is this even correct? I wonder, does this not make the speed difference with the planet even larger, and therefore require more deltaV to slow down, compared to an approach where the craft approaches the planet on a more parallel course?

I have used the AdamKSP to get the launch window, and launched from a prograde orbit. The ejection angle is of course mostly guesswork, it could or could not be right. I relied more on maneuvre nodes. As I said I got an encounter, which was pretty "close" (5 million km). Adding additional maneuvre nodes to get closer to Moho didn't give any improvements and was frustrating (that part may even be bugged, the nodes showed T-52 days when it was just a few hours away). At such close distance did not feel right to get so close and still miss it, but it was an interesting new lesson, now I understand why it's difficult for NASA to get to Mercury, and use these complex Venus / Earth flybys.

 

[Hellraiser]

How did it take you 5 km/s of delta-v to enter orbit around moho? It's about 2 km/s (not counting delta-v needed to get an encounter first) in my experience and according to the delta-v map posted earlier in this topic. Still a lot, although I can see how hard reaching Moho can be from Kerbin orbit. Although NASA uses slingshots mostly for delta-v saving rather than accuracy.

I went solar orbit>eve slingshot at 400 km periapsis (IIRC)>solar orbit>moho. Which is an inefficient way of doing things apart from the slingshot. Although I wonder how good the oberth effect really is as far as delta-v saving is concerned.

Anyway if you have problems with the proximity of the encounter my bet is you need (anti-)radial/normal burns to adjust your encounter. Moho is small and close to the Sun, if your inclination is marginally off even by a fraction of a tenth of a degree you miss it like hell. Same applies to coming in from the radial/anti-radial direction. If you're doing that and still not getting shit protractor is bugged (because you can always plan a close as possible surface grazing encounter regardless of the trajectory, it's just that it may require an unrealistic amount of delta-v) so I recommend double clicking on the moho encounter periapsis which you will get from a planned maneuver (so it's distance displays all the time even as the cursor is not hovering over it) and adjust the maneuver using that.

When aerobraking from retarded interplanetary trajectories with sometimes really small encounter windows (Jool>Kerbin in particular because I botched my launch window for a proper hohmann transfer) I first tried adjusting my inclination plane to get the lowest encounter periapsis, then I adjusted it on radial/anti-radial axis. Works like a charm every time, only issue is delta-v for insertion if you can't aerobrake (like on Moho).