Ruedii
-
Posts
1,209 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Ruedii
-
-
On 3/17/2024 at 4:07 AM, ShadowZone said:
Very hard disagree on this.
Whoever taught you that Agile is something that you can do or that is a methodology or framework like some kind of cooking recipe, was selling you snake oil. The Agile Manifesto is over two decades old and people apparently still haven't understood it - or are deliberately misrepresenting it. It's far more fundamental: Either you (meaning your organization) are agile or you are not. If your work adheres to the twelve principles outlined in the manifesto (or at least most of them), then you are agile, no matter what framework you are using to structure your work. Scrum is just a methodology that developed from the agile way of thinking. But you can be agile doing Kanban or XP or yes, in parts even waterfall.
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. -
On 3/12/2024 at 3:41 AM, ShadowZone said:
I just have to add my voice to the people asking for #20 to switch from "works as intended" to "redesign going on based on player feedback".
It hampers more complex trajectory planning, same as the choice to limit maneuver nodes to stop working when exceeding the calculated dV of the active vehicle (which can be demonstrably wrong often times).
Please change this!
In modern software development and especially when using a framework called "Scrum", the development team works in short increments, usually 2 to 3 week cycles called "sprints". At the beginning the team pulls from a prioritized backlog what they believe they will be able to achieve during the coming 2 weeks. The backlog is usually prioritized by a product owner based on business value (based on answering the question: what will provide the most value to the customers/users of the software?).
This process of picking the body of work for the next sprint and committing to it is called sprint planning.
After a sprint, the development team presents their results and gathers feedback and after that usually sits down and discusses what went well and what could be improved in the upcoming sprints.
Switching to these shorter development cycles enables software companies to get feedback faster and improve on software faster than working months or years in the blind and then having to rework a metric ton of code at once if they realize they messed up a foundational feature.
At least that's the theory. Most software companies/teams use some variant of this process.
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.
-
On 9/2/2023 at 3:48 AM, Anth12 said:
Reported Version: v0.1.4 (latest) | Mods: Lazy Orbits was used to create the 8001 test save then removed | Can replicate without mods? Yes
OS: Windows 10 | CPU: i9 9900K | GPU: 3070ti | RAM: 32GB
Expected Behaviour:
That when a craft isn't rendered the game treats 1 craft as one entity (no matter how many parts it has) and that the craft is on rails to improve overall performance.
Note: This behavior might be different then a craft is using its engines.
Observed Behaviour:
That KSP2 is calculating the physics of all parts of all crafts whether they are rendered or not, causing performance issues.
3 Tests:
What the tests will prove:
Test 1 will show KSP1 maintaining maximum performance regardless of how many parts there are in the save when theres only a 1 part craft in scene.
Test 2 will show KSP2 with a massive drop in performance which is directly related to the amount of parts in a save no matter if they are rendered or not. (Used the Lazy Orbits Mod)
Test 3 will show similar to test 2 (Lazy Orbits Mod Not Used)
Test 1 + 2: KSP1+KSP2 8x1000 part crafts being deleted one at a time while focused on a 1 part craft on Vall. (Includes Videos + Save File)Note that the 1000 parts are made up of 999 truss segments + 1 probe to stop it being counted debris.
I did this to attempt to stop the game from excessively using the resource system.
I did the following:- Put 8x1000 part crafts in orbits around different planets/moons using Lazy Orbits
- Put a 1 part craft on the surface of Vall
- I recorded the ms/frame (KSP2) or FPS (KSP1) for 8001 parts while having only the 1 part craft in scene on Vall.
- Went to the tracking station and deleted 1x1000 part craft reducing the part count total to 7001 and then tested on Vall again.
- Went to the tracking station and deleted 1x1000 part craft reducing the part count total to 6001 and then tested on Vall again.
- Went to the tracking station and deleted 1x1000 part craft reducing the part count total to 5001 and then tested on Vall again.
- Went to the tracking station and deleted 1x1000 part craft reducing the part count total to 4001 and then tested on Vall again.
- Went to the tracking station and deleted 1x1000 part craft reducing the part count total to 3001 and then tested on Vall again.
- Went to the tracking station and deleted 1x1000 part craft reducing the part count total to 2001 and then tested on Vall again.
- Went to the tracking station and deleted 1x1000 part craft reducing the part count total to 1001 and then tested on Vall again.
- Went to the tracking station and deleted 1x1000 part craft reducing the part count total to 1 and then tested on Vall again.
- I recorded all of the results and put them into a graph.
Video Evidence: (Time stamped after each deletion for faster navigation)
KSP1: 1.12.5 https://youtu.be/v8Q8LkIPu_s?t=12
KSP2: 0.1.4.0 https://youtu.be/GVe6zyo9KQ0
Save File:
0140 8001 Part Test.json (Dropbox Link)Test 3: KSP2 10x250 part crafts being deleted one at a time while focused on a 1 part craft on the Mun (Includes Video + Save File)
The 250 part crafts were made up of the ball tanks R-4 Dumpling, standard tanks, vector, pod and landing legs etc
I needed to actually launch it into space and the truss segments were going to be problematic.
I did the following:- Launched 10x250 part crafts with infinite fuel on into Kerbin low orbit
- Launched a craft and landed on the Mun and decoupled parts so it ended up 1 pod
- I recorded the ms/frame (KSP2) or FPS (KSP1) for 2501 parts while having only the 1 part craft in scene on the Mun
- Went to the tracking station and deleted 1x250 part craft reducing the part count total to 2251 and then tested on the Mun again.
- Went to the tracking station and deleted 1x250 part craft reducing the part count total to 2001 and then tested on the Mun again.
- Went to the tracking station and deleted 1x250 part craft reducing the part count total to 1751 and then tested on the Mun again.
- Went to the tracking station and deleted 1x250 part craft reducing the part count total to 1501 and then tested on the Mun again.
- Went to the tracking station and deleted 1x250 part craft reducing the part count total to 1251 and then tested on the Mun again.
- Went to the tracking station and deleted 1x250 part craft reducing the part count total to 1001 and then tested on the Mun again.
- Went to the tracking station and deleted 1x250 part craft reducing the part count total to 751 and then tested on the Mun again.
- Went to the tracking station and deleted 1x250 part craft reducing the part count total to 501 and then tested on the Mun again.
- Went to the tracking station and deleted 1x250 part craft reducing the part count total to 251 and then tested on the Mun again.
- Went to the tracking station and deleted 1x250 part craft reducing the part count total to 1 and then tested on the Mun again.
- I recorded all of the results and put them into a graph.
Video Evidence: (Time stamped after each deletion for faster navigation)
KSP2: 0.1.4.0 https://youtu.be/uEFy6o8bOOg
Save File:
0140 2501 Part Test.json (Dropbox Link)Results from Videos on a Graph (lower is better):
Note that KSP1's FPS is converted to ms/frame.
Excel File:
KSP12TestResults.xlsx
Conclusion:- KSP1 only calculates 1 craft as 1 part when it isn't rendered and is out of physics range regardless of its part count.
- KSP2 calculates the physics of every part of every craft in a save causing performance issues the more parts there are in a save file.
Additional Information:
Colonies has the potential to have players using a lot more than 8000 parts in a save file.
This will affect performance even more severely and also means for longer and longer load times.Original Bug Report (0.1.1.0):
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. -
On 8/31/2023 at 6:10 PM, Anth12 said:
@Timmons Pulled this bug report out of the archive.
Link?
1 hour ago, Vortygont said:Does somebody think that framerate downgrade in atmosphere and in low orbit is memory leak? Because it looks like memory leek for me but I don't have evidence
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. -
45 minutes ago, Ruedii said:
...
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.
...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. -
On 9/12/2023 at 8:19 AM, siimav said:
Looks like this issue only existed for 2 hours until NathanKell pushed a hotfix release.
Still having the problem on Linux, though. I will double check my versions.
-
On 7/31/2023 at 8:02 PM, SpudNutimus said:
Heads up, I cobbled together a quick ModuleManager config that allows the parts in this mod to work with KSP 1.11+'s EVA construction system. You can find it on GitHub HERE or inside the following spoiler. Requires Missing Robotics and ModuleManager, obviously.
// RvR-toob 150
@PART[DC_Arm_arm]:FINAL
{
MODULE
{
name = ModuleCargoPart
packedVolume = 80
}
}// RvR-toob 80
@PART[DC_Arm_arm2]:FINAL
{
MODULE
{
name = ModuleCargoPart
packedVolume = 40
}
}// RvR-toob 45
@PART[DC_Arm_arm3]:FINAL
{
MODULE
{
name = ModuleCargoPart
packedVolume = 20
}
}// Micro Motor
@PART[DC_Arm_rotor]:FINAL
{
MODULE
{
name = ModuleCargoPart
packedVolume = 5
}
}// RvR-LBow 44
@PART[DC_Arm_turn]:FINAL
{
MODULE
{
name = ModuleCargoPart
packedVolume = 30
}
}// RvR-LBow 32
@PART[DC_Arm_turn_02]:FINAL
{
MODULE
{
name = ModuleCargoPart
packedVolume = 15
}
}// Flat Hinge (2m)
@PART[DC_doorhinge_2m]:FINAL
{
MODULE
{
name = ModuleCargoPart
packedVolume = 100
}
}// Flat Hinge (0.5m)
@PART[DC_doorhinge_0075m]:FINAL
{
MODULE
{
name = ModuleCargoPart
packedVolume = 25
}
}// Flat Hinge (1m)
@PART[DC_doorhinge_075m]:FINAL
{
MODULE
{
name = ModuleCargoPart
packedVolume = 50
}
}// 23Z Rolling Gantry [Standard]
@PART[DC_GANTRY_01]:FINAL
{
MODULE
{
name = ModuleCargoPart
packedVolume = 400
}
}// 23Z Rolling Gantry [Double]
@PART[DC_GANTRY_01_2X]:FINAL
{
MODULE
{
name = ModuleCargoPart
packedVolume = -1
}
}// 115Z Rolling Gantry
@PART[DC_GANTRY_02_2Xs]:FINAL
{
MODULE
{
name = ModuleCargoPart
packedVolume = 150
}
}// 05Z Rolling Gantry
@PART[DC_GANTRY_02s]:FINAL
{
MODULE
{
name = ModuleCargoPart
packedVolume = 75
}
}// 40Z Rolling Gantry
@PART[DC_GANTRY_03_2Xs]:FINAL
{
MODULE
{
name = ModuleCargoPart
packedVolume = -1
}
}// 77C Pivot
@PART[DC_Pivot_01]:FINAL
{
MODULE
{
name = ModuleCargoPart
packedVolume = 150
}
}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? -
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.
)
-
When you want to push a testing build with Native Linux, I will gladly run some basic testing.
-
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. -
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. -
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.) -
BTW, if I bypass the launcher by launching the KSP2 binary as a non-steam game, the game runs quite well.
-
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. -
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. -
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..)
-
On 5/1/2023 at 2:54 PM, dr.phees said:
Launchers really are a cancer to games. I struggle to understand the reasoning behind these pieces of
junksoftware.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.
)
Bug Status [3/11]
in KSP2 Suggestions and Development Discussion
Posted
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.