[1.12.x] MissingHistory v1.9.3: Handy parts to complement Making History.

[Kaa253]

Oh my goodness @Snark I am so sorry. I thought I was posting about something obvious and didn't imagine for a moment that it would not be instantly reproducible . You are absolutely correct in that I thought it seemed "self evident". If I had thought the issue might be more illusive I would have provided a more detailed description.

I took all my mods out one by one and then put them back in one at a time. Like you (very unfortunately) I spent a lot of time trying to debug and discover the reason for my spaceplanes being plagued with really high drag. I got to the point where I could take out just the folder of Porkjet versions in Missing History and all was normal with the resulting stock parts and then put the folder back in place again to immediately reproduce the bugged drag result. So I did try running the same scenario both with the stock tanks and with the Porkjet versions and more or less did that testing right.

Next I thought I had also tested properly in an otherwise un-modded install of stock KSP. The craft in the posted image I made it as simple as possible specifically to try to debug this. The craft file is still there for testing, copied into both my heavily modded install and in my un-modded install but I must have been too tired or something and messed up that last test somehow because when I load up the un-modded version and repeat it now to my surprise I cannot reproduce the drag issue, everything appears normal (oh shame the shame). 

You are not asking for a lot, you are perfectly reasonably asking for sufficient detail to reproduce the bug and that is the totally standard correct practice. I do still have the drag problem with the Porkjet tanks in my heavily modded install so I have hard evidence that in just my KSP install something is wrong somewhere but in this case there is a large and eclectic mix of mods and some of my own probably dodgy custom MM scripts also present. So apparently I have managed to commit the cardinal sin of accusing a mod of having a bug when it is likely not there at all and in fact arising from somewhere else completely unrelated! It is affecting these parts but not being caused by them.

I will try to do lessons learned about QC of my debugging practice, never forget that the most likely problem is between the chair and the keyboard and for now go away and crawl under a rock someplace. 

If someone else comes along complaining about drag you can tell them Kaa253 spectacularly failed to demonstrate (un)conclusively that it is (un)likely to be coming from some other (un)specified mod out there someplace.

Edited April 13, 2018 by Kaa253

[Snark]

5 hours ago, Kaa253 said:

I thought I was posting about something obvious and didn't imagine for a moment that it would not be instantly reproducible . You are absolutely correct in that I thought it seemed "self evident". If I had thought the issue might be more illusive I would have provided a more detailed description.

Heh, no worries, it's okay.  It's an easy sort of mistake to make:  if you've never been a producer or tester of software, it's generally not obvious what sort of information is likely to be needed.  That's why this kind of thing happens all the time, and I can promise you that you are far from the first person to run into this. 

Just as a PSA, a few additional thoughts in spoiler section, to help you better understand the thought processes of a modder when they receive a bug report, and what sort of information they need.

Spoiler

5 hours ago, Kaa253 said:

I spent a lot of time trying to debug and discover the reason for my spaceplanes being plagued with really high drag.

LOL... Just to be clear just how non-obvious the problem was:  Not only did I literally have no idea that this was your issue, I was actually guessing that your problem was the exact opposite and that you were complaining that your drag was too low, somehow. 

The original bug report simply says "broken", and then shows a screenshot that has nothing that is visibly wrong (to me, anyway).  I was looking at it, scratching my head, trying to figure out "what's the issue?"  The only clue I had was that you had popped up the PAW for the FL-T400 tank, and the FL-T400 tank is one of the parts you said was "broken".

So I looked at that, and here's roughly what went through my head:

• Hmmm... okay, he said this part is 'broken', and he popped up this menu, so he must think that the numbers in this menu are so damningly, visibly wrong that it's self-evidently obvious from the screenshot what the problem is.  So let's look at the numbers, here.
• Hmmm, okay, I see that there's a whole bunch of gibberish numbers that neither I nor 99% of the KSP-playing population knows what they mean.  I can see that a bunch of them zeroes but I have no idea what they're supposed to be, or whether 0.00 is a good or a bad thing, or why.
• I don't think it's Mach, since that's just how fast he's going, clearly that's not the bug.  Drag Vector is just a direction, seems pretty clear, it's just saying that the part is oriented perfectly as one can see from the screenshot.  So that's not it, either.
• Okay, he must be complaining about  drag.  He thinks.... something's wrong with that value?
• Well, the drag number here is...zero.  What the what?  He's complaining that it's zero?  He thinks it should be bigger than that?
• Okaaaaay, it's a cylindrical part that's inline in the middle of a stack traveling straight , so I would kind of expect it to be zero, but I'm no expert on aero, and maybe he's complaining that it's too low?  Is that it?  Is he complaining that it really should have some small amount of drag, and it doesn't have any?  Perhaps he's complaining "Hey, why does my plane go up to Mach 0.98 when it's only supposed to be able to go up to Mach 0.97", something like that?"
• Well, okay, I honestly have no idea what the supposed issue is.  So I'll just do a quick test to see if something is glaringly wrong.
• ....Nope, nothing turned up, I won't spend any more time on this for now.  I'll post back to the bug reporter asking for more info.

So... perhaps you can understand my puzzlement?

 

5 hours ago, Kaa253 said:

I will try to do lessons learned about QC of my debugging practice, never forget that the most likely problem is between the chair and the keyboard and for now go away and crawl under a rock someplace. 

Seriously, no worries at all, and absolutely no hard feelings.  Just to be clear here, the above spoiler vignette is not even slightly intending to criticize you, and I really don't want it to make you feel bad-- I'm just trying to illustrate how modders work through bug reports.  You didn't do anything wrong.

Bug reporting is like any other skilled technical process:  there are a whole lot more ways to get it wrong than to get it right, and therefore if a person doesn't have experience with it, they're almost guaranteed to do it "wrong".  My users are doing me a favor by bug reporting (it's not as if I'm paying them for QA), so it would be unreasonable of me to expect perfection.  So seriously, this would happen to anyone-- don't feel bad.  The important thing is to learn from the experience, and clearly you're doing that.  So, yay!  Everyone wins. 

And also, don't feel bad that you've wasted a lot of my time or anything.  Because, like all modders, I'm used to getting bug reports that aren't necessarily platinum-plated, because the reporters are just normal regular users and not professional QA staff.  Therefore, I prudently didn't put much time into it.  I did a quick glance with one quick test that took me about five minutes to put together, didn't see anything obvious, and then batted the ball right back into your court.  So, no harm done.

So not only are there no hard feelings, I'm grateful that you're the kind of user who takes the trouble to produce bug reports, and to do so in a friendly and non-demanding way.  That's basically the poster child of the ideal user that every modder wants.  I'd far rather have enthusiastic, engaged users who care enough to send me bug reports (even if they're occasionally incomplete or false alarms), than have a mod that nobody cares about and no one bothers to report anything.

So this report was a bit incomplete, but that's no big deal and happens all the time and I'm sure your next one will be better.  So it's all good. 

[Kaa253]

@Snark I was not feeling like you were criticising me, I was/am actually being very critical of myself. I should know better. Nevertheless, I am pleased to see you have no hard feelings.  

Spoiler

In a spoiler just because it is going on off-topic.
You see while I am not a "producer or tester of software" as such, I am actually a research scientist who writes code (or maybe its better described as spaghetti) at work from time to time and more regularly I have to provide useful code testing feedback to the computing and engineering teams. I would have no excuse for sloppy reporting at work so it is even worse when I do it to someone who is helping us all with modding for free. 

I enjoyed reading in your reply your personal and very insightful description of the experience of being the owner/manager of a game mod. Thanks  

  

[4x4cheesecake]

@Snark Well, i ran into the same drag issue which is described by Kaa253 and its somehow reproducable. While using the black/while model of the FL-T800, my MK3 SSTO can barley break through the sonic barrier, but its no problem with the grey/orange or stock variant. Actually, this is also a problem of stock-DLC parts, as you can read here:

I dont know anything about part modding but maybe someone who does can take a closer look at this? I wish i could provide some numbers or anything else to confirm this issue but the only thing i can provide is a craft file of my SSTO, if someone is interessted in some further testing.

[JAFO]

@4x4cheesecake, well done on finding a way to reproduce the bug, and for pointing the devs in the right direction!

 

6 hours ago, 4x4cheesecake said:

Actually, this is also a problem of stock-DLC parts, as you can read here:

 

 

Hmm.. up to 7% variation in what are supposed to be identical drag values, eh?

Hopefully, this has been discovered in time to be added to the DLC portion of the floating-in-limbo 1.43 patch before it's released.

Edited April 25, 2018 by JAFO
removed unhelpful speculation

[JAFO]

5 hours ago, JAFO said:

Hopefully, this has been discovered in time to be added to the DLC portion of the floating-in-limbo 1.43 patch before it's released.

Hmm.. I may have been overly optimistic.. I've just been informed by @bewing that:
 

Quote

It's worse than that. The reskins are just paint jobs all on the same model. There is no copy/pasting involved. It's only one config file. Having the paint job modify the functionality of the part is 100% completely impossible. So yeah, how could parts that have the same model and config file diverge by 7%? I don't envy the dev who gets to try to debug this one.

Given that "completely impossible" bugs tend to be somewhat tricky to track down, it may be a while before this one gets sorted.

[Snark]

10 hours ago, 4x4cheesecake said:

@Snark Well, i ran into the same drag issue which is described by Kaa253 and its somehow reproducable. While using the black/while model of the FL-T800, my MK3 SSTO can barley break through the sonic barrier, but its no problem with the grey/orange or stock variant. Actually, this is also a problem of stock-DLC parts, as you can read here:

Sorry, but I just can't reproduce this.  I find no detectable difference at all between the black/white and the orange/gray variants.  I tried a couple of different tests.  Details in spoiler.

Spoiler

First test:

1. Take the above craft, don't turn SAS on, and just take off from the launchpad at full throttle.  (Those two side tanks are empty.)
2. Try it two ways:  on one, both tanks have the black/white color scheme.  On the other, they're two different paint jobs as shown above.
3. The theory is that if there's a significant drag disparity between the two, it should make the rocket yaw strongly to one side or the other.
4. Result:  No discernable difference between the two cases.  Doesn't seem to make any difference whether the two side tanks are the same or different paint jobs.

That test was a bit subjective, so I decided to try a different test where I'd get a nice, hard, objective, comparable number.  So I did this:

(The fuel tank is exactly half full.)

1. Take the above craft, set SAS to "hold orientation", and launch at full throttle.  (It accelerates hard and passes Mach 1 by around 1000 m.)
2. Just let it run, hands off the controls.
3. When it exits atmosphere, take note of the Ap height.
4. Repeat the experiment, but with the other paint job.

If there were a significant difference in drag, I'd expect to see significantly different heights reached.  But I didn't observe any difference at all.  It was remarkably consistent.  I ran it twice with each paint job, and here were the Ap numbers I observed:

• Black/white paint job:  118328m, 118236m
• Orange/gray paint job:  118248m, 118247m

There was only a 0.08% difference between the maximum and minimum observed values among all the trials.  And there was only a 0.03% difference between the average value for the black/white paint job and the average value for the orange/gray paint job.

I have no idea what's going on here, but I simply cannot reproduce it at all.  Works fine for me.

For those of you who can reproduce it... could you try a little experiment for me?

1. Go into your KSP folder.
2. Find the file named PartDatabase.cfg.
3. Save a copy of it somewhere outside your KSP folder.
4. Delete it from your KSP folder.
5. Now run KSP and try to reproduce the problem again.

Maybe this won't make any difference to you.  But if it does fix the problem, that could be a clue where the problem may lie.

(Just trying to think of "what could cause other people's ability to reproduce the problem to be different from mine", and "what about a stale PartDatabase.cfg" is one idea that comes to mind.)

[4x4cheesecake]

@Snark

Ok, i've done some testing with my "old" PartDatabase.cfg and a new one, the results are quiet interesting:

1) Using the old database causes the FL-T800 tanks to not create any drag by itself, but somehow the total drag is higher while using the orange/gray model instead of the white/black model.

2) Using the new database causes the FL-T800 tanks to create drag but even then, the orange/grey model creates less drag then the white/black model.

3) Total drag created of my SSTO is lower while using the new database. (I had to throttle down to keep a speed of ~333m/s)

My tests with the SSTO are not 100% comparable because it is pretty hard to get the plane in different flights into the exact same situation (pitch, AoA, roll, etc), but i tried to do a screenshot at speed of ~333m/s and an altitude of 2500m.

If i can find soime time, i try to do some further testing with a more comparable vehicle.

I put the screenshots in my dropbox folder since imgur seems to shrink them down too much: https://www.dropbox.com/sh/ch2egc2k9ufqik4/AACakVWLlwZ_H8Ix7sndxecKa?dl=0

Edited April 25, 2018 by 4x4cheesecake

[Snark]

7 minutes ago, 4x4cheesecake said:

Ok, i've done some testing with my "old" PartDatabase.cfg and a new one, the results are quiet interesting:

1) Using the old database causes the FL-T800 tanks to not create any drag by itself, but somehow the total drag is higher while using the orange/gray model instead of the white/black model.

2) Using the new database causes the FL-T800 tanks to create drag but even then, the orange/grey model creates less drag then the white/black model.

Okay, now that is interesting.

@bewing, any chance there may be some sort of shenanigans going on with variants, in which the game's not spotting that PartDatabase is stale?  The TL;DR of the above anecdote is:

1. User observes unusual draggy behavior in game
2. User quits KSP, deletes PartDatabase, restarts
3. User observes different drag behavior in game.

[4x4cheesecake]

I just had an idea of a quick test by using both tank variants on the same plane (0 trust torque in VAB) and 0° roll, so everything else like AoA, speed, altitude etc should be the same, right?

But look at this:

Spoiler

On the left is the actionwindow of the black/white variant, on the right the grey/orange one, obviously using the new database.

The difference is small (~3,3%) but there should not be a difference at all.

Full screenshot with AeroGUI can be found in the dropbox folder i've linked before.

 

Edited April 25, 2018 by 4x4cheesecake

[Snark]

15 minutes ago, 4x4cheesecake said:

The difference is small (~3,3%) but there should not be a difference at all.

Hmm, interesting.  Just for grins, could you try a little experiment?  Details in spoiler.

Spoiler

1. Find the MissingHistory config file for the FL-T800.  It's here:  GameData/MissingHistory/PorkjetParts/FuelTank/fuelTankT800.cfg
2. Open the file in a text editor
3. Find the line up near the top where it says:    @scale = 1
4. Just before that line, insert a new line that says:   -mesh = null
   • that's a minus sign in front, don't forget that, it's very important
5. Start up KSP and repeat the experiment you just did (i.e. the one where you saw a 3.3% difference).

Just a hunch that would be useful to check out.  Supposedly it shouldn't make a difference... but maybe there's a variant bug that's making it do so.

 

[4x4cheesecake]

@Snark

So, I did some more proper tests. I've tried very hard to get the same roll degree everytime but thats actually quiet difficult, the exact roll degree can be found at the bottom of every table. Also, I double checked the results of the test with your suggested additional line in the config file, but these values are correct.

Spoiler

Some terms, just to be correct:

B/W = Black and white

G/O = Grey and orange

I don't know what the two additional roll degree values are but they seem to be important (unity AeroGUI readout).

[bewing]

8 hours ago, Snark said:

@bewing, any chance there may be some sort of shenanigans going on with variants

I've done a lot of rechecking and you are right. A maximum achievable altitude test is not showing any effects with stock variants (even though the PAW aero data *is* showing differences).

[Dfthu]

You should also include the fix for the Soyuz style boosters, the COM is offset. I would also absolutely love if someone here could make new textures for the upscaled 1.25m parts.

[Snark]

16 hours ago, Dfthu said:

You should also include the fix for the Soyuz style boosters, the COM is offset.

Thanks, not a bad suggestion.  However, that's a well-known problem, the fix is straightforward, and I assume that Squad will get around to fixing it at some point.  So, I'm not especially inclined to include a fix for that in MissingHistory-- its purpose is to "fill in gaps" rather than to be a bug-fix mod.

[Not Sure]

I found a pretty terrible bug and i think it has to do with the connection node sizes and their effect on drag. 

I found it on this SSTO, for some reason at around Mach 1 the liquid fuel tanks behind the rocket fuel tanks produce 150+kn of drag, and the rocket fuel tanks produce none.. I checked their connections multiple times with no avail. 

I thought this problem would have to do with the fuel tanks so i removed the only mod modifying them (missing history) and the drag was consistant and smooth. (This screenshot was taken at mach 2 as well, twice the speed as the first one with 1/5th the drag. EXACT SAME VESSEL, ONLY WITHOUT MISSING HISTORY)
Craft file here: https://kerbalx.com/Pyro_Fire/MSS-12

Edited May 13, 2018 by Not Sure

[4x4cheesecake]

23 minutes ago, Not Sure said:

//Stuff about high drag in missing history

Sounds like you got the very same bug like me.. Try to delete your "PartDatabase.cfg" contained in your KSP install folder and restart the game. The PartDatabase will be recreated and should fix this problem.

[Not Sure]

20 hours ago, 4x4cheesecake said:

Sounds like you got the very same bug like me.. Try to delete your "PartDatabase.cfg" contained in your KSP install folder and restart the game. The PartDatabase will be recreated and should fix this problem.

That worked, thanks! Really didn’t want to uninstall this mod because of it, it is very nice.

[MikeO89]

I had an issue with the Terrier engine suddenly showing up with shroud attached and I couldn't get rid of it. All my save games that had the Terrier suddenly had shrouds and starting from scratch in VAB, when selecting the Terrier, it had the shroud attached and clicking disable shroud had no effect. I also had an issue of some of my saved crafts appearing with good sized gaps in between stages. I had an earlier saved copy of ksp from a couple of weeks ago and didn't have this issue. I started comparing copies and noted the previous copy didn't have the Missing History mod in it. I removed the mod and started the game again and this time no shroud on the Terrier either from scratch or on my save games and no gaps between stages. Thought I would mention this experience.

Edited May 15, 2018 by MikeO89

[klesh]

15 hours ago, MikeO89 said:

I had an issue with the Terrier engine

 

Did it look like the stock Terrier, or the Porkjet overhaul version?

[MikeO89]

Dunno, it was the only Terrier in the parts list and all the previous saved games that contained the Terrier all showed them with shrouds after the mod was installed (and some of those save games were done before the mod was installed).

Edited May 16, 2018 by MikeO89

[Snark]

On 5/13/2018 at 10:36 AM, 4x4cheesecake said:

Sounds like you got the very same bug like me.. Try to delete your "PartDatabase.cfg" contained in your KSP install folder and restart the game. The PartDatabase will be recreated and should fix this problem.

This has now popped up often enough that it ought to be called out as a "known issue".

I've updated the OP of this thread so that the problem (and its solution) are listed in the "how install" and FAQ sections.  Hopefully this will save folks like @Not Sure from grief in the future. 

On 5/14/2018 at 9:34 PM, MikeO89 said:

I had an issue with the Terrier engine suddenly showing up with shroud attached and I couldn't get rid of it. All my save games that had the Terrier suddenly had shrouds and starting from scratch in VAB, when selecting the Terrier, it had the shroud attached and clicking disable shroud had no effect. I also had an issue of some of my saved crafts appearing with good sized gaps in between stages. I had an earlier saved copy of ksp from a couple of weeks ago and didn't have this issue. I started comparing copies and noted the previous copy didn't have the Missing History mod in it. I removed the mod and started the game again and this time no shroud on the Terrier either from scratch or on my save games and no gaps between stages. Thought I would mention this experience.

Not sure what's going on-- I've never run into this myself.

Note that in general, it's often a dicey proposition in KSP to install a part mod that modifies a stock part, when you're in the middle of a career and have already-launched ships that have that part on them.  I try to avoid that, myself.  Not sure if this is the explanation for what you're seeing-- just wanted to raise the possibility.

To be clear:

• Do you see this problem on newly-launched vessels that you launch after installing this mod?
• Or do you only see it on vessels with Terriers that you already launched before installing this?

If the answer to the first question is "no" and the second one "yes", then I'm guessing it would be something along those lines.  If that does turn out to be your problem, then my recommendation would be to do one of the following:

• either just write off the munged-looking ships and avoid installing the mod mid-career in the future,
• or else "un-mod" the Terrier by just deleting the file GameData/MissingHistory/PorkjetParts/Engine/liquidEngineLV-909.cfg

The former approach leaves you with the ugly ships, but keeps the MissingHistory Terrier goodness for all future launched ships.  The latter approach does the opposite, and should fix your "legacy" ships, but you won't get the reskinned Terrier on new ships.

And again, all of the above is just speculation on my part, since I don't have this problem myself (because I always choose my mod set at the start of a career and generally don't install them mid-game).  It's possible I could be wrong, this is just my best guess as to what may be going on.

[Tyko]

25 minutes ago, Snark said:

If the answer to the first question is "no" and the second one "yes", then I'm guessing it would be something along those lines.  If that does turn out to be your problem, then my recommendation would be to do one of the following:

• either just write off the munged-looking ships and avoid installing the mod mid-career in the future,
• or else "un-mod" the Terrier by just deleting the file GameData/MissingHistory/PorkjetParts/Engine/liquidEngineLV-909.cfg

The former approach leaves you with the ugly ships, but keeps the MissingHistory Terrier goodness for all future launched ships.  The latter approach does the opposite, and should fix your "legacy" ships, but you won't get the reskinned Terrier on new ships.

A third option would be to rename the MissingHistory version of the terrier in the config file. This would make it show up as a separate part in the VAB. Existing ships would keep using the normal Terrier and you can use your renamed fancier Terrier for new ships.

[MikeO89]

My answers to that two part question is that when the mod is installed, a new Terrier shows up with shroud and a saved ship using the Terrier before the mod was installed then has a shroud. Take out mod, both shrouds go away. All in sandbox mode (it's the only way I roll).

Edited May 17, 2018 by MikeO89

[Superfluous J]

I installed this because I don't care about shrouds on my Terriers if it means I can have that awesome half-Terrier engine that fills a super needed gap in engines.

I have not seen a shroud on any Terrier, newly built or already in orbit.