[Min KSP: 1.12.2] Mark One Laboratory Extensions (M.O.L.E.)

[OrbitalManeuvers]

Hi. Checking out this cool mod. Thanks for working on it.

I find the SRM performance to be surprising. In screenshot one, notice TWR 1.34. I have the thrust limiter at 24.5. Next shot, literally one second later, the TWR has tripled after barely consuming any fuel. It seems to increase exponentially with every second that passes.

Same test with a Hammer turned down to 36.5 will take over 5 seconds to increase TWR to 1.4.

This is 1.10.1, latest MOLE from last night. Is this working as intended?

Edit: i started looking into this after building a more reasonably scaled rocket with a few fuel segments. I started with a TWR on the pad of 1.36 and broke 300m/s before 100 meters alt as the TWR skyrocketed weeeeeee.

Spoiler

Check out mission time (1 sec), TWR (4.25 after 1 second), and fuel consumed.

 

Edited September 2, 2020 by OrbitalManeuvers
added info about scale

[JadeOfMaar]

3 hours ago, OrbitalManeuvers said:

I find the SRM performance to be surprising. In screenshot one, notice TWR 1.34. I have the thrust limiter at 24.5. Next shot, literally one second later, the TWR has tripled after barely consuming any fuel. It seems to increase exponentially with every second that passes.

The Sledgehammer SRM has a number of engine modes, each for a different use case and each has a thrust curve so thrust rises and falls as the fuel amount changes. The massive thrust -should- be the effect of your test craft being nothing but a small pod, a short tank and the engine.

I've changed the options in the Sledgehammer (and found and fixed a problem that I somehow caused: its engine mode options are loaded twice. So maybe that's where your problem is coming from) so perhaps your problem will go away. If this happens with stock SRMs then I have no clue.

Spoiler

Then your install is cursed and needs to be nuked.

 

[OrbitalManeuvers]

  

58 minutes ago, JadeOfMaar said:

If this happens with stock SRMs then I have no clue.

That's why I put test results from the Hammer in the original message, and also edited to say the same thing happens on a full-scale rocket. This engine is nothing like stock.

[JadeOfMaar]

I guess I should add a default mode with no thrust curve.

[OrbitalManeuvers]

idk! I'm still just scraping the surface of this mod, trying to figure out its intended uses. Makes sense to me to understand what the authors are aiming for before asking for any changes. 

[capi3101]

Alright, so @taniwha released a new version of Extraplanetary Launchpads today, with instructions to check for a group of parts in saves and craft files that would become broken with this new version. Are any of the MOLE or Pathfinder parts dependent on any of the same underlying functions as those parts? I ask because after checking for them in my current save file and finding none, the old undocking bug seems to be rearing up its ugly head again (can't undock from stations with Drydocks without the whole damn thing blowing up). Would be awful nice to know what I'm looking for to see if I can do a quick KML fix.

[taniwha]

@capi3101 It's only the parts themselves (EL's Auger, Smelter, etc) that are affected, not the functionality attached to them, so other mods should not be affected in any way. I appologize if that wasn't clear.

[capi3101]

7 hours ago, taniwha said:

@capi3101 It's only the parts themselves (EL's Auger, Smelter, etc) that are affected, not the functionality attached to them, so other mods should not be affected in any way. I appologize if that wasn't clear.

Hmm...that being the case, there's a new unholy interaction going on. I was able to un-dock just fine with the shipyard prior to yesterday's EL update. I'll see about getting some data for y'all.

EDIT: Still happening this morning. I had a craft docked to the space station in question - undocked that craft without issue though DPAI wasn't functioning properly. Docked my second craft again, refueled it and undocked it; it partially exploded, accelerated to a point where it escaped Mun's SOI and then proceeded to completely self-destruct.

Here's the log for the session. At this point I'm less certain that it's either MOLE or EL...all the same, this is new behavior since the EL update.

EDIT EDIT: Okay, after further fiddling, it appears to be a problem with just the one specific craft. KML time, looks like.

Edited September 7, 2020 by capi3101

[capi3101]

Alright, at 1:30 AM local, I finally remembered what caused the undocking bug and the repair. It's a related problem, so I'm posting.

The undocking bug was something I was experiencing a few versions of Pathfinder ago, when I couldn't get Castillo retraining of colonists working and was using KML to do that bit manually. I had missed a bit in the code that still had the affected Kerbals added to the Colonization contract scenario, so what would happen is that when I had one of those colonists aboard a craft, it would prevent the game from quicksaving, switching, quitting or cutting over to the Space Center or Tracking Station. Undocking would result in a kraken. The repair simply involved removing the names of the affected kerbals from the involved contract scenario. The name removal took place earlier this morning; I have yet to see if that did the trick or not but I have no reason to suspect that it didn't.

In this particular case, what happened was that I picked up a contract to send twelve kerbals to a piece of debris from which I had rescued a different kerbal on a previous mission; I had failed to terminate said debris once that contract was complete (and the game still had it listed as a Ship). The contract was to send the kerbals out there for thirty days and at √15M the pay was too good to pass up; I'd have skipped it otherwise. Bill tagged along with a docking port and screwdriver for the job to attach to the debris and docking was successful. Once the contract was complete and I had the money, the kerbals departed without being re-trained first...after all, it was an orbiting piece of debris; no Castillo there, obviously. But my space program is shorthanded right now, so I didn't want to just send those twelve back to Kerbin...

So a couple of things - I know that colonization missions have something to do with a function that, IIRC, is called TouristTrap. I'm pretty sure that function is supposed to check for sites that contain Castillos as possible target sites, so was this a bonafide bug? At the time I accepted the mission I didn't have any bases with a deployed Castillo (started a new save with 1.10.1). Also, are there any other extant parts that handle the retraining of kerbal colonists?

Edited September 8, 2020 by capi3101

[Bit Fiddler]

I believe this is the mod that adds the small light named "Station Light".  If this is true, then I have a request for this part. 

 

as it is now if I assign all the lights on the station to the "Lights" action group and launch everything works fine up until the point where something happens to cause loss of power to the craft.  When this happens of course all the lights on the craft will go out, but the problem comes in when the power is restored.  Most lights on the craft will still be in sync with the "Lights" button in the UI.  However, this part is now out of sync with the UI button.  When I press "Lights" on the UI, all the other lights on the station are on when the UI button is white.  However, all these "Station Lights" are on when the button is black.

 

It seems other lights are not just a simple "toggle" when the button is pressed, but will somehow read the state of the UI button itself.  It would be nice if these lights worked the same way, as I could just use the UI button, and not have to make an action group just for these "Station Lights".

[capi3101]

Got a contract to do a Surface Construction Study contract on Mun. I've got the thing in a Pathfinder Castillo Observatory with four Scientists in it and the prerequisite facility is also present (and the base has productivity around +3 or so), but I'm getting a message that says "Needs Kerbin;Mun;Minmus"; the contract appears to be stuck in that state. I'm confused as to what's going on there, since (as mentioned) the experiment is Landed on Mun, and should have that prerequisite fulfilled.

Edited October 1, 2020 by capi3101

[Angelo Kerman]

MOLE 1.23 is here- now with CKAN support!

Thanks to JadeOfMaar:
- Added BetterSRBs integration for Sledgehammer SRM.
- Added experiment slot patch for Restock+ conical science box.
- Fixed Raptium tuning in LFO engines (corvette, Hemi-Cuda, Fulcrum).
- Fixed Sledgehammer SRM multimode behavior.
- Fixed Sledgehammer SRM plumes behavior.
- Fixed SRMFuel flow mode to make it respect staging.

[DeadJohn]

@Angel-125 or others, is welding of MOLE Mk2 Docking Ports still broken?

Here's a test I did with MOLE 1.22 and KSP 1.10.1.

Case 1: This was a complex station with a mix of MOLE, Near Future, SSPXr, and stock parts. I tried a weld and a whole bunch of weird stuff happened, in this order:

1. I immediately lost control of my EVA engineer and station. The camera was locked into space where I did the weld. I could change the camera angle but I wasn't in control of any vessel.
2. The square-bracket keys would not let me get to my engineer or station. Orbital speed is fast but I think they were still in range.
3. Pressing M got me to the map window, but clicking on my station (or on other vessels) did nothing. I couldn't get the menu to select or switch control to a vessel.
4. The Tracking Station eventually got me back to my station.
5. The weld did something. It looked like the ports were gone, the station was still one vessel and not broken, but there was a gap where the ports used to be. Is welding supposed to shift parts?
6. KSP.LOG contained "[WRN 12:34:29.875] [AttachNode]: Unable to invert surface node on Octo-Girder Pressurized Adapter. Set to center of part." That led me to suspect a mod compatibility issue with Near Future Construction so I proceeded to Case 2.

Case 2: This was a simple test craft. 2 stock Mk1 landing cans joined with 2 MOLE Mk2 docking ports. The ports were connected in VAB, not docked during gameplay like with Case 1. I tried a weld on the launch pad. The ports vanished but the landing cans didn't connect with each other; I now had 2 separate vessels on the launch pad.

 

 

[Angelo Kerman]

24 minutes ago, DeadJohn said:

@Angel-125 or others, is welding of MOLE Mk2 Docking Ports still broken?

Here's a test I did with MOLE 1.22 and KSP 1.10.1.

Case 1: This was a complex station with a mix of MOLE, Near Future, SSPXr, and stock parts. I tried a weld and a whole bunch of weird stuff happened, in this order:

1. I immediately lost control of my EVA engineer and station. The camera was locked into space where I did the weld. I could change the camera angle but I wasn't in control of any vessel.
2. The square-bracket keys would not let me get to my engineer or station. Orbital speed is fast but I think they were still in range.
3. Pressing M got me to the map window, but clicking on my station (or on other vessels) did nothing. I couldn't get the menu to select or switch control to a vessel.
4. The Tracking Station eventually got me back to my station.
5. The weld did something. It looked like the ports were gone, the station was still one vessel and not broken, but there was a gap where the ports used to be. Is welding supposed to shift parts?
6. KSP.LOG contained "[WRN 12:34:29.875] [AttachNode]: Unable to invert surface node on Octo-Girder Pressurized Adapter. Set to center of part." That led me to suspect a mod compatibility issue with Near Future Construction so I proceeded to Case 2.

Case 2: This was a simple test craft. 2 stock Mk1 landing cans joined with 2 MOLE Mk2 docking ports. The ports were connected in VAB, not docked during gameplay like with Case 1. I tried a weld on the launch pad. The ports vanished but the landing cans didn't connect with each other; I now had 2 separate vessels on the launch pad.

 

 

Yup, I haven't touched them in a long time.

Meantime, I've fixed the missing textures in MOLE 1.24.0.

[DeadJohn]

1 hour ago, Angel-125 said:

Yup, I haven't touched them in a long time.

Meantime, I've fixed the missing textures in MOLE 1.24.0.

Thanks for confirming the welded docking port issue.

I upgraded from 1.22.1 to 1.24.0 and got 3 Module Manager errors related to MM_BetterSRBs.cfg, which then triggers a "B9PartSwitch - Serious Warning" window on the main menu. Log file at https://drive.google.com/file/d/1pwp2zY0nlCW_vKeXAVLr2wisv4CdXdLL/view?usp=sharing

If I go back to MOLE 1.22.1 and leave all other mods as-is, neither MM nor B9PS report major errors while loading. The problem returns if I try MOLE 1.23 or 1.24. I'll guess that it's related the Sledghammer changes you credited to @JadeOfMaar.

Here's a portion of the log:

Spoiler

[LOG 15:39:14.491] Applying update WildBlueIndustries/MOLE/ModuleManagerPatches/MM_BetterSRBs/@PART[WBI_Sledgehammer]:NEEDS[BetterSRBs] to WildBlueIndustries/MOLE/Parts/Engine/Sledgehammer/Sledgehammer.cfg/PART[WBI_Sledgehammer]
[ERR 15:39:14.492] Error - Cannot parse variable search when inserting new key maxThrust = #$/MODULE[ModuleEnginesFX]/maxThrust01$
[ERR 15:39:14.492] Error - Cannot parse variable search when inserting new key maxThrust = #$/MODULE[ModuleEnginesFX]/maxThrust02$
[ERR 15:39:14.492] Error - Cannot parse variable search when inserting new key maxThrust = #$/MODULE[ModuleEnginesFX]/maxThrust01$

 

 

[JadeOfMaar]

@DeadJohn I think that's an "Ooooooh boy. I didn't actually define that" incident or an "I accidentally pushed the obsolete version" incident. Try this. Save it anywhere in GameData, even in the MOLE folder:

@PART[WBI_Sledgehammer]:NEEDS[MOLE]:BEFORE[BetterSRBs]
{
	@MODULE[ModuleEnginesFX],0
	{
		maxThrust01 = 1360 // 80% of maxThrust
		maxThrust02 = 2040 // 120% of maxThrust
	}
}

 

[DeadJohn]

10 hours ago, JadeOfMaar said:

@DeadJohn I think that's an "Ooooooh boy. I didn't actually define that" incident or an "I accidentally pushed the obsolete version" incident. Try this. Save it anywhere in GameData, even in the MOLE folder:

[snipped for brevity]

My current save won't load regardless of that patch. I found that some parts were removed from 1.24 (SPF1, 2, 3 .cfg solar panels and maybe others) but I already have vessels in flight with those parts. I've decided to just stick with 1.22.1 until I start a new playthrough.

 

[capi3101]

Just upgraded from 1.22.1 to 1.24.0. I'm getting a message when attempting to load my 1.10.1 career save about parts missing from my various deployed craft - specifically the Appaloosa Block 2, Colt and Mk1 Docking Port. This after a full purge of the 1.22.1 directories and clean install of 1.24. Here's the log file from the last attempt; not really seeing anything useful there. I'll roll back a bit and see if I can get the save to load without the error message coming up. Definitely a concerning issue since I don't think I've got a single craft deployed right now that doesn't include at least one of those three parts.

 

EDIT: No luck with 1.23 either. Going to roll back to 1.22.1.
EDIT EDIT: Well, now I don't know what's going on. Got it back to 1.22.1 but it's still doing it...

Edited October 20, 2020 by capi3101

[razark]

1 hour ago, capi3101 said:

Just upgraded from 1.22.1 to 1.24.0. I'm getting a message when attempting to load my 1.10.1 career save about parts missing from my various deployed craft - specifically the Appaloosa Block 2, Colt and Mk1 Docking Port.

I can confirm something happened to some of the parts.  I was able to get the Mk1 and Mk2 docking ports to stop complaining, but the Appaloosa OrbitalModule eluded me.

From 1.22.0:
    name = wbiMk1DockingPort
and:
    name = wbiMk2DockingPort

From 1.24.0:
    name = WBI_Mk1DockingPort
and:
    name = WBI_Mk2DockingPort

 

1 hour ago, capi3101 said:

EDIT: No luck with 1.23 either. Going to roll back to 1.22.1.
EDIT EDIT: Well, now I don't know what's going on. Got it back to 1.22.1 but it's still doing it...

Double check you got rid of the 1.24.0 version completely.  I was able to swap 1.22.0 back in and everything worked.

Edited October 20, 2020 by razark

[Angelo Kerman]

Can you give 1.24.1 a try?

[razark]

I just installed 1.24.1, and it fixes the inability to load for the parts I was having an issue with.

I did notice that this version has some z-fighting on some parts, noticeably the Habitat and the Botany modules, that wasn't there in 1.22.0.

[Angelo Kerman]

1 hour ago, razark said:

I just installed 1.24.1, and it fixes the inability to load for the parts I was having an issue with.

I did notice that this version has some z-fighting on some parts, noticeably the Habitat and the Botany modules, that wasn't there in 1.22.0.

Ok for that, the MOH18 and MOBL part configs need the following:

	MODULE
	{
		name = WBIMeshHelper
		objects = Cylinder003,TankSleeve002;MohBodyWhite
		guiNames = Theme: Black and White;Theme: MOLE White
		editorOnly = true
		showGui = true
		showPrev = false
	}

I'll fix that this weekend. Any other issues you've noticed?

[razark]

Just now, Angel-125 said:

I'll fix that this weekend. Any other issues you've noticed?

I haven't noticed anything else, but I only really loaded it up to make sure everything loaded properly.

[Angelo Kerman]

MOLE 1.24.2 should fix the z-fighting.

[razark]

That fixed the Habitat.

I am still seeing it on the Botany Lab, Solar Batter Module, MOLE Battery Module, and MOLE Power Module.