Lisias

Ah, so this is the meaning on the "Pseudo FLC" button! Thank you very much! In time, while toying with the thing, I ended up mistyping a value (ended up typing a "," instead of "." as my keyboard is PT-BR) and the damned thing gone 737 MAX (and since I use the GPWS add'on, I crashed hearing that terrifying "PULL UP" alarm! My spine is still frozen...). Well, I think I had solved this problem on the pull request https://github.com/Boris-Barboris/AtmosphereAutopilot/pull/39 . Please review it and advise any change you want me to do! Cheers!

Hi. I'm trying to use AA to automate the ascent to cruise level. To do such, on the Cruise Flight Controller I set the desired Airspeed on the Speed control, and then on Vertical motion I set a Vertical speed that keeps the throttle control at 100%, but without dropping the current Airspeed below the desired one. Rinse, repeat. Cumbersome, because I would like to have the thing doing it automatically to me, so I can focus on other things while the craft is climbing. There's a way to automate this using AA? I.e., once the aircraft reaches the target Airspeed with the throttle at 100%, the Vertical speed is gradually increased instead of the Throttle being decreased? At the same time, if the current Airspeed drops below the target, the Vertical speed is gradually decreased until the speed matches again the target. That would make my cruising missions way more comfortable! If there's no currently available option to do such, I will gladly implement it myself (and do a pull request into the mainstream) if someone could guide me in the process!

GIMP was a niche once, how in hell someone would even dream on competing with Adobe Photoshop? (GIMP 1.0 was a dog, I can tell you that - but I was locked behind Windows at that time, so perhaps my perception got tainted). Audacity, Blender (still miss Caligari TrueSpace though - a friend that used Amiga showed it to me at that times), you name it. There're a lot of "niche" projects that became incredibly successful once they gone the OSI way. Being niche is not a problem if you have "nichist" people enough around - and, believe me, KSP have it. And have it on a lot in places that most OSI projects could not even dream of. Granted, this is not synonymous of profits for KSP's IP owner - things are not that simple, they rarely are (you can't cherry-pick who are going to get interested in the project, for each value aggregating collaborator, you will have a full hand of time wasters to cope with). But the niche factor, definitively, is a positive factor for KSP: Space Faring, per se, it's a hell of niche full of very, very interesting and competent people. As was said before:

Nope, they are not. It was stated before that some bits of KSP were reused on KSP2. Every single time an unhappy soul did the misfortune of telling something like that, things backfired badly in his face. OSI people overweighted Microsoft, see SAMBA. For years Microsoft tried and tried again to actively sabotage the project, without success. Bill Gates didn't managed to do it, what to say from you? Wishful thinking is, really, the only weapon OSI detractors can use. Good luck, you surely are going to need it.

We need something to believe in.

I understand where you are willing to go, but I'm afraid this route will not lead to it. I know no professional developer, at least skilled enough to do a proper job, that would accept to sign an NDA without getting something back - some significant by the way. It would just not make sense, you would be accepting liabilities without getting anything as payback. OSI people does Pro Bono work, not "free" (as in beer) work (also known as charity) - these are two completely different things. Makes no sense doing charity work for a Commercial Company, not to mention doing it while accepting legal liability under a NDA... If I'm going to sign an NDA, I will be properly paid for it. No exceptions. BUT… There're OSI developers also working as hired guns for private companies, if this is what you are meaning - and perhaps some of them would accept the job under some other terms than money, it's not impossible. It just happens that I will not be one of them - it would make more sense for me under my legislation to just go rogue and creating an alias somewhere else and doing the job under the shady practices it's being used by some people around here. What would not make too much sense for me neither: if I'm not going to at least being credited by the work, why bothering doing it at first place? (Being credited by the work is the essence of doing OSI!) I'm afraid this baby is in need to learn to run sooner rather than later… KSP2 flatlined twice this week: The first time it happened, I ignored it because it could be a glitch on Steam Charts (it happens now and then), but another one 3 days later is pushing the glitch a bit too much, so perhaps KSP2 is really risking flatlining. Of course this relates only to Steam players, but since this is something between 50% to 70% from the current gamers in the World, we can infer the real results with some confidence. KSP(1) online players are still holding but, frankly, the current online players is about 30% of what it used to be in last December (before KSP2 being launched), less than half from June 2022 and again one third from June 2021 - a clear sign of decaying. At the same time, my time is running scarce and, frankly, the huge amount of time I need to pull white and black test cases from my hat to diagnose problems like this one is really, really discouraging. I'm blind in a crossfire, how can I be expected to hit the bandits? Perhaps, just perhaps, this huge amount of annoyances would be one of the main reasons people are fleeing the Scene? Perhaps people would be tolerating all these KSP problems because they were believing KSP2 would be better, but since KSP2 was launched in that appalling state (and, again, I firmly belive this is not a development issue, but a shoddy management's workmanship), people may be losing the hope. I surely would had lost it if I would not be a developer myself, being able to diagnose and fix a lot of KSP problems in the past. But hope don't pay the bills - we need something to believe in. My opinion is that if we are able to fix KSP and make it stable and working, people will get confidence that KSP2 will be delivered in a decent state the same.

TweakScale was allowed on WW2????

It's impressive how people in KSP ends up reproducing History without being aware. In WW2, some aircraft carriers could launch scout planes from the Hangar Deck - in a pretty kludge way, I think. But, hey, if it works, then it works. Jeb approves!

Hi! Currently, no. But I will work on it. Can't make promises about deadlines, though. These menu options are important for debugging weird misbehaviours where KSP-Recal could be influencing or causing, as it allows you to deactivate a feature on some part and not on others. But, granted, gone are the days in which I was needing to ask users to use them regularly. https://github.com/net-lisias-ksp/KSP-Recall/issues/68 Cheers!

Or some of your coroutines are yielding waiting for some external event now and then, completely screwing the order of events that you assumed while developing the code where such events weren't active by some reason. Unity makes heavy use of spinlocks while looking for some events, by the way, to the point it's impairing overall performance - see the MONO_THREADS_PER_CPU=1 stunt… What's something I should had checked before, by the way. I will work on it. Having initialization code in both OnInitialize and on OnStart seriously suggests that the original author didn't managed to accomplish what he intended deterministically by using only one of them, what again suggests that. Also, I didn't managed to suppress the LogSpam on a test bed with way less logging happening on the KSP.log (as well less KSP-Recall PartModules active). Now I need to redo the tests using only KSP 1.12.5 mimicking what 1.4.1 was running, to rule out some influence from KSP 1.4.1 internals to determine if the environment is being mangled by the logging or by the presence of additional PartModules on the affected parts - or it's just another ghost that I ended chasing. I did better. I'm logging on KSP.log when the value being written is the same and it's different from the current one. if (value != this.part.persistentId) Logging.Log( string.Format("Part {0}:{1:X} has persistentId={2} and it's being changed to {3}. The ClassID is {4} and the CraftId (cid) is {5}." , this.name, this.part.GetInstanceID(), this.part.persistentId, value, this.part.ClassID, this.part.craftID ) , Logging.LogType.WARNING ); else Logging.Log( string.Format("Part {0}:{1:X} has persistentId={2} and the value ({3}) is being written back. The ClassID is {4} and the CraftId (cid) is {5}." , this.name, this.part.GetInstanceID(), this.part.persistentId, value, this.part.ClassID, this.part.craftID ) , Logging.LogType.WARNING ); part.persistentId = value; If you are diagnosing a problem, checking only your hypothesis is… well, like being chased by Wisdom but managing to run faster. I'm not even looking on SYD yet, I'm trying to understand the persistenId behaviour because even if SYD rolls back to the previous, custom GUID system, it still need to cope with how KSP works internally after the First Great Breakage at 1.4.0. Right now, what I have on my logs is: [WRN 17:42:19.236] [Part]: Cannot have ModuleCargoPart and ModuleInventoryPart on same Part [mk1pod.v2'. Removed ModuleCargoPart [WRN 17:47:05.766] [ScrapYard] Part mk1pod.v2:FFF8C676 has persistentId=1590504603 and the value (1590504603) is being written back. The ClassID is 49675735 and the CraftId (cid) is 4294504548. [WRN 17:47:07.416] [ScrapYard] Part mk1pod.v2:FFF8C676 has persistentId=1590504603 and the value (1590504603) is being written back. The ClassID is 49675735 and the CraftId (cid) is 4294504548. [WRN 17:47:21.382] [ScrapYard] Part mk1pod.v2:FFF8C676 has persistentId=1590504603 and the value (1590504603) is being written back. The ClassID is 49675735 and the CraftId (cid) is 4294504548. [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. [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. [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 [WRN 17:47:38.707] [ScrapYard] Part mk1pod.v2:FFF7EBB6 has persistentId=1590504603 and the value (1590504603) is being written back. The ClassID is 49675735 and the CraftId (cid) is 4294504548. [WRN 17:47:38.790] [ScrapYard] Part mk1pod.v2:FFF7EBB6 has persistentId=1590504603 and the value (1590504603) is being written back. The ClassID is 49675735 and the CraftId (cid) is 4294504548. [WRN 17:47:49.979] [ScrapYard] Part mk1pod.v2:FFF7ABE0 has persistentId=4043188831 and it's being changed to 1590504603. The ClassID is 49675735 and the CraftId (cid) is 4294504548. [WRN 17:47:49.997] [ScrapYard] Part mk1pod.v2:FFF7ABE0 has persistentId=1808313221 and it's being changed to 1590504603. The ClassID is 49675735 and the CraftId (cid) is 4294504548. [WRN 17:48:41.567] [ScrapYard] Part mk1pod.v2:FFF7A77E has persistentId=33424378 and it's being changed to 1590504603. The ClassID is 49675735 and the CraftId (cid) is 4294504548. [WRN 17:48:41.580] [ScrapYard] Part mk1pod.v2:FFF7A77E has persistentId=151739214 and it's being changed to 1590504603. The ClassID is 49675735 and the CraftId (cid) is 4294504548. You see, the persistentId is being changed and not changed before the LogSpam, but also later. This log is an excerpt of a test run in which: Compile and install the HEAD of the branches above on the target KSP Fire the damned thing Create a new savegame called test-scrapyard (delete any previously existent one) Create a craft called Untitled Space Craft on VAB. Save it and then launch it into Launch Pad I used a mk1pod and a Flear SFB. Go back to KSC, leaving the craft on the Launch Pad Enter VAB Load again the Untitled Space Craft. Do it again just for the lulz Exit the game session Close KSP https://github.com/net-lisias-ksp/KSP-Recall/issues/67#issuecomment-1569102163 Note that I didn't clicked on the New button before loading the craft again. To tell you the true, I never tried this by clicking the New first, this is another test session in need to be executed. You see, changing or not changing the persistenId is not directly linked to the LogSpam, point. There's something else happening, and this is proof that we need to look somewhere else. Before the commit you linked, SYD was running on KSP 1.3.1. That commit happened after the Great Breakage of KSP 1.4.0. It's probably be the reason the changed was made, but only the original author can answer that (if they recall it, of course). What doesn't means there's none. SYD intends to enhance a part reliability by "reuse", and so it needs to keep track of each part "incarnation", so the same Part Identifier needs to be trackable between different craft instances, because from the SYD point of view, it's a part that was refurbished and used again - not to mention that firing up two equal crafts in sequence should not be counted as reusing the exact same part from the warehouse. That said, I'm not telling that this is the best way of accomplishing the task - it may be even the worst, but this is just not under discussion at this moment. It's out of the scope of this issue. What is being in dispute here is the changing of the persistentId being the trigger of the LogSpam, something that it's being refuted again and again. I agree with this assessment; We don't have evidence of that. It may be even true, but until the moment we DO NOT have evidence of this causing problems - au contraire, my last test session suggests it's harmless. Correlation does not imply causation. We need to start to look for the problem somewhere else. NOW that the persistendId is definitively out of the suspects lists, I will start to look somewhere else. Since you did some work in advance, and it made sense, I will see how to probe this new hypothesis.

I tried the latest from neistridlar (P6) on my 1.3.1 test bed, and it appears to work - but with issues: NeistAir/Parts/Structural/CurvyTail/CurvyTail NeistAir/Parts/Utility/PassengerCabins/collider On a quick test run, the parts works - but the Cabins are missing the IVA. Then I tried the latest from kerbmario (P9.1A), and it worked… And it worked too (for the most parts, at least). I tested one of the engines, and it worked - with sound, and reverse. But the CF96 have the nacelle screwed. The P6 release had it right. I think P6 is the best for you, as the engines are fine - but things may get better on the P9 series as the bugs are fixed.

It does matter. What you are failing to understand is that the LogSpam is happening when the SYD writeback is harmless (i.e, when the value being written is already there, so no change). The really interesting part is that when SYD writes back a value that ends up overwriting something different, the LogSpam does not happen. Essentially, given the current configuration on my test rig, what you are saying should not be there is, in essence, "fixing" the problem. Now, it's beyound doubt that SYD is triggering something on KSP, and it can be even SYD's fault somehow - but the code you are pinpointing as a problem, until this moment, is harmless as worst (writing back the same value has literally no practical effects), or effectively preventing the problem at best. Whatever SYD is triggering inside KSP, is not related to the persistentId being (re)written by it. We need to look for the problem somewhere else.

A coroutine, from the running code point of view, is a kind of concurrency. If you have a bunch of coroutines dealing with the same data structures, you will see the need of some kind of synchronisation the same. And you are still on a real multitask environment, your running thread will be scheduled out regularly no matter what you do, and since you just don't have control about the scheduling, you can't guarantee that whatever fickle equilibrium you manage to reach now will work as times goes by on new processors and operating systems with different scheduling algorithms. No. ScrapYard is trying hard to cope with how KSP works, it's trying to blend. It creates a new persistentId only when creating new parts for itself, a code that we don't even touched yet, as the code involved on the mess is the one on OnInitialize and OnStart. I found very interesting the need to do this twice in a raw, it looks like the Author was trying to fight a race condition, by the way: sometimes the data wasn't there yet on OnInitialize, so he tried OnStart and it works for some cases, but not for others, then he managed to pull a kludge that worked at that time, and now obviously is not working consistently anymore - I want to stress that I reached a situation in which SYD writing back the known persistentId coerced KSP into stopping the LogSpam, what may suggest that, hell, SYD is fixing something. Again, it's interesting that on my last test session, the LogSpam ceased once I caught ScrapYard writing back the persistentId. The LogSpam was being caused (on that test session) when the write back was not happening on the same test run. So, at least on my last test session, the weird situation that suppresses the LogSpam is also the one that triggers SYD into writing back the data. Further investigations are needed, however. I just learnt how to stop the LogSpam this week. Now I need to trigger it again on the same test session to see if the M.O. is consistent. I managed to stop the LogSpam by having a identical craft on the Launch Pad, and then going back to Editor and reloading the craft (even if it is was loaded automatically). On the logging I did, when SYD dos not writeback the persistentId, I have a LogSpam. When SYD does the writeback, the LogSpam doesn't happens! This evidence suggests that the write back have a reason to be. Not saying that this is the best workaround, but it is a working work around under determined circumstances. Further investigation is necessary. I did. Way more thoughtfully than yours, by the way. I managed to suppress the LogSpam, and the suppression is happening exactly when SYD writes back the persistentId. I suggest you analyse my tests and take my results into consideration.

Yes, it's possible - but it's pretty tricky to do so on a multithread environment. You set a breakpoint on a thread, then you break the chain of event in which the problem happens. I'm seriously thinking that the "vanishing LogSpam effect" is happening because I'm injecting a lot of debugging messages on the KSP.log, breaking the "timing" needed to happen to the bug be triggered. Reading the logs with the extra messages, and comparing with previous logs with less messages, my current best guess is a kind of race condition somewhere, perhaps between SYD and KSP, perhaps inside KSP and so SYD only made it more prone to happen. Interesting enough, the LogSpam ceased to happen exactly on KSP 1.12.5 where the persistentId is still 0 at OnAwake and later I flagged SYD writing a different value on persistentId (finally!!), something that it's not happening on KSP 1.4.1 where the persistentId was already initialised with the correct value at OnAwake but the LogSpam is still happening.[edit: I can't affirm that anymore. I may had screwed this specific test due biasing] Since SYD does the write back stunt on OnInitialise and also on OnStart, when by that time the persistentId usually was should be correctly initialised, in order to this to happen the other thread (or coroutine - it can be also a coroutine) appears to be getting delayed somehow (perhaps by the huge amount of log messages I'm shoving into KSP.log?) to a point in which the value is not yet initialised on the SYD's OnInitialise. Yeah… Apparently that code that writes back the persistentId is that mysterious event that should happen (or a sign that something else happened or ceased to do) in order to suppress the LogSpam on my 1.12.5 rig (and not vice versa). The current difference between my KSP 1.4.1 and 1.12.5 rigs are the huge amount of logs that 1.12.5 is configured to emit (as a log of KSP-Recall modules are active on 1.12.x, but only one or two on 1.4.1), and I'm betting this was one of the reasons I wasn't being able to reproduce the problem earlier this month, an obscene amount of logging that I reactivated in the last test session (and probably was activated early month) - I really should had preserved that logs, but since the problem was not happening on them, it didn't occurred to me. Code injection, on the Rational Purify way! Yes, it helps, and it helps a lot - as long you are not handling race conditions or unsynchronised code, because the decorators will inject also new latencies and this will change the behaviour of the test subject. But it still worths a shot, because you don't need to inject decorators everywhere, only on a very few key points and so there's a chance that it will not screw up the test. You will not be able to prove the problem is not there (due the latencies injected by the new code), but with luck you may prove the problem is there if the latencies as harmless enough and the problem is triggered. It's not too much different from what I'm doing by brute force on SYD (see my last post on the issue 67), but since we can't do the same on KSP itself, it's a nice idea. I would like to instrument the FlowGraph logspam to give more details about the part that it's already there, and the part that is being rejected as duplicated. This information will help to pinpoint where in the part's life cycle this is happening, shrinking the probable suspects to a more manageable number.

Yep, Point taken. ClassID & CraftId (cid) are different values on my savegame, and after fixing the code, things match now. SCC would be Strongly Connected Components? Anyway, I fixed the test bed and come with this after loading a craft file twice in a row (with another already lingering on the LaunchPad). [LOG 15:46:51.738] [KSP-Recall.Test.PersistentId] INFO: Part mk1pod(Clone):FFFCCE8E has persistentId=438584920 at OnAwake. The ClassID is 2480147 and the CraftId (cid) is 4294758030. [LOG 15:46:51.742] [KSP-Recall.Test.PersistentId] INFO: Part mk1pod:FFFCCE8E has persistentId=91659911 at OnLoad. The ClassID is 2480147 and the CraftId (cid) is 4294757984. [LOG 15:46:51.762] [KSP-Recall.Test.PersistentId] INFO: Part mk1pod:FFFCCE8E has persistentId=91659911 at OnInitialize. The ClassID is 2480147 and the CraftId (cid) is 4294757984. [LOG 15:46:51.768] [KSP-Recall.Test.PersistentId] INFO: Part mk1pod:FFFCCE8E has persistentId=91659911 at OnSave. The ClassID is 2480147 and the CraftId (cid) is 4294757984. [LOG 15:46:51.791] [KSP-Recall.Test.PersistentId] INFO: Part mk1pod:FFFCCE8E has persistentId=91659911 at OnStart. The ClassID is 2480147 and the CraftId (cid) is 4294757984. [LOG 15:53:56.513] [KSP-Recall.Test.PersistentId] INFO: Part mk1pod(Clone):FFFCCA78 has persistentId=438584920 at OnAwake. The ClassID is 2480147 and the CraftId (cid) is 4294756984. [LOG 15:53:56.516] [KSP-Recall.Test.PersistentId] INFO: Part mk1pod:FFFCCA78 has persistentId=631267469 at OnLoad. The ClassID is 2480147 and the CraftId (cid) is 4294757984. [LOG 15:53:56.524] [KSP-Recall.Test.PersistentId] INFO: Part mk1pod:FFFCCA78 has persistentId=631267469 at OnInitialize. The ClassID is 2480147 and the CraftId (cid) is 4294757984. [LOG 15:53:56.525] [KSP-Recall.Test.PersistentId] INFO: Part mk1pod:FFFCCA78 has persistentId=631267469 at OnSave. The ClassID is 2480147 and the CraftId (cid) is 4294757984. [LOG 15:53:56.527] [KSP-Recall.Test.PersistentId] INFO: Part mk1pod:FFFCCA78 has persistentId=631267469 at OnStart. The ClassID is 2480147 and the CraftId (cid) is 4294757984. [LOG 15:53:56.529] [KSP-Recall.Test.PersistentId] INFO: Part mk1pod:FFFCCE8E has persistentId=91659911 at OnDestroy. The ClassID is 2480147 and the CraftId (cid) is 4294757984. [LOG 15:53:59.005] [KSP-Recall.Test.PersistentId] INFO: Part mk1pod:FFFCCA78 has persistentId=631267469 at OnSave. The ClassID is 2480147 and the CraftId (cid) is 4294757984. [LOG 15:53:59.388] [KSP-Recall.Test.PersistentId] INFO: Part mk1pod:FFFCCA78 has persistentId=631267469 at OnDestroy. The ClassID is 2480147 and the CraftId (cid) is 4294757984. We have two incarnations of the mk1pod (from that omnipresent Untitled Space Craft file), the one with InstanceID FFFCCE8E and the one with FFFCCE8E . They never shared a persistentId, but the ClassId and the CraftID are the same for both of them on this test run. The one interesting thing I noted is that for a brief moment, from [LOG 15:53:56.513] to [LOG 15:53:56.529], both parts are alive in memory - with the FFFCCE8E being destroyed after FFFCCA78 being started. If these parts are used to populate and depopulate some internal data structures, we have a situation in which the new part's OnAwake, OnLoad, OnInitialize and OnStart have to live with a dying previous incarnation still in memory and, so, yet on that data structures. If by any reason the new Part ends up sharing the same persistentId from the previous incarnation, we have a Window of Opportunity for the LogSpam be triggered. Worst, probably the new part will not be registered on these Data Structures and left orphan - and this opens a whole new can of worms inside the game. So, yeah, I think we may have identified where the problem may be happening - as long someone screws up the persistentId. Problem - until now, none of my logs even remotely suggests that ScrapYard is changing the persistenId of the part until the moment the LogSpam happens! I had instrumented the suspect code to yell when it would change the current this.part.persistentId with a new value, and that code remained silent for the whole ordeal - and, again, I recently had reached some mysterious event (and i don't have the slightest idea what it would be yet) in which the LogSpam just doesn't happens, sometimes on the same test session where the damned thing was happening half a hour [5 minutes!!!] ago. Not to mention early May where the problem just didn't happened no matter what I did!!! My (current) conclusion is that, until new information is gathered somehow, ScrapYard is not directly involved on this persistentId mess (at least, until the first batch of LogSpam happens). Assuming, of course, that the problem is really related to the persistentId and not something else. The LogSpam mentioning the cid is, well, unfortunate because this test session just proved that a rogue Part can share the same cid with a genuine one and, so, we need to figure out by inference what would be the part screwing up things on the SCC graph. Logging the instanceId would be better IMHO. Now, with a way better understanding of the current mechanics, my next task will be redo the same tests but with the instrumented ScrapYard installed too, and then redo the same analysis again and see what changes - while hopping to the LogSpam to do not vanish again, of course. So we have a definitive source for the trigger of this problem. Well, this helps to reduce possible targets - the persistentId needs to be involved on the mess somehow. — — POST EDIT — — It happened again. The LogSpam happened ONCE, and then just vanished from the log. Forum rules prevent me to further express my thoughts at this moment. I'm documenting this test session the most Forum Friendly I can at this moment at https://github.com/net-lisias-ksp/KSP-Recall/issues/67

Real Life™ and Day Job® teamed up these last days, could only came back to this today! But that, IMHO, will not be accomplished by using only Open Source craftsmanship - if they are planning to do that, they will need to rely on professional craftsmanship - there's a lot of internal gobbledygook on a Company that, really, no one is going to do voluntarily. So, long term (professional level) support is not something that can be used to support our proposal, I think. Granted, the fruits they would gather by opening the access to the Source will surely be reusable on such endeavour - exactly like the current Open Source add'ons available today can be - if not in code, in lessons learned at worst. So, it's not an argument against our proposal neither. Right now, I will settle to a Shared Source style (like Unity does) access to the Source Code! Not that I consider that ideal - far from it, both sides will "fail to gain" a lot of benefits by using a half-baked Open Shared Source license, but frankly things doesn't happens in a snap, they took time to develop… Having access to the Source today doesn't not means pull requests happening tomorrow, what to say the whole shebang needed for a truly OSI project. Some people thinks that "Open Source" is like summoning your Patron on a Harry Potter movie: it's enough to say some gibberish and then a Magical Entity will come from nowhere and save the day. Knowing how short sighted some managers can be (what's not necessarily a bad thing, depending on how things are developing: if your plane is going to crash, who cares if you trashed the engines while securing a safe landing?), using what we already are able to do on the bargain table is way more persuasive than whatever we may be able to do. Once we have published material, worthy of being merged, around, they will have tangible reasons to go OSI (or, at least, a somewhat more permissive license than "Shared"), not to mention getting the time to build up the whole infra-structure to support an OSI model of development in the mean time. Someone needs to run that show. From a business point of view, going OSI when you are not going to be able to get the benefits of it will erode your part of the bargain and, so, makes the move less attractive than any other alternative that could bring you some short term benefit. We will not manage to get our part of this bargain without securing them theirs too. Me too. And I want to add, the most in need situation too, see my most recent posts at this moment. KSP has painted itself into a corner, and we are unable to help from where we are now. We need to build some bridges and, IMHO, right now. Not only public, but also some organisations and even agencies. I have this weird feeling that KSP would get concrete and direct help even from some space agencies, you know? I could not agree more. I'm unsure if we can, because both issues are intrinsically related when we are talking about licenses. First, they need to decide what model of Open/Shared Source they are willing to pursue now. OSI? Unity style? Another one, like Microsoft? Without this decision, there's no point on discussing legal issues, because these legal issues are 250% dependant of the model they want to go. I'm in the bitter duty to inform you that you are going to the wrong path, already headed to a dead end. It's not the interest of T2 to hurt sales (from both KSP and KSP2), point. There's absolutely no evidence until this moment that opening the Source (and only the Source) of KSP will hurt their sales, what we have until this moment is exactly the opposite, some examples on how opening the Source can improve the sales by side effect. Granted, there's no certainty of success neither - as everything you do (or don't), things can go south. They need to measure pros and cons of opening the source on a shared model; on a truly OSI model; or just forget about and keep things as they are now. We have strong evidences that keeping things are they are now appears to lead to less than desirable results on the short term, with some historical evidences suggesting the same for the medium term. On the long term, I don't think we will be able to do even an educated guess, because these would involve T2's business strategies that they definitively will not share to anyone. On a personal note, I don't think KSP2 will flop due technical issues, I'm pretty confident that the dev team is more than capable of delivering it, as long they have sufficient resources (time included) to accomplish the tasks. I think its obvious that keeping the franchise alive and kicking in the mean time is a very decent and effective way to secure resources for KSP2's development, and IMHO opening the Source (and only the Source, even in a restrictive way) is a viable way to secure interest into the franchise on the short and medium term. My opinion about it is that after KSP2 is finished, there will be little to no point on releasing KSP's Source, as I don't think P.D. would be able to harvester any concrete benefits from it. It will be a nice P/R stunt, no doubt, and some people will get beneficed for sure - but what P.D. or T2 would gain from it at that point? Where is the aggregating value on opening KSP source when there will be little to no interest on it anymore? Right now, we have real and immediate benefits on opening KSP's Source, even under a restrictive license: tackling down bugs that are plaguing the game and improving the existing Add'Ons, keeping the public interest high enough to even sell some additional KSP copies (as expecting KSP2 to sell right now is, well, somewhat wishful thinking) - as well gathering knowledge and lessons learned that may be of interest even for the KSP2 team.

Should, but it's doing it? And how? KSP predates all this stuff, so any protocol to communicate the system the best way to be handled just isn't there, and so ITD will need to: Guess Use a lookup table to decide So it appears Windows users need to read some Intel documentation to be sure. I don't have any machine with this e/p cores stunt* so I just can't help on this one. *well, I have… my Android mobile, but I doubt it will be of help.

BREAKING NEWS. I just got evidence that the problem is not and never was the persistentId. What we have is a collision on a thingy called cid (or ClassID CraftId) on the part. First, I determined that the cid thingy is not changing with the PersistenId: [LOG 18:41:57.873] [KSP-Recall.Test.PersistentId] INFO: Part mk1pod(Clone):FFFC2988 has persistentId=91659911 at OnAwake. The cid is 2480147. [LOG 18:41:57.875] [KSP-Recall.Test.PersistentId] INFO: Part mk1pod:FFFC2988 has persistentId=91659911 at OnLoad. The cid is 2480147. [LOG 18:41:57.884] [KSP-Recall.Test.PersistentId] INFO: Part mk1pod:FFFC2988 has persistentId=91659911 at OnInitialize. The cid is 2480147. [LOG 18:41:57.885] [KSP-Recall.Test.PersistentId] INFO: Part mk1pod:FFFC2988 has persistentId=91659911 at OnSave. The cid is 2480147. [LOG 18:41:57.886] [KSP-Recall.Test.PersistentId] INFO: Part mk1pod:FFFC2988 has persistentId=91659911 at OnStart. The cid is 2480147. [LOG 18:42:45.857] [KSP-Recall.Test.PersistentId] INFO: Part mk1pod(Clone):FFFC10FC has persistentId=2366749665 at OnAwake. The cid is 2480147. [LOG 18:42:45.861] [KSP-Recall.Test.PersistentId] INFO: Part mk1pod:FFFC10FC has persistentId=1795537535 at OnLoad. The cid is 2480147. [LOG 18:42:45.871] [KSP-Recall.Test.PersistentId] INFO: Part mk1pod:FFFC10FC has persistentId=1795537535 at OnInitialize. The cid is 2480147. [LOG 18:42:45.871] [KSP-Recall.Test.PersistentId] INFO: Part mk1pod:FFFC10FC has persistentId=1795537535 at OnSave. The cid is 2480147. [LOG 18:42:45.874] [KSP-Recall.Test.PersistentId] INFO: Part mk1pod:FFFC10FC has persistentId=1795537535 at OnStart. The cid is 2480147. [LOG 18:42:45.876] [KSP-Recall.Test.PersistentId] INFO: Part mk1pod:FFFC2988 has persistentId=91659911 at OnDestroy. The cid is 2480147. And later I realised that the FlowGraph's LogSpam is complaining bout the cid, not the persistentId!! LOG 01:54:36.612] [UIMasterController]: ShowUI [ERR 01:54:36.714] [FlowGraph]: Graph already contains item! Part mk1pod.v2 with id 4294401494 [ERR 01:54:36.714] [FlowGraph]: Graph already contains item! Part mk1pod.v2 with id 4294401494 --- Craft File PART { part = mk1pod.v2_4294401494 <--- here! The cid is the number after the underscore! partName = Part persistentId = 1768470123 --- SFS file PART { name = mk1pod.v2 cid = 4294401494 <--- here! uid = 3987364613 mid = 1624790515 persistentId = 1935682175 launchID = 1 I've been chasing ghosts until the moment, there's nothing wrong on the persistentId handling by ScrapYard, as it appears. Unfortunately, the ClassID is not properly documented on the KSP's API. Details on KSP-Recall Issue 67. And. again, there's still that test session I have documented on the Issue 67 where the LogSpam suddenly stopped and didn't came back until rebooting the game, not to mention the whole week late April, early May, where I was trying to reproduce the damned thing and just could not!

This is fait accompli, so I have no other choice but to accept it and keep walking. It doesn't really matter if it makes sense to me or not - so I'll silently complain about the subject to myself from now on. So this is how things happens on the log now, on a ideal Scenario where: A single craft called "Untitled Space Craft" exists on the VAB folder Let's focus only on the root part, mk1pod An instance was previously launched and left on the Launch Pad Editor is launched, and the previously loaded craft file is loaded automatically And it's the same one that is on the LaunchPad now There's a PartModule called KSP-Recall.Test.PersistentId on each Part those only reason of existence is to log which phase of its life cycle it is at the moment. This is how I know what's being called below. This is the sequence of events I'm getting: Part mk1pod(Clone) is created, an InstanceId is given, the OnAwake is called. The persistentId is loaded from the Craft File on KSP 1.4.1, and it's zero on KSP 1.12.5 Part mk1pod (it was renamed in the process), with the same instanceId from the last step, have its OnLoad called. The persistentId was changed (as I have the same craft already on the LaunchPad) Part mk1pod, with the same InstanceID and same persistentId from the last step, have its OnInitialize() called. "Untitled Space Craft loaded!" is logged Part mk1pod, with the same InstanceID and same persistentId from the last step, have its OnSave() called. Part mk1pod, with the same InstanceID and same persistentId from the last step, have its OnStart() called. "Autogen thumbnail" is logged. Oukey, things make sense and it's exactly what you are telling it is. The reason I'm wasting Forum's bandwidth with this information is because there's only 4 situations in which the persistentId from the part could be being overwritten on ScrapYard: on OnInitialize() on OnStart() on a button click handler on a method called MakeFresh() that it's called every time a new "handled" part is created (as in PartModule.OnCopy). this one uses FlightGlobals.CheckPartpersistentId(0, part, false, true) to get the new persistentId. I'm not arguing with you about unnecessarily writing back values into the Part.persistentId being bad. It is, and this will be fixed. Point. However, and this is the point in which I think ScrapYard is more of a messenger than a perpetrator (at best, an involuntary accomplice) is that from that 4 situations above, two will just write back a value that is already there (the OnStart and OnInitialize), so no harm can be possibly done and a third is not called unless the user clicks on something inside the ScrapYard's Window, and none of us had done it on our tests. The remaining option is the MakeFresh() method, that so would generate a new persistentId for this current part that should be remembered, and so should be really written on the current Part's persistentId if it's not there yet (or at least it's what I'm understanding of this code). It worths to mention that FlightGlobals.CheckPartpersistentId calls GameEvents.onPartPersistentIdChanged if a new persistentId is issued (and it probably always is, as the persistentId argument given is 0). This may be a mistake, or perhaps not. But the real problem I'm dealing is that the [FlowGraph] LogSpam was not happening earlier this month when I spent a whole week bashing my sorry SAS on the matter, except a couple times when I was using a savegame provided by a user that reported the problem. More interesting yet, once I quit to the Main Menu and reloaded it (i.e., had written the SFS file, and then loaded it again), the problem ceased to happen - I didn't even restarted KSP. And after this, I just couldn't reproduce the LogSpam no matter what (using that savegame or new ones). And the user had KSPCF installed, while I had not. This last Friday was the first time ever I could easily reproduce the LogSpam, and using a savegame that I just created on my rig that never had KSPCF installed. So, yeah, on this last Friday I could rule out KSPCF from this equation, but not before. But we still have this weird misbehaviour on the wild, and now I have concrete evidences that there's something that need to happen and nowadays most of the time it's not (or something that shouldn't, but nowadays is constantly happening) that suddenly makes the LogSpam to cease in the very same rig and savegame where the damned thing was happening half an hour before. All we can do now is to suppress the LogSpam on ScrapYard, but whatever is happening under the bonnet, will still keep happening - it only will not be logged on the KSP.log by something triggered by ScrapYard. And I want to diagnose it, because it may explain some other pretty weird happenings I'm getting sometimes (as some PartModules giving me the finger after a Restart to Launch).

However I caught the thing happening when there's no craft alive in the game. There's a race condition happening somewhere, being triggered by something I'm still trying to determine. Additionally, and this is yet another problem, from KSP 1.4.1 to some release I didn't cared to check yet, the persistedId was being already initialised when the PartModule.OnAwake()** is called, but from some point (I checked only KSP 1.12.5 at this time) that attribute started to be still 0 on the OnAwake, and anyone relying on the previous behaviour would be caught with its pants down. ** NOTE: Not necessarily. Since I'm loading and reloading the damned thing consecutively, there's a chance that the part.persistentId that I'm interpreting as being already initialised is, in true, an unitiiliased data from a previous PartModule incarnation that by <insert your non forum compliant favourite expletive here> "luck" ended up being relocated to a new PartModule by some really, really, really less than ideal memory allocation algorithm. But this is still Unity, with a butchered GC from a old Mono's release. I can't say this is impossible. ** NOTE AGAIN: If it would be a left over from a previous incarnation, the KSP.log's first logged occurrence from the part's persistentId would be zero or a random value. I just confirmed that the first logged occurrence of a persistentId had already the correct value, so this is really the right value read from the Craft File on memory and, so, this value is already known before calling the OnAwake() and could be had checked and fixed by KSP at that time. Could, but as it appears, it was not. With the due respect, unless further information suggesting otherwise is provided, this sounds like an ugly kludge to me. See, at least on the initial implementation (probably on 1.4.0, but I only checked 1.4.1 to this moment), the persistentId was already initialised correctly on PartModule.OnAwake(). Any clash on the a unique identifier should be already be known before OnWake(), after all the code was able to had fetched it from the Craft File at this point and so could had verified and fixed any collision with an existent part before calling the PartModule's OnAwake() - by doing this way, we would not had to cope with a mutating persistentId at all. I fail to see the need for this callback, but this ship has already sailed - we need to cope with it as it is right now. It will be interesting to see how this GameEvent will behave on my Test Bed where I can trigger the race condition I diagnosed above - once I determine exactly how to deterministically reproduce it, because at this time besides having a hunch about how to trigger it, it's still a try and try again until "success" process. At that time it didn't caused any (observable) issues (as long KSP would be behaving). It worked at that time, it only happens that it didn't aged very well as KSP was being developed with further features (and bugs) being introduced. You did found something on KSP, see this post (and also this one) on my issue tracker. [Kraken knows how many times I fell on similar traps over the years - you are not alone on this] — — EDIT — — Additionally, @magico13, this post essentially exempt you from any wrongdoing. That piece of code is a bit cheesy for today's standards but it was not causing any harm. The need to initialise the internal structures twice, on on OnStart and another on OnInitiaze, may also be seen as redundant, but my experience on KSP taught me that sometimes redundant code is a last measure attempt to work around an undiagnosed situation. Since I didn't reproduced such situation on a clean up KSP instalment, I'm guessing that you were probably fighting a unhappy interaction with a 3rd party code - a not so uncommon occurrence even nowadays.

TL;DR: People are shooting the messenger. ScrapYard got bitten by a(nother) KSP's Editor [not only, see below] bug in 2018 when KSP 1.4.x happened (I reproduced it on 1.4.1 at least). The ScrapYard's workaround worked at the time, but aged badly. On this, there's no doubt. But the problem that affected ScrapYard is still happening on KSP 1.12.5, so the underlining problem will persist. It's a viable workaround for ScrapYard, but it will not fix the underlining problem. There's a bug on KSP's Editor. Yeah, another one. Confirmed to be happening since KSP 1.4.1, and it's, obviously, plaguing KSP 1.12.5 too - so I'm assuming everything between is also affected. [KRAP! Just found another situation where it happened, Editor is one of the triggers of the problem, but not the only one!!!!] The sad true is that the persistentId is not persistent at all. Editor is changing this value now and then under conditions still to be determined, but that at least today were happening regularly (but not every time) on a minimalistic Test Rig without ScrapYard installed, completely ruling it out of the ordeal. The previous Maintainer had detected the misbehaviour for sure, but didn't figured out exactly what's happening and tried a work around that worked fine at that moment, bug aged badly as KSP was further developed. I would recommend to anyone willing to put themselves on the position of having the whole scene relying in your work to please consider that Authors don't do things just because, even that it may look stupid years later (for the sake of honesty, this includes me). KSP has a history, a long history, and trying to diagnosing anything related to KSP without taking such a history in consideration is by itself a stupid move at best, and an insult to people that are around here for ages at worst. We should be aware at this time that we are all on the same damned boat, and there's no place for a Author that it's putting itself on the Critical Path of the whole scene to just "don't care about anything but its own work". It was exactly the mistake I had made early this month, but by <insert your favorite non forum compliant expletive here> "luck", I got stuck on the opposite result. This is not a simple bug on a code. It's a complex and unhappy interaction between codes superficially correct, but that are in a bad relationship between them. I'm documenting the findings on https://github.com/net-lisias-ksp/KSP-Recall/issues/67

Oh, well.. Got screwed again! The unhappy author had linked his source: https://www.polygon.com/features/2014/1/27/5338438/kerbal-space-program#:~:text=Doug Ellison works,on our adventure." From having NASA employees playing regularly (including the article writer) and late teaming up with Squad to promote a mission, yeah, prototyping missions on KSP is too much of a stretch. Some more years and I will try again!

I was vindicated! NASA, indeed, uses KSP for prototyping ideas!! Nope, got screwed again! https://scifi.radio/2023/01/06/nasa-using-kerbal-space-program-for-virtual-experiments/

No, it was not. I have right now a setup where the problem is not happening. #67. [snip] Again, I want to refer to KSP-Recall's #27 and #66: what is now known as bugs on the AutoStrut (since 1.2.2) and on the ReRoot (since 1.8.0) were being attributed to TweakScale for years merely because only TweakScale was being used on the machine when the user got screwed by these bugs. It could be TS? Of course it could, and that's the reason I spent so many man/months trying to find something on TS. But in the end, it was not. Exactly why do you are so sure this is not happening again right now? [snip] if it would be so easy to reproduce the problem as it's happening now, @zer0Kerbalwould had already acknowledged the problem since the first occurrence, not to mention I would had reproduced it from late last month and early this one when I caught and diagnosed #66. And I want to say it again: for a whole week, from April 26 to May 6 (more or less), I was using all my free time (about 4 to 5 hours per day) pursuing this problem without success, where the only situation in which I reproduced the problem was by loading a savegame from the one of the users that was kindly enough to not only report the problem, but provided us with all the material we had asked. And that rig had KSPCF installed where my rig did not. Yesterday, May 26 Friday, was the first time a savegame created on my rig manifested the problem. [snip] I ruled out an influence of MM, because on my rig changing between Forum and my own Fork didn't affected the results. (yeah, it crossed my mind too) [edit] Unless MM (or ScrapYard) would be running more than once in memory, as it had happened before with MM (Forum) under special circumstances. Long shot, but it worths checking. Thanks for the insight! [edit2] Nope, I just ruled out again MM (no matter which one), and the "double threading" hypothesis, besides still possible, appears to do not be causing the LogSpam neither (besides, hypothetically, being a possible explanation for some double logging I found). Contract Configurator is not needed, the rig I used yesterday (where the problem was finally consistently reproduced by the first time) doesn't had it installed. Remove ScrapYard_ContractConfigurator.dll from the Plugins folder and you are good to go - the less things installed you have, more easier is to zero in into the target.

Anyone willing to play LEGO? https://www.space.com/lego-astronauts-fly-to-near-space-video