FlowerChild

Oh no worries man, I worked around it in my own code, which is why I only brought this up when the above post reminded me of what happened there. What I was doing was creating a sub-class of ModuleEngine that added in thrust corrector code ala Arctures or KIDS for the FAR integrated version I was working on. When I figured out what was causing the above problem, I just created a part module separate from the engine one to do the same thing, so it all worked out.

Nathan: just in case you hadn't already figured this out, I suspect the above is due to the hardcoded search for ModuleEngines within the DR code which then special cases how the mod handles them. I ran into a similar problem with some custom BTSM engines I had created (custom in that I had created a child class off of ModuleEngines for them) where they were overheating extremely rapidly and then exploding with a G-force message due to them not being found by that code. The exploding would also occur at odd times when the heat meter hadn't even filled up on them. It also occurs to me that maybe said code is only setup to handle 1 engine module per part or something, which might be why it's not handling the 2nd one appropriately in this case. Anyways, not entirely certain if that applies to the RAPIER as well, but the above description sounded eerily familiar to me, so I just thought I'd throw that your way in case it saves you some searching.

Yeah, excellent thread idea. I was just browsing looking for something on this subject I don't have any info to add to this yet, but I was wondering if anyone had discovered a way to disable existing tweakables on parts. For example, I have some custom engines that I'd like to disable the thrust limiter tweakble on either through code or config. Any ideas?

Cool, yeah, I realize that bit about fins adding stability relative to the current velocity, and the attitude of the rocket being perfectly centered on the velocity vector in the above screen supports that's what is happening here, so I guess I'll just chalk it up to launch pad instability. Thanks for taking the time to respond Ferram. Much obliged.

Hmmm, it's possible, but I've been locking it down with launch stabilizers, and while other designs tend to diverge slightly from vertical, it's *really* pronounced with this one with as you can see above, it hitting close to a 45 degree pitch only 1500m off the launch pad. It flies very similar actually to when I've tested launching blunt nosed designs and they're unstable as a result. As an aside and just to verify: static fins should act to stabilize flight with FAR installed, correct?

Ferram, any idea why a design like this might not fly straight up without any control input? It seems to have a tendency to veer over as pictured which I haven't encountered with other designs. Note that while I added fins (those are static ones in 4 way symmetry, they aren't control surfaces) on that last test, it seems to behave pretty much the same without them. I'm a little puzzled as to what is causing it, or how to correct it, and was hoping you might be able to spot something I missed

Ah, cool man, thanks for the response. Just wanted to make sure I wasn't missing some crucial distinction in adding in my own solid rockets

Nathan, just to return to this point: I took note of it and tried to do a little research online as to the difference between the two, and as far as I can tell, it's just a difference in nomenclature to designate a motor's usage within a particular rocket design rather than an actual physical difference. Am I wrong there? Is there some aspect of design (other than the obvious like decoupling method) which is different, that I am missing there?

Well, there's no yelling involved in any of this, and I hope it wasn't taken that way, but understood

Hehe...actually, as an experienced modder, no, I wouldn't be at all surprised by how little people read Despite that, it's not something for which I have a better idea to suggest. Unfortunately, the interface method itself is a tad obtuse and without some kind of formal explanation won't necessarily be intuitively figured out by the player.

Fair enough, but since the toolbar API is integrated directly into the mod, that's not necessarily apparent either. Also, with KSP's tendency to miss interface clicks, I think I had even tried clicking the little arrow previously, and when it didn't work the first time, assumed that wasn't how the thing worked. I'm an extremely experienced game player, programmer, and designer, and again, it took me half an hour of fiddling, looking at config files, and searching the thread to finally figure out something that is rather trivial in the grand scheme of things just to start playing with FAR installed. I mention it now, not because it benefits me as I already know how it works, but rather to benefit other players who will also likely be confused by it, and Ferram himself who will likely have to answer the question of how to do it many times in the future. When you've already been using something for awhile and have become habituated to it, things like this are not necessarily apparent anymore. To paraphrase one of my favorite quotes by Doyle Brunson "things only seem obvious a few minutes after you figure them out"

Ferram, just as a small request, it might really help if the above was in the readme or elsewhere in the instructions for the mod. I just spent a good half hour fiddling with how to move the button as it was covering rather crucial interface elements, before finding this post. It also really doesn't follow any existing interface convention I am familiar with, so it's not particularly intuitive

Time to install a little BTSM then man... (sorry for the OT Ferram, couldn't resist the gag when I read the above )

The thing is, the more you dig into it, the more of a tangled mess you realize all these aspects of the game are. Many things, like Kerbin being smaller than earth, factor into how the aerodynamics work. It's not as simple as use FAR or don't, as using it changes a lot of aspects of the game, and very much how it feels, beyond such things as drag not being based on mass or what have you. Like I mentioned previously, I like a lot of things about how FAR works (drag model included), however, striking the balance between any kind of vanilla "feel" and using FAR is not a simple matter once you start looking into it. Even with KIDS installed or corresponding ISP adjustments, how the game plays is radically different in areas you might not initially expect. This isn't at all the fault of FAR. As far as I can tell, it's working exactly as intended, and is an awesome mod. Anyways, this is all getting rather off topic for the DR thread, so I'll respond to any further posts on the topic over on the BTSM one.

Thanks for the explanation man. The probe core is indeed a spherical shape and thus I would expect it to be aerodynamic. The speeds seemed like a bit much, but much like my earlier perceived problems with the heat shields in DR, hearing that it is indeed working as expected goes along way in easing my concerns As for the soup and such, yeah, these are the kind of problems I'm wrestling with at present namely, how far to stray from the vanilla feel with BTSM. KSP already straddles the line between simulator and game, and there's also a high degree of uncertainty as to where it's going in the future. Is Squad really going to implement a different aerodynamic model at some point? Reentry? Life support? I've seen mention of such around the forums, but who really knows? They call the current builds "sandbox complete" which says to me that the core mechanics are set and won't be changing, but I also see a lot of mentions they're still working on them which contradict that. So, where to set the realism bar is a rather big question mark if I want to retain a vanilla feel to BTSM, as I'm not even sure if Squad knows where it's going to wind up I do know however, that in terms of KSP being a game (as opposed to a simulator), that people's perception of realism is often more important than actual realism. I'll give an example of what I mean by that: About 20 years ago Jane's Simulations put out a game called Longbow 2. Both the press and players went wild over how it was the most realistic depiction of a helicopter ever found in a PC game. At one point, PC Gamer magazine brought in an actual Apache pilot, and after sitting him down in front of the game for awhile asked "so how close is it to the real thing?" The response was: "Not at all". After a good laugh when I read that, the lesson I learned from it that really stuck with me was what I said above: that it's people's perceptions of how reality behaves that will determine how realistic they view a game to be. Thus whether something "feels" right became way more important to me as a designer than whether or not it accurately reflects how reality actually works You mention how vanilla KSP trains us to think things should work a certain way, and I wouldn't argue otherwise. The problem being that by this point, I think most KSP players have been so thoroughly trained in this matter that genuine attempts at simulation wind up feeling "off" by comparison and act counter to suspension of disbelief during play as a result. So where to draw the realism line with KSP? I dunno yet, but it's something I'm actively pondering Oh yeah, I realize you're maintaining the mod in the absence of the original author. I just wouldn't want to be in the weird position of having an ambiguous package where it can easily be misinterpreted that I created DR or something. Just doesn't feel right to me. And thanks for the rest of what you said there man. I put a ton of work into BTSM, and I'm still entirely uncertain as to how the KSP community tends to view it (or if they're noticing it much at all), so the recognition there is much appreciated Since we seemed to be agreed on the point of a branch then, feel free to just fire me a PM when you think the timing is right and I'll get to work on it! The probe I pictured has a custom engine part on it that I configured not to do that. The acceleration going up wasn't what I was talking about there, rather the acceleration as it was in free fall on the way down Also, didn't explode on descent. Was just going hela-fast.

Yup, I'm actually way ahead of you on this one, as the following was the result of some of my initial tests at tweaking BTSM to integrate FAR yesterday I dunno man. What I pictured above was basically the probe in question, and I was still accelerating in free fall a few KM up (don't remember precisely but it was pretty darn low like 2-4Km) and was over Mach 1 complete with visual effects to indicate as much (nose down). It felt really off. Again, I'm not an expert by any means, but it wasn't at all what I would expect. Oh, and there are certainly many aspects of that I would like to have. Nosecones actually being effective for example instead of just dead weight...fixed fins acting to stabilize a rocket instead of whatever the heck it is they're doing now in vanilla...parts applying drag relative to how they are placed rather than just as some universal constant. To me, beyond realism, that all leads to interesting rocket design constraints that amount to interesting gameplay that I'd very much like to be part of BTSM and which I find are sorely lacking from vanilla. However, where my hesitation is coming in is with regards to the cost to benefit ratio of how much work it will take to balance for it at present, and how far off the end result will be from what stock players are used to. I still haven't made up my mind on it, and am still weighing various options, all that's really happened is that FAR integration has gone from a definite for me to a question mark while I think it over further Oh dude, I wasn't even suggesting integrating it into BTSM. Even if the license allowed it, or I modified the BTSM one to accommodate doing that (really, I just have that set to "all rights reserved" as I don't want to deal with licensing stuff and would prefer to be asked about specific usage to leave myself wiggle room to say "no" when something doesn't seem right), I wouldn't want to based on my own personal principles with regards to mod packs. DR is NOT my work, and I would not want to represent it as such. Also, what I'd be doing there would be of benefit not just to BTSM players, but to stock players in general, so I think keeping it separate makes total sense for that reason as well, and allows me the flexibility to still make whatever BTSM tweaks might be appropriate in that specific context. So yeah man, if you're down with it, then I'm happy to do so. Just let me know when the timing is good for you, and we can arrange the details Thanks for the trust that involves man. Like I said, I haven't been in the community long, so I very much appreciate the vote of confidence the above implies.

Actually, Nathan, I've been thinking about the above, and I think I may have come up with a possible solution: It strikes me that both of us are basically going in two very different directions, with you focusing on realism, while I'm focusing on more of a vanilla gameplay feel. This means that we will likely be wanting different things out of DR that will likely go beyond just parameter tweaks, and will also be catering to a different player demographic. So, what I wanted to propose, is that if you're cool with it, I'd be willing to maintain a separate branch and version (even a separate thread) for say a "Deadly Reentry Stock", while you could focus on say "Deadly Reentry Realism". I think this might simplify matters for us both greatly. Like, you seem to get a lot of posts from vanilla players that just want reentry effects that wind up being confused by the parameters and such, which you could just direct over my way. Meanwhile, if players are looking more for the realism overhaul type thing, I could send them your way. We could each provide default values for our separate versions to help avoid additional confusion amongst players, and also evaluate any modifications to the existing code base solely on its merits for our chosen playstyle. We would likely also both benefit from having a 2nd set of eyes in the code as we could share any bug fixes we make. To give you an example, even with regards to the modifications you were talking about above to heat shields, I'm frankly happy with them the way they are now, now that I've gone through and tweaked the values. The thought of rebalancing for a new system, which I don't suspect will have much impact on my chosen playstyle anyways, isn't exactly appealing to me. However, I don't think that should in any way discourage you from making those changes, as they'd certainly advance things in the direction you want to go. Anyways, just an idea man. I definitely wouldn't be offended if you're not keen on it, as I haven't been part of this community for very long, and thus I realize that my credentials might not be readily apparent. However, if you're down with it, I'd certainly be game.

Oh yikes....quite an issue actually I played around with BTSM in combination with FAR and KIDS yesterday, and I can't say I'm really a fan of the results. The thing is, even with ISP adjustments, rockets tend to behave in a very different manner than they do without FAR installed. The total fuel consumed to reach orbit and such may be roughly equivalent, but their behavior in atmosphere is still radically different. For example, they tend to accelerate way too fast relative to stock, which with my early game tech tree, and in combination with DR, winds up making them burn up in the atmosphere on the way up (my early tech is all solid fuel rockets, so no throttle control there). Using the KIDS option to have ISP affect thrust doesn't seem to help that either, which kind of surprised me. Another thing which kinda gives me pause is they seem to accelerate way beyond terminal velocity in freefall. I had one probe going over mach 1 in freefall yesterday after running out of juice while still in the atmosphere. Now, I am in no way an expert on aerodynamics, but that seems really off to me. So, my overall impression is that integrating FAR into BTSM would be a bit of a balancing nightmare, and I'm not certain I'd be happy with the end results either as one of my goals has been to retain vanilla's "gamey" feel with BTSM, and FAR seems to take the overall feel of the game rather "far" from vanilla I'm still pondering various potential solutions, but yeah, integrating FAR is not currently something I am as keen on as I was previously. Don't get me wrong, there's a lot of good in FAR, but I'm just not certain integrating it is the right move for a mod like BTSM. Having said all that, DR is your mod man, so please don't let any balancing issues that it may cause me affect your decision either way if you feel it is the right choice

Nathan, if you will forgive a moment of self-promotion, I've finally publicly released the mod I've been talking about so much here if you'd like to check it out: http://forum.kerbalspaceprogram.com/threads/61632-Plugin-0-22-Better-Than-Starting-Manned-Career-mode-redefined?p=837988#post837988 Please let me know if the way in which I reference Deadly Reentry is cool, as I definitely don't want to cause any offense with any of this. Once again, mucho thanks once again for all the help you've provided in making this happen

Well, the post I made about it contains a link straight to the .cfg file for ease of installation, and I'm totally cool with you linking to that elsewhere as well. Do what you want with it man, I'm good with it One thing I wanted to mention is that I've also modified the descriptions for the different heat shields within my own mod and it corresponds to the information I provided within that post as to the purpose of each shield. If you like, I can include those in the .cfg file as well as it may save you some tech support I didn't include them in the original though, as I wasn't certain the extent of modifications which was appropriate. Anyways, let me know if they'd be of use to you and I'll post them up if so.

Not at all man. Although it makes me think that I probably should have asked you if this whole "required mod" thing I'm doing is cool with you, and if it's all right that I'm passing around links to the DR thread to people But yeah, feel free to provide a direct link to that config file. I may ping you in the future if any further balancing is required on the late game heat shields, as that's something I'm in the process of play testing in my own mod right now. Well, "late game" in terms of the way I think of them with my own tech progression as atmospheric entries on other planets is something I've pushed way up towards the end of the tech tree

Ok, this has been a long time coming while I worked on balancing my own mod, but here's the custom config settings that I promised for people that want a more challenging DR experience with stock sized Kerbin and otherwise stock install. I've tweaked them to present a real challenge for those that find default DR values way too easy, while maintaining vanilla's "gamey" feel, and personally find them to fit in very well with the rest of vanilla KSP. Just drop the following file into your Gamedata/DeadlyReentry folder and you're good to go: Download Link If you already have a custom.cfg file in that directory, you will likely need to delete it in order for these changes to take effect. I've tried to balance it so that the 1.25m heatshield (and the Mk1 capsule integrated shield) are effective for reentry from low Kerbin orbit. 2.5m on a direct return trajectory from the Mun. 1.25 effective for small probes entering thin atmospheres (like Duna), and 3.75 effective for entry and aerobraking maneuvers in thick atmospheres like Eve or Jool. I've left the reflective heat shields at default values given they get rid of a percentage of the heat accumulation regardless of other settings. I will warn that I have not fully tested the 1.25 and 3.75 heat shields yet to make sure they really fill their roles, so they may require further tweaking down the road. I've tested the other values though many many times over to ensure they're capable of doing the job they're intended for. For reference, here's the contents of the config file in question: // config file to rebalance Deadly Reentry parts and stock parts with DR heat shields for stock game feel. @REENTRY_EFFECTS[Default]:Final { @shockwaveExponent = 1.09 @shockwaveMultiplier = 1 @heatMultiplier = 25 @startThermal = 250 @fullThermal = 1150 @temperatureExponent = 1.03 @densityExponent = 0.85 @gToleranceMult = 2.5 @crewGClamp = 30 @crewGPower = 4 @crewGMin = 5 @crewGWarn = 300000 @crewGLimit = 600000 @crewGKillChance = 0.75 } // Command Pod MK1 @PART[mk1pod]:Final { @MODULE[ModuleHeatShield] { @dissipation { @key, 1 = 800 480 } } } // 1.25m Heatshield @PART[1.25_Heatshield]:Final { @MODULE[ModuleHeatShield] { @dissipation { @key, 1 = 800 480 } } } // Heat Shield for Mk 1-2 Pod @PART[2.5_Heatshield]:Final { @MODULE[ModuleHeatShield] { @dissipation { @key, 1 = 800 240 } } } @PART[0625_Heatshield]:Final { @MODULE[ModuleHeatShield] { @dissipation { @key, 1 = 800 640 } } } @PART[3.75_Heatshield]:Final { @MODULE[ModuleHeatShield] { @dissipation { @key, 1 = 800 60 } } } Note that I've also reduced the visible threshold on the reentry effects from what they normally are in DR for more flamey goodness. Keep in mind I've done this to present a good gameplay challenge in keeping with the spirit of my own mod, NOT for realism. If that's the kind of thing that you're personally looking for, then you may want to give it a try.

Man, I've been heavily into this modding game (mostly Minecraft, just really starting on KSP) for quite awhile now, so boy do I hear you. I've been biting my tongue at a lot of the more demanding posts I've been seeing in this thread as a result, and I guess that one I responded to just happened to catch me in a particular mood. Anyways, suffice it to say I greatly appreciate what you've been doing here, and am entirely sympathetic to a lot of the baggage that comes along with providing people with free content. Way too often "here's some cool stuff I made!" seems to only be responded to with "but I want it in blue!" I've yet to go fully public with it (getting very close now, but I might wait for .23 since it sounds like it's coming soon), but DR has made an absolutely HUGE difference to the overall quality level of my own KSP mod through making it a required install to go along with it, and already a lot of people are getting a great deal of enjoyment out of it as a result. I'm extremely grateful for the work that you have put into making that possible.

Yup, it's entirely possible that it wasn't the intention, I just think it's worth keeping in mind the context in which mods are developed, and that phrasing things as a request rather than as a demand or expectation goes a long way in showing appreciation for the effort involved in providing the rest of us with free entertainment. When I see phrases like "you should" or what have you, directed at a modder, it tends to get my goat as a result From experience, I know that dealing with an ungrateful and demanding public is a surefire way of killing a modder's spirit, when without any real profit motive, they are often just providing this stuff out of good will and enjoyment of making mods as a recreational activity. I also know that often times when I pop into this thread (and many KSP mod threads for that matter) to see what's been going on there's an awful lot of "I want" from the public relative to the gratitude expressed for what's already there.

That's rather rude man. You realize you're getting this software for free right, and that it is likely being developed as a hobby? If an angle of reentry indicator is something that is of such importance to you, why not look into developing it yourself? In other words, why isn't it on your own todo list? I've encountered very few mod devs as friendly and helpful as Nathan. I thus find it rather depressing at times that this thread often seems to be so heavy on demands for new features, and so seemingly light on gratitude.