Loskene
-
Posts
377 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Posts posted by Loskene
-
-
On 9/11/2019 at 3:59 PM, UomoCapra said:
The KSP community has always played a crucial role in the development of the Kerbal Universe, and with the KSP franchise growing, there is an important mission you Kerbonauts can help us with.
It’s about time to update the game’s loading screens and we came to the conclusion that we should let you, the community, submit your illustrations, screenshots, pictures and/or any form of fanart you’d like to see in KSP’s loading screens! A set of finalists will be included in Update 1.8. Cool right?
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.
-
13 hours ago, Snark said:
^ I think this is key.
Bear in mind that most people aren't serious "power users" who really get down into the weeds about the finer details of aerodynamics. What they care about is just "do my airplanes fly". And in stock KSP... well... airplanes fly. I fly stock KSP, and am perfectly happy with it. When I build an airplane that looks to me like it ought to fly, it flies. And flies controllably and predictably for me, so I have fun doing it.
All the other stuff you mention, while no doubt valid technical points, are only going to be of concern to people if they're unhappy with how their airplanes fly. If they're fine with it, then what happens under the hood usually isn't their concern.
It's also worth noting that going with FAR is going to significantly rejigger how airplanes work. A craft designed with KSP stock aero may not fly well if you try to run it with FAR, and vice versa. So, going with FAR means that (for example) if you want to exchange aircraft, it'll need to be just with other FAR users, and if you need help with "why won't this fly" or the like, the pool of people who could help you would just be FAR users. It's a popular mod, but it's still just a small minority of the overall player base, so those factors could be significant. How much a player cares about that, of course, would be another matter-- it would matter a lot to some folks, but to others not as much.
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.
-
1 hour ago, Snark said:
Need to qualify this statement.
The little imperfections will nag at you if you're the kind of person that they would nag, i.e. you care a lot about being very realistic. Not everyone does.
It's perfectly possible to fly lots of planes for years and never be bothered in the slightest by KSP's aero model, i.e. to find it "good enough".
The short answer for someone who's not sure where they stand, like @Fierce Wolf, is this: The stock KSP aero model is fine for most people. Give it a whirl. If flying planes feels fine to you and you're happy with it, you don't need FAR. But if, as Loskene says, little details about the way things fly start to bug you... then you may want to consider FAR.
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.
-
3 hours ago, Aegolius13 said:
I've never really understood the purpose of this restriction. I get not being able to create a new node. But deleting an existing one doesn't really give you an advantage; it's just nice to reduce the clutter.
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.
-
1 hour ago, captinjoehenry said:
Honestly I would prefer it if the game came without life support built in. Or at least there really needs to be an option to disable it. As while it is a neat feature but part of the charm of KSP in my opinion is how simplified it is. Which lets you get away with all sorts of fun and silly things like command chair only spacecraft. And I feel people should be free to use that game play style if they want to instead of needing to add in living space and life support parts.
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.
-
2 hours ago, esmenard said:
If I want to land (and don't care about the landing site), direct reentry. If I want to go in orbit, propulsive braking (I find aerobraking too dangerous in this situations, I have no way to know in what orbit I will end up, and I don't bring a heat shield except on landers). If I want to capture at Jool, Laythe or Tylo gravity assist.
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
-
3 minutes ago, pschlik said:
I'm confident that everything in the trailer can be reconstructed in game.
Otherwise, there is one engine in the trailer I've not seen much talk about. It's this super long thing with all these radiators.
Not quite as beefy of a reaction chamber above the nozzle, but this is the one type of engine I know of that can be so long (the longer it gets, the more powerful it becomes!) There is also a similar antimatter variant, but I get the feeling that antimatter won't play a massive role in KSP 2. Regardless, this type of engine would be one of the most high tech planet hoppers you'd get. When it's long enough (like in the trailer) the specific impulse becomes actually insane, but without reducing the fuel flow...which means tons of thrust. Main disadvantage is the size and weight; the version in the trailer dominates half the cruiser, and that's before you even consider room for fuel! This one would really only be practical once you have orbital VABs, which means it's quite late game, but it'd be great once you are at that point.
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.
-
9 hours ago, Kerenatus said:
I got an idea: they could add a stock RSS system as one of those "free-dlcs", and add some new systems as paid dlcs.
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
-
22 minutes ago, Citizen247 said:
This literally has absolutely nothing to do with anything I said.
If course they can. There's no reason the ships velocity has to move the ship within the local space. I'm not talking about how is presented to the user, I'm talking about separating different contexts out to different scenes.
Except for all the floating point precision problems... Plus the issue that KSP has to keep all it's assets in memory all the time and can't stream from disk.
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.
-
11 minutes ago, Citizen247 said:
You make interstellar space a transition where the ship looks like it's thrusting but isn't actually moving. To avoid issues with floating point precision. When enough time has passed the the ship transfers to the other stars SOI. I.e. the different start systems and interplanetary space would be separate scenes rather than sharing the same space.
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.
-
3 minutes ago, GoldForest said:
We saw them launch it on the Mun though. Not on Kerbin.
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.
-
28 minutes ago, Citizen247 said:
Once you leave a system SOI you're in "interplanetary space" where the ship doesn't actually "move", it just sits in blank space until it should reach the new system.
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.
-
4 hours ago, Cavscout74 said:
I had to EVA each kerbal & deploy his or her chute, switch back to the wreck & EVA the next one, while plummeting towards the ocean below. I managed to parachute all 6 into the ocean & recover them all safely.
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.
-
29 minutes ago, JeeF said:
The wobbly joints have always been a major turnoff for me. Rockets are supposed to be rigid.
Sure mods can fix it, but I'm surprised to see this is still a thing in KSP 2. Spaghetti rockets are not cute, fun or realistic.
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.
The Loading Screen Contest!
in 2019
Posted
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.