Squelch

SQUAD staff
  • Content count

    182
  • Joined

  • Last visited

Community Reputation

158 Excellent

About Squelch

  • Rank
    Breaker of all the things

Profile Information

  • Interests Technology Womble, and student of W. Heath Robinson.

Recent Profile Visitors

1748 profile views
  1. Hi @Silverwood and @brian4951welcome to the forums. Persistence is another name for the saved data. This normally resides in memory during a game, and copies of that data are written to the .sfs save file. Loading a save file writes that data back into memory so that you can continue where you left off. This particular bug is caused by the data that is still in memory not being updated when the training save is loaded. The level of the buildings affects the options that are available to the player. The workaround is as the others say - Either restart the game and go straight to the training session, or load another save that has fully upgraded buildings before going to the training sessions. This bug has been reported and has been fixed in the Pre-Release version as part of our feature addition and maintenance program.
  2. We have resolved the problem and the new build of 1758 is now available on the store together with patched language files for all platforms.
  3. Hi @Blackpuma I have moved your post to the correct subforum. Please could try the latest build available from the store? If the problem persists, then please could you find your log as outlined here and upload it to a suitable file sharing portal so we can take a look into the nature of the problem?
  4. Hi @kolmansverre I have marked your self found answer as the solution. On MacOS Sierra, the security settings are more strict, and gatekeeper is blocking access to the files. By moving and then replacing these files, the filesystem now sees these as safe and does not quarantine them. This should no longer be an issue in KSP 1.2.9 on Sierra, but alas this workaround is still necessary on 1.2.2
  5. Thanks for raising this @Numerlor it has now been fixed.
  6. We have resolved the problem and the new build of 1730 is now available on the store together with patched language files for all platforms.
  7. A problem has prevented the files from being successfully uploaded to the store. Build 1730 is only available on Steam at present. We will let you know when the problem is resolved.
  8. Fantastic design, execution, and what a brilliant presentation?
  9. 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.
  10. We can neither confirm nor deny that such a feature exists. We can confirm however, that this is not a bug.
  11. Yes, they are in the settings.cfg file found in the installation root folder, towards the bottom.
  12. Well gravity does suck...allegedly Just about every sandbox game could be described as lacking something, so providing the ability to modify the game to suit individuals needs and wants is really a no brainer. Are there a set of rules that dictate what should and shouldn't be in any given game? Some of the best ones have broken any perceived conventions and are later hailed as groundbreaking. It is the territory indeed.
  13. I'm currently running Windows 10 and have used the controller with KSP previously. However, plugging in to check this issue required a driver update and reboot, so there may be something what you say. If the controller seems otherwise dead, try the following assuming that the controller is using the USB port and is wired directly. Check the controller is being detected by windows - Open Game controller settings [Typing joy.cpl into the search box or navigating the settings windows] Alternatively type devices and open the devices and printers page. With this method, the device may be shown as an unknown device named controller. Opening the properties revealed a reboot was necessary to finish installing the drivers in my case. (Windows does have a tendency to partially update some files thereby restricting any services that use them until the next reboot. This is not always conveyed to the user and can result in some functions simply failing to work). If a wireless adaptor is being used, check the driver installation for the adaptor first.. After the controller is verified as being present and functioning on the system via joy.cpl, it does appear to be recognised by KSP with all axes and buttons able to be bound.
  14. Thanks for sharing that. While the console utilities do allow the controllers to be customised, these customisations will not be reflected in the game help screens. If anyone does change their scheme, please make a note of any changes you have made, particularly if reporting problems later. Caveat emptor. Thanks for sharing that tip. A further tip is anything that would use the Mod key on the PC versions, will also use the mod buttons on the consoles more often than not.
  15. While in docking mode, the X or Square button will toggle between linear and rotational control. they can't both be used at the same time currently.