ScrapYard (et all) is being screwed by a Race Condition those origin is still unknown #67
Assignees
Labels
Comments
Lisias
added
support
|
New test session for KSP 1.4.1: Interesting findings, I will update this issue later as I have confirmation for some working theories. "Those who cannot remember the past are condemned to repeat it." - George Santayana. |
|
Test session for KSP 1.12.5 Working theories confirmed. More interesting findings to be disclose later, at my convenience. "Dude, what a fscking mess…" — Myself. EDIT: the |
Lisias
changed the title
|
Commit d7147fd adds the Diagnosing |
|
This is the results of a Test Session where the above mentioned This is what was done:
|
|
This is (more or less) the same, but when executed on KSP 1.12.5. It's interesting to note that besides finally being able to reproduce the problem, it took me some more attempts. |
|
Interesting excerpts from the 1.4.1 log: Please note the following timestamps:
|
|
Interesting excerpts from the 1.12.5 log (I took more time to reproduce the problem on this one) Please note the following timestamps:
|
|
What I detected until this moment:
I'm currently working on a deterministic way to create that "instantiation clashes" at will. |
|
There's also an ongoing discussion happening on Forum here. The reader should be able to deduce the reason I locked up this issue by visiting this link. :) |
Lisias
added
enhancement
|
This is not a support anymore, I found a bug on KSP itself. This makes it an How I will do it, I will see after I managed to detect what in hell is triggering to crafts to be instantiated in memory at the same time. |
Lisias
referenced
this issue
in zer0Kerbal/ScrapYard
May 28, 2023
|
Ah, yes!! I almost forgot to explain this! :) Okey, the commit zer0Kerbal/ScrapYard@0576f77 was a step back, besides trying to be a step ahead by using the KSP's API when possible. It's sad that this very commit started the sad sequences of events that leaded this one one line being added: However… And let's make things clear on this, the logs above proves that on ideal conditions (i.e., the Without the bug, on KSP 1.4.1 that line would just write back something that was already there. And on KSP 1.12.5, if the code would be run on OnAwake, that line would be needed because somewhere in the mean time KSP started to failing to provide the So, and again, on ideal conditions, that unhappy line should be harmless. ScrapYard is causing trouble because KSP is "changing the |
|
For the sake of fairness, it was stated that the This is fact, a fait accompli and not subject to arguing. This renders the ScrapYard code in need to be changed, that's final. I'm having a hard time trying to swallow this pill (it makes no sense in my mind), but things are how they are and I'm redoing the tests with this in mind - but my initial code (assuming it's not buggy itself) is suggesting that the If things are happening as they should, I must be able to intercept the |
|
The note to myself: there's a lot of information on Forum, move the relevant bits to this issue. |
|
Oukey, new Exploratory Tests trying to understand how things really works under's KSP's bonnet. I reinstrumented the
|
|
Now follows an except of the previous Nothing special, the Craft file: SFS file: And why I'm showing you all of this? Because the ID being logged on the LogSpam IS THE CID, not the The ordeal was misdiagnosed on Forum. The Additionally, it's a good idea to figure out what's |
|
This is the analysis of a previous KSP.log where the LogSpam was triggered: ksp.log Now the craft file: And now the SFS file: Now observe the following copy&pastes: You see? The problem is not, and never were the |
|
The [edit]: what doesn't matter, because |
|
Other than misunderstanding I reloaded that last KSP 1.4.1. savegame used, with an Now we have two copies of the same Craft on memory, one on the LaunchPad and another on the Editor: The first batch of At It's interesting to note that for a brief time, the parts FFFCCE8E and FFFCCA78 coexist in memory, with FFFCCE8E being destroyed only after FFFCCA78 is Started! These two parts have the same Note: I did not entered the Flight Scene on this session, so the packet craft on the LaunchPad was never unpacked (ie., made "alive" in memory). |
|
I did a new test on KSP 1.12.5 and the LogSpam just ceased to happen under my nose. I will save the assets here now to avoid loosing them, but I will come back later to further discuss the matter. Right now, I'm just pissed off about the matter.
M.O.:
On KSP 1.4.1, the LogSpam didn't happened a single time. On KSP 1.12.5, it happened once, and then just vanished into thin air. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
As the tittle says. On certain circumstances still to be really understood, SYD is causing the following lines to be logged on
KSP.log:It's interesting to note that:
I'm finally near the cause of the problem now. What I need to do is to find a way to screw up things again, then realise what I did to "get it fixed", and once I consistently establish a Modus Operandi, go doing Regression Tests on previous KSP versions to see what I pull from that fishing expedition. Exactly as I did on #66.
Evidences:
KSP.logof this test session.[LOG 21:32:48.736], but there's an Exception on SYD when going from Flight to Scene once. But it happened only once, apparently.EDIT
There's another possible trigger for the problem! Instead of a mysterious event in need to happen in order to make SYD to behave, it may be that a mysterious event is happening and screwing up SYD in the process.
The text was updated successfully, but these errors were encountered: