[1.12.*] Deadly Reentry v7.9.0 The Barbie Edition, Aug 5th, 2021

[AbeS]

Will it be 'possible' that we can turn off FAR for landing or have some method of it working with MechJeb for Landings and such. Any method so that FAR and MJ play well together would be great. does not have to be perfect, but just so they will be 'kind' to each other.....

Then all would be perfect, I love DRE, FAR and MJ... Thanks for asking and thanks for all of your work, to all.....

The landing autopilot is made to work is stock frag model which is very very simple and easy to work with (mathematically speaking) FAR makes it have lots of variants, like angle of attack and stalling, center of lift position, top or bottom heavy lander, altitude and velocity, is it aerodynamic or not... I'm not saying it would be impossible but compared to the default and easy to calculate drag model it would require lots of work!

[drtedastro]

The landing autopilot is made to work is stock frag model which is very very simple and easy to work with (mathematically speaking) FAR makes it have lots of variants, like angle of attack and stalling, center of lift position, top or bottom heavy lander, altitude and velocity, is it aerodynamic or not... I'm not saying it would be impossible but compared to the default and easy to calculate drag model it would require lots of work!

Thanks for reply. I was 'guessing' as much. I was hoping that there might be some method (button) that would basically ghost out any FAR, for the initial part of the landing, and then I could bring it back online once the burns were over. Oh well, always something to think about... I certainly know that what FAR does is out of my normal sphere of guestimation and work....

Again, thanks.

[dtobi]

Hi Nathan,

I made sone animated parts that are supposed to work with deadly reentry (two inflatable heatshields that actually have adaptive buoyancy when in water and a number of heat tiles). I am not sure what values to put into the config file. Would it be possible to send you a preview of the mod so that you can suggest some values? I'd hate to accidentally create super parts.

Edited December 15, 2013 by dtobi

[Goozeman]

Thanks for reply. I was 'guessing' as much. I was hoping that there might be some method (button) that would basically ghost out any FAR, for the initial part of the landing, and then I could bring it back online once the burns were over. Oh well, always something to think about... I certainly know that what FAR does is out of my normal sphere of guestimation and work....

Again, thanks.

Don't give up quite so easily. The trick to precise landings with FAR is to design such that your reentry vehicle has a stable axis. If you do that, then Cd is a function of Mach number only, so it is possible to do some calculations. Basically, check out the 7 Minutes of Terror video that NASA put out for the Curiosity rover. Aeroshells and powered landings are your friends.

Edited December 15, 2013 by Goozeman

[drtedastro]

Absolutely... The problem I am having is that when I select Landing Guidance for my capsule, the initial part of the de-orbit burn goes fine, but then all gets confused and ends up creating a terribly elliptical orbit and not de-orbit... Numbers, I believe, that MechJeb are looking for are zeroed or corrupted by FAR currently or other way around.

I love my skycranes and other 'fun' devices... I am just looking for method(s) to automate repetitive tasks for building bases and such.... I would rather build and design than pump stick and fly... got the flying bug out of my system long time ago....

DrTedAstro.

[AbeS]

Maybe try KOS, you would have to spend some time creating your programs, but you can make it do almost anything you want with your ships (if you know how to)

[drtedastro]

I will look at it again. Seems to be running hot and cold. I think the Dev is taking some RL time (as he should , and all Dev's should)... Might dig into that after holidays.....

[Ghostbird]

DRE segfaults my game during the black loading screen that occurs between the splash loading screen and the main menu. Any idea what can cause this?

Oddly enough, the second time I tried to start KSP with DRE, it worked flawlessly. But the first time it segfaulted, and every time after the second time it segfaulted as well. That one time was running really well, and I managed to get a fairly heavy (15+ tons) lander into orbit and back on Kerbin safely, but when I circularised into orbit on a second test flight, the game crashed my graphics card, which is unrelated to DRE. Stock KSP .22 is simply ridiculously unstable.

I'm running Steam KSP .22 on GNU/Linux Mint 13 with Cinnamon.

I've tried:

• Running DRE with mods (FAR, RealChute, RemoteTech2, MechJeb2)
  
• Running DRE on stock KSP
  
• Running DRE alone (without Squad folder in GameData)
  

All three methods yield the same crash.

I've tried removing the GameData/DeadlyReentry folder and running KSP with the mods mentioned above, which works perfectly. (Still very unstable, but still but no segfault upon load.)

Stacktrace from GDB¹:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff7fcd780 (LWP 4893)]
0x0000000040272aee in ?? ()
(gdb) bt
#0  0x0000000040272aee in ?? ()
#1  0x0000000000000594 in ?? ()
#2  0x00007fff8c871588 in ?? ()
#3  0x00007fff8c8715d8 in ?? ()
#4  0x00007ffff25b1fe0 in ?? ()
   from /home/username/Steam/SteamApps/common/Kerbal Space Program/KSP_Data/Mono/x86_64/libmono.so
#5  0x00007ffff6595720 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#6  0x000000001b6f9740 in ?? ()
#7  0x0000000000000018 in ?? ()
#8  0x0000000000000000 in ?? ()
[Thread 0x7ffff1eea700 (LWP 4894) exited]
[Thread 0x7ffff1e59700 (LWP 4895) exited]
[Thread 0x7ffff140e700 (LWP 4897) exited]
[Thread 0x7ffff0c0d700 (LWP 4898) exited]
[Thread 0x7fffebfff700 (LWP 4899) exited]
[Thread 0x7fffd3ffe700 (LWP 4905) exited]
[Thread 0x7fffd37fd700 (LWP 4906) exited]
[Thread 0x7ffff019b700 (LWP 4907) exited]
[Thread 0x7ffff03ff700 (LWP 4908) exited]
[Thread 0x7ffff7fcd780 (LWP 4893) exited]
Program terminated with signal SIGSEGV, Segmentation fault.

I think KSP does not leave crashlogs or crashdumps, so I cannot tell what exactly is wrong. I read online that crashdumps e.a. should be created in the main KSP install directory, but my KSP never creates any such files. There are three reasons I can think of:

1. KSP doesn't have a SIGSEGV eventhandler and does not nicely handle segfaults, it simply terminates immediately, which would be very strange, especially for a game still in development that is reliant on the players for bug reporting.
   
2. Steam KSP doesn't have the debug facilities the normal version has. Yes I've run KSP directly and without launching it trough Steam, for debugging purposes, but it still is the binary packaged with Steam, which may or may not differ from the one from the KSP store.
   
3. KSP for GNU/Linux has a bug that prevents correct SIGSEGV handling and/or crashdumps/reports.
   

1) The GNU Project Debugger, not to be confused in KSP context with the GDb (The KSP GameDatabase).

[amo28]

I assume you're running the x86_64 bit KSP client on a 64 bit OS.

Have you followed all of the instructions in the Linux Compatibility thread? Specifically the 64 bit fix from a.g. found here?

I'm using KSP x86_64 bit client on a 64bit OS and DRE v4 and have not had issues like you're seeing. If you've gone through the Linux thread already and are still having trouble, your installation of KSP may be corrupt. Especially if you're seeing it as extremely unstable. Most 64 bit Linux users will tell you that, after a few tweaks, it's incredibly stable. Like, incredibly stable.

[Ghostbird]

I assume you're running the x86_64 bit KSP client on a 64 bit OS.

Have you followed all of the instructions in the Linux Compatibility thread? Specifically the 64 bit fix from a.g. found here?

I'm using KSP x86_64 bit client on a 64bit OS and DRE v4 and have not had issues like you're seeing. If you've gone through the Linux thread already and are still having trouble, your installation of KSP may be corrupt. Especially if you're seeing it as extremely unstable. Most 64 bit Linux users will tell you that, after a few tweaks, it's incredibly stable. Like, incredibly stable.

Well I'll have another look at the Linux compatibility thread. I read it before, but at that time I was just reading through, without looking for anything specific. KSP often crashes my graphics card, leaving me no choice but to switch of my machine's power and reboot, and often crashes when it has to spawn ghost copies while building something symmetrically, most often with air intakes I think.

EDIT: I have found nothing definite on the Linux Compatibility Thread, but I'm going to try A.G.'s fix for the libpng miscompilation. Though I don't think that's the issue, since: It is only supposed to happen on the x86_64 version (for me it happens on both), and it should happen without DRE as well, yet for me DRE is the definite factor that causes the crash (removing DRE immediately solves the problem), also my stacktrace is different.

EDIT: I found where KSP on Linux stores it's Player.log files, the bad news is, that there is still no data on the crash in there.

EDIT: The forums will not allow me to view the thread for A.G.'s fix because I lack permissions. That's weird.

Edited December 16, 2013 by Ghostbird

[sal_vager]

Ghostbird, maybe this will help?

http://forum.kerbalspaceprogram.com/threads/24529-The-Linux-compatibility-thread!/page41?p=806007#post806007

Don't try to open the settings file in the terminal, just open a terminal in the same folder as the settings.cfg

[Ghostbird]

Ghostbird, maybe this will help?

http://forum.kerbalspaceprogram.com/threads/24529-The-Linux-compatibility-thread!/page41?p=806007#post806007

Don't try to open the settings file in the terminal, just open a terminal in the same folder as the settings.cfg

Ah thanks, that is a patch for the binary.

Is this the a.g.'s patch? It seems to change two highly specific code addresses in the binary. I'm always amazed that people manage to find such fixes.

Alas as I feared (My stacktrace was quite different from that of people that needed the patch, and my KSP only has problems with DRE), this did not fix my problem.

The good news is, my KSP runs fine (both x86 and x86_64) when I run it from terminal (no idea why, crashed before). However the crash is still persistent when I start the game trough steam. Which is kind of a shame, since I normally chronicle all my missions on my Steam profile screenshots. I've already tried restarting Steam, and adding different launch options in Steam, but that didn't help. Also it doesn't matter whether I launch x86 or x86_64 trough Steam. Both crash. No crash log is given, and the GDB stacktrace is the one I gave before.

So on the positive side: I can happily play with DRE. Alas I cannot screenshot my magnificent craft explosions, nor my successful landings for my Steam profile. I'll happily run it from terminal though, since the new .23 is slated for the day after tomorrow, and I'll have to restart my save anyway most likely since it seems to be a significant overhaul.

[FlowerChild]

(FlowerChild, I know right now you don't support FAR, but you were looking into it with KIDS. How much of an issue would it be for you if DRE required FAR?)

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

Edited December 16, 2013 by FlowerChild

[FlowerChild]

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.

Edited December 17, 2013 by FlowerChild

[NathanKell]

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.

IIRC, the default version of Isp adjustment for KIDS is "assume SRBs are sea-level rated". Instead you should choose the version of thrust adjustment where EVERY engine and SRB is assumed to be vacuum rated. That'll cut sea level thrust to, say, ~92% of what it was. But it sounds more like just an issue where stock KSP solids have pretty ridiculous burn times for their thrust, if used as cores rather than boosters. Remember they're SRBs, not SRMs. Especially since you're using them for starting probes, you might want to make (or grab from MFS) 0.5x rescales of the two solids, for use with probes.

Also, you should definitely use HoneyFox's thrustCurve plugin (available from source or from the Space Shuttle SRB Replica thread); that lets you set a curve (like atmosphereCurve or velocityCurve) that takes burntime and outputs thrust multiplier.

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.

Actually, you've been mistrained by KSP's [lack of an] aerodynamics model. In FAR terminal velocity is completely respected; it's just that the TV of an object is, well, real--unlike stock KSP. In stock KSP (1) the atmosphere is assumed to be pea-soup thickness all the way up to 10km or so and (2) all vessels are assumed to have the same coefficient of drag and the same ballistic coefficient (that of, basically, the blunt end of a capsule), whereas in FAR the terminal velocity of a pod at sea level is ~100m/s or less, whereas that of a nice pointy rocket is >400m/s (both as in real life), and density (and with it, drag), decreases appropriately with altitude.

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

That, of course, I can't argue with.

It's amazing what going from "doesn't have an aerodynamics model" to "has a very realistic one" does...

Now that I've said all that, I actually really like your proposal, if you're indeed willing to take that on I think it makes the most sense by far (heh). The one thing I'd ask is that you keep "stock-DRE" available as a standalone rather than it being integrated into BTSM, so people who don't want to use full BTSM (although...why? ) and don't want to use FAR (again...why?) have an option. Although, since DRE is share-alike I don't think the license you have for BTSM would allow that anyway.

Uh, but wait a day or two before forking? There's some stuff I have to commit tomorrow that taniwha (uber-generous soul that he is) fixed for me while I was working on Stretchy, that I have locally but haven't posted yet.

[FlowerChild]

IIRC, the default version of Isp adjustment for KIDS is "assume SRBs are sea-level rated". Instead you should choose the version of thrust adjustment where EVERY engine and SRB is assumed to be vacuum rated. That'll cut sea level thrust to, say, ~92% of what it was. But it sounds more like just an issue where stock KSP solids have pretty ridiculous burn times for their thrust, if used as cores rather than boosters. Remember they're SRBs, not SRMs. Especially since you're using them for starting probes, you might want to make (or grab from MFS) 0.5x rescales of the two solids, for use with probes.

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

Actually, you've been mistrained by KSP's [lack of an] aerodynamics model. In FAR terminal velocity is completely respected; it's just that the TV of an object is, well, real--unlike stock KSP. In stock KSP (1) the atmosphere is assumed to be pea-soup thickness all the way up to 10km or so and (2) all vessels are assumed to have the same coefficient of drag and the same ballistic coefficient (that of, basically, the blunt end of a capsule), whereas in FAR the terminal velocity of a pod at sea level is ~100m/s or less, whereas that of a nice pointy rocket is >400m/s (both as in real life), and density (and with it, drag), decreases appropriately with altitude.

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.

That, of course, I can't argue with.

It's amazing what going from "doesn't have an aerodynamics model" to "has a very realistic one" does...

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

Now that I've said all that, I actually really like your proposal, if you're indeed willing to take that on I think it makes the most sense by far (heh). The one thing I'd ask is that you keep "stock-DRE" available as a standalone rather than it being integrated into BTSM, so people who don't want to use full BTSM (although...why? ) and don't want to use FAR (again...why?) have an option. Although, since DRE is share-alike I don't think the license you have for BTSM would allow that anyway.

Uh, but wait a day or two before forking? There's some stuff I have to commit tomorrow that taniwha (uber-generous soul that he is) fixed for me while I was working on Stretchy, that I have locally but haven't posted yet.

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.

[jrandom]

My first thought is "what is FAR's drag model for that probe?". That might be the number to adjust if FAR is seeing it as a highly-aerodynamic part.

[AbeS]

@FlowerChild that vessel exploding is totally what I would expect: Because it has a lot of thrust it gets to high velocities quickly, because it is going so fast at such a low altitude drag forces tear it apart like they should!

[NathanKell]

FlowerChild: That probe looks like it would have a Cd of approx 0.01 or so, which is 1/20th what stock KSP assumes. That's on the order of a normal rocket's Cd (~0.002 or so?) so terminal velocity will be far higher. What you need to look at in FAR's panel is the Frac SL Density (the current atmospheric density) and, once you open the flight details, the current Cd (coefficient of drag) and reference area (multiply the two for a sense of how much drag you're getting).

So your terminal velocity at sea level should be ~400m/s, and probably closer to mach 2-3 some km up. Note that FAR doesn't change visual effects; they don't mean "over terminal velocity", they just mean "fast."

I can't argue with feel, except to say that KSP _really_ trains us wrong. Especially since KSP rockets are *denser* than real-world rockets, and should suffer less drag as a result!

That said, it _does_ indeed change the feel of the game (in atmosphere at least). Thus if you want an experience like stock KSP--replete with "get clear of the soup before you pitch over", low terminal velocity, and limited aerodynamic forces (i.e. you don't flip out or disintegrate for not flying forwards)--then itt's really hard to replicate with FAR.

Regarding DRE:

Oh, cool! (Although it's not really my work either, just some maintenance and a few new features. ). I'm absolutely down with it, and BTSM (like the little I know of BTW) is a class act; I have no worries there.

And you've already been super helpful on this thread, doing the balancing-for-stock-KSP work that I never got done myself, for example.

[FlowerChild]

FlowerChild: That probe looks like it would have a Cd of approx 0.01 or so, which is 1/20th what stock KSP assumes. That's on the order of a normal rocket's Cd (~0.002 or so?) so terminal velocity will be far higher. What you need to look at in FAR's panel is the Frac SL Density (the current atmospheric density) and, once you open the flight details, the current Cd (coefficient of drag) and reference area (multiply the two for a sense of how much drag you're getting).

So your terminal velocity at sea level should be ~400m/s, and probably closer to mach 2-3 some km up. Note that FAR doesn't change visual effects; they don't mean "over terminal velocity", they just mean "fast."

I can't argue with feel, except to say that KSP _really_ trains us wrong. Especially since KSP rockets are *denser* than real-world rockets, and should suffer less drag as a result!

That said, it _does_ indeed change the feel of the game (in atmosphere at least). Thus if you want an experience like stock KSP--replete with "get clear of the soup before you pitch over", low terminal velocity, and limited aerodynamic forces (i.e. you don't flip out or disintegrate for not flying forwards)--then itt's really hard to replicate with FAR.

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

Regarding DRE:

Oh, cool! (Although it's not really my work either, just some maintenance and a few new features. ). I'm absolutely down with it, and BTSM (like the little I know of BTW) is a class act; I have no worries there.

And you've already been super helpful on this thread, doing the balancing-for-stock-KSP work that I never got done myself, for example.

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!

@FlowerChild that vessel exploding is totally what I would expect: Because it has a lot of thrust it gets to high velocities quickly, because it is going so fast at such a low altitude drag forces tear it apart like they should!

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.

Edited December 17, 2013 by FlowerChild

[jrandom]

Personally, I feel that regardless of whether or not you want a simulation or a game, you need FAR. The stock atmosphere is so horridly wrong. I hate it. Drag based on mass?? NO! BAD! WRONG WRONG WRONG!

FAR should be the one absolutely-required mod put before all others. The rest of the simplifications made in KSP are fine. Small world, dense rockets, etc, etc... they all help balance out the gameplay. But that atmosphere... argh. I would go so far as to call the stock drag model "severely broken". Replace it. If part of BTSM doesn't seem to be FAR-compatible, change BTSM.

[FlowerChild]

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.

Edited December 17, 2013 by FlowerChild

[Ghostbird]

I'm running FAR and DRE both happily. I guess my rocket designs just aren't that good, since they fly with FAR similarly to how I would fly them in Stock KSP. The main difference is that with FAR I need some winglets on the bottom sections of the launch stages to avoid tipping over the craft.

Also I have to throttle down far more than I used to, and keep my ship at low speeds until I'm high up, otherwise it will destabilise horribly due to drag, and start to flip over.

EDIT:

But I have realised a bit of how the shrunk KSP solar system affects things, and I think that for .23 I'm going with the RSS in addition to DRE, FAR, and RealChute, and maybe some other realism mods.

[jrandom]

Also I have to throttle down far more than I used to, and keep my ship at low speeds until I'm high up, otherwise it will destabilise horribly due to drag, and start to flip over.

Build taller, skinnier rockets, and build them so your at-launch TWR is around 1.2.

[Ghostbird]

Build taller, skinnier rockets, and build them so your at-launch TWR is around 1.2.

I have indeed been reducing my TWR a lot. Normally in KSP you'd need 2.2 TWR to get a rocket up, and I guess I'm too used to designing them that way. Most of my rockets now have 1.8 to 2.2 TWR.

And I always build my rockets tall and skinny. I've seen a lot of awesome things at the forums, but the launch vehicles often look more like a hockey puck tan a rocket, and I can't really bring myself to build something that un-rocketlike.

Anyway, I'm back here, since my DRE struck again. For unknown reasons the game doesn't run from terminal anymore, and the Steam version isn't working yet either. I didn't change anything since last time, so I'm a bit surprised. I have some ideas that may cause this problem, but no known way to verify or fix them.