swjr-swis

Emphasis mine. Bad, bad camera.

Oh really?

Someone is making assumptions here alright, but it might not be who you think it is. It might indeed be. I never claimed it to be an optimal design - in fact I specifically mentioned it not being optimized. Just a craft lifting a full CRG-100 bay of payload to LKO, which is the biggest Mk3 cargo bay we have in stock, without having to spam engines. Let's recall how this exchange went: I said in current stock, an Mk3 payload could be comfortably lifted with the engines available to us. You seemed to take exception with that particular assessment. So I provided proof for my statement by slapping a simple, low part-count plane together that lifts such a payload on just 3 engines, with about the easiest ascent profile I can imagine. In my opinion, that is pretty 'comfortable'. In any case, I'm always up for learning what a really optimized design looks like for such a payload. I promise I won't call you rude if you post a craft file that blows mine out of the water in terms of optimization (for any definition of 'optimal' of your choice). A big part of what I enjoy out of participating in this forum is learning new design tricks and optimizations. Information exchange is awesome.

I understand losing sight of scales when objects are several orders of magnitude apart IRL, because we simply do not have the means readily available to make easy comparisons. The thing is, KSP is one of those programs that allows us to quickly visualize this. Just for fun and kicks, cheat whatever your biggest craft is into orbit around Gilly. Now start zooming out, and keep going until you make Gilly about as big on screen as your craft. Try to spot your craft. Consider how many of your craft it would take to start even becoming visible, let alone getting near to the size of Gilly. Feel free to keep zooming in and out to get a good idea of the difference in scales. Now think again about the 'challenge' you posted.

First, let me say that this isn't even a question in my mind. All of them, we need all of them, for reasons. So I'm not even going to bother reacting to each one specifically. I do have some comments about this one though: Dude, HUGE opportunity missed by not letting the rocket launch out of the friggin' volcano in the center of that island!! What were you thinking?? As for I'd hate to see what a launch looks like with cluttering. That's a whole lot of fairing material. Back to topic though: 30m parts. Yes. For 1.11 please.

Except Europa. Attempt no landings there.

You're doing something wrong if you need 8-10 engines for an Mk3 cargo spaceplane. 3 jet engines is plenty, and that's without optimizations. Full album: https://imgur.com/a/38iytZO Craft file: https://kerbalx.com/swjr-swis/Mk3-Spaceplane1

Can you show us the exact description of the mission? It's been a while since I've accepted that kind of contract. I suspect that you can fulfill this contract simply by taking a normal trajectory into orbit, and during your regular gravity turn towards Ap, you stage the fairing when passing 53km altitude. Then circularize at Ap to also get the orbit requirement. If it really expects you to be orbital at the same time as being between 53-54km, then you'll have to make sure you have accelerated to orbital speed when you reach that altitude. KSP considers you orbital when Pe is anything over 25km, if I recall correctly - this is when the camera switches from atmospheric to orbital mode. In that case, take a shallow gravity turn, shallower than you would normally take to get to LKO, aiming to circularize when you get to 53-54km. Then either stage the fairing right then if you have time, or simply boost Ap on the opposite side to give yourself more time. The remaining drag at that altitude will slowly drop Ap and a good portion of your orbit back into your target band even if you overshoot. At 53km the atmosphere gets very thin already and you shouldn't have to worry about overheating, but this way you can take your time to stage the fairing at the right moment. That would not give you a stable orbit due to drag, obviously, but I do think for the KSP mission system this is considered orbital and would fulfill the requirements.

They always drop on their head. Kinda like the sandwich on the spread side. And cats on their feet. There's gotta be some correlation I'm missing...

If you're genuinely interested in the subject, you can search the forum. It has been discussed extensively. Starting multiple threads about this just seems like poking the bear.

Minor is a very vague qualifier, subjective to every person's own assigned value to privacy, and only valid if you choose to judge this as its own little thing. Funny analogy you used. Of course we won't worry about a 0.1% price change for one single product. Who would ever be silly enough to complain about that. How about when they don't do it just to your mortgage (KSP), but also your account fees (GTA), overdraft fees (etc), transaction fees (etc), insurance (etc*)? How about if it's not just your bank (TT), but your utilities(EA) too, and your grocery store (Ubi), and your computer store (Steam)? And if they're all doing it already, why would it be objectionable to everyone else doing it too? (*: I don't know all the games they own, there's a lot though). Now, since we've already established it would be silly to object to 0.1% price hikes, surely tomorrow you won't object to us adding an additional 0.1% price hike (which btw, our EULA tells you is completely within our rights to do so). No, that's not 0.2% <laughs>... it's two minor unobjectionable completely unrelated 0.1% hikes. See how you misinterpreted that? So silly. Money is not a good comparison though, cause we all make so much of it that cents on a dollar are truly insignificant, and with inflation being a systematic requirement of economy, 0.1% is actually scary low. Privacy is about data. Information. And in case you didn't notice, data is big money these days. Even the insignificant kind. Because it is aggregated. So let's compare to pixels instead, a form of data. A single pixel is nothing, right? What harmful information could ever be gleaned from one pixel. Surely we can all agree on that. Worrying about one tiny pixel, pff. So how about ten people gathering 'single pixels'? That has to be ten times nothing, so still nothing, if I recall my math correctly. How about 10000 of them? How about 1920 by 1080 people, gathering one single pixel each? How about that many, 25 times a second? We're still not worried, yes? The math still has to be valid regardless of the scale or frequency. I'm sure each person can individually -and quite demonstrably true- argue that their 'minor' piece of data cannot possibly show anything even remotely objectionable. So clearly anyone objecting to the minor, routine practice of pixel gathering by this one specific person has to be overreacting. As for 'routine': it's only routine because we have tacitly permitted it to become so. As consumers, we'd rather have our product or convenience than stick to our principles, to the point of ridiculing those who would advocate for privacy. It's of course all anonymized and aggregated (!) and several other words we throw around to make it all sound less invasive, but meanwhile it has spread to almost every facet of our lives, one 'minor routine' step at a time, to the point that the main 'defense' used against people lobbying for more privacy is that it's 'already everywhere anyway'. Yes indeed it is, and I wonder how it came to be that way. No irony in pointing out the fallacy of explaining the 'slippery slope' of allowing even 'minor' monitoring of course. What could we ever be worried about. Silly people and their hypothetical overreaching scenarios. Anyway, I responded to the OP, I really really don't wish to get into this whole discussion again (he said, after a wall of text).

As you can see, the term 'spyware' is a bit loaded and there are varying opinions on this subject. I would say that the statement 'KSP is spyware' is wrong on a pragmatic level. It's a game, but some of the code it runs does call home and send data about your usage and your computer, with the option to do more. The Redshell component was indeed removed. So if that one specifically triggered your question, you can be happy about that. End of discussion. Unity telemetry was not removed, however. In fact, in KSP versions after 1.4 its monitoring capabilities were considerably extended, and stopping it from working by manual actions was made much more difficult. Whereas in the older versions it was easy enough to simply delete the telemetry DLLs to stop it from running, in later versions this would completely prevent the game from even starting. You are offered the option to 'opt out', but this is implemented in a way that still requires the Unity telemetry code to load and call home every time anyway ("To check if you chose to opt out! How else could we possibly know if we're allowed to look or not?"). Both Unity and KSP's current IP owner have stated to only use telemetry in good faith. Both their EULA reserve extensive rights to do considerably more. The latest EULA you're 'bound' to if you play KSP explicitly reserves the right to change their rules as they please, and your rights are limited to stopping playing the game if you disagree. You can use hosts files, DNS, or firewall workarounds to block the telemetry ports and IP numbers, but nothing says they can't add to or change them in future updates (and they already have at least once). There's a few forum posts around that offer a list of ports and IPs to block. So, 'spyware'? No. Good faith? Make up your own mind about it. If you want to be principled about these things, you may have to live with some inconveniences, including potentially not using stuff at all. for now, that's the status quo. Which is only a 'fallacy' as long as it's not already happened before.

Whether or not the built-in functionality was being used is irrelevant, it was about the potential, and the way it was added silently and only even acknowledged after people raised a stink about it. Redshell could do a lot more than what they 'sold' it for, plus the forced EULA reserved the rights to extend things well beyond that. You get a call to bring in your glasses for a free upgrade/adjustment. You find out when you get them back that it now includes telemetry electronics that monitor/register everything you look at, what you do, and all your bodily parameters while you're wearing them. You're told when asking that they will really only monitor a few things, for anonymous purposes that will improve your experience in using the glasses (how?). The EULA you had to sign to even get the glasses back says they have the freedom to monitor everything, share it with anyone they like, into infinity, and you basically can't do anything about it. Oh and btw, we can change this EULA however we want in the future. But we're good guys, so we're cool. You would still shrug and go ahead with it? I mean, they did promise not to do anything nefarious, and right now, it doesn't seem to be sending anything objectionable. Silly tinfoil hat types and their conspiracy theories... right?

If running KSP well is important enough to you to drop the Macbook requirement, I would recommend looking for a non-Apple product. What you save on the brand can be spent on better specifications. Watch also for the trap called 'gaming laptop'. Just naming it that way tends to add several $100 to the price of a laptop, for what often amounts to just some visual enhancements instead of actual performance (special case with 'beefy' appearance, glowing logos, etc). If you're ok with a more run of the mill duller look, you can often find the same specs in a regular laptop for considerably less money, or better specs for a similar price than a 'gaming' version. Specs-wise, at least make sure there's a discrete graphics card in the laptop. KSP is not the type of game that taxes graphics much, but letting a dedicated chip handle the graphics still gives the main CPU some extra margin to deal with the intensive calculations that KSP does use, and some of the physics code can even be offloaded to it. Look for the mention of either NVIDIA or AMD graphics chip - with their current performance levels, almost any of them will do for KSP. As for the main CPU, Intel pretty much wins at the moment performance-wise, while AMD is cheaper. An i7 of almost any current type will offer a good base, but your budget is somewhat limited, so you may need to consider a compromise. A higher end i5 with good clock speed should still perform well with high part loads in KSP. 16GB of ram is a good target, I would not go below that if you can. An SSD can speed up the initial load of KSP considerably, which should only really bother you if you run your game heavily modded. Once within a game session its influence is negligible. So consider the trade off, since SSDs tend to add a good bit to the price. That said, for all other use of the laptop, the SSD will of course also speed up load times. I know this is very generic advice and doesn't really give you a specific recommendation, but if you're willing to let go of specific brand or model requirements and focus on the components, you can get very nice performance out of a 'regular' laptop. With a limited budget, some compromising is probably going to be required, so you'll have to consider what aspects are more important to you.

You listed that one under my name, but I was just testing what your design could do with a few tweaks. It's your craft.

I decided to give that a try. Replaced the payload with two tanks and fully fueled up the plane for a test run in KSP 1.9.1. End result: 777 m/s dV left in LKO.

Hmm. I do like a challenge. You'll regularly find me participating in them in this forum. But you're not allowing a lot of time for challenges that require quite a bit of time investment. I do have an actual job on the side (how scandalous, I know!). Tip: you may see a bit more action on this thread if you a) post challenges that don't require participants to take a vacation from work/school, and b) if you actually show the current challenges on the first post (now it looks like the thread is empty). I'll keep an eye on this thread nonetheless.

Welcome to the forum, and your offer is most welcome as well. Be sure to post your exploits as well. We tend to like pictures, or movies. We're easy that way.

Agreed. We have precisely one jet engine of that size, the Goliath, and it's near to useless for any practical spaceplane design as it's not even meant to go supersonic (somewhat relevant: look at this challenge and see what compromises are being made just to get something -anything- delivered to orbit with a Goliath-powered spaceplane). We are definitely missing a supersonic jet in that size. Looking at stock only though, we don't have much practical use for them: there are no cargo bays beyond the Mk3 ones, and any reasonable (*) Mk3 cargo can be lifted pretty comfortably with the engines we already have. So if we go this route, please also include some bigger cross-section cargo bays. We need to lift Mk3 and size 3 cargo! (*: yes, I do realize this sounds ridiculous coming from me... I don't build all that much 'reasonable' stuff anymore -- did I ever? Not the point.)

Quite easily actually - it only weighs about 8.5t empty, and ends up pretty well balanced, which makes it surprisingly easy to glide in for a smooth landing. I was going as slow as 50 m/s and it was still not stalling. That landing gear may look fragile but it really doesn't need any more. Just don't get nervous when you're almost down, any sudden control inputs can make that low tail hit the runway. Turning the Goliath upside down would allow some clearance to counter that risk, and it would have zero impact on its performance or control - but it would've affected the original concept a bit much.

That general design can do even better, if the goal is just reaching LKO and landing. Under 20 t, 17 parts, single Thud. Allowed the use of a second precooler, both for intake air and for CoM balance. You're right though, it's light enough for the Goliath to easily overheat if you don't climb fast enough. I did use a different control surface layout to improve roll control; made it easier on reentry and landing. I think it can still be improved a bit either way: add some more oxidizer and fuel for extra dV in orbit, or tweak the ascent profile to need less for barely making it, and lower its starting weight.

This one was actually my first concept for this challenge, but it took me a good bit longer to optimize as I had my goal set on a payload that realistically exceeded the operational limits of this craft. I'm stubborn though, so here it finally is: The Thuliath Ib "Goose". Specifications: Powered by one Goliath and four Thuds. Mk3 fuselage mid section, including two fuel tanks and a cargo bay. Single seat cabin. 37 parts, 21378 kg dry weight, 34315 funds. 49908 kg, 36906 funds fueled for this run. 54878 kg including payload. Operational limit of 4.5 t of payload to LKO and return (this run uses a 4.97 t payload). Exceeding operational payload limit is not recommended - margins are razor thin, and the ascent corridor allowing transition into supersonic is just decimals of a degree wide. With the proper ascent profile, moves into supersonic on a single Goliath alone, even at 55 t. Thuds are not engaged until 6km up and Mach 1.6+. CoM is balanced almost dead center on the cargo bay. The forward C7 adapter can be fueled for overweight payloads, which will shift the CoM forward; this does not compromise flight performance, and as it's prioritized to burn first, CoM quickly returns to its proper place. She can hold radial out on reentry down to about 40km, but take care to drop the nose close to prograde beyond that as there is a chance of getting into an uncontrolled tumble. Fueled weight minus payload = 49908 kg. Payload delivered: 4970 kg. Fuel used: (3110+3190) - (19.72+0) = 6280.28 units. Efficiency: 4970 / 6280.28 = 791 grams per unit. Still stock 1.3.1, still no dV read out. Enough to drop Pe from 77km to 59km. Pics or it didn't happen: Full album: https://imgur.com/a/nPVZBel Craft file: https://kerbalx.com/swjr-swis/Thuliath-Ib-Goose

http://kerbalx.com/?search=-dlc ~stock -dlc ~spaceplane ~include ~by:created_at ~all_time http://kerbalx.com/?search=-dlc ssto ~stock -dlc ~include ~by:created_at ~all_time

I did. The static intake of the two precoolers falls just a bit short of what the Goliath needs at stand-still. The two intakes are almost as good a drag end as the nose cones, plus they give some extra powerful static intake for the start of the roll. Once at speed they do nothing anymore, but by then the precoolers are delivering all the air the Goliath needs.

Create, fly, and land. Check. No command chair: crewed Mk1 cockpit. Both engines used: 1x Goliath, 2x Thud. Full album: https://imgur.com/a/K6oCzA3 Craft file: https://kerbalx.com/swjr-swis/Thuliath-Vc2 29407 kg fueled, minus payload. The 'or' in this phrase implies it's optional which one to use for the calculation, in which case I pick LF (1568 of 2280 units tank space used). 1129 kg relay satellite payload lifted to space. 1129/1568=0.72 kg/u. Hmm, I can't see this on KSP 1.3.1 stock. Enough to return to KSC and land. Just under 31 units of O plus some excess LF.