almagnus1

Blasphemy... I mean, how can you not like bacon? Or dogs for that matter.....

(Left click the debris icon in the tracking station to select it, or right click to ONLY see the debris).

It's a breeding ground for the kraken. Run away before your ship is eaten.

One thing that hasn't been mentioned yet is trying to burn half the maneuver before the node, and half after it - you don't want to start your burn when you hit the node, but want the node time to occur in about the middle of the burn. Alternatively, you can burn at half power and then your start time is equal to the predicted maneuver time, but the burn takes twice as long.

Yeah, automagically. When something just works, and you have no clue why, but it just worked. Like "I added the hardware and Windows automagically installed the right drivers". Or in the case of KSP: "I pressed launched and the flight automagically made it to orbit.... Then exploded".

That's functionality that should come native with TAC LS. I'll take a deeper look at what my mods are, and see if I can't figure a way to hack that into TAC-LS, as my parts tree would love that.

If they're just going to be a parts package useful for props, people like Bob Fitch would make great use of them because they don't need to handwave a PC from other components. Creating more parts for usage in machinimas is never a bad thing. If it's going to be used for a gameplay mechanic, you'll have to differentiate yourself from kOS ( http://ksp-kos.github.io/KOS_DOC/ ). You might want to consider RemoteTech as well, ( http://forum.kerbalspaceprogram.com/threads/83305 ), because I'd imagine that having things automagically work may not be desired gameplay (ie: I shouldn't be able to send data from Laythe without building out the communications network between Laythe and Kerbin).

I had a rescue mission spawn this vessel, and I didn't realize the issue until I was basically on top of the borked vessel with the rescue ship. For those that don't want to dig this out of the code, the game spawned a crew in the Stayputnik probe core. The relevant part of the save file is: VESSEL { pid = 0e2bc2e4afc244b2b55aef5b77f333e3 name = Sanene's Heap type = Ship sit = ORBITING landed = False landedAt = splashed = False met = 1569441.36633497 lct = 666921.854570274 root = 0 lat = 6.73506090365856E-05 lon = -20.3778108672025 alt = 12453.3493932342 hgt = -1 nrm = 0.5051957,0.4189748,0.7544783 rot = 0.5062978,0.6112752,-0.03380423,0.6073405 CoM = -0.0001926655,0.0001912729,-2.829274E-05 stg = 0 prst = False ref = 0 ctrl = False cPch = cHdg = cMod = 0 ORBIT { SMA = 212071.913438575 ECC = 0.00367614064784069 INC = 7.6701952403066E-05 LPE = 180.887790058527 LAN = 180.881282626128 MNA = 4.20439832111668 EPH = 2236363.22090524 REF = 2 } PART { name = probeCoreSphere cid = 0 uid = 1478654267 mid = 1478654267 launchID = 0 parent = 0 position = 0,0,0 rotation = 0,0,0,1 mirror = 1,1,1 symMethod = Radial istg = 0 dstg = 0 sqor = 0 sepI = 0 sidx = 0 attm = 0 srfN = , -1 attN = bottom, -1 mass = 0.05 temp = 4.53208096950573 tempExt = 4.56532661252188 expt = 0 state = 0 connected = True attached = True flag = Squad/Agencies/GoliathNationalProducts rTrf = probeCoreSphere (Sanene's Heap) modCost = 0 crew = Sanene Kerman EVENTS { } ACTIONS { } PARTDATA { } MODULE { name = ModuleCommand isEnabled = True controlSrcStatusText = Not Enough ElectricCharge (0.0/0.0) EVENTS { MakeReference { active = True guiActive = True guiIcon = Control From Here guiName = Control From Here category = Control From Here guiActiveUnfocused = False unfocusedRange = 2 externalToEVAOnly = True } RenameVessel { active = True guiActive = True guiIcon = Rename Vessel guiName = Rename Vessel category = Rename Vessel guiActiveUnfocused = False unfocusedRange = 2 externalToEVAOnly = True } } ACTIONS { } } MODULE { name = BBModule isEnabled = True EVENTS { } ACTIONS { } } MODULE { name = TweakScale isEnabled = True currentScale = 0.625 defaultScale = 0.625 defaultTransformScale = (0, 0, 0) DryCost = 300 EVENTS { } ACTIONS { } } MODULE { name = USI_ModuleRecycleablePart isEnabled = True EVENTS { ScrapPart { active = True guiActive = False guiIcon = Scrap part guiName = Scrap Part category = Scrap part guiActiveUnfocused = True unfocusedRange = 5 externalToEVAOnly = True } } ACTIONS { } } MODULE { name = USI_ModuleRecycleablePart isEnabled = True EVENTS { ScrapPart { active = True guiActive = False guiIcon = Scrap part guiName = Salvage Part category = Scrap part guiActiveUnfocused = True unfocusedRange = 5 externalToEVAOnly = True } } ACTIONS { } } MODULE { name = ModuleSPU isEnabled = True IsRTPowered = False IsRTSignalProcessor = True IsRTCommandStation = False RTCommandMinCrew = 6 EVENTS { } ACTIONS { } FlightComputer { TotalDelay = 0 ActiveCommands { AttitudeCommand { Mode = Off Attitude = Prograde Frame = World Orientation = 0,0,0,1 Altitude = NaN TimeStamp = 2236363.22090524 ExtraDelay = 0 CmdGuid = a1b5291f-38be-4c4f-8d3c-9ef86cdffde3 } } Commands { } } } MODULE { name = ModuleRTAntennaPassive isEnabled = True IsRTAntenna = True IsRTActive = True IsRTPowered = False IsRTBroken = False RTDishCosAngle = 1 RTOmniRange = 0 RTDishRange = -1 EVENTS { } ACTIONS { } } MODULE { name = TrajectoriesVesselSettings isEnabled = True EntryAngle = 0 EntryHorizon = False HighAngle = 0 HighHorizon = False LowAngle = 0 LowHorizon = False GroundAngle = 0 GroundHorizon = False ProgradeEntry = False RetrogradeEntry = False AutoPilotEnabled = False AutoPilotStrength = 5 hasTarget = False targetLocation = (0, 0, 0) targetReferenceBody = EVENTS { } ACTIONS { } } MODULE { name = ModuleTripLogger isEnabled = True EVENTS { } ACTIONS { } Log { flight = 0 } } RESOURCE { name = ElectricCharge amount = 0 maxAmount = 10 flowState = True isTweakable = True hideFlow = False flowMode = Both } } ACTIONGROUPS { Stage = False, 0 Gear = True, 0 Light = False, 0 RCS = False, 0 SAS = False, 0 Brakes = False, 0 Abort = False, 0 Custom01 = False, 0 Custom02 = False, 0 Custom03 = False, 0 Custom04 = False, 0 Custom05 = False, 0 Custom06 = False, 0 Custom07 = False, 0 Custom08 = False, 0 Custom09 = False, 0 Custom10 = False, 0 } DISCOVERY { state = -1 lastObservedTime = 666921.854570274 lifetime = 184032000 refTime = 184032000 size = 0 } FLIGHTPLAN { } CTRLSTATE { pitch = 0 yaw = 0 roll = 0 trimPitch = 0 trimYaw = 0 trimRoll = 0 mainThrottle = 0 } } The mods in play are (from CKAN): { "kind": "metapackage", "abstract": "A list of modules installed on the default KSP instance", "name": "installed-default", "license": "unknown", "version": "2015.08.09.06.51.36", "identifier": "installed-default", "spec_version": "v1.6", "depends": [ { "name": "ActiveTextureManagement-x86-Basic", "version": "5-0" }, { "name": "BetterBuoyancy", "version": "v1.4" }, { "name": "EnvironmentalVisualEnhancements-HR", "version": "7-4" }, { "name": "KerbalFlightIndicators", "version": "R10pre" }, { "name": "NavHud", "version": "1.2.1" }, { "name": "RealChute", "version": "1.3.2.3" }, { "name": "TransferWindowPlanner", "version": "v1.3.1.0" }, { "name": "USITools", "version": "0.4.2" }, { "name": "DistantObject", "version": "v1.6.0" }, { "name": "CrowdSourcedScience", "version": "v3.0" }, { "name": "FairingWithMass", "version": "1.3.1" }, { "name": "FirespitterCore", "version": "v7.1.4" }, { "name": "UKS", "version": "0.31.6" }, { "name": "KSP-AVC", "version": "1.1.5.0" }, { "name": "TACLS-Config-Stock", "version": "v0.11.1.20" }, { "name": "TweakScale", "version": "v2.2.1" }, { "name": "TACLS", "version": "v0.11.1.20" }, { "name": "AlcubierreStandalone", "version": "0.2.1" }, { "name": "USI-FTT", "version": "0.4.1" }, { "name": "EnvironmentalVisualEnhancements", "version": "7-4" }, { "name": "InfernalRobotics", "version": "v0.21.3" }, { "name": "TacFuelBalancer", "version": "v2.5.1" }, { "name": "Trajectories", "version": "v1.4.3" }, { "name": "PlanetShine-Config-Default", "version": "0.2.3.1" }, { "name": "EditorExtensions", "version": "2.12" }, { "name": "PlanetShine", "version": "0.2.3.1" }, { "name": "CommunityResourcePack", "version": "0.4.4" }, { "name": "BoxSat", "version": "A.02e" }, { "name": "ModuleManager", "version": "2.6.7" }, { "name": "IR-Model-Rework-Core", "version": "v01b" }, { "name": "IR-Model-Rework-Expansion", "version": "v01b" }, { "name": "DistantObject-default", "version": "v1.6.0" }, { "name": "KerbalAlarmClock", "version": "v3.4.0.0" }, { "name": "DockingPortAlignmentIndicator", "version": "6.2.0" }, { "name": "ExtraPlanetaryLaunchpads", "version": "5.2.2" }, { "name": "StockClamshellFairings", "version": "1.0" }, { "name": "AsteroidDay", "version": "1.0" }, { "name": "KerbalEngineerRedux", "version": "1.0.18.0" }, { "name": "RemoteTech", "version": "v1.6.7" } ] }

Have you done any testing with either TAC-LS or USI Kolonization System? RE: Debug stuff, you might want to take a look at this article, and consider wrapping it in a while where the compiler will remove the code during an optimization pass: C# “Debug only†code that should run only when “turned on†http://stackoverflow.com/questions/5080477/c-sharp-debug-only-code-that-should-run-only-when-turned-on It's the same basic idea s the C++ #ifdef __DEBUG__ preprocessor flag, just .NET-ified.

Have you given any thought into collecting the life support hex cans and discs into a single hex can or disc of a size class, then using the texture change functionality to switch between the various components? I'm thinking of functionality like RoverDude did with the freight containers in FTT, and this would help clear up a lot of the clutter that TAC-LS makes of the parts menus by reducing the hex cans and discs down to just one for life support and another for waste for each size class, rather than the 20-30 different components that are currently present, as TAC-LS tends to spam the early game Utilities parts screen with a lot of stuff.

Ok, so what are the exact implications of setting the physic range to MAX_DOUBLE? @Captain Sierra: Random question, but did you ever play any of the Outposts or Space Quests?

Why not use Infernal Robotics to create something that will move the legs into the bay when you're not using them, yet deploy them to a stable position when you want to?

But what about other ships in other orbits that would normally go into the planet's atmosphere? As I understand the way the game engine works, it only applies physics to the currently active ship, and only if it's not currently under time warp. So how difficult would it be to get physics to work on all the things (probes, other ships, etc) when it makes sense?

Soo... how difficult would it be to force physics to calculate all the things all the time? What would be the proper approach to do this via code?

Any chance you'd make a drive unit that's designed for the FTT starlifter series of parts?

Part of the Shuttle reentry involved S Turns, which is essentially putting the bottom of your space plane into the prograde vector while pointing your nose to the left or right, essentially making giant S's to bleed off speed in the 20k-30k region, where the atmosphere is biting in. You'd then turn the other way, so you can correct the change in trajectory (thus flying an "S", hence the maneuver name). If you can learn to do this, it can help to slow you down. Expect to see SSTO confetti when learning though, as it's really easy to get TOO aggressive with this maneuver and rip the plane apart, especially with FAR installed. Edit: You may want to read https://en.wikipedia.org/wiki/Space_Shuttle#Re-entry_and_landing, as this goes into detail on what I'm failing at describing XD

A) You're going WAAAAAY to fast for that low in the atmosphere Don't use the prograde markers, as the computer is WAAAAY to twitchy. Use MechJeb's for this as it just does it better. C) You screwed up the gravity turn, as that's basically a .90 launch profile, not a 1.0. Gravity Turns complete best when you turn SAS off. What happened was a ship that was going too fast, broke apart, then blew up cause you did something aerodynamically stupid. That's not the heating system there.

You need to upgrade Mission control so you can accept multiple contracts at once. Then it's just planning how you can achieve multiple missions on a single contract.

How effective of a workaround is adding a lot of radiators?

Heatshields are crucial, as is some way to apply torque to the vessel (like reaction wheels/capsules/cockpits) For a lot of the early on tourist missions, I frequently recover a vessel that's the heat shield + inline cockpit + mk1 capsule + nose cone parachute + 2x radial parachutes (all parachutes mounted to the capsule, so they are shielded from heat - at least that's the idea). The key is keeping the heat shield pointing towards your prograde vector, which basically means having the capsule going retrograde the entire way down. That said, I have managed to incinerate myself by loosing control of the reentry (as I need to watch the reentry as that capsule design requires a lot of attention until it's sub 1 km/s speed), so it's all a combination of how you're reentering the atmosphere with how well you can put the heat shield in front of you. While not the most credit efficient of designs, I generally don't stick anything on my capsule that isn't a heat shield or parachutes. All science instruments get shed before reentry, as that keeps the capsule aerodynamically stable, and my chances of survival the highest.

Going off of what they said, you want to rework the design of the ship so that only the heat shield + capsule + parachutes reenter, and everything else is shed. The capsules are generally areodynamically stable if you get them pointing retrograde, so you should be able to reenter without needing to use SAS. It's also where service bays full of stuff is helpful, as you can stick one of those on a heat shield, and put a bunch of stuff in the service bays.

That might have been what had happened, but normally when I freeze them (due to lack of heaters, I assume), it's death to lack of electricity. Food had more than enough (single kerbal capsule heading to the Mun and back with a small hex can for life support) Food, water and O2 was good. The toxicity message threw me.

I think the intent was to get people into the modded scene, as it extends the base game quite a bit (like actually adding in some end game with the balanced warp drives, and MKS/OKS + EPLP providing a way to colonize the system)

What's wrong with the Asteroid Day mod being a mod?

I had a kerbal killed by CO2 toxicity, despite having MORE than enough O2, and CO2 storage remaining. I have both TAC-LS and MKS/OKS installed, and I'm trying to figure out which one killed the Kerbal. What are the exact kerbal kill conditions of TAC-LS?