Jump to content

Ruedii

Members
  • Posts

    1,209
  • Joined

  • Last visited

Everything posted by Ruedii

  1. 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.
  2. 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.
  3. 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.
  4. Any chance you could explore Linux builds soon? Trying to get Private Division to make their launcher compatible with Proton is getting annoying.
  5. Oh, when playing with the SpikeX parts I found that the nacelle parts make excellent drop tanks.
  6. 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.
  7. 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.)
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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)
  13. 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.
  14. Still having the problem on Linux, though. I will double check my versions.
  15. 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?
  16. Also occurs when loading saved game. (Might be different bug, but logically would be the same bug.) Not fixed on 0.1.4-x in that case. Worse yet, the colliders stay in place which just ruined my Mun landing. (No fret, I'm tuning my Mun landing craft for fun and found it a tad short on fuel, made it safely, but fallen over on the ground with 22 Dv left in the lander stage. )
  17. When you want to push a testing build with Native Linux, I will gladly run some basic testing.
  18. As a note, the exact module acting up seems to be CEF. (Chromium embedded framework). While there is a minor issue loading the WMF (Window Media Framework) embed for CEF, this doesn't seem to be the issue. That should just stub out safely. It looks like there is a crash on the attempt to access the SSL/TLS Keystore, however I'm relying on rather unclear debug logs so I don't know for sure. All I know is that CEF is failing and then there are a series of segfaults.
  19. I think there is a need for a selection of "Zones" on many of the parts (most notably the Mk3 passenger cabin). In these zones you should be able to select from several preset coloring patterns, each of which utilize the two colors and colors derived from them differently. Additionally you can set each of these two zones to use a different pair of colors per zone and select between textures that can utilize those two colors. You should be able to bookmark a large number of color pairs, with a good number of presets available for you. There should be blanks for 8 pairs in the default interface, and 256 pairs in the advanced selection, about 16-32 of the pairs should be prefilled for you, being pulled from the various common real world space agency paint pallets and natural colors of certain common materials.
  20. Any progress with getting the launcher working with Proton/Wine or will I need to use my override to run the game executable directly in proton? Also, any progress in getting an option in the launcher to just skip the vast majority of it's function and have it just strap over to the game without loading anything substantial (only a "loading" splash screen derived from the updating one instead of the full interactive UI.)
  21. BTW, if I bypass the launcher by launching the KSP2 binary as a non-steam game, the game runs quite well.
  22. I particularly like the parts that get a soft glare (semigloss anodized metallic parts.) While harsh glare on many things IS ABSOLUTELY realistic for space (near zero atmospheric scattering), sometimes there question of aesthetics. This is why while national space agencies normally have everything coated in foil for maximum performance, your commercial agencies will use various anodized scattering paints that get almost the same level of reflection with none of the glare. When they shoot footage from webcams they put up on their equipment they want it to look good, and the level of glare you get on foil coating in space does not look good at all.
  23. They have a surprising number of engineers on their team, due to the nature of the game allowing them to attract them. I don't think they will have any problem optimizing the game itself. The question is if they can do so without substantial quality loss. There is a massive amount of A/B testing and smoke testing to do to determine if something creates reliable performance gains while not having notable quality loss. Depending on the gains, it may be worth adding to the list of performance optimizations to put for low end systems, provided it provides the same performance gains on those older systems.
  24. Full bug report (sorry it took so long, I was slowly exhausting various methods of trying to get it to work every few days.) KSP Version: KSP2 0.1.2 Operating System and version (Windows 10, Windows 11): Kubuntu Linux 21.04 CPU and GPU models, any other system information which could be relevant: Ryzen 5 1500X, AMD RX 5500XT, GPU Driver Mesa 22.2.5. All major Proton versions tested. Description of the bug. Expected Behavior Be able to play game from launcher Observed Behavior Launcher displays a busy spinner than crash Steps to Replicate: Launch game on any Linux system via Proton. Fixes / Workarounds (if known..): Configure system to skip launcher via replacing the launcher binary with a link to game executable. A list of ALL mods. If the list is long, please consider using a spoiler window. Other Notes / Screenshots / Log Files (if possible..)
  25. I know. Anyhow, I manually downloaded the files it was failing to unpack and here are updated debug logs. https://gist.github.com/Ruedii/4bd8c48d6a983c1d0c09274aabc0a76f I will fetch and give full data on my system and formal bug report information in a bit. (Sorry for not doing this earlier. A little mentally exhausted from trying to sort out the issue myself and find a workaround that did not involve skipping the launcher.) I will also add a Proton debug log then, but I need to adjust the debug log settings so it is not full of log spam.
×
×
  • Create New...