[1.02] (.50)ExtraPlanetary LaunchPads Extended-Part Pack (and extras!)

[Jagzeplin]

the one you uploaded on 16th

edit- oh i just realized you probably meant the pre-release. im using the mks.20/karb.3 prerelease

[rabidninjawombat]

Just added in some Re-Textured Smelter models, courtesy of Mossman. Great looking models. 3 version, Humongous, regular, and tiny.

CFG's have been updated to work with Karbonite. (these are added to both versions of the download) Just added some small touches to the textures for now, but adding more as i get time.

[boribori]

I have an issue with the blue workshop and the USI converter. It won't convert metal to rocketparts. I think because it has no storage for scrapmetal, when I add the rocket building workshop (which has storage for scrapmetal) the blue workshop does convert metal to rocketparts.

I use KSP 24.2 x64 linux, with MKS 0.20.4, Karbonite adaptation v.14 and EPL 4.2.3.

I guess its an easy fix, I just don't know if I should add scrapmetal storage space to the workshop or remove the requirement for that space. And I'm not sure which files to edit.

[Spagoose]

A couple things I have noticed in the config for the pre-releases:

You no longer need the default karbonite drills extracting ORE if you have MKS because they now have their own drills.

The OMD automatically deploys and there is no buttons for deploying/retracting but I imagine that is an animation issue.

[rabidninjawombat]

I have an issue with the blue workshop and the USI converter. It won't convert metal to rocketparts. I think because it has no storage for scrapmetal, when I add the rocket building workshop (which has storage for scrapmetal) the blue workshop does convert metal to rocketparts.

I use KSP 24.2 x64 linux, with MKS 0.20.4, Karbonite adaptation v.14 and EPL 4.2.3.

I guess its an easy fix, I just don't know if I should add scrapmetal storage space to the workshop or remove the requirement for that space. And I'm not sure which files to edit.

You are correct, the issue is with the lack of scrapmetal storage. (I always tested with the workshop attached to a smelter which has scrapmetal storage so i never noticed this, Sorry!) The new USI converters syntax is a little different than the old one.

Just uploaded a fix to the download, which adds scrap metal storage to the Workshop and the Rocketbuilder.

Note this only applies to the pre-release version.

Tested it and all appears to be good. Rainbows and Unicorns for everyone.

A couple things I have noticed in the config for the pre-releases:

You no longer need the default karbonite drills extracting ORE if you have MKS because they now have their own drills.

The OMD automatically deploys and there is no buttons for deploying/retracting but I imagine that is an animation issue.

Correct On the Karbonite drills, But the config is made also made for folks who just have Karbonite too. If they have Karbonite and not MKS, the drills only do karbonite, Thats why the config uses the tag [!KolonyTools]. This makes it so those particular modules only run if the user does not have MKS, so that ore extraction gets added to their drills.

And yes, the OMD is a known issue it uses the Kethane animator so its broke with karbonite, If i find a workaround ill get it added.

Edited August 19, 2014 by rabidninjawombat

[boribori]

Thanks for the quick fix!

[Spagoose]

Correct On the Karbonite drills, But the config is made also made for folks who just have Karbonite too. If they have Karbonite and not MKS, the drills only do karbonite, Thats why the config uses the tag [!KolonyTools]. This makes it so those particular modules only run if the user does not have MKS, so that ore extraction gets added to their drills.

And yes, the OMD is a known issue it uses the Kethane animator so its broke with karbonite, If i find a workaround ill get it added.

In that case I think think the [!KolonyTools] tag isn't working as intended because with MKS I am still getting ore being added to the karbonite only drill and had to remove that segment manually.

[rabidninjawombat]

In that case I think think the [!KolonyTools] tag isn't working as intended because with MKS I am still getting ore being added to the karbonite only drill and had to remove that segment manually.

Im gonna assume that you didn't upgrade to the Pre-release compatibility version then. Its download is on the front page if your interested. If your using the MKS Pre-release wchih im assuming your are based on your post, you should grab the new download, the old one will work (as the old legacy converter code is still in Karbonite) but the new converters work on rails, which is awesome.

Tested in install with MKS 20.4PRE, and Karbonite 3.0PRE , all appears happy and good.

[Spagoose]

Im gonna assume that you didn't upgrade to the Pre-release compatibility version then. Its download is on the front page if your interested. If your using the MKS Pre-release wchih im assuming your are based on your post, you should grab the new download, the old one will work (as the old legacy converter code is still in Karbonite) but the new converters work on rails, which is awesome.

I figured it out, I thought I did install the pre-release version on but somehow the old version was hidden in a completely unrelated folder which was overriding it and adding the extra resource extraction.

[Gaalidas]

I don't know if this has been discussed earlier in this thread, but my brain is itching to make this revelation here and I'm running out of time to go get my starbucks drink while allowing my mother to pay for it (need caffeine fix now!) so here goes...

I was reading a bit on the first page (yeah, I know, that was like... forever... ago) and I thought I should point something out here that is being ignored by the majority of people out in the add-on development world with respects to module manager. Module manager does not only look at configs which are formatted for it's own patching process. In fact, it can read configuration specifically made for it's patching process from within the configs of the parts themselves. What this means is that you can take something like this:

MM config:

@PART[partnamehere]:NEEDS[neededmodhere]
{

[INDENT]MODULE
{[/INDENT]

[INDENT=2]name = neededmodule[/INDENT]

[INDENT]}[/INDENT]

}

And turn it into something like this:

PART config:

PART
{

[INDENT]name = partname
part config stuff here
...

MODULE:NEEDS[neededmod]
{[/INDENT]

[INDENT=2]name = neededmodule
a bunch of other parameters[/INDENT]

[INDENT]}
MODULE:NEEDS[!neededmod]
{[/INDENT]

[INDENT=2]name = alternativemod
a bunch of alternative parameters[/INDENT]

[INDENT]}[/INDENT]

}

So, what's happening here? Well, module manager will look at this and compare those needs to what it can tell is installed and it will then remove the one in which the needs cannot be met. This is done without having to ship an external cfg file that contains just a few lines of code to patch a module out of a config. This also cuts down on the time it could take to remove a module from a config and replace it with something else, or anything else you could need to do in a patch. You can also put a needs section following the PART entry at the top of the part config to force it to only become available in the VAB/SPH if the needs are met.

Also, the above code, used in context of my own modding needs, works without a hitch. I use it mainly to replace ModuleAnimateGeneric entries with FSanimateGeneric entries based on the status of Firespitter.dll, which could theoretically disappear from my install if an alternative for the texture/model switch and animations makes itself available. I don't want to have to search for all my various module manager configs to eliminate any pre-needs-filter patches that are replacing modules with firespitter-specific modules.

If this is all old news, then please disregard. I just thought this little bit of information could help to make the parts in this kind of project compatible with any number of different situations without requiring half a dozen separate module manager configs, some of which would need to be removed by the end user if the mod they apply to is not installed (if the config somehow gets past quality control without a needs filter in it).

Standard disclaimer in my signature applies here... in the extreme sense.

[rabidninjawombat]

I don't know if this has been discussed earlier in this thread, but my brain is itching to make this revelation here and I'm running out of time to go get my starbucks drink while allowing my mother to pay for it (need caffeine fix now!) so here goes...

I was reading a bit on the first page (yeah, I know, that was like... forever... ago) and I thought I should point something out here that is being ignored by the majority of people out in the add-on development world with respects to module manager. Module manager does not only look at configs which are formatted for it's own patching process. In fact, it can read configuration specifically made for it's patching process from within the configs of the parts themselves. What this means is that you can take something like this:

MM config:

@PART[partnamehere]:NEEDS[neededmodhere]
{

[INDENT]MODULE
{[/INDENT]

[INDENT=2]name = neededmodule[/INDENT]

[INDENT]}[/INDENT]

}

And turn it into something like this:

PART config:

PART
{

[INDENT]name = partname
part config stuff here
...

MODULE:NEEDS[neededmod]
{[/INDENT]

[INDENT=2]name = neededmodule
a bunch of other parameters[/INDENT]

[INDENT]}
MODULE:NEEDS[!neededmod]
{[/INDENT]

[INDENT=2]name = alternativemod
a bunch of alternative parameters[/INDENT]

[INDENT]}[/INDENT]

}

So, what's happening here? Well, module manager will look at this and compare those needs to what it can tell is installed and it will then remove the one in which the needs cannot be met. This is done without having to ship an external cfg file that contains just a few lines of code to patch a module out of a config. This also cuts down on the time it could take to remove a module from a config and replace it with something else, or anything else you could need to do in a patch. You can also put a needs section following the PART entry at the top of the part config to force it to only become available in the VAB/SPH if the needs are met.

Also, the above code, used in context of my own modding needs, works without a hitch. I use it mainly to replace ModuleAnimateGeneric entries with FSanimateGeneric entries based on the status of Firespitter.dll, which could theoretically disappear from my install if an alternative for the texture/model switch and animations makes itself available. I don't want to have to search for all my various module manager configs to eliminate any pre-needs-filter patches that are replacing modules with firespitter-specific modules.

If this is all old news, then please disregard. I just thought this little bit of information could help to make the parts in this kind of project compatible with any number of different situations without requiring half a dozen separate module manager configs, some of which would need to be removed by the end user if the mod they apply to is not installed (if the config somehow gets past quality control without a needs filter in it).

Standard disclaimer in my signature applies here... in the extreme sense.

Thanks for the info =) I was aware of this particular feature of MM, though it doesn't really apply in the very limited scope of this particular project

Edited August 20, 2014 by rabidninjawombat

[rabidninjawombat]

Added in two new parts

An Orbital Rocket Workshop (using OKS style module) complete with pre-attached orbital Dock, so you can process metal into rocketparts, and build ships to launch. (No more blue workshop sticking out )

And an Inflatable Rocketparts storage tank.

Goes great with any MKS/OKS space station.

Javascript is disabled. View full album

Edited August 22, 2014 by rabidninjawombat

[Tabakhase]

Hi there,

to get the OMD partly fixed just reenable the ModuleAnimateGeneric, its removed in favor of KethaneDetectorAnimatorUnity in the original EPL.

adding this code it starts packed in the VAB and can be opend/closed in flight =)

@PART[OMD]
{
	MODULE
	{
	   name = ModuleAnimateGeneric
	   animationName = Deploy
	   startEventGUIName = Open
	   endEventGUIName = Close
	}
}

[rabidninjawombat]

Hi there,

to get the OMD partly fixed just reenable the ModuleAnimateGeneric, its removed in favor of KethaneDetectorAnimatorUnity in the original EPL.

adding this code it starts packed in the VAB and can be opend/closed in flight =)

@PART[OMD]
{
    MODULE
    {
       name = ModuleAnimateGeneric
       animationName = Deploy
       startEventGUIName = Open
       endEventGUIName = Close
    }
}

Huh.... i coulda swore i had already tried re-implementing ModuleAnimateGeneric and it didn't work, must have been an error or type o on my part originally , because everything works now when ive inserted it. Good deal, thanks for that!.

Also since the OMD works properly now, ive added the scansat module to it as well. Download updated on the first page.

Edited August 22, 2014 by rabidninjawombat

[Alvin853]

FYI: the D and the OWNLOAD in the first post are 2 seperate links, would be awesome if you could fix that so my mod manager doesn't get confused

[rabidninjawombat]

FYI: the D and the OWNLOAD in the first post are 2 seperate links, would be awesome if you could fix that so my mod manager doesn't get confused

Fixed.. musta happened when i removed the Pre-release download. they both went to the same place. Sorry bout that.

[Alvin853]

I think it got there when you introduced the Pre-release download, it's been like that for a couple days. My mod manager always had me choose if I wanted the D or the OWNLOAD

[Alvin853]

You made it worse, now there's a second download link without text, just a space. I think you have to edit in source mode, not in WYSIWYG mode

[rabidninjawombat]

You made it worse, now there's a second download link without text, just a space. I think you have to edit in source mode, not in WYSIWYG mode

lol that should do it (hopefully) i hate vBulletin sometimes. No other links show up in source. Silly mod managers

[caipi]

Hi Rabid ninja wombat,

I just installed your mod and I really like it. I'm a fan of MKS/OKS for some time and always used the EPL as well. Your mod fits perfectly into these two branches.

Two things I've noticed so far:

• The Orbital Rocket Workshop is missing an attachment node at the top
  
• The Miniature Blast Furnace has no nodes at all
  

Keep it up

[Alvin853]

And it seems, that the medium sized smelter, both the reconfigured EPL and the blast furnace output metal one order of magnitude too high (0.1 ore -> 0.85 metal, should be 0.085?)

[rabidninjawombat]

Hi Rabid ninja wombat,

I just installed your mod and I really like it. I'm a fan of MKS/OKS for some time and always used the EPL as well. Your mod fits perfectly into these two branches.

Two things I've noticed so far:

• The Orbital Rocket Workshop is missing an attachment node at the top
  
• The Miniature Blast Furnace has no nodes at all
  

Keep it up

The Orbital Workshop not having a node on top is on purpose as that space dock apparatus is very brittle (really just a personal choice, I don't believe there should be one there )

Fixed the Miniature smelter, somehow the attachRules node was missing. Fixed and uploaded.

And it seems, that the medium sized smelter, both the reconfigured EPL and the blast furnace output metal one order of magnitude too high (0.1 ore -> 0.85 metal, should be 0.085?)

You are absolutly correct.. yay typos ....either that, or the smelter somehow broke space time, and produces more metal then ore

Fixed that too,

Edited August 22, 2014 by rabidninjawombat

[caipi]

Ah Crap, I see my error: after using your mod, I deleted most of the EPL files (to clean out parts I don't use anyways), but the rocket shop was using the spacedock images and put it on top. Since I deleted it, it looked like there is no spacedock on top of the workshop. Never mind. My mistake. -.-' You're absolutely right, there shouldn't be a node. Thanks for the quick fix of the miniature smelter.

[Nori]

So was going to use some of your parts and noticed something i thought was strange. The blast furnaces all have really low prices. The Mk II is free for instance. Though maybe that is because I'm not suppose to launch them? Also the orbital workshop is 187k is that right?

[Jagzeplin]

+1 what Garibal-er i mean Nori said. How do I manually change the cost of the blast furnace to something a little more realistic?

edit- i think around 50-100k should be about right for a blast furnace eh?

Edited August 29, 2014 by Jagzeplin