Jump to content

[1.9-1.10] Configurable Containers

allista

By allista
in KSP1 Mod Releases

 Share

Recommended Posts

Aelfhe1m

Aelfhe1m

Posted
Posted (edited)

@ss8913 To get AT_Utils to compile in VS2017 you just need to go into project properties and change the target framework to .net 3.5 (after updating the references). It looks like monodevelop which @allista uses writes the .csproj file differently (or ignores it? I've never used monodevelop so can't comment) but the GitHub version definitely list .net 2 as its target on this line - changing that either in VS or a text editor is all that's needed.

Spoiler

YHCfwcd.png

Edit: I've only tested whether it will build - not whether the built DLL works correctly.

Edited by Aelfhe1m
disclaimer
Link to comment
Share on other sites
ss8913

ss8913

Posted
Posted (edited)
11 hours ago, Aelfhe1m said:

@ss8913 To get AT_Utils to compile in VS2017 you just need to go into project properties and change the target framework to .net 3.5 (after updating the references). It looks like monodevelop which @allista uses writes the .csproj file differently (or ignores it? I've never used monodevelop so can't comment) but the GitHub version definitely list .net 2 as its target on this line - changing that either in VS or a text editor is all that's needed.

  Reveal hidden contents

YHCfwcd.png

Edit: I've only tested whether it will build - not whether the built DLL works correctly.

that seems promising.. thanks!  and yes I'm using VS2017.. maybe I should try this on linux.. I have used linux since 1993, but I figured, perhaps wrongly, that this would be easier on windows... :)
EDIT: Yes, that worked.  I'm testing the new DLLs now.  With the existing DLLs, KSP crashes on load, so if I can get to the start menu, it's an improvement over the current status.  will post a zip with the new .dll files if it works.

Edited by ss8913
Link to comment
Share on other sites
allista

allista

Posted
  • Author
Posted

Version 2.4.1.1 for Kerbal Space Program 1.3.1

Released on 2017-11-09

  • Fixed Cryogenic/CryoCooling NEEDS, fixed KarbonitePlus requirement for Metal.
  • Update TankTypes.cfg
    • added Snacks support (Snacks --> Food, Soil --> Soil)
    • modified KolonyTools support --> ColonySupplies are visible/usable/transferable even if USI-LS is not installed
  • Added Chemicals to LiquidChemicals for KolonyTools.
  • Attempt to fix #10 using the patch suggested by @Starwaster.
  • Fixed issues:
    • 16 - Attempting to change configuration when none exists results in NullReferenceException
    • 18 - Tweakscaled tank saved prior to installation of CC gets capacity reset to un-scaled value
    • 20 - Lag/freeze when placing tanks in VAB

 Download 

Link to comment
Share on other sites
  • 2 weeks later...
  • 3 weeks later...
Murdabenne

Murdabenne

Posted
Posted

@allista FYI, Configurable Container's mod manager scripts generate a couple hundred errors with the new Module manager.  All the same type of error, see below.  And unlike before, they no longer generate cache, which means the mod is broken for now, with the parts associated. 

[ERR 01:33:48.470] [ModuleManager] Error - more than one pass specifier on a node: ConfigurableContainers/Parts/Tal-Tanks_Patch/@PART[TAL.Toroidal.Tank.Medium.Fuel]:FOR[ConfigurableContainers]:HAS[!MODULE[InterstellarFuelSwitch],!MODULE[FSfuelSwitch],!MODULE[ModuleB9PartSwitch]]:AFTER[ModsByTal]

Apparently they are now strictly enforcing syntax, and the MM scripts are in error (and thus do not get processed).  This error is specifically addressed. Apparently you cannot have a FOR with an AFTER.

See here for more details:

 

Link to comment
Share on other sites
allista

allista

Posted
  • Author
Posted
On 12/4/2017 at 11:21 AM, Murdabenne said:

@allista FYI, Configurable Container's mod manager scripts generate a couple hundred errors with the new Module manager.  All the same type of error, see below.  And unlike before, they no longer generate cache, which means the mod is broken for now, with the parts associated. 


[ERR 01:33:48.470] [ModuleManager] Error - more than one pass specifier on a node: ConfigurableContainers/Parts/Tal-Tanks_Patch/@PART[TAL.Toroidal.Tank.Medium.Fuel]:FOR[ConfigurableContainers]:HAS[!MODULE[InterstellarFuelSwitch],!MODULE[FSfuelSwitch],!MODULE[ModuleB9PartSwitch]]:AFTER[ModsByTal]

Apparently they are now strictly enforcing syntax, and the MM scripts are in error (and thus do not get processed).  This error is specifically addressed. Apparently you cannot have a FOR with an AFTER.

See here for more details:

 

Thanks! Will fix ASAP.

But it would do MM good to first make a release with some deprecation warnings. One oughtn't break an API like this :(

Link to comment
Share on other sites
Murdabenne

Murdabenne

Posted
Posted (edited)

It would have been nice to see: "we are going to depreciate this behavior in the next release" , with MM spamming warnings and continuing, instead of erroring out, at least for a few weeks.  There are several mods which have been hit by this.

Happy that the fix is not obscure, and doesn't require code changes.

Edited by Murdabenne
Link to comment
Share on other sites
  • 2 weeks later...
Murdabenne

Murdabenne

Posted
Posted

Do you have a fix I can test for you?   Here is an example at random:

PART[KW1mtankL4]:FOR[ConfigurableContainers]:HAS[!MODULE[InterstellarFuelSwitch],!MODULE[FSfuelSwitch],!MODULE[ModuleB9PartSwitch]]:NEEDS[!modularFuelTanks&!RealFuels]:NEEDS[KWRocketry]:AFTER[KWRocketry]

Unpacking it:
PART[KW1mtankL4]
:FOR[ConfigurableContainers]
:HAS[ !MODULE[InterstellarFuelSwitch], !MODULE[FSfuelSwitch], !MODULE[ModuleB9PartSwitch] ]
:NEEDS[ !modularFuelTanks & !RealFuels ]
:NEEDS[KWRocketry]
:AFTER[KWRocketry]

One of the two in red has to go - and I was wondering about the intent of the use of FOR, since you are already running it from inside the context of ConfigurableContainers. It may be redundant here.   If that's the case, then the fix for all the tank config scripts is pretty simple.

PART[KW1mtankL4]:FOR[ConfigurableContainers]:HAS[!MODULE[InterstellarFuelSwitch],!MODULE[FSfuelSwitch],!MODULE[ModuleB9PartSwitch]]:NEEDS[!modularFuelTanks&!RealFuels]:NEEDS[KWRocketry]:AFTER[KWRocketry]

I was also wondering why  "NEEDS[!modularFuelTanks & !RealFuels]" is in there. Is this to avoid a conflict with the module tank manager from those?  If so can you instead check for pre-existing "HAS" for a module tank manager instead.

Link to comment
Share on other sites
Jesusthebird

Jesusthebird

Posted
Posted (edited)
On 12/15/2017 at 6:03 PM, Murdabenne said:

Do you have a fix I can test for you?   Here is an example at random:

PART[KW1mtankL4]:FOR[ConfigurableContainers]:HAS[!MODULE[InterstellarFuelSwitch],!MODULE[FSfuelSwitch],!MODULE[ModuleB9PartSwitch]]:NEEDS[!modularFuelTanks&!RealFuels]:NEEDS[KWRocketry]:AFTER[KWRocketry]

Unpacking it:
PART[KW1mtankL4]
:FOR[ConfigurableContainers]
:HAS[ !MODULE[InterstellarFuelSwitch], !MODULE[FSfuelSwitch], !MODULE[ModuleB9PartSwitch] ]
:NEEDS[ !modularFuelTanks & !RealFuels ]
:NEEDS[KWRocketry]
:AFTER[KWRocketry]

One of the two in red has to go - and I was wondering about the intent of the use of FOR, since you are already running it from inside the context of ConfigurableContainers. It may be redundant here.   If that's the case, then the fix for all the tank config scripts is pretty simple.

PART[KW1mtankL4]:FOR[ConfigurableContainers]:HAS[!MODULE[InterstellarFuelSwitch],!MODULE[FSfuelSwitch],!MODULE[ModuleB9PartSwitch]]:NEEDS[!modularFuelTanks&!RealFuels]:NEEDS[KWRocketry]:AFTER[KWRocketry]

I was also wondering why  "NEEDS[!modularFuelTanks & !RealFuels]" is in there. Is this to avoid a conflict with the module tank manager from those?  If so can you instead check for pre-existing "HAS" for a module tank manager instead.

Ive tested this. removing :FOR[ConfigurableContainers] in every .cfg gets MM to generate a config cache. now I didnt try every mod for every patch. I downloaded the mk2 and mk3 expansion +dependencies from ckan along with IFS and B9partswitch for testing purposes. Now....not every part in the fuel tank section(example) can be changed, even though IFS was able to... I imagine thats the limitation of either the parts themselfs, or that the information hasn't been added to the cfg. but regardless...I got my quicker loading times back!!

Edited by Jesusthebird
Link to comment
Share on other sites
Caliban259

Caliban259

Posted
Posted
6 hours ago, Jesusthebird said:

Ive tested this. removing :FOR[ConfigurableContainers] in every .cfg gets MM to generate a config cache.

Confirmed. It's as simple as "find & replace" in WordPad. Have to do it with all dependant cfg-files in the \ConfigurableContainers\Parts-directory...

Gets rid of all the error messages and CC is running fine in game.

Link to comment
Share on other sites
genericevildude

genericevildude

Posted
Posted

Here's all the configs that I removed :FOR[ConfigurableContainers]. There's no more MM errors, my crafts seem fine. I can edit squad tanks and I tried to edit a mod tank (Talisar spherical tank) but there was no option in-flight or in the editor.

Disclaimer: I don't know anything about modding other than installing them, I just went through every config and removed :FOR[ConfigurableContainers], so use at your own risk and backup your saves.

 

https://www.dropbox.com/sh/2orehp842uukqie/AABXzfCQ9W9N3UIeRBwnGNUfa?dl=0

Link to comment
Share on other sites
Murdabenne

Murdabenne

Posted
Posted (edited)
9 hours ago, allista said:

Thanks everyone for the help here! I have my hands full right now, so I really appreciate it :)

Willrelease a version with this patch tonight.

Thanks very much! 

OffTopic: How's the new baby, sleep through the night on a regular basis yet? Becoming a Dad is one of the few things cooler than hitting your first landing on the Mun without MechJeb and without crashing! :wink:  Unlike KSP, there's no mods, there's not even a manual! :D

Edited by Murdabenne
Link to comment
Share on other sites
Murdabenne

Murdabenne

Posted
Posted (edited)

The NEEDS specifies that the modules are either there [mod], or else are NOT there [!mod] in order for this to run. Basically it means after the initial parse there must be an addon directory with that name or else someone has created one with a FOR[mod] statement.  If the NEEDS of a mm statement are not met then it is my understanding that it is simply is not processed any further after the initial pass for detecting NEED, in effect, its discarded if there is no NEED for it.  Note: I think its possible for HAS to work in this role as well, although I have never used it in that manner.

The NEEDS[] can be used as many times as you want.

The statement you quote means that there cannot be ModulaFuelTanks and cannot be RealFuels, and there must be KWRocketry.  Using simple propositional logic from my high school days oh so long ago...

(~A & ~B) & C using demorgans you get  you get ~(A | B ) & C, which might render a little more clearly as NOT (A or B), and C. 


In plain English, it goes something like this: Neither A nor B can be present, and C must be present.

As long as KWRocketry is loaded, and both ModularFuelTanks and RealFuels are not loaded, then this rule will process. 

I was asking about checking for the tank manager module. But that brings with it a whole host of problems, starting with - what happens if this runs before MFT or RF, will they overwrite CC, or will the presence of CC prevent them from functioning, essentially breaking those mods?  This would require fairly close coordination and integration between all 3, which makes the entire system brittle as hell, breaking all of them any time any of the 3 changes.  So now that I think about it, its probably not such a good idea unless the other authors agree in advance to disentangle their apps or agree on a commonality that all 3 can use and that none will break.

 

Edited by Murdabenne
Link to comment
Share on other sites
Murdabenne

Murdabenne

Posted
Posted

MM is nice, but its still a relatively blunt instrument when so many mods duplicate functionality yet nobody has time to work out or agree on a universal standard for fuel tank managers in terms of what they need to do, how they do it, etc.   Think about it, there's this Configurable Containers, Interstellar Fuel Switch, Modular Fuel Tanks, etc, and then there's the grand daddy of them all: Firespitter's FSfuelSwitch.  On top of that are the mods that depend on a single one, like Interstellar on IFS, RealFuels on MFT, and then there are even some that take one multiples, like NecroBone's FuelTanksPlus (which uses IFS or MFT but not CC).

If I recall the history of this specific case (CC vs MFT & RF) the reasoning is that MFT and RF, separately and together, change things in KWRocketry in a way that Configurable Containers would break, or that would break CC.  So CC simply will not change KWRocketry if either or both of them (MFT, RF) are loaded mods.   Mainly something to do with tank manager modules, mass recalculations,  and other tangled dependencies. 

 

Link to comment
Share on other sites
Murdabenne

Murdabenne

Posted
Posted (edited)

Hey @allista or anyone else that know how this works... how would I go about overriding the default avoidance behavior this has for IFS, B9PartSwitch and FSFuelSwitch?

Basically, in the MM scripts, instead of bailing out on all the KWRockety (or other mod) configs when those other mods are present, I want to either override them, or better yet, make a new part that takes away the other stuff and uses CC's internals instead.  The reason for this is that I want KW stuff, and maybe Fuel Tanks Plus as well, with CC for managing the internal structure and fuels the tank has.  I understand from reading that MFT and RF are pretty closely entangled, so Im not going to mess with those.

As far as I can tell, KW tanks and FTP tanks are stand alone parts mods, so changing their internals at the very final pass should break other apps as long as I am creating new parts (leaving the originals in place), and deleting out all the old guts of the copied part.  The one thing I do worry about is the B9PartSwitch is also used for changing textures, so ripping these out would also kill the ability to change textures. 

Would something like this work, if not, what would it break and how? (I'm trying to learn).  Will this break any texture switching, or does it just affect internal sctructure and contents? KW Size 2 "Pancake" tank presented as an example, below.

  

+PART[KW2mtankPancake]:HAS[MODULE[InterstellarFuelSwitch] OR MODULE[FSfuelSwitch] OR MODULE[ModuleB9PartSwitch]]:NEEDS[!modularFuelTanks&!RealFuels]:NEEDS[KWRocketry]:FINAL
{
	name =  CCKW2mtankPancake

	// remove stock resources
	-RESOURCE[LiquidFuel] { }
	-RESOURCE[Oxidizer] { }

	// remove conflicting modules
	-MODULE[InterstellarFuelSwitch] { }
	-MODULE[FSfuelSwitch] { }
	-MODULE[ModuleB9PartSwitch] { } // need to figure a way to not touch the ones that are doing the texture switching

	// remove tank manager if it already exists, the reimplement it per straight CC
	-MODULE[ModuleTankManager] { }
	MODULE
	{
		name = ModuleTankManager
		Volume = 5.55555555556 //405.000000 units of LF: conversion rate is 0.013717 m3/u
		DoCostPatch = True
		DoMassPatch = True
		TANK
		{
			name = LFO
			Volume = 100.0
		}
    }
}



 

Edited by Murdabenne
Link to comment
Share on other sites
  • 2 weeks later...
Tau137

Tau137

Posted
Posted (edited)

@allista: Are you aware that you are using wrong conversion coefficients for Monopropellant?  You took them from stock mini-tank, and that is the only one (radial tanks are pretty bad, too) that holds almost 3 times as much as it should have, compared to all other containers?

As a result, all other non-RCS container (stock and mode), after you patch them, can hold almost 3 times as much RCS fuel as they were supposed to, by volume, and all formerly RCS tanks (except the mini stock one) can only hold 1/3 of other resources (e.g., LFO).

If you consider this important (few people would care, presumably, except perhaps those that use NF Spacecraft, where this miscalculation gives almost cheat-leave advantage to monoprop engine over LFO, e.g., on landers), please correct the MM patches; stock mini-rcs tank can be either left extremely overstuffed or, optionally (at your or end-user's choice), nerfed to its proper volume of ~160L.

I also noticed some glitchty behaviour with TweakScale, where parts with configurable containers, when cloned in editor from resized parts, get scale factor applied twice (^2) to container volumes... have not figured that one out yet, but it is not a big deal.

Otherwise great stuff, I have almost everything "configurable" now, helps a lot with keeping part count low.  Thank you keeping up great work, on this and your other mods (I just wish you'd enable orbital option for Ground Construction...)

Edited by Tau137
Link to comment
Share on other sites
This thread is quite old. Please consider starting a new thread rather than reviving this one.

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