Gotmachine

TBH, I have no idea how to read this, that's why I'm asking. This is talking a lot about goals, and is very vague about what the actual system will be.

So, if I understand correctly, this is a stateless system where only instantaneous heat fluxes are considered each tick, with part temperature being an analytical result of the current fluxes, with no concept of stored energy ?

Resource conversions have indeed a bunch of limitations, some of them could be qualified as bugs. But the short answer is that the foundation for that subsystem just isn't adequate to make complex resource chains work reliably. Moreover, there are tons of mods relying, extending or even trying to fix some of the shortcomings of that subsystem, so altering it is a nightmare from a mod compatibility PoV. Not to say nothing can be done, but personaly I'm not interrested in working on this.

@jinksThanks for the details. There is indeed a bug in KSPCF, see https://github.com/KSPModdingLibs/KSPCommunityFixes/issues/152 I'm not currently available to work on this, but NathanKell will try to push a fix soon.

Which thread / post ? There are at least 8 different WBI mods. I haven't investigated this issue because nobody managed to give me a clear description of which mod is involved nor what mechanism or part isn't working.

When there is no solution, you're working on the wrong problem. KSP 1 joint physics are the result of a bug, or rather, an unphysical behavior in the PhysX solver. Wobbly joints are fundamentally unphysical, so no amount of tweaking will result in something that both satisfy the "lol spaghetti so kerbal" alleged identity that absolutely every KSP 1 player has found at best irritating and a possible structural engineering gameplay element.

Okay. Do a simple thing, comment out that line : https://github.com/zer0Kerbal/ScrapYard/blob/2fdfcc0c0bdc72c8e777d34356ccb574b0b858d0/source/ScrapYard/Modules/ModuleSYPartTracker.cs#L31 Then recompile ScrapYard and use it, good luck trying to get the flowgraph error to happen now.

No. You don't need any kind of synchronization on data access. There is no concurrent access to anything. Everything runs from a single thread and all calls are sequential, no matter if you use a coroutine or a MonoBehaviour message. If you have a coroutine with "yield null", it will yield sequentially on the Update loop, like any MonoBehaviour.Update() method. If you have a coroutine with "yield new WaitForFixedUpdate()", it will yield sequentially on the FixedUpdate loop, like any MonoBehaviour.FixedUpdate() method. The only thing that is affected by performance characteristics is how many FixedUpdate loops are happening within an Update loop. This is indeed something that one might have to consider if accessing the same data both from the FixedUpdate and Update loops, and has nothing to do with thread scheduling, but simply with the fact that the FixedUpdate loop is called a varying amount of times (including not at all) from within the Update loop, in order to be roughly called 50 times per second, whereas the Update loop call frequency is directly tied to the framerate. While this is something to keep in mind, anything wrongly relying on a 1:1 ratio between FixedUpdate and Update calls is pretty much guaranteed to break, especially in KSP where the load on the FixedUpdate and Update loop has a huge variability. There are some other shenanigans with that in KSP, for example PartModule.OnStartFinished() is called on the third Update loop after the part instantiation, and consequently an undetermined amount of FixedUpdate() calls will have happened. There are a few other cases like that, and they do indeed impose some extra care in implementations, but this is just order of execution considerations which are almost entirely limited to initialization sequences, nothing in common with what one have to deal with in a concurrent/multitask environment. I suggest you take a careful look at the Unity documentation for all that : https://docs.unity3d.com/2019.4/Documentation/Manual/ExecutionOrder.html Yep, it's entirely possible that some consequences of ScrapYard altering the persistentId aren't consistently visible depending on order of execution shenanigans. But I don't see why this matter at all. The root cause of those issues is ScrapYard overwritting the parts persistentId, it seems we are all finally agreeing on that, so I don't see the point of loosing time analyzing the failures modes instead of just fixing the root cause. ScrapYard didn't rely at all on persistentId prior to the commit I linked. I can see why it would benefit from reading that id, but I don't see any valid reason to overwrite it.

It shouldn't change the ID. This is a ScrapYard oversight, it is hijacking a stock variable for its own needs, and I am very doubtful there is any valid reason to do that. As I mentioned, that ID is relied on by various pieces in the stock codebase, not only by the delta-v calcs, and by mods as well. And while there is a mechanism that can cause it to change in the stock implementation, this is a narrow/early event which is largely ignored both in stock code and mods using it (because it doesn't affect them), so even if ScrapYard was actually calling the id changed event, this would still cause the same issues.

A coroutine is just an extra execution point in the game loop, and the execution is just as deterministic as MB messages like Update or FixedUpdate. There are a few corner cases that can indeed result in a non-predictable order of execution, like the fixed loop frequency versus the main loop frequency, or a coroutine set to yield based on time, but I'm quite confident that no such thing is involved in the interactions between ScrapYard and the delta-v stuff. What happen is simply that on vessel/ship load, the stock deltav code create a cached data structure referencing the vessel/ship parts. That cache is then used latter when the delta-v calcs are run, but by that time, in some specific cases, Scrapyard has changed the parts persistentId. This result in the parts not being found in the cache, and consequently added again. The log error happens way further the execution stack thanks to some safeguard detecting those duplicates. I haven't done a ton of tests, but the errors have been perfectly reproducible and deterministic when I checked. It won't always happen, simply because ScrapYard doesn't always change the parts persistentId. For example, it will happen if you launch from the VAB, but not if you "revert to launch", because the "vessel rollout" event ScrapYard is listening to isn't fired in that case.

It does. You don't need to resort to native debuggers, it's possible to debug plugin managed code from within Visual Studio. Debugging the managed code from KSP itself is a bit more involving, but can be done from within VS with a bit of hacking around, or more easily with DNSpy, which has Unity debugging capabilities. I can give you a quick rundown in PM if you want. There is no multithreading going on in the KSP codebase, at the single exception of the integrator used for the maneuver planner added in 1.12. While Unity native side is multithreaded, the managed API isn't thread safe and Unity actively prevent any call to it from any thread outside of the main thread. The Unity game loop is strictly single-threaded, so there is absolutely zero chance for such things like race conditions happening unless a plugin explicitly implements some threaded code.

The error message is indeed logging cid/craftId (not ClassID, that's something entirely different), but that is just to give a way to find back the offending part from the log entry. The messages comes from the SCC graph, which actually doesn't care about any id, it holds direct part references and detect the issue by comparing those, way after the problem actually occurred. The underlying cause of duplicate entries in the SCC graph lies in the DeltaVStageInfo class, which uses persistentId to build the part lists.

You want to be able to cope with a persistentId mutation, not being able to would be a design hole in the KSP API. Lets say you have a "controller" partmodule of some some sort, that has some functionality where the user should select another part on the same vessel/ship. This mean you needs to persist a reference to that other part, which is exactly the use case that persistentId was designed for. So you grab the persistentId of the target part and persist it on the controller module. Now, when the ship is re-loaded, you want to find again the part that was targeted, finding it by it's persistentId (FlightGlobals has methods for that). This is where you want to get notified if the id has changed, which is what the onPartPersistentIdChanged event is for. And you want to get notified of it after the module has been loaded (ie, Load()/OnLoad() called), because otherwise you can't check if the id that has changed is matching an id you had saved.

As I mentioned, persistentId does indeed change. It needs to since it is well, persisted into a craft file, but at the same time must be guaranteed to be unique for every instantiated part. So when KSP loads a craft, the id that are persisted can already be in use (and often will be, since a craft tend to be loaded multiple times, for example by launching it as vessel, then loading it again in the editor, or simply launching multiple vessels out of the same craft file). That's why KSP has GameEvents.onPartPersistentIdChanged, which you can subscribe to to get notified of such persistentId re-assignements (this will be fired potentially anytime a part is being instantiated). There is second (added more recently, around KSP 1.7 I think) mechanism to get notified of such persistentId changes, the IShipConstructIDChanges interface, which one can implement on a PartModule. The interface is more limited in scope, as it will exclusively be triggered when loading a shipConstruct, and is mostly there for convenience as it will be fired a bit latter than the GameEvent in the part initialization flow. Said otherwise, there is no bug and no "misbehaviour". persistentId changing is by design, and always has been. It's even documented on the official API : https://www.kerbalspaceprogram.com/ksp/api/class_game_events.html#a87bb044eae00585d041c7f2babf47c72

Here is a detailed explanation of the issue : When a vessel is created, KSP creates a resource graph cache that is used for delta-v calcs. Specifically, a dictionary of <persistentId, DeltaVPartInfo>, which you can access from vessel.VesselDeltaV.OperatingStageInfo[x].partInfoDictionary Specifically on vessel launch (but there are other execution paths where this happen), ScrapYard reassign all parts persistentId to new ones. The execution path in the ScrapYard codebase for this is the GameEvents.OnVesselRollout handler : EventListeners.VesselRolloutEvent() -> Utilities.InventoryManagement.RemovePartsFromInventory() -> ModuleSYPartTracker.MakeFresh() -> ModuleSYPartTracker.ID setter KSP then tries to run the deltaV calcs. It check the vessel parts against the partInfoDictionary cache, but because of what ScrapYard did, all parts persistentId have changed, so the partInfoDictionary keys don't match the part.persistentId anymore, leading to KSP re-adding the same parts but with the new key This can easily be verified by doing a bit of logging on the ModuleSYPartTracker.ID setter and the partInfoDictionary objects state. Again, altering the parts persistentId is a very bad idea. The whole point of those ids is that they can be relied on to uniquely identify a part game-wide, and they are used by a variety of KSP subsystems, from docking ports to ground science or robotic parts, and are commonly used by a variety of mods. And while KSP has a mechanism to handle persistentId changes (which ScrapYard doesn't leverage), this is an internal mechanism designed to handle potential duplicate persistentIds when instantiatiating a craft, which is a very specific and limited scenario. There might be ways to mitigate that specific issue with the delta-v calcs/flow graph error, but again, this is only the tip of the iceberg. ScrapYard is messing with a fundamental mechanism of KSP and altering it's behavior in a way that is breaking the API contract. Now, to be clear, I don't mean this as an attack against anyone. This mistake was made a long time ago, see https://github.com/magico13/ScrapYard/blame/57f02047cadd56c139d2bddf74b0dd7a8b8229b0/ScrapYard/Modules/ModuleSYPartTracker.cs#L30 I would suggest looking at how things were handled in ScrapYard prior to that commit, and look into re-introducing it, or some variant of it. From a high level functional PoV, I don't see why ScrapYard would ever need to alter the parts persistentId in the first place. I'm not familiar with ScrapYard in detail and I don't intend to provide such a fix, but hopefully you can leverage the information I gave to fix the whole issue.

I don't care about if this mod is working or not, I do however care about the repeated and unfounded claim that KSPCF is the cause of the issue. The point is that SYD alters the unique identifier of parts, and that is the cause of the flowgraph errors. It shouldn't be doing this, no mod ever should, and this has far more consequences than the flow graph errors, which are actually relatively benign since they only affect the delta-v calcs and the error is actually handled gracefully by KSP. You're free to doubt or disagree, I wouldn't expect less.

How could it not be ? All you have to do to reproduce it is get a clean stock install, add Scrapyard, new game (sandbox/career doesn't matter), add a mk1 pod, a fuel tank and an engine, launch, and get immediately a bunch of flowgraph errors... Edit : and actually, I can even tell you why this is happening. This is due to ScrapYard reassigning the parts persistentId, which is a very sketchy behavior (what did you say about mods mucking about inside KSP ?), and not the only one BTW, it also alter the part prefabs, which is arguably even more questionable. This happen from the ModuleSYPartTracker.ID setter, which is called from a bunch of code paths, but notably from ModuleSYPartTracker.MakeFresh() which generate a new id from every call, and from there, there are just a whole tree of call sites. Reassigning persistentId is something that should be done with great care and can't be done at random points in the execution flow, it implies at the very least firing the onPartPersistentIdChanged gameevent, but even that isn't enough, as persistentIds are internally used by variety of subsystems, including but not limited to the resource flow graph, and also by many mods whose bheavior will also be affected by what ScrapYard is doing. Said otherwise, the flow graph errors are just the tip of the iceberg for a much more fundamental and widespread issue in ScrapYard, and has actually been around since a long time. I believe @severedsolo was actually aware of it, see

Yes and no. This doesn't affect FAR because (AFAIK) it doesn't use drag cube for its overrides of the stock aerodynamics and buoyancy. However, drag cubes are still used and computed (and are still used for thermodynamics) even in the presence of FAR, so the patch has the same benefits in terms of performance even if FAR is installed.

Note that there is no algorithmic solution that allow to simulate physical integrity (be it using RB joints, soft body / beam physics, or any other kind of simulation) at arbitrarily large time steps, it's not just a limitation of Unity/PhysX. In general, not only for physics, time warp at such extreme levels as in KSP is a quite unique requirement, and one that is a massive challenge. Everything in games (and actually, in non-games software as well) is based on the premise that logic is running in an iteration whose frequency is lower enough than real time to handle everything with a good enough degree of precision. This make everything orders of magnitude easier than trying to solve the same logic with analytical algorithms, which in most cases is simply out of reach given the overall complexity of the logic. That's why virtually every game having a "time acceleration" feature are only doing it at low factors like 4x or 10x. You only have two options to accelerate time : - Increase the iteration frequency, in which case the computational cost is directly proportional to the warp factor (ie, if your PC was able to handle 100 ups at 1x, it will only be able to handle 50 ups at 2x, 10 ups at 10x, and so on). Obviously this is very rarely used, and not applicable for KSP. - Increase the time step of each iteration, in which case you inherently get a less precise result, and past some point, you will start to hit boundary effects and get garbage, broken results out of the game logic. Some of those boundary effects can be dealt with, but this has to be done on a case by case basis, and usually require more complex specialized implementations that always have precision, performance and capabilities tradeoff. They can be either in the realm of analytical methods (rarely), or iterative methods (basically, sub-stepping some critical parts to avoid hitting the boundary effects, or using those boundaries as an iterative condition, instead of the arbitrary time step). In KSP 1, the issues of high warp speeds were relatively rare in practice, mostly because they avoided to implement features that would be subject to such issues. So while those issues exist, they aren't too much of an annoyance. But you can definitely experience them. Everything related to resource consumption/production/conversion is utterly broken past the 1000x warp barrier, and so are thermodynamics (vessels overheating out of nowhere when getting out of timewarp is a pretty common sight in KSP 1). But at least in stock KSP, those are relatively minor feature, that only affect the currently active/loaded vessel, as indeed, everything resource related is dealt with in a comically simplified analytical way for all non-active vessels. There are many other examples of things that are utterly broken at large timewarp speeds, like the comms network or solar power evaluation. But there is barely any player interaction or effect while timewarping, so this has no visible effect. In KSP 2, however, they made the (ambitious) choice of expanding the active vessel game logic to all vessels, essentially reducing the loaded/unloaded distinction to just "affected/unaffected by rigidbody physics". The primary motivation was very likely to provide the "thrust under warp / in the background" feature, but I'm not sure they realized how huge a can of worms they opened... This mean that all those timewarp issues will now have a much more impactful and visible effect (not to mention the performance implications). Personally, this has been my main concern about KSP 2 since they first announced that it would have an interstellar scope (meaning there will need to allow a huge timewarp max speed) and the "thrust under warp" feature (meaning they need to simulate everything coherently at any timewarp speed).

"other boundary conditions" are actually not so boundary. If you have engines involving EC, you also need to tick the whole EC production chain, which might also involve solar panels, which in turn have time step dependent conditions (occlusion, incidence, etc). You can also potentially have internal resource conversion chains that directly involve the consumed fuel, which you also have to tick. If you have thermodynamics, either directly for involving engine thermals, or indirectly in the resource/EC production chain (nuclear power for example), you also have to tick that, and also account for varying over time external conditions (radiators). All that can work relatively consistently at varying time steps up to 100x or even 1000x warp, but start falling apart quickly after that. And no, you can't "run this at 10K+ warp without breaking a sweat", at least certainly not given the performance characteristics of the KSP 1 or 2 implementations, if what you mean is increasing the tick frequency while keeping a constant tick time step

I haven't looked into it, but I wouldn't be surprised if they are just ignoring the problem. What I can say at least is that I looked into other subsystem having long standing timewarp related issues in KSP 1, and they didn't address any of those in KSP 2. Indeed, running at variable timesteps will introduce incoherencies. And, no you can't just substitute numerical integration for an analytical solution. You can for some limited parts of the problem, but not for the general dependency chain of every involved subsystem, meaning you're adding more complexity, you are solving only part of the coherency problem, and in the end it might not even be much better computationally than running the numerical integration with a lower time step in the first place.

You might want to explicitly set rotation locking off in your KAL sequence. Docking ports are set to auto-lock themselves in many cases. Honestly I don't remember which ones, but KSPCF should follow stock behavior in this. Using the rotation feature in a KAL sequence doesn't actually check for the locked state, which can result in weird stuff happening. TBH, I don't recommend using the rotation feature within a KAL sequence, use regular robotic parts instead. While I did a decent pass to fix many of that feature bugs (like it simply not working at all in the editor), this is clearly something that wasn't properly implemented and tested by Squad, and I probably won't ever have the courage to go over it again.

The answer is that they didn't kept the "physics on". The only thing preventing running at arbitrary timewarp speeds with engines burning in KSP 1 is that joint/RB physics are unstable at large timesteps. There is no additional computational cost to running at large timewarp speeds. The game engine is still running at 50 ticks/second, which mean that at 1x timewarp, each tick is 1/50 = 0.02s. To accelerate time (ie, timewarp), you instead pass a higher elapsed time (the "timestep") for each tick. For example, if each tick is 0.08s, that gives you 4x timewarp. If you pass 20s, that gives you 1000x timewarp. The underlying difficulty is that whatever subsystem runs in each tick must behave consistently whatever timestep you feed it. In KSP 1, most systems are actually designed to accept that. However, RB/joint physics simulation stability is heavily timestep dependent, that's why vessels have a higher probablity of experiencing instabilities in phys-warp in KSP 1. KSP 2 isn't different in that regard, what they did is just disable physics when timewarping, and are directly summing the forces resulting from engine thrust to compute the frame displacement (ie, the vessel acceleration).

Well, as I said, please provide a save that reproduce it and I will take a look. I was just pondering that while there are cases where the oscillation issue can be a result of interactions between the SAS, it's control point and the controlled attitude control providers, the underlying root issue has very little to do with that and can be reproduced with a vessel that doesn't has any SAS nor any attitude control providers, it's an inherent instability of the physics simulation KSP uses.

To expand a bit, I'd say that changing the reference transform point (ie, "control from here") has indeed a direct effect on the SAS behavior for attitude control providers (reaction wheels, rcs, gimbals, control surfaces). The conditions for a feedback effect where the SAS enter a self-reinforcing "shake inducing" loop are indeed primarily dependent on the position of the reference transform, the general rules being that when the reference transform is far away from the attitude control providers, the refrence transform momentum has a greater chance to be in an opposite direction as the attitude control provider at any given time due to ongoing or pre-existing oscillation effects. After looking a bit into it, I'm very doubtful there is an actual bug where for a single vessel, some components would be referring to different reference transforms. However, without doing any testing, I'd say there is decent probability for the reference transform to be reset to the root part in some circumstances, like docking. And in the case of docking, it's likely the root part of the combined vessels will be located at some "far end", which might be a not-so-great place as far as the above feedback effect is concerned. The thing is, by setting manually a different reference transform, you're acting knowingly on the root issue, with all the mighty analysis power of your brain. Turning that into an algorithmic rule is likely difficult, might simply not work (the fact that you're acting manually with a delay after the feedback loop has started might play a great role in why it actually works), and is also likely to have other unwanted side effects.