RageMode

Makes sense. Though I'm not really playing with the stock solar system any more. I liked RSS much better but couldn't deal with the stuttering it caused. But since I've found MemGraph and its ability to increase the GC padding, which reduces the stuttering drastically, I'm back on it. Interestingly, I find it much easier to design rockets that fly stable in RO with FAR than stock with FAR. Probably because the engines are balanced better for realistic rocket design in RO.

Some more info on reproducing this. It only seems to happen once. Afterwards, you're able to create a new save game and contracts work as expected without reloading the save. Example: Create a new install. Add mods. Create new career mode game. Contracts are not available as they should be. Exit to main menu and reload the save. Contracts are now available. Exit the game. Start a new career mode game. Contracts should be available as expected.

I'm also pretty certain this mod is the cause of a 1 second or so freeze every 5 seconds or so, which is extremely annoying. At first I thought it was the garbage collection issue, but I've since installed MemGraph and enabled its padding, and that didn't solve the problem. Memgraph also isn't showing anything that would indicate GC is causing the problem. Edit: As it turns out, Mod is the Alt key, not CTRL. And MemGraph's graph needed to be adjusted to show the lag spikes. It is indeed GC, and not this mod.

I'm using Realism Overhaul with Realistic Progression Zero. I'm using the latest version of Contract Configurator (1.16.2), and the latest versions of the other mods. When I start a new career, contracts are shown in the "All" tab, but there are no available contracts in the "Available" tab. If I exit to the main menu and reload the save, the contracts are then available. This has been reported by others in the RP-0 thread as well. But given that Contract Configurator works based on config files, and the contracts work fine after reloading the save, I'm guessing this is a bug more with Contract Configurator than with RP-0.

You're assuming what I'm saying is that you should implement these features. That's not what I'm saying. I'm not saying you should necessarily do anything. I'm just throwing some ideas around. If I want it that bad, the source is available and I know how to use the fork feature.

I can understand. I would imagine if KSP doesn't have any sort of API to work with stages that's beneficial, and I doubt it does, then it would probably be a difficult thing to do. But I know the delta-v is already available information. And at the very least, MechJeb and KER are open source and capable of calculating delta-v per-stage. So the needed source is already available. Combining these two would make it a much more manageable task. Perhaps it would even be possible to use information already provided by MechJeb or KER if they're installed. Unit testing can go a long way to help with edge cases as well. You'll spend a lot of time writing tests for the edge cases, but in the long run it will make the code much more maintainable and much more reliable. And from my brief research, unit testing seems like it's possible with KSP mods.

I'm not a typical user. While I haven't worked on any KSP mods, and have never actually looked at any KSP mod code, I'm a C# programmer myself with a fair amount of programming expertise. I understand your reasons for not wanting to implement it though. It seems like a simple concept, but I don't understand enough about KSP modding to know everything it would require. Perhaps I'll take a look at the github repo at some point and see if I'm able to find a fairly simple way to implement it. I have a significant amount of free time available, and I'm pretty sure stock KSP burn times don't cooperate very well with staging either.

This has to do with the fact BBT doesn't handle staging. In RO, your engines have a limited number of ignitions. This means it's best not to activate the engine until you're ready to use them, because accidentally hitting the throttle up key would ignite the engine, and possibly ruin your mission. A lot of the engines have only a single ignition, so this is a pretty important fail-safe. Especially when you factor in the ability to lock staging temporarily to further prevent the engine from being activated unless explicitly activated. I haven't actually tried your mod with RO, but I'm guessing it isn't able to calculate the burn time for the next stage. Perhaps a simple way to handle this would be to calculate the burn time based on the next stage if the current stage has no active engines or has no fuel. Another simple way to solve this would be to implement some sort of stage selector for the burn time, so that you can choose which stage the burn time calculations would be performed for. Being able to select the stage by number is the best way I can think of to do this, because it provides a fairly clear way to figure out what engines the burn time is being calculated for. I understand that calculating burn times divided between multiple stages would be rather difficult, but these two options should be fairly simple and shouldn't add excessive performance penalties. The second option would be the best one in my opinion, as it allows the most in terms of versatility, and would work with the most ship designs and staging setups (some people put the decoupler and engine activation on a single stage, some divide them between two stages, for example). It would also be useful to have in the stock solar system, and not just RO.

Thanks.

Using the latest versions of both the Rover Pack and Contract Configurator. I'm also using the Unmanned Pack. The Unmanned Pack contracts are showing in the "All" list. However, the Rover Pack contracts aren't showing up. They were prior to the update.

@ferram4 My rocket is symmetrical (I'm OCD about that, even when it doesn't matter). It's a fairly small rocket, 1.25m diameter tanks. I'm using fairings. In this case, it was to launch a small probe. The first stage got me up to about 5km or so. Then upon staging, my rocket would instantly lose its balance and flip over, and aerodynamic stresses would take over and wreck the craft. I also started with a TWR of 1.3 or so. I've played RSS/RO/RP-0 before and know how to properly design a rocket. I follow pretty much the same methods you listed. But for some reason, rockets seem extremely tippy. I've since managed to get some rockets to launch. I've found the method that works best was keeping the first stage long burning (which is hard to do with my current mods and the current progression I'm at). For the record, I'm not currently playing RO/RSS. I had no problems in RO/RSS though, nothing like what I'm experiencing now, and that has FAR, too. Although I understand that's probably because of the largely different atmosphere setup and massive differences in general. I don't doubt that 20Kn of drag isn't big, I mentioned it to make sure though. For comparison, I don't think any of the engines I was using for that particular rocket were over 100Kn of thrust. I think a large chunk of the issue was that I was flying the rockets like I would in RO/RSS, and that particular design got my rocket up to 250m/s or so before 5km of altitude, which I think is too much. I notice a significant difference in flight characteristics when I got the rocket to stay around 100-150m/s under 15-20km. I think it's just a case of significant changes in FAR since the last time I played KSP that made designing rockets a lot more challenging. Last time I played, it tended to make rockets easier to get into orbit, but made planes a lot more challenging than stock. After reading around a bit, it seems the NuFAR update changed things a lot, and now rockets are much harder to get stable.

I've played with FAR pretty much since I started playing KSP back in the 0.23 days. I took a break for a while. Now coming back, using FAR, my rockets seem to be stuck on stupid. The main problem I'm having is that my rockets want to flip retrograde in the upper (~20km) atmosphere for some reason. I'm designing my rockets in a similar way to how I designed them previously. I also noticed the drag when watching the FAR flight data window seems to get up to the 20Kn range pretty quickly. Is this normal? I also notice the side forces are about equal to the drag, even when the rocket is going straight up. The way things are working right now, this is less fun realism, and more of a headache than anything else, making my rockets feel as though I have no control over them unless they have fins until they're completely out of the atmosphere, which adds a design requirement that I'm not too fond of at all. Perhaps it's a bug, or a problem with my current install. I hope that's the case at least. I've tried KSP with only FAR installed and no other mods, to make sure it's not a mod conflict, and the issue is still present. I generally put fins on the bottom stage, and sometimes a smaller fin on upper stages depending on the length of the rocket and the profile. In this case, my rocket is a two stage rocket, and it seems as soon as there aren't any fins left, even in the upper atmosphere, the rocket goes retrograde no matter what I do. Gimballing engines can't counter it like I expect them to. Is anyone able to provide an ideal ascent profile as far as what speeds you should be reaching at what altitude? Also, has anyone managed to launch a rocket without any fins? If FAR is supposed to be realistic, I would imagine this is possible considering the Falcon 9 has no fins, and that's a real rocket.