asmi
-
Posts
1,070 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by asmi
-
-
On 12/21/2023 at 11:38 AM, Vl3d said:
It was not the wobble of the rockets that made KSP special, it was the comedy of spending hours improvising with parts that look like they were found in the trash bin and designing a craft, saying "ok, I'm done, I'll try it like this" and then having it mess up your SAS and you stressing over controlling it on ascent because you built the damn thing too tall.
That was only comedy for the first couple of times, beyond that is was just annoyance. Definitely not miss that crap.
-
On 12/23/2023 at 9:22 AM, Scarecrow71 said:
My big issue here is that it's happening really high up in the atmosphere, and it's happening before anything else overheats. There is also very little warning that it's happening; you look at the craft, it's fine, you look away, it's exploded.
This is actually the way it works in real life. It's all about heat flux, heat shields can only absorb/dissipate so much of it, once it's overpowered, things go south really quickly. Most people think that reentry heating works kind of like frying pan on a stove - it slowly builds up the heat. And it's hard to really blame them, as most people don't really have experience dealing with high heat flux. In reality it's more like aiming a 3000+°C welding torch into the middle of a said pan - the torch provides much higher flux than pan can wick away and dissipate, and as a result you will very quickly have a hole in the middle of the pan. The only unrealistic part of it is that in KSP (both 1 and 2) there is a hard cut-off of the atmosphere, while in reality it's very gradual, if you watch some of RL reentry videos, you will see that windows get charred waaay before they feel any significant G-load.
This whole dynamics is actually pretty accurately modelled by late versions of KSP1 (if my memory serves me well, it was implemented in 1.12 when some of modders were hired by Squad to work on the core game), but it is very non-intuitive to most players so it was heavily toned down in stock variant, but since the actual simulation is still there, it can be made realistic with mods. For KSP2 devs decided that it's too complicated for players (which is true), and so they introduced severly simplified system instead which only looks at the temperature of entire vessel as a single unit by postulating that any temperature gradient which is present in vessel will eventually even itself out. The funny part is that reentry (and atmospheric flight in general) is one of flight regimes when this statement is absolutely FALSE, infact the very reason heatshields work is because such gradient exists and can be maintained on purpose (by keeping the heat away from sensitive parts of a vessel), so it's principally impossible to simulate real-life behavior with such approach. What I suspect they've done is basically manually tuned system parameters such that it would work the way they wanted in some finite number of flight scenarios, but since the model they use is fairly crude, you can't really expect it to function realistically.
But then again, most players have no idea how this works in the real life, so an argument can be made that maybe they made a right call for majority of players. But of course those who bothered to learn it will not be happy with such approach, and wasn't learning things being marketed as one of purposes of this game?
-
3 hours ago, PDCWolf said:
Sorry man, just gotta get out of the forums and look at real people interacting with the product, or rather, refunding it. The refund rate is enormous according to steam reviews, 75% of people inside the refund window refund the game.
Good then, what is your problem? Have you got your refund?
-
Just now, PDCWolf said:
That's clearly not the case. Price sets expectations. You ask for $50, and everyone but 10 people in this forum are gonna expect a $50 dollar game's worth of effort.
Nope, your expectation is your problem and yours only. There are plenty of people who don't have a problem with price. If you do - you walk away and don't buy. Simple as that.
-
8 minutes ago, PDCWolf said:
Price. Sets. Expectations.
Your expectations is your problem, not that of game developer's.
-
17 hours ago, PDCWolf said:
Yeah, and I'm not a noob, I've been here for 10 years, it'd be great to have anything in the game for me, or to at least have the devs come out and say "sorry, nothing for you, this is only for people who missed the bus".
That's always been like that - stock experience is for notice players, veterans have to rely on mods to give them whatever challenge they desire. Because if you flip things around, there will be no veterans as the game will be way too complex for beginners and they will never become veterans. Take a look at the Orbiter - it's so complex that you need to spend a significant number of hours reading docs and guides before you will be able to do anything meaningful. In KSP 1 (it was v 0.17 when I bought the game) it took me about an hour or so to get to the Mun, in Orbiter even after hours upon hours of reading guides about MFDs it still took upward of 20 hrs to achieve an equivalent goal. Very few people have persistence like that, and you can see results in the number of people playing respective games.
-
12 hours ago, Scarecrow71 said:
I generally deploy parachutes at ~600 m/s during descent, and I've never had an issue with them not opening.
Well you should have had. What kind of fabric would endure a super-sonic shockwave upon deployment? Just to remind you - a speed of sound is about 300 m/s on Earth at altitude of 10 km.
----
One criticism for the update I would add is they should've kept a small solid booster in the default unlock instead of a liquid engine + fuel tanks. It would provide a limiter of sorts without actually having any technical limits. And in general I like solid boosters more because they really reward thrust- and ascent profile optimizations, when by creative use of thrust limiters in VAB + flying a correct trajectory you can take those solid booster really far.
-
On 10/24/2023 at 8:06 AM, PDCWolf said:
Yeah, I'll agree a million times the QOL changes are great, but I'll also argue a million times it's not worth anywhere close to $50, and that the point of a sequel is to go deeper than "QOL Changes".
If it's not worth it for you, then don't buy it. What's the problem?
-
1 hour ago, Periple said:
take a temperature reading at these arbitrary coordinates
That's one of the things that annoyed me in KSP1 contracts - those random coordinates have no meaning nor logic behind them, my question has always been "what's so special about those coordinates?" If we ever get those missions again, I hope they would contain objectives which actually make sense in the context of a mission and environment, and won't be stupid stuff like "activate a decoupler on escape trajectory from Kerbol".
-
14 hours ago, chefsbrian said:
If things are royally busted on launch and its a repeat of February, I worry it'd be the last straw for the wider community. Sucks to say this, but its gonna be a sink or swim moment for many.
I've heard the same thing about first patch. And then the second one. And the third one.
The reality is any big update is going to bring bugs. That's just the way it is, so expect a couple of hotfixes until it stabilizes enough for long-ish career plays. And no, it won't be "a sink or swim moment", just like none of previous ones was.
-
5 hours ago, regex said:
What I think could work pretty well would be node-to-node welding of similar size, so a 2.5 -> 2.5 node would weld but a 1.25 -> 2.5 node wouldn't weld. Makes adapters useful, makes a sort of intuitive sense, reduces rigidbodies, doesn't mess with wheels (if they're surface attached)... Naturally this wouldn't apply between decouplers.
Procedural fuel tanks would solve a lot of those issues, as each of those tanks will actually be a single rigid body, with no need for any welding. I know Nate doesn't like procedural parts for some reason, but once I tried them in KSP1 I could never go back to the LEGO stuff.
-
39 minutes ago, Lisias said:
I understand that. On my country we have a legal dispositive called "despersonalização da pessoa jurídica", that I don't have the slightest idea how to translate it to USA's legal system, where the company is… humm… "disincorported"? … and the owners' assets are so accessible to honor the company's debits. It's more commonly used to (surprise!) recoup fiscal debits than to ordinary debits, however.
That is that criminal caveat I mentioned above. Tax evasion/fraud is a criminal offence in most countries, and if director will be convicted, all of what you've said can happen. But it rarely happens in practice for a host of reasons which are offtopic here.
-
1 hour ago, Lisias said:
If a company I own hire a motoboy, and the dude slams on a parked car, I will pay for the damages. I'm responsible for any wrongdoing any employee of mine infringes to third-parties, and since I own the company, my personal assets are on the line if the company can't hold its obligations.
If you own an incorporated company (LLC or Feredal Corporation), then you are not responsible with your personal assets (again with the caveat about crimial nature of your actions or inaction), and this is the same whether your company is a one-man-band or a multi-billion international enterprise. It's the company which will cover damages with it's own assets. That's the whole point of incorporation, it segregates owners' personal assets with that of an incorporated entity, and limits the personal liability. This is what allows startups to exist and try to invent new great things - as you probably know, most of startups fail, but people who organized those do not go to jail nor are they ending up on a hook for the rest of their lifes to repay investors' money. So on balance such setup is good for economy overall, as it allows enterpreneaurs to try risky things hoping to come up with something new, cool and useful, but of course any particular investor does end up losing money, infact VCs lose money all the time, but if they are smart and at least some of their investment do pay off, such payoff easily covers all losses.
In your example, company would either purchase an insurance policy that would cover damage to third parties, or (if it only needs a one-off job) it would hire a contractor who would have his own insurance policy that covers such damage (or he self-insures and in that case pays from his own pocket/that of his employer).1 hour ago, Lisias said:So the shareholders are defenceless, and it's suicidal to invest on public companies on the long run. I, definitively, will avoid them.
That's the way it works. To be fair, management of public companies are financially incentivized to make sure a company does good - their bonuses and stock options depend on company doing good, not to mention bad top managers risk losing their job and becoming unhireable elsewhere as their reputation tend to follow them, so no sane top manager would willfully run the company into the ground.
-
1 hour ago, Lisias said:
The problem I see is that the Board of Directors are not exactly "employees" from each other, but elected officials of the shareholders that , at least in theory, are the bosses. Ergo, they answer to the shareholders, not to themselves. Again, in theory.
Before this plan ever reached the Board, it went through executive office tops who actually prepared it, you know drawing all those PowerPoint presentations with arrows going up into the stratosphere, and all of that. So if this proposal reached the Board, you can be sure that it was approved by all vices, SVPs and other folks from executive office.
1 hour ago, Lisias said:As far as I know (and it's not that much, I admit), the BoD are directly responsible for this huge borkage and are in risk of being sued by the shareholders, to the extend of their personal assets.
No, this is not how it works, none of directors are responsible with their personal assets, they are in the same boat as any other employees - unless a criminal negligence or criminal intent will be proven in a criminal count of law(which is extremely unlikely), the worst can happen to them is that they will be fired without any additional compensation.
I happen to be an onwer and a president of a federal corporation under Canadian feredal law, and even I am not financially responsible for my bad decisions unless someone manages to prove in count of law criminal negligence/intent on my part. I suspect the law in US works the same way it does here in Canada.
-
15 hours ago, Periple said:
In my experience it’s really rare to see dissent in those kinds of meetings.
Very few people have the guts to say "no" to their boss, especially a passionate one (even if for all the wrong reasons), as it can put their career at risk. As the old saying goes, a failed project is a failure for grunts (engineers and regular line workers - you know those who actually get stuff done), but it's "gained experience" for managers. All those vice's are probably seeing themselves in a CEO chair one day.
-
17 hours ago, Kerbart said:
So what do they want per install? $20? I mean if it's like 2 dimes it doesn't really have that much of an impact but I assume they charge a substantial amount to cause such an outrage?
The problem is not the price itself, but the fact that it's outside developers' control, and there is nothing they can do to affect that. Don't like an update a developer made to your favourite game? Write a simple shell script that installs/uninstalls the game 10000 times - and BOOM - developer has become $2000 poorer! Multiply it by a thousand of unhappy users (and no matter the nature of a change, in any large enough userbase somebody isn't going to be happy) - and that turns into $2M down! Numbers of course are made up for illustration, but the point here is that this policy is so susceptible to abuse that I feel like it's been designed to be that way on purpose. Add to that non-transparent "Trust me bro" billing, when Unity will charge devs whatever it "believes" the install count is with no way to prove it and no recourse on the dev's part, and I can totally see why so many devs are very uncomfortable with the change, even if it won't affect them immediately. And even if this change will be walked back and/or watered down, there is still a breach of trust - and remember this is a matter of devs' ability to put bread on their families' tables, so they will take this extremely seriously.
-
51 minutes ago, marce said:
Given that Unity decided they want to retroactively change TOS and charge the developer for every install, does that mean KSP2 will switch engine?
I don't think it's legal to change conditions of a contract retroactively.
-
18 hours ago, Lisias said:
However… My personal experience on modding KSP (and I have some reasonable knowledge since 1.2.2, as I choose to keep backwards compatibility on everything I do), is not soooo kind about the team (or at least, part of them) that took over after HarvesteR departure. There're a lot of huge, huge mistakes and bugs lingering there for almost a decade, and they failed to correct fix them - worst, they created worst bugs and unnecessary collateral effects by naively trying to tackle down some of that bugs. There're a few decisions on the thing that really made me mad over the years.
I'm not complaining about bugs happening - bugs are unavoidable consequences on doing new things. I'm complaining about they not being diagnosed and/or fixed.
I've been modding since 0.19 (I think), and I gotta say, things were way worse back then. The last version I monitored was 1.2 IIRC, and there was a ton of bugfixes specifically along stock-mod interface. For example, one bug I still remember (because it gave me no end of headaches when I was working on a Engine Group Controller mod, which was included into RSS mod - and maybe still is?) was related to engines thrust limiter, the problem was in the stock code, but this bug was not reproducable in stock because of the way engines were configured, and it took a big fight on my part over multiple KSP versions to get this one fixed. Also part g-limits was introduced at my recommendation (intended use case was for solar panels, so that you had to fold them during maneuvers with high enough acceleration). These are just a couple of those I remember from many years ago, but there were much much more.
That is not to take away Harvester's achievements of creating the game, but he made a lot of bad calls towards the end. The deltaV number was just one example, if my memory serves me, he was also against introducing realistic thrust model (engines have higher thrust in vacuum vs in atmosphere, back in a day engines had the same thrust everywhere).
-
1 hour ago, Alexoff said:
It would be great if Harvester was one of those employees
Absolutely NOT in my opinion. He made so many wrong calls, that KSP1 started progressing in a right direction only after he left. if you talk off-record over a beer or two to any of late KSP devs who has seen Harverster's late days in the team, you won't hear many good words about him. That's not to take away his achievement of the very creation of KSP, but at some point things turned for the worse. That just shows once again importance of leaving at just the right time before your star has finally set for good.
-
10 hours ago, Snark said:
which flavor of ice cream is better, vanilla or chocolate. (Chocolate.)
You're wrong, and you're bad (C)
-
23 hours ago, DunaManiac said:
Interesting, out of curiosity, what are some of the reasons why its so difficult for even experienced teams to stay on time? Is it just unpredictability of the code, or other reasons?
Whenever you do something you've never done before, there is an inherent chance of encountering something unexpected, which will throw all your time estimates out the window. And the more "unusual" is your task, the higher is the chance of something going wrong. So by not announcing time IG is managing expectations, or, more specifically, preventing situations when they have to break their own promised timelines due to factors beyond their control. To give you a more easily understood analogy (and please remember that it is but analogy, so don't push it too far), why do you think courier companies like DHL, Fedex et. al. never tell you precise time of delivery? They generally only tell you a day of delivery, maybe a few hours-wide time window if you're lucky, but never exact time. The reason is that there are certain factors which can affect that time, and there is nothing a company can do about them. So it's the same priciple.
Another approach to this is a rolling release schedule, when a release happens every X weeks, hell or high water, but the scope of release changes based on what is actually completed as release code-freeze deadline hits. This usually workes better with larger teams so that even if some functionality is not going to be ready, there is always something to release because a chance that everyone in a team will get stuck at the same time is rather low, and get lower as number of people in that team increases.
23 hours ago, DunaManiac said:Regardless though, for the playerbase who are laypeople and are unaware of the problems game devs deal with, Intercept has burned through all of its good will and really needs it back if they want to bring back their mostly disgruntled playerbase.
I suspect that this is mostly beyond IG's control, except maybe for overhyping the game before release, but this problem is very typical for EA games as players tend to have over-inflated expectations and become disappointed when reality hits them. As for the good will, IG is not a 100 dollars bill to be liked by everyone, so no matter what they do, somebody will be disappointed. That said, I have a suspicion that a majority of KSP players either bought KSP2, played a bit and shelved it until some better times, or delayed a purchase until that better time arrives, but don't feel an urge to go to forums and scream&moan about it until the pigs fly. I myself bought the game on a release day, played a bit, and shelved it. Every time an update hits, I fire it up to check it out, and leave it be. I want some sense of progression, so I don't think I will be playing a lot until science hits, but every now and then I still fire it up and do something I feel like doing at that exact time.
-
15 hours ago, Dakota said:
As the one who has been championing these and produced the new video version, what would make you want to tune in?
I can't speak for Redneck, but since I'm a software developer, I would love to hear technical folks. I know they tend to be camera-shy and not really into talking, but still - I want to learn more about ins and outs of KSP2 from technical standpoint. Creative side - not so much, sorry, since my professional deformation (abstract reasoning) allows me to see the beauty in ugly pictures which demostrate some cool technology at work.
-
10 hours ago, Dakitess said:
Wheehaw, don't you feel that the actual patches already feel like applying dressings* and dressings* on a fragile basis ? It does not feel like logical and legit optimization + bug hunting, to me, but more like patches that address a specific bug while using dirty workaround that might cause some other instability, be they detected or not detected.
(* dressings ? This is what I found for translation, I mean here "bandage", we use this word in French to say that you apply layers and layers of patches on a fragile basis)
This is what a lot of mature products look like in my experience (20+ years of software development of pretty much everything under the Sun from websites and fintech LOB applications to AGV guidance systems and applications for factories' shop floor). It doesn't neccessarily mean that foundation is fragile, but it just happen to not account for certain edge cases that planners/developers/testers didn't think of when they were working on a system. This is where 80/20 rule comes from - it takes a relatively small amount of time ("20%") to implement a system, and then the bulk of work ("80%") goes into ensuring it works over the entire range of cases which it's supposed to work. The first stage ("20%") is usually referred to as "initial development" (or simply" development"), and the second one ("80%") is "stabilization". There is also a rule of diminishing returns - meaning that you tend to get the most gains in the beginning of stabilization stage ("low hanging fruit"), but as it goes on, it takes progressively more effort to achieve the next step.
Armed with this information, you can actually get a rough idea of where on this journey each sub-system is - if you see a lot of bugfixes in certain sub-system, that means it's just entered a stabilization stage (and it's got a long way to go), but if you see developers wrestling with the same issues for a long time - that means this sub-system is closer towards the end of stabilization. So as much as I hate SOI and trajectory bugs, the fact that they are battling with them for a while gives me some confidence that sub-systems involved a rather mature. This is obviously not a certainty as it makes certain presumptions regarding the team (like that people working it have enough qualifications to actually complete it, and there are no non-technical obstacles), but this is the best we have at this point.
I'm personally more concerned about regressions - while they are inevitable every once in a while, they usually indicate deficiencies in a QA process (not neccessarily with actual QA people, but rather the whole flow from documenting bugs to passing this info to QA, to QA actually understanding info that is passed on them, to them executing testing properly, to passing feedback back to developers).
-
1 hour ago, Dakitess said:
I don't know how FAR did work but it seems like it's doing a whole craft envelop pretty good, while keeping the ability to recalculate when something break, when a part is destroyed, etc ?
From my discussions with Ferram, FAR uses voxelization to calculate an airfoil, what I proposed is a more simple model which doesn't account for a lot of aerodynamic effects. That said, it can be extended to do that should they ever decide to - for example they can add a part mask to figure out which part is exposed to airstream so that they can apply forces to it (this gives things like body lift and per-part vessel destruction due to aerodynamic loads) and/or add heating (gives us high-speed/reentry heating). This also "implements" air breaks essentially for free (since their deployments increases an area presented into the airstream, they generate additional drag). Finally coupled with slope calculations based on a depth map this system will also "implement" an actual aerodynamics, meaning not just drag, but also a lift, and allow removing yet another crurch, which is what current lift system is. And knowing slopes + depth you can calculate an airfoil, which leaves a door open for a full-blown FAR-like system with faithfully simulated advanced aerodynamic effects.
As far as performance goes, any more-or-less modern hardware should have no problems rendering a few 10K triangles into a texture, and compute shaders are no longer a serious performance drag like it was a some years ago.
What does your ascent profile look like?
in KSP2 Discussion
Posted · Edited by asmi
With higher TWR you lose a lot for aerodynamic drag, as it's ~v^2 (ignoring Mach effects, which would make situation much worse). You also have higher aerodynamic load on your vehicle (read - you have to pilot it much more carefully as smaller deviation from +VV will be enough for RUD to occur), and higher heating of course. This is why most RL launch vehicles have liftoff TWR of 1.1-1.3.