hatterson

February 13

16 hours ago, Superfluous J said:

Doing a fairly restricted version of Kerpollo, I've found just how little Science there is in Kerbin's SOI, especially when you do no missions and restrict yourself to a single region on both Mun and Minmus.

I was able to unlock all of Tier 1 in the tech tree, but in Tier 2 (after that first entry node) I could only unlock 1 of the first 4 nodes. It wasn't a hard choice, luckily. Fuel Lines are more important than everything else in that tier, even accounting for the fact that the node costs more and only has them in it.

But it's funny that I can't unlock a 2nd science instrument with the points I got from my first 3 missions (LKO, Mun, Minmus) so must avoid Duna on my first interplanetary launch (because with an atmosphere, I want to be able to do the atmospheric science before I go).

You're surprised how little science there is when you intentionally limit the science you're collecting?

February 11

On 2/9/2024 at 4:34 PM, Scarecrow71 said:

EDIT: So, can't do Wheelin' and Dealin' because, apparently, airplane landing gear does not count as wheels. Even though they have wheels on them. Sigh.

Yea, the wording on that mission isn't great. I spent several minutes figuring out what I was doing wrong and seeing if I could pin down the "bug" before realizing I was just using the wrong parts.

February 5

1 hour ago, Biggen said:

I'm working on this mission now. Using f8 cheat menu to teleport me to Tylo so I can test lander design. It's a PITA for sure but fun as well.

I can already tell this is a two craft mission. One to push the lander there and then another craft to rendezvous and pick them up to return them to Kerbin.

Yea that was my original plan. Send one craft with the dV required to get to Jool/Tylo, land on Tylo with some precision, and return to LTO. Then another craft with the dV to get to Jool/Tyle, some extra dV to maneuver around LTO and rendezvous, and then the dV to return to Kerbin.

February 5

Just now, Oak7603 said:

Yeah 430+ m/s into the Tylo surface will do it. It took me forever to do that mission.

I sent two separate rescue missions.

My primary mission didn't have enough TWR to safely land so it stayed in orbit.

My first rescue mission used far more fuel than I was expecting to land so stranded him on the surface.

My second rescue mission actually got him back to orbit and then I hand plenty of fuel between the three return crafts that I had now in Tylo orbit to easily get home.

February 2

Through my testing I found that the Thrust Limiter is double applying.

If you set it at 50% instead of taking 198 kN and going to ~99 it instead halves it *again* resulting in ~49.5

If you set it at 80% instead of going to ~158 it multiplies it by .8 again and results in ~126kN.

This affects all of the SRBs that are used as engines (Thumper, Hammer, Flea, Kickback, and Clydesdale). It does not appear to affect throttleable engines nor does it affect the Sepratron or the launch escape Bottle Rocket.

To reproduce an example you can follow these simple steps:

Create vessel consisting of a Tin Can mounted on top of a Hammer SRB
In VAB set Hammer thrust limiter to 25%
Launch vessel.
Right click on Hammer to pull it up in parts manager and click activate
Notice that thrust peaks at ~12.4kN as opposed to the expected 49.6kN

February 2

13 hours ago, ArmchairGravy said:

I've not noticed it on other engines, but I'm not deep into the tree on this save yet.

Hide contents

Hide contents

Figured it out! Yay bug fixing progress!

It appears that when you throttle limit SRBs the in flight thrust gets double throttled.

Per specs the Hammer should create 197.9 kN of thrust at 1atm. If you launch from the launchpad at 100% thrust, this is reported at 198.44 (close enough since you're a few meters above sea level on the pad). If you launch at 49% thrust limiter (as you have) you'd expect 99.22 kN of thrust in flight. However it looks like that 49% is being applied twice so instead of 198.44 * .49 = 99.22 it is 198.44 * .49 * .49 = 47.645 kN. Reported in flight thrust for me shows as 47.65kN. That means that instead of the expected (and reported in VAB) TWR of 1.65 you end up with a real TWR of only ~.81 which is why you have to burn a bunch of the fuel before it finally takes off.

Clydesdale is 2948.9 kN of thrust at 100%. If I launch it at 75% thrust I should get ~2211 if it's accurate, but with the double throttle I'm expecting ~1658. If I go at 25% throttle I should get ~737 but actually expect to get 184 with the doubling. I typed that up for the Clydesdale without testing to show that it works. Testing now....and verified I get the double throttled numbers.

This does *not* appear to affect throttleable engines (at least the few I tried, didn't do an exhaustive test). If you set those at 50% in the VAB and then launch it has the slider at 50% in flight and the correct 50% thrust is shown. It also doesn't appear to affect sepratrons or the launch escape motor.

I'll write up a bug report now.

Edit: I see you alreadh had the bug report, will add this info to it.

February 1

2 minutes ago, Fizzlebop Smith said:

Precision of Language Jonas!

I love when someone succinctly sums something up so well. I hate the font too... but meh.

Give me an exploration mode with better progression for playstyle.

If one player wants to spend 2 years dinking around the local SOI to *explore* the system in KSP1 was better equipped to facilitate this

It another player with the exact same install could push for that Tier 1 mega collector of science and try to rush the outer most reaches of the cosmos... and the mission system of KSP1 would continue to generate "newish missions.

(So far and beyond that with the contract packs)

Yes a good deal of these were repetitive and endless launch cycles are ALWAYS boring AF....

BUT

Even vague and poorly worded vaguely generalized directions can lead to wonderful new journeys of discovery.

A mission to place Space Station in a SOI you only briefly visited before?

Let's collect science from the Poles of Duna...

Yes you may have collected science from 10 other poles.. but to ME having the selection of general / repetitive / redundant contracts allowed me tp feel like I was actually managing a space agency.

What I have now is a glorious new overlay for sandbox with a few nice introductory missions.

To sh%& with the spirit of the original career mode. I truly think science & career can successfully be combined...

But it requires combining them. I feel the current version is like some Frankenstein fruit tree where the grafts are refusing to take.

You have removed the bulk of what made career what it was & hot glued it to a mostly intact science base

I think a lot of these additional contacts (different places to collect science, polar missions, space stations, etc.) will be introduced with colonies.

Space stations are effectively colonies in space. Polar orbits aren't very valuable when there's nothing to scan, etc. So when those things get added in, then those missions have a purpose.

The missions we have now aren't the final form of exploration mode. They're the initial campaign and a few random side missions, along with the bones of science collection, in order to show the system and get player feedback on it.

February 1

53 minutes ago, magnemoe said:

Fonts are important for many. Its an office life carton in Norway, Dilbert but Norwegian work environment.
Character: "30 minute meeting about the long term strategy and expansion document is too short also its an 2 days workshop about it next week"
Boss: "this meeting is about the content of it and if its the correct direction, the workshop is about spelling error, grammar, fonts and styles"
Character nods.

Fonts are also easy to change. Recommend changing system font to wingding.

Changing the font is trivial. Making sure every single place it's used that all of the UI scaling still works is not.

February 1

Yay I just noticed they fixed one of the bugs I reported. I'm helping!

Shush to you people saying how it's one of the most minor bugs possible. I'm gonna take credit where I can

February 1

Just now, Meecrob said:

Fair enough, I was incorrect in my diction. Rather than use the word "listen" I should have used the phrase "do something about"

Everyone hates the font and they have done nothing about it other than "listen"

I apologize, I should not have assumed that people would have known I meant I wanted to see action.

You originally said "My honest opinion is that votes don't work. The Devs work on things in their own order. " There are multiple examples of that being incorrect. Wobbly rockets being perhaps one of the most significant. They knew about wobbly rockets and, to a point, it was intentional. Then they saw how significant the community feedback about it was and spent time implementing an entire system they hasn't originally planned on implementing because of how loud and how significant the feedback was. I suspect the fact that wobbly rockets also directly impacts gameplay as opposed to only visuals, impacted their prioritization as well.

On the font issue, the dev/decision making team has listened to the feedback and has decided that it is not (yet) at the level where it justifies spending the time it would take to resolve it. It's fine to disagree with that decision, but disagreeing with it doesn't mean that they never listen to or do things about the feedback.

February 1

22 minutes ago, Meecrob said:

We all told them we hate the font. It is still the same. They didn't listen. Its not complicated.

You seem to be confusing listening with doing what you said. They are fundamentally different things. The fact that they have provided multiple comments on the font shows that they do *listen*.

They listened and either disagree with the feedback or believe other things are higher priority (publicly the response has been more about priority, but obviously we don't know what's said/decided behind closed doors). Neither of those responses show that they don't listen to or value feedback, it shows that they don't have to (and shouldn't) just automatically do whatever they are told.

February 1

40 minutes ago, Poppa Wheelie said:

I think it would be very useful to use positive and negative to indicate if your distance to target (at the indicated relative velocity) is increasing or decreasing.

I think that would be better resolved by having a distance to target item with a little up or down arrow for increasing or decreasing, especially since the +/- wouldn't apply to other nav ball modes like surface or orbit.

There also be confusion about what +/- means. If + relative velocity means that you're getting closer then if you're at a standstill and burn away from the target, your relative velocity would decrease, which would feel weird. If - relative velocity means you're getting closer, then if you're approaching and burn retrograde you'd see your relative velocity "increase" (going from say -100 to -50) which could feel weird and I think would increase the likelihood of someone being confused between burning away from a target to kill velocity vs burning retrograde to kill relative velocity.

January 31

Just now, BechMeister said:

In flight of Nova a your prograde, retrograde, normal anti-normal, radial in/out are all visible in space around you. I think that gives you a lot of clairity. You also have a "local" "Anti-local" which shows the relative movement of the target.. but relative speed is, as far as i remember, just always shown in 1 number. Maybe it goes negative.. its been a while since i played it.

I love that system in that game.. but I am not sure I feel it has a home in KSP

Translating the nav bal into a HUD would be a cool system to give additional clarity.

January 31

If by "sign" you mean + or -, then it's not really something they can do since going +26.1 m/s relative to the target has no no real meaning different than going -26.1 m/s relative to the target.

The only way that + and - would be meaningful would be tying them to vessel and/or target orientation, but that is near impossible to properly translate to three dimensions and spinning your ship would lead to wildly oscillating relative velocities which would be very confusing.

I can understand that on a small display seeing the difference between target markers, target relative velocity markers, and maneuver markers can get confusing, but I think the only real option there would be to allow resizing the nav ball independent of the rest of the UI to give you more visual detail

January 31

Has anyone managed to put together a "normal" mission for this that doesn't include using the external seats to ditch mass, has that looks like a mostly normal rocket, and seems like a craft that 10 kerbals could reasonably spend several years in?

Obviously that's even harder without the inflatable heat shield working properly so you don't have the extra surface area, but I'm curious how close someone can get.

January 25

3 hours ago, Aevitas said:

I cried internally.

Context: Laythe ascent vehicle won't stop spinning out of control, and when I gave up on that I tried to design something so I could survive re-entry. It of course, continually flipped over. I think I need to make a fat pancake. A super fat pancake. I've done 4 completely different designs, and they all do the same thing. I'm so lost. What's in the video below isn't even the most recent attempt, but it was the most controllable. """controllable"""

Looks like there's a few things going on:

1.) You limited gimbal control so it had less control authority to correct itself.

2.) The middle top of the rocket looks very flat and is likely producing a ton of drag which causes a lot of torque on the vessel when it's not perfectly in line with atmospheric prograde. You're also accelerating pretty fast low in atmo which exacerbates any drag issues since the atmosphere is still incredibly thick.

3.) You're taking off from exactly on the north pole which causes weird camera shifts as well and further exacerbates the visuals of the situation.

Posted January 23 · January 23

13 hours ago, RocketBlam said:

I'm not sure what an "under-warp failed control input" is

What they (most likely) mean by this is when you're under timewarp but don't realize it (say you're at 2x or 4x or whatever and well out from Kerbin, you can't tell visually), then you go to adjust your craft. Spinning it so it faces the sun, or trying to burn, or whatever, and the game doesn't accept the input since you can't interact with it during on rails time warp. It's not clearly communicated to you why your attempt to control the rocket didn't work and thus you think "this must be a bug, why can't I turn the rocket" Then maybe you switch to another vehicle or save+reload or whatever which sets warp back to 1x and then you can control it again, further reinforcing that it was a bug that got fixed by your actions versus a timewarp issue.

January 21

I’ve seen a similar bug with the dab going down way faster when I used multiple engines on the same tank. Not sure if they were occluding or something.

Do you have a screenshot of the craft? Would be interesting to see if the issue is with the dV calculations on screen (showing too high a number) or if fuel was actually burning too fast.

January 19

Also keep in mind that you don't need to have a ton of extra dV so you can adjust everything to land right on top of it. Either you can savescum to get close or just take time running across the surface on EVA

January 17

2 minutes ago, Periple said:

That’s sad to hear! It’s funny how individual these things seem to be though, I’ve never had issues with chutes nor have I hit the uncontrollable spin bug either. Who knows what’s triggering them!

I've never hit the uncontrollable spin bug, but have seen the chute bug a few times although it's usually only 1 out of a large number that won't open and a save + load has always fixed it.

January 17

On the bright side, if you do have a 3000 m/s lander and a 4000 m/s orbiter you'd be able to do multiple biome hops on Duna, transfer out to Ike, do a few biome hops there, and then head back to Kerbin, so you'd be getting solid science.

January 17

6 minutes ago, Scarecrow71 said:

I built a lander with 3000 dV, which is more than enough to get from LDO to the surface and back to LDO. So no issue there.

I built a transfer stage with 4000 dV, which is more than enough to get from LKO to Duna, capture/orbit, and then have enough fuel to either ferry the lander home OR refuel the lander so it can get home on its own. So no issue there.

The problem is building something to get into LKO from the surface of Kerbin. No matter how many fuel tanks or engines I use, I cannot get enough TWR or dV to get into LKO. I have the mainsail unlocked, and I've got plenty of medium tanks. But I cannot build something to get into orbit. Which is annoying, because I can easily get to Duna and back in KSP1 with these parts.

I am simply not sure what I am doing wrong, and I'm frustrated that the sequel, which is supposed to be designed to be EASIER FOR NEW PLAYERS us so damned hard for someone with >1000 hours in the original.

Option 1: More boosters. Eventually it'll work

Option 2: Send up the lander and the orbiter separate and then dock them in LKO

Option 3: Send them up together but unfueled and then send up refueling launches

Option 4: Send them up separate *and* unfueled and send up refueling launches.

Option 5: Send someone your save file and we can give you design suggestions with the parts you have.

January 16

1 hour ago, Mister Spock said:

Kerbin-rise over the Mun, as my Apollo-style spacecraft prepares to separate the Munar lander from the Command Module.

Separation went fine – except that my VAB engineers cleverly installed a decoupler instead of a stack-separator, so the decoupler remains glued to the command module, obscuring its docking port. HEADS WILL ROLL! I can’t pry the thing off, sigh. This may slightly complicate docking, lol.

Nonetheless, I safely landed Donley Kerman on the Mun, making Kerbal history! Er, we had a little bit of parking trouble, but I later cured this by shoving the lander a few times. I'm also a bit worried that the docking port looks a little crooked, like a drunk's New Year's hat.

One more tiny complication is that Donley has only 308 m/s of delta-V left, probably not enough to make Munar orbit. But the good news is that this moots my multiple docking-port issues. I'll just send the orbiter home, build a better rocket with a bigger lander, and return to rescue Donley. We got this!

If the decoupler is attached to the docking port you should be able to just undock it to free up the port.

January 13

1 hour ago, Mitokandria said:

I know it's already been pointed out, but wanted to add a bit more.

Bug Hunting and professional troubleshooting generally goes:

Reliably reproduce the error/glitch/issue

Systematically remove/modify variables to isolate exact conditions required to produce the error/glitch/issue

Investigate correlation of identified conditions and the error/glitch/issue.

Isolate and systematically modify code to resolve individual conditions.

Test code and attempt to reproduce the error/glitch/issue.

Repeat until error/glitch/issue is no longer reproducible

There may be more steps depending on the exact setup of the development team and design documentation. It's like a massive sudoku puzzle, but the more people you have providing data the more numbers get prefilled.

I'm super excited for the orbital decay fixes! I still sometimes get them, but not nearly as often. Sometimes I'm even able to stop the decay via short rapid bursts of thrust, spinning, and/or timewarping. Also really really really really want to see UI improvements. I do not have large monitors and I have an astigmatism in one eye making it very hard to read any of the UI and it's tiny font depending on which side of the screen it's on.

And the key to this is really that they want to actually fix the issue and not just cover over it.

A mod like community fixes can often include a lot less code and discovery because it can take the "treat the symptom" approach instead of curing the disease. No orbital lines show up because your vehicle still says landing? No worries, just update the vehicle state to be correct. Rover spins out every 1000m? Maybe just reset some anchor every 500m behind the scenes.

Those types of fixes are fine when you're not really worried about long term maintainability, but instead are focused on just making the game play better. But when you're actually trying to properly fix them, as game developers absolutely should at this point of a project, the "what is wrong?" is just the very first step and there's a ton of work to go from knowing what is wrong to knowing why it's wrong and then even more work to go from there to knowing how to fix it without breaking a ton of other things.

January 13

SoIs are a result of a system in which simplifying assumptions are made to reduce calculation load. So they're "fictional" in the sense that they don't exist in the real world, but they're not "fictional" in the sense that they're made up. They're a result of very clear and unambiguous calculations.

None of that changes the fact that in the in-game universe in which Kerbals operate, they would be comparatively trivial to calculate.

Profiles

Forums

Developer Articles

KSP2 Release Notes

Bug Reports

Posts posted by hatterson