A configuration entry is missing for the 5m fairing, and we'd like to offer an unofficial workaround in the meantime until the next patch.
Close the game.
Find the following file and open it in a text editor.
"PATH\TO|\Kerbal Space Program\GameData\SquadExpansion\MakingHistory\Parts\Payload\fairingSize4.cfg"
Add the following line between the closing curly brace and node_stack_interstage01a
rescaleFactor = 1
The result should look like this
...
MODEL
{
model = Squad/Parts/Aero/fairings/AutoTruss
scale = 4,4,4
position = 0.0,0.22,0.0
}
rescaleFactor = 1
node_stack_interstage01a = 0.0, 2.17, 0.0, 0.0, -1.0, 0.0, 2
node_stack_interstage01b = 0.0, 2.27, 0.0, 0.0, 1.0, 0.0, 2
...
Save the file and the fairing shell will no longer have the gaps when used.
This is an unsupported workaround, and If you are not comfortable with editing files, then please wait until the next patch.
Hello all.
Windows 10 Defender was detecting Assembly-CSharp.dll as containing a virus. This has been found to be a false positive.
The file was being detected as having a virus on the following previous definitions
1.263.580.0
1.263.582.0
1.263.580.0 release time corresponds with the first reported cases.
Virus definition 1.263.585.0, just released, does not quarantine the file. Please be sure to update Defender's virus definitions.
Source: https://www.microsoft.com/en-us/wdsi/definitions
Results of the analysis: https://www.microsoft.com/en-us/wdsi/submission/bdea1058-efcc-4c43-8051-22cfe1139e81
Update:
If Defender continues to flag the file as containing the Critet.BS trojan, the following advice comes from the Microsoft Defender team after the file was submitted again for review.
Furthermore, you may find that a system restart is necessary to completely clear the problem
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.
Conclusion.
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.
Thank you for the information.
It is indeed, and the reason why I asked for further information rather than making assumptions. It is an unfortunate reality of Linux support - in general - and we tried very hard to fix this issue for 1.1. A further upgrade to Unity3D promises to help with this somewhat, but the real results won't be known until that occurs. If the workarounds allow KSP to be played in the meantime, then please mark this as resolved so others may benefit?
TLDR: We are aware of the problems with some driver and hardware combinations on Linux. Partial workarounds are available.
[Edit to add]
Add the -force-glcore to the start up parameters on Steam, or to the commandline otherwise.
