a__gun

The Mk3 Cargo Nose Ramp has some crazy drag issues. On take off it quickly generates more drag than the rest of the plane and flips you round. I'd patch it myself, but I have no idea how the drag cube stuff works

Yep just launched a Lynx shuttle in a fresh sandbox. Cockpit headlights light the planet

If you are talking about the ports from Konstruction, this will do it: @PART[*]:HAS[@MODULE[ModuleDockingNode],!MODULE[ModuleWeldablePort]]

It's just a parts pack. It works fine in 1.2.2 and I'm sure it's fine in 1.2.1 too

Using this (and loving it) in a reasonably heavily modified 64 bit game and not had any crashes for a while. No issues with the hitches. What is the compatibility of the docking port with the stock and KPBS ones? For that matter, what's the state of compatibility between the stock and KPBS ports?

I'd definitely be interested in this. I hate how spread out and bitty the stock UI is - being able to move the panels around would be a great help.

Using stock comms (No RT) I can't get full control using the top (probe) part of this, even landed at the KSC. If I place just the two parts that come with this mod, partial control. If I add an external antennae, still only partial control. Only if I add a stock probe core I get full control, even if I then jettison the stock core. I'm really confused with this. I've tried it on an otherwise clean install and its still the same. I've compared the config to stock probe cores and that didn't help (Though the ModuleDataTransmitter is set to 'DIRECT', whereas the other probe cores are 'INTERNAL'). Scratch that I've fixed it - add 'vesselType = Probe' to the config and it works. I guess without this or any other command parts on board the game doesn't know how to treat it.

(Admittedly I haven't actually tried them recently, but...) The part was originally released before landing legs had their own separate module, and therefore doesn't have suspension etc which makes them a bit too easily breakable

Awesome work! Have you managed to update the base mount to use the proper landing leg module, or is it still just a generic animated part?

As someone else noted, its in d/m/y format. I've never really understood American date formatting - m/d/y. Why would you put [middle sized thing]/[smallest thing]/[biggest thing]? Anyone who's ever programmed knows it should be [biggest thing]/[medium sized thing]/[smallest thing]. Anways I digress... I'll put this (And DDS textures!) in an update soonâ„¢

Hi all! I've released an update to this now which I hope should fix everything - sorry it took me a little while! I've not had much time to play around with 1.0 so if anything seems unbalanced do please let me know. I also still haven't had a chance to look at where the parts should fit in the tech tree - any ideas greatly appreciated. Enjoy Also, Thanks to Z-Key for providing support :)

I've just tried a fresh stock install + BoxSat and the battery modules still lag when they are loaded into the editor. I've not checked my RAM usage and I don;t get crashes or anything, but there is definite lag between you selecting the part and it appearing. Mentioned this a few pages back, but from past experience it tends to happen when models have a high poly count - does the battery have a higher count than the other parts?

I'm pretty sure that if you simply use the absence of CO2 to infer the presence of CO2, then your recycler will operate everywhere except Kerbin and Laythe (I.E. in space, around Kerbol, on planets with no atmosphere etc)

This definitely. Even better, use the stock textures as Lack does with his SXT pack.

The oxygen in atmosphere flag uses a data in the stock game to determine if the atmosphere contains oxygen. There is no such stock data for other elements (CO2 included) so this would be impossible without a resource mod. Your best bet is probably to look at Regolith/Karbonite.

Probably a TweakScale issue I'm guessing...

You could just clone the empty piece and give it some electric charge

I've noticed the editor lag with the batteries too - tends to happen with hi-poly models so I'd assume that's the case

[As Crzyrndm says] You can use ORs within the NEEDS command. You would need this: PART:NEEDS[LifeSupport|IoncrossCrewSupport|TacLifeSupport] Alternatively you could define the part in the conventional way, and then remove it with a conditional MM patch like this: @PART[US_Wedge_Sabatier]:NEEDS[!LifeSupport&!IoncrossCrewSupport&!TacLifeSupport] { [INDENT]@category = -1[/INDENT] }

Doing something of an overhaul on the balance and parts I use for life support (With TAC) and noticed in the cfg for the US Sabatier reactor that whilst there are three different parts that MM can create depending on the life support mod the user has installed, they all seem to have the exact same statistics. Is this intended..?

Been toying around making custom welded parts and started on a replacement for the TAC air filter (IntakeAir->Oxygen). After reading the warning in the existing parts description that it wouldn't run when the vehicle is unfocused, I ran a few tests to work out exactly why. I set up my custom part with two TacGenericConverter modules: one taking IntakeAir and ElectricCharge and creating Oxygen (Exactly as the stock one does) and the other only requiring the ElectricCharge. Both had the requiresOxygenAtmo flag set to true. I found that the module with the two inputs behaved as expected when the vehicle had focus, but (as warned) didn't create Oxygen when unfocused. The other module seemingly worked perfectly however - it creates Oxygen both when focused and unfocused, and only works on oxygenated planets. However (And this is the reason for my post), whilst it only works on planets with an oxygenated atmosphere, it does so at any height within or above the atmosphere. I looked over the source code for the module and I think I've found an easy change that would fix this behavior. I believe this is the bit of code that handles the requiresOxygenAtmo flag: [I]159[/I] { [I]160[/I] converterStatus = "Atmo lacks oxygen."; [I]161[/I] return; [I]162[/I] }[I]158[/I] if (requiresOxygenAtmo && !vessel.mainBody.atmosphereContainsOxygen) If this were to be changed to add an extra check that the vehicle is within the atmosphere (Or even below a certain point within the atmosphere as with the existing Kerbin behaviour detailed here) then a air filter that runs in the background could be a reality Never done coding within KSP, but I've just looked over the API and I think this would work: [I]159[/I] { [I]160[/I] converterStatus = "Atmo lacks oxygen."; [I]161[/I] return; [I]162[/I] }[I]158[/I] if (requiresOxygenAtmo && !vessel.mainBody.atmosphereContainsOxygen[B] && vessel.mainBody.maxAtmosphereAltitude<vessel.orbit.altitude[/B]) Edit: Realised I had a > where I should of had a <

Used to be - when the new window came in it was dropped as a dependency

NO you do not need HullCam

AKA, no pics=no clicks. Sounds interesting though.

You would need the source files of the mesh - only PorkJet would have those. I wouldn't hold your breath.