vyznev

Members
  • Content Count

    121
  • Joined

  • Last visited

Community Reputation

199 Excellent

About vyznev

  • Rank
    Curious George

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. vyznev

    Duna InSight Challenge

    That's pretty darn minimalist, indeed. Congrats! I do suspect that dropping the reaction wheel and replacing the Ant engine with a Spider (which can gimbal) could save even more mass. The only detail I'm not 100% sure about is whether that could be made stable enough in Duna's atmosphere. I may need to test it...
  2. vyznev

    Duna InSight Challenge

    Considering that even just the OKTO2 probe core alone is both bigger and heavier than the actual MarCO cubesats, that's pretty much unavoidable with stock parts. Unless you tweakscale them down to a tiny fraction of their normal size, at least. I did manage to cobble together something that at least looks vaguely similar: But it's still several times bigger than the real ones, and over 50 times(!) heavier.
  3. It's a suggestion; @sturmhauke is not on the micro-challenge team (see first post in this thread). But it did occur to me that recreating the InSight mission in KSP would have plenty of targets for a full-blown "tick the boxes" challenge. I couldn't find one on this forum yet, so I just might try my hand at making one, if sturmhauke doesn't call dibs. Anyway, that would be something for a separate thread.
  4. vyznev

    Kerbal Galatic LKO tourbus challenge

    You post it in this thread, of course:
  5. A seismic scan seems reasonable enough to me. (The really annoying thing here is that the DTS-M1 antenna is not relay-capable. )
  6. vyznev

    Sun Atmosphere Sampler

    KSP heating mechanics get wonky in time warp. I've built craft that were perfectly fine sitting at their Kerbol periapsis in 1x warp, but would overheat and blow up instantly at 5x warp. I think what happens is that the game is still tracking the heat in time warp, but using much larger time steps. And it probably uses simple Euler integration instead of some fancier integration algorithm -- that is to say, on every time step it just calculates the net rate of heat gain/loss over time for each part, summing up all heat sources and sinks, and then multiplies this by the length of the time interval (and divides it by the part's heat capacity) and adds the result to the part's temperature. Now, the rate of heat loss through radiation (and conduction to adjacent parts, etc.) is generally proportional to temperature (both in KSP and in real life), while the rate of heat gain from the sun is constant (or, rather, proportional to the temperature of the sun, which of course is pretty constant). So what happens is that each part will basically have an equilibrium temperature where those two rates are equal: if the part is cooler than its equilibrium temperature, it will gain more heat than it loses, and if it's hotter than its equilibrium temperature, it will lose more heat than it gains. The problem is that, if the time step is too large, the temperature change calculated in the simple way described above can easily overshoot the equilibrium. For example, let's say you have a part on your probe that would be at equilibrium at 2000 K, but is currently only at 1999 K. And just to keep the numbers nice, let's say that its temperature gain/loss rate at 1 K below the equilibrium, as calculated by the game, is 1 K/s. At 1x time warp, the game does something like 100 physics time steps per second, so on the next timestep the game will increment the part's temperature to 1999.01 K. And on the next time step it will heat up by, say, 0.99 K/s, so its new temperature will be 1999.0199 K. And it will keep gradually heating up more and more slowly as it approaches its equilibrium temperature, and all will be fine. But if we're instead at, say, 1000x time warp, then the game obviously cannot do 100,000 physics updates per every real-time second; your CPU isn't that fast. Instead, it just keeps doing 100 updates per second in real time, i.e. one update per 10 seconds in game time. (Well, OK, for a simple craft it probably could do 100,000 updates per second, if the heat physics code was optimized enough. But the point is, there's always a limit and the game doesn't even try to scale the physics update rate with the warp factor.) So that means that, after one physics update tick, the part will now be at 1999 K + 1 K/s * 10 s = 2009 K. And what's worse, on the next time step, the game will see that the part is now 9 K above its equilibrium, and calculate its new temperature gain/loss rate as something close to -9 K/s, and thus its new temperature, one ten second time step later, as 2009 K - 9 K/s * 10 s = 1919 K. And now the part is 81 K below its equilibrium, and thus heating up at a rate of about 81 K/s, so one more time step later it will end up at 1919 K + 81 K/s * 10 s = 2729 K. And then it will blow up, because it just exceeded its heat tolerance of 2500 K. Now, if the KSP devs wanted, they could pretty easily replace the simple Euler integration with something more advanced like fourth order Runge-Kutta (which can still blow up if the time step is too large, but is a lot more accurate and less likely to do so) or even the backward Euler method (which is no more accurate than the normal Euler method, but tends to undershoot rather than overshoot at large time steps, and thus won't blow up). Both of those are a bit more complicated to code and require more time to calculate (since they need to recompute the heat gain/loss several times per timestep to find a solution), but they would solve, or at least mitigate, the stability problem. Unfortunately, I suspect this this is probably not a high priority for the devs, since few players will ever put their craft in situations where it really matters, and those who do will probably just chalk it up to low Kerbol orbit being inhospitable to spacecraft. (As a disclaimer, I should note that everything I wrote above is just informed conjecture. I have not looked at the KSP code to see how it actually updates part temperatures. But I have written physics code myself, both for games and for scientific purposes, and the simple Euler integration I described above is pretty much the simplest and easiest way to write something like the part temperature tracking in KSP, especially if you don't actually realize that what you're implementing is an integrator. Also, the symptoms fit.) (Edit: After some testing, I think there must actually be something more going on. It feels like KSP is doing something like scaling the heat gain/loss rates down under time warp, perhaps precisely to avoid the overshoot effect I described, but doing it in some weird way that can cause the equilibrium temperatures to go up or down depending on the time warp factor. I dunno. I still stand by my initial statement that things "get wonky" under time warp. )
  7. I just thought of another challenge suggestion: launch and dock two vessels in Kerbin orbit, like in the earlier "SRBs to orbit" challenge, but this time using no reaction wheels or RCS. (If your command pod or other parts have built-in reaction wheels or RCS, disable those. And yes, Vernors count as RCS.) That basically means using only engine gimbals for steering. (Aero surfaces are OK too, of course, but of rather limited use in space. Not sure how I feel about abusing time warp to kill rotation. Probably I'd say it should be regarded as permitted but cheesy. ) It's definitely doable, and teaches a useful skill. For a bonus challenge, turn SAS off and fly the whole mission 100% by hand. (For easy mode, could maybe allow reaction wheels but still forbid RCS.)
  8. vyznev

    Kerbal Galatic LKO tourbus challenge

    TBH, it's not hard. It just means that you need to throttle up if you want to steer. But you don't need to throttle up much, usually just the tiniest nudge of the Shift key is enough get you some steering control. If you really want to conserve fuel, you can even cut the throttle again once you have the vessel rotating, and just let it rotate until it's facing the way you want (or until you realize that it's rotating the wrong way and you need to make a correction...). Come to think of it, that would make a neat micro-challenge: launch and dock two vessels in orbit using no reaction wheels or RCS. It's definitely doable. I'll go and suggest it.
  9. vyznev

    Asymmetrical Aircraft Challenge

    Now that's seriously impressive. I tried making an SSTO for this challenge earlier, but I just couldn't get it to handle well in the 20-30 km region at all. (Admittedly, I was trying to do it without rapiers, which probably added needless extra difficulty. But still. Well done indeed.)
  10. vyznev

    Kerbal Galatic LKO tourbus challenge

    Here's my entry for the disposable category. Perhaps not surprisingly, it looks a lot like @TheFlyingKerman's entry, and I admit to shamelessly stealing the service-bay-as-airbrake trick from them. My version is slightly cheaper and more primitive, though. It costs 5,985 kerbucks, seats four passengers and qualifies for the -10% caveman bonus due to only using parts from tier 4 and below. Thus, its total discounted per-passenger cost works out to 0.9 * 5985 / 4 = 1346.625. The first stage is attached to the launch clamp with a slight westward tilt, and looks as if it should be launching retrograde. In fact, the combination of its slightly unstable aerodynamics and the shifting center of gravity during the first stage burn instead cause it to execute a really neat mid-air turn and head eastwards at a roughly 50 degree pitch, which is just about perfect for the launch profile this craft needs. I wish I could say I designed the craft to launch like this on purpose, but to be honest, it just happened by chance and I decided to go with it. The piloting is done by a Stayputnik probe code hidden inside the service bay and the nose cone. However, there's actually not much piloting to do, since the ascent and re-entry are almost entirely hands-off. Indeed, the first stage and the re-entry stage have no active attitude control whatsoever(!), and the second stage only has the gimbaled Terrier engine to steer with. All you need to do is launch with SAS off and throttle at max, stage when the SRB burns out, keep burning until your apoapsis is between 70 to 80 km, throttle down, coast to apoapsis and circularize. If you do the coasting under physics warp, the craft will even maintain a prograde heading automatically. To return from orbit, turn retrograde, burn the remaining fuel (which should drop your periapsis down to about 50 km), open the service bay and stage. Note that the craft has no RCS or reaction wheels, so you need to throttle up slightly to steer. Or you can just timewarp until you're pointing retrograde anyway. If you forgot to open the bay before staging (like I did ), do it afterwards and manually deploy the parachutes. The craft will naturally turn sideways in the atmosphere (and tumble in a way that will surely thrill the passengers, or possibly make them airsick), and the chutes should semi-deploy automatically around 11 km. Imgur album with more screenshots: https://imgur.com/a/YC4uSIB Craft file: https://pastebin.com/0t5JEJcs YouTube video: There's a couple of potential ways to reduce the cost further. One is that the battery inside the service bay is technically not necessary if you're really agressive with hibernation and only turn the Stayputnik on when you absolutely need it (i.e. for staging and orbital maneuvers). You can't stay very long in orbit if you do that, though, since even hibernation still consumes some power and the Stayputnik only has 10 units of it. Another option I considered was replacing the first stage decoupler with a cheap girder segment and using overheat staging. While this works fine as far as the staging goes, and saves almost 400 kerbucks, it unfortunately also messes up my elegant and efficient launch maneuver. I'm not sure if it's the changed aerodynamics due to having a 0.625m part in the middle of the stack or what, but I just couldn't get it to work properly no matter what.
  11. vyznev

    Small Falcon 9 Challenge

    Well, I made a 2.5 m scale Falcon Heavy back in January, so I figured I could just rebuild a single-core version of it for this challenge. Actually, I already did this last month and posted screenshots of it in another thread, but I forgot to post it here too. So here it is now. Better late than never, I guess. Anyway, I believe this meets the following targets: It might also be able to do a boostback RTLS and still make orbit, but I haven't actually tested this, so I won't count it. Honestly, looking at this craft and the target list now, I see several potential ways to improve it. For one thing, the first stage is kind of short and stubby compared to the real Falcon 9, and could probably easily accommodate one more fuel tank. Also, the second stage was just something I quickly slapped together, and I could easily improve it for more points. And of course I could always turn it back into a three core heavy variant like I flew back in January. Still, at least it flies (and lands). Here's the craft file: https://pastebin.com/Kz2yJduX And here are a few more screenshots of the test flight (including a bunch of failed landing attempts): https://imgur.com/a/A1mt0Ik I do also have video of the flight, but I still haven't gotten around to actually editing it. Maybe later...
  12. Of course, I went directly for the True Belter goal. As they say, if you aim your rocket at the Mun and miss, you'll still end up in space. If you aim for the ground, you won't miss! And as it happens, I didn't miss, and I wasn't aiming at the ground, either! So, without further ado, here are the screenshots: Not shown above: the second and third encounters with Vall and Tylo, and the numerous orbits spent waiting between them. For more screenshots and commentary, see the full album at https://imgur.com/a/W3AqhVL. The total mission time from the initial maneuver burn to the last encounter was a little over 1 year and 169 days. During that time, I flew by Pol, Tylo, Bop, Vall, Vall again, Tylo again, Tylo yet again, Vall one more time, and finally Laythe. Out of those encounters, only the first three (Pol, Tylo and Bop) were planned ahead. After that, I just trusted that I would get more encounters with the inner moons and hopefully encounter all of them before getting flung out of the system or crashing into Jool or one of the moons themselves. As it turns out, that worked out just fine, although getting that last Laythe encounter took quite a bit of waiting. The only mods I used were Precise Node for planning the maneuver and KER for precisely executing it. Of course, I also used Alt+F12 to initially cheat the craft into a circular Jool orbit with a 250,000,000 meter radius. (Unfortunately, the challenge statement seemed a bit contradictory on the exact altitude / radius required, and I never got a reply to my request for clarification, so I just decided to go with what I already had. Still, I don't feel it really made any difference in the end; the challenge would have been no easier or harder even if I'd started at a 254,000,000 meter radius instead.)
  13. Wait... shouldn't that be 244,000 km? At least that's what I get when I cheat my ship to 250,000,000 meters above Jool's center of mass. And the wiki seems to agree, listing Jool's radius as 6,000 km.
  14. vyznev

    Eve biome hopping plane

    Honestly, doing this in stock KSP (without stock propeller hacks) is kind of unnecessarily difficult, simply because the stock game lacks any engines that would be suitable for the conditions on Eve. Eve's atmosphere is so thick that flying in it is almost like swimming through water, and the ideal propulsion method for it would be what ships (and low-speed aircraft) use on Earth: propellers. But there are no real propeller engines in stock KSP, unless you build them yourself. To add insult to injury, there are also no jet engines that work on Eve (which might be reasonable, depending on what Eve's atmosphere actually consists of) and no rocket engines with nozzles properly optimized for the pressures on Eve's surface (which is not). Of course, as a challenge, making a plane that can fly around on Eve using only stock parts is just as sensible as, say, making an SSTO spaceplane using only SRBs. It's fun precisely because it's hard. But if you want to do it in a real game without making it deliberately hard for yourself, I'd recommend installing one (or more) of the various mods that provide engines more suitable for the job (such as Eve Optimized Engines or Explodium Breathing Engines or Firespitter). (Or, if it helps your sense of realism, you could consider using stock props but powering them with fuel cells instead of the usual RTGs. It's quite doable, and at least means that your engines will still be consuming some fuel and oxidizer.)
  15. vyznev

    No SpaceX Flag?

    I finally found the SpaceX flag I made: I also made one with just the X, but I didn't like it so much after all. Maybe someone else will, though: