swjr-swis

My pre-order policy is simple: . <syntax error> [DOES NOT COMPUTE] What is that you say? Buying before I even know what the product actually is? And paying extra just for doing so? Yes yes, I also buy swamp real estate, random bridges and treasure maps at garage sales. No. My 'early access' policy is simple too: quid pro quo. I'll be a free beta tester if it lowers what I have to pay for the product. The current trend of asking me to pay extra for the 'privilege' to deal with bugs is a sure way of ending up on my 'we'll see somewhere down the line if you can still convince me you can actually finish what you started' pile. I don't think I'm exceptionally patient, but then I also have a couple thousand games to keep me busy while I wait. Plus of course in this case the eternally-almost-finished original KSP. I think I can manage to pass my time until KSP2 is close to fulfilling all its promises. Perks? I hope this is not your way of saying 'we already plan to add some stuff after release and call it DLC, and you may get some of that as a gift - yes, we'll call it a gift!'. TL;DR: show me what you got, and tell me how much you want for it. If it seems equitable, I might buy. That's it. No pics, no clicks I mean, no tangible product, no buy.

If you find the need to do this, remember that you can 'Jettison' full tanks of ore! Just bring a sizeable ore tank, and keep dumping as you mine what you no longer need for the ejection burns.

I'm missing the options to start the climb from the deepest point in the ocean, and scoring according to the biggest altitude difference traversed. Naturally, the only allowed vehicles should be powered by hamster kerbal-wheels. Kerbal buoyancy would be an acceptable way of getting through the first leg of the trip. I'll sit this one out - I just don't have the time for these kind of challenges anymore. Should be interesting to see how this pans out.

The F3 window has always been very inaccurate when it comes to speed/distances recorded. Additionally, it will sometimes wildly overestimate the values at apparent random, which means there's no easy consistent way to recalculate what the accurate numbers should be. This has been a known issue for many many versions now, if not always. There's been a number of challenges where the ultimately winning entry so vastly surpasses even almost identical craft, that one can safely assume the F3 randomness to have played a major part, but it is what it is... in stock we have no other information to work with.

<hushed> Anyone wanna buy a slightly used Grays Time Machine Drag Race Almanac 1950 -2020 and place a little bet? </hushed>

What actually happened is he set his return clock 10 minutes before the time he left in an attempt to warn himself about the Tardis pilot stealing his snacks. He did cross the finish, but 9m37s *before* the starting shot, so he was summarily disqualified due to a false start.

I thought it was magnets.

No real rewind, but you can still do this two ways: by saving a game state at a certain date and time you wish to be able to go back to, and reverting to it or loading it. Or by editing the persistent.sfs in the save to fill in an arbitrary time (it's a text file). The value you're looking for is 'UT = xxx.xxxxxxxxxxxxxx' with xxx.xxxxxxxxxxxxxx being a floating point value between 0 and 19760285526235197 (at this point, less than a second to in-game year 2147483647, the game starts going crazy).

I do second this, but I am a bit wary of payload in such short bay sections ending up not being shielded from drag despite being entirely inside a closed multi-segment bay. We've seen this in the existing cargo bays, where a payload with a part that crosses bay segments and more than half of its length in another bay segment ends up unshielded to drag, because only the bay segment the part CoM is in is checked for that part. With service bays being so short, this would become much more common an issue. Or was this resolved already?

I am confused and do not know how to take the above. Took quite a while editing that post to make sure I did not discourage you from sharing your craft, but that closing phrase sounds like I missed my target. I expressly avoided answering with my own craft and took time to search for examples from others as it seemed more appropriate. In a rather ironic way, you seem to be right about some people here needing a safe space - I'll rethink hitting the reply button next time. I do hope you're wrong about soy milk though, it's awful. Peace and rainbows and stuff.

One thing I wondered for a while now about KerbalEDU and somehow never got around to ask: why isn't KerbalEDU a DLC for the regular game? Looks to me like a perfect fit for DLC release being an incremental set of dialogs and parts, and you would probably get as much sales from regular players as from educational buyers. More income, more profit, more incentive to spend extra manpower to update/improve it? Is there a downside?

Corrected that for you, but yes I thoroughly dislike how it's become 'accepted' that software cannot ever be finished, feature-complete, properly documented, or reasonably bug-free on release. Over the years we have gotten more sophisticated tools, IDEs, prefab components and modules, better standard practices, a plethora of online resources, and we are drowning in processing and transmission capacity, memory and storage.. and yet product quality and reliability seem to keep going backwards instead of improving. </rant><deep breath> Anyway. Service bay revamp good, keeping old model as variant would certainly be nice (open bay doors have served me well as quite durable landing gear!), but please check what part of the associated code causes that excessive drag when closed and leaving the internal nodes unused. It's annoying to always need to ensure the nodes are 'plugged' just to get the low drag expected when placed between other Mk1 parts.

https://kerbalx.com/zedextreme8177/Tholhi-LF-only-long-range-SSTO Not my craft, just an example. Btw, when it comes to spacecraft, heavier does not usually mean better... more the reverse, since this isn't about payload. The above craft achieves all the same things with less parts and lower starting mass. In spacecraft terms, that's winning. https://kerbalx.com/Hotel26/Four-Of-Diamonds Also not my craft. Mk1 and same type and nr of engines, but using lower tech parts otherwise. Less total parts and starting mass. Less dV in orbit, but does lift 5 crew instead of 3. https://kerbalx.com/AeroGav/SX-60L Again not my craft. Same type and nr of engines, higher starting mass (so yes, one rapier can lift more than 35T). Somewhat less dV in orbit, but arguably more aesthetic mixing advanced Mk2 with Mk1 parts, lifts twice as many kerbals, full RCS capability for docking. And yet others have made working spaceplanes using Whiplash, Panther, and even Wheesley and yes, Juno. Examples can be found in this forum and on KerbalX, if you wish to search for them. Would it surprise you to hear that each one of those has been done and published here and on KerbalX multiple times over the years? I'll spare posting even more links, but you get the idea. TL;DR: yes, nice craft, worthy of publishing and being proud of. Clean lines, KSP-optimized drag, relatively low on parts - all things I like. There's things I would do different or change, but that's all a matter of personal design priorities or preferences. Just know: KSP has been around for a good nr of years now, with a lot of pretty creative people working the same problems with a limited nr of stock parts. When optimizing, many similar solutions tend to come out of that. Odds are stacked quite high to find that it's been done before, or better, by multiple people. Most work doesn't even get published anywhere. I only publish sporadically myself - the time it usually takes me to gather screenshots, record a movie, edit, and post it all is often a deterrent for me when I prefer to play (or more likely, keep tinkering on the design). No less achievement for you, and keep sharing, that's what KerbalX and this forum are for.

While a welcome upgrade in looks... have you looked at resolving the disproportionate drag of service bays when the internal (shielded!) nodes are left open/unused?

I see. <already left>

Confirmed that this -sometimes- happens. Not consistently though, at least not in my case.

Indeed. Oh and don't ask about the three seashells either.

Don't get me started... . . .

The tag [description] is substituted by the contents of the in-game craft description field. So like Val said, edit the description in-game, re-upload, and that typo will be fixed. Alternatively, if you wish to have more control over the description used on the KX page, you can remove the tag and replace it by your own text of choice. I do this often because I try to keep the in-game descriptions short and format it for readability in the game, which is usually not so good for the KX page.

It's always possible that kerbals have us all fooled. We think they are physical manifestations, but they may just be a form of electromagnetic energy/projection without solid form. For all we know they live in an entirely simulated reality.

You mention one good reason to use the Jr size, and one that leaves it undecided. No other argument is made based on any other constraints other than 'relative diameter'. What 'we are used to doing' has no bearing on the single constraint of 'keep it close to the relative diameter'. If there are no other constraints, it sounds like you should go with the Jr for standard ports, and maybe the standard port for common berthing to visually distinguish the two. You still keep the issue of 'weird' sizes, either way. Directly comparing to RW craft, It will look oversized if you go Sr/Standard, and with Standard/Jr it will look impossible for kerbals to transit. Your choice as to which of those matters most to you when building replicas. That's why I said that this is one of those things that you really need to not overthink too much. Pick what matters most to you, add an explanation of your choice in the craft description if need be for your own peace of mind, then stick to it for consistency between craft in the same save.

I feel I stand corrected - a bit of further research showed me that it's actually a minority of available games, even to this date, and I just happen to have high number of games that do implement GPU for PhysX (explaining why I had an incorrect impression about its ubiquity). I seem to remember rather vividly that at introduction of the PhysX library, the whole premise was to offload these calculations to the GPU, because they had such a hefty cost on the CPU. Why this turned out to get ignored by so many game developers baffles me. But I digress. Please ignore my mumbling and return to the thread at hand.

To Orbit and Back Again - A Kerbal's Tail. (in 10 parts or less) More pics: https://imgur.com/a/VAaofEo My first impulse was to do a search on KerbalX for undoubtedly multiple craft already having done this years ago, but to my surprise I couldn't find any - a combination of the 1.25m limit and my low search-fu skills, I suspect. Either that or people felt it didn't merit uploading. So I slapped something together myself, of which the first version worked the very first launch, except I staged the chute too late and crashed - a silly and easily corrected mistake leading to a fully successful run the second launch. Three stages, of which two burn up in the atmosphere, so definitely not an SSTO (by any definition). Launches only 5 degrees off pure vertical (just to simplify the gravity turn), so almost certainly a roket. All parts 1.25m or smaller - which is how I interpreted your 'only use 1.25m part'. Let me know if it filled your requirements.

Inserting a personal and completely subjective opinion here: I abhor all these 'realism' effects that have nothing to do with how human vision really works. People get hung up on all kinds of effects that basically only demonstrate our shortcomings in replicating the human eye, and forget that what we've become used to seeing in photos and movies is NOT how we see things in real life. When they do consider it, they then often still forget that our brain has a major correcting impact on how we actually perceive things that goes beyond the purely physical aspect of light pathing and lensing. Our brain cannot do that same kind of correction when those aberrations are forced digitally onto a screen, often amplified 'for effect', which results in what I consider a highly handicapped form of 'vision' which I find neither enjoyable or artful in any way. I build/buy my PCs with high end GPUs, so games tend to enable by default all their GFX trickery including many of the effects you mention in newer games, forcing me to go look for the settings to disable them again with extreme prejudice. I tend to quickly stop playing games that enforce some of these settings without option to disable them. One other that I really dislike and quickly disable when possible: camera shaking or bouncing. TL;DR: I vote these kinds of effects to be wholly optional if implemented at all.

Seeing as PhysX often uses the GPU to do its calculations, it's not that unlikely that the two can affect each other.