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

[MikeO89]

Hmm. Since no one else seems to be having this issue, it must be on my end then. Don't know if it's conflicting with another mod I have or if something got corrupted, but I get the shroud with it installed and shroud disappears when it's un-installed. Unless I can figure out what's happening with it on my install, I guess I will have to live without it. I can't hang with the shroud that I can't get rid of cause I use that engine on a lot of my crafts. It's pretty much my go to engine for small crafts as I can't stand the cigarette lighter looking Spark exhaust. They should rename the Spark motor to the Bic motor. Every time I see the Spark motor in action, I can't help but picture a little kerbal in the back with his hand out the exhaust flicking his Bic (and if I still smoked, I would probably put my cigarette up to the screen for a light).

Edited May 19, 2018 by MikeO89

[Snark]

On 5/19/2018 at 1:37 AM, MikeO89 said:

Unless I can figure out what's happening with it on my install, I guess I will have to live without it.

Sorry you've got no answer for your problem. 

If the Terrier is the only part that's giving you grief, you could just delete GameData/MissingHistory/PorkjetParts/Engine/liquidEngineLV-909.cfg so that MissingHistory will leave the Terrier alone.

It's not an ideal solution, but at least you'd still be able to enjoy the rest of MissingHistory, without the reskinned Terrier.

[cyberKerb]

@Snark Just wanted to acknowledge that you have to be one of the more patient moderators / modder on the forums here. Not to take away anything from the other people doing similar work, I just happen to follow a good number of your threads, so it might be selective bias . Even when you have to step into moderate, the post is direct, fair and never seems rash / off the cuff. For your mod threads, I've seen posts that would drive some modders to frustration due to blunt request/ demands, but again all I see is understanding there is a lot of new people to the game, despite it's age.

Thank you for your work and sharing of your mods (this one included). I can only image what kind of gameplay you regularly go through to warrant the creation / publications of your mods.

Thank you, thank you, thank you!

Edited May 23, 2018 by wile1411

[Nik kal]

Nice mod, i was always founding stock parts missing adapters, making history did not  correct this.

One thing, i am playing with remote tech 2 campaign and the 1.875m probe always maintain local control instead of remote. Any one knows how to configure that part?

[Snark]

16 hours ago, Nik kal said:

One thing, i am playing with remote tech 2 campaign and the 1.875m probe always maintain local control instead of remote. Any one knows how to configure that part?

Hm, interesting.

Various technobabble analysis in spoiler, for the curious:

Spoiler

Well, as you can see from the 1.875m probe config, there's nothing there at all about local versus remote control-- it's just a rescaled clone of the 1.25m probe core, with a few numbers tweaked here and there.

So my guess is that whatever is going on here, it's on the RemoteTech side of things.  It's been a long time since I played RT and I have no idea what their config looks like, but just taking a wild guess here (based on the behavior you describe):  my guess is that RemoteTech adds some sort of custom config to probe cores that says "this requires a RemoteTech data connection".  In other words, I'm guessing that RT is designed that by default, all command parts have local control unless specified otherwise, and then adds specific "needs remote control" config to the probe cores.

If that guess is correct, it would explain why you're seeing the behavior you are:  I've added a "new" probe core that RemoteTech doesn't know about, and I haven't added any RemoteTech config to it, so it just gets the default RemoteTech behavior of having local control.

If that's what's going on, then presumably the thing to do would be for me to add a bit of patch config to MissingHistory so that the new probe core would get the appropriate bit of RT config to make it act like the other probe cores.

I've poked around in RemoteTech's source a little bit, and it looks like this is the config file where it decorates the various stock probe cores from Squad.  They follow a pretty consistent pattern, so this gives me a reasonable idea of what would be needed to make the 1.875m probe core behave similarly.  Let's try that and see where it leads us.

I think I have an idea of what's going on, here (technical details in above spoiler).  I think I can fix this with a simple patch to MissingHistory, but I'd need someone to be my guinea pig to test it out and make sure it works.  @Nik kal, could you give the following a try and let me know whether it works?

Here's what to do, in spoiler section:

Spoiler

Here's some config that I believe will fix the problem:

@PART[probeStack_1p5]:FOR[RemoteTech]
{
    %MODULE[ModuleSPU] {
    }

    %MODULE[ModuleRTAntennaPassive]	{
        %TechRequired = unmannedTech
        %OmniRange = 3000

        %TRANSMITTER {
            %PacketInterval = 0.3
            %PacketSize = 2
            %PacketResourceCost = 15.0
        }
    }
}

So, here's what to do with it:

1. Create a new file in the MissingHistory folder (anywhere you like), with a name ending in ".cfg".
2. Using a text editor (Notepad or whatever), paste the above config into that file and save it.
3. Start up KSP (with RemoteTech installed, of course).
4. Test out the 1.875m probe core and see whether the problem is fixed.
5. Let me know how it went. 

If you could try that out, and if it solves the problem, then it will be very easy for me to release a MissingHistory patch that takes care of the problem.  Thanks!

[canisin]

On 6/1/2018 at 6:09 PM, Snark said:

Hm, interesting.

Various technobabble analysis in spoiler, for the curious:

  Hide contents

Well, as you can see from the 1.875m probe config, there's nothing there at all about local versus remote control-- it's just a rescaled clone of the 1.25m probe core, with a few numbers tweaked here and there.

So my guess is that whatever is going on here, it's on the RemoteTech side of things.  It's been a long time since I played RT and I have no idea what their config looks like, but just taking a wild guess here (based on the behavior you describe):  my guess is that RemoteTech adds some sort of custom config to probe cores that says "this requires a RemoteTech data connection".  In other words, I'm guessing that RT is designed that by default, all command parts have local control unless specified otherwise, and then adds specific "needs remote control" config to the probe cores.

If that guess is correct, it would explain why you're seeing the behavior you are:  I've added a "new" probe core that RemoteTech doesn't know about, and I haven't added any RemoteTech config to it, so it just gets the default RemoteTech behavior of having local control.

If that's what's going on, then presumably the thing to do would be for me to add a bit of patch config to MissingHistory so that the new probe core would get the appropriate bit of RT config to make it act like the other probe cores.

I've poked around in RemoteTech's source a little bit, and it looks like this is the config file where it decorates the various stock probe cores from Squad.  They follow a pretty consistent pattern, so this gives me a reasonable idea of what would be needed to make the 1.875m probe core behave similarly.  Let's try that and see where it leads us.

I think I have an idea of what's going on, here (technical details in above spoiler).  I think I can fix this with a simple patch to MissingHistory, but I'd need someone to be my guinea pig to test it out and make sure it works.  @Nik kal, could you give the following a try and let me know whether it works?

Here's what to do, in spoiler section:

  Hide contents

Here's some config that I believe will fix the problem:

@PART[probeStack_1p5]:FOR[RemoteTech]
{
    %MODULE[ModuleSPU] {
    }

    %MODULE[ModuleRTAntennaPassive]	{
        %TechRequired = unmannedTech
        %OmniRange = 3000

        %TRANSMITTER {
            %PacketInterval = 0.3
            %PacketSize = 2
            %PacketResourceCost = 15.0
        }
    }
}

So, here's what to do with it:

1. Create a new file in the MissingHistory folder (anywhere you like), with a name ending in ".cfg".
2. Using a text editor (Notepad or whatever), paste the above config into that file and save it.
3. Start up KSP (with RemoteTech installed, of course).
4. Test out the 1.875m probe core and see whether the problem is fixed.
5. Let me know how it went. 

If you could try that out, and if it solves the problem, then it will be very easy for me to release a MissingHistory patch that takes care of the problem.  Thanks!

Hello, this will be a bit of thread hi jacking but I couldn't resist asking. If this is indeed a problem, then I can gladly move it to a private message conversation.

1) Isn't it weird that RT hasn't taken care of all probes with a config that targets all parts with command module and minCrew of 0?

2) More interestingly, the ModuleRTAntennaPassive module in that config has a TechRequired parameter. I didn't know modules inside parts could have tech requirements. What does this do? How does it work?

[Nik kal]

On 6/1/2018 at 6:09 PM, Snark said:

Hm, interesting.

Various technobabble analysis in spoiler, for the curious:

  Reveal hidden contents

Well, as you can see from the 1.875m probe config, there's nothing there at all about local versus remote control-- it's just a rescaled clone of the 1.25m probe core, with a few numbers tweaked here and there.

So my guess is that whatever is going on here, it's on the RemoteTech side of things.  It's been a long time since I played RT and I have no idea what their config looks like, but just taking a wild guess here (based on the behavior you describe):  my guess is that RemoteTech adds some sort of custom config to probe cores that says "this requires a RemoteTech data connection".  In other words, I'm guessing that RT is designed that by default, all command parts have local control unless specified otherwise, and then adds specific "needs remote control" config to the probe cores.

If that guess is correct, it would explain why you're seeing the behavior you are:  I've added a "new" probe core that RemoteTech doesn't know about, and I haven't added any RemoteTech config to it, so it just gets the default RemoteTech behavior of having local control.

If that's what's going on, then presumably the thing to do would be for me to add a bit of patch config to MissingHistory so that the new probe core would get the appropriate bit of RT config to make it act like the other probe cores.

I've poked around in RemoteTech's source a little bit, and it looks like this is the config file where it decorates the various stock probe cores from Squad.  They follow a pretty consistent pattern, so this gives me a reasonable idea of what would be needed to make the 1.875m probe core behave similarly.  Let's try that and see where it leads us.

I think I have an idea of what's going on, here (technical details in above spoiler).  I think I can fix this with a simple patch to MissingHistory, but I'd need someone to be my guinea pig to test it out and make sure it works.  @Nik kal, could you give the following a try and let me know whether it works?

Here's what to do, in spoiler section:

  Reveal hidden contents

Here's some config that I believe will fix the problem:

@PART[probeStack_1p5]:FOR[RemoteTech]
{
    %MODULE[ModuleSPU] {
    }

    %MODULE[ModuleRTAntennaPassive]	{
        %TechRequired = unmannedTech
        %OmniRange = 3000

        %TRANSMITTER {
            %PacketInterval = 0.3
            %PacketSize = 2
            %PacketResourceCost = 15.0
        }
    }
}

So, here's what to do with it:

1. Create a new file in the MissingHistory folder (anywhere you like), with a name ending in ".cfg".
2. Using a text editor (Notepad or whatever), paste the above config into that file and save it.
3. Start up KSP (with RemoteTech installed, of course).
4. Test out the 1.875m probe core and see whether the problem is fixed.
5. Let me know how it went. 

If you could try that out, and if it solves the problem, then it will be very easy for me to release a MissingHistory patch that takes care of the problem.  Thanks!

That did the job. For both new and existing probes.

[Snark]

8 hours ago, canisin said:

1) Isn't it weird that RT hasn't taken care of all probes with a config that targets all parts with command module and minCrew of 0?

Not really.  If you look at the config I pasted, it has some specific numbers to use for that specific probe core.  In this case, I just copied the numbers from the RT config for the 1.25m probe core, since I've designed the 1.875m to act pretty much like the 1.25m in game terms.  But that's not something that would work in a one-size-fits-all fashion-- if some random mod adds a brand-new probe core to the game and wants it to work with RemoteTech, they'd have to pick the appropriate numbers based on how they want that probe core to behave.

8 hours ago, canisin said:

2) More interestingly, the ModuleRTAntennaPassive module in that config has a TechRequired parameter. I didn't know modules inside parts could have tech requirements. What does this do? How does it work?

Modules inside parts don't have tech requirements, as far as the stock game is concerned.  The base PartModule class, from which all part modules are derived, has no "TechRequired" property.  It's not a thing.

However, whenever some mod makes its own custom subclass of PartModule (such as ModuleRTAntennaPassive), of course, the modder who's coding it is free to give that module whatever properties and behavior they want.  It's their code, after all.  What that field actually does is going to be up to the modder.  So I assume that what's going on here is that whoever coded ModuleRTAntennaPassive happened to have some idea for "I want this to <have some behavior> based on whether some technology has been researched, and so I'll code it like this."  It would be an easy thing to do.  Of course, it would only apply to that specific module, and wouldn't apply to any other PartModule in the game.

[Snark]

Hi all,

I've released version 1.3.1 of MissingHistory.  This one adds a RemoteTech compatibility patch for the 1.875m probe core.  Thanks to @Nik kal for catching this, and verifying the fix!

(I've also updated the bundled ModuleManager to 3.0.7, which is the latest version.  This shouldn't have any effect on your gameplay.)

Enjoy!

[canisin]

7 hours ago, Snark said:

Not really.  If you look at the config I pasted, it has some specific numbers to use for that specific probe core.  In this case, I just copied the numbers from the RT config for the 1.25m probe core, since I've designed the 1.875m to act pretty much like the 1.25m in game terms.  But that's not something that would work in a one-size-fits-all fashion-- if some random mod adds a brand-new probe core to the game and wants it to work with RemoteTech, they'd have to pick the appropriate numbers based on how they want that probe core to behave.

Modules inside parts don't have tech requirements, as far as the stock game is concerned.  The base PartModule class, from which all part modules are derived, has no "TechRequired" property.  It's not a thing.

However, whenever some mod makes its own custom subclass of PartModule (such as ModuleRTAntennaPassive), of course, the modder who's coding it is free to give that module whatever properties and behavior they want.  It's their code, after all.  What that field actually does is going to be up to the modder.  So I assume that what's going on here is that whoever coded ModuleRTAntennaPassive happened to have some idea for "I want this to <have some behavior> based on whether some technology has been researched, and so I'll code it like this."  It would be an easy thing to do.  Of course, it would only apply to that specific module, and wouldn't apply to any other PartModule in the game.

Thanks for both of the explanations and for taking your time to explain them as clearly as they did.

For the first one, I just noticed that the passive antenna module added to each probe core was identical, so I thought a blanket patch would be more appropriate. But then again there are certainly some trade offs here, as in covering unknown modded parts and assigning specific divergent values to specific parts.

For the second one, as you have guessed my surprise was based on my assumption that techRequired was a vanilla parameter for part module. 

[Cavscout74]

I encountered a conflict when I installed the latest Missing History version 1.3.1 - previously I had 1.1.1 installed with no issues.   After installing 1.3.1, most of the antennas for Coatl Aerospace Probes Plus lost their antenna properties & the JX2 Antennas lost the ability to open but still seem to function as relay antennas even closed.  I reverted to my previous version of Missing History & everything is back to normal.  Has anyone else run into this kind of issue?

[Snark]

Hi all,

I've released v1.3.2 of MissingHistory.  This fixes a bug introduced with the 1.3.1 update that broke JX2Antenna parts, among others.

Many thanks to @Cavscout74 for catching this!

 

15 hours ago, Cavscout74 said:

I encountered a conflict when I installed the latest Missing History version 1.3.1 - previously I had 1.1.1 installed with no issues.   After installing 1.3.1, most of the antennas for Coatl Aerospace Probes Plus lost their antenna properties & the JX2 Antennas lost the ability to open but still seem to function as relay antennas even closed.  I reverted to my previous version of Missing History & everything is back to normal.  Has anyone else run into this kind of issue?

Argh.  After some investigation... yeah, that's a legitimate bug.  Looks like it's the RemoteTech patch in 1.3.1 that caused the problem.  Thank you so much for catching this!

Especially thank you for catching it before I did.  If you hadn't posted this, and then I happened to try to use JX2Antenna and found it all broken... I can't even imagine how much time I would have wasted trying to pin down what the dickens was going on, because I never in a million years would have suspected the MissingHistory 1.3.1 update as being the culprit.  I would have been chasing my tail for many hours.  (Technobabble discussion of the issue in spoiler section below, for the curious.)

Spoiler

So, here's what completely bamboozles me about this bug, and why it would likely have been so hard for me to figure out what was going on if I simply noticed that "oh noes JX2Antenna isn't working for some reason", and why I never would have suspected MissingHistory 1.3.1 as being the culprit:

• MissingHistory doesn't do anything with antennas.  At all.  It never has.  It probably never will.
• Corollary:  MissingHistory makes no reference to JX2Antenna at all, in any way.
• JX2Antenna is a completely stand-alone mod that doesn't depend on anything else.  It ought to be physically impossible for another mod to break JX2Antenna, unless that mod actually modifes JX2Antenna in some way (e.g. via ModuleManager patch).

In short:  MissingHistory and JX2Antenna have nothing whatsoever to do with each other, and I never, ever, ever would have suspected that there could be any sort of interaction between the two.

To make matters worse:  I run MissingHistory and JX2Antenna all the time (surprise, surprise), and have never had any problems at all.  The 1.3.1 update to MissingHistory literally doesn't do anything risky at all, as far as I can tell.  The only substantive thing I did in 1.3.1 was to add a patch for the 1.875m probe core.  Which isn't broken.  And which has nothing to do with JX2Antenna.  And even that change is set up so that it shouldn't have any effect unless RemoteTech is installed.  And I don't have RemoteTech installed.

It's absolutely stark raving silly.

To try to put this in non-programmer terms for the layperson:  Suppose you have a house, and one day you notice that your furnace is making a scary grinding noise and stops heating the house.  And that the thing that caused this is that you put new tires on your car.  Which isn't even parked in the house, but parked along the street.  You find that if you put a different brand of tires on your car, then suddenly your furnace is okay again.

And sure, naturally your immediate reaction to such a thing would be "well, that's silly".  But... how would you figure that out?  I mean, sure, if you come home one day and your housemate says "hey, I put new tires on the car and suddenly the furnace stopped working, so I tried swapping the tires back again and then it got better", then you'd at least know where the problem was, even if you haven't the foggiest clue why or how.

But suppose you hadn't had the diagnosis spoon-fed to you, like that?  Suppose you simply noticed the grinding noise in the furnace one day, and set out to figure out "how and why is my furnace broken".  What would you do?  Well, you'd probably take the furnace apart, examine all the pieces, and so forth... and then scratch your head when the furnace seems to be completely in perfect working order and nothing's broken and everything's clean and well-oiled and there's no earthly reason why it should be having problems, as far as you can tell.  At what point would it occur to you to wonder whether your car tires might have something to do with this?

Would it occur to you to think "gee, I wonder if the fact that I put new tires on my car could be causing my furnace problems"?  Probably not.  Goodness knows how much time you'd waste trying to track down the furnace problem, as long as you didn't know that the furnace is not the problem.

Sheesh.

Anyway, the problem eventually turned out to be a simple one-line fix.  The 1.3.1 patch for RemoteTech said this:

@PART[probeStack_1p5]:FOR[RemoteTech]

I find that when I changed it to this, the problem went away:

@PART[probeStack_1p5]:AFTER[RemoteTech]

So, to recap the whole sorry tale:

• Q: What was the problem?
• A: I said "FOR" instead of "AFTER" when patching the 1.875m probe core, and somehow that broke a completely unrelated part from a completely different mod, when neither of the two mods has any reference at all to the other one.
• Q: How did this cause the breakage?
• A: I haven't the slightest freaking clue.  It seems like it ought to be physically impossible for this problem to happen.
• Q: How did the change you made fix the problem?
• A: I haven't the slightest freaking clue.  It seems completely unrelated to JX2Antenna, and should only apply when RemoteTech is installed (which it isn't).  It ought to be physically impossible for this "fix" to have any effect on the problem.
• Q: But that's mad.
• A: Yes.

So, to sum up:  we have a problem that can't possibly happen, caused by a thing that can't possibly be related, with a fix that can't possibly solve the matter and which in any case only applies when a thing is there that isn't.  (So I should probably round it off with breakfast at Milliways...)

Sheesh.

And, finally, thank you for submitting your excellent bug report in such a clearly stated way, which also saved me loads of time by nicely zeroing in on exact repro steps so I could figure out what's going on.  It's hard to express just how deeply a programmer appreciates good bug reports.

Anyway, the good news is that it turned out to be very easy to fix.   So, everyone wins. 

 

[Cavscout74]

1 hour ago, Snark said:

MissingHistory doesn't do anything with antennas.  At all.  It never has.  It probably never will.

  I had actually updated 3 mods yesterday - Jet's Chop Shop, Missing History & RLA Reborn (actually switched from RLA Recontinued).  Except both Chop Shop & RLA I've removed some of the parts I didn't use, so I spent most of my time finding & removing the unused parts from the new versions & forgot about Missing History.  And then was mystified that reverting Chop Shop & RLA didn't fix the antenna problem.   I actually had to look in the folder I store my previous version mods in & sort by date to remember MH was also updated, then was wondering how a mod with no antennas in it messed up an antenna mod.  For the record, I don't have RemoteTech either.

I'm not a programmer, but I am an aircraft mechanic, so I'm familiar with troubleshooting problems & occasionally running into one that defies reason, so I'm glad I could help you out.  I once had a Cessna 208 that had been having gremlins in the avionics power supply for days (specifically intermittent power losses), we'd swapped multiple components, chased wires, etc, and finally a stray beagle walked onto the airport, hiked his leg on one of the aircraft tires & wandered off.  And the avionics power supply never had another problem.

[4x4cheesecake]

1 hour ago, Snark said:

Technobabble discussion of the issue in spoiler section below, for the curious.

 

21 minutes ago, Cavscout74 said:

a stray beagle walked onto the airport, hiked his leg on one of the aircraft tires & wandered off.  And the avionics power supply never had another problem.

Both stories...just hilarious

[Snark]

1 hour ago, Cavscout74 said:

I once had a Cessna 208 that had been having gremlins in the avionics power supply for days (specifically intermittent power losses), we'd swapped multiple components, chased wires, etc, and finally a stray beagle walked onto the airport, hiked his leg on one of the aircraft tires & wandered off.  And the avionics power supply never had another problem.

My folks had a beagle, so I already knew that beagles are really smart, but this takes it to a whole new level!  Anyway, great story.  TIL:

• Beagles are even smarter than we think.
• There are some things they don't teach you in aircraft mechanic school.

Well, at least you learned a new repair technique!  Hopefully, you'll be able to bring this wisdom to your fellow mechanics when they're faced with an intractable avionics problem.  "Well, have you tried peeing on the tires?"

(Okay, now I find myself totally wanting to rename the Cheetah engine as the Beagle.  It fits in with the dog-named-orbital-engines theme, is bigger than a terrier but smaller than a wolfhound...)

[JAFO]

8 hours ago, Snark said:

Anyway, the problem eventually turned out to be a simple one-line fix.  The 1.3.1 patch for RemoteTech said this:

@PART[probeStack_1p5]:FOR[RemoteTech]

I find that when I changed it to this, the problem went away:

@PART[probeStack_1p5]:AFTER[RemoteTech]

So, to recap the whole sorry tale:

• Q: What was the problem?
• A: I said "FOR" instead of "AFTER" when patching the 1.875m probe core, and somehow that broke a completely unrelated part from a completely different mod, when neither of the two mods has any reference at all to the other one.
• Q: How did this cause the breakage?
• A: I haven't the slightest freaking clue.  It seems like it ought to be physically impossible for this problem to happen.
• Q: How did the change you made fix the problem?
• A: I haven't the slightest freaking clue.  It seems completely unrelated to JX2Antenna, and should only apply when RemoteTech is installed (which it isn't).  It ought to be physically impossible for this "fix" to have any effect on the problem.
• Q: But that's mad.
• A: Yes.

So, to sum up:  we have a problem that can't possibly happen, caused by a thing that can't possibly be related, with a fix that can't possibly solve the matter and which in any case only applies when a thing is there that isn't. 

My guess would be that it somehow caused something convoluted to occur within the inner workings of MM. An edge-case scenario where it borked the internal logic employed by MM, perhaps. It may be worth passing along the relevant info to Sarbian to have a look at.

 

8 hours ago, Snark said:

(So I should probably round it off with breakfast at Milliways...)

Absolutely!

[Eskell]

19 hours ago, Snark said:

Anyway, the problem eventually turned out to be a simple one-line fix.  The 1.3.1 patch for RemoteTech said this:

@PART[probeStack_1p5]:FOR[RemoteTech]

I find that when I changed it to this, the problem went away:

@PART[probeStack_1p5]:AFTER[RemoteTech]

IFAIK the cause of the problem is, that the :FOR[RemoteTech]statement marks the patch as a internal part of RemoteTech mod and, as a side effect, MM will assume that RemoteTech mod is present. So all other patches with condition :NEEDS[RemoteTech]will now be applied. This may lead to some unintended behavior.

[Cavscout74]

Ok, now you're going to start hating me.  The newest 1.3.2 is causing several of my craft files (happily no ships in use) to show ***Contains locked or invalid parts***    And when I try to load any of them, I get "Craft xxxx was not loaded because:  It had the following parts missing:  Size3.Size2.Tank"     Yet both old & new versions of MH have that part .cfg file.  I haven't gone line by line through the files though.

[Snark]

11 hours ago, Cavscout74 said:

Ok, now you're going to start hating me.  The newest 1.3.2 is causing several of my craft files (happily no ships in use) to show ***Contains locked or invalid parts***    And when I try to load any of them, I get "Craft xxxx was not loaded because:  It had the following parts missing:  Size3.Size2.Tank"     Yet both old & new versions of MH have that part .cfg file.  I haven't gone line by line through the files though.

What version of ModuleManager are you running? Is it 3.0.7, which is the version installed with MissingHistory 1.3.2? Or are you running some older version of MM?

[cyberKerb]

Hi @Snark, it seems the MM patch to add EnginePlate1 based on MH EnginePlate2 has a minor issue with the ModuleDecouple

[LOG 22:52:02.697] PartLoader: Compiling Part 'SquadExpansion/MakingHistory/Parts/Coupling/EnginePlate_2/EnginePlate1'
[ERR 22:52:02.716] Invalid float value! Field ejectionForce, value 100; on object of type ModuleDecouple

Looking at the MM code, it only has the following in relation to the decoupling

    @MODULE[ModuleDecouple] {
        @ejectionForce = 100;
    }

I think the issue is the wayward semi-colon.

Edited June 9, 2018 by wile1411

[Snark]

9 hours ago, wile1411 said:

it seems the MM patch to add EnginePlate1 based on MH EnginePlate2 has a minor issue with the ModuleDecouple
...
I think the issue is the wayward semi-colon.

Argh.  Yep, that's the problem, all right.  Occupational hazard of being a programmer; my fingers keep wanting to put a semicolon at the end of every line.  Sigh.

(Just in case, I just now did a quick grep just now through all the config files for all of my mods, and that one spot was the only place anywhere that a semicolon leaked through, so it looks like I'm otherwise clean.  Whew.  In case you're wondering, the technical term for that particular operation is a... semicolonoscopy.  <drops mic>) 

I've gone ahead and pushed a fix to the github repo for the part-- here's the updated config.  For now, I'll hold off on doing an actual new version release of the mod, since this is a fairly small bug and I don't want to spam updates too much; but the fix will get rolled into the next release.

Anyway, thank you very much for catching!

[cyberKerb]

5 hours ago, Snark said:

Argh.  Yep, that's the problem, all right.  Occupational hazard of being a programmer; my fingers keep wanting to put a semicolon at the end of every line.  Sigh.

(Just in case, I just now did a quick grep just now through all the config files for all of my mods, and that one spot was the only place anywhere that a semicolon leaked through, so it looks like I'm otherwise clean.  Whew.  In case you're wondering, the technical term for that particular operation is a... semicolonoscopy.  <drops mic>) 

[Cavscout74]

On 6/9/2018 at 11:19 AM, Snark said:

What version of ModuleManager are you running? Is it 3.0.7, which is the version installed with MissingHistory 1.3.2? Or are you running some older version of MM?

Just double checked & it is 3.0.7

[Snark]

3 hours ago, Cavscout74 said:

Just double checked & it is 3.0.7

Hmm.  Well then, I have no clue what it might be.

If you were running anything older than MM 3.0.7-- for example, 3.0.6, which is what MissingHistory used up through version 1.3.1-- then I expect that would precisely explain the symptoms.  That's because in MissingHistory 1.3.2, I made a change to the config that requires 3.0.7 (or later), and if someone were still running 3.0.6 or older, I expect they'd get an error that looks exactly like what you're getting.

But if you're using MM 3.0.7, I haven't an earthly.  Just now went and checked my KSP 1.4.3 install, running MissingHistory 1.3.2 with ModuleManager 3.0.7... and it works just fine.  I can create a new craft with the S2-S3 tank on it just fine, no problems.  Can create it in the VAB, can save it, can load it from the saved file, can launch it.  I even went back and found a prior career game from before MissingHistory 1.3.2 that had some "legacy" ships with that part in them, and they loaded just fine, too.

So, at this point I'm out of ideas, since it works fine for me and I don't have any way of reproducing the problem.  Sorry about that. 

[Cavscout74]

25 minutes ago, Snark said:

Hmm.  Well then, I have no clue what it might be.

Thanks for checking.  I tried reinstalling, with the MM 3.0.7 out of your zip instead of the one I already had, and no difference.  The older MH still works for me at least.