Eleusis La Arwall

April 1, 2020

Hello everyone!

It has been a while since I worked on Keridian Dynamics - Vessel Assembly and @zer0Kerbal asked for permission to continue the mod. I'm actually very happy to see people still using my mod and even want to update it :3 I propably won't find time to work on the mod in the near future.

Hereby I gladly grant permission to continue / adopt / update / release to @zer0Kerbal. Also thank you for taking care!

A lot of the updates I posted here never saw the light of day and so I packed an experimental version of my current state and uploaded it to Github: link
(versions I used: KSP v1.6.1; CRP 1.0.0; EL 6.5.0; PM 0.0.016.4; MM 4.0.2; IFS 3.6.18.3)

I'd like to thank the community for the fun time I had working on this mod. Special thanks to all who gave feedback or helped me in other ways.

Have fun and stay healthy!

June 13, 2018

6 minutes ago, Nivee~ said:

So, in the first case, the tanks texture is totally white, and AO sorts out the shadows??

Yes.

June 13, 2018

I'd say a lot of people (including myself) like stockalike models/textures but you can't please everyone. Do what you like.

Think the SolarPanel look good but here are some suggestions:

Circuits/cables on the PCB
Holes for screws
(Random) text

SolarPanels are a bad example for this but one thing that helped me a lot when I got started with textureing is Ambient Occlusion bakeing (but I don't know if/how wings3d can do this). Here's a small example how a part looks with AO (right) and without AO (left). Top is pure white, bottom is white with some grey fillings. Since the renderer does most of the work for you, it's a quick and easy way to make a model appealing. Also you get a small coffee-break while the maschine is rendering

Spoiler

The more I did and learned, the less I 'needed' the AO but at the beginning it kept me from giving up on the textureing part.

June 12, 2018

@FreeThinker is always looking for models to use in KSPIE and as I saw, he already reached out to you

But why not practice with your cubesat mod? It seems pretty much ideal for practice. I'd recommend to start with something easy like a fuel-tank and do it from scratch to finish to find your work-flow. From what I can see you did no unwrapping or textureing or unity-stuff yet, right? I think it's vital to know the entire process from start to finish because somethings you can only learn by encountering them further down the road. Every step has its own pitfalls that make some parts harder to do than they appear at first (if not impossible at all). With every new part you start, it becomes easier because you get a better idea of what is important and what not. It's not like 'you do the model and the modelling part is done', it's more of a back and forth between modelling, unwrapping and texturing. For example, you texture an area and suddenly you have an idea how this would look better with a different shape on the model, so it's back to modelling, new unwrap and texture again.

Also I personally found it much easier to do models I came up with. Requests can be easy but can also be very tricky.

June 11, 2018

10 hours ago, strudo76 said:

I'd like to modify some experiments to allow the science to be collected (only by scientists), ...

I don't know a way to restrict the science collection but you can restrict who can run the experiment with usageReqMaskInternal and usageReqMaskExternal (more details).

11 hours ago, strudo76 said:

and disable the ability to reset the experiment.

If you want to do that for ALL experiments, you can make the science lab unable to restore experiments and set the rerunnable key on the experiments to false:

@PART[*]:HAS[@MODULE[ModuleScienceExperiment]]
{
	@MODULE[ModuleScienceExperiment]
	{
		%rerunnable = false
	}
}
@PART[Large_Crewed_Lab]
{
	@MODULE[ModuleScienceLab]
	{
		@canResetConnectedModules = False
		@canResetNearbyModules = False
	}
}

If you want to do that for individual experiments, the science lab will always be able to restore the experiment, even with:

@PART[*]:HAS[@MODULE[ModuleScienceExperiment]]
{
	@MODULE[ModuleScienceExperiment]
	{
		%resettable = false
		%rerunnable = false
		%resettableOnEVA = false
	}
}

Only if you run an experiment and hit the reset button, the lab can't restore the experiment. But you also get no results and can't run the experiment again. This only occures with resettable = false.

Here you can find all/most of the keys in ModuleScienceExperiment: LINK

Other than that you can take a look at the modules in here:

June 4, 2018

15 hours ago, DeltaDizzy said:

The configs can be difficult to write and tweaking the masses means redoing a lot of math and hope you did it right. B9 configs are much easier to write and understand and are much more versatile in case Windspren ever wants to change something.

Well the difficulty is rather subjective, for me it's easier to write IFS configs but only because I've been using it longer than B9PS. I think they are both easy to write and understand. My point is that B9PS and IFS are both suitable for the task at hand (as is Firespitter), just wasn't sure how to interpret your 'IFS is bad news' statement.

However I'm curious what you mean by ' tweaking the masses means redoing a lot of math '. In my experience IFS can do a lot of the math for you. It gives you multiple approaches to tweak the mass (add mass per setups, fixed fuel-to mass ratio for all or per setup, fixed factors). If you don't need all of that, use the add mass per setup key similar to B9PS. In fact I'm always using IFS when doing mass-configuration because it tells me the fuel to mass ratio right away.

June 3, 2018

On 6/2/2018 at 4:13 AM, DeltaDizzy said:

IFS is Bad news

Would you mind to elaborate? I don't see why IFS should not be suitable for the task at hand.

18 hours ago, Windspren said:

I don't really want to add a dependency when simply deleting a few files can replace its functions.

I share your philosophy to have as few dependencies as possible but there is a difference between dependending on another mod and offering support for another mod. In the case of PatchManager it would be a small change in the file-hierarchy. Instead of putting patches in individual folders inside GameData/ISRU Extended/<Patchfolder> you would have to put them all in GameData/ISRU Extended/PatchManager/ActiveMMPatches. Beside that you only need a small config for each patch to tell PM how to deal with the patch. If users don't have PM installed, all patches are still applied. Manually deleting patches still works, so your mod does not depend on PM.

By supporting other mods you can reach a larger group of people but it also means more work for you. So please don't get me wrong, I'm not here to persuade you to use PM. I personally consider PM a blessing because it made my life so so much easier but this is your decision

June 2, 2018

2 hours ago, Windspren said:

@Eleusis La Arwall Sorry to bother you, but could you explain a bit more on how to get MM to calculate conversion ratios? I think I understand the math, but I'm not exactly sure on how I would get MM to do all of it for me

Sure, no problem. The converter expects a Ratio in Units per second (U/s) but to prevent violations of mass-conservation you need to convert Units to mass. This can be done with the density of the resource. KSP densitys are given in tons per Unit (t/U). For example your Sabatier has Ratio = .2, multiply that by 0.001 and you get a mass-conversion rate of 0.0002 t/s. Now you would need to do that for the output and make sure the sum over all output-Ratios does not exceed the input-ratios. The easier way is to define Ratio with a value in t/s and have MM divide that by the resources density later.

Ratio = 0.0002

Now comes the important line that converts a t/s Ratio into a U/s Ratio KSP expects:

@Ratio /= #$@RESOURCE_DEFINITION[Water]/density$

I know you're already familiar with the basic stuff but I'll try to describe the line as detailed as I can: @ tells MM to modify the exisiting key Ratio. /= tells MM to divide the existing value of the key by what comes after the equal sign. # tells MM that a variable follows. $ tells MM that a variable starts and it requires a second $ to close the variable. Here it gets interesting, inside the $ you can navigate through the config like a file-browser. The second @ inside the variable tells MM to change root level (because the resource density is not defined in a PART config). You can target other PARTs, RESOURCE_DEFINITIONs, etc. and navigate through their hierarchy. So $@RESOURCE_DEFINITION[Water]/density$ says: look at the RESOURCE_DEFINITION of Water and obtain the value of density.

To sum it all up, the line means: Modify Ratio by dividing its current value by the density defined in the RESOURCE_DEFINITION of Water.

The full INPUT definition for Water would look like this:

INPUT_RESOURCE
{
	ResourceName = Water
	Ratio = 0.0002
	@Ratio /= #$@RESOURCE_DEFINITION[Water]/density$
	FlowMode = STAGE_PRIORITY_FLOW
}

June 1, 2018

20 minutes ago, DeltaDizzy said:
1) you cant have more than 1 HAS pass. Your example would be changed to
@PART[RadialDrill]:HAS[!MODULE[ModuleResourceHarvester],[#ResourceName[<ResourceName>]]]
also are you trying to see if the part doesnt have ModuleResourceHarvester? if so, that would be
HAS[MODULE[!ModuleResourceHarvester],blah]

I ran a few tests and my example with 2 HAS passes does what I need it to do.

I try to see if the part does not have any ModuleResourceHarvester that has ResourceName = <ResourceName>. So it's a HAS pass inside another HAS pass. The patch you suggested would look for ResourceName at PART-level but I need it to look inside the ModuleResourceHarvester.

Originally I used this in my KeridianDynamics mod to make stock-drills able to harvest MetalOre:

@PART[RadialDrill|MiniDrill]:HAS[!MODULE[ModuleResourceHarvester]:HAS[#ResourceName[MetalOre]]]:FOR[KD610]
//	@PART[RadialDrill|MiniDrill]:HAS[!MODULE[ModuleResourceHarvester],[#ResourceName[MetalOre]]]:FOR[KD610]
{
	+MODULE[ModuleResourceHarvester]:HAS[#ResourceName[Ore]]
	{
		@Efficiency /= 3
		@ResourceName = MetalOre
		@ConverterName = MetalOre Harvester
		@StartActionName = Start MetalOre Harvester
		@StopActionName = Stop MetalOre Harvester
		@ToggleActionName = Toggle MetalOre Harvester
		@INPUT_RESOURCE
		{
			@Ratio *= 2
		}
	}
}

To test the patch I add a new test.cfg in GameData containing:

@PART[RadialDrill|MiniDrill]:FIRST
{
	+MODULE[ModuleResourceHarvester]:HAS[#ResourceName[Ore]]
	{
		@Efficiency /= 3
		@ResourceName = MetalOre
		@ConverterName = MetalOreFIRST
		@StartActionName = Start MetalOreFIRST
		@StopActionName = Stop MetalOreFIRST
		@ToggleActionName = Toggle MetalOreFIRST
		@INPUT_RESOURCE
		{
			@Ratio *= 2
		}
	}
}

1. Run: The RadialDrill has one ModuleResourceHarvester with ConverterName = MetalOreFirst and no further ModuleResourceHarvester for MetalOre. The KD610 patch did not add a second Harvester for MetalOre.
Renamed test.cfg to test.txt
2. Run: The RadialDrill has one ModuleResourceHarvester with ConverterName = MetalOre and no further ModuleResourceHarvester for MetalOre. The KD610 patch did add a Harvester for MetalOre.
Switched to the comma notation you suggested (I've commented out that line in the KD610 patch)
3. Run: No MetalOre Harvester at all on the RadialDrill.

47 minutes ago, DeltaDizzy said:

2) I think its best if you try and avoid dependencies for your mods. Modularity can be accomplished just fine without Patch Manager, but if @Windspren wants to include it, by all means he can.

I fully agree to that, but PatchManager is no hard dependency. If you set up the configs correct, everything works as intended even with PM not installed. You just can't toggle patches from within the game. However I admit that it's easier to delete a folder in GameData than search for a specific patch if a user doesn't want to use PM.

June 1, 2018

14 minutes ago, Windspren said:

Oh wow, thanks for all that information! I haven't really looked into the finer parts of what MM can do, but I'll be sure to incorporate this into 0.2.

You're welcome! If you invest some time into the finer parts of MM, it will pay off soon enough. Specially with all the converters you'll be doing

9 minutes ago, Windspren said:

As for the license, I included it inside the README, but I can always make it a separate text file if that's preferred.

The README states:

ISRU Extended v0.1

To install, delete the modules you do not wish to add. Only keep one set of each module; do not use both the Simple and normal versions of each one, or issues will result.

Licensed as Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International

To my knowledge that is not sufficient and you need to include copy of the entire license, like this:

https://github.com/BobPalmer/CommunityResourcePack/blob/master/FOR_RELEASE/License_CC.txt

June 1, 2018

Neat idea! Congrats on your first mod. I have a few suggestions/ideas:

1.) Maybe this is intended but the ISRU converters do not generate heat. (Curves are missing.)

2.) Water miner doesn't work. (Closing brackets ' } ' for @PART{} are missing.)

3.) The Sabatier process generates vast amounts of mass. Per 1 kg input, about 78 kg output are created. If you don't want to do all the volume/density/mass calculations yourself, MM can do this for you (requires some advanced MM configs). Enter the ratio as tons/sec and divide it by the resources density to get units/sec:

Ratio = 0.001						// t/s; 0.001 = 1kg/s
@Ratio /= #$@RESOURCE_DEFINITION[<RescourceName>]/density$		// t/s / t/U = U/s

Replace <ResourceName> with whatever recource you want. More details are in the MM Handbook/Syntax.

4.) There are several mods that add new resource harvesters to the stock drills. To prevent double entrys, it's good to have the patch check for existing harvesters of the same resource:

@PART[RadialDrill]:HAS[!MODULE[ModuleResourceHarvester]:HAS[#ResourceName[<ResourceName>]]]

5.) For modularity I recommend PatchManager:

6 hours ago, Windspren said:

SolidFuel Refining | Alumina = SolidFuel (If I can find a way to allow SolidFuel to be moved)

6.) Not sure if that is what you want but you can refill empty SRBs by changeing the flow-properties 'temporary' with the FlowMode key in the converter:

		 OUTPUT_RESOURCE
		 {
			ResourceName = SolidFuel
			Ratio = 1
			DumpExcess = false
			FlowMode = STAGE_PRIORITY_FLOW
		 }

7.) I'm no expert on the license stuff but afaik you need to include a copy of the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International license into your download.

Hope you can put some of this to good use and Happy Modding!

May 29, 2018

On 5/27/2018 at 5:37 PM, linuxgurugamer said:

I have 5 icons in a mod I'm updating which are 24x24. I need to get them in 38x38 for the stock toolbar, is there anyone who would be interested in redoing them for me?

I volunteer if the quest is still open

May 25, 2018

That is a real bummer, thought I could finish that part today. At least I'm not alone with this problem. Hopefully it will be fixed. You're right, an all-in-one animation will not work for me

Thanks for your quick reply! Gonna look around for another way.

May 25, 2018

I'm working on a part that will have 3 different light-animations, red, green and blue. It has an actual light source and an emissive surface. After fiddleing a bit around I found an almost working solution. The only problem I have is that the green and blue lights/emissives don't work unless I turned the red light on and off before.
Also the part will become a stand-alone EVA-item, so the color needs to be changeable from EVA.

Spoiler

Attach the part, activate blue light -> nothing happens.
Deactivate blue and activate green -> nothing happens.
Deactivate green and activate red -> success! The actual light and the emissive work.
Deactivate red and activate green -> success! Now the green lights work as well.
Deactivate green and activate blue -> success! Now everything works as expected.

The log shows no errors or warnings. It feels like I'm just missing some tiny detail but I have no clue what it could be.

My animation setup in unity and module-config:

Spoiler

All animations use the same light and same object for emissives.

	MODULE
	{
		name = ModuleAnimateGeneric
		animationName = KDLaunchSiteDeployAnim
		...
		SNIP
		...
		layer = 1
	}
	MODULE
	{
		name = ModuleAnimateGeneric
		animationName = KDLaunchSiteLightBlueAnim
		actionAvailable = true
		actionGUIName = Lights Anim Blue
//		defaultActionGroup = Light
		startEventGUIName = Lights Blue start
		endEventGUIName = Lights Blue end
		eventAvailableEditor = true
		eventAvailableEVA = true
		eventAvailableFlight = true
		evaDistance = 5
		layer = 2
	}
	MODULE
	{
		name = ModuleAnimateGeneric
		animationName = KDLaunchSiteLightGreenAnim
		actionAvailable = true
		actionGUIName = Lights Anim Green
//		defaultActionGroup = Light
		startEventGUIName = Lights Green start
		endEventGUIName = Lights Green end
		eventAvailableEditor = true
		eventAvailableEVA = true
		eventAvailableFlight = true
		evaDistance = 5
		layer = 3
	}
	MODULE
	{
		name = ModuleAnimateGeneric
		animationName = KDLaunchSiteLightRedAnim
		actionAvailable = true
		actionGUIName = Lights Anim Red
//		defaultActionGroup = Light
		startEventGUIName = Lights Red start
		endEventGUIName = Lights Red end
		eventAvailableEditor = true
		eventAvailableEVA = true
		eventAvailableFlight = true
		evaDistance = 5
		layer = 4
	}

May 24, 2018

Since the update takes more and more time I wrote a little bit about the current state. Configs are pretty much done by now, just the models and textures need more work.

The Planetary Assembly Management (aka SurveyStation) has a new model with its own texture and this time with proper IVA(unfinished):

Spoiler

Management demanded an increased clearance for their high heads and so the part became a bit taller than the old one. The smaller version of PAM is no longer available.
To give PAM a real purpose, it will be the only part that can act as SurveyStation. I will add a config to re-enable the SurveStation on the MobileVAB via PM.

Early state of the new, smaller recylcer "Krushenator":

Spoiler

The old one is a really bulky but the new one should still be able to eat 5 m parts. So this is the smallest variant I could come up with (3.75 m bottom, 6 m diameter top). The texture leaves me enough space to do a smaller one. It will be one of these two options (opinions are welcome):

2.5 m part that can eat 3.75 m parts
1.25 m part that can eat 2.5 m parts

The overhauled 3DPrinter:

Spoiler

Not much to say besides the new model. Since the FabricationContainer is also no longer available I might do a 1.25 m variant of it.

V.3.0 of the CargoTanks with a total of 14 different resource setups, including multi-resource setups like MetalOre, Metal and RocketParts in one tank:

Spoiler

Now you can choose which switcher you want to use (IFS, FS, B9PS), no more auto-detection with priority. I still highly recommend the use of IFS (enabled by default) because it's build to work with the new modular fuel-setups, thanks to @FreeThinker. The other two have some limitations. As usual the tanks have lights to indicate their content even in the dark of night and also an IVA. Station Tanks are no longer available.

By default the converter-parts have all converter-modules added. Now you can disable the ones you don't need/want/like:

Spoiler

Would anyone like to have a MetallicOre --> Metal converter available? Suggestions are welcome.

As mentioned before the update includes some major changes and it's unlikely that you can upgrade from older versions To give a little heads-up of the critical aspects, here is a list of removed parts and renamed parts:
Removed (no replacement):

KD-PAMSmall
KD-OrbitalHangar
KD-FC (FabricationContainer)
KD-StationTanks (all)

Renamed or replaced:

KD-3D-Printer --> KD-3DPrinter (this bothered me for ages)
KD-TXXXXFS --> KD-CTXXXXFS
KD-OrbitalPad --> KD-Keronica / KD-Launchpad
KD-Recycler --> KD-Krushenator
KD-SledgeHammer --> KD-KDA

Other parts keep their name but that doesn't mean they are 100% safe. All models, textures, animations, etc (except KD-Pad and KD-Keronica) are beeing re-made from scratch. For example PAM is not on the list but the attach nodes and collider change.

You may ask "why all this effort?" - Some parts like the Furnace are very old and I've learned a ton of new stuff since I made them. New parts will feature:

All animations made in unity, no imports with hundreds of unused keys.
Proper use of specular maps instead of separate materials for glas, foil, etc.
Texel-density of 170 pixel per meter for all parts instead of a random texel-density. (I've tried to go for 200 but I couldn't fit stuff on 1024² textures anymore.)
Reduced tris-count.

A note to other modders making configs with/for KD:
I no longer use module-indices to asure the correct loading order with MM but instead use different :FOR[KDXXX] definitions. This means :BEFORE[KeridianDynamics] will no longer work correctly. To patch before KeridianDynamics use :BEFORE[KD000]. You can also apply patches between other KD-patches. Here's a list of all load-order IDs currently in use:

'KDXXX' with XXX:
000-009		Reserved
- 007		Primary Fuel Switcher choice
- 008		Add displayNames for multi-resource setups
- 009		Add Volume to Resource if no Volume-key is set (currently deactivated)
010-099		Variables (Reserved)
- 010		- Primary (KDV1,KDV5,mass)
- 011		- Secondary (Special Volumes)
- 012		- Tertiary (Cost)
100-289		FuelTanks
290-299		FuelTanks 'Suffix' Stuff
300-389		ResourceConverters
390-399		ResourceConverters Anim/CoreHeat
600-699		Stock-Patches
- 610		- Drill MetalOre
700-799		Mod-Support (Add Modules)
- 710		- ExtraplanetaryLaunchpads
- 715		- EL Recycle Recipe
- 720		- KIS/KAS
- 730		- OSE Workshop
- 735		- OSE RocketParts Recipe (2 patches, 1 running :AFTER[Workshop])
- 740		- JSI Advanced Transparent Pods
- 780		- Connected Living Space
800-899		Mod-Support (No Modules)
- 810		- Community Tech Tree
- 890		- KD Old Prices
FINAL		Cleaner

For a release-date I can only say "soon ...^TM".

May 24, 2018

I don't know what's going on there but I'm currently working on a part with a hollow skirt as well. The part is upside down, so the skirt is on top and I don't observe the problem you described/visualized. Here's my unity setup, maybe it can be of use:

On 5/20/2018 at 4:57 AM, mcdouble said:

If I remove the skirt colliders it no longer happens, so I assume it has something to do with them, almost as if there are invisible mirror images of them appearing at the top.

If your assumtion is correct and there is some weird mirroring stuff going on, maybe it helps to change the center of origin in the model.

May 17, 2018

2 hours ago, LatiMacciato said:

oh and BTW, are the pre-parts part of the new upcoming release or will there something change like in the beta parts of KIS (or was it KAS?) .. anyways, I hope there will not be much more part change tho.

Unfortunatly the parts will change a lot in the next update. It's too much to write all of that down but I hope this will bring everything in line and I don't have to change anything vital after that.

I don't know yet how well I can support the older version in the new update. For example the texture from MobileVAB is used on the OritalHangar, PAM, PAM(small), FabricationContainer and the StationTanks. I'm gonna update this texture and the old models will look horrible.

BTW I plan on dropping the OrbitalHangar in the next release because I mostly forget that it's even there.

2 hours ago, LatiMacciato said:

But please keep in mind adding another key might just add a second or 3rd key, It doesn't edit it. Please correct me if I'm wrong! This way there might be added multiple keys with the same name like having 2 keys like "Metal = 1" or similar (might bring up unseen consequences, or the Kraken)

That is exactly what happens with current stabel version of KD and EL and why I switched to %

Now your patch does exactly the same if SC is installed or not.

So far SC support was only necessary because of the differeing density of Metal but I found a way avoid that once and for all with MM. Here is the important part of the ResourceConverter config as an example :

		INPUT_RESOURCE
		{
			ResourceName = Ore			//	Density(Ore) = 0.01
			Ratio = 0.02 // t/s
			@Ratio *= #$@RESOURCE_DEFINITION[Ore]/volume$
			@Ratio /= #$@RESOURCE_DEFINITION[Ore]/density$
			FlowMode = STAGE_PRIORITY_FLOW
  		}
		OUTPUT_RESOURCE
		{
			ResourceName = Metal			//	Density(Metal) = 0.039
			Ratio = 0.002 // t/s, 10%
			@Ratio *= #$@RESOURCE_DEFINITION[Metal]/volume$
			@Ratio /= #$@RESOURCE_DEFINITION[Metal]/density$
			DumpExcess = false
			FlowMode = STAGE_PRIORITY_FLOW
		}

KSP expects the Ratio in InGameUnits / sec. For the conversion to make sense, the ratio must be calculated with masses. Previously I made the calculations manually but now I just enter a tons / sec value and have MM multiply it by the Resources Volume and divide it by the Density to obtain IGU / sec. This way the mass-extraction-ratio is kept independant from resource-density. 20 kg Ore will always yield 2 kg Metal.

May 17, 2018

10 hours ago, LatiMacciato said:

@Eleusis La Arwall I just looked through the pre-release on github.

Question: is it save to edit the savefile to switch the depreciated orbital pad with the new lightweight LaunchPad or is it more save to keep the part (also keeping the part config for this one from the latest stable version) and exchange the part manually in situ?

note: in my savegame I just use the orbital pad for building things because I love the design and the cool flow it brings rather than the EL-stock blue girder one!

Can't really tell if that is save because I almost never do save-file edits. I start a new save with every new KSP version If you're not short on RAM it's probably better to keep the old OrbitalPad files.

Glad to hear you like the design An overhauled version of the OrbitalPad-model is now used for the Keronica probe core.

10 hours ago, LatiMacciato said:
According to the current EL 6.0 Recipes.cfg EL 6.0 originally recycles stuff only with ScrapMetal = 9 and no Metal output.
EL_RecycleRecipe {
	name = RocketParts
	Resources {
		ScrapMetal = 9
		loss = 1
	}
}
Question 2: Is KD adding 1 unit Metal in favour of -1 unit ScrapMetal?

Yes, but with the next version this change can be turned off via PM.

10 hours ago, LatiMacciato said:
In mind KD defaults a new EL recipe having 1 Metal, 8 ScrapMetal & 1 loss and the current SC Recipes.cfg defaults the recycle output to Metal = 8 & loss = 2 I suggest this fix for the KeridianDynamics-EL-Recipes.cfg:
Hide contents
@EL_RecycleRecipe[RocketParts]:NEEDS[!SimpleConstruction]:AFTER[Launchpad]{
	@Resources
	{
		Metal = 1		// add new key "Metal" and set value to 1
		@ScrapMetal = 8		// set existing key "ScrapMetal" 8 (EL default: 9)
		@loss = 1		// set loss to 1 unit in any case
	}
}
EL_RecycleRecipe:NEEDS[SimpleConstruction]:AFTER[SimpleConstruction]{
	// name = RocketParts		// unecessary because already defined!
	@Resources
	{
		@Metal = 1		// set existing key "Metal" units to from 8 to 1
		ScrapMetal = 8		// add new key "ScrapMetal" and set value to 8
		@loss = 1		// key is not "Loss" (with a small L) in SC & EL
	}
}
NOTE: this cfg is for the KD v0.8.9-PRE and SimpleContruction is NOT updated to EL 6.0 yet!

Feedback is always welcome!

I'm not planning dedicated support for SC in the upcoming version. I'll keep SC in mind and KD should still work with SC but no special configs anymore.
The config I posted above should do the same as the one you suggested. I can do an optional patch to run the recipe change at :FINAL but it should work already.

10 hours ago, LatiMacciato said:

EDIT 2: Unsure if that is already noted but the 3 new LaunchPads (KD-LaunchPad, KD-LaunchPadSide, KD-LaunchPadTop) do not have different weights if form size is switched.

I'm still not sure if I want the mass to change. It would be logical but also annoying to bring extra weight with no benefit. There would be no reason to ever use a 2.5 m Launchpad.

A note on current development:
1.4.3 is out for a while now and there is still no official update for KD - unacceptable! - There is actually good reason for that. I'm doing a major part overhaule for the entire mod and it takes much more time to do than I had anticipated. At first I just wanted to do a little tweaking here and there but one thing lead to another and now I'm redoing most models and textures from scratch. Here's a preview of the new ChemicalReactor and Tanks (now with 0.625 m sized variants starting at 32 L volume):

Spoiler

May 11, 2018

1 hour ago, DStaal said:

No, I mean the ones that fill up the loading screen, are written to the log, and prevent MM from creating it's caches.

Strange, that should be fixed already. Can you provide the KSP.log file?

Did you delete IFS before upgrading to the latest version?

May 11, 2018

1 hour ago, Gordon Dry said:

I toggled to the CDT12Setups from the default CDT4Setups

Edit:

~~btw the shipped GameData\InterstellarFuelSwitch\PatchManager\PluginData\CDT7Setups.cfg is a zero-byte file.~~
nevermind, I still don't get the way PatchManager works to 100%

Right, I forgot to remove CDT4Setups and CDT12Setups, they are no longer used and will probably break stuff when activated. Will fix that for next update.

May 6, 2018

22 hours ago, schlosrat said:

FYI this mod is currently breaking the EL recycler when used in 1.4.3 with EL 6. Not sure about other configurations, but including this (even if no parts are used) will cause the recycler to produce about 1 order of magnitude less material making it pretty much useless. With this mod I recycle a 1t part and get 2.56 u of metal (where the recipe is configured for metal rather than scrapmetal). Without this mod I get 23.08 u metal.

Bummer, 'cause I really like these parts for storing things.

Thank you very much for the report. The MM patch in KD expects the old recipe from before Dec 2016. My bad, haven't noticed the recipe change in EL for over a year :blush:

I was not able to reproduce your problem but since the patch currently writes some non-sense in the recipe, the result is not always the same
Are you using SimpleConstruction?

Easiest fix is to delete KeridianDynamics-EL-Recipes.cfg in GameData/KeridianDynamics. This way ELs default recipe is kept unchanged by KD.

Better fix is to replace the content of said file with the following:

@EL_RecycleRecipe[RocketParts]:AFTER[Launchpad]{
	@Resources
	{
		%Metal = 1
		%ScrapMetal = 8
		%loss = 1
	}
}

For the next version I will make the recipe-change toggleable (with PatchManager).

May 5, 2018

As I suspected, this is my bad. ~~A certain part of the MM-patches require the Modules to have an exact position in the Part-config and I forgot to put the right indices on the Modules.~~

A fix should be up soon. Thanks for reporting the issue!

Edit: The Module order is no longer a problem. Found a better way to convince MM to do what I want.

May 5, 2018

1 hour ago, Jammer-TD said:

I had been using 1.4.3 with no issues when I add the 3 version this is what happens

~snip~

previous version =2.13.3

the errors go away with the earlier version I have MM3.0.6, CRP 10,tweakscale 2.3.12 but I don't use patch manager.

any ideas?

thanks love this mod

Jammer

I have a suspicion what's going on there. Could you provide the KSP.log file?

May 4, 2018

Are you tired of clicking through dozens of setups to find the one you need? Then you will love the new modularization feature, because now you can disable setups you don't need. FreeThinker and I have put a lot of work into it and I'm gonna explain how to use it so that you all can get the most out of it. If you have questions or need help, feel free to ask!

How to use modularized tank setups:
At the KSC open PatchManager and you will see a whole lot new 'mods' but they are not all individual mods. Each IFS tank-series has its own category in PM so you can adjust them individually. For example select IFSCC (CargoContainer) and you'll see all available resources. By default all resources are available but you can disable them one by one.

Spoiler

Say you have no use for Caesium and Decaborane and can now disable them

Spoiler

After hitting 'Apply All', KSP needs a restart and that's it!

You can disable and re-enable setups at any point. If you find bugs please let us know here or on GitHub issue tracker.

Note: Always use IFS 3.0.0 or above with the modularization or unexpected things may happen.

April 30, 2018

3 hours ago, juanml82 said:

The KD Extension Part isn't working as an EL disposable part. There are this two lines in the .cfg file

// Optional MM-Modules
// MODULE,1 {name = ELDisposablePad} KeridianDynamics-EL.cfg

But commenting out the second line doesn't show anything in the module manager window at the KSC screen

That is odd, I just checked and it works for me (on KSP 1.4.2 and EL 6.0.0, haven't installed 1.4.3 yet).

The second line is just for documentation, it tells you where to find the MM-patch that applies the module (KeridianDynamics-EL.cfg). This applies the module:

@PART[KD-ExtensionPad]:NEEDS[Launchpad|SimpleConstruction]
{
	MODULE,1
	{
		name = ELDisposablePad
		SpawnTransform = LaunchPos
		PadName = ExtensionPad
	}
}

If this really doesn't work for you, try to replace the second line you mentioned in the PART config with this:

	MODULE
	{
		name = ELDisposablePad
		SpawnTransform = LaunchPos
		PadName = ExtensionPad
	}

Profiles

Forums

Developer Articles

KSP2 Release Notes

Bug Reports

Posts posted by Eleusis La Arwall