Starwaster

Maybe. The remote control thing looks promising. Is it KAS capable out of the box?

Not an SDHI issue; he's not doing anything with SDHI that affects the capsule itself. I'd take a look at Advanced Texture Management and check its settings for Squad.

The field is PhysicsSignificance and if it's not present then it uses its default value. Disabled would be PhysicsSignificance = 1 It's an enumerator not a boolean so the above is not the same as 'true'. So PhysicsSignificance = 0 (default) is physics enabled. PhysicsSignificance = 1 is physics disabled. Edit: More info. You're not going to be able to affect landing gear physics with the above because the PartModule involved will override it no matter what you set it to in the file Edit #2: FSWheel landing gear does not override physics (that I can tell) but landing gear that use FSWheel still exhibit the same sliding behavior. I have to concur with Random Tank. This is more an issue with the gear not being perfectly aligned, and it might NOT look like it is, but a degree of difference of even 0.0001 off will throw you off course when you approach takeoff speeds.

This sounds like a similar conversation we've had in the past. How is the PartModule being added and what version of Module Manager? Versions of MM pre-2.2.0 will delete PartModules that were dynamically added regardless of what data they were storing. Admittedly there might be a problem going on with 0.24.x's new module fixing code but you don't even have to look there for potential problems as Module Manager has been a culprit in that regard long before 0.24 Edit: I strongly advise removing Module Manager from the equation when testing for this if you really think it's Squad's new code that's at fault. Use a testing environment that doesn't even include Module Manager and only add PartModules via edited part files. I really cannot understate the capacity for Module Manager to destroy persistant data (prior to version 2.2.0)

Yes, he's talking about the Hubmax and it does indeed have issues in how it connects to another Hubmax. Place one Hubmax then grab another Hubmax out of inventory and try to place it. You can connect the 2nd one to the bottom of the first one by the 2nd one's top node, but if you try using other nodes to connect to/from you'll run into problems. It will snap as you described but not actually connect. That's a stock problem when editing the craft in the VAB/SPH. It does not affect docking at all.

What he posted was a complete part configuration, intended to replace what's in the lab's part file. It's not meant to be used as a Module Manager patch as is. To know why yours isn't working you would have to post your MM code and someone can look at it and fix it. Or you can edit the original file and replace it with what he posted. (not advisable because if you ever delete and reinstall the original files then you will lose your changes, so a MM patch is best) Edit: Here's an alternate config that you can use as an MM patch. (just put this into a file named zzz_science.cfg) @PART[sci_generic] { TechRequired = fieldScience entryCost = 15000 //MODULE //{ // name = ModuleEnviroSensor // sensorType = ACC //} !MODULE[ModuleEnviroSensor]{} !MODULE[ModuleEnviroSensor]{} !MODULE[ModuleEnviroSensor]{} MODULE { name = ModuleScienceExperiment experimentID = seismicScan experimentActionName = Log Seismic Data resetActionName = Delete Data useStaging = False useActionGroups = True hideUIwhenUnavailable = False resettable = True resettableOnEVA = False xmitDataScalar = 0.6 } MODULE { name = ModuleScienceExperiment experimentID = crewReport experimentActionName = Crew Report resetActionName = Discard Crew Report reviewActionName = Review Report useStaging = False useActionGroups = True hideUIwhenUnavailable = True rerunnable = True xmitDataScalar = 2.0 } MODULE { name = ModuleScienceContainer reviewActionName = Review Stored Data storeActionName = Store Experiments evaOnlyStorage = True storageRange = 4.0 } MODULE { name = ModuleScienceExperiment experimentID = mysteryGoo experimentActionName = Observe Mystery Goo resetActionName = Reset Goo Canister useStaging = False useActionGroups = True hideUIwhenUnavailable = True resettable = True resettableOnEVA = True xmitDataScalar = 0.4 FxModules = 0 } MODULE { name = ModuleScienceExperiment experimentID = mobileMaterialsLab experimentActionName = Observe Materials Bay resetActionName = Reset Materials Bay useStaging = False useActionGroups = True hideUIwhenUnavailable = True resettable = True resettableOnEVA = True xmitDataScalar = 0.2 FxModules = 0 } MODULE { name = ModuleScienceExperiment experimentID = barometerScan experimentActionName = Log Pressure Data resetActionName = Delete Data useStaging = False useActionGroups = True hideUIwhenUnavailable = False resettable = True resettableOnEVA = False xmitDataScalar = 0.6 } MODULE { name = ModuleScienceExperiment experimentID = gravityScan experimentActionName = Log Gravity Data resetActionName = Delete Data useStaging = False useActionGroups = True hideUIwhenUnavailable = False resettable = True resettableOnEVA = False xmitDataScalar = 0.6 } MODULE { name = ModuleScienceExperiment experimentID = temperatureScan experimentActionName = Log Temperature resetActionName = Delete Data useStaging = False useActionGroups = True hideUIwhenUnavailable = False resettable = True resettableOnEVA = False xmitDataScalar = 0.6 } MODULE { name = ModuleDataTransmitter packetInterval = 0.3 packetSize = 2 packetResourceCost = 15.0 requiredResource = ElectricCharge DeployFxModules = 1 } }

Thanks btw, it's actually 0.25 per day (Earth days) but the VAB rounds up to 1 significant figure. If you right click on the capsule in flight it will report more accurately.

output_log.txt (or player.log for Mac or Linux) To find your log file: Windows: KSP_win\KSP_Data\output_log.txt Mac OSX: Open Console, on the left side of the window there is a menu that says 'files'. Scroll down the list and find the Unity drop down, under Unity there will be Player.log Aka Files>~/Library/Logs>Unity>Player.log Linux: ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log NOT ksp.log file. Especially not ever.

output_log.txt (or player.log for Mac or Linux) These logs are updated constantly while you play and are created even if the game does not crash. (don't let anyone tell you otherwise) To find your log file: Windows: KSP_win\KSP_Data\output_log.txt Mac OSX: Open Console, on the left side of the window there is a menu that says 'files'. Scroll down the list and find the Unity drop down, under Unity there will be Player.log Aka Files>~/Library/Logs>Unity>Player.log Linux: ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log

I think part of what you're describing is the stock finickiness with stack nodes and their order in the part file.... And the other part sounds like misconfigured attach nodes....

Adding an atmosphere isn't necessary, at least not for heat only effects. If you want actual drag then, yeah I guess you could add an atmosphere but I think you'd burn up before actually reaching it. But for just heating, all you need to do is edit the sun's temperatureCurve. You could also do it with Real Solar System... I *think* you could even do it 'out of the box'... have to look into that. If it's not currently possible, the changes necessary should be trivial. Need more info; what settings did you change, DREC settings? If so, what specific changes did you make? And is it a stock Kerbin environment or Real Solar System?

I've added a new version of the AnimatedDecoupler that implements Sarbian's x64 decoupling fix. I've not had a chance to test it and will not be able to test it in a 64 bit environment anyway. Try it out if you experience decoupling force problems using 64 bit KSP only. Don't use it if you don't have trouble with decoupling force in 64 bit KSP. https://github.com/Starwaster/AnimatedDecouplers/blob/X64/AnimatedDecouplers.x64.zip If anyone needs to report issues with the plugin, please use the issue tracker on the plugin's issue section on its Github page. Edit: I'll still answer queries or requests re: the plugin here, but I could miss it here...

I haven't done anything with O2 consumption rates. However, please look at the page before this one at my discussion with StainX. To sum up that discussion: All consumption rates are reported in Earth days, not Kerbin days. One of our days is ~24 hours long. A Kerbin day is 6 hours long. If your game settings are configured to display time in Kerbin days then there's going to be a mismatch in the numbers reported. One change I would like to make in the near future, but have not had time to work on, is to make Ioncross aware of player settings so that it can adjust reported rates. That said, I will also be going over consumption rates and will ensure that Kerbals are consuming ~2/3rds of the resources of a human astronaut on standard EVA/IVA workload. BTW, I also added resource cost to Oxygen so when you buy a tank of it now, you're also paying for the O2 inside. I won't have much time over the next few days to work on Ioncross as I'm going away to spend some time with my ailing grandmother, which might be the last chance I have to do

Can't do it with only Module Manager. MM can only make changes that you would be able to make by editing a part configuration file, and the engine just can't be configured to be externally activated. It would require someone to either code that kind of functionality into a new engine class (which possibly has one of the stock engine classes as its parent) or possibly functionality incorporated into KAS that allows it to access other PartModules like the engine ones. Maybe KAS already has that ability; I don't know. You might want to inquire in its thread.

even in real life, satellite constellations have to deal with drift all the time and routine corrections are necessary....

Yes, nothing mod related should be going anywhere but GameData these days in their own mod folders. the plugins, resources, plugindata, internals or parts off of the main KSP folder are legacy from the old days. I've accidentally put things in them recently and KSP didnt work properly when I did. they shouldnt be used anymore.

Yes, it is. It's still the same build but nothing really changed to affect it. I'm using it with the latest KSP.

New update is up on Curse. Fixes the EVA resources not being loaded. I was racking my brains on this thinking that maybe Yongedevil hadn't gotten around to implementing that part, but the more I traced the code, the less sense it made that it wasn't working. (loading/restoring happens at a lower level class; the same code worked fine for other derived classes of the base class...) Turns out it was just one line of code that was checking for a config node that was under a different name... Also fixed a problem with recyclers having 0 amounts of ElectricCharge. (0 is bad, mkay?) And I reverted a change I made to CarbonDioxide resource that the recyclers don't seem to like anymore

I'm working on a minimalist set that makes Life Support even simpler. Also... coming soon....

I would swear I saw in the code that they are ignored.... I think the stock game even ignores them for heat....? dont hold me to that though.

What was your velocity and air pressure? (or altitude and body if you're not sure) Short story though is that for purposes of shielding, chute modules are treated differently than regular parts if the chute is deployed. If other parts are hot enough to be destroyed (without shielding) then your chute should also be getting destroyed if deployed. (just the chute, not the chute part. The chute would effectively be 'cut') Older versions of DREC would just treat the chute module as unshielded no matter what parts were in front of it.

Deadly Reentry. Don't open your chutes until outside temperature (roughly equal to velocity in m/s) is less than halfmthe chute module's max heat rating. The only type of damage resistance altered is max heat which is reduced. DREC acceleration damage is something extra it does not linked to a parts ability to withstand impact. Sounds like you have something else (not-DREC) modifying impact resistance.

No, that's not normal. Logs. (Chris, I suggest the following as an official response from now on.... "Logs or it didn't happen!" )

The intention is for you to put your own decoupler there. I think there's a blank decoupler module so that MechJeb will recognize that there is a stage there but that's all. That's why there's an icon. (of course, you could always edit the part and change it to a real decoupler.... I did:P)

OK, EVA resources are definitely being saved. They just aren't being LOADED. .........usually. They might be loaded sometimes.... Also, the NaN thing seems to be a separate issue.... but related issue because display module info isnt being loaded... Also, recyclers have an issue relating to them having 0 ElectricCharge. That used to be OK and had special meaning to KSP's resource flow rules. Now it just breaks things. I'll post a hotfix part file later but for now either dont use the recyclers or edit the part file and change amount / maxAmount to 1. or delete the resource entirely...