FlowerChild

I'm uncertain what might be going on there. I just checked over the config file for the Mk1-2 to be certain, and there aren't any other heat settings that are modified by it that would explain that behavior. Weighing in at 4 tons, it should also take it a good long while to decelerate from orbital velocities, which should be plenty to cause it to burn up. You are reentering from orbit right? Not just a straight up and down to space? Unless you're going to rather extreme heights, the latter really shouldn't destroy anything.

Yeah, the capsule has a max temperature of around 2400 Kelvin, while the rest of the parts tend to max out at or under 2000. That's something else that's easy to change through a MM patch though: @PART[Mark1-2Pod] { @maxTemp = 2000 // 2400 stock }

Download ModuleManager (http://forum.kerbalspaceprogram.com/threads/55219), drop the code I posted to a .cfg file in your GameData directory, and there you go Well, you're definitely not alone in that. My mod tends to cater to such players (those that play career anyways), and there's quite a few of us that prefer to play that way. The above adjustment I posted, is actually straight out of it. Not sure if it will solve your mk1-2 woes alone as I made a bunch of other adjustments to it as well, but I suspect it will do the trick.

I've also gotten good results with 120% heat settings and just by applying a blanket modifier to the thermal mass of all parts to make it a fraction of what it is in stock with the following module manager config: // assign all parts that don't have an explicit thermal mass modifier, a default value of 1 @PART[*]:HAS[~thermalMassModifier[]]:Final { thermalMassModifier = 1.0 } // set all thermal mass modifiers to a fraction of their value @PART[*]:Final { @thermalMassModifier *= 0.1 } This essentially causes parts to heat up much faster than they would normally, which makes all but the gentlest reentries difficult to survive without a heat shield.

Fair enough man. When a code segment can easily be run a couple of thousand times a second though, I just tend to wince when I see unnecessary conditionals thrown into the mix

While I agree, I will also note that not addressing such low hanging fruit that has no impact on code readability or maintainability is probably a close second in the evil department I also have no idea what you're planning in terms of expanding on the code in question that would make it "premature". Perhaps, but I think what was more concerning to me was the overall trend there. There was really no solid reason that I could discern for the stuff I mentioned.

Hey James, I'm finally getting to integrating the newest version of BP with my slow process of porting BTSM over to KSP 1.0, and looking over some of the code, I'm getting a little worried about the performance impact of some of the newer stuff. In particular, with SolarPanel.cs I'm a bit concerned over the number of conditions that have been added to what is essentially a tight inner loop. Like, with all the Addon.Debug() statements, each of those involves a condition testing if the message is above the current debug level set in the config file. Now, with that one, hopefully branch prediction will minimize the impact of it, but it still seems rather excessive to include that kind of thing in such a performance sensitive portion of the code. Also, with stuff like this: if (!Addon.config.solarOrientationMatters) { orientationFactor = 1; Addon.Debug("Orientation disabled in config file", DebugLevel.ALL); } if (!Addon.config.solarTemperatureMatters) { tempFactor = 1; Addon.Debug("Temperature disabled in config file", DebugLevel.ALL); } It worries me that regardless of the settings, the full calculations for orientation and temperature are performed first, and only afterwards are those values overridden depending on the options. In other words, even if the computed values aren't used, they're still being calculated, when whether they should be calculated or not could just as easily be tested beforehand. Obviously, speed of execution is a big concern with something like BP, and solar panels are probably the biggest potential issue there.

The options for the poll are really a bit off. It's entirely possible to think that it hasn't improved the game without thinking it takes all the challenge out of it. Personally, I don't think it improves the game because the investment in player time required isn't compensated for by the benefits provided. I mostly play career, and will say that this point isn't just exclusive to sandbox In career, if it takes you more time to save some funds than it would take you to earn them through doing contracts, then why bother? I feel that's currently the case with the resource system. It's a cool thing to do once. However, after that the realization rapidly sets in that it's not really practical and you're probably better off just taking a few more contracts to make up for the cost of shipping the extra fuel to orbit.

Drew Barrymore.

That's good news James! So far I've just been using a recompiled version of the last one I rigged up for 0.9, but that's only because I've yet to get to the point where solar panels are unlocked in the mod. I don't envy that task man, as I could see it getting messy real quick. I'm actually ditching both of them for BTSM, as well as solar panel heat affecting energy output.

Imperceptibly better thrust? It's like 200 vs 170 thrust at sea level for the LV-T30 vs T45 with ISP factored in. Not sure what kind of rockets you're building where a 15+% increase in thrust on liftoff (when you need it most) isn't noticeable, but I'll take it any day.

I'm not sure I understand that bit, at least not the gameplay part: the LV-T45 seems to be balanced as a mid-stage engine with a lower thrust to weight ratio, but with thrust vectoring (which you need higher up as you can just use fins lower down). If the ISPs were reversed, you'd end up with a mid stage engine with no thrust vectoring, and a lifting engine with crappier thrust to weight.

Hmmm...that's a fair point. I've mainly been focusing on serially staged designs early in my mod's tech tree, but I can see them working much better as a central core with radially staged boosters or asparagus designs. Still though, I'd say they have nowhere near the same level of relevance as previously, as you just don't spend as much time in-atmo. Don't get me wrong, I'm certainly not pining for old aero or what have you, but I do think the new has brought a number of other issues to the surface that essentially boil down to Kerbin being tiny.

I think it would, and this largely comes down to an issue with the size of Kerbin. Yes, it loses 50% of its thrust at sea level, but atmospheric pressure drops off so quickly due to the lack of depth to the atmosphere relative to earth, that it would rapidly become quite efficient. Already, with the thin shallow atmosphere in 1.0, I find that mid-stage engines like the Skipper and LV-T45 have pretty much lost all relevance, because you just don't spend enough time in atmosphere thick enough to be significant for them to really come into play. If in-vacuum engines were better in atmosphere, this problem would become even worse and you could get away with extremely short first stages followed immediately by in-vacuum engines. I've been doing a lot of tweaking of the engine values for my mod, and while I initially balked at the extremely low in-atmo ISP of vacuum engines, the more I worked with the numbers, the more that aspect made sense to me.

I'm honestly undecided on this one. On one hand, it does seem like an artificial constraint. On the other hand, during play it's lead to some interesting decision making that I can't really debate against. I think it might be justified thematically in terms of Kerbal engineering only being capable of handling a certain degree of complexity before stuff begins to fall apart...maybe The limitations on actions groups though...yeah, that's just lame. I really don't think a pure GUI convenience like that should be in any way associated with in-game progression. It's basically just forcing the player to have to suffer through right-clicking on parts to access the various menu items until they research/build something, which is an extremely odd blurring of the lines between in and out of game. Why are the Kerbals aware of and studying the buttons I can press as a player? I dunno, but I think it's beginning to make me a little nervous

What I would debate in that is whether it is just for the sake of realism, which I think is an invalid assertion. I really don't care about the realism of having different roles for different engines, but what I do care about is that it provides me with additional rocket design constraints that keep me engaged while playing. I like having a wide range of variables to consider while putting together a rocket beyond just how it looks. To me, the justification for that lays with gameplay, not realism, whereas the argument for free-form creativity lays with aesthetics, and not gameplay. To use a chess analogy, the knights aren't restricted to a L-pattern move because of realism. It's in no way realistic. However, it does make for an interesting tactical, and thus gameplay, consideration. Depending on the set, whether the knight looks like a medieval knight on horseback, or Chewbacca, is also entirely irrelevant to the gameplay itself.

a) Everyone knew about it. Wow...way to go in abusing early access.

Yeah, the biome maps have been a mess in this way pretty much since they were added to the game. I've been considering trying to setup a system to filter them and convert to more reasonable values based on longitude and latitude to at least get rid of some of the sillier ones like tundra and Munar poles near the equator and such. Those ones in particular are a shame as they're a big motivation towards putting things in polar orbits rather than just equatorial all the time.

It makes me sad that so many of these debates get labeled as "game vs realism". I'm strictly a game guy, and in no way view realism as a valid argument for putting anything into a game on its own, yet most of the time, I find myself siding with the realism side of things. Why? Because games have rules and need interesting constraints in order to be compelling. Otherwise they're just toys. I don't think free form creativity has anything to do with a "game", or that people arguing for it are pro-game as opposed to pro-realism. Being able to instantly move across the board on a whim in Monopoly doesn't encourage creativity, it just breaks the game. That really has nothing to do with realism, and everything to do with needing to have meaningful constraints for a game to be interesting. And even in terms of toys, many of the real classics operate on constraints to make them more interesting. Take Lego for example. The shapes you can build are constrained by the pieces at your disposal and how they fit together. Regular blocks are far more free form, yet have nowhere close to the same level of popularity, and it's fairly natural for a child to "graduate" from blocks to Lego at a certain stage of development, I think largely due to it creating a more interesting puzzle for their minds to ponder while they simultaneously express their creativity. Really, I think if that kind of entirely open creativity is what someone is after, they should probably learn some 3D modelling or CAD software so that they can properly express themselves with tools ideally suited to doing so, and stop expecting games to somehow provide them that same degree of freedom.

Thanks Nathan! That all makes a lot of sense

Thanks man. I was not aware of that, as I had never run into it before. Is that a single-character wildcard, or is it specifically for spaces? Apologies for the erroneous bug report then.

Just a small bug report. Not sure if this was always the case as I wasn't modifying this particular resource before 1.0, but the "EVA Propellant" resource has a space in it that MM doesn't seem to like, so something like this: @RESOURCE_DEFINITION[EVA Propellant] Will generate a MM error during load, but with no reporting as to the cause other than the file name that contains the patch. Worked around it with this: @RESOURCE_DEFINITION[EVA*] So not an issue for me, but just wanted to give a head's up on this in case someone else runs into it.

IMO, the 50% thing is just a faulty solution to a game design problem that further obfuscates what's going wrong: Zero throttle, new players quickly learn they need to throttle up or their engines don't work. Experienced players quickly identify what they did wrong when they occasionally forget, and it winds up feeling like the player made the mistake, not Squad. It's a clearly identifiable problem for which an in-game solution is provided. 50% throttle delays new players learning that they need to throttle up and causes their otherwise valid designs to underperform or crash back into the launchpad. Meanwhile, flames are shooting out of their engines, indicating that they are indeed working, and thus that must not be the source of the problem (which it actually is). Experienced players may not identify if they have forgotten until mid-flight, usually resulting in a revert, largely wasted time, and a bit of swearing at Squad. 100% throttle, I doubt this thread would even exist or anyone would be complaining. The odd fringe design where it's not appropriate, players would likely know to throttle down before launch, and if they didn't, would receive ample feedback to know what went wrong (like stuff exploding). IMO, the worst case of those three was selected for some strange reason, like some kind of mathematical compromise that doesn't actually make any sense in practice was chosen. I guess 25% would be even worse, but not much else would be

Exactly. And if you can watch this and still think they didn't know precisely what they were doing when they bought it: Well, then I don't know what to say As for the question in the OP: that's just silly. KSP is an awesome game I love to death, but Minecraft is a once in a lifetime cult phenomenon. It's like asking if Battlestar Gallactica will be the next Star Wars.

More power to you for doing your own thing and sticking to your guns on it man. "Rock on"