Gotmachine

Logs are indeed needed, please upload them somewhere (dropbox, google drive...) and provide a download link. Mac OS X: Open Console, on the left side of the window there is a menu that says 'Reports'. Scroll down the list and find the one which says "Log Reports", click that. A list of files will be displayed in the top part of the window, in there will be Player.Log ( Files>~/Library/Logs>Unity>Player.log ). Right-click on it and select "Reveal in Finder".

V1.31.0 is out : New KSP bugfix : DockingPortConserveMomentum [KSP 1.12.3 - 1.12.5], make docking ports conserve momentum by averaging the acquire forces between the two ports. Thanks to @Jules-Bertholet for the contribution. DragCubeGeneration : fixed issue #154, fix broken map view (and various other issues) when a drag cube is generated on a root part having multiple drag cubes. DragCubeGeneration : fixed issue #162, fix incorrect drag cubes generated for stock procedural fairings (and potentially mods doing procedural mesh generation). DragCubeGeneration : patch enabled by default, hopefully all bugs fixed PersistentIConfigNode : adress issue #159, add some logging when an enum parsing error happens instead of swallowing it silently.

Quite the opposite. Life support needs can easily be quantified, all a player need is a decent in-game estimate. It's no different than delta-v. Thermal on the other hand is extremely situational and has a tons of hard to estimate inputs. Reentry heat depends on velocity and angle, radiator (and more generally parts) heat balance depends on sunlight/shadow and distance from the nearby stars and bodies, as well as atmospheric temperature. Heat output by various producers depends on their usage. Life support is a difficult mechanism to get right and interresting, and I'm in the camp that it's a terrible fit for KSP 2, but from a player mission planning perspective, thermal is a mess too, which is why I fully expect its KSP 2 implementation to handwave a lot of it.

As a Kerbalism dev, I'm a huge supporter of time as a core gameplay element, and LS is a major part of it. There are other gameplay loops (ISRU, crew health...) that can benefit from LS, but it's one of the two pillars of the "time isn't free" mechanism, the other one being maintenance/failures. Outside of that, LS is not a very good gameplay loop in itself. It has the inherent flaw that it's mostly a planning stage gameplay loop with punishing consequences appearing way latter and no way out for the player. This being said, I don't think any of this is relevant given the core gameplay pillars that were choosen for KSP 2. KSP 2 made the choice to zoom out and to go for a more macro simulation. The technology scope ranges from near future to science fiction. The time scales to hundred of years. The amount of concurrently active places and kerbals to hundreds. There are already a lot of design and technical difficulties when trying to put together the "time isn't free" mechanism. Even at the KSP 1 scale and scope with few concurrent active missions/places, and interplanetary (not interstellar) time scales, that mechanism inherently involve some micromanagement. Your proposition is a nice one if your goal is to get a LS thing in the game, and it's well designed given the scope and other gameplay loops of KSP 2, but I can't help to notice that it has no purpose beside a boost in science gains, which is a peripheral mechanism. You also cannot solve the issue of interstellar timescales without a magic food generator, which once available essentially defeat the whole thing. Yes there are some balance tricks that could be used, but as I see your proposition, it's an optional mechanism that doesn't add anything to how the game plays, it's just here to exist. KSP 2 made the choice to expand the scope to science-fiction territory. It certainly opened some new shiny opportunities, but by doing so it also threw away a lot of potential rooted in real-world space exploration challenges. Personnaly I think this was a mistake. What was setting KSP apart from the crowd of other space themed games is being rooted in what we can relate to in the real world.

VRAM first, then RAM when it's full.

As someone who tried to design and implement such a system for Kerbalism, this is a technically difficult feature, especially if you want to factor environmental conditions in a stable and coherent behavior, especially during timewarp. Aside from the technical difficulties, one pain point is designing proper planning tools in the VAB so the user can know how much cooling/heating will be required for the mission profile. I would suggest a simplified system like Kerbalism does : compute an analytic "average environment temperature" at the vessel position (ideally using simplified rules), get the difference between that and the "ideal" temperature, scale that diff by some measure of hab size (amount of crew seats is a decent proxy), then have : - Integrated "heater" in crewable parts consuming EC to make up for a negative scaled diff. - Radiator parts consuming EC to make up for a positive scaled diff. This would result in a stateless, vessel wide system (avoiding some timewarp related issues) that is relatively simple and predictable, as by the custom temperature evaluation can be simulated for various situations in the VAB. There is a major difficulty in the temperature evaluation if you try to account for dynamic solar occlusion (ie, time spent in shadow/eclipse), as this fundamentally won't work at mid-high timewarp speeds. Simplifying the problem to some average solar exposure has the drawback of eliminating a lot of gameplay aspects, like intentionally choosing specific orbits or locations where you are always in sunlight or in the shade of something, and proper solutions to solar exposure evaluation are quite complex and performance intensive. I would advise against any kind of interop with the "usual" KSP thermal stuff, be it general part thermodynamics, core heat or its modded replacement (SystemHeat). They are complex and finnicky systems each having specific purposes and area of application, extending or interoperating with them is hard and limiting.

I'm primarily interrested in modding in gameplay features. There is no point starting anything on that front until the core stock gameplay features like progression, science, resource chains and colonies are implemented. You can't mod what doesn't exists. I absolutely don't care about the availability of additional official modding tools/API. We already have everything we could possibly need to mod KSP 2, and I very much doubt we will ever be given anything really useful from official channels anyway.

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.