Starwaster

And again has nothing to do with what's being asked for. The parameters in question are EASILY subject to an RO patch if you care to make one (for all three modes). Trivially easy. Anyone else want to chime in? Someone who can restrict themselves to Easier / Harder? Come on... Throw me a fricken bone here.... I'm the modder here. Need the info...

Amazingly enough, we are indeed playing a game Shocking, right??? Normal (called Default in the config files) is exactly what it sounds like. If you're playing and finding DRE too difficult you want to make things easier. In the past people would wonder what they needed to edit to make things survivable (even on stock Kerbin). Even more people would complain the default settings were too easy and want to make things challenging. Arguably, neither of these viewpoints is correct because the default settings on stock Kerbin are survivable and if you can't survive then you're (apologies) 'doing it wrong.' If you think that the default settings are too easy well, guess what, that just means you did it right. It's not supposed to make things difficult. Doing it right means it gets easy. Doing it wrong means you're hiring more Kerbals. That's the Starwaster viewpoint and it ignores the fact that this is a game and not all players are equal. I can't just tell them that 'space is a tough place where wimps eat flaming plasma death.' So that brings us to where we are today. If it's too easy then there's a nifty Easy button to click. If you want it harder then you click Hard. (I was tempted to label the Easy button 'CA Mode' but I'm actually a kind person at heart so I didn't do it) So like Nathan says, it doesn't have a lot to do with realism. If I had to choose one to call 'Real' I'd go with Normal and then try to code the mod to behave realistically on the default settings, with the caveat that I might have to abstract some things in the interest of game play. So, tl;dr, the difficulty menu is simply about giving people who think it's too hard or not hard enough an easy way of changing things up at the push of a button. I probably won't get the answers I'm seeking with my request and I posted it with that knowledge in mind so I'll end up just choosing some some obvious candidates to change values for and put the update out. Then as the complaints trickle in I'll fine tune as needed. That's cool too.

In preparation for the next update I'm going to need some very specific feedback in a specific manner. On the subject of difficulty settings: Easy, Normal (Default) and Hard, what do people consider easy or hard? The form in which I need this feedback is in terms of what changes did you make either through the debug menu or by editing the custom.cfg file? (created when saving through the debug menu) For instance, if you found parachute destruction to be too hard, what did you change the multiplier to? If reentry was too hard (or too easy) on stock Kerbin, what did you change to make it easier or harder? (densityExp, shockwaveMultiplier, etc. I expect to have the new difficulty system up and running soon and the Easy/Hard groupings need populating. Currently its primary function is to apply changes to the DRE settings using one of three difficulty templates. which are basically what you see when you look at custom.cfg only there will be three of REENTRY_EFFECTS nodes now (Easy, Default and Hard)

That's some good information but I don't think it entirely answers his question. Unless I'm misinterpreting, he also wants to detect when a new game was actually created for the first time. onGameStateCreated triggers when a game is loaded and nothing identifies it as a new game. paul23, if that's what you're looking for or need one-time code execution for a new game you should look into the Scenario class. Give it a flag to be set when you've initialized anything needing initializing so it knows not to do it again. Bind the events that MoreUmpf mentioned and any other events you need. Here's some example usage of the Scenario class that I've coded https://github.com/Starwaster/Ioncross-Crew-Support/blob/Dev/Source/IoncrossCrewSupport/IonLifeSupportScenario.cs Here's another that I did for enneract's Real Roster to implement crew rotation per save game. https://github.com/Starwaster/KSPRealRoster/blob/master/RRScenario.cs

Stop trying to make modpacks happen. It's not going to happen!

Banned because Mojave Desert

They're part of your save files.... if the rest of the save loaded but contracts did not, they might have had some dependency that is now missing. (such as a part) If any part of that failed with an error then it could / probably would stop the rest of the contracts from loading.

"Water Breathingâ€â€This is a wimp power. Face it. When the great super hero parties happen and Ulterior Motive Man asks you what you do and you say 'I breathe water,' you end up wearing a full fishbowl." â€â€Marvel Super Heroes Advanced Set (TSR, 1986).

Northrats, They're 40kg. That's not heavy. And they are active cooling because they consume electricity. Just pretend that the fin is only the visible radiator part of it or something. Here, try this. @PART[ThermalFin] { @node_attach = 0, -0.66, 0, 0, -1, 0, 1 @MODULE[ModuleHeatPump] { @heatDissipation = 1.0 @heatGain = 1.0 @heatConductivity = 0.0 } } I think that still works in the current HeatPump class.

Your rocket now starts in the same orientation as it will be on the launch pad. (previously the rocket would be rotated 90 degrees on the launch pad. That VAB orientation just changed to match)

Screenshot demonstrating the problem please. (I haven't noticed such behavior myself, aside from being decouplers, they dont do anything with staging. If the shield is the only part in the stage then it won't have DV associated with it because it's just a decoupler stage)

The current implementation for radiators is flawed. You can get tank temperature low enough but it takes a lot of fins. Something like 12 of them will stop boiloff IIRC.

The textures there are probably tga, which are prone (in 0.25) to a bug where the diffuse texture may or may not load properly.

Maybe you or a mod that you installed altered the inflatable's animation settings or used a different animator (firespitter). As distributed though in DRE, the inflatable is set to be a 'oneshot' animation. It's a simple boolean field. If true, you can't deflate. If false, then you can reinflate

Hey guys, here's something I've been working on for Real Roster: crew rotation. Instead of random selection, it maintains a separate list of Kerbals who have been assigned to craft. When they launch, those Kerbals are moved to the bottom of the list. So far it looks like the bugs have been worked out of it and I've done a pull request to enneract for inclusion. But it would also be good to get some more people looking at this and see if they can break it / find bugs, etc. To enable rotation, make sure that crew assignment is on and randomization is turned off. (even if assignment is off or randomization is on, Kerbal assignments are tracked so that when rotation is turned on it knows what Kerbals should be assigned ndext) One last thing, the rotation roster is on a per save game basis and is saved in your save game files via the Scenario class. dll is a drop in replacement. changes and additions / source here: (feel free to use the Scenario code) https://www.dropbox.com/s/xd73zd4qchxtpj4/RealRoster.dll?dl=1

The inflatable works by having a higher than usual reflective rating (25% of all incoming heat is simply ignored). You can see its maximum temperature rating in the VAB by hovering the mouse cursor over the part's icon in the catalog. I don't consider it to be reusable as there's no way to deflate it and it has high drag when inflated. I don't think DRE's damage system has ever really worked. There are two points at which you're supposed to take damage: When the vessel is undergoing high G and you hear creaking as the parts are stressed. And when parts are on fire. Those two events tend to result in destruction if you actually get to them so I've never really been in a situation to notice if something got damaged or not, as a player. Since taking over this mod It's been on my mind to look at the damage system and see if it actually is working but I haven't got to it yet. (realistically it should take some sort of resource to repair something...)

It's not that simple, the source code has to be changed and recompiled. Nobody minds if you do that unless it gets redistributed and results in extra work for the developer. (i.e. having to deal with 64 bit requests which have no solution possible). You do a thing like that then you better take ownership of the situation

What about PQSMod_VertexHeightMap then? Scaling its deformity 10x seems like it would be a bit excessive. I've been just experimenting with setting it to the highest possible elevation that I want to find on Kerbin (or whichever body)

What's wrong with it exactly? Doesn't the current system reflect heat radiation, which is based on how hot the radiating item is? I'll try your suggestion locally to see how it works out but it doesn't seem like it's really necessary?

Linear should be fine. If that curve is happening in-game then we (I) should put that in. Sigh. BTW there's another factor in there that affects where things actually max out (yes, the peak vs max is confusing, I'm not sure who wrote that) That factor is atmospheric density. So the point where REAL maximum ablation occurs during an actual reentry isn't really reflected on that curve....

Where are you getting a value of 95 from? What are you using to plot that with? I don't think the in-game curve is going to be like that, although it's theoretically possible due to the vagaries of how Unity deals with curve data. The shield data lacks tangents so the game could be doing something weird I suppose, but again, where are those numbers really coming from? And BTW, that shield configuration isn't really RSS appropriate. If you haven't already you want to get the RSS / RO heat shield config from the front post. (typical highest shield loss curve maxes at 6000 and not 3000)

First, throw out any information you got off the wiki. Anyone can edit that so there's no uniformity there. People edit that who still think stock resource volume units are in liters. Second, Re: Celsius vs Fahrenheit: It's Celsius. The game does not impose a lower limit on temperatures at all. I could set it to -69,105 in DRE code and the stock code would allow it. RealChutes vs Stock chute tolerances are exactly the same. By the time DRE is finished with them, they have a final maxTemp of 1150. The parachute temperature multiplier is currently 0.25 by default giving canopies a virtual maxTemp of 287.5. I'm probably going to bump the multiplier up a bit to give canopies a virtual maxTemp corresponding to Nylon 6-6 which is a more heat resistant fabric and is often used in NASA's chutes. (Curiosity chutes were made of this; the lines were made of something stronger, I forget what). (it would be nice to grab the Real Chute material field and treat different canopies according to their material properties, but it's a tricky thing to deal with. Kevlar has a higher 'melting' point but is substantially weaker at high temperatures. All we really deal with right now is failure due to high temperatures) Finally, yeah the *10 multiplier does make them more prone to destruction, but without the multiplier they become essentially invulnerable. I'd like to change it but don't want to upset the current balance which in spite of complaints I feel is working appropriately. And, FINALLY finally (I lied about the first Finally): Soonâ„¢

Nobody can help you with the level of information you provided. http://forum.kerbalspaceprogram.com/threads/92229-How-To-Get-Support-%28READ-FIRST%29

No. That's outside the scope of this mod. Real Solar System can handle giving the sun heat in the form of a temperatureCurve..... No configs out there currently do this, but it's possible.

Except that no such calculation (for stress) is ever made in DREC. The calculation is for heat and is made against against one quarter of the chute's max temperature rating. In the future, for Real Chute I'd like to see this done against the actual canopy material's melting or burning point but we don't currently check RC's material. So for now we take a fraction of the chute part's rating and say that's the canopy's rating. If there ever is an actual aerodynamic stress test for canopies then it will be alongside of thermal checks.