Starwaster

Don't know, not enough information to say. Might have just overheated too quickly. Did you see any flames before it happened? Did the part catch fire at all?

That's because that was the older code (which, yes, !leaveTemp actually worked too, once upon a time) Conditionals are (or were) generic. Anywhere that was doing logic checks the same syntax worked for them all. I have no idea what's happened with the code since then but yes, that worked.

Is there landing gear on the thing? If the hinge is heavy enough then the gear could be strutted to it. (landing gear/wheels force autostrutting to heaviest part)

How big is the shield? It has to be bigger than the probe itself. And with stock heating you can probably get away without a fairing as long as the shield is bigger than the probe but sometimes that isn't the case with FAR. Which frankly is more realistic. In real life, the shockwave is still pretty hot after it passes the capsule. The backside of the capsule is still between 4200-8200K And you might want to adjust your reentry angle. If the probe is ok higher up then give it a shallower reentry so it has time to slow down before descending deeper into the thicker parts of the atmosphere. Greater atmospheric density means it can transfer more heat into your fragile little spacecraft.

I don't need to look at the code to know that it worked for Module Manager 2.0.8. What I can't tell you is when it stopped working. But yes, using | in HAS blocks was a thing once upon a time. As for the latter, Deadly Reentry looks for a flag 'leaveTemp' in the body of all part configs. More properly that flag belongs in ModuleAeroReentry but we look for it in the part itself to make it easier for other modders to opt out. What USED to happen was that in the same patch that we looked for the flag in we would add ModuleAeroReentry with the flag and its associated value (leaveTemp = #$/leaveTemp$) inserted and then the flag would be deleted. That worked up until a few years ago when it stopped after MM updated. I reported it here and was told that there was just no way for Module Manager to know that the flag was being read before its value inserted into the module and I left it at that as it was just easier to leave it in there. (worst that happens is the part compiler complains about an unknown field). But it did used to work. @PART[*]:HAS[#leaveTemp[*],@MODULE[ModuleAeroReentry]]:FINAL { @MODULE[ModuleAeroReentry] { %leaveTemp = #$../leaveTemp$ } !leaveTemp } @PART[*]:HAS[#leaveTemp[*],!MODULE[ModuleAeroReentry]]:FINAL { MODULE { name = ModuleAeroReentry leaveTemp = #$../leaveTemp$ } !leaveTemp } Try removing the : at the end of title @title ^= :^:#$bulkheadProfiles$ Also though, the way you have it there there won't be a space between bulkhead profiles and the rest of the title.

Sounds like a bug to me!

I say not to use both stock and DRE for part g force damage because they both have the same the same goal: destroy the part. Implementation of g forces on Kerbals inside a part differ between DRE and stock. Stock will cause gforce induced loss of consciousness (GLOC) Kerbals and DRE will kill them. In the case of parts, DRE gforce damage depends both on intensity and duration and does cumulative damage which can be seen and repaired by engineers on EVA. Kerbals in parts have gforce effects treated differently where there is a threshold of 6gs and it is tracked cumulatively for as long as the threshold is exceeded. The intensity is exponential with relation to gforce. When the accumulated gforce reaches a certain point there is a chance one Kerbal will die every physics frame. If gforce drops below the threshold the counter is reset. It is tracked per vessel part. The accumulated value (needed to kill) is much lower in stock than IRL because Kerbals are usually subject to it for much shorter periods of time. IRL people have been subjected to 40g’s for short periods of time and hundreds of g’s for brief periods of time such as in car crashes. How much a person could really take is highly subjective and hard to quantify. In RO/RSS and other scaled up environments I set it up so that 9 g’s can kill you but it has to be REALLY sustained for a long period of time. 40 g’s are survivable for a less of a period if it’s not too long.

An example of hotstaging would be igniting the second stage engine before jettisoning the first stage.

It's pretty bizarre considering commas work in HAS blocks as a logical AND You're probably right and it probably did work in the past which means its failure to work now is another regression. Just as it used to be possible to add a field to a node, test for that field in a node and then delete that field from the node in the same patch section as it had been tested for. (now MM gets confused because it no longer knows what order to execute the commands in)

Deadly Reentry does not use or interact with stock's G force or pressure system Deadly Reentry has its own handler for gforce damage. I'd leave the stock one turned off.... OR.... if for some reason you think you'd prefer the stock one or you'd like to TRY the stock one then you should disable the Deadly Reentry one in its menu. (click the little capsule on the stock toolbar) and set G Tolerance Mult to 0 (default is 6) The stock Kerbal G force one you can enable as you please without needing to do anything with DRE's one. The stock one only controls Kerbal unconsciousness (GLOC) whereas the DRE one can actually kill them. I consider the two to complement each other nicely.

Yes.

Back when Real Solar System was its own mod independent of any other mod I was working on an update for it and I accidentally put Deimos too close to Mars. As in I was sitting on the surface of Mars and watched a Deimos coming over the horizon at me and it smashed into me and wrecked the ship and killed all the Kerbals. That was bad but it didn't crash the game. TL;DR I accidentally Deimos. The whole Deimos. Is this bad?

@Tonka Crash it is possible to do but you’ll need to disable ROCs. Edit your save file and change ROCSeed to -1

Right, there are severe performance issues with regards to Kopernicus and surface features. Typically you shouldn’t see more than 1-2 thousand but today I got hit with almost 28 thousand all at once tanking my performance. It was the worst I’ve ever seen

Kopernicus for 1.7.3 is out now. RSS will work with it though some of the Breaking Ground features will be missing (special terrain features, ROC. They are defined per CelestialBody and configs only exist for Kerbin right now)

Are any of your mods Kopernicus and/or a scaled Kerbol system? If so there is an issue with Kopernicus and the BG surface features (ROCs) One way to test if your lag is from the ROCs is if you still have lag in a saved game that existed before you installed Breaking Ground. Older saved games do not have ROCs by default because they could break any bases or vessels you have on the ground. (ROCs are physical and if they spawn in on top of a vessel it will not end well)

@JPLRepo what about ROCMissionSeed?

It means you can make a functional Kanadarm2 now.

Loading more patches just means it will take longer to patch when the game starts up. It doesn't automatically translate to lag in-game. And the extra time it takes to patch is only the first time you have to process new patches. After that, MM caches the patches so on subsequent startups it only has to apply the cached patches without processing them all from scratch.

So uh, I'll just leave this here then... this... thing I did to the LC5 MODULE { name = ModuleInventoryPart InventorySlots = 12 } Is that a little too much? Maybe... but the 1.25m part can hold 9 so I think it's ok. (btw that's for the new Breaking Ground DLC.... adds deployable science inventory slots to the LC5 if you hadn't guessed)

https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19700024568.pdf https://www.hq.nasa.gov/alsj/nasa58040.pdf (same document but not text searchable; just a scan of the original document) "The purpose of the DO1 is to efficiently reduce the orbit altitude from approximately 60 nautical miles to 50 000 feet for PDI. Performance of contir~uous powered dcscent from altitudes much greater thwl 50 000 feet is inefiicient, and a PDI at lower than 50 000 feet can C become a safety hazard (ref. 3)" I don't know what your source of information is but I trust the original documents describing the why and how of the lunar landings. And that document says that Apollo's descent trajectory was chosen for efficient propellant usage.

What nonsense! Bugs are just extra protein

As you say they don't represent a specific distance. The distance in meters per degree varies from planet to planet.

Your second and third sentences contradict each other Leaving your burn as late as possible is the opposite of a gravity turn in reverse. Apollo's lunar landers did the latter. Typically starting with 115 x 15km orbits and braking at the low point. Pitching up just enough to manage their descent so that both vertical and horizontal are mostly canceled as they approach their landing sites. (keep in mind that their orbital velocity was starting at ~2km/s while doing this) The difference between the two (shallow vs steep) is that shallow landings have lower gravity losses. But I guess for most KSP stock landings it's not usually an issue since our landers don't usually have to worry about delta-v that much or conserving any of it for the final approach. Nevertheless, it is more efficient to do a shallow rather than steep landing.

Current landing AP is pretty wrong. Landing should be a continuous burn with no course corrections. Instead, if there is error then it needs to compute how much corrective burn it needs but then spread it out over the remaining burn time. And the current targeted system IS capable of that but only within the final stage of the burn and if the burn is interrupted for any portion of time it will want to do another course correction before moving on to the final burn stage. The landing AP also has no real concept of vertical velocity management which is why landing from too low an altitude tends to result in crashes. It spends too much time cancelling the horizontal velocity and unless its gravity turn orients downwards enough to cancel out the vertical before the suicide timer goes negative then it will probably crash. I've been sitting on some code for the AP that takes that into account and pitches up just enough to keep its downwards momentum under control. It works pretty well in scaled systems but not so much in stock so I never made a pull request on it. And it doesn't work for targeted landings at all.