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.