Starwaster

The next DRE will make manned missions to Venus.... even MORE interesting.

Time zones??? NO! What madness is this? What the hell are you talking about? What are these... time zones? Just hearing about it makes me want to rage quit and post in Comic Sans!

Re: KSP 1.3.0 As everyone is probably aware of by now, KSP 1.3.0 has been released The latest build of DRE is 99.999999% certain not to be compatible with 1.3.0 at all on the grounds that anything not re-compiled for KSP 1.3.0 will probably CRASH the game before it gets to the main menu. I don't know for certain that it will crash 100% of mods so I allowed for 0.000001% chance that it wouldn't, but let's be honest: It's probably going to crash 100% of anything not recompiled against the 1.3.0 binaries. My plans are to finish work on the current build of DRE (which abbreviation I notice STILL hasn't gotten any mouse-over abbreviation love ) release that update for KSP 1.2.2 followed by an immediate release for KSP 1.3.0 That probably should take less than a week.

Actually, stock drag calculations aren't applying drag to 'inline' parts, except as appropriate for their angle of attack. If the parts are all the same size and the angle of attack is zero then they won't get any drag. As I said earlier, those red drag arrows that you can turn on do not tell you what you need to know when looking at a part's drag.: Let's look at the rocket below: The action menus for both the nose cone on the front and the top most fuel tank on the stack are showing. Notice that the tank's YP and YN faces of its drag cube show 0.00 : 0.00. That means looking along its long axis (its Y axis) it has zero cross section exposed and its drag coefficient is zero. Looking at its drag you will see that is has much less drag than the nose cone. The only reason the tank has ANY drag right now is because of the angle of attack. What that means in terms of the drag cube is that one or both of either the X or Z faces are exposed so we're getting some drag from those. If the angle of attack had been zero then there would be no drag on the tank. If I'd taken the time to load in an OPT craft with K parts, or any other parts, the results would be much the same. So, what I'm trying to get across to people here, is that there actually isn't a problem at all. The drag that people seem to think is happening on the 'inline' parts just isn't happening like that.

@captinjoehenry @TheKurgan Those screenshots don't really provide much useful drag information. Specifically the Aerodynamic Forces Overlay. What you really need to be looking at is the aerodynamic debugging available in the action menus (alt-F12 -> Physics -> Display Aero Data In Action Menus) With that enabled you can see if a part is shielded or not in the cargo bay (will say 'Shielded: False' if it's not shielded) I'm looking at the K parts right now and I do see contents being shielded in the cargo bay. I can also see that K parts that are attached to cockpits and other K parts ARE properly drag occluded, but it's also dependent on how MUCH of the part is occluded. The J-K adapters for instance will naturally have parts of them exposed to the airflow. And angle of attack plays a part there because obviously if you're angled up a bit (even half a fraction of a degree) then the belly is getting airflow. It doesn't take much to get you a nice fat juicy red drag vector (drag is based on velocity squared after all)

It doesn't matter how hard it is or how simple it is because those are just technical problems to be overcome (have been overcome) There are no technical reasons keeping there from being a delta-v readout in the editor.

I apologize for responding to this so late but... this is just so fundamentally WRONG. The ability to calculate the delta-v available to a rocket is NOT an upgrade. It's part of 'The Rocket Equation'. No. Scratch that. It IS 'The Rocket Equation' and it is SO old that (thanks to Russian scientist Konstantin Tsiolkovsky) we knew how to calculate the delta-v of a rocket LONG before anyone could even BUILD rockets, certainly as a mode of transportation. The equation is over 100 years old and was the result of work started in the late 1800s. For a game about rockets to so thoroughly ignore the most historically important aspect of them continues to boggle the mind.

I don't think OCD can be fixed. Maybe the parts could be made to appear in the right tab instead?

@Bornholio Your Cygnus is probably using the ServiceModule type, which assumes vacuum bottles and/or vapor cooled shielding. I used Apollo service module data to determine leakage. Heat leakage was low enough that they had to use heaters to keep tank pressure up to feed the fuel cells and ensure that enough O2 was available for human consumption And, something else you might or might not be aware of is that if your vessel is unloaded for more than a few minutes: Analytic mode kicks in and yeah, that does tend to raise your temps up obnoxiously. Obviously that's another area that needs addressing. My current modding priorities are Finish the current new update for DRE before KSP 1.3 if possible get Ioncross Crew Support back up and running Go back to Real Fuels + Heat Pumps to further address analytic mode boiloff and cryocooling. (which will be done concurrently to ensure they work properly together)

Well, as I've also said before,MJ's accuracy is comparable to real life landers. If you look at the accuracy of past Mars landers, we've gotten more accurate over the years, but the most accurate lander so far was Curiosity and that required active guidance

If you're talking about the cryotanks with the simpleboiloff plugin, you should only use one or the other. Neither stock radiators nor this mod will prevent Cryotanks boiloff because they use a static method which is independent of heat. They don't have increased boiloff rates as they get hotter and don't stop boiling if you cool them down. The reverse would also be true in that any mitigating system they have for preventing their tanks from boiling off wouldn't work for Real Fuels. Also, I know NOTHING about their tank parts and I have no idea if they are properly configured for passive insulation. (i.e. they would have to have RF MFT modules with the Cryogenic type)

Some of the reported errors did result in actual problems, to be fair. The problem is in taking those errors into multiple unrelated forums and complaining when there are still issues after a recommended troubleshooting step intended for ONE of those issues doesn't fix the others as well. (case in point: recent Real Fuels postings where a step intended to deal with the Real Fuels issue didn't correct the other errors which weren't even related to RF - a step not even followed properly after the person did his own thing)

The current build doesn't consume any resources during analytic mode. A future build will look at net power generation/drain to determine if it should request resources or not. As far as storing the pre-analytic value, I'm not really clear on what you're suggesting, and where you're suggesting it be done? (Heat Pump? Real Fuels? Remember that there is lowered capacity to do anything to another part in analytic mode.)

@Bornholio 100x timewarp isn't treated any differently in stock. GREATER than 100x is where analytic starts, unless you or a mod has changed that. If it's stopped working during time warp then I have to assume that analytic mode has kicked in. I DID have hopes that I would be able to get both Real Fuels and Heat Pumps working with analytic mode properly but I didn't properly understand the nature of the problem, even though NathanKell and I had some discussion about analytic mode and the interfaces that would go into place to allow us to interact with it. He even asked me for input about what those interfaces should do, but I don't think we really understood the problem, not even Nathan even though he coded much of it. The problems are: Analytic mode assigns a temperature for the entire vehicle, not on a part by part basis. Heat flux goes out the window. You can still add/remove flux but it is treated differently. Temperature contribution is based on the square of the square of the flux. Specific heat of a part is ignored. Conductivity is also ignored; temperature is assigned directly though you can change how quickly or slowly it lerps to the designated temperature. So, in analytic mode, I have no idea how much 'flux' is leaking into the tank because there is no flux. I could figure out an arbitrary value based on how much Analytic wants to increase the tank temperature, but any flux I remove is being done to the entire vehicle and it doesn't really have the result needed. Oh, and the analytic interfaces ONLY affect the parts that the code is running on. So, if analytic mode runs on the heat pump... it's for the PUMP part (radiator) and not tank, which is what really needs to be affected. So... I CAN change what the analytic temperature is, on a part by part basis, I can't do that from the pump part. If Heat Pump were still part of Real Fuels, it might be a little easier to interface with but it's not. And I don't feel like fighting to put it back in again. (yeah, it got taken out once, put back in at my behest and then removed again, so I split it off into its own project) So right now I'm not sure what to do about analytic mode. Maybe the answer is to send event messages to and from the tank part... so I can tell it... yeah, you're refrigerated so ignore the heat and don't boil off. Or maybe I'll have to do it by reflection. I don't know yet. EDIT And, re: stock radiators: No, they're not going to be any better in analytic mode. In fact, probably even less helpful since the stock code doesn't even TRY to deal with the analytic problem. Oh, and finally: About the power usage separately vs in symmetry mode, I can't do much about that without a vehicle module to coordinate between multiple radiators. I do have plans to do something like that so they behave more like stock radiators, but that's in the future.

No, it doesn't. Only folders in GameData and NONE of their subdirectories folder name dll name FOR[some-mod-name] Note that because of that last one it is DANGEROUS to use FOR unless the mod being so designated is YOURS and is the mod in question. If a third party mod or a player doing their own configs use FOR inappropriately it can fool ModuleManager into satisfying NEEDS that do not actually exist: Example being: My mod needs to run one of two configs based on whether a second mod is installed. A third mod contains does :FOR[second-mod] and my mod cheerfully decides to execute the config that is only supposed to run if second-mod is installed but it isn't so maybe my configs are now invalid. Maybe I used a RESOURCE that would only have had a corresponding RESOURCE_DEFINITION if second-mod had been installed. Now KSP is throwing exceptions because of the missing RESOURCE_DEFINITION and either parts don't compile now or KSP halts during the loading process. (in this example it's probably the former and not the latter) So, long rant over, TL;DR no MM does not support subdirectories on a NEEDS

In the old days with the old unrealistic aerodynamic system, MJ was unrealistically accurate to the point that it once landed me about 5 km from my Duna base. In fact it probably would have got closer except I overrode it at one point because it was too close to clipping the rim of the canyon the base was in. (then I used the Translatron to hover the ship and tilt in the direction of the base until I arrived at its doorstep

No, it can't get confused that way. Things we call engines are defined on the part as ModuleEngines or ModuleEnginesFX (which is a child of ModuleEngines). That's what determines if it is an 'engine', not the propellant used or how many propellants is uses. I could make a new resource called VespeneGas and make an engine that can use it and MJ2 will handle it just fine. (WE REQUIRE MORE!) Here's a thing to try, as a workaround: Cancel the landing while there is still time for the suicide burn (if you don't have that displayed on one of MJs windows then you should add it) Then click 'land anywhere'. Just a suspicion but I'm thinking maybe if it's not on course and doesn't have time for a course correction that it might not go to the final landing phase. Probably an issue in its logic somewhere. Land Anywhere on the other hand doesn't care if it's 'off course' because it doesn't have a course to adhere to...

It's telling you (not very clearly) that the landing mode is 'SafeDescentSpeedPolicy' and 'false' means that it is not going to use the atmosphere to brake. (either there was no atmosphere or it was too thin for sufficient braking) what is your TWR ratio? It has to at least be > 1 at some point

Any craft? Not just Kerbals? It's been a long time since there's been any report of inappropriate fire effects. (though if you ARE on fire and turn on Ignore Max Temp cheat then fire effects don't get removed until both the cheat is disabled AND temperatures lower enough to not be on fire, but that's the only situation I know of and it's been low priority) Fire also only happens if skin temperatures pass a threshold determined its maxSkinOperationalTemp value, with the exception of the previously mentioned bug that was affecting Kerbals. I have a preview of the next version that's not even in pre-release. You can try it if you want: https://www.dropbox.com/s/2kiug1k6opjvgqv/DeadlyReentry.dll?dl=1 I just added some code to it to keep Kerbal temperatures stable if in time warp. Maybe that will help It also has a new directional damage system in place but you probably won't 'see' it

You could delete Ven's version of the docking port and restore the original stock port. Then you can have both mods right now.

@Gordon Dry If you are so much of an expert, you should be able to fix this yourself. That's what I would do if I were in your position. And I would succeed. I wish you equal success. Good luck.

I didn't say 'delete two files of your choosing' I said, delete the entire two FOLDERS. Not just delete. Gone. Destroyed. They're history. Then reinstall from the zip. This isn't a bug, there's nothing wrong with Real Fuels or Solver Engines and if you install them correctly they work

Ok so actually this seems like it is working as designed. 323.1 K is approx 120 Fahrenheit. Fortunately, the part of the code that would start doing internal damage isn't in place yet, partly because I wanted to be sure how Kerbals would interact with it. Basically though, IRL, tissue damage starts at 317 Kelvin. So that's not even a high fever, that's like scalding water hot. He's not boiling yet but he's hurting pretty badly. I don't know why he'd be getting so hot in Kerbin orbit. I looked at your logs and MM cache and I don't see any mods that I recognize as being capable of doing that and your physics globals config has all stock values. Is timewarp past 100x a requirement for reproducing that temperature?

You have a version mismatch somewhere. Between solverengines and rf probably. How did you install it? Edit: Actually, never mind how. Delete your RealFuels and SolverEngines folders and reinstall from the RealFuels_v12.1.0.zip file

It's not just a matter of having left Squad, he's also dropped out of the modding scene as well.