almagnus1

Only if you give us hamster wheels as exercise modules =P

Is there a mod that can disable mouse selection of objects in flight? I've been continually mucking around with making a machinima of an Apollo-alike mission (mostly as a learning experience before tackling something bigger) using KSP, and one of the problems I'm having is with trying to mimic the Stage1 seperation, but the problem I'm having is the mouse keeps highlighting stuff green. This is making creating something like this frustrating, as I can't position the mouse off-screen without highlighting something. For reference, here is what I'm trying to create:

I'll check that out, thank =)

Is there a mod that has low profile engines that work in 1.0.4? I'm working on converting an Apollo-alike craft from .90 to 1.0.4, and due to changes with KAS being split into KAS and KIS, I've had to scrap the old lander design and go with a new one because the new KAS boxes aren't as low profile as the older ones, so I had to go with the inline 2m KIS container so I could fit my rover bits into the lander.

Isn't that essentially a fork of a subset of the KW Rocketry functionality? Perhaps better described as a salad or crab fork? =P Either way, it would be preferable as it does provide a way to have that functionality live on for the time being, as (IMO) the KW Rocketry fairing system was the best of the ones available pre-1.0.

So, two questions: 1) Does the petal adapter work as expected in 1.0.5? 2) Have you thought about splitting the older fairings into a separate mod and possibly bundling those with http://forum.kerbalspaceprogram.com/threads/132343-1-0-4-Old-School-Fairings ? That is, assuming all parties involved consent to doing that >.>

Wait, found a mod that helps to patch the non-procedural fairings: [1.0.4] Old School Fairings http://forum.kerbalspaceprogram.com/threads/132343-1-0-4-Old-School-Fairings

How do you think 1.0.5 is going to impact this mod?

I'm not really a fan of the procedural fairings, they make it harder than necessary to strut the payload to the fairing, which can make takeoff and the gravity turn more difficult than necessary without building an internal structural support system for the payload that you attach struts to, then jettison after the fairing. However, using a fairing system like the KW Rocketry fairings allows me to strut the cargo to the fairing, as the craft was stable enough once I was in orbit to finish deployment of whatever I'm hauling; however, this isn't an option because 1.0 broke that style of fairing. While each system has it's strengths and it's weaknesses (assuming they both work in KPS), it's really a decision that should be left to the player, as the player knows best with what will (and won't) work for a particular design. So that leads me to some of the stuff I've read about the 1.0.5 changes, specifically: Will the 1.0.5 changes allow the non-procedural fairings to work as they did in 0.90?

It all boils down to how effective your control surfaces are at moving the plane in flight, how fast you're going, your CoM/CoL, and your TWR. Stupidly high TWRs means you basically have fins on an engine, but the craft is oh so maneuverable, assuming the control surfaces actually bite.

As I have, but most of my experience with planes (sans FAR and DRE on the stock aero model in 1.0.x) has been purely atmospheric, and I've gotten that down. The problem I think I'm facing is either building a lawn dart (yay), or building a SSTO that works great in atmosphere, but can't make it to orbit - which I suspect to be too much drag combined with a bad ascent profile. I probably need to examine the design (again), then spin this off into another thread.

What's the recommended way to mount engines on the wings, rather than have them inline? I am using an 8 whiplash engine configuration (with two rocket engines on a bicoupler on the SSTO core), with four whiplash engines to either side of the main fuselage, and the whiplash engines paired above and below the wing. I've also got enough TWR to go at max throttle from takeoff, hold to a 45 degree angle of attack, and put my apoapsis in space without using the rockets. It's just going from suborbital to orbital that's the current problem.

Does it matter which intake you're using?

./rimshot

That's what I'm doing after every launch, as I'm building out a satellite network, and want to minimize as many things around KSP as possible. Although I try to engineer the launchers to minimize debris, but that doesn't always happen....

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.