Lisias

I just realised that I have a somewhat decent notebook available for testings, so why not for gaming? So I decided to give a try for some indie developments that caught my attention lately. For sandbox and building players that loves immersion but don't care for physics, Starship EVO appears to be a dream came true! I'm also playing this new real physics one (but no building), rogue like game, Flight of Nova. Made me remind playing Elite Frontier and First Encounters. Very impressive graphics, by the way... At last, but not the least, I'm revising an old "friend", Rodina. Last time I had played it was before my KSP times, and I'm happy the developer continued to develop it!

Humm… Nice information! You probably diagnosed something on KSP! Cheers!

(sigh). I think it's time to create a KSP spin off.

The mods don't appear to be the problem, they working together may be. The signs I see in your Player.log suggest races conditions inside KSP. The problem with race conditions is that they are unpredictable, they are a mine field - everything looks fine until someone with bad luck steps on a mine. So, a rig working fine can go nuts by simply adding or changing something, because it could be the last straw that will break the camel's back - or, going back to the mine field parabola, this last change could made KSP walk slightly to the right where a mine was waiting for some to step over. A pretty clear evidence of things going down the tubes on your rig (and only in your rig) is, between many, TweakScale - and I will use it as guinea pig because I know this code pretty well (unsurprisingly :P). Please bear with me even by not understanding what follows, because my intention is to document the problem so people could reference it later. — — WARNING: GORY TECHNICAL DETAILS FOLLOWS! NOT FOR THE FAINT OF HEART! — — On your Player.log I found two entries like this one: [AddonLoader]: Instantiating addon 'TweakScaleHotKeys' from assembly 'Scale' (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35) Problem. It's sure that TweskScaleHotKeys is only instantiated once on a sane rig, because of this line on the code: [KSPAddon(KSPAddon.Startup.MainMenu, true)] internal class HotkeyManager : SingletonBehavior<HotkeyManager> { <yada yada yada> [UsedImplicitly] private new void Awake() { Log.dbg("HotkeyManager.Awake"); base.Awake(); DontDestroyOnLoad(this); // <---- THIS IS ALSO IMPORTANT This behaviour is only instantiated ONCE the first time the Main Menu is loaded (see 'True' on that KSPAddon thingy) , and it's never destroyed until KSP quits (because of the DontDestroyOnLoad thingy). Then later, I found ONE log entry for this problem: NullReferenceException: Object reference not set to an instance of an object at TweakScale.Features.ScaleChaining.DeInit () [0x00012] in <d64755e43d324177804233d3acaee766>:0 at TweakScale.TweakScaleHotKeys.OnDestroy () [0x00005] in <d64755e43d324177804233d3acaee766>:0 What's nuts, because the ScaleChaining.Deinit and the TweakScaleHotKeys.OnDestroy are correctly coded checking for things before doing anything. The only way this would happen is by the TweskScaleHotKeys being initialized TWICE in memory (what we already know it is), because after the first incarnation's OnDestroy is called, the internal data structures are destroyed and then the second one will bork for sure. Double checking my theory, I found exactly two copies of it on memory: > cat Player.log | grep "Instantiating addon 'TweakScaleHotKeys' from assembly 'Scale'" | wc -l 2 On my rigs, I only find one. This means that KSP's life cycle is completely screwed up, launching things twice and destroying things out of the order, because the ScaleChaining.DeInit always happens before the TweakScaleHotKeys.OnDestroy, unless rogue copies of the TweakScaleHotKeys are lingering on memory (and probably rogue copies of the whole TweakScale too). And, yeah, I just tried it on my rig just to be absolutely sure about it - things on my computer is happening exactly as they should. Now, I don't really know Scatterer, so I'm unsure if it is misbehaving or not, but inspecting your Player.log I found 14 times it was being instantiated: > cat Player.log | grep "Instantiating addon 'Scatterer' from assembly 'Scatterer'" | wc -l 14 And it appears to be too much, because as far as I know, this log entry: [AddonLoader]: Instantiating addon 'Scatterer' from assembly 'Scatterer' (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35) should happen only once. And this should be the reason I found this: Uploading Crash Report NullReferenceException: Object reference not set to an instance of an object at Scatterer.ScreenCopyCommandBuffer.OnDestroy () [0x00029] in <43bdde13a3a142b1913e072d4d09bd61>:0 Because, in the same way TweakScale does in your rig, it should being initialising things many times, but that thing was meant to be uninitialised only once (because it was meant to be initialise only once). — — END OF THE GORY TECHNICAL DETAILS — — So, unless new information is put on the table, we have determined that there's something on your rig causing the problem. But what? Your KSP.log tells me: OS: Windows 10 (10.0.0) 64bit CPU: 12th Gen Intel(R) Core(TM) i7-12700F (20) RAM: 16225 GPU: NVIDIA GeForce RTX 3070 (8043MB) SM: 50 (Direct3D 11.0 [level 11.1]) RT Formats: ARGB32, Depth, ARGBHalf, Shadowmap, RGB565, ARGB4444, ARGB1555, Default, ARGB2101010, DefaultHDR, ARGB64, ARGBFloat, RGFloat, RGHalf, RFloat, RHalf, R8, ARGBInt, RGInt, RInt, BG So you are using a "hybrid" CPU from Intel, with 4 Performance Cores and 8 Efficient ones. humm… I had already diagnosed that KSP (to be fair, Unity, KSP is just following suit) handles concurrency naively (stupidly is the correct word). And I had detected other things misbehaving on Intel Hybrid cores before. So I'm almost sure this is your case. The solution for you is to tell Windows to only run KSP on the 4 Performance Cores using a thingy called Affinity. I think you should apply this trick to KSP: https://www.windowsdigitals.com/how-to-set-process-cpu-affinity-priority-permanently-in-windows-10/ — — POST EDIT — — No!!! It's something on KSP!! I reproduced on my rig, and it's a punny MacPotato running i7 mobile!!!! DAMN!!!! — — POST POST EDIT — — DAMN²: I only reproduce the log "spam", not the NRE at the end of the log. It looks like the log "spam" is a false alarm - it happens all the time, no matter the add'on is going to be loaded or not… So we have a real problem (an add'on being instantiated at least more than once when they shouldn't) those diagnosing is being made harder and harsher by a false alarm on the log. (sigh) — — POST POST POST EDIT — — — Ok, I think I found what happened: on the original log, I concluded I had evidence of KSP instancing things multiple times because of the log "spam". BUT on KSP 1.4.3 I also had the log "spam", but not the NRE. And checking again my KSP 1.12.5 log, I also found the spam but not the NRE. So the log "spam" is a bug by itself. It only happened that between the thousands of false alarms, one of them ended up hitting something real. So we are back again to the multiple instancing of the TweakScaleHotManager . So it may be related to the asymmetric/hybrid CPU used by the user - still investigating other possibilities.

Before anything else, make a FULL BACKUP of the whole KSP. Not a link, not a move, be sure to do a FULL COPY. O suggest to copy the thing into your Desktop to make easier to reach the files. Then, whatever you do, you do in the copy. If things screwed, then you delete the copy and do another backup to Desktop, and then start again. I'm a maniac archivist I have backups of every single KSP gaming session I ever had (another day I fired up my old 1.4.3 one with some pretty old savegames just fo the nostalgia). I suggest you do the same. In the mean time, I'm giving a peek on your Player log. — — — I need some information to help me look on the thing with the proper mindset. Do you remember running CKAN between the last time the game worked and the first time it started to bork? If you don't use CKAN, do you remember installing something new (anything) instead? I had diagnosed rigs similar to yours without these exact Exceptions I found in your rig, I'm finding somewhat weird things that I know works breaking on your rig without apparent reason - but my suspicions goes to a direction in which the diagnosing is made by elimination, i.e., we must eliminate the known causes until what's left should be probably be caused by some of my suspicions.

The Cycle of Life is ruthless. Farewell, dear...

Can you reproduce the problem? If yes, reproduce it then quit KSP and find a file called KSP.log on the directory where your KSP executable is. Then publish it on Dropbox or something and post the link here. With a hit of luck, we will find a exception somewhere that explains this problem, and then we can try to do something about.

As usual, reproduce the problem and then quit KSP. Look for a file called KSP.log in the same place where the KSP executable is and publish it on Dropbox, googl4le drive or similar and then post the link here. With a bit of luck, the log will pinpoint what's going on.

I confirm the problem on my 1.12.5 Acceptance Test Bed. I'm not sure yet if this is a TweakScale bug, a KPS-Recall mishap or a new problem on KSP 1.12.x [it's insidious bug on TweakScale] but I will post my findings on the https://github.com/TweakScale/TweakScale/issues/307 . Thanks for the report! Cheers! — — (I felt a disturbance in the Force - as thousands of Parts suddenly had their attachment points reset after scaled…)

I understand. However, allow me to pinpoint some of what I had found: A nasty bug about AutoStruts, that gone unchecked for years and was surely the cause of a lot of misdiagnosing on 3rd party add'ons (TweakScale between them). When it strikes, it screws the craft for good. Since 1.2.2 The Editor's ReRoot feature being completely screwed from KSP 1.8.0. It essentially destroys all the radial attachemnts KSP failing to recovering Funds from PartModules implementing the IPartCostModifier. Since KSP 1.11, I think This completely screwed up any PartModule that affects the cost, as damages, recovering, TweakScale, Fuel Switches, you name it, Editor's arbitrary reset of the PartModule's values from Prefab after OnLoad, completely screwing up the PartModule life cycle and forcing modders to do shenannigans to survive the crap. Now imagine having to rewire your PartModule after the OnLoad and before the first Update, praying for it happen before the first FixedUpdate (to minimise the chances of waking the Kraken). A incredible sequence of mishaps and misfeatures plaguing the Assembly Loader/Resolver until nowadays, royally screwing up Savegames if left unchecked. Robotics being implemented in a way that screws up the part's position on the craft on saving, piling up small displacements on every save - ending up completely destroying the craft as time goes by. "Fixed" by a kludge recently, if IIRC. Similar problem affected the Docking Ports when they start to rotate. A nasty drift on Kerbals and Crafts from KSP 1.8 caused by spurious random torques (noise from the random generators, as it appears) that where never really fixed, and the kludge used to workaround the problem implemented on KSP 1.11.0 (I think) degraded as new KSP versions were released. And many more, I don't (KSP) Recall all of them now. There's a reason we have at least two different add'ons trying to fix or workaround a lot of internal KSP bugs using different shenanigans techniques. Again, I'm not exactly mad about the bugs (they happen). I'm pretty liquided about they lingering for years, some for more than half a decade, while the new features were implemented over them - what makes fixing such bugs very tricky, because you just don't know what feature become dependent of a bug being triggered or not. You never know what Kraken will unleash over you when you fix something.

People will get fired. Or sued. Or fired and then sued.

No. They bend when the joint is overstressed, and the wobble follows the internal data structure that represents the craft in memory. You are aware that now you are talking about a completely different problem? This looks more like a craft being thrown into the physics engine before being completely initialised. What's the PartModule's default for the self collision attribute? When the self collision was introduced in KSP? This problem used to happen before it? [edit] Nope, it may be related. There're more than one reason for crafts exploding on loading, as it appears.[/edit] [snip] Or under signed NDAs.

And, better yet, this very same feature was prototyped on Flight Gear! I'm unsure if the YASim would be useful on KSP2, but it can surely help with some ideas if the "bending rigid body" idea sticks. I see no reason that concept would not be more or less applicable to rockets - with some compromises. But, hell, KSP is, by itself, a huge set of compromises that end up having some kind of similarity to Real Life™ by hacking and slashing our way into the problem.

I'm afraid you lost sight about what's the cause and whats the effect. I honestly failed to understand how you misunderstood this argument as being related to wobbling at that point. I was answering this comment: And then I answered:

Post your KSP.log after reproducing the problem. It will help to find something to start the search.

[Snip] KSP uses Meters as measure and Units (about 5KG, depending of the density) as Mass [Volume!!! Mass is kilograms!]. And it was CTDing the same, It still does, by the way - they closed the Mass door, but there's something still lingering around, I don't recall right now if related to momentum (I'm guessing) or something like that.

No, you are unfortunately misinformed. The bigger (or the smaller) the magnitudes of the attributes involved on the computations, the more likely they will end up giving you Infinites or Non-A-Number in the middle of your physics engine. Believe me on this one, I was one of the guys that diagnosed KSP's CTD due physics problems back in the 1.4 era. You can really never get rid of these pesky problems, but you can mitigate them by using binary representations with better precisions (i.e., doubles are sensibly less prone to these computations mishaps than floats), but since floats are usually adopted by physics engines to allow faster net-computations inside the silicon, the sad true is that we need to carefully trim down our models to this problem, instead to the thing from Real Life© you want to simulate. If and only if each new part injected into the World are fully capable "vessels", and not only statics being thrown into the game engine. I'm not saying you are wrong, I'm saying you don't know if you are right about the matter without more information. You are misguided. Vessels on KSP use stages, do docking, hold cargo and fuel (and consume it) and a lot of things that will force you to decompose or compose different vessels into a single high level entity. How do you think we should compose and decompose these vessels? How do you think they should be implemented on the Physics Engine? Kit Bash don't have to cope with any of that. I suggest you read my posts there, I'm one of the original proposers of the idea. The thing bends under stress? Misbehaves aerodynamically if you pumps fuel to the wrong fuel tank? Things just blow up out of the blue when abused, or they visually warns you that you are abusing the frame due aerodynamic forces? If no, it's dumbed down. A RC airplane model, in essence, is a dumbed down version of the original craft. If you don't need a pilot brevet to pilot the thing, it's because the thing was dumbed down so you don't need to take years of piloting classes to pilot it. Because they do not simulate crafts made by the user. Every craft on MS Flight Simulator and X Plane were custom made by software developers, carefully trimmed and optimised to behave as specified - some of them costing more than the game itself. You are misunderstanding the problem with the effects. The excessive wobbling on KSP2 is not the root problem, it's the most obvious manifestation of the problem. We had replaced spars, spines and structural reinforcements for attachment points on a tree data structure, but we still want the thing to behave like it had spars, spines and structural reinforcements. Some abstractions will leak, some compromises are unavoidable. You move the current solution for a "lattice" physics engine for each vessel, and you will still have the same problem happening but with a different collateral effect: heavy crafts will still behave weirdly, the wobbling will be replaced by some other undesired consequence. I want my vessels to bend and ultimately fail under excessive stress - otherwise, what would be the point of KSP2? Being a gold platted Juno rip off?

You see, this is the main reason I like to talk to people that previously maintained/create any code I maintain (both on hobby as in Day Job®). There're only a few ways on doing things right, but a huge amount of other ways to do things wrong. The more I know about the later, better may chances on the former. However… My personal experience on modding KSP (and I have some reasonable knowledge since 1.2.2, as I choose to keep backwards compatibility on everything I do), is not soooo kind about the team (or at least, part of them) that took over after HarvesteR departure. There're a lot of huge, huge mistakes and bugs lingering there for almost a decade, and they failed to correct fix them - worst, they created worst bugs and unnecessary collateral effects by naively trying to tackle down some of that bugs. There're a few decisions on the thing that really made me mad over the years. I'm not complaining about bugs happening - bugs are unavoidable consequences on doing new things. I'm complaining about they not being diagnosed and/or fixed. Other thing that caught my attention is he explaining how he found the need of doing a more detailed city to play at - since the crafts would be essentially toy sized, things around should be way more detailed than if the crafts were normal sized. People are going to look at bricks, not at walls while playing! Another thing that I found pretty clever: the use of Cities: Skylines as a Scene Editor for the KitBasch's city, taking advantage of an add'on that implemented Open Street Map I think. I'll buy this game as soon as it is on sale (and the thing works on MacOS!) Take in consideration that he signed a (probably pretty nasty) NDA when he left, and I'm almost sure that NDA is still in force. So, there's a chance he was feeling exactly like that (besides I doubt Nate would be the gunner).

He probably did a lot of bad calls, and if he learnt from it, we call it "experience". And if he's able to use this experience into new projects with success, we call it "wisdom". This doesn't means that he will not make new mistakes - only that he will not repeat the old ones, and that he will probably make less new mistakes than someone else. Yes, but we need some context: that model was fine tuned to be used for a few kilograms "vessels". KSP2 will need to handle multi-stage, multi-tons and docking capable crafts. It's a problem some orders of magnitude higher than what Kit Bash had to handle. Additionally, we still have the vessel's "internal physics". How it will be modelled? Using Graphs (and so how to avoid the terrible pitfalls - do a search for the Salesman Travelling Problem)? Or the same Tree used on KSP¹ and probably on KSP2 (and then we will have the very same problems we have now, but encapsulated on a second physics engine)? It's interesting to note that @HarvesteR avoided to do a direct answer about KSP2. He wisely avoided giving an clear opinion without knowing exactly what's inside KSP2 first, besides I'm pretty sure he have a very good idea about what is going there. That said, and to avoid another unfortunate flame-fest, I'm not saying that the Kit Bash solution will not work on KSP2, I'm saying it will not be enough, and some of the current pitfalls will be reproduced on it the same, because it will be the same problems with similar solutions - unless we decide to dumb down KSP2's physics models to a RC model level (that it's perfectly fine for Kit Bash, but I doubt people are buying KSP2 to fly RC balsa airplanes on Laythe). A team is so smart (or stupid) as the guy paying their bills. Without privileged information, we can only speculate about but there must be a reason for that layoff that happened recently on P.D. What follows is pure speculation based on my own experience on the software development business: Team Leader: "We are going to rewrite the core business of the Company's Flag Ship, as maintaining it is consuming more man/hours than introducing new fetures!" 3 months later, the new components are sent to Q/A and, as any new component, get a lot of issues opened. Manager sees that as a regression, because the core components are working on PRD as is, and shut downs the [current] development, diverging developers from an other teams to code that new features, on the most "9 pregnant women will give birth 1 child a month" mentality as possible. 9 months later, no new features could be finished and all the old ones that were working started to misbehave due the huge technical debits that were accumulated not only from the older core business components, but [also] from the brute force injection of that components into the new code base after ripping off that new code that the Q/A guys flagged as regression. Looks familiar to you? Exactly. The questions he didn't answered sounded a lot louder than the ones he did. Silence can be deafening loud.

Using the cannons as RCS thrusters!

Quick Click!!!

They don't. We have this problem because we decided to replace spars, structural spines and internal reinforcements with attachment nodes glued together by a game physics engine using joints on a Tree Data Structure - but yet, we still want the thingy to behave more or less Real Life™ crafts created with spars, structural spines and internal reinforcements. We have a serious case of Leaking Abstractions here. Some compromise is unavoidable.

However, please remember the context in which he did that. KSP is launching multi staged, many-tons vessels into space (and into water too), Kit Bash is flying models with only some kilograms of mass - and they not even leave the lower atmosphere. People are not expecting to fly Balsa made RC planes on Laythe. That said, I'm not implying this solution is not the way to go. See my previous posts about.

Please read this post just a bit above yours. An unfortunate copy and paste mistake from the github's release page that I left unchecked by accident. The github's release entry was edited, by the way: https://github.com/TweakScale/Companion/releases/tag/RELEASE%2F2023.03.18 . This released was flagged as Pre-Release, and posteriorly promoted to Release after TS 2.4.7 was published. TweakScale 2.4.7 was released on March 24 : https://github.com/TweakScale/TweakScale/releases/tag/RELEASE%2F2.4.7.1 , so anyone that installed the 2023.03.18 (released on March 28 on SpaceDock) or newer didn't found any problems. And people that had read the unfortunate mishap on the change log and cared to check TweakScale would had detected that 2.4.7 was already released, and so the warning was already dated. Obviously, you didn't cared to check if TS 2.4.7 was released or not, and decided to keep ranting about it since then - as you did now, by the way. The absolute lack of checkings on CKAN is a constant source of head-aches for responsible maintainers, and you just helped me to prove this point now.

Now put the ISS on a launch pad and see what happens! I don't think we're converging into something constructive on this monologue (a discussion incurs on each other paying attention about what the other has to say), perhaps we should divert our mutual attention to something else?