TruePikachu

I was referring to that specific log because your description that accompanied the log implied the log was showing that the spam wasn't related to the persistentId, whereas I was indicating that conclusion is...errr...inconclusive. Also, the only 1.12.x log from your link that has any match for the regex /FlowGraph/ is the one from this comment, and it doesn't seem to have persistentId writes instrumented. Just to note, looking at that log excerpt, something funky looks to be going on on behalf of whatever is setting the persistentId of four different parts all to the same value. While I'd probably call it a potentially-invalid test, I don't know enough about the actual trigger for the FlowGraph message to say for sure (e.g. I don't know if it's keying a set based on identity or by persistentId, nor if it's silently discarding duplicates by the key when added to the set). The big problem is that the spam hasn't been reliably triggered by everybody for a yet-unknown reason; for instance, @zer0Kerbal doesn't appear to have had it much if at all while I've had it happen reliably. As such, the lack of FlowGraph errors in a test session isn't conclusive evidence for the change being tested being an actual fix for FlowGraph errors, but the presence of FlowGraph errors indicates that something is still wrong. This is probably my least favorite thing about the bug altogether: I'm able to reliably reproduce it, but I have neither the experience with KSP's internals nor the time to put together and learn a modding environment in order to experiment with it, all for a mod I haven't been able to use (and therefore personally gauge how valuable fixing the bug would be) because of the bug creating issues in my installs. All I can really help with is philosophical views from my own experience with bug testing, and even that's starting to stretch my patience pretty thin. Also a testing environment for already-compiled instrumented plugins, though with the rising aggression I'm not sure I can offer that anymore for my own safety.

I've only ever seen this log spam happen with SYD installed, which heavily implies SYD is doing something it shouldn't be doing. Note that even if the game is exposing a bug to the API, the mod using the API can still be considered to have a bug if it's not accounting for the game's bug in its handling of the particular API. Also note the thing SYD is doing doesn't appear to be a documented feature of the KSP API, technically making it unspecified behavior at best; it might have been convenient in older versions that it worked, but there was no guarantee it would continue to work in future versions. Your own log indicates the value was changed and there was log spam after it was changed. The fact the log spam didn't happen on the very next line after the change is inconsequential, as is the facet that it appears to have had the value written twice. Note that the following example snippet of C (which is not from KSP itself, but rather only exists to highlight the flaw in your argument) exhibits the same events that your log implies are happening, but still indicates that manually changing the persistent ID is probably not a good idea. long you_dont_see_this = 1590504603; /* Later... */ long persistentId = you_dont_see_this; /* Set the initial value */ persistentId = 3513538705; /* BUG! You shouldn't change the value */ /* Output from KSP log when the above "happens": [WRN 17:47:23.471] [ScrapYard] Part mk1pod.v2:FFF8C676 has persistentId=1590504603 and it's being changed to 3513538705. The ClassID is 49675735 and the CraftId (cid) is 4294504548. */ long some_other_memory = persistentId; /* Copy it elsewhere */ persistentId = some_other_memory; /* Copy it back, this is nop */ /* Output from KSP log when the above "happens": [WRN 17:47:24.219] [ScrapYard] Part mk1pod.v2:FFF8C676 has persistentId=3513538705 and the value (3513538705) is being written back. The ClassID is 49675735 and the CraftId (cid) is 4294504548. */ assert(persistentId == you_dont_see_this); /* Check is false because of the BUG! line above */ /* Output from KSP log when the above "happens": [ERR 17:47:24.464] [FlowGraph]: Graph already contains item! Part mk1pod.v2 with id 4294504548 [ERR 17:47:24.464] [FlowGraph]: Graph already contains item! Part mk1pod.v2 with id 4294504548 [ERR 17:47:24.522] [FlowGraph]: Graph already contains item! Part mk1pod.v2 with id 4294504548 [ERR 17:47:24.522] [FlowGraph]: Graph already contains item! Part mk1pod.v2 with id 4294504548 */ It looks like you're only looking for a bug in KSP so you can try to fix it in Recall, versus considering that SYD might be the one with the bug and KSP is working as best as it can after SYD changes something it shouldn't have.

IMO this can be accomplished solely with the PartModule that exists on instantiated parts in conjunction with the record keeping that's already being made in the mod's scenario(?) node. What purpose does maintaining the exact same persistent ID accomplish that just doing part module copies from recordkeeping doesn't? The ID is already being saved in SYD's PartModule, by the way, so write hijacking the vanilla version of it shouldn't even be necessary, exempting a state where the PartModule is strictly unavailable. Thinking about it, if the ID itself isn't the problem, maybe it changing part modules around could be? This is just a wild guess which I haven't tested in any manner (and probably can't since I don't have a dev environment nor the API experience), but considering that the state of the fully-loaded craft on the pad depends both on the vanilla .craft file mechanics and the modded SYD mechanics (or, in the editor case, vanilla part instantiation with a defaulted module versus SYD logic with modified modules coming from the savegame)... when does restoration of the PartModule state happen anyway? Right now, I'd probably experiment with removing requirements to write to the vanilla ID field; if they're not needed, we might have improved compatibility with some other mods, but if they are needed, the reason would show itself in testing. But if the same exact issue happens when the writes are removed, the writes clearly aren't the entire problem (though they could still be part of the issue). EDIT: This suggests that changing the ID is the issue; it gets changed to something new, the new value gets written back again (nop), and then spam on the part that had the ID changed. You can only say this if you provide an example where a part's ID doesn't get changed at all but it still contributes to the spam. Right now, for all we know, logic the flowgraph depends on is still referring to the older ID because it never expected the ID to change.

Just to clarify this a little bit, while you don't need standard synchronization primitives to control objects shared between coroutines (assuming this is a standard single-thread implementation), there's still a requirement for synchronization at a higher level under specific circumstances. While you only have one task interacting with a data structure at a time, and (under the context of user code execution) task execution can only be interrupted at certain points of time, certain actions performed in one context can still break an invariant or other assumption imposed by the current thing the other is doing. Using C++ as an example (mainly because I know many standard library requirements offhand), an `std::set<>::iterator` remains valid only while the original `std::set<>` is unmodified. If a task is iterating through the particular object and yields every, say, 200 iterations, but during a yield another task modifies the object, the iterator is no longer considered valid and access is undefined behavior. This is irrelevant (except in matters of execution timing) unless you have an external process or something that's modifying your program structures behind your back; all bets are off if that's the case. I agree with this assessment; while SYD's changing of the ID to something already recorded seems well-intentioned (especially considering that mods that affect parts in such a way as to give them a sort of history might be using a non-partmodule mapping keyed by ID to maintain some state), actually doing the change "might" (read: if I wrote KSP it probably would) break a class invariant. It's probably enough that the ID remains strictly constant for a part's singular journey through flight mode, without needing it to still remain the same value once the part has been recovered and built into a new craft. Under my testing procedure, at least, log spam under the editor is triggered by instantiation of a part in SYD's part inventory. You made sure you didn't run out of stored parts, right?

My reproduction steps don't even need to touch flight mode, FWIW; I can repro from strictly inside the editor, though the current repro steps use SYD's part list. I don't know if this changes your analysis, but I felt I should mention it just in case you're running under the assumption it's something that only happens when the vessel is loaded into flight mode. I've had this same personal experience, but clearly something not strictly deterministic is going on if some people can repro it but others can't using the same steps and basically the same code in play (we'll assume it's not a bug introduced by an external library to KSP's distribution) Assuming this is the problem, shouldn't SYD just wipe the cache when it changes the ID?

KSP supports coroutines, though, which while not strictly multithreading still require care to be taken in some cases. If memory serves, the vanilla ∆V calculation takes a bit of time to process, which implies it's being scheduled as a coroutine and awaited upon by the UI code to update the readout (or something similar). My current suspicion is that a data structure that the vanilla ∆V calculation transverses is being modified after the calculation coroutine starts execution but before it finishes, resulting in it reaching some nodes multiple times and then complaining about it. Normally, this can happen when editing the ship, but that seems to be smart enough to cancel the coroutine. It shouldn't be a stretch to say that differences in execution time will affect the actual ordering of coroutine execution, especially considering that coroutines that have yielded might even have the ability to work multiple times per frame, which would imply that a faster CPU could be less likely to hit the issue and a more complex craft (or slower coroutine because of decorations) could widen the window of opportunity.

Just to confirm, the Unity+KSP mod environment doesn't provide functionality to break on object variable write? I know that if this were native code, I'd be reaching for that right now, and I believe that .NET under Windows provides such support via WinDbg, but Unity is running its own VM so WinDbg can't access the C# level of things. I still have my isolated install which is getting a reliable repro, but due to neither having a debugger capable of attaching at the C# level nor being familiar with KSP's internal structure I unfortunately can't help chip away at finding the underlying culprit, beyond saying it's something between KSP and SYD. EDIT: Or wait, can't Harmony decorate KSP's methods that write the ID? Barring a debugger, I'd probably try using that to log call stacks at write, and see if anything curious shows up.

I just tested v2.2.99.1-prerelease in my isolated install and the FlowGraph issue is still present. EDIT: For completion, my reproduction steps are (with reference to this gist): Manually apply the three patches listed in the diff output in the gist Run KSP with absolutely no mods other than ScrapYard installed (no ModuleManager, no DLC) Load the savegame from the gist (the notable feature of the savegame is that it has some parts in the inventory already) Enter VAB Open logging console page Expand the parts list, switch to ScrapYard inventory Construct a rocket from the stored command pod, fuel tank, and rocket engine (don't touch the fins or parachute, the patch isn't applied for those and you'll get other log spam) Once the rocket engine is added to the rocket, a number of FlowGraph errors will come up in the log.

I'm trying to write a ModuleManager patch that removes one of the runways from "defaultRunways.cfg". However, since this otherwise-static data is being stored in `PluginData`, MM can't touch it. Additionally, the Making History runways aren't being loaded; I don't know if this has a similar cause (being in `PluginData` and not getting loaded by the game's module loader). KSP.log, Player.log

Sometimes I prefer the scientific method of driving around KSC. Anyway, direct shell launch (w/o any implied parameters) still hits flowgraph. EDIT: For the record, I'll keep that particular copy of the KSP install around (w/ the edits I made) until this issue gets worked out, so it doesn't impact my actual game (though I might symlink a bunch of identical directories in order to save space).

Steam version still (just copied somewhere else), I'll check direct shell launch in a while (not at computer right this moment, and it'll be a pain to test over phone remote desktop).

I don't think I can get pure stock to duplicate flowgraph, in that I've only gotten flowgraph when SYD is installed. I can see if removing the DLCs from the gamedata affect anything, though, as well as see what sorts of problems crop up removing MM and CC (which are listed as deps in the OP). The KSP itself is from Steam, and I've generally been launching it recently via CKAN (which I believe just invokes the x64 executable with a normal environment and no parameters; I'll verify this later, but I'm avoiding having Steam launch it because then I have to mess with the launcher etc). EDIT 1: CKAN launches KSP with just the `-single-instance` flag EDIT 2: I don't get flowgraph with just KSP+SYD, but I do get other errors because the MM patches aren't applied. I might try to manually apply them and see what happens. EDIT 3: Your Config/PartBlacklist.cfg looks like it has some extra junk from Git present in it, so you might want to make sure it has what you want EDIT 4: Yes, I very much still get flowgraph when it's just base KSP, SYD from SpaceDock, and four manually-applied part patches. E4.1: Log

I've been thinking about this a bit, and my current thoughts are: Is the FlowGraph error specifically from the unmodded game (i.e. present in the assembly), or does a mod provide it? I'd think the former, but want to be 100% sure. Unfortunately, I can't check the game right now, and GitHub doesn't support searching forks, so I can't check that SYD is providing it or not. But under the assumption SYD isn't providing it, my earlier experiment would indicate SYD is doing something weird (but we know something along these lines already). What are the specifics of your own environment @zer0Kerbal ? I'm assuming the game itself is up to date, but do you have the expansions? What OS? Have you tested with specifically the release version of SYD on GitHub, or only on development versions? In both the serialized .craft and .sfs, the persistent IDs for the parts (provided both on part root and SYD's module) match up with each other and not with those of other parts; this reflects in that loading the affected save and testing without a relaunch of the craft seems not to be triggering the issue. But, when the craft is loaded into the game onto the pad, SYD is clearly modifying the structure of the craft to handle persistent IDs (as is intended), but the full state of the craft at this point of time isn't being reflected in the serialized savegame, as a reload doesn't trigger the issue. Is the structure of the craft actually somewhat invalid as a result of SYD modifying it, but getting corrected by the serialization code?

I haven't watched it yet, and certainly won't be able to within the next 9 hours (honest this time), but: I was having difficulty with repro inside the VAB, even using what I thought was reliable repro from my earlier attempts at getting KCT going, but when I launched the log lit up and that happened to be reliable. When assembling the craft, I used alt-click duplication a lot; the upper """stage""" in my screenshots is just a flipped copy of the lower one. While I don't know if it's required, some parts are "reused" from a previous test. I don't believe I started with any reused parts when I brought it out to the pad the first time (the thing previously there at first didn't have any parts in common), but all subsequent tests on the pad used parts freshly placed in the scrapyard. I have no idea how serialization plays into it, since I don't believe the errors cropped up after a save/quit/reconfigure/reload cycle, but rather after a recover/relaunch. I can probably test repro again in my save quickly and, assuming repro, I can drop it in another gist so you can check for repro. EDIT: persistent.sfs available here. Modlist is the same as the first screenshot, and all the mods (except the particular SYD version) are on CKAN, though not all of them are listed as "compatible" with 1.12.5 (however, the worst one is compatible with 1.12.2, and their own functionality is...err...functional). Of note, there's probably a craft that uses KAS nearby the pad. EDIT 2: Just did a repro both on-pad and in-VAB with just SYD, CC, and MM installed. Uploading footage to YouTube right now, hang tight. EDIT 3: Video, log.

KSPCF deps Harmony, and I think the only thing the mod can do without it is the part manufacturer changes (which are akin to modulemanager patches). I checked the list of patches on the forum post earlier, but none stood out significantly. That said, it should be possible to do a baseline test by disabling all the patches (via config) and, assuming the FlowGraph issue doesn't recur, determine which patches are responsible. I might be able to mess around with this about 18 hours from now, if you want. EDIT: I lied. Tested around instead of going to sleep. Still got FlowGraph errors even without Harmony+KSPCF installed. Errors went away upon removing SYD. Screenshots from workflow in spoiler.