Loskene

I'm not participating. Were this handled in a less exploitative manner I might have, since like any other long time player and fan of the game I have plenty of interesting screenshots to contribute, and digital art skills to make them stand out. But that's where the correctness ends, because it's not as simple as that. The problem arises from this not being some cutesy little community forum challenge like any of the others they've posted. This is work which will be put into a commercial product for which people contributing their labour will receive no compensation for their time. Time is money, remember. If you're good at something, never do it for free. This is identical to artists being commissioned for a project and paid with "exposure" (and I hope you're all familiar with how dirty a word that is in artistry/content creation circles) rather than anything they can use to buy food. What makes it both clear and contemptible is that it's framed as a prize-free contest with legal disclaimers/Ts&Cs to avoid any legal culpability for the aforementioned work being performed at cost to the worker without compensation or contract of employment. This might've even slid past were it not coming directly off the back of Chucklefish getting into hot water over abusing (literally, if you look into the allegations) their fanbase to produce content for their games without compensation, taking advantage of their youth, inexperience with labour practices, and love of their games to get away with it. This is why here it's being given the whole legally-binding contest with no actual reward malarkey. What they're doing is not illegal, it is entirely optional, but it is also a blatant act of learning from another company's mistakes in order to produce a PR-friendly method to achieve the same results. Furthermore, where does this leave us if successful? Will there be another "contest" to produce full cinematic trailers for their steam store page? Official gameplay tutorials? Anything else that's difficult to produce in large quantities without paying a team big bucks for it? And what about Squad's in-house artists who would normally do this kind of job, are they still getting paid, are they still employed? I'm not saying this for myself, as said I'm not participating. This is for the rest of you, who should be demanding compensation for however much time you contributed to someone else's workload. Especially without them actually hiring you for the job, which is notorious in our current "gig" economy. How much do you think it would've cost Squad in wages to have an artist produce a couple dozen new loading screen pieces for their game? They certainly know since they started life as a multimedia marketing company. Whatever that sum is, that's at least how much you should collectively be asking for before producing for them. Unfortunately if you've already submitted an entry and agreed to their "contest" terms you've effectively waived your rights to it. Oh well. Live and learn. I hope.

No, it's not cool. How is that a contest? Entrants don't win anything, it's just the company that wins some free labour. If you want more art, pay your artists. If you want lots of art by crowdsourcing submissions, offer an actual prize for winning submissions. Doesn't have to be much, just some token to say you're not overtly exploiting your userbase's "passion" for unpaid work. This is just weak, really, particularly given the effort and quality put into some of these submissions so far. Pay the damn people, you're not exactly strapped for cash and there's no indie dev excuse to fall back on these days. You have literal triple-A publisher money, one of the scabbiest, shadiest publishers known in the industry but money nonetheless. Leveraging the community involvement and creativity this game has come to be known for in such a cynical way (and counting on the inexperience of amateurs to not notice what you're doing) is a real low blow coming from Squad, I'm not impressed. Nor am I looking for an argument over this. Sort it out.

Fair points, but I'd have to disagree with the notion that a plane built for FAR wouldn't work well under stock. They do, and the "rejiggering" required is less significant than you'd think, often none at all depending on the craft in question. They're two different aerodynamic models but they perform the same basic function, making planes fly, just achieved via different methods of varying complexity. Once the centres of lift and mass are in the right place (with the caveat that FAR can be more sensitive to this) the plane will fly just fine in either. The small differences only become apparent under specific flight regimes, like breaking the sound barrier, exact stall speeds and flight ceilings etc. where one model is intended to better reflect reality while the other is tailored for more general gameplay. I think FAR sometimes gets an undeserved bad rap for being "too complicated" or "too different" to get into, especially with all the graphing and "wind tunnel" tools you get in the editor, but after getting over that number fear I found it remarkably straightforward to adjust to. Green numbers = it fly good, and that's good enough for me The pool of users that can assist with FAR issues is anyone who understands common aerodynamic quirks though, since those are usually the stumbling blocks. Not necessarily limited to FAR users, unless something is specifically a FAR-related issue/bug. Also should thank Dafni for reminding me it is not good for boats. I believe Ferram stated he designed it with only aircraft in mind, and so it doesn't model the specific qualities of water like displacement to determine buoyancy. So yeah, not for boats, though floaty parts do make seaplanes a bit easier, if you can get them up to take-off speed again Overall it's surely a try-before-you-buy thing, so it's probably not going to become a stock feature, much as I'd love otherwise, unless it were added as an option. But that depends on how much work is involved in integrating it and whether the devs think it's worth it. I really hope it gets consideration though, since Ferram seems to have stopped developing the KSP1 version, meaning I have no guarantee of any successor for KSP2, if no one with a similar level of experience takes up the mantle.

Yeah might be worth expanding on the little things. Arbitrary/inconsistent drag cubes and part configurations, special handling for lifting bodies that only affects a handful of parts, "cheaty" exploits abusing the simplified calculations like covering engine nodes with clipped nosecones, node vs radial attachment, determining what's shielded from the airflow and what's not, etc. Practically all of these are resolved by using FAR's voxel model, which calculates the aircraft's flight characteristics based on the actual shape of the exposed hull rather than predefined values and hokey abstractions meant to paper over edge cases for the majority of gameplay situations. It resolves problems that make some parts over or under-perform for no good reason, like the dreaded Mk2 spaceplane parts that look great but are unreasonably draggy in stock. If these sound like things that would bother you, then you'll want FAR. As others mentioned it has issues of its own but after having used it for so long they're overall easier to deal with than otherwise unresolvable stock issues that spoil some aspects of the game for me. But then this might all be a "power user" problem so YMMV.

I mean it might have made sense if we had means of pre-programming commands into probe cores, meaning if we lose signal we couldn't tell a probe *not* to complete a manoeuvre. But we don't so... idk

I would guess most people, when they read about what it does, know whether they want the FAR aero model or not. I'd say if anyone's on the fence about it or whether it's relevant with the updated stock aero, that it depends on how much of your playtime is spent in atmosphere. If you mainly launch rockets and spend most of your time in space, the stock aero model is perfectly adequate for your launch and aerobraking needs and you don't need the associated overhead of the mod, nor adjustment time to its own quirks. If you build a lot of planes, however, sooner or later the little imperfections in the stock lift/drag calculations will start to nag at you until you want them to just go and build a voxel-based model into KSP2. I really hope someone brings that up by the way, it seems to have gone largely understated in the fan coverage/dev interactions so far. I hope they haven't forgotten aircraft completely. KSP is a really wonderful flight simulator that walks the line between arcade fun and realism in a way few others achieve.

While stock KSP doesn't have much micro parts coverage, you can make very small rockets with the Procedural Parts mod for tanks, SRBs, structure and nosecones. Plus one of the procedural wings forks or tweakscale for tiny fins and other bits and bobs. Normally use this for custom aircraft missiles but that's basically a model rocket anyway. Or you could just tweakscale an entire stock rocket for a true "model" experience.

Boooo naw I'm just playing I get you dude. I like to think of it as an extra challenge when there's little else to do, since it tests all aspects of your building and planning skills, but for beginners or people just looking to play sandbox there's no point to it, so it should be toggleable and probably off by default. I only ever have USI installed when I'm doing a semi-realism career game. I like that one because it's just supplies, waste, fertiliser, and energy you have to deal with for a complete offworld kerbal ecosystem. There's no point breaking it down into food/water/ox unless you really like clicking ISRU converter menus, they always run out at the same rate because few missions are short enough to survive with a loss of any of them alone. It also has a nice 2 week grace period for short trips without any supplies or emergency rations if you have a problem. I'm well for it is what I'm saying, even as a post-launch update (do not say the d-word) Oh but of course I forgot to mention the thing that makes it actually gamechanging: the habitation mechanic. When you actually need a liveable volume for your kerbals to survive in without going crazy on potentially indefinite voyages, you're forced to build big. It changes how you build every crewed payload and launch vehicle. Some might not like that but it makes mine look more true to life out of necessity rather than aesthetics, so I like it a lot. Example: You know how going to Duna orbit and back can basically be done with a space chair, and a station might as well be a science lab, docking port and solar panel? Well this the bare minimum kind of vessel you need for the hundreds of days worth of supplies you have to bring for keeping kerbals alive that whole time (since I hadn't unlocked growing crops yet): https://youtu.be/no6Rq2BNKJI

I hope there's something simple and effective like USI life support, with all its options for supply requirements and punishment scaling as difficulty settings. It wouldn't be the same without it and the sequel is the perfect time to bake it in to the resource system.

The issue with aerobraking for anything beyond necessity is while you do have ways of knowing what orbit you'll end up in, there's a proportional tradeoff between ease of calculation and accuracy of prediction. The more you want your aerobrake to result in a deltaV vector of specific magnitude for the desired resultant orbit, the more napkin space you need to scribble on and the more babysitting you have to do with your craft's lift/drag vector during a process which may take much longer than a simple rocket burn. The trajectories mod does most of this but is limited by its assumptions and time spent on running the whole computationally expensive simulation. Land "here"? Easy peasy, no maths needed once you brought enough ablator or spend your leftover transfer fuel on the way in. Capture into a specific orbit and circularise? Well you might want to pause the game for a while and make a cup of tea. Then work out your time spent in atmosphere, it's density curve, the precise mass and area of your craft's air facing side, gravity losses, oberth effect, etc etc etc. Hopefully get your apoapsis down low but not too low, then do at least one circularisation burn at apo and probably a second at your next periapsis, because it's really risky to aerocapture into a very low orbit in case you end up spending too long in atmo, in which case you're landing "here" and can throw out your napkin. So yeah I just bring the fuel tank if I'm not planning to capture and land at the same time. At least you can capture and circularise in one burn that way, instead of having it forcibly split into aerocapture/peri lift/circularise one orbit later.

I'll spill the open secret: we only do aerobraking for cool points. We all do braking burns when nobody's looking because calculating aerobrakes so you don't skip out, sink low or blow up is tiresome. Mass ratio to heatshield area and atmospheric density at high altitudes and fbdbhfgh just bring another fuel tank.

I'd also like to remind anyone who's not sure why the epstein drive from the expanse would be interesting to put into KSP, that the general consensus on the real drive's performance (based on what canon observations could be obtained, some assumptions and some confusing maths) would've required a fusion engine so powerful it would've vaporised any ship that tried to use it as depicted. Oh my. http://www.projectrho.com/public_html/rocket/enginelist2.php#epstein

Oh damn, it looks like those chamber modules are stackable too, you could conceivably make one of these as long as your part count will allow.

If they don't include this hidden history holy grail of rocketry unlocked from the first tech node I'm going to be very disappointed.

oh nononono we don't talk about DLC until KSP2 has at least 1000 mods written for it, are we all in agreement? Look how long it took just to find out what KSP was well enough to conceptualise a sequel to it.

They're a bit hokey and I generally build my own payload deployment rigs with an empty aeroshell, but I think you need to use a stack separator on them so nothing stays attached to the node after decoupling, then it might disappear. I don't know, it's black magic at my level of usage. You know you can attach the probe directly to the docking port and use "decouple node" in orbit to detach it though, or another stack separator if you want to be safe, since they decouple on both sides.

ok pal

If it doesn't then you weren't talking about anything relevant to interstellar travel simulation and avoiding FP issues because that's exactly what krakensbane is for, and even that's a bit of a half-measure with less annoying edge cases than other solutions, so it works for 99% of our purposes. The ship doesn't move within local space. Space moves around the ship. How it's presented to the user is just an abstraction of the same numbers used to calculate its position and velocity in the first place, they're not separable like that. What they've most likely done is just take a freeze frame of the Kerbol system (and all your craft in it) and stop calculating/rendering it once you get a certain distance away, then running catchup calculations when you switch back to determine where everything is now. That way you don't get FP issues ruining all your on-rails orbits while you're very far away from them. I'm sure this is mostly wrong too and they have some even more complex mechanism to make interstellar travel viable, but they won't be taking such drastically game-limiting measures like the ones you propose.

That's not how krakensbane works mate, it just makes the active vessel the centre of the universe to avoid FP issues, afaik SoI changes don't have any impact on it. When unfocused the craft is on rails and doesn't really exist, only its orbital parameters, which you can change on the fly to simulate thrust. We have no indication yet whether they've had to change how this works for extremely long range brachistochrone trajectories, but since beyond a certain speed they can be roughly approximated as straight lines, they might not have to. However, assuming they stick to real physics and the sandbox nature of KSP, we should be able to brake halfway between two star systems in order to set up a waystation there (for a laser highway perhaps, or just a void colony for fun). They can't really "compress" or abstract away the distance between these systems without removing the ability to stop a ship once it escapes Kerbol. Given that we have interstellar travel mods in KSP1 already and they work just fine with krakensbane, I don't see what necessitates any changes there.

FAR has tools that basically simulate wind tunnel testing now, by exposing the calculations that it has to do anyway in flight. I hope they bake that into the stock SPH.

And? It'll still blow up your space center if you ground launch it and I don't know why they'd want to arbitrarily restrict that aspect of (extremely Kerbal) gameplay. I mean there were plans to ground launch Orion-powered city ships IRL (as mentioned they work even better in atmo) so I can't imagine Kerbals being more safety-conscious than humans.

What?

We've seen an Orion launch in the gameplay footage. They use boosters to yeet it a few hundred meters above the launchpad before engaging the drive, and they said in the interview it will destroy your infrastructure if you ground launch it, so it's up to you.

Nice. I've yet to have a plane break up with enough altitude to let me bail out all the Kerbals in time, but then I rarely build SSTO spaceplanes. I've taken to making sure all my test flights are done with only a single pilot on board instead. If anyone else sneaks aboard while I'm making edits, on their gargantuan heads be it.

Spaghetti joints seem to have been a half measure between completely rigid body physics and true soft body physics (think beam.ng drive but for balloon tanks). I can't say I think it was a good compromise though, might as well go all or nothing there.