hatterson

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

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.

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.

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.

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

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.

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.

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

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

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.

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.

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.

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

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

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.

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.

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.

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.

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

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.

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.

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.

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

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.

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.