Gotmachine
-
Posts
701 -
Joined
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Gotmachine
-
-
31 minutes ago, Vl3d said:
What sources or evidence are you basing your assumptions on?
Sources and evidences that we aren't allowed to discuss in these forums.
-
In some vain efforts to make PhysX joints to be more rigid when connecting parts of vastly inequal masses, KSP 2 is implementing a silly hack in the form of scaling the Rigidbodies inertia tensor according to the connected parts mass ratios.
This is a well known "trick" in the Unity community, however, this has the consequence of fundamentally breaking the physical behavior of Rigidbodies.
Excerpt from the PhysX documentation :QuoteMass Scaling
PhysX joints may apply scale to the mass and moment of inertia of the two connected bodies for the purposes of resolving a joint. For example, if you have two objects in a ragdoll of masses 1 and 10, PhysX will typically resolve the joint by changing the velocity of the lighter body much more than the heavier one. You can apply a mass scale of 10 to the first body to make PhysX change the velocity of both bodies by an equal amount. To ensure the same property holds for both linear and angular velocity, you should adjust the inertia scales in accordance with the bodies' inertias as well. Applying mass scales such that the joint sees similar effective masses and inertias makes the solver converge faster, which can make individual joints seem less rubbery or separated, and sets of jointed bodies appear less twitchy
Many applications that prioritize visual behavior over adherence to physical laws can benefit from tuning these scale values. But if you use this feature, bear in mind that mass and inertia scaling is fundamentally nonphysical. In general momentum will not be conserved, the energy of the system may increase, the force reported for the joint may be incorrect, and non-physical tuning of breakage thresholds and force limits may be required.
Now, I haven't tested what KSP 2 does in depth nor attempted to prove the consequences of KSP 2 scaling the inertia tensors, but given how many people are reporting issues with phantom torques/forces resulting in vessels spinning out of control randomly and orbit instability, it's tempting to connect the dots.
This could also explain why reaction wheels and RCS appear so weak compared to KSP 1, despite not having being nerfed. Since the parts providing RCS or RW torque are usually very light, they might be disproportionally affected by the inertia tensor scaling hack, resulting in their ability to provide torque being artificially reduced when connected to heavier parts.For anyone that has some issues with stuff spinning out of control and other phantom forces issues, I would suggest disabling that KSP 2 "feature" and to report back if things seems better.
You can disable that feature by going to the KSP user data folder and editing the physics settings :
- Paste the following in the windows explorer bar : %USERPROFILE%\AppData\LocalLow\Intercept Games\Kerbal Space Program 2\Global
- Hit enter to navigate to the folder
- Right-click on the PhysicsSettings.json file and select Open with... > Notepad
- Locate the "ENABLE_INERTIA_TENSOR_SCALING": true, line
- Change true to false
- Save the changes and restart the game
-
1 hour ago, Vl3d said:
Why do you say that?
Background processing of unloaded vessels (and other stuff like colonies), assuming they intend the players to be able to have a moderately complex space program going on, entails running a large chunk of the game logic on thousands of entities.
To make that possible without tanking performance, there are only two possible strategies :
- Don't actually run the same game logic and aggregate entities into higher-level abstractions and/or reduce the update rate to cut down computational cost at the expense of simulation precision/coherency.
- Architecture these entities around data-oriented programming paradigms, making the data cache-efficient and allowing to leverage parallelism and SIMD instructions.As of the current EA release, KSP 2 isn't doing anything like that.
All they have done is to separate the objects game logic from their loaded representation, which is the bare minimum required for the background processing concept to work.
Now, each unloaded vessel/part/partmodule is doing a lot less work than when loaded : no joint physics, no collisions, no visuals to push to the GPU...
But even taking the estimate that each unloaded part does around 5% of what a loaded part does in terms of processing, if for example you have a game with 20 vessels made out of 100 parts, that still is worth the computational cost of 200 loaded parts.The only thing they can possible do without basically throwing away the whole thing is to dial down the unloaded vessels update rate, but this has direct consequences on the simulation quality, especially on some subsystem that are time-step sensitive like solar panel evaluation or thermodynamics.
It might be possible given the current architecture to implement some limited parallelism, but currently there is no provision for any of that and it would already require a quite large refactor. -
This is not a bug, it's a feature.
The visible, physically interactable with representation of the vessel is not loaded.However, the core logic will stay loaded, because that's a feature of KSP 2 : vessels are able to use their engines in the background, while unloaded.
To make that work consistently, this mean a large chunk of the core logic is kept running : resource requests and conversions, solar panels, thermodynamics, etc...
This obviously add a lot of overhead, but with a good core architecture, this would have been doable without impacting overall performance too much.
Unfortunately, the way KSP 2 is architectured is absolutely not up to that task, at least in the current state of things. -
1 hour ago, tstein said:
Yes but they reduce the stack by half. That is engineering solution. If you cannot remove the problem you remove the frequency of the condition
Due to the nature of the problem, that doesn't really solve anything, it would make it even worse.
As I mentioned, the main issue is that PhysX joints become less rigid when the mass ratio between connected parts is higher.
So for example having a single huge procedural fuel tank part connected to a decoupler is actually worse than several smaller fuel tank parts connected together and then to the same decoupler. -
5 hours ago, Mushroom Kerman said:
10,000x more rigid and the wobble only gets.... a lil bit better? Can someone who is good with computers explain this to my tiny mushroom brain?
The short answer is that PhysX, the physics engine KSP 2 (and 1) uses is not capable of simulating infinitely rigid joints. That's not what it's designed for.
They will always flex to some extent, and additionally, it's dependent on the mass ratio between connected parts.
Said otherwise, a joint connecting a very heavy and a very lightweight part will flex (a lot) more than a equally strong joint connecting two parts of equal mass.
This is why you get a lot of flex in KSP 1/2 when you connect a several tons fuel tank to a 100 kg decoupler.And to be clear for all the people thinking having wobbly joints is a design decision and a physically accurate challenge, it's not.
The behavior is unphysical and largely unpredictable, it exists because PhysX is the default physics engine available in Unity and requires the least effort to implement.The only workaround is to spam more internal joint connections between each part, which is what the KSP 1 autostruts does (badly) and the KerbalJointReinforcement KSP 1 mod does (a lot better).
-
On 2/25/2023 at 7:20 PM, Vicis said:
Per the EULA you won't own any mods you create though
Per the EULA, mods aren't allowed, so this doesn't really matter...
-
1 hour ago, Vl3d said:
Please always consider the fact that the UI has to be visible for players that are sitting 3 meters away from the TV on the couch.
Well, in that respect, it's a total failure. While the overall UI takes a ton of screen real estate, many critical elements (text, icons) are tiny and barely readable.
When you want to make an UI that work for all uses cases, you make it as uniform and space efficient as possible so it can be globally scaled up and down. -
1 hour ago, linuxgurugamer said:
It would be best if the devs provided at least some guidance as to how to set up mods, package them, etc
Yes, in an ideal world, KSP 2 would have a proper mod manager that define and handle packaging, semver, dependencies, metadata, etc.
My little finger tells me we aren't in that world, and that we better handle all this by ourself.As for using an external / community maintained modding toolset / modloader / injector, there are several benefits at doing so, regardless of if the game if using the Mono or Il2CPP backend.
But frankly, I don't see how they could possible have made the "KSP 2 will be more moddable than KSP 1" statement if the game is using IL2CPP.
I know that personally, that would probably kill all motivation for me to develop mods for KSP 2. -
1 hour ago, Master39 said:
You're right in one thing here, we're talking about an intentional design choice, not a bug, nor a fail in optimizing.
Nope, that couldn't be further away from reality.
I can say with 99% confidence now that KSP 2 is using the Unity vanilla PhysX joints implementation.
Why so confident ? Because the floppy joints is a well known intrinsic limitation of that implementation, and all you can do is "spam more joints" workarounds, which KSP 1 does in two variants :
- For stack nodes connections, it actually create multiple joints, usually 3 joints put 120° apart on a circle centered on the node.
- Autostruts
This is also what the KJR mod does. KJR is basically just a smarter and fully automatic autostrut implementation, spamming additional joints using some heuristics based on connected parts mass.The point is that floppy joints as they exist in KSP 1 and now KSP 2 are not a game design choice and never were.
They are the result of using a physic engine that isn't designed to handle what KSP is trying to do with it, and that decision itself is the result of not enough skill/resources to implement an alternative. -
We don't need anything from the devs to start modding KSP 2.
There is a quite dynamic community and toolset ecosystem allowing to extensively mod any Unity game. The most popular/advanced of these tools is BepinEx.
In fact, I would argue that given how overwhelmed Intercept seems to be with trying to put the game together, they should probably let the modding community handle everything on their own. -
I'm excited about KSP 2 being a new thing !
-
@king of nowhereYou're missing the Harmony dependency.
-
6 hours ago, king of nowhere said:
anyone knows how to fix?
KSP.log needed.
-
On 2/13/2023 at 7:39 AM, Lisias said:
what's happens if there's an Exception while handling the ModuleB.OnStart()? Well, the ModuleC.OnStart() will not be called,
Nope. Managed exceptions happening in the UnityEngine.MonoBehaviour "message" methods (Awake, Start, FixedUpdate, Update, etc) are always catched.
Same for the PartModule major virtual methods (OnAwake, OnStart, OnFixedUpdate, OnUpdate, etc), each individual call is wrapped in a try/catch block.
Said otherwise, triggering an exception in those methods will only affect the problematic call, all subsequent calls on other objects will run as usual. -
@R-T-B Moving the MapSO and ScatterDistribution patches to Kopernicus seems a sensible approach indeed.
The ROCValidationOOR patch isn't Kopernicus specific, the stock bug can affect anyone defining custom ROC scatters, so it make sense to keep it in KSPCF.
This being said, you could probably duplicate it in Kopernicus to avoid the KSPCF dependency, and disable either the KSPCF or Kopernicus patch when both mods are present.Let me know when/if you're doing that, but in any case I will probably wait a few months before removing the MapSO and ScatterDistribution patches from KSPCF, we can't really rely on people keeping both mods up-to-date immediately.
-
@DrKerbalMDThanks for reporting. This should be fixed in release 1.24.6
8 hours ago, dok_377 said:from the technical standpoint it's still a bug
It's a bug, but this has no consequences in stock, and the KSPCF patch is causing the terrain to generate slightly differently at the poles on all stock bodies (not only Moho).
For people installing KSPCF and having already landed stuff there, this is likely to wreak havoc.Technically, the stock bug is only an issue for planetary system modders wanting the terrain to generate as defined in their heightmaps, so my opinion is that the whole thing should be handled by Kopernicus.
There is also the issue that the methods being patched are hot paths from a performance standpoint and the simple fact that KSPCF is patching them has a (small) effect on performance for no good reason for all players that don't have Kopernicus.
Things are what they are and trying to revert the patch in KSPCF to move it to Kopernius is gonna be more trouble than anything, both for me, R-T-B and end users, so things are staying as they are.But this should serve as a reminder that KSPCF mission statement is to fix stock issues and that modded KSP issues should be handled by the mod in question, to avoid situations like this.
The cases where a modding related patch make sense to be included in KSPCF are when :
- The patch is at very low risk of altering the stock API behavior.
- The patch can benefit to multiple mods, so implementing it in KSPCF prevent multiple mods to be fighting over its implementation. -
KSP doesn't handle anything related to your monitor refresh rate. There are several software layers in between. Some driver settings will take precedence over the in-game settings.
This being said, your issue is likely that the NVidia driver is configured to use GSync or adaptive sync , but somehow your monitor doesn't handle it correctly.
Framerate in KSP does indeed jump all over the place because of various issues but mainly because it's a single-thread CPU bound game, and your Ryzen 9 5900HX isn't exactly shining on that front, far from it.
The solution is likely to just disable GSync/Adaptative sync in the NVidia driver for KSP. -
You don't need mods for that, you can just adjust the "science rewards" % setting in the stock difficulty settings.
-
New release : Kerbalism 3.17 for KSP 1.8.x to 1.12.x
- Fixed issue #811 : MP transferred to jetpack when going on EVA is not registered correctly (@gotmachine)
- Fixed issue #500 : Process dump settings aren't handled/persisted correctly (also fix #337 and #834) (@gotmachine)
- Fixed issue #833 : Ensure VesselData can always be created even if ProtoVessel is null (@gotmachine)
- Fixed issue #845 : Make isSerenityGroundController persistent to prevent loosing comms when vessel type is changed manually (@gotmachine)
- Tweaked automatic DataRateDampingExponent calculations so result in stock is ~6, matching original value in Kerbalism 3.14 (@gotmachine)
- Performance tweak : Prevent PartModule PAW update code from running when PAW isn't shown, provide very significant perf gains (-0.7ms / frame on a basic space station) (@gotmachine)
- Added stock cargo part support for Kerbalism parts (@OnlyLightMatters)
- SSPX support : Added greenhouse to aquaculture-375-1, changed cupola-greenhouse-125-1 from 1/90 to 1/6 of kerbalism greenhouse (@DangerNoodle9000)
- SSPX support : Tweaked analysis speed of some labs (@DangerNoodle9000)
- US2 support : Added support for sabatier reactor (@DangerNoodle9000)
- Science : Added back automatic conversion of all modded labs to the Kerbalism version (see issue #762) (@DangerNoodle9000)
- Added body/biome localization in a few additional places (@tinygrox)
- Improved zh-cn localization (@tinygrox)
- Improved ru localization (@deVDem)
- Added partial fr-fr localization (@vinix38)
Thanks to @R-T-B for triggering my will to work on all this
-
@Vl3dSo... the issue is mainly that the Station Science mod is half implementing features that are half implemented in KSP itself.
The PersistentIConfigNode KSPCF patch is providing an implementation for those missing stock features, but since the mod doesn't implement them correctly, things go quite wrong.To fix this, you can disable the PersistentIConfigNode patch, take a look at the KSPCommunityFixes\Extras\KSPCF_UserSettings.cfg.extra file for how to to that.
This being said, while the station mod is the root cause, KSPCF should probably handle such errors more gracefully. -
3 hours ago, Vl3d said:
Does anyone have any idea about these errors?
Could you provide the full KSP.log ?
-
Okay, should be fixed in KSPCF 1.24.2
-
Ok, I managed to reproduce the issue.
I won't have a lot of time to investigate in the following days, but this is caused by the FastLoader patch, and it actually cause drag cubes in general to be semi-randomly wrongly generated.
Specifically, this happen on all parts having multiple drag cubes defined, this include parachutes, but also animated parts such as the inflatable heatshield, deployable antennas, landing gears, etc.The FastLoader patch alter the part compilation to decouple it from framerate, but it seems some part of the drag cube computations actually require a frame to skipped.
I suspect what require a frame skip is setting the part animation at the desired position for each drag cube, but it might be an issue with the aero texture not being updated immediately, this require further investigation.
The reason it's semi-random is likely because the FastLoader patch still skip a frame occasionally to maintain ~30 FPS while loading.I'm opening a github issue to track this, will try to push a fix ASAP.
n-body Physics Discussion
in KSP2 Discussion
Posted
Simple keplerian orbit ("patched conics") is analytic but it doesn't have a closed-form expression either, it's also an iterative algorithm.