Archgeek

Gah, I currently work with an AS/400. My place o' work runs a giant DB2 database and a lot of cobol and CL stuff (as well as our web server for some reason) on one of the things. So much emulated greenscreen.

What oh what would JS be doing in a full non-web-browser-hosted game? Does Unity really use Javascript for things?

When you forget to pop a probe core onto the transfer vehicle for your single-launch to Laythe craft, leaving your lander to dock very carefully.

HAH! That looks like its own little mini-hype train.

Nah, you don't have to rewrite for every platform, just abstract all your system calls to a platform interface class, write one of those for each platform you care about, disambiguate them with a pre-compiler directive, and just recompile with the appropriate options on each platform. Easy-peasy. (this forum needs an :evil_grin: emote)

To pull this off in stock I'd go with a kraptonne of klaws. You can't defend the whole thing with heat shields, but you can place them in strategic locations. I'd put klaw parachute modules (drogue and full, of course) around the ring with klaw heat shield modules under those, plus another heat shield klaw'd to the core, and an array of large active radiators klaw'd to the back of the core. The heat shields should help mitigate the overall re-entry heat at least a little, and actively defend the parachute and radiator modules. The radiators should hopefully siphon heat from all over the craft, making up for sections the heat shields can't protect. However you wind up doing it, rest assured we'd all love to see screenshots or a video of the insanity. XD

Whoops, colour me corrected. I didn't read that bit about the half output. By all rights the part should be both more mass and energy efficient (implied that it's using fancier tech inside, plus that fancy bus to the side could be up to some trickery), but that should yield no more than a 20% output improvement, and that's stretching it.

No doubt that's working as intended. Efficiencies of scale, Squeaky Muldoon.

For some reason I've gotten into the habit of always using certain action groups in certain ways across all vehicles. For instance, action group 1 is always a solar panel toggle (lights in career before unlocking the numbered ones), and I always make a two-phase abort sequence -- Abort: cut all engines, decouple whatever's been defined as the escape vehicle (pod with tower, spaceplane cockpit, or cross-range capable return stage), and fire its thrusters or escape system. Group 0 (brakes if group zero not unlocked in career): decouple escape thrusters if needed and pop chutes. For some reason I never deviate from that pattern.

Now this has been quite the interesting and informative thread. 'Seems like the core flight simulation loops are in significant need of tightening up, as it seems the entire ship is scanned every step for every part that wants to consume or provide a resource, which is frankly terrifying. They very likely would see a surprising performance jump if it were scanned once -- with the scan populating lists of producers, storage, and consumers for each resource (EC, LF, O, Mono, Xenon, Ore, and I hope ablator was written as a special case) which are cached until lost, and flagged when depleted. Tightening resource scans alone would help a lot, but other loops seem to need tightening as well, which would in turn better expose where they can get away with parallelizing things for multi-threading (even my poor old Core 2 Duo would benefit from this) I throughly understand how off-the-cuff that initial exploratory "can we even make this work" phase can be, but once a proof-of-concept is together, next should really be tightening it up enough to not want to explode, then profiling and fixing glaring computational bottlenecks and redundancies before adding more features (though ideas for making new or planned features will turn up and should be considered when tightening stuff up to avoid over-optimizing the incomplete version). Test-based design and unit testing would be great for preventing and early sqashing of bugs, but I'm guessing with a team that small no one had time to learn something like cucumber, though the argument could be made that the beta phase should've been just that. Still, good on SQUAD for making this awesome thing in the first place. Hopefully a code-repair pass will find itself embedded in all the unity 5 re-writing.

No need. There's a subtle little animation that whips around the target orbit if you watch it a bit. The direction it moves is the direction of the orbit.

Sounds to me like an unshielded pod from Minmus might in trouble now, as well as an unshielded pod from the Mun on a dumb trajectory.

Nah, I used to think like that myself. Orbital mechanics is kind of easy in patched conics land, but it's still a little unintuitive for creatures who grow up this deep in a gravity well. It's to the point that those of us who know better sometimes only store the result in our heads and run around in circles when trying to support it. </self-deprecation> One has to latch on to the fact that with the right timing, horizontal takeoffery can have the exact same ejection benefit as vertical ascent, meaning they're on equal footing save for gravity drag, which is usually enough to get the logic engine to turn over in the face of one's false intuition.

Oops, good point there. I was getting a bit fast and loose with the terminology. Also, I clearly confused myself a little and attributed too much to the Oberth effect. There is some oberthage going on, as an orthagonal burn escape does do its burning close to the surface and thus deep in the gravity well, but yeah, the main savings is in mostly ignoring gravity. Once you're safely falling around the mun, every kN of thrust goes into your escape, while on a vertical ascent, you're spending your might on holding yourself up on a pilar of flame, and only get to keep the difference.

You do fight the mun's gravity, but you don't have to fight it as much. I once thought as you did, but a couple of little experiments proved me wrong. I just tried both things from the same quicksave, and checked how much fuel I had left once I made good my escape, then calculated remaining delta-v using notepad and calc.exe (this was before I started using KE). The flat exit beat the direct ascent handily. Also, it seems I was wrong on the Oberth bit, there. Direct Ascent would get a weaker Oberth effect due to rampaging out of the gravity well as quickly as possible rather than burning deep within it. Ohoh, moving the goalposts, eh? That's not fair, but my advantage is less fair so I'll allow it. The answer's simply east -- you just burn up clear of local terrain, burn east until you've an apoapsis clear of the mountains, then whip around the Mun until you're a bit past 180 degrees of your starting point, then burn hard prograde (nice and near the surface, you'll note) into an ejection angle that's nicely retrograde to Kerbin until your Kerbin PE is at your favourite re-entry height, 'same as you would with having burned straight up earlier. The dealyotrope is simply that energy put into an orbit is never lost, you can add to it whenever you like, and by burning closer to the surface you get a nice Oberth effect savings on your delta-v. It is true you're still "fighting gravity" by having to put enough energy into it to escape, but by opposing it directly, you wind up moving slower at the end of your burn than you would be burning near the surface (which is kinda how the Oberth effect works). It's a small savings on the mun, pointless on Minmus, but nigh-mission-critical on Tylo.

Not quite, and as said before, you're actually wasting delta-v going straight up. The cheapest way home from the mun is hard and flat from little more than 90 degrees shy of Kerbin retrograde. This lets you whip around the Mun with an ejection angle pointing fully retrograde to Kerbin, barely fighting the Mun's gravity at all, and getting that sweet sweet Oberth goodness from doing the whole transfer so deep in the Mun's gravity well. Do the same thing from just shy of Kerbin retrograde (to make up for Munar rotation), and burn straight up, and you've got the same nice ejection, the same Oberth party, but you're leaking delta-v by directly fighting the Mun's gravity.

Wow, that looks a lot more effective than my crazy Von Braun tug. Mine's got a lot more fuel and half the thrust, making for a pathetic TWR. It can get a 101 tonnes on a kerbin escape and come back, though.

Knowing how some things are coded, I'd say it's likely along the lines of "The first one placed on the antenna bearing part closest to the craft root", since the game's craft function logic radiates outward from the root of a craft in a depth-first search, and when things are in the same node of the tree they tend to be simple lists ordered by placement.

I'd go with a huge heat shield sans ablator or a custom shade made of structural panels (or wings...does the game model albedo?) on one end of the ship to take the heat, under a big fuel tank to soak up the heat, bearing a bunch of fins or panels (carefully kept in the shadow of the shade) to purge the heat, and the other end of the ship with all the sensitive probe core and battery like parts connected to the assembly via a docking port, as those make weirdly good insulators. 'Might have some upward facing panels on the sensitive end as well, just to help keep it cool. Dang it, now I'm tempted to build a sundiver this weekend and see how much a few different designs can take.

Just to add to what's already been said, it does not in fact need to be a grind. Need more cash, sure, you test parts, but why just test parts when you can incorperate part tests into your missions? Some part tests are convenient and ask you test a part when you'd be using it anyway, like testing a booster when landed on Kerbin. Others give you temporary access to parts you haven't even unlocked yet, and if they fit your mission profile, can help simplify a mission you were doing anyway. For instance, I'll often combine part tests with a rescue mission, making dreadbank and getting free crew member.

Heh, I remember the night 1.0 came out I took the Aeris IV upstairs, and quite afraid of the new atmospheric effects, came in at a roughly 90 degree AoA, treating the plane like a sail, desperate to purge as much speed as I could before things got thick and nasty. I eased my way down as the gs started to mount, but never got over 5gs, and only subtle little flare effects, with not a thing exploding. Would the aero forces really tear off wings of a pancaking craft at the very top of the atmosphere? I'm not sure it's thick enough to produce that kind of force until at least 56km or so.

Cool kerbals don't look at explosions.

Ah, complete with radially-attached bacon for added control authority. Very nice.

Far, far too long for me. I can work on an individual craft all night and not be done with it, and my Helios project is yet incomplete and has been under way since .20. ...Which reminds me that I should really fire up my .90 game and bring home the intrepid pilot of the experimental Xenon Tempest m1k, which went sun-diving and then a bit of trouble encountering kerbin again, though I finally planned a burn that'll work and saved it in kerbal alarm clock.

Heheh, that or you fully intend to hover over the crater and land softly on the other edge, like my silly Puddle Jumper rover. I was wondering why I've not experienced this issue. N cheers for the Claw-erator! for(int i = 0; i < n; ++i){puts("Herp derp, huzzah!"); if(i < n) puts("\n");}