Vulkan

So I've just been playing around with putting things in places and I'm not entirely sure where the info is actually being stored. Would be very happy if someone could enlighten me please. If I place an object in game then it appears in the KTinstances file in the save folder, but it still appears in other saves on the same install when I load them, so it must be going somewhere else as well? Where? It's not the cfg in gamedata I checked that. In which case what is the KTinstances file for? If I make an object a launchpad when I place it it doesn't appear in the launchpad list when I reload. But if I copy the node in KTinstances in the save folder over to the cfg in gamedata then it does appear. So launch locataions are being read from gamedata when the game loads?

Might be worth moving that warning a bit further up the OP. I came here just now to report the exact same thing and was thinking it should have worked based on that video.

I've think I've found another bug that looks like it will be the same as the one mentioned a few days ago with transforming orbital to surface reference, but this time it's maneuver to orbital. The following import krpc conn = krpc.connect(name='Auto-launch') vessel = conn.space_center.active_vessel node = vessel.control.add_node(conn.space_center.ut,prograde=1.,radial=0.,normal=0.) vessel.auto_pilot.set_direction(node.vector,reference_frame=conn.space_center.ReferenceFrame.maneuver) should be putting up a 1ms prograde maneuver for current time and pointing the vessel along it, but actually points -ve normal. A 1ms radial works fine, but 1ms normal also points in +ve radial. Everything else is good so far:D

This is properly amazing and useful. Thank you so much for making it. I had a go at running a kOS career but gave up pretty quickly becuase of the limitations, pid control is about the limit of reasonable complexity and you have to rewrite it every time. The ability to "import scipy" is going to be awesome. Minor notes: 1 - the names on the wiki are out of date with the current release, still showing "Flight().VerticalSpeed" when it's actually "flight().vertical_speed" 2 - might be worth putting a health warning on true_altitude that it returns altitude above the sea floor if you're over water, so a parachute deployment loop should be looking for min(altitude, true_altitude). Took me a few ocean crashes to work that one out.

Now that would be a very realistic and difficult tech tree. You have to land on the Mun with the proverbial "less computer power than a mobile phone" in order to make enough science for more computer. No hovering skycranes until you've unlocked the last tier.

Thanks very much, that explains things. Looks like it's time to brush the dust of my pid control notes.

Am I right in thinking that lock:steering does not make use of engine gimbals? I'm trying to do a kOS career and so have no torque or aerodynamics as yet. With an LV-T45 under an unmanned probe (edited the tech tree to give me one at the start) I can run set ship:control:yaw to 0.5. lock throttle to 1. stage. and go into a nice sidespin but lock steering to heading(90,45) lock throttle to 1. stage. goes straight up. If so is ther a workaround beyond of any kind? Thanks in advance.

I've hit driver problems as well since upgrading ubuntu 13.10->14.04. I was using the fglrx-updates driver and all was well. Since 14.04 that now causes the freezing described by brickmack. Tried the X.Org driver and KSP runs without crashing but the lag/framerate is hideous, about 6fps on the titlescreen and worse in flight. With the other fglrx driver KSP doesn't start at all and spits something about mono paths to the terminal, so no KSP for me until somehing gets fixed. Hardware is i5 and Radeon 7870 with 8G ram, so not limiting. I had a large number of mods without too many issues before the ubuntu update.

This is an awesome mod, really enjoying working out how to set up a remotetech network over the new Jool system. Thing is I started putting together a delta-v cheat sheet to plan out my launches and found that having so many bodies of that mass in such close proximity has really gone past the limits of the SOI system. The combination of the kerbin SOI being small compared to Kerbin but still large compared to it's distance from Jool means that it's possible to ecape Jool from a 100x100 orbit around kerbin with an 879ms^-1 burn despite the minimum value to conserve energy being 1250ms^-1. I can't really see any way round this apart from implementing multiple influences on the spacecraft or making the system a lot bigger, the force of gravity due to the most significant celestial body simply isn't big enough compared to the second and third most significant for the SOI approximation to be valid. On a more achievable note would it be possible for the dark side of Jool to be a bit darker when viewed from KSC? It's properly black viewed from space but at the launchpad more of a mid grey.

I just found this. It seems to be only affecting solar panels that start in containers and it fixes itself if you return to the space centre and back. Minimal steps to reproduce: 1- build and launch a pod + xenon tank + ion engine + container containing a solar panel. 2- use the ion engine to drain the battery 3- eva and place the solar panel on the pod 4- return to pod and deploy the solar panel. The panel menu claims to be drawing power but no electric charge is acquired. The debug menu reads "[Error]: Resource System Error: Requested resource (id: 0) does not exist" 5- quit to space centre and return. It now works fine.

What's that greyish planet with the highly eliptical orbit? I seem not to have it... I also have the others using stock textures on Linux but that's already been mentioned elsewhere several times so I'm hopeful that it will be patched relatively soon for that.

That's it. Many thanks. For some reason I was thinking that the list was if I wanted to poll more than one resource. Working code for anyone in the future: var resources = new List<PartResource>(); this.part.GetConnectedResources(IntakeAirID, resources); availableAir=resources.Sum(r => r.amount);

Afternoon all, I'm getting a bit confused about polling for connected resources, specifically intake air. I've written a module that should be displaying the available intake air as a prelude to using this value elsewhere. In OnUpdate I have: var resources = new List<PartResource>(); this.part.GetConnectedResources(IntakeAirID, resources); availableAir=resources[0].amount; Air = string.Format("{0:0.000}",availableAir); No if I put one air intake anywhere on a rocket and a part to display the 'Air' string in a window then the value in the window tracks the IntakeAir value in the top right. However, if I have more than one air intake then it only gets the value for the first intake placed. This means that a rocket with four radial intakes will have 1.6 IntakeAir on the launchpad according to the resources readout but only 0.4 is being found by GetConnectedResources. So how do I get the true value for the IntakeAir that is present onthe craft?

I am definitely interested and as a taster present to you a couple of screenshots for my newly started atmospheric collection plugin. So far the module keeps track of available IntakeAir from the stock intakes and calculates the ratio of the individual components in the atmosphere based on height. Currently it's a simple 50:50 Oxygen:Nitrogen at sea level with a linear transition to 100% Nitrogen at 69km. I used the KSP-PartGenerator v3.0 by Lando for the part file and texture. The plan is to have a different profile for each planet with buttons on the GUI to separate each element into tanks. Power requirement for separation will increase with lower concentrations.

First can I say thank you very much Lando. As a code person with no graphics skills beyond paint this is exactly what I want and worked with no problems once I had it installed. I do have two minor points: The first is that most of the button text is grey on a very similar grey and I had to tilt the screen to read them. If you could change them to white to match the rest of the program that would make things a bit easier. The second is just a note on installation for Linux users. If you have mono already installed and running the .exe gets an error message looking a bit like this Missing method EnableVisualStyles in assembly /path/to/PartGen3.0/KSP_PartGen.exe, type System.Windows.Forms.Application Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies. File name: 'System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' [ERROR] FATAL UNHANDLED EXCEPTION: System.IO.FileNotFoundException: Could not load file or assembly 'System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies. File name: 'System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' Then you are missing some windows compatibility libraries for mono. I'm not sure which ones exactly so all I can recommend is getting the full 90MB version by apt-get install mono-complete

Check the versions of EPL and Kethane. The spaceport version of EPL is quite old and needs a modified kethane 0.4.4 to work. More recent releases from the back pages of the forum thread are compatible. Memory should't be an issue with just those two though. I've run EPL 3.1 and Kethane 0.7.7 without issue on 4G of RAM along with MechJeb, KAS, damned robotics and assorted other parts mods.

So I just read the above and am now somewhat confused. If KSP is only running in 32 bit then what is the KSP.x86_64 icon that I've been clicking on all the time?