damerell

Rock, thanks. It'll have to wait until I get some play time tomorrow, but I'll chase that up. (And thanks for Sane Strategies, for all it's not in the current game because I was chopping and changing mods to try and get to the bottom of this.)

I have a station with Station Science and Orbital Material Science parts. When I load it, I get a constant flow of this in the debug log (circa 25 entries per second; in my most recent output_log.txt I have over 50,000 entries, and I was no more than fiddling with the station to see if I could permute things to make it stop). [CurrencyConverter for Patents Licensing]: 3.099442E-07 Science taken, yields 9.949208E-05 Funds (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) [CurrencyConverter for Fundraising Campaign]: 0 Reputation taken, yields 0 Funds (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) Destroying every kerballed module on the station, so that all is left is debris, makes it stop immediately. I know this request is short on detail; right now, I'm just at the "has this happened to anyone else, please?" stage.

It turns out to be (sigh) a bit more complicated than that. Something _else_ carries out these transactions on vessel load, over and over again, several a second. VOID unfortunately exacerbates the situation by faithfully recording them, causing persistent.sfs to grow without limit. So, sorry for the initial assessment being wrong. I suggest VOID should decline to record entries where all three Deltas are lower than some small value and/or throttle the rate at which transactions are being recorded. (FWIW, if anyone else is having the same problem and Google-chasing it, it's not Sane Strategies, but completely removing currency conversion strategies does put a stop to it, as one might expect. I now suspect ScienceLibrary...)

I have circa 150,000 entries in persistent.sfs of this form: CURRENCY_TRANSACTION { reason = ScienceTransmission fundingDelta = -7.174909E-06 scienceDelta = -2.011657E-07 reputationDelta = 0 timeStamp = 2740906.0948175 } From the number, the recent RAM issues I've been having, and the tiny Delta amounts involved, I suspect some sort of "sorceror's apprentice" mode is multiplying these every time the save is loaded. I don't know if other people are affected. I used to use the "Sane Strategies" mod, which gives regressive gains at higher commitments - that might be what makes me unusual. But I suspect there's a bug at work here.

I just hit it again, when a ship came within 2.2km of a station. (Not overall part count; switching vessels immediately improved matters). http://www.chiark.greenend.org.uk/~damerell/temp/ksp/ has KSP.log and output_log.txt - anything else you would like?

Huh. Sorry for the spurious bug report. I must have completely forgotten how it worked before.

Has that changed, or am I just an idiot?

Thank you. That is clear, if it's not what I wanted to hear. I'm sorry I was tetchy.

But I don't want RCS balancing. I want RCS not to be used for rotation by MechJeb. I am happy to receive answers of that form, but only from people who read the question.

I've got a bit of a problem with MechJeb. The "RCS balancer" window offers a "Smart translation" option. "Smart translation" doesn't seem to do anything useful, but instead makes RCS behave very oddly. However, if it's not turned on, all the other options vanish (there's an "if (balancer.smartTranslation)" in MechJebModuleRCSBalancerWindow.cs which hides them all), so there's no way to turn off RCS for rotation, which I'd like to both to save monoprop and because I'm, ahem, usually docking unbalanced vehicles and so RCS rotation also makes them translate. I would be utterly delighted if the answer to this question is "you missed an obvious tickybox, idiot".

Not only can't I reproduce it in stock+ScienceAlert, I can't even reproduce it in my own game - under exactly the circumstances that reliably provoked it beforehand. Gah! If it happens again I'll squirrel away a complete copy of the KSP directory so as to be sure of being able to supply any information that will help. Sorry.

I amended the script to dedupe X+ entries if they are entirely identical (and to make that actually work, sigh). I also wrote http://www.chiark.greenend.org.uk/~damerell/games/missioncount which adds M+ and L+ entries to fix the case where a kerbal seems to have taken off, or landed, twice in a row. If anyone else is trying to use these it's worth noting that if you run the script on Windows under Cygwin or similar, there are all sorts of MSDOS line ending issues, which I'm afraid are your problem.

It'll have to be later than right now, but I'll do so. If I can reproduce the problem in stock+ScienceAlert, I'll produce logs from that. Thanks.

I've got an interesting problem, which was entirely cured by removing ScienceAlert (and only that) from my set of installed mods, which is rather annoying given its considerable utility. Sometimes when I load a scene with more than one vessel in, or sometimes when a vessel is split in two (undocking, decoupler, etc), or sometimes when a second vessel enters physics range, and (as far as I can tell) every time when a vessel is split in two and the other part of it is then destroyed inside physics range (eg, decoupling a part which then splashes down hard), the frame rate drops to about 5fps regardless of the frame rate beforehand (which is sometimes quite respectable), and the UI is very unresponsive. Switching to another vessel in physics range, or EVAing a kerbal, usually cures the problem immediately. On the face of it this seems to have nothing to do with ScienceAlert, but that removing it cures the problem is suggestive. I'll happily supply KSP.log, try in a stock+ScienceAlert game, give a list of installed mods, etc - whatever you need.

I'd like to request a gauge showing total orbit energy for descent purposes - kinetic energy based on surface velocity plus potential energy based on height. It's this that needs to be bled off during re-entry. It looks like an easy patch, but I have no idea how to compile KSP plugins, so I'm posting to the thread first...

An obvious issue there is "first kerbal to do XYZ". If the timestamps are identical, all the entries should be preserved; but if not the earliest entries should trump the others - we introduced more "first kerbal to do XYZ" in a fork of history, or because we did things before noticing the ribbons got eaten. Another useful facility for the script would be to fake up entries to ensure these come in pairs (except the last L+, since the kerbal may still be on the mission). If we see two L+ in a row for Urist Kerman, slip in an M+, and vice versa. I'm kind of hoping Nereid reappears, but if not, I'll make more changes next week.

I've just tried an EVA operation to move some US wedges around; I can KAS-grab them, but the option to reattach them doesn't show up in the right-click menu. I know this is quite a minimal bug report. I'll gladly provide more information, but I don't know what you are going to want. Every module I use is CKANed up to date, except that I have a development KJR to fix the undock bug. I have tried going back to the Space Centre and returning, and removing the Module Manager cache. I have not before, in 0.90, tried to do this.

I had an attack of the Ribbon Kraken. I wrote a very tiny Perl script to pull ribbons from old savefiles and deduplicate them, intending to combine that with aggressive saving. (I'd be grateful to know if my assumption that two Hall of Fame entries that differ only by time should be combined and no other should is correct - in particular, I have no idea what the "data =" line does for S+ entries and suspect there should be at most one per Kerbal). The script is at http://www.chiark.greenend.org.uk/~damerell/games/savemangler - it reads savefiles on STDIN, ideally oldest first, and spits out a replacement set of Hall of Fame entries on STDOUT. It's a quick bodge but perhaps someone will find it useful. It probably gets firsts wrong, but as it happens I think my post-Ribbon-Kraken game gave Jeb all the same firsts he had beforehand. If there's more info about the FF data format forthcoming, I'll try and refine it a bit. I do wish KSP kept savefiles in version control. - - - Updated - - - A little pondering suggests entries with codes of the form X+ should only be de-duped if they have identical timestamps. Updated script on that basis.

Thanks awfully for this. It turns out to be just what I wanted to cover more areas of the screen with excessive amounts of data. :-)

However, that *10 multiplier is essentially a second part to parachuteTempMult - if parachuteTempMult were 0.025 by default, the *10 could vanish. I appreciate the current balance is about right, but it seems to be getting the right answer for the wrong reason; the shockwave temperature is, in fact, quite cool, but it's multiplied up by a fudge factor because chutes would otherwise work at supersonic speeds.

(tl;dr for people just trying to preserve their chutes; if I am not mistaken, you are always safe at or below 273 m/s but, unless the atmosphere is much less dense than Kerbin's, have little margin above that.) Gotcha, I didn't know that rule of thumb. (But, even with the density multiplier, does it give a sensible answer for Duna/Eve/Jool?) However, presently the test is: bool cut = ambient + Math.Pow(density, ReentryPhysics.densityExponent) * shockwave * 10f > part.maxTemp * ReentryPhysics.parachuteTempMult; That additional factor of ten surely significantly promotes chute destruction (at least above 273 m/s). If we are just high enough on Kerbin that density^densityexponent = 1, for example, and using a RealChute with a temperature tolerance of 3100 C (whoah!), the safe speed is about 350 m/s; in your code, about 1 km/s. But wait! 3100 C is much too high (although the Wiki lists part heat tolerances as Kelvin and then also says heat is measured on an unknown scale which, on the 2HOT thermometer, can go down to -429, which would imply it has to be Fahrenheit, although since Squad aren't American it seems unlikely they'd use so mad a unit, although the huge stock part heat tolerances actually make more sense in Fahrenheit, but on the other hand Kerbin's surface 20 degrees implies Centigrade, gah, and I see the old DR thread wrestles with this) and DeadlyReentry-RealChutes.cfg does this: @PART [*]:HAS[@MODULE[RealChuteModule]]:Final { @maxTemp = 1150 } and DRE also halves any maxTemp over 2500, getting stock chutes down to 1550C. So (in that density^exponent =~1 scenario) a stock chute will rip off at about 310 m/s and a RealChute at 300 m/s. Without the x10 factor, you can do about 670m/s stock, 570m/s RealChute. I wonder if that x10 factor is too high? The effect is that, while you're always safe below 273m/s, the death zone is very close above it - in the calculations above, a RealChute is destroyed when the rule of thumb says the shockwave is at a princely 30C or so. I wouldn't much care to stick my head out the cockpit in a 300 m/s wind, but I'm not sure a mere 30 degrees heat would significantly increase the inconvenience. (A more radical proposal would be to abandon this calculation and propose that any chute is destroyed at supersonic speeds.)

I've been trying to work out safe limits, but I'm a bit puzzled by ReentryHeat() - which appears to start by converting the vessel's speed from Kelvin to Centigrade (a curious set of units for speed).

Done. Outcome unchanged.

I get the same result; screen goes pure white, KSP.exe keeps running but nothing ever happens. The ordinary module-loading bar appears for a second or so beforehand. Radeon HD 6670. (I realise there are many more details I could provide, and I will on request, but this may be a known problem with an easy fix...)

The TACLS panel just counts down the amounts you left behind when the ship was last active, as if the kerbonauts aboard were using them and nothing else was generating or consuming them; but as far as I know this is just to give you a guess as to endurance, and when you return to the ship it fast-forwards to find out if the little green rascals are actually dead or not.