StarStryder

Most of the time, everything is fine. Sometimes, with no pattern that I've noticed, I'll start to get one or more of the controls receiving phantom input. The current example of this that prompted this post is full left roll being applied. I do have the Advanced Fly-by Wire mod installed. I have all of its configurations disabled. I have no controls other than keyboard and mouse connected to my computer. While testing, it also started to apply a little bit of right yaw, not full application as with the roll. Warping zero's the control input, but the full lock re-applies when warp is stopped. While in physics warp, all 3 axes are floating about the centre randomly. After leaving physics warp, I now have roll (left) and pitch (down) fully applied and yaw (left) is slightly applied. Not had these issues before updating to v1.11 Quicksave/Quickload seems to stop the problem. It's not a trim issue. Mod+X doesn't affect it. If I manually trim then the control indicator re-centres, trims as normal and then returns to the fully applied position. The quickload solution means that this isn't completely fatal to my game play experience, but there's a clearly something going on here. Any thoughts or ideas? Installed mods:

Firstly, let me say thankyou. I played with the original version of this mod a few years and never got it to work properly. It just seemed that Linux was generally a bit unsupported. Such a pleasure to see someone taking the effort to support all players. And, I have to say, this version is a vast improvement. Works straight out of the box...well, mostly. https://github.com/linuxgurugamer/ksp-advanced-flybywire/issues/28 Also, there doesn't appear to be a way to assign a button to the mouse left click. The only reason I noticed is the BD Armoury uses that for the trigger, which I'd like to assign to the stick trigger. Is this a bug, or just a limitation?

ok, so I found somewhere saying that you choose platform support at installation so I had a hunt through AUR (I'm running Manjaro) and found a unity-editor-windows package for the version of Unity I have installed. I shutdown Unity, installed the Windows support package and started Unity up again. Same error. I also found an option in Build Settings to select the platform but only Linux was in the list. Do I have to do anything particular to get it to pick up the Windows stuff?

So, I'm playing with creating a mod with a UI. I'm following the tutorial here: I've got the Exporting the Asset Bundle section. In the AssetCompiler window, when I update, I get an error about WindowsStandalone support not being allowed because the required module is missing. Where can I find this module and how do I install it?

Check out the BetterCrewAssignment mod.

v1.2.2 has Set Orbit build in on the cheat menu (RightAlt+F12 or RightShift+F12 on Linux). No mods needed.

It didn't, but I have solved the problem. I'd completely forgotten my Windows training and had not turned it off and on again! That solved the problem although it still breaks if launched from CKAN. Not sure what's going on there. Launching from cli is fine.

This looks more promising:

The game window appears for a fraction of a second and then disappears again. The window manager doesn't crash though. No libraries are listed as missing by ldd I'm using Linux Mint 18.0 I have an Nvidia Geforce 1060 using driver 375.39 Yes, it's installed in my home folder. All of the files are owned by me and my personal user group. They are a mixture or rw+u and rw+ug permissions.

Yes, that is the entire log before the program exits to the terminal. Same issue with both KSP.x86 and KSP.x86_64. oh, and no KSP.log file is generated.

I have this problem and deleting settings.cfg and ~/.config/Unity3D did nothing to fix it. Running Kerbal Space Program Set current directory to {home}/bin/kerbal/v1.2.2/game Found path: {home}/bin/kerbal/v1.2.2/game/KSP.x86_64 Mono path[0] = '{home}/bin/kerbal/v1.2.2/game/KSP_Data/Managed' Mono path[1] = '{home}/bin/kerbal/v1.2.2/game/KSP_Data/Mono' Mono config path = '{home}/bin/kerbal/v1.2.2/game/KSP_Data/Mono/etc' displaymanager : xrandr version warning. 1.5 client has 4 screens displaymanager screen (0)(DP-4): 1920 x 1200 displaymanager screen (1)(DP-2): 1920 x 1200 Using libudev for joystick management Importing game controller configs I have had v1.2.2 running on this system. I don't know what's changed between then and now other than the usual system updates.

I wasn't talking about beta (<1.0.0) vs. released (>1.0.0) but about the release cycle for 1.2. They're nearing the end of the "experimental" phase for the 1.2 release and they're still adding new features. This is a fundamentally bad idea as it massively increases the risk of new bugs making it through to the public release. New features really should be held until release 1.3 now.

So your ore carrier is full at the time of contract acceptance. You empty the tanks, head to the contracted ore source, fill up from the miner and head to the contract destination. Does the contract complete? It's not as simple as you're making out.

Am I the only one concerned that there is still new feature development being done at this late stage in the release process. It really should be bug fixes only at this point.

No, they were discussing the "rumour" that Porkjet may no longer be working for Squad.

They weren't talking to you. Different thread of conversation entirely.

Welcome to software project planning. It is notoriously difficult to estimate development times. Tasks that should be simple unmask some horrible technical complication that triples the estimate. Or you encounter a bug in a third party library that takes weeks or months to get fixed (*cough* Unity *cough*). Big companies smooth out these blips by virtue of running bigger teams and bigger projects so the delays are easier to absorb. Even then, it doesn't always result in deadlines not being missed or QC targets being missed. However, for small companies, these issues really hit hard. Now Squad have a history of releasing anyway rather than delaying to fix issues. This has generally worked out because the PC based players are much more used to small software developers. Console gamers, due, I suspect, to the more complex release cycle imposed on them by the platform vendors, are more used to dealing with larger companies and so are a lot less forgiving. They're simply not used to the hobbyist aspect of gaming.

Also, not technically a Dyson sphere if it's encapsulating a planet. The whole point of a Dyson sphere is to capture the entire energy output of a star. Putting one round a planet would both cut the population off from the star's energy while also presenting a sub-optimal surface on the outside for solar energy capture. Still, a planet circling ring station would be rather cool.

What I do is launch into the same orbit as the target. Then put a maneuver node at Pe and add prograde until the intercept marker gives a close pass. Remember that you need to make sure your relative inclination is low. Burn at An or Dn to adjust it. This method will give you an encounter in a single orbit, although it uses more dV than a multi-orbit solution.

. Don't worry, you weren't the only one.

This seems like a PC vs Console cultural issue. PC gamers generally have no issue looking up stuff online while playing. That's a lot harder on a console and so console gamers expect a lot more hand holding.

Yes, because if you're in a tight orbit then waiting 1 more orbit is going to make likely to no difference on the launch window. Interplanetary launch windows are measured in days, not minutes or hours. There will be a small loss of efficiency in correcting for the small change in orbital position of the assisting body but since correcting early is vastly more efficient than correcting late, it's still much better. Combine this with a course correction mid-way between the assist and the target (will be <10m/s) and you'll be fine.

No. You're right that you might need to use a little radial thrust to re-gain the intercept but doing this after you've boosted your AP to nearly Mun altitude is wasteful. As a general rule it's always better to combined burns. Think about travel the long side of a triangle vs the two shorter sides. Also, burning further away from your target gives bigger changes of position per m/s speed change than burning close to your target. When this sort of thing happens, kill the original maneuver node and create a new one, as early as possible.

Going straight up is not the most efficient trajectory, even if you're leaving Kerbin. The most efficient way to the moons is a normal gravity turn up to LKO and just keep burning prograde.

The thing with radial burns is that they don't change your orbital energy much. They just re-direct it. This is great if you want to use a gravity assist to boost out to higher orbit using the oberth effect. Burning retrograde to bring your PE in is actually removing orbital energy so hurts your boost. In your case, you want to get into orbit which means that you need to reduce your orbital energy so a retrograde burn helps and then your final PE burn is also more effective. Win-win.