alecdacyczyn

Yes, that directory is owned by the user. There are no permissions issues. But I found the problem: While I was poking around in the Driver Manager, get the version number for the above post, I noticed that the "amd-microcode" part of the driver was turned off. Apparently that was installed as part of an update but is not turned on automatically. After I finished writing my post I enabled that device and restarted to see it it would make a difference. It works! At least the 32-bit version. The 64-bit binary crashed the Cinnamon environment spectacularly. Really bad. I had to Ctrl+Alt+F1 to get out of that trainwreck of corrupted GUI elements to kill the Xorg server to recover. But that's not KSP's fault. I'll have to put in a bug report to Mint. It seemed to have something to do with a screen-mode change. Never mind. It's now working and playable.

KSP Version: 1.2.1, OS: LinuxMint 18 Cinnamon x86-64, Current proprietary Nvidia driver (nvidia-367), Installed from the ZIP archive, downloaded on Dec 1st Game will not launch. I get this in console: Player.log (This is it. There is no more. It crashes pretty early) I've searched through these forums and tried all of the workarounds I could find with no discernible change in behavior, including: -Deleting the "~/.config/unity3d" folder and all its contents. -Running with "LC_ALL=C ./KSP.x86_64" -Running with "-force-glcore" or "-force-gfx-direct" -Pulseaudio is installed and running. The "pulsenomore" thingamajig has no effect. -The libs listed by "ldd KSP.x86_64" all seem to be present. - Installed 'libgl1-mesa-glx:i386' -Identical behavior running all of these attempts with both 32-bit and 64-bit executables and direct to the KSP.x86(_64) binary and through the Launcher (except for the log file producing shorter memory addresses in the stack trace, obviously). - That installer script at the top of the "Linux compatibility thread" didn't work... much. It downloaded and inflated the files fine, but then spit out a bunch of error messages. The binaries it installed produced the same results. It looks like a problem with the Mono runtime, which I've read in included by Unity; so updating my system's packages won't help. Are there any known workarounds for this issue? I suspect I'll just have to wait patiently for someone at Unity to fix the bug. Until then, I'll try to get the Windows version working through Wine.

Staging and Docking modes can be set to use the same controls; but kerbals are separate. That's where the real problem is. I hate this 'rotate to camera' nonsense. I wish kerbal jetpacks simply used full 6-axis RCS-like controls. Someone aparently thought that the current setup would make things more intuitive. They were wrong. (And I never use Docking mode. I don't see the point of it. Gimme all the controls at once.)

Yikes. Message received. In a rocket science game about delta-Vs, mass ratios, and orbital mechanics the concept of paying back your debt to Newton might boggle the poor little noobs' minds.... Everyone seems to agree that reaction wheels ought to be nerfed in some way. But the problem with simply knocking down the torque rating is the there IS a legitimate use for strong short-term torque. We need it for turning heavy ships in preparation for maneuvers, to stabilize rough landings, etc. It is not desirable to make everything sluggish (think of the last time you launched a probe and forgot to include a reaction wheel in the booster system. augh!). Down-rating is not the solution. The problem is people using their ability to produce high torque indefinitely to do things that are comically impossible. What is needed is some sort of time integral limit behavior. I think I know how I can make everyone happy. Change the Reaction Wheel module to have a saturation limit, but also an 'aether-magical' angular momentum dissipation rate. For example: Inline Reaction Wheel Torque: 20 kN∙m Saturation: 100 kN∙m∙s Dissipation: 5 kN∙m (kilonewton meter seconds... per second) So the system "remembers" how much angular momentum is being stored it it, but also "forgets" at a rate of 5 units/second and quickly returns to zero. At that rate you would NEVER even notice any difference during normal activities. However, suppose you land on a steep slope and need 13kN∙m to keep you lander upright. It would take 100/(13-5)=12.5 seconds for it to reach saturation. After it runs out of 'oomph' the output doesn't suddenly drop to zero; the Dissipation rate makes room at a rate of 5kN∙m. This would be the effective torque at saturation (along that vector, normal full power in the other direction). And once the demands on the reaction wheels are removed, the saturation level will return to zero after only 20 seconds. You would never need to think about bleeding off AM. And therefore, there is no need for a 'Spin Down' button of anything similar. If you are flying a ship that is slightly out of balance and needs only 4kN∙m to keep it stable then you could do so indefinitely because AM would be dissipated faster then it would build up. You wouldn't have to worry about it. The exact figures would needs some tweaking and balancing; but you get the picture. I think this is an ideal fix. If Squad implemented this tomorrow and didn't tell anyone an experienced player could go for weeks and never notice the change.. until they tried to use the reaction wheel kludge to force something that otherwise wouldn't work. Thoughts? [EDIT: Oh, and the realism purists could produce a trivial mod that sets the dissipation rates on everything to zero. Then you would have to bleed of builtup AM manually with RCS, etc.]

Sure, it doesn't need to be that realistic. But management of angular momentum is a key part of the operation of any real-world spacecraft. And keep in mind that five seconds of full torque is a lot of AM. I don't think you'd ever have to worry about it in normal spaceflight. This would mainly only effect things like launches, landings, and reentries. And during most spaceflight you are using gimbaled engines which have the ability to impart torque of free. Perhaps the advantage of Advanced SAS over regular SAS is that ASAS will automatically, opportunistically manage it for you in the background during engine burns.

I like the idea of the core sampler. A Mineral Analyzer like the grinder/microscope/laser/spectrum-analyzer thing that the Curiosity rover on Mars has would also great. What we really need is a good reason to build rovers (beyond just screwing around ). Currently, there is nothing that a rover can do that a stationary probe can't do equally well. Imagine a procedurally generated scattering of rock and boulders of varying composition and rarity (maybe a dozen+ different kinds). It'd give you a reason to drive around and do sciencey things.

The ISS is designed and operated to avoid building up much angular momentum in the first place. But when they do need to shed some, usually after docking maneuvers, they use little thrusters (RCS).

The Problem I know that this has been brought up before by the physics purists... The way that the reaction wheels currently work is grossly unrealistic. In the real world, inertial attitude control systems impart torque on spacecraft by spinning internal masses on the opposite direction (there's a little more to it with CMGs, but let's not complicate things). In doing so, they store angular momentum and have limits on how much they can store. There must be a way to eventually 'bleed off' that momentum or else that will become ineffective. In KSP reaction wheels don't work that way. They seem to magically grab onto the aether and apply their rated torque to the spacecraft for as long as the electricity holds out; and there is never a reckoning. Players have been long known to exploit this to build landers that can keep themselves upright on steep slopes that would have otherwise causes their top-heavy ship to tip over and to indefinitely counteract unbalanced aerodynamic forces. The Solution The coding to rectify this would actually be very simple. Each reaction wheel, and device which contains one, would have a added state variable to represent the stored angular momentum (in either Euler-angle style or quaternion style). The stored vector will obviously need to be relative to the universal coordinate system, not the ship's orientation. Whenever the part receives a signal to apply torque, either from user input (WASDQE) or from SAS, it will attempt to increase the internal stored momentum in the opposite direction and then, if this would not cause it to go over its saturation limit, it will impart torque on the vessel as normal. Parts currently have a torque rating (in kN∙m, or something) and would be given a new Angular Momentum Saturation rating (in kN∙m∙s). I think a figure of about 5x the torque rating feels about right (that is to say, it would take about five seconds of making you ship spin faster and faster before it saturates). There will only be a couple GUI functions needed. The user will of course need an indicator. Some small graphical or numerical thingy next to the SAS light would be great. It would show the total magnitude of AM stored in all reaction wheels throughout the craft. Holding the mouse over this indicator would show a breakdown of AM for the yaw, pitch and roll axes with regards to the crafts current orientation. Also a 'Spin Down' button would be incredibility handy (clicking on the indicator thingy would be intuitive, maybe a keyboard button too). The Spin Down button would directly signal all active reaction wheels apply a torque in the same rotational direction that as their AM vector. This would, through the normal physics, transfer AM from the reaction wheels to the rest of the ship (or to the ground if the ship happens to be landed and stable enough to not fall over). In addition to the Spin Down button on the NavBall instrument cluster, there should be a button on the menu that pops up when you click on the specific part (Inline RW, Control Module, etc) what would activate the function in that part alone while decoupling it from any SAS signals (uses for this below). Implications Scenario 1: In space, not spinning, with stored AM in you reaction wheels, SAS off, RCS off. Pressing the Spin Down button causes you ship to begin spinning as the AM is drained from your reaction wheels. You are now spinning like crazy. In panic, you hit the SAS. The SAS works to bring you to a stop and effectively puts that momentum right back into the reaction wheels where is started. Scenario 2: In space, not spinning, with stored AM in you reaction wheels, SAS on, RCS off. Pressing the Spin Down button doesn't cause much visible to happen. As AM is drained from the RWs, your ship begins to turn a tiny bit before the SAS detects it and dutifully tries to cancel it out with a signal to the RWs, precisely undoing the Spin Down effects. Not much happens but a loss of electric charge. You may see you ship quiver a bit as the two systems fight each other. Scenario 3: In space, not spinning, with stored AM in you reaction wheels, SAS on, RCS on this time. When RCS is turned on the signal from the SAS are routed to the RCS thrusters instead of the reaction wheels. So when you press the Spin Down button, and directly send a signal to the RWs, they will do their thing and impart torque on the craft. But this time the SAS will sense the change and fire the RCS thrusters to compensate. You bleed of excess angular momentum at the expense of monopropellent (without craziness!). Scenario 4: In a lander approaching the surface of the Mun, coming down onto a 45deg slope, reaction wheels not near saturation, SAS on, RCS off. You make contact (or at least on of you lander legs does). SAS does it's thing and uses the huge reaction wheel you brought to keep you mostly upright. But the AM indicator immediately begins climbing. Soon, it reaches saturation, your ship looses torque, and the inexorable happens: you fall over. [Perhaps it should be setup such that the loss of torque happens gradually starting around 80% saturation. But in the not-increase-saturation direction it remains 100% effective (or even better).] Scenario 5: In a lander approaching the surface of the Mun, coming down onto a sensible 15deg slope, reaction wheels not near saturation, SAS on, RCS off. You make contact. The SAS acts to dampen the rotational jolt that happens due to your imperfect landing and keeps you from falling over patheticly. The AM indicator climbs a little before you toggle off SAS and settle down gently. Once all lander legs are firmly on the surface you hit the Spin Down button. The reaction wheels transfer their stored AM to the craft. The lander is sufficiently stable and gravity is high enough that this doesn't flip you over (it's only 20% of rated torque). Whether SAS is on or not doesn't matter as you will not move significantly. You bleed off excess stored AM to the Mun through your landing legs. Scenario 6: You dock at a space station, non-zero AM in you reaction wheels. Once you are docked the two systems effectively become one. Hitting the Spin down would cause the reaction wheels in your small ship AND the big station to dissipate momentum and cause the whole conglomeration to spin. You don't want that. So, while SAS in turned on station wide, you click on your ships reaction wheel (and/or command module, etc) and click the 'Spin Down' button in its little dialogue thing. AM is transferred to the combined ship/station and SAS responds. But because SAS signals are decoupled from specific parts while using the part specific dialogue thing, the other active reaction wheels, namely the station's huge one, do all of the work to compensate. Your ship has just transferred its excess AM to the station. (If your ship has multiple RW devices then it may be nessissary to Toggle Torque on any that you don't want absorbing it instead.) Scenario 7: Great, now my station's RW is nearing saturation. What now?! Firing RCS thrusters like in Scenario 3 would work. But a better solution would be to stick pairs of xenon thrusters at the far reaches of your station pointing such that the translational effects cancel out as they impart (very weak) torque on the structure. Run these thrusters while SAS is turned on and (assuming you're running the right pair) the reaction wheels will (slowly) wind down while keeping the station steady. You send your excess angular momentum into space in the most mass efficient way possible. Misc. Scenarios: You're flying under power through an atmosphere using control surfaces or through space using a gimbaled rocket engine, stored AM in your reaction wheels, SAS on. Pressing the Spin Down button imparts torque on the craft. The SAS sees this exactly as it would torque from any other source and manipulates the control surfaces or gimbals to compensate. Conclusion The coding changes to implement this would be small and tidy and effect only the Reaction Wheel module (and a trivial bit of the GUI). Everything else, all of the above complex behaviours, will couple through and result from the physics engine (no spaghetti code flying everywhere!). It would take little time at all. I actually looked at doing this myself as a plugin. However, after much searching, suitably detailed API documentation to tell me if this is even possible through a plugin, overriding such basic functionality, remains elusive. So I'm posting this as a Suggestion. --------------------------------------------------------------- [EDIT: Reworked after forum responce. (Post from second page copied here).] Yikes. Message received. In a rocket science game about delta-Vs, mass ratios, and orbital mechanics the concept of paying back your debt to Newton might boggle the poor little noobs' minds.... Everyone seems to agree that reaction wheels ought to be nerfed in some way. But the problem with simply knocking down the torque rating is the there IS a legitimate use for strong short-term torque. We need it for turning heavy ships in preparation for maneuvers, to stabilize rough landings, etc. It is not desirable to make everything sluggish (think of the last time you launched a probe and forgot to include a reaction wheel in the booster system. augh!). Down-rating is not the solution. The problem is people using their ability to produce high torque indefinitely to do things that are comically impossible. What is needed is some sort of time integral limit behavior. I think I know how I can make everyone happy. Change the Reaction Wheel module to have a saturation limit, but also an 'aether-magical' angular momentum dissipation rate. For example: Inline Reaction Wheel Torque: 20 kN∙m Saturation: 100 kN∙m∙s Dissipation: 5 kN∙m (kilonewton meter seconds... per second) So the system "remembers" how much angular momentum is being stored it it, but also "forgets" at a rate of 5 units/second and quickly returns to zero. At that rate you would NEVER even notice any difference during normal activities. However, suppose you land on a steep slope and need 13kN∙m to keep you lander upright. It would take 100/(13-5)=12.5 seconds for it to reach saturation. After it runs out of 'oomph' the output doesn't suddenly drop to zero; the Dissipation rate makes room at a rate of 5kN∙m. This would be the effective torque at saturation (along that vector, normal full power in the other direction). And once the demands on the reaction wheels are removed, the saturation level will return to zero after only 20 seconds. You would never need to think about bleeding off AM. And therefore, there is no need for a 'Spin Down' button of anything similar. If you are flying a ship that is slightly out of balance and needs only 4kN∙m to keep it stable then you could do so indefinitely because AM would be dissipated faster then it would build up. You wouldn't have to worry about it. The exact figures would needs some tweaking and balancing; but you get the picture. I think this is an ideal fix. If Squad implemented this tomorrow and didn't tell anyone an experienced player could go for weeks and never notice the change.. until they tried to use the reaction wheel kludge to force something that otherwise wouldn't work. Thoughts?