Starwaster

Ran into an error placing some boosters in symmetry mode. Log has errors in SymmetryActionFix every time I try to click to place them. Doesn't do it all the time and I'm not sure what the repro is yet. full log file: https://www.dropbox.com/s/ac97rro7hfy3xbw/output_log.txt?dl=1 Excerpt of error. ArgumentOutOfRangeException: Argument is out of range. Parameter name: index at System.Collections.Generic.List`1[PartModule].get_Item (Int32 index) [0x00000] in <filename unknown>:0 at PartModuleList.get_Item (Int32 index) [0x00000] in <filename unknown>:0 at ClawKSP.SymmetryActionFix.UpdatePartAndChildren (.Part UpdatePart) [0x00000] in <filename unknown>:0 at ClawKSP.SymmetryActionFix.onPartAttach (HostTargetAction`2 AttachedPart) [0x00000] in <filename unknown>:0 at EventData`1[GameEvents+HostTargetAction`2[Part,Part]].Fire (HostTargetAction`2 data) [0x00000] in <filename unknown>:0 at Part.setParent (.Part p) [0x00000] in <filename unknown>:0 at EditorLogic.attachPart (.Part part, . attach) [0x00000] in <filename unknown>:0 at EditorLogic.attachSymParts (.[] cAttaches) [0x00000] in <filename unknown>:0 at EditorLogic.UpdatePartMode () [0x00000] in <filename unknown>:0 at EditorLogic.Update () [0x00000] in <filename unknown>:0 (Filename: Line: -1)

As stated, the Mk1 pod has a heat shield and does not require one added. Furthermore re and more importantly, DRE DOES NOT ALTER DRAG AT ALL. I'm not sure what inverted drag really means but it's an issue for you to bring up with Ferram and not deadly reentry.

It's not that SAS code is 'terrible'. It's that stock SAS has no idea how to handle NEAR (or FAR) control surfaces. Or even that they exist as control surfaces. The only control authority it would be able to recognize with certainty is any reaction wheels and gimbaled engines. (as long as they are stock gimbal). That's not a problem with SAS, that's a natural consequence of replacing portions of stock modules that other stock modules rely on.

Oh... I thought maybe you were a composite being, with one part of you being smarter than the other part....

Asteroids are not accorded any special status and will burn up like anything else. I suggest constructing an attachment using the grabber device with a heat shield at one end and radial parachutes or Real Chute's stack mounted (non-cone) chute. Or even using grabber arms, one with a heat shield and the other a chute.

IRL, Apollo deployed its drogues at ~7 km which is consistent with what we've been telling people for the most part. 7km is USUALLY safe, but YMMV. drogue = 24,000 feet = 7317 meters mains = 10,000 feet = 3048 meters

The story of my life...

Here's some values I've tried for Gilly: Not perfect but getting there PQSMod_VertexSimplexHeightAbsolute { deformity = 800 octaves = 10 persistence = 1 frequency = 0.20 } PQSMod_VertexHeightNoise { deformity = 15000 frequency = 1 lacunarity = 2.5 persistance = 0.5 octaves = 6 } PQS { Minmus { maxLevel = 14 maxQuadLenghtsPerFrame = 0.001 PQSMod_VertexPlanet { seed = 23123 deformity = 0 // 5000 colorDeformity = 7000 // 6000 oceanLevel = 0 oceanStep = 0 oceanDepth = 0 oceanSnap = False terrainSmoothing = 0.01 terrainShapeStart = 5 terrainShapeEnd = -5 terrainRidgesMin = 0.4 terrainRidgesMax = 0.5 buildHeightColors = False terrainRidgeBalance = 0.25 order = 11 // Go after VertexHeightMap so we can apply color by altitude } Add { PQSMod_VertexHeightMap // doubles { heightMapOffset = 0.0 heightMapDeformity = 15000.0 scaleDeformityByRadius = false; order = 10 heightMap = GameData/RealSolarSystem/Plugins/PluginData/Minmus2.png } } } } Minmus needs this DLL to work (until Nathan rolls in my pull request) https://www.dropbox.com/s/ydnvp1fz6h9fsf9/RealSolarSystem.dll?dl=1 And this Minmus height map: https://www.dropbox.com/s/datzypft09xbysq/Minmus2.png?dl=1

Yes they can. Do we need some configs that do that? I hadn't thought about landing gear in awhile..... I'll try to sneak it into this update. Oops they already have them... Oops again, ArcFurnace commented on that. Are you talking about someone else's landing gear? B9 or something?

Sure, I might even write up the code and just do a pull request. Along with one that adds heightmap support to the land class mods. (Though it contributes only tiny amounts to vertex modification...)

Ugh, been playing with Minmus. Minmus uses PQSMod_VertexPlanet instead of a heightmap. I got a nice looking Minmus just by editing that in KittopiaSpace but RSS doesn't support PQSMod_VertexPlanet At a bare minimum if we want a nice Minmus we need to add PQSMod_VertexHeightMap, LandControl sections for color.... some of the other vertex modifiers for fine tuning it. Maybe an exported color map and normal map for scaled space. Or add PQSMod_VertexPlanet. (two approaches, tweak VertexPlanet to scale the cliffs or flatten them all completely and add VertexHeightMap with its order before VertexPlanet which will then be used to only handle color. I've tried both approaches and got good results, but again it hinges on VertexPlanet)

I haven't a clue.

Right clicking them doesn't work?

Wow does this mean they all share the same building damage?

There's a problem with the LANTR (aka trimodal NTR) and it's my fault as I wrote up the config for it originally. It has way too much thrust. Not sure how that happened except that I had done up several configurations for different LOX / H2 mix ratios and I might have put in the thrust for a higher LOX ratio. Here's an updated config that's a lot closer to what it should be for a 3-1 mix ratio: +PART[nuclearEngine]:BEFORE[RealFuels_StockEngines] { @name = nuclearEngine-trimodal @author = NovaSilisko, Starwaster @title = LV-N Atomic Rocket Motor, trimodal @description = Despite the big scary trefoil painted onto the side of this engine, its radioactive exhaust, and tendency to overheat, the LV-N Atomic Rocket Motor is harmless. Mostly. This one can inject LOX into the nozzle stream to increase thrust at the expense of fuel efficiency. @MODULE[ModuleEngines] { @minThrust = 0 @maxThrust = 111.2 !atmosphereCurve{} atmosphereCurve { key,0 = 0 925 key,1 = 1 556 } } !MODULE[ModuleEngineConfigs],*{} MODULE { name = ModuleAlternator OUTPUT_RESOURCE { name = U235Rods rate = -0.0000000005 } OUTPUT_RESOURCE { name = DepU235Rods rate = 0.0000000005 } OUTPUT_RESOURCE { name = ElectricCharge rate = 3.0 } } MODULE { name = ModuleGenerator //resourceThreshold = 0 isAlwaysActive = true OUTPUT_RESOURCE { name = ElectricCharge rate = 1.5 } OUTPUT_RESOURCE { name = DepU235Rods rate = 0.0000000005 } INPUT_RESOURCE { name = U235Rods rate = 0.0000000005 } } RESOURCE { name = U235Rods amount = 5 maxAmount = 5 } RESOURCE { name = DepU235Rods amount = 0 maxAmount = 5 } MODULE { name = ModuleHybridEngine configuration = Hydrogen techLevel = 5 origTechLevel = 5 maxTechLevel = 8 engineType = N origMass = 6.8 CONFIG { name = Hydrogen thrustVectorTransformName = thrustTransform exhaustDamage = True ignitionThreshold = 0.1 minThrust = 0 maxThrust = 111.2 heatProduction = 300 fxOffset = 0, 0, 1.0 PROPELLANT { name = LqdHydrogen ratio = 1.0 DrawGauge = True } PROPELLANT { name = U235Rods ratio = 0.00000000001 } atmosphereCurve { key = 0 925 key = 1 556 } IspSL = 1.016483516483516 IspV = 1.016483516483516 } CONFIG { name = LqdHydrogen+LqdOxygen thrustVectorTransformName = thrustTransform exhaustDamage = True ignitionThreshold = 0.1 minThrust = 0 maxThrust = 303.9466 heatProduction = 325 fxOffset = 0, 0, 1.0 // Assuming LOX / H2 ratio of 3-1 (mass) // 0.6941 Isp // volume ratio conversion // 1.141 kg LOX (1L) x3 // // 1.141 kg LH2 (16.10444601270289L) // mixture ratio by mass: // = 0.003423 kg O2 // = 0.001141 H2 PROPELLANT { name = LqdHydrogen ratio = 16.10444601270289 DrawGauge = True } PROPELLANT { name = LqdOxygen ratio = 3.0 DrawGauge = False } PROPELLANT { name = U235Rods ratio = 0.00000000001 } atmosphereCurve { key = 0 642 key = 1 386 } IspSL = 0.6941 IspV = 0.6941 } } }

Either that or his RCS isn't well balanced.

Although I personally can handle 0.5, it's difficult enough that I can't help thinking most of DRE's users would find it too painful. Though it could maybe go in Hard mode. I seem to recall it was set to that before and there was much weeping and gnashing of teeth Have you tried B9's landing gear? Even if you keep nothing else from B9, it's worth it for the landing gear. (and the air brakes. And that.... short squat engine thing.... and the S2 cargo bay that I made an S2->Mk2 adapter for Porkjet's SpaceplanePlus...)

The normal map is not properly marked as a normal map. Renaming it to *_NRM makes a difference. not sure why except that Unity or KSP checks the filename and knows to treat it as a normal map. The alternative is to import the texture into the Unity3d editor and assign it as a material's normal map or edit an object's texture and try to assign it to the object's texture as a normal map. Under the normal map preview box it will tell you it's not marked as a normal map and gives you the option to do so. Then just re-export the texture as part of some dummy object (export it using the KSP plugin). The resulting texture file will be properly marked as a normal map. Replace the original with that file.

I love the idea that players should have choices and should be allowed to use what they want and do what they want. But a modder is under no obligation as to whether or not he/she offers you that choice. Because it's HIS choice as to whether or not to offer or support 64 bit. And it supplants yours by simple virtue of the fact that for you to have your choice, he has to make that offering and cannot be forced to do so. SHOULD not be forced to do so. But you still have a choice. You can download Github for Windows, clone the source, download Monodevelop, remove the offending bit and recompile. If you lack the knowledge, that sucks but the modder still doesn't have to accommodate you.

Out of the question. A body is mandatory. If Red is not available or eligible then you may substitute a 100 liter tank of hydrazine. If hydrazine is not available then you may substitute chlorine trifluoride.

Progress report: Ok, so I know I said I was going to try to push an update out over the weekend and obviously I'm still working on that. I'm starting to get things to where I think they ought to be at least for Normal mode. A bit of warning, it's going to be a little bit deadlier, even for stock sized Kerbin. I still have to test it without any drag modifiers. (no FAR, no NEAR, no SDF). Here's some of the more prominent changes (aside from the toolbar and difficulty settings) First, know that these still aren't engraved in stone! I'm still doing some test flights to be sure that things are still flyable without being too hard. I don't want my RCS engines burning off anymore than you guys do. And I want my spaceplanes to be able to make it to orbit without incinerating themselves! So if these numbers go into production then it means I can do launches and reentry without dying, and so can you! SO: 1: Max temperatures are being slashed across the board for everything except heat shields and engines. The new max temperature on parts is 700 degrees. I based that on the melting point of aluminum but gave it a bit of a safety buffer for playability Heat shields have long had a hard coded exemption that prevented them from being reduced and I added a similar case for engines. Engines won't be cut unless they are over ~1400. (based on steel's melting point but buffed a little) Those maxes are actually per difficulty level so Easy will have higher tolerances. (except that I think it will require a game restart for that to go into effect, or at a bare minimum, exit to main menu might be enough) What it means for ascent and reentry: No shallow launches! That's really always been true but now just a little more so. If your flight path during ascent is too shallow then you'll be going too fast when you're too low in the atmosphere and you'll burn bits off. But it's still quite doable to get to orbit whether you're using RSS, FAR or whatever. 2: Density coefficient is dropping from 0.85 to 0.8 for normal. Easy will keep it at 0.85 or possibly raised. (I don't think it really needs raising but... it's on the table). Hard will likely see it lowered. (haven't really committed to that but I'm looking at a value of 0.5 - 0.7). What it means: Things will get hotter faster. During reentry you'll see hotter temperatures at higher altitudes. For a stock Kerbin reentry that will mean peak reentry heating at 45-50 km depending on if it's an LKO or return from Münar space. (haven't tested with a Minmus return but I'd expect it to be a bit hotter. For Real Solar System, that will result in reaching peak heating at about 70km (which is about right for real life) Easy Mode: Parachutes will be more durable by about two times as much as they currently are. Kerbals will be more resistant to g-forces. Heat shields: I'm looking at making these scale up in efficiency when using them with Real Solar system without having to download separate shields. This shouldn't affect the current RO shield download.... much.... or at all hopefully. I'm probably forgetting something, but that's the important stuff I think.... Some minor stuff: Some data that is currently persistent no longer is. This means that if certain config file data is changed, those changes will now apply to saved games. (for example, certain heat shield stats such as loss / dissipation. Currently if those are changed, existing craft don't have those changes applied. Now, they will) Edit: Oh, chutes. Chutes will be patched so that their default values are safe®. Kerbin is the benchmark for those values (which is true even in Stock KSP) Edit #2: And chutes in cone housings will have weak heat shielding (reflective only, 0.1) so if they're acting as nose cones on the tops of rockets, they'll provide some protection against heating. BUT, only if they haven't been deployed at all. As soon as the cap has blown they're open, just as they should be.

I'll have to think on it. I know there's an event that fires for both loads and changes. onEditorVesselChange? Or some such. I wasn't aware it also happened for subassemblies.

Ok I just downloaded enneract's latest branch and crew do randomize when a pod is placed that will have crew assigned to it. But it's not working for ships loaded into the editor. (as in a craft file)...... I honestly can't remember if that was something that was working in the older versions. I think it was unless I just didn't notice.....

alt+D+R to bring up the debug menu. You could reduce heat multiplier to reduce the amount of heat you're getting but that's affects everything not just space planes. You'll basically neuter the whole mod. What I recommend instead is that your spaceplane launch and reentry procedures need some consideration. If you're burning up on launch then you need either a steeper ascent or you need to keep your velocity down until the upper reaches of the atmosphere. For descent you need a much shallower reentry than if you were coming down in a capsule. Stay in the upper atmosphere as much as possible. From entry interface to landing should take about half the planet.

This is also worth mentioning for just about any planet: Hit it from behind if at all possible. I tried a reentry on Laythe where I hit it oncoming. Literally a headon collision with the atmosphere. No reentry profile could salvage it and I tried quite a few. I ended up quickloading and looking for a course correction that would carry me around Jool and intercept Laythe from behind. Today I'm testing a variety of planets to see how some of the settings I'm testing will hold up. I used MechJeb's porkchop plotter to find me the fastest possible path to Eve and it took me high up out of Kerbin's orbital path and then back down to intercept Eve as it passed. Gave me a very nasty reentry with over 6km/s orbital.