swjr-swis

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.

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 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?

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.

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.

Depends on your self-imposed rules and restrictions when building replicas, and even what your personal interpretation is of 'replica'. I would say use whatever works within your personal context, and don't worry about what others might consider 'bad'. The relative scale of humans and their spacecraft is different from kerbals and their spacecraft, so trying to directly compare hatch or docking port diameters between the two is going to be problematic anyway. Gigantic heads with even more ridiculously big helmets to try and fit through a hatch... it's best not to overthink that aspect.

Besides the very common issue @bewing explains and the others he mentions, I see other potential causes. But you haven't shared the craft file, so it's guessing. Are your engine pods and main gear actually attached to the wings, or are they attached to the body and offset to the sides? Wings have very flexible connections by default, and those heavy pods with powerful vectored thrust can cause the wings to independently flex higher and lower, making it veer off course. It's better to attach engines and gear to the body and offset them, so the wing flexibility doesn't affect them. It looks like your CoL is very far aft. As your plane picks up speed and lift increases, it will tend to want to lift its butt before the nose, at which point the main gear have less and less contact with the tarmac - leading to the dreaded wheelbarrowing. Consider designing the plane with a CoM/CoL a bit closer to the body center, or add flaps ahead of the CoM that move the CoL forward during take off. You have placed your main gear in series instead of parallel, and with a good bit of distance between them. Additionally, they are very far aft as well. What this does is create considerable difficulty for the plane to rotate, adding additional stress to the aft gear, which also causes them to 'buckle' slightly in random directions. This too will make the plane veer off. Finally, as you accelerate and get near to take off speeds, aerodynamic forces start to overwhelm gear friction/steering, and it's actually your rudders taking over. But these too look to have very little leverage in your design... if I'm not mistaken, the CoM is quite far aft and very close to them, leaving very little arm to work with. Mk3 parts have quite high drag when even slightly off perfect prograde, so the whole body in front of the CoM probably create strong yaw forces than the rudders, with so little leverage, may not be able to correct sufficiently.

Reading this comment just a day or two ago (can't believe I missed this thread all this time) sparked my curiosity. Then reading the overall and specific category requirements, and noticing most entries seemed rather bulky and very expensive, I thought I'd give this a try. Craft file: https://kerbalx.com/swjr-swis/JumboJet1d Full imgur album: https://imgur.com/a/Fhs4shl On that note, I see that in the meantime this challenge is about to undergo another reboot, with what looks like significantly different rules/requirements. Figures. I'll try and find it again some time before 2021...

Manned, unmanned? Max nr of LES to use? Vertical or horizontal launch? Does the craft have to remain undamaged? Asymmetric thrust is easily solved by placing them in mirror or radial symmetry. After that, without any further restriction, its all going to be about the nr of LES used, which practically means whatever your computer will allow before a Kraken spasm attack.

Well, it sounds like a fun contest. But no, I do not agree to giving a blanket permission like that. Not even for KSP. Y'all have fun.

Something like this? KSP 1.3.1, starting tech only (parts and facilities), 30 parts, under 2.9t, single engine. Pitching up as soon as rotation is possible to gain altitude - goal is around 5 km. Final approach as level as possible to slow down to safe speeds for landing. Jeb is happy to report a safe landing at the island airfield, plane fully intact. Craft file: https://kerbalx.com/swjr-swis/T1-plane-A3b