AVaughan

I'll pass. No loot crates for me. Edit: I really don't think they will ever add loot crates to KSP. I can't see loot crates helping Squad/TT sell new copies of KSP, and unless they contained something like random planets to add to games, I can't see people buying loot crates. So I don't see Squad and TT spending time and money to develop them.

Think of ISP as the engines efficiency in converting fuel to thrust. The higher the ISP the more efficiently the engine uses the fuel.

@Zosma Procyon You seem to have posted in multiple threads. I assume you saw JPLRepo's reply in the other thread?

Well even when devs read every suggestion, there will be many suggestions they don't agree with, and attempting to respond to every suggestion with a rational reason why they don't agree would be a huge time sink. (Not to mention that it would probably lead to even more flame wars about devs not listening to their users. Far too many people seem to confuse devs not agreeing with them, or devs having a different vision of the game, with devs not listening to them).

I think that is Kopernicus. And kopernicus is normally tied to the exact version of ksp it was built against. According to the forum thread the latest version is for ksp1.4.2.

It will probably take a few months (or maybe longer) before RO works in 1.4.

Well there are a couple of Jool "landing" videos on Youtube. Bradley Whistance "The Odyssey by Bill; Book 22: "Landing" on Jool and returning" (Returning from below the zero altitude). Matthew Karr "KSP: A Manned "Surface" Return from Jool". (Returning from about 2450 metres).

See https://github.com/KSP-RO/RP-0/wiki/Science .

Gravity is the same as earth 9.8 m/s^2

Someone else posted a comment about deployable solar panel break when using the cargo ramp a few days ago. (Unfortunately I can't find that post atm). Hopefully this will be fixed for 1.4.3

A Youtuber I sometime watch had his entire channel removed a while ago due to being flagged for spam. He appealed and it was back up the next day. So it is possible it is something like that.

@steve_v I run debian as well, but not as my primary desktop, and not normally for gaming. I managed to link to the wrong post on the Unity forums above. (I'll edit my post above to fix that in a few minutes). I meant to link to https://forum.unity.com/threads/no-joystick-detected.475870/ . In particular read posts #7, 8, 9 and 10 including the bit about and

You should really try the dev version of rp-0 . It adds things like sounding rocket contracts. See the 1.3.1 section of https://github.com/KSP-RO/RP-0/wiki/Setting-up-for-Development-Install-:Temp-Page:

You need to calm down. You need to get a sense of perspective. You post is arrogant, rude and toxic. Posts like that drive developers away from the forums because they make reading the forums an emotionally draining and unpleasant experience. First lets cover your expectations line by line. "Regressions this obvious are dealt with swiftly, or ideally, caught long before release." If a bug only happens on some systems, then the bug is only "obvious" if you have one of the affected systems. Since GeneCash reports his joystick is working on linux it is quite possible that joysticks work on whatever systems Squad uses to test the linux version, which means that there is no reason for this regression to be "obvious" to them. (This would also make it harder to diagnose and fix the bug if they can't reproduce it). "Two patches (one of which made other problems worse) do not go by without any kind of update on basic functionality being restored on one of the supported platforms". Basic functionality is build, launch and fly rockets, planes and rovers. Also core ancillary functions like load and save, and the science and mission systems. Joystick is more optional functionality, since you can play the game without it. Yes it's supported functionality, and yes it should be fixed. (And yes I can see how for some people joystick support might be central to their ksp gameplay experience, but many people play ksp without having a joystick, so in the greater scheme of things it isn't core functionality). It would be nice if the developers communicated more on the bug forums, but given how toxic certain members of the community are, I can see why they they don't. (I do agree that 1.4.2 seems to have been rushed out without adequate testing). "Restoring said basic functionality takes higher priority for a patch than introducing additional content." I've already covered my opinion about the basic functionality bit. You seem to imply that this is a case of do A or B. It's not. We don't know who created the extra missions we are getting with 1.4.3, but I see nothing to suggest that they were created by someone who would be otherwise have been working on a linux specific bug. (It's also possible that Squad have already decided it's not a bug in their code, and have forwarded the bug upstream to Unity and are waiting for a fix from them). Personally I think that the root of the bug might be a client-side configuration issue exposed by the change from Unity 5.04 to Unity 2017.1. Amongst other changes Unity changed from using the legacy joystick API to using SDL2 and the modern evdev API. See https://wiki.archlinux.org/index.php/Gamepad#evdev_API for instructions on testing if your joystick is working with evdev and SDL2. For some possible configuration issues and fixes see https://forum.unity.com/threads/no-joystick-detected.475870/ and https://discourse.libsdl.org/t/sdl2-requires-root-privileges-to-use-joysticks-in-linux/20181 . Both of those problems might result in joysticks working in 1.3, but not working in 1.4.

I've had several installs of R0/RP-0 with KER, and don't recall any noticing issues. (I prefer KER's readouts to mechjeb's).

I don't have a source, but those are my impressions from looking at the decisions the designers made. I think the intention is for players to have fun whilst trying and failing (and sometimes succeeding). (Think about games like platformers. I hate them, but for people who do enjoy them they would probably be no fun if you never missed a jump and always waltzed through a level on the first attempt). Just consider things like Mun landings in stock. How much easier would they be in stock if you had a nice display with height above ground, time to impact, and how many seconds you need for your deceleration burn. If the game designers wanted us to stick our Mun landings the first time, then readouts with that sort of information would be part of stock. Instead we get an altitude readout, and a descent rate that is just barely useful, and stock players rely mostly on just eyeballing things, perhaps adding lights to their landers to help gauge height above ground. Edited to add: Also look at the crashed on the Mun main menu screen, the humour in the loading screen messages, and in the mission and part descriptions. This is not a game that takes itself too seriously. It's a fun game about spaceflight where things are expected to go wrong on a regular basis.

All I can say is if you can't do a Kerbin -> Mun and a Kerbin to Minmus -> transfer without mods, then you are overly reliant on mods. Manually plotting a Kerbin to Moho/Eve/Duna/Jool is only a bit harder, once you know what you are doing. (Mods like transfer window planner and kerbal alarm clock are very useful to warn you when the transfer window is getting close, but are absolutely not required). Similarly a tool to calculate deltaV isn't required to build a craft capable of such a mission. (You don't even need a dV map, nor do you even need to understand the concept of dV). What is required is a willingness to experiment and test things. If you are willing to say "I think this ship will do, let's try", you can absolutely play without even understanding what dV is. Looking at a lot of decisions the game designers made, (the comic way kerbals ragdoll from even minor collisions when using their jetpack to board craft on Mun/Minmus) that seems like the way the designers intended KSP to be played. The weak joints between tanks, the lack of things like dV in the VAB, and no radar altimeter outside the internal capsule view are all consistent with that desire to produce comedic fails. Unfortunately not everyone enjoys failing (I know I don't). But for us there are mods that add stronger joints, dV readouts, height above ground readouts etc. But do not confuse a design which is trying to encourage people to have spectacular and/or comedic fails as meaning KSP is incomplete.

Well if the developers added a dV display, they could always label it "estimated vacuum dV". That at least implies that there might be some approximations. (And neatly sidesteps the in atmosphere approximations, where vacuum numbers for dV are normally "good enough". As @blakemw mentioned, I find sea level TWR to be a much more important stat than sea level dV). For maximum usefulness a stock dV display needs to be a per stage listing (like KER and mechJeb), rather than a just single number for the entire rocket.

It can't, for the reasons I mentioned a few posts ago. Another situation it can't properly calculate is an Apollo style mission, where it can't know when the lander will be detached, and hence when the service module will stop having to push that extra weight.

You might have an R7 style booster, without fuel lines but with the decouplers setup with crossfeed enabled, and fuel priority set to drain the radial boosters first. KER has no way of knowing when you will detach those radial boosters. (You might be planning to use them until you are sure the core will have enough TWR without them, by which time the core might be half empty). You might also have an LES. Again KER has no way of knowing when you will ditch it as no longer necessary. The best any deltaV system can do is make assumptions and display numbers based on that assumption.

Still shows as available for me.

Ah I wasn't aware that pressure cutoff affected the pitch to horizontal. I thought it was for fairing deployment. But I have pressure cutoff set lower than default as well. For RO, these days I highly recommend Mechjeb for launches. The dev version has an implementation of Programmed Explicit Guidance that can put a suitable rocket into a nice circular orbit without needing throttle control, or coast to AP or engine relights. I haven't tried that in stock or x3.2 yet. (Maybe I'll play another x3.2 campaign once 1.4.1 is stable and mods have updated).

But since the Principia mod brings n-body orbital mechanics to KSP, then they should exist (assuming Principia is installed of course) .

As I understand GT, it isn't hard-coded. Once your vertical speed reaches "Start m/s", GT pitches over by the amount specified in "Turn Angle". It then tries to follow prograde, and maintain its desired time to apoapsis. If time to Ap is rising too much GT will throttle down, if it is dropping, then GT will pitch up. If Gt is pitching up too much, then that stage probably wants more TWR. Alternatively you can start the launch with a high sensitivity to prevent GT throttling down, and let time to AP grow above 50, let the next stage burn some of its fuel, and then gradually drop sensitivity to bring time to AP back down. I normally use a start ms of around 80, and a turn amount of 8. I often have a low TWR of around 1 to 1.2 on the second stage, and often launch with sensitivity at 0.9. If you are getting flat too early or too low, you want to start the turn later and/or turn less. Note that GT follows KSPs internal prograde calculations, so when the navball auto-switches between surface and orbit, the rocket's prograde marker pitches down, and required TWR to maintain time to AP grows. Also make sure that any SRBs burn a decent amount of time, and you have a decent TRW at SRB burnout.

You really should give mod authors a week or more to update their mods for 1.4. Some might work, but you shouldn't be surprised that some mods will need an update to be compatible with 1.4. This is goes doubly for mods that actually need to hook into ksp code, like kerbal alarm clock.