Jump to content
  • 0

Are you going to fix this?



I reported this months ago.


Squelch from QA acknowledged that there was something wrong but still did not confirm that it was a bug.

Quote "Thanks for reporting this. There is certainly something not right here, and there appears to be log entries that haven't been seen before in any tests, or indeed other reports, so this could well be an edge case.
Could you please upload a pre-dock save to aid in debugging what happens with the vessel identifiers? "

I gave all the data required.

If I load the save in Linux or Windows it is still broken so it isn't OS specific.

As the BugTracker is run by QA I have to wonder if the devs are even aware of this bug.

I think I have been patient long enough.

How about a response from a Dev?

Link to comment
Share on other sites

1 answer to this question

Recommended Posts

  • 3

Hello @Daveroski,

We have a triage system on our bug tracker. Each report is reviewed, verified, and checked against other similar reports or known issues. The report is then prioritised based on that information. I replied to your report when you first made it, and asked for more information, and you kindly provided us with that information. As I remarked back then, this seems to be an edge case (something that is rare or hard to reproduce) and your report was placed in the queue for further investigation, but with a low priority due to the difficulty of reproduction and rarity of occurrence. We do not ignore bugs, but have only so many resources available to us to deal with every one. I'm sorry if it appears that nothing has been done.

I have spent some time specifically looking at your issue, both then, in the intervening period, and again more recently. Yes the savegame certainly exhibits a problem, and it is not a nice one, but it is unique and very difficult to reproduce. A savegame alone does not constitute a full reproduction. There are an infinite number of variables involved in a sandbox game such as ours, and any confluence of circumstances can bring about behaviour that might not be expected. That sometimes is rather unpleasant when hours have been spent getting to that point, but it is a regrettable possibility.


To the issue.

The game engine that we use (Unity3D) allows flexible joints. These can also be joined together and we use that ability in the construction of craft. The joints are never fully rigid, and there will always be a small amount of flexibility even when they have been constrained. KSP is (in)famous for wobbly rockets and many steps have been taken to successfully stiffen large constructions in recent releases. There is still some flexibility in all joints, and this has been kept as a design decision to simulate the natural non rigidity found in every day life. It is also part of the destruction system, and KSP is equally famous for things blowing up. However, when joints are close to each other, they can sometimes interact and cause mutual oscillation (they fight against each other) and this can increase in amplitude to the point where the assembly will destroy itself. This is what I believe is happening with your particular craft. We are aware of some assemblies that oscillate in this way, particularly where several joints converge close together. This is also a well talked about point on the Unity website. A quick search for "Unity joint wobble" should reveal a myriad of questions and offered solutions. We have tried them all, but none have worked without severely restricting other parts of KSP. It is an inherent part of the game engine.

We do have a device that helps - Struts - They serve to stiffen the joints when placed appropriately. In engineering, the triangle is known for its strength, so attaching struts so they complete a triangle is often the best strategy. However, a triangle only acts in one plane. A real world analogy might be a shelf bracket, it forms a triangle with the wall to support the shelf. It works best in the vertical plane. It is not so strong in the horizontal plane and can easily be moved in this direction. To gain the best advantage of the triangle structure, a placement of more than one, and in more than one plane will give the strongest assemblies.


Your vessel.

I have looked long and hard at your vessel both in the save and the craft file. The savegame vessel destroys itself in quick order when loaded. I have extracted the vessel from the save and loaded it independently. It still destroys itself. I have reduced the craft file so that only the final stage (the miner) is left, and this appears to be stable. Both the extracted vessel and the original craft file look identical. I then reduced the problem vessel down to the bare minimum that still showed the problem. The craft file was also reduced to the same level, and the two files were compared. The differences are minor, but there are some very small differences between joint locations in the two craft. This comes about when two vessels are decoupled from each other, and they are both effectively rebuilt at that point. The very small and unavoidable differences that are introduced when this happens are not normally a problem. However, this insignificant position difference combined with joint wobble is the enemy in my opinion.

Your miner craft has eight legs radially attached. You have attached two struts to tie each of the ore tanks to the central fuel tank. This completes a triangle in the vertical plane. This is much like the shelf bracket example. There is no secondary strut to tie the legs together in the horizontal plane. The instabilities talked about previously are not always immediately apparent, and it may take the smallest impulse to trigger them when combined with structural weakness or a small change in position. I have only managed to trigger the instability in the craft file once in 30 decouples and reloads. The simple modification of taking one of the struts that tie the ore tanks in the vertical plane, and re-attaching so the ore tanks are tied to each other in the horizontal plane immediately solves the shake and the vessel is safe.



This particular craft has been an unlucky casualty of a combination of circumstances. It is rare, and incredibly hard to reproduce reliably in recent releases of KSP. That does not make it any easier to bear after you have invested time and effort. However, there is little that can be done to prevent this from happening from our development perspective and due to the rarity of it's occurrence, it would be hard to justify the effort involved.

Physics is both the cause and the solution. The cause, because there is weakness in the horizontal plane which is an invite to the oscillation problem inherent in the game engine. The solution, because it takes just a simple strut to add that horizontal strength and therefore prevents the oscillations. History is full of accidents and disasters caused by the simplest of design oversights combined with unforeseen circumstances.


Link to comment
Share on other sites

This topic is now closed to further replies.

  • Create New...