Eleusis La Arwall

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!

Yes.

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 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.

@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.

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). 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:

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.

Would you mind to elaborate? I don't see why IFS should not be suitable for the task at hand. 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

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 }

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. 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.

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 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

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.) 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!

I volunteer if the quest is still open

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.

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. 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: 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 }

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): 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": 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: 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: 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: 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".

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: 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.

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. 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.

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. Yes, but with the next version this change can be turned off via PM. 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. 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):

Strange, that should be fixed already. Can you provide the KSP.log file? Did you delete IFS before upgrading to the latest version?

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.

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 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).

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.

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

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. Say you have no use for Caesium and Decaborane and can now disable them 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.

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 }