Gotmachine

Would you be so kind as to provide said KSP.log files and, ideally, links or additional context on the original reports ?

Ok, that's weird. Try to disable the "LostSoundAfterSceneSwitch" KSPCF patch, but I'm a bit skeptical the issue is directly caused by KSPCF. Please provide your KSP.log, that would be a starting point. Can you give a broad estimation of when you had that bug ? The information would at least allow me to clear out that this isn't due to something I did in the few last days KSPCF updates. [snip] Problem preemptively solved !

Coming up with a *stable* and somewhat enjoyable modded KSP install can indeed be quite the challenge. You won't find any "how to guide", because everyone has different desires in term of what combination of mods they want. I'd say that the only controlled, beginner friendly modded ecosystem is RO/RP1. It's by far the most actively maintained, and the team actively work to ensure that the core and supported mods work well together and provide a good user experience. But in the general modding jungle, things can indeed get ugly. My recommendations would be : - Avoid any mod that isn't somewhat actively maintained and explicitly updated for the latest major KSP version (1.12.x), and stick to the widely used "quality" mods. - Don't go overboard with how many mods you try to combine, especially the big mods, and don't try to combine mods that have some overlapping in functionality / purpose - Some "big mods" are doing things in a way that tend to cut them from the general ecosystem. Examples of such mods are Kerbalism or KSPIE. Those are two mods that work relatively well "alone", but have tons of compatibility issues with many other mods. But I share the feeling that the KSP 1 modding scene has somewhat failed to deliver a polished experience, at least on the "going beyond the stock gameplay" side. I'm still profoundly dissatisfied with the modded career mode experience. There are good ideas here and there, but nobody managed to consolidate them in a polished and well integrated way. The best effort is again RP1, but its focus on realism isn't for everyone. Anyway, if you want some personal recommendations : - For the planet pack, either JNSQ (a re-imagination and expansion of the stock system) or KSRSS (1/4 sized real solar system). Both provide great and somewhat up-to-date visuals and the 2.5x scale is a perfect balance for stock-sized parts to get that feeling of "real rockets" instead of "toy rockets". - For additional parts, restock/restock+ and the near future suite (and various other part mods by Nertea). This provide everything you can possible need with minimal overlap, and with great integration, as well as some relatively polished gameplay mechanisms. The only thing that is somewhat missing is surface base parts, which can well covered by Planetside Exploration Technologies - For progression mods, I would always recommend Strategia and the most well known Contract Configurator packs, which while not a game-changer, at least turn the mess that are the stock strategy and contract system in something vaguely coherent. I'm not a fan of the various tech tree mods beyond CTT, I think the whole "get science points to unlock parts" gameplay loop is boring and broken anyway, and alternate tech trees invariably come with tons of compatibility and balance issues. - For life support, ISRU and offworld base building mods, that's where things start to become real messy. There is the USI LS/MKS option, which is somewhat complete and relatively well integrated with the various part mods, but I personally find the thing shallow, cumbersome and frustrating to play with as well as somehwat buggy. Kerbalism has great life support and science progression mechanisms, but its resource and ISRU systems are incomplete, it's reliability system is annoying, its radiation system is quite limiting and it is a bit buggy and has major incompatibilities with other mods. TAC-LS is cumbersome and buggy. For LS, Snacks is... somewhat decent if you want something simple. Offworld rocket building can be covered by EPL, which is... lets say functional. - There are some mods attempting to implement whole new gameplay mechanisms like KCT, ScrapYard or Bureaucracy. I personally find them poorly thought and poorly implemented, and they come with their own caveats in terms of bugs and incompatibilities. - I'm personally staying away from anything "interstellar". That doesn't add much in terms of gameplay and the large distances are causing various bugs. In terms of parts and "technologies" to get there, KSPIE is a hot and buggy mess, and FFT are just overpowered engines that don't really create much additional gameplay considerations.

Well, don't take it wrong, but I don't want to waste time investigating issues that aren't caused by KSPCF in the first place. So do you both confirm that you saw that issue happening when KSP Community Fixes *isn't* installed ? And please provide your KSP.log when reporting an issue. Spike88 : Hard to say what exactly is causing the app launcher issue from your log, as your log is showing errors coming from tons of different stuff, but nothing obviously related to KSPCF.

The video should be made available on the Unity YouTube channel the week of April 3. It will be interesting to see what they have to say, especially since they admitted last week that the terrain system they have put together doesn't work and that they are planning to scrap it.

I'd say that both iterations are equally bad in how they fail to deliver an actually *good* maneuver editing and planning tool. I will see myself out.

KSPCF fixes multiple major bugs in the stock upgrade system. Unfortunately, the whole stock upgrade system has a major design oversight, and long story short, showing upgraded part/module info in the editors part tooltips just isn't possible. I'm not sure if what you two are talking about is this 100% cosmetic change, or if you are actually experiencing an issue where some modded upgraded parts don't work as expected. Could you : - Describe exactly what isn't working as expected when KSPCF is installed ? - Tell me exactly which parts from which mods are involved (there are tons of WBI mods...) - Post your KSP.log file In the meantime, you can disable the specific KSPCF patch involved (UpgradeBugs) by copying the KSPCF_UserSettings.cfg.extra file from the KSPCF "Extras" folder to your GameData folder. Note that if disabling that specific patch doesn't fix your issues, then this is probably caused by another patch. Thanks for the report, will try to take a look.

To manipulate the orbit you likely need to pack the vessel first with Vessel.GoOnRails(). This being said, I noticed in the video that the vessel is in-atmo. I'm not sure what you're trying to achieve, but if you're trying to set the vessel velocity while in atmo, I'm not sure this is actually doable with orbit manipulation. You will likely have to manually teleport the vessel first, then apply a velocity to all the parts. I highly suggest that you check the source of existing mods doing similar things, HyperEdit is the main one coming to mind.

Don't remember and I'm too lazy to check I would suggest doing a github search for "UpdateFromStateVectors", that should give you plenty of examples of how it should be used.

From memory, they are relative to the current body frame, but really not sure. Yes that should work.

You need to manipulate the vessel orbit. Orbit.UpdateFromStateVectors() should be the most straightforward way.

I think marking non-patch releases as experimental/pre-release on github (preventing them to be pushed to ckan) is the best solution. It has been my personal release model for while now, and I think it's the best middle ground. For that release model to work, however, there are a couple rules to follow : - You have to advertise as widely as possible the pre-releases, on the same channels where you advertise for the normal releases, because if nobody uses them, nobody will ever report the eventual issues they have, making the whole release model useless. - They should be clearly advertised as pre-releases, with an emphasis on the changes made and potential issues to look for, with a disclaimer that if users don't intend to check on updates and actively try to troubleshot/report their issues, they should use the stable releases. - Always sleep for a good while on the pre-releases. You say you have a weekly dev cycle, that's perfect. It's enough so whoever is inclined to use them has had the time to do so, find issues, and report them, and not enough for you to have forgotten what you were doing. And maybe that's not something that happen to everybody, but personally, I often have bad-lightbulb moments one day or two after a release where I realize I did something dumb without even looking at the computer. It's still a relatively fast release pace and you won't end up with multiple new/experimental changes at once (which I agree makes troubleshooting more difficult, it's easier to know where an issue is coming from when you have fewer changes). A release model with a separate "bleeding edge" branch / distribution channel just doesn't work. People won't actively check it. The only worthwhile cases are when you're working on big features / changes that : - generate enough interest, sustaining a somewhat active "beta-tester" group that actively provide feedback - are backward-compatibility breaking changes, or just in-progress, unstable features I indeed think your current release model isn't very nice for the users, especially since Kopernicus is a middleware mod. Many people grab whatever current release is available at the moment and never update it. You are viewing changes and issues from your own hyper-aware lens, but most people experiencing bugs won't even know they are coming from Kopernicus, they might not even be aware of what the "Kopernicus" mod they have installed is for, since all they consciously installed is a planet pack. It's also worth noting that Kopernicus went from the most "release locked, extremely risk-adverse, months between updates" mod in the ecosystem to "push not really tested changes every week to mainstream". There is probably a middle-ground. All this being said, I fully acknowledge that modding is a personal act, that it's perfectly reasonable to do things in the way that is the most convenient for you, and that users are entitled to nothing. Do what works best for you.

This isn't really a "type of joint" problem. The different joint types you see in the Unity documentation aren't different implementations, they are just presets of the "configurable joint", which is what KSP actually uses. The issue is not really in the "joint", but it's an intrinsic limitation of the type of solver implemented in PhysX, and the same limitation exists in all other similar physics engines (Havoc, Bullet, etc), and although other engines might be better at mitigating that specific issue, it will still be there. To really get around that issue, there are only two options : Use a solver that doesn't have those issues. For example, PhysX (and Unity since very recently) has an alternative solver based on the Featherstone algorithm, which is specifically designed to have physically accurate joint behavior. Implementation in the context of KSP could pose a few challenges, but that solver have shown impressive results by the the very KSP-like Mars First Logistics Get ride of the whole "1 part = 1 function = 1 structural unit" paradigm. That paradigm is mainly a consequence of the original KSP going for the easiest technical solution available for a wanabee solo game dev 15 years ago. It never really was a conscious or intended decision, and while I agree that it is part of the KSP identity, I think the game scope has evolved in such a way that this "feature" is now largely getting in the way of the game achieving its full potential. Objectively, the 1 part = 1 rigidbody linked by non-rigid joints doesn't lead to a significant or remotely realistic "structural engineering" gameplay, and doesn't even succeed at preventing players from building structurally impossible vehicles, as due to the fundamentally un-physical behavior of the joints, they had to make them virtually indestructible. That paradigm is also responsible in a very large part for the overall jankiness of the game physics, as well as some of its performance issues. If they really wanted to have a "structural engineering" aspect to the game, it could be something like user-configurable connections strength (with a mass penalty to balance it), then have a relatively simple solver that compute cumulated forces/torques applied on each connection, with the connection simply snapping if the forces become greater than the limit. The only thing that bendy joints objectively provide is a visual feedback, which could be replaced by a cool "stress overlay", scary sounds of metal bending and particule effects of things starting to snap. Doing that would add an actually interesting, predictable gameplay element, and would get ride of a good chunk of the core issues the game has.

So, as someone that has a bit of technical knowledge on how things are actually implemented, I thought I could maybe give a bit more insight. This isn't the primary reason why things aren't accurate. The primary reason is that the joint solver isn't designed to be accurate in the first place, and has a core limitation in that the behavior is fundamentally not accurate when connecting parts that have a large difference in mass. Said otherwise, and to simplify (it's actually a bit more complex than that), a joint with a stiffness value X connecting a 10 tons part and a 0.1 ton part will be a lot less rigid than the same joint connecting two parts of equal mass. This is why parts like decouplers or reaction wheels are "weak points", because they are usually very light parts used to connect very heavy parts. KSP actually does this. For node/stack connections (not surface attach ones), KSP (1 and 2) actually generate multiple physical joints evenly positioned on a circle centered on the node. This is why larger node connections are stronger than smaller node connections, despite all joints using the same stiffness values. You're preaching to the converted. Unfortunately, given the level of coupling between the builtin Unity PhysX implementations and almost every other subsystem in the game, the chances of them doing such a redesign and refactor are very slim.

As of now, we have zero evidence that any of the specific technical challenges of a game like KSP have been solved : - Rigidbody physics are still the good old PhysX joints, with the same limitations as in KSP 1 - Aerodynamics are still the good old dKSP 1 drag cubes system, with all its limitations. - Keplerian orbits are extremely unstable and buggy, and we haven't seen any demonstration of the 3-body solver. - The background processing / thrust under warp / while unloaded system has bugs and massive performance issues that will be a significant bottleneck unless they do a radical refactor. - Thermodynamics and resource chain handling are the difficult things to get right at massive timewarp speeds, and those aren't implemented yet. Funnily enough, that system was put together by an external contractor, Jason Booth : https://medium.com/@jasonbooth_86226/my-approach-to-optimization-bfcafc1f8768