Ruedii

Yes, I agree. It seems we are actually on the same page, and you misinterpreted what I meant by "Do agile" Yes, I meant the full philosophy of cyclic feedback, not just going through the motion, and also to be adaptive on it. It seems we both have the same beef with the people who take agile philosophy too by the book and not enough as a philosophy. At the time Agile was created, before it became popular, there were not tools to have proper conversations in notes, so I absolutely understand the face to face thing. I find it annoying when people take that concept of face to face so literally. While I don't have a team, per say, I regularly work with bug reports of my interest on open source projects. I do have one open source project feature that I've been considering undergoing since. I commonly use a hybrid approach that does consider Agile principals as key values. Keep everyone in the loop as to what you do and plan to do. Inform people of your next steps and what the current blockers are. Receive and consider feedback, and provide more information as necessary, then go back and repeat at the predetermined time. This often is waiting on someone else's dev cycle, of course, since for volunteer work I don't have time for an intense cycle on every GIT commit relevant to my bugs.

OK, let me put it simply, Agile purists are the absolute worst hypocrites in software. Following a specific manifesto and process as a means to complete software is a clear contradiction of Principal 2, and 12. Not adapting your development workflow and priorities and instead staying on a fixed set of priorities is against the very principals of Agile. So entering new methodologies, setting teams on other methodologies, is important. Furthermore, Agile's 12 principals are seriously in contradiction to each other, because 6 assumes everyone works in the same way favoring face to face contact, but 5 says everyone should work in an environment best suited for them. I for one do NOT communicate best in face to face contact. I find this sort of generalized broad brush fallacy a sham, which is exactly why you should never subscribe to a single management philosophy, lest you lose the ability to adapt to your fellow team members, and the needs of the project. I should say you should do an agile inspired methology with some things. You need to do much more rapid cycles and much more frequent changes to requirement in certain aspects of development. Fixing bugs and limitations are one of them. Honestly, the vast majority of Agile theory is extremely effective at triaging and addressing common bugs and limitations. However, Agile is also very short-sighted and many functions require things it frowns on. For instance, forking a team and the codebase to add something that will take a lot of time. I find it one of those things managers come up with that don't really understand how programming and codebases work. Many major key items require a very large amount of base code and invisible background features. Agile is not very accommodating to the development of such code. When managing the roadmap you can take some inspiration from Agile. Determining what features should be delayed or canceled to get a new feature put in the roadmap is very consistent with agile. Simply put, while it's a good theory to learn, it is rather short-sited, and broad brush to think it has to be applied to everything. Additionally, claiming it should be applied to everything is hypocritical in that it expressly says you need to adapt to the needs of your team and your clients. Sometimes what your team and clients need is not something Agile will provide, in which case you need to introduce other management and methodology theories.

Yes, the most common one is small bugs and high priority bugs are done AGILE, roadmap is planned Waterfall/Cascade, and implementation of major patches and roadmap steps is done SCRUM. AGILE does not work well with roadmap as it results in a constant moving target, but it works well with smaller and high priority bugs. Leaning too much into AGILE planning methods will result in the project losing focus (e.g. KSP2 under the initial management team) but not embracing it enough will result in a lag between simple but game-breaking bugs from being fixed. It is a balance to do things right, and generally multi-methodolgy is the way to go.

Any chance you could explore Linux builds soon? Trying to get Private Division to make their launcher compatible with Proton is getting annoying.

Oh, when playing with the SpikeX parts I found that the nacelle parts make excellent drop tanks.

A few more questions: Do you have any consideration for adding a slow draw, fast discharge HV-Charge resource w/ Super Capacitors? Additionally do you have plans to implement heat from fast electric charge transfers (obviously treating slow ones as moot for efficiency.) Additionally, if you need some ideas on how to reduce physics load, and error drift I can give some minor tips. Most of them involve creating a tree to disable physics on stuff, cutting collider and physics object count to a minute fraction of what they are.

BTW, if you want someone to update the config versions of all your old mods, and help you mask parts that became non-functional due to KSP version updates (Mostly wheels) @linuxgurugamer can do that. He also frequently takes over old projects or even accepts them as donations to Restock+ or Recycled parts. (Streamline would go good in Recycled Parts if you ask me.)

As a note, your CKAN files need updating, if you get your mod on github. Simply uploading and editing in the web IDE is a very good option if you don't want to use GIT command line (trust me you don't.) That is what I do 99.99% of the time. The only time I would consider bothering with GIT is if I'm actively editing, compiling and testing an unstable branch of something and I absolutely need to keep everything in sync as often as possible because other people are working on it too. If I can keep my change record on GitHub's side that is enough for me.

Sorry for the old reply, but it seems these still work with newer game versions. Is there any reason they haven't been updated in CKAN? The same goes with inline cockpit, which has only one broken part set (landing gear.) As a note, as of tweak scale you can "Manually" tweakscale in stock using some of the settings to create a cloned part that is the same other than being scaled up. I should just look into doing this myself.

Interesting question on a related bug, is KSP2 properly handling treating each craft and terrain layer as a separate physics layer unless they are within collision range? This is a very important way to reduce physics load. Additionally turning off collisions for any body not in close contact with another body might be a good improvement for physics. Ideally only the single quad of a surface should be active for physics on a craft that is landed, landing or taking off. It might be good to run a threshold algorithm on the delta of active forces on a vessel over the past few seconds to determine whether to treat it as a single ridged body or a structure made up of multiple ridged bodies. If the forces on a vessel are within a margin of error of static, including internal forces, of course, then it be treated as a static object and thus a single ridged body mesh instead of a compound one.

Link? Worse, I bet it is that nasty geometry buffer GPU memory leak. Slow memory leaks in the CPU-Side are often able to be cleaned up by the GC, or at worst the OS can throw them into VM. The GPU typically has no such options. I understand if this is legacy code from a previous project and they are going to declare critical mass on this. They might want to hurry up if this is the case.

Nevermind on the crash. The segfault was (somehow) caused by waterfall, unrelated to this other issue (Which should still be fixed.) I don't know if it's related and I'm too lazy to reinstall waterfall (which I don't need) and remove contract configurator (which I do)

Found the problem in my log: OnLevelWasLoaded was found on ContractConfigurator This message has been deprecated and will be removed in a later version of Unity. Add a delegate to SceneManager.sceneLoaded instead to get notifications after scene loading has completed (Filename: Line: 369) Script error: OnLevelWasLoaded This message parameter has to be of type: int The message will be ignored. (Filename: ./Runtime/Mono/MonoScriptCache.cpp Line: 265) There are two errors here, one major, one minor. The minor error is that "OnLevelWasLoaded" should not be used at all on the latest version of Unity. After this OnLevelWasLoaded has a bad paremeter to one of it's settings. This is followed by a segfault and stack dump that probably isn't useful.

Still having the problem on Linux, though. I will double check my versions.

Doesn't 1.10+ simply not allow parts to be packed if they are missing "Module Cargo Part". Sure, not being able to assemble is bad, but not the end of the world. As a note, can you get this listed on CKAN?