Jump to content

[1.12.X] Kerbal Planetary Base Systems v1.6.15 [28. April 2022]

Nils277

By Nils277
in KSP1 Mod Releases

 Share

Recommended Posts

LatiMacciato

LatiMacciato

Posted
Posted (edited)
15 minutes ago, Nils277 said:

What do you want to use the water for?

I know the question went to @Cannon but I know a billion uses for water! Fuel, plants .. currently I convert water to liquid hydrogen (I guess it was NFE that bring the parts and functionality) to use it as fuel for my crafts, at least one mainstream fuel alternative. I use snacks as main food resource :D

Edited by LatiMacciato
Link to comment
Share on other sites
Rafael acevedo

Rafael acevedo

Posted
Posted (edited)
On 11/7/2018 at 5:49 PM, Vas said:

Heya, I noticed that your modules don't quite match up in length with each other which makes building a base thats connected together in cube form and such impossible. I used docking ports to make the base fully connected even in a way to try and fill some gaps but it doesn't always work.  Is there anything you can do about this? I'll show some examples below.

unknown.png

The above shows that your 4 way stops won't meet up with the habitats because the central node is a different size and offsets them a little.

unknown.png

The above, I managed to actually fix with docking ports, kinda... Buuuttttt...

unknown.png

You can see here that the docking ports were a perfect fit, but very slightly off set.

unknown.png

Now this is just something I don't understand at all... Its literally the same exact structure. I placed it, it worked, I deleted it, and placed it again in the same spot, and it changed to something else. I tried 10 more times, same issue, I tried placing elsewhere, same flat ass thing. Nothing I did could get the original back and I couldn't figure out why.

 

I wish KSP used a different system, not some tree ship method that has one parent per item instead of forcing me to use docking ports or struts to connect a base together in a specific shape.

Nils

Thanks for your hard work.. I know you been working on this.

Vas

Here is how I have been able to build a square shaped base 

hMffsDN.png

Corner part created with two ports at 90 degrees and the last at 135 from both 90 degree ports

 

DUCHYUk.png

mazwhUV.png

Completed corner with one docking port and 2 kpbs expandable tunnels 

 

g08b49l.png

Completed Base

 

zNTA3dt.png

OBTW the excellent lander at left corner was my interpretation of Space 1999 eagle transporter built with Nils Excellent Feline utility rover parts

 

sj0yuSG.png

 

Completed base close up, used Konstruction docking ports to join t section toghether

Edited by Rafael acevedo
Link to comment
Share on other sites
Vas

Vas

Posted
Posted
On 11/10/2018 at 3:48 AM, Nils277 said:

The different sizes were a mistake when designing the parts. I'm currently working on an overhaul of the parts that make them have sizes that allow for better structures (aside from the tree structure thing of course) This will however take a looong time till i have that done...currently i'm not even able to update for 1.5.1. The last image is the exact same structure but highly rotated. The windows on the right image are not showing to the top instead of the left.

What about the strange module there at the end that is the same exact module but each time I place it, it has a 90% chance of not matching the port at all and being squashed into a flatter longer version of its self?

Link to comment
Share on other sites
Tonka Crash

Tonka Crash

Posted
Posted
4 minutes ago, Vas said:

What about the strange module there at the end that is the same exact module but each time I place it, it has a 90% chance of not matching the port at all and being squashed into a flatter longer version of its self?

It's not changing shape. You just need to rotate the part. In one picture you're attached to the back the other your attached to the bottom.

Link to comment
Share on other sites
Vas

Vas

Posted
Posted
Just now, Tonka Crash said:

It's not changing shape. You just need to rotate the part. In one picture you're attached to the back the other your attached to the bottom.

I rotated the hell out of it.  Look at he two, you can see it being squashed in the second image.  There's no way rotating it will unsquash it.

Link to comment
Share on other sites
Tonka Crash

Tonka Crash

Posted
Posted
1 minute ago, Vas said:

I rotated the hell out of it.  Look at he two, you can see it being squashed in the second image.  There's no way rotating it will unsquash it.

I am looking at your photos and in the misaligned one I see that the windows (front) are pointed up and you have it attached at the bottom node of the part with the access hatch hidden from view. Looking at the photo, flip it counterclockwise 90 so the windows are pointed to the left and roll it 180 degrees, so the door is on the visible side and it lines up. I've used that part many, many times and it doesn't change shape.

Link to comment
Share on other sites
LatiMacciato

LatiMacciato

Posted
Posted

latest MM release brings up some errors:

Spoiler 

// [ERR 14:58:15.400] [ModuleManager] Cannot parse node name as tag list: encountered opening bracket in primary trailer
// on: PlanetaryBaseInc/ModSupport/Parts/LifeSupport/Container_CO2_big/@PART[KKAOSS_LS_container_co2_big]FOR[PlanetarySurfaceStructures]:NEEDS[TacLifeSupport]

// [ERR 14:58:15.400] [ModuleManager] Cannot parse node name as tag list: encountered opening bracket in primary trailer
// on: PlanetaryBaseInc/ModSupport/Parts/LifeSupport/Container_CO2_big/@PART[KKAOSS_LS_container_co2_big]FOR[PlanetarySurfaceStructures]:NEEDS[IoncrossCrewSupport]

// [ERR 14:58:15.400] [ModuleManager] Cannot parse node name as tag list: encountered opening bracket in primary trailer
// on: PlanetaryBaseInc/ModSupport/Parts/LifeSupport/Container_CO2_big/@PART[KKAOSS_LS_container_co2_big]FOR[PlanetarySurfaceStructures]:NEEDS[LifeSupport]

 

I think this can be solved by adding a ":" (double-dot/colon) before FOR (e.g. making it :FOR) in PlanetaryBaseInc/ModSupport/Parts/LifeSupport/Container_CO2_big

fixed config

Spoiler 

PART:NEEDS[TacLifeSupport|IoncrossCrewSupport|LifeSupport|Kerbalism]
{
    // Kerbal Space Program - Part Config
    // A container to store a huge amount of CO2

    MODEL
    {
        model = PlanetaryBaseInc/ModSupport/Parts/LifeSupport/Container_CO2_big
    }

    // --- general parameters ---
    name = KKAOSS_LS_container_co2_big
    module = Part
    author = Nils277

    // --- asset parameters ---
    scale = 1
    rescaleFactor = 1
    CoMOffset = -0.45, -0.45, 0.0

    // --- node definitions ---
    node_stack_top = 0, 0, 0, 1, 0, 0, 1

    // --- editor parameters ---
    TechRequired = advExploration
    entryCost = 9000
    cost = 800
    category = none
    subcategory = 0
    title = #LOC_KPBS.co2containerbig.title
    manufacturer = #LOC_KPBS.agency
    description = #LOC_KPBS.co2containerbig.description


    // --- attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision ---
    attachRules = 1,0,1,0,0
    tags = #LOC_KPBS.co2containerbig.tags

    // --- standard part parameters ---
    mass = 0.16
    dragModelType = default
    maximum_drag = 0.2
    minimum_drag = 0.2
    angularDrag = 2
    crashTolerance = 15
    maxTemp = 2000 // = 3000
    
}

//------------------COMMUNITY TECHTREE-------------------------
@PART[KKAOSS_LS_container_co2_big]:FOR[PlanetarySurfaceStructures]:NEEDS[CommunityTechTree]
{
    @TechRequired = logistics
}

//------------------TAC LIFE SUPPORT CONFIG--------------------
@PART[KKAOSS_LS_container_co2_big]:FOR[PlanetarySurfaceStructures]:NEEDS[TacLifeSupport]
{
    @cost = 2000
    RESOURCE
    {
        name = CarbonDioxide
        amount = 0
        maxAmount = 127883.136852896
    }
}
//------------------IONCROSS CREW SUPPORT CONFIG--------------------
@PART[KKAOSS_LS_container_co2_big]:FOR[PlanetarySurfaceStructures]:NEEDS[IoncrossCrewSupport]
{
    @cost = 2200
    RESOURCE
    {
        name = CarbonDioxide
        amount = 0
        maxAmount = 64000
    }
}
//------------------ECLSS CONFIG--------------------
@PART[KKAOSS_LS_container_co2_big]:FOR[PlanetarySurfaceStructures]:NEEDS[LifeSupport]
{
    @cost = 4000
    RESOURCE
    {
        name = CarbonDioxide
        amount = 0
        maxAmount = 2600
    }
}

 

 

Link to comment
Share on other sites
Starwaster

Starwaster

Posted
Posted
38 minutes ago, LatiMacciato said:

latest MM release brings up some errors:

  Hide contents 


// [ERR 14:58:15.400] [ModuleManager] Cannot parse node name as tag list: encountered opening bracket in primary trailer
// on: PlanetaryBaseInc/ModSupport/Parts/LifeSupport/Container_CO2_big/@PART[KKAOSS_LS_container_co2_big]FOR[PlanetarySurfaceStructures]:NEEDS[TacLifeSupport]

// [ERR 14:58:15.400] [ModuleManager] Cannot parse node name as tag list: encountered opening bracket in primary trailer
// on: PlanetaryBaseInc/ModSupport/Parts/LifeSupport/Container_CO2_big/@PART[KKAOSS_LS_container_co2_big]FOR[PlanetarySurfaceStructures]:NEEDS[IoncrossCrewSupport]

// [ERR 14:58:15.400] [ModuleManager] Cannot parse node name as tag list: encountered opening bracket in primary trailer
// on: PlanetaryBaseInc/ModSupport/Parts/LifeSupport/Container_CO2_big/@PART[KKAOSS_LS_container_co2_big]FOR[PlanetarySurfaceStructures]:NEEDS[LifeSupport]

 

I think this can be solved by adding a ":" (double-dot/colon) before FOR (e.g. making it :FOR) in PlanetaryBaseInc/ModSupport/Parts/LifeSupport/Container_CO2_big

fixed config

  Hide contents 


PART:NEEDS[TacLifeSupport|IoncrossCrewSupport|LifeSupport|Kerbalism]
{
    // Kerbal Space Program - Part Config
    // A container to store a huge amount of CO2

    MODEL
    {
        model = PlanetaryBaseInc/ModSupport/Parts/LifeSupport/Container_CO2_big
    }

    // --- general parameters ---
    name = KKAOSS_LS_container_co2_big
    module = Part
    author = Nils277

    // --- asset parameters ---
    scale = 1
    rescaleFactor = 1
    CoMOffset = -0.45, -0.45, 0.0

    // --- node definitions ---
    node_stack_top = 0, 0, 0, 1, 0, 0, 1

    // --- editor parameters ---
    TechRequired = advExploration
    entryCost = 9000
    cost = 800
    category = none
    subcategory = 0
    title = #LOC_KPBS.co2containerbig.title
    manufacturer = #LOC_KPBS.agency
    description = #LOC_KPBS.co2containerbig.description


    // --- attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision ---
    attachRules = 1,0,1,0,0
    tags = #LOC_KPBS.co2containerbig.tags

    // --- standard part parameters ---
    mass = 0.16
    dragModelType = default
    maximum_drag = 0.2
    minimum_drag = 0.2
    angularDrag = 2
    crashTolerance = 15
    maxTemp = 2000 // = 3000
    
}

//------------------COMMUNITY TECHTREE-------------------------
@PART[KKAOSS_LS_container_co2_big]:FOR[PlanetarySurfaceStructures]:NEEDS[CommunityTechTree]
{
    @TechRequired = logistics
}

//------------------TAC LIFE SUPPORT CONFIG--------------------
@PART[KKAOSS_LS_container_co2_big]:FOR[PlanetarySurfaceStructures]:NEEDS[TacLifeSupport]
{
    @cost = 2000
    RESOURCE
    {
        name = CarbonDioxide
        amount = 0
        maxAmount = 127883.136852896
    }
}
//------------------IONCROSS CREW SUPPORT CONFIG--------------------
@PART[KKAOSS_LS_container_co2_big]:FOR[PlanetarySurfaceStructures]:NEEDS[IoncrossCrewSupport]
{
    @cost = 2200
    RESOURCE
    {
        name = CarbonDioxide
        amount = 0
        maxAmount = 64000
    }
}
//------------------ECLSS CONFIG--------------------
@PART[KKAOSS_LS_container_co2_big]:FOR[PlanetarySurfaceStructures]:NEEDS[LifeSupport]
{
    @cost = 4000
    RESOURCE
    {
        name = CarbonDioxide
        amount = 0
        maxAmount = 2600
    }
}

 

 

That's always been the syntax. Sounds like either MM is enforcing things it let slide before, or more likely that it is throwing errors on things that were failing silently before.

Link to comment
Share on other sites
LatiMacciato

LatiMacciato

Posted
Posted
1 minute ago, Starwaster said:

That's always been the syntax. Sounds like either MM is enforcing things it let slide before, or more likely that it is throwing errors on things that were failing silently before. 

strange, I noticed the wiki it should be :FOR[*] :NEEDS[*] and not FOR:[*] NEEDS:[*]. Maybe MM is beeing more explicit now.

Link to comment
Share on other sites
Starwaster

Starwaster

Posted
Posted
On 11/12/2018 at 10:09 AM, Vas said:

I rotated the hell out of it.  Look at he two, you can see it being squashed in the second image.  There's no way rotating it will unsquash it.

Please PLEASE tell me that you are not talking about this:

unknown.png

Can you really not see what is happening there? No, it is NOT squashed. Yes, it IS rotated. The part that is the front in the first image is now on the top due to rotation. The port and starboard sides (with hatch and flag) have changed sides for the same reason.

4 minutes ago, LatiMacciato said:

FOR:[*] NEEDS:[*]

No, that should never have worked, if it ever did.

Link to comment
Share on other sites
DStaal

DStaal

Posted
Posted
10 minutes ago, LatiMacciato said:

strange, I noticed the wiki it should be :FOR[*] :NEEDS[*] and not FOR:[*] NEEDS:[*]. Maybe MM is beeing more explicit now.

Yes, it's explicitly telling you that :FOR[*]:NEEDS[*] contradicts itself.  (Both specify - among other things - which order the patch should be applied in.  If it has both, you're telling MM to apply the patch in two different places in the loading cycle.  Personally I think this is a weakness in the MM syntax, as both of those have other meanings as well, so they've overloaded the syntax, but that's a separate discussion.)

Link to comment
Share on other sites
Starwaster

Starwaster

Posted
Posted (edited)
31 minutes ago, DStaal said:

Yes, it's explicitly telling you that :FOR[*]:NEEDS[*] contradicts itself.  (Both specify - among other things - which order the patch should be applied in.  If it has both, you're telling MM to apply the patch in two different places in the loading cycle.  Personally I think this is a weakness in the MM syntax, as both of those have other meanings as well, so they've overloaded the syntax, but that's a separate discussion.)

No. NEEDS is only a conditional and does not specify a phase in which to apply the patch. FOR is not a conditional at all and it specifies a phase in which to apply the patch. Additionally, FOR will satisfy any NEEDS by the same name. 

So, it doesn't contradict itself but if the NEEDS and FOR are the same then the condition will be satisfied. (i.e., :NEEDS[DeadlyReentry]:FOR[DeadlyReentry] would cause the patch to be applied even if DeadlyReentry is not installed, which is also why FOR[DeadlyReentry] should never be used by any mod other than DeadlyReentry - to use an example) 

Edited by Starwaster
Link to comment
Share on other sites
LatiMacciato

LatiMacciato

Posted
Posted (edited)
20 minutes ago, Starwaster said:

NEEDS[DeadlyReentry]:FOR[DeadlyReentry] would cause the patch to be applied even if DeadlyReentry is not installed

quote from Module Manager Handbook:

Quote

:NEEDS[<modname>] Patch is applied only if given mod is installed.

quote from Module Manager Syntax:

Quote

A FOR[Blah] defined would allow NEEDS[Blah]

my suggestions :NEEDS might just be enough to fill the needing dependency

Example of my recycler config for KBPS:

Spoiler 

@PART[KKAOSS_ISRU_g]:FOR[Snacks]:NEEDS[Snacks&PlanetaryBaseInc]
{
	MODULE
	{
		name = SoilRecycler
		ConverterName = Soil Recycler
		StartActionName = Start Soil Recycler
		StopActionName = Stop Soil Recycler
		AutoShutdown = false
		GeneratesHeat = false
		UseSpecialistBonus = true
		UseSpecializationBonus = true
		SpecialistEfficiencyFactor = 0.1
		ExperienceEffect = ScienceSkill
		EfficiencyBonus = 1.0
		RecyclerCapacity = 4
	 
		INPUT_RESOURCE
		{
			ResourceName = Soil
			Ratio = 0.000034723
			FlowMode = ALL_VESSEL
  		}

		INPUT_RESOURCE
		{
			ResourceName = ElectricCharge
			Ratio = 12
		}

		OUTPUT_RESOURCE
		{
			ResourceName = Snacks
			Ratio = 0.000034723
			DumpExcess = false
			FlowMode = ALL_VESSEL
		}
	}
}

@PART[KKAOSS_Greenhouse_g]:FOR[Snacks]:NEEDS[Snacks&PlanetaryBaseInc]
{
	MODULE
	{
		name = SoilRecycler
		ConverterName = Soil Recycler
		StartActionName = Start Soil Recycler
		StopActionName = Stop Soil Recycler
		AutoShutdown = false
		GeneratesHeat = false
		UseSpecialistBonus = true
		UseSpecializationBonus = true
		SpecialistEfficiencyFactor = 0.1
		ExperienceEffect = ScienceSkill
		EfficiencyBonus = 1.0
		RecyclerCapacity = 2
	 
		INPUT_RESOURCE
		{
			ResourceName = Soil
			Ratio = 0.0016
			FlowMode = ALL_VESSEL
  		}

		INPUT_RESOURCE
		{
			ResourceName = ElectricCharge
			Ratio = 25
		}

		OUTPUT_RESOURCE
		{
			ResourceName = Snacks
			Ratio = 0.0016
			DumpExcess = false
			FlowMode = ALL_VESSEL
		}
	}

	RESOURCE
	{
		name = Soil
		amount = 0
		maxAmount = 100
	}
}

@PART[KKAOSS_LS_container_greenhouse]:FOR[Snacks]:NEEDS[Snacks&PlanetaryBaseInc]
{
	//This is calibrated for 4 kerbals at 100% efficiency
	//when they consume 1 snack per meal and 1 meal per day. For your custom recycler,
	//Take into account the number of kerbals it should support along with the meals and snacks.
	//In game, the player can adjust the efficiency of the recycler from 10% to 100%.

	MODULE
	{
		name = SoilRecycler
		ConverterName = Soil Recycler
		StartActionName = Start Soil Recycler
		StopActionName = Stop Soil Recycler
		AutoShutdown = true
		GeneratesHeat = false
		UseSpecialistBonus = true
		UseSpecializationBonus = true
		SpecialistEfficiencyFactor = 0.1
		ExperienceEffect = ScienceSkill
		EfficiencyBonus = 1.0
		RecyclerCapacity = 1
	 
		INPUT_RESOURCE
		{
			ResourceName = Soil
			Ratio = 0.0002
			FlowMode = ALL_VESSEL
  		}

		INPUT_RESOURCE
		{
			ResourceName = ElectricCharge
			Ratio = 10
		}

		OUTPUT_RESOURCE
		{
			ResourceName = Snacks
			Ratio = 0.0002
			DumpExcess = false
			FlowMode = ALL_VESSEL
		}
	}
}

  

@PART[KKAOSS_ISRU_g]:FOR[Snacks]:NEEDS[Snacks&PlanetaryBaseInc]

:FOR should be recognised before :NEEDS so I wrote it that way, and this way it applies the patch correctly

The NEEDS should include the FOR if this is a multiple crossover modification. In the error-related patch file there are just wrong setted double-dots, thatfor MM shouts errors.

Edited by LatiMacciato
Link to comment
Share on other sites
Starwaster

Starwaster

Posted
Posted

@LatiMacciato

Not sure what you're trying to get across with the MM documentation quotes other than it is a reiteration of exactly what I already just said.

No, the behavior of MM should not be what you describe; instead of using FOR (since you are writing for a separate mod that is NOT Snacks) you should be using either BEFORE or AFTER. Using FOR the way you specify can cause unwanted behavior for even more mods that might be performing conditional checks for Snacks mod.

Link to comment
Share on other sites
LatiMacciato

LatiMacciato

Posted
Posted
2 minutes ago, Starwaster said:

@LatiMacciato

Not sure what you're trying to get across with the MM documentation quotes other than it is a reiteration of exactly what I already just said.

No, the behavior of MM should not be what you describe; instead of using FOR (since you are writing for a separate mod that is NOT Snacks) you should be using either BEFORE or AFTER. Using FOR the way you specify can cause unwanted behavior for even more mods that might be performing conditional checks for Snacks mod.

first of all, I have a hard time reading things in specific english words, my first lang is german, so please excuse my unwanted misunderstandings. I just wanted to describe that if you use AFTER is a sort of safer solution but using FOR does the same after the dependancy is loaded directly after and can cause issues with other mods that also follow the loading tree, but NEEDS might just set things in priority.

If NEEDS is unsatisfied then FOR just doen't apply, as far my experiments with config files. unsure if there is an issue when using FOR and NEEDS and patches applying anyways.

I also just tried to report things, glad we can discuss about this :)

Link to comment
Share on other sites
DStaal

DStaal

Posted
Posted
1 hour ago, LatiMacciato said: 

@PART[KKAOSS_ISRU_g]:FOR[Snacks]:NEEDS[Snacks&PlanetaryBaseInc]

:FOR should be recognised before :NEEDS so I wrote it that way, and this way it applies the patch correctly

The NEEDS should include the FOR if this is a multiple crossover modification. In the error-related patch file there are just wrong setted double-dots, thatfor MM shouts errors.

*Never* use :FOR[] unless you're the author of the mod you're specifying.  That’s sure to cause issues.

(I'll admit I may be off on the :NEEDS order/timing issue - it was one I was thinking didn't make sense and I may have been conflating it with the a different recent MM error-reveal change.)

Link to comment
Share on other sites
Starwaster

Starwaster

Posted
Posted (edited)
53 minutes ago, LatiMacciato said:

If NEEDS is unsatisfied then FOR just doen't apply, as far my experiments with config files. unsure if there is an issue when using FOR and NEEDS and patches applying anyways.

That statement is not true. I don't know how you conducted your experiment but the presence of FOR[some-mod-name] ANYWHERE in ANY config file will automatically satisfy any NEEDS[some-mod-name] no matter if they are in separate config files, separate folders or even running in different phases. THIS IS BY DESIGN

At the time that Module Manager begins applying patches, all phase ordering AND conditionals have already been determined and exist concurrently.

Consider the following: 

@PART[*]:NEEDS[TestForFORDependencySatisfaction]
{
	FOR.Met.Conditions = true
}
@PART[*]:NEEDS[DummyNEED]:FOR[TestForFORDependencySatisfaction]
{
	// Don't do anything
}

Go ahead and save that as a config file and run KSP. Let it finish loading and then check your ModuleManager.ConfigCache file and you will find the line FOR.Met.Conditions = true in every single PART node.

Note that the two patches occur in separate phases. The first one doesn't have a phase specified so it is applied during the LEGACY phase, which occurs just after FIRST. The second patch doesn't even perform any work, its sole purpose here was to satisfy the conditional in the first patch.

Edited by Starwaster
Link to comment
Share on other sites
LatiMacciato

LatiMacciato

Posted
Posted (edited)

considering your words 

@PART[KKAOSS_ISRU_g]:FOR[Snacks]:NEEDS[Snacks&PlanetaryBaseInc]

should be 

@PART[KKAOSS_ISRU_g]:NEEDS[Snacks&PlanetaryBaseInc]:AFTER[Snacks&PlanetaryBaseInc]

or 

@PART[KKAOSS_ISRU_g]:NEEDS[Snacks&PlanetaryBaseInc]

I just added the FOR part to make sure what mod it should apply to especially. I should test and apply this asap.
(I did things by testing and reading about other configs/MM-github-wiki)

I might reserve the FOR part for seriously own mods, not other modifications.

Thanks for pointing out.

Edited by LatiMacciato
Link to comment
Share on other sites
Starwaster

Starwaster

Posted
Posted
50 minutes ago, LatiMacciato said:

I just added the FOR part to make sure what mod it should apply to especially. 

Yeah, FOR doesn't work that way; it just specifies  what phase (or pass) to run in and satisfies conditions. As far as order goes you could take it to mean 'during' (BEFORE, during, AFTER)

Link to comment
Share on other sites
LatiMacciato

LatiMacciato

Posted
Posted (edited)
1 hour ago, Starwaster said:

Yeah, FOR doesn't work that way; it just specifies  what phase (or pass) to run in and satisfies conditions. As far as order goes you could take it to mean 'during' (BEFORE, during, AFTER)

your right, my mistake, every day is a learning day :P
Regardless the correct syntax should be :FOR and not FOR: according to the wiki so my report seems legit especially after i edited my files and MM did not threw errors anymore.

EDIT:
I also updated my snacks-recyclers Repository with correcting the :FOR issue, thanks for letting me know about this cruel thing @DStaal & @Starwaster

 

Edited by LatiMacciato
Link to comment
Share on other sites
Nils277

Nils277

Posted
  • Author
Posted (edited)

Update to 1.6.6

Changelog:

Quote

General:

  • Recompile for KSP 1.5.1
  • Updated CCK to version 4.0.0.0
  • Updated CRP to version 1.0.0.0

Mod Support:

  • Updated support for Kerbalism (thanks to IrisBlanche)
  • Updated support for KAS 1.0

Bug Fixes:

  • Fixes and clean up of chinese translations (thanks to EthanWang706)
  • Fix of a tag for the planetary module (thanks to madman2003)
  • Fixed missing colons in some MM patches (thanks to MaximeBrean)

Download:

oYvtZpW.pngUVVt0OP.pnglMOxt2k.png

Guide for the new KAS Flexible corridor:

To be compatible with @IgorZs update to KAS 1.0 the flexible corridor now consists of two separate parts. The active part is called "K&K Flexible Corridor" it can now be connected by a Kerbal to any "K&K Docking-Port" or "K&K Corridor Docking-Port". It is not possible anymore to connect two "K&K Flexible Corridor" parts with each other like it used to be before.

Edited by Nils277
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing
×
×
  • Create New...