speedwaystar

the CKAN version is standard size, i notice. would it be possible to add the stockalike dimension patch as an optional CKAN dependency? rather than overwriting the base files, have you considered making the patch into a ModuleManager config which only modifies the relevant values? it would be much easier for you to keep up to date with changes in the base files.

i'm not sure if this bug is unique to Universal Storage. i encounter it quite often with normal parts: for some reason attachment nodes sometimes disappear on removal of a part.

what's the best way to merge these two scout modules? if i link them with a FlexOTube (which i forgot to bring with me... oops!) will KSP treat them as one structure which can share resources? i thought it best to ask before i send another mission on its way.

if you're not running 64 bit KSP and the game requests more than 3.5gb of ram at any point, it will simply crash without a log entry. there are memory leaks that occur every time you perform a scene transition which basically ensure that at some point the game will end up needing more than 3.5gb of ram. if you are running a lot of mods that will occur sooner rather than later.

does anyone have a working link to Mk3 KIS Cargo Containers? EDIT: nvm, about 15 seconds after posting this i found https://janbrohl.pythonanywhere.com/ckan/Mk3KISCargoContainers/1.0

http://spacedock.info/mod/130/ is broken however, http://spacedock.info/mod/130/Contracts%20Window%20+ works

having an issue where turning on SAS causes all the RCS thrusters to continuously fire -- fighting one another to keep the prograde vector aligned. same problem arises in this configuration: EDIT: although it might be the fault of GravityTurn, according to ExceptionDetector: that's a lot of exceptions! uninstalling GravityTurn didn't help.

so, the spacedock and CKAN downloads still have only the two inline thruster blocks (2.50m and weird 1.675ish) -- i'm guessing you haven't been able to update with the fixes yet? tbh the easiest way to handle the inline thrusters would be to simply make tweakscale a dependency and have one part which automagically resizes. let tweakscale worry about mass, resources and thruster power and bob's your uncle. in the meantime though i've created a 1.25m part thus:

after floods of gamebreaking null pointer error and days of whittling down the cause, i seem to have narrowed it down to MissionController. uninstalling MissionController completely fixes the problem. is anyone else encountering game-breaking issues since the most recent update?

suggestion: flashing amber hazard lights!

wow, the like this? i hadn't thought of that configuration. this was my attempt: which is fine -- the push adapter wraps around the grappler without clipping (much). the only problem is that the top docking port is blocked. i guess it's not possible to make both ends of the same object into docking ports. really impressed with how these parts all fit together (in various configurations, some probably not intended :D) this is my simple homebrew tug, which is basically two universal docking ports, a probe body and an OMS.

i was wondering that myself, but left it at 1, which RoverDude can change if/when he merges the pull request. i guess he's quite busy with KSP 1.1 atm, which is in crunch mode.

i'm a bit confused by this since the Push Adapter seems to fit behind the command pod, over and around the grappler unit. am i assembling it correctly? i don't see how it would fit in front of the command pod. pictures?

my outstanding pull request on github fixes this, and other unrelated (TAC-based) stuff.

very minor bug report: the push adapter doesn't have a manufacturer, and so doesn't group with other Ark Propulsion stuff

big thumbs up! i was about to do this myself, so phew.

the fuel cell mod works. will check the atomic engine soon.

personally i would delete ven's and use dr jet's.

seems fair enough. for the moment i'll just not use tiny initial amounts, i guess.

issue logged: https://github.com/BobPalmer/MKS-LITE/issues/37 so resource space available after expansion is based on the consumption rates from TacLifeSupport/LifeSupport.cfg? FoodConsumptionRate = 1.6927083333E-05 WaterConsumptionRate = 1.1188078704E-05 OxygenConsumptionRate = 0.001713537562385 CO2ProductionRate = 0.00148012889876 WasteProductionRate = 1.539351852E-06 WasteWaterProductionRate = 1.4247685185E-05 what does inflatableMultipier from USIAnimation do? EDIT: even weirder. i set the resourceAmounts for food,water,oxygen to 1,1,1 instead of 1.097, 0.725,111.038 in an attempt to figure out what is going on, and to determine if the expansion is proportional to TAC's defined consumption/production rates. to my surprise, all three resources expand to 100 units on deployment. i'm all out of ideas

interesting. thanks. from my brief test i didn't notice the TAC-LS resource capacities increase after inflation, but i could be mistaken. will check. EDIT: well, this is weird. relevant config from my TAC-LS patch: MODULE { name = FSfuelSwitch resourceNames = Dirt,Ore;MaterialKits;Food,Water,Oxygen;RareMetals,ExoticMinerals;Waste,WasteWater,CarbonDioxide resourceAmounts = 35,7;70;1.097,0.725,111.038;35,35;0.1,0.924,95.913 initialResourceAmounts = 0,0;0;0,0,0;0,0;0,0,0 tankCost = 3500;3500;3500;3500;3500 hasGUI = false basePartMass = 0.75 tankMass = 0;0;0;0;0 } on launch we see the expected values (1.097 food, 0.725 water and 111.0 oxygen) the config values for USIAnimation are: MODULE { name = USIAnimation deployAnimationName = Deploy inflatable = true inflatedMultiplier = 100 } which to me suggests it should multiply the initial RESOURCE values by 100 when you deploy the structure. however. after deployment, food is multiplied by 100, water by 10k, and oxygen by nothing. which is... unexpected. on retracting, everything is divided by 100, as expected (but we now have different max values for everything). REdeploying a second time, we get:everything multiplied by 100. my second set of TAC-LS waste products also displays weird behaviour. start values are again correct. on deployment, waste is multiplied by 10k, wastewater by 10k, and CarbonDioxide by 100. on retraction they are all divided by 100: @RoverDude: any suggestions? it seems the the FIRST call to USIAnimation (the initial deploy) is borked, but subsequent deployments/retracts are fine. should i open a git ticket? note that the USI stuff works as expected (raw materials, refined goods, and commodities all are multiplied by 100x on deploy, /100 on undeploy).

to Minmus, with TAC-LS patched Scout Hub, by SLS Block 1A Exploration Upper Stage with Orion Explorer Service Module!

here's my ModuleManager bandaid fix to the Agriculture Module. it replaces USI-LS resources with TAC-LS resources, and adds the TAC-LS LifeSupportModule, it also fixes the problem where the the Ag Module can't be entered after deployment, despite needing crew to operate it. // assumptions: AgricultureModule is intended to have CrewCapacity = 1 @PART[*_AgModule]:NEEDS[TACLifeSupport]:HAS[@RESOURCE[Supplies]] { %CrewCapacity = 0 // undeployed %CrewCapacityDeployed = 1 // minimum needed to staff the structure, but might be more? // add CrewCapacity on deployment so kerbals can enter it @MODULE[USIAnimation]:HAS[#animationName[Deploy]] { %inflatable = true %InflatedResourceThreshold = 100 %CrewCapacity = #$/CrewCapacityDeployed$ } // add TAC life support MODULE { name = LifeSupportModule } // add TAC resources !RESOURCE[Supplies] {} RESOURCE { name = Food amount = 0 // MKS-Lite provdes 200 supplies, enough for 1 kerbal for ~12 days // this is 4x as much as the standard TAC-LS allowance @maxAmount = 1.097 // enough for 1 kerbal for 3 days @maxAmount *=4 // enough for 1 kerbal for 12 days isTweakable = True } RESOURCE { name = Oxygen maxAmount = 111.038 @maxAmount *=4 amount = #$maxAmount$ isTweakable = True } RESOURCE { name = Water amount = 0 maxAmount = 0.725 @maxAmount *=4 isTweakable = True } } i'm not sure if the CrewCapacity should be 1 (needed to activate the recycle) or more. anyone? as for the Hab Module: // assumptions: deployed HabModule is intended to have a CrewCapacity of 4 @PART[MKSL_HabModule]:NEEDS[TACLifeSupport]:HAS[@RESOURCE[Supplies]] { %CrewCapacityDeployed = 4 // add TAC life support MODULE { name = LifeSupportModule } // add TAC resources !RESOURCE[Supplies] {} RESOURCE { name = Food amount = 0 // MKS-LITE provides 200 supplies, enough for 1 kerbal for ~12 days, or 4 kerbals for ~3 days @maxAmount = 1.097 // enough for 1 kerbal for 3 days @maxAmount *= #$/CrewCapacityDeployed$ // enough for 4 kerbals for 3 days isTweakable = True } RESOURCE { name = Oxygen maxAmount = 111.038 @maxAmount *= #$/CrewCapacityDeployed$ amount = #$maxAmount$ isTweakable = True } RESOURCE { name = Water amount = 0 maxAmount = 0.725 @maxAmount *= #$/CrewCapacityDeployed$ isTweakable = True } !RESOURCE[Mulch] {} RESOURCE { name = Waste amount = 0 @maxAmount = 0.1 @maxAmount *= #$/CrewCapacityDeployed$ isTweakable = True } RESOURCE { name = WasteWater amount = 0 maxAmount = 0.924 @maxAmount *= #$/CrewCapacityDeployed$ isTweakable = True } RESOURCE { name = CarbonDioxide amount = 0 maxAmount = 95.913 @maxAmount *= #$/CrewCapacityDeployed$ isTweakable = True } } note that the reason TAC-LS doesn't add these values automagically to the parts is that CrewCapacity is always 0 during ModuleManager's loading pass (because they're deflated). TAC Life Support patch for the Inflatable Storage Module/Warehouse: @PART[MKSL_ILM]:NEEDS[TACLifeSupport] { @MODULE[FStextureSwitch2] { %textureNames = UmbraSpaceIndustries/MKS-LITE/Assets/SW_01;UmbraSpaceIndustries/MKS-LITE/Assets/SW_02;UmbraSpaceIndustries/MKS-LITE/Assets/SW_03;UmbraSpaceIndustries/MKS-LITE/Assets/SW_04;UmbraSpaceIndustries/MKS-LITE/Assets/SW_05; %textureDisplayNames = Raw Materials;Refined Goods;Supplies;Commodities;Waste %fuelTankSetups = 0;1;2;3;4 } @MODULE[FSfuelSwitch] %resourceNames = Dirt,Ore;MaterialKits;Food,Water,Oxygen;RareMetals,ExoticMinerals;Waste,WasteWater,CarbonDioxide // 35 supplies = two day's worth of storage %resourceAmounts = 35,7;70;1.097,0.725,111.038;35,35;0.1,0.924,95.913 %initialResourceAmounts = 0,0;0,0;0,0,0;0,0;0,0,0; %tankCost = 3500;3500;3500;3500;3500 %tankMass = 0;0;0;0;0; } } i note that as provided, the maximum amount of USI-LS storage available seems really low: two days of supplies/mulch (35 units) vs ~12 days (200 units) in the hab module by default. maybe it should be bumped up? in any case, i've followed the default and provided 2 days of TAC LS/waste storage. if this all looks good and fine i'll upload a pull request.

a query regarding TAC support in MKS-Lite: shouldn't these be showing food & oxygen (instead of supplies) and waste (instead of mulch)? this is with MKS-Lite + TAC, and without USI-LS installed.

i use the following ModuleManager script to fix this and other parts which still use largeControl (for instance, AerojetKerbodyne). @PART[*]:HAS[#TechRequired[largeControl]] { @TechRequired = specializedControl }