NecroBones

[1.4.1] Fuel Tanks Plus 2.0.2 (2018-03-14)

Recommended Posts

20 hours ago, Laguna said:

@NecroBones,

I have a favor to ask, could you add (or modify) a decoupler (just one size) that is truly hollow (i.e. no colliders) on the inside to match the visual appearnce, much like the Mk1 Structural Fuselage?  I have use for such a thing as an interstage (with appropriate scale changes), and with the mesh-switching capability I could make all sorts of matching interstages.

As you may have guessed, I found out the hard way that the FTP decouplers are not actually hollow. :)

 

 

Updated. :)

 

1.12 (2017-04-07) - Tweaks & Fixes.
 - Corrected a typo that was preventing the B9PartSwitch patches from applying correctly on the radial tanks.
 - Slightly increased the performance of the 2m/3m stack decouplers, and increased their propellant maximums.
 - Changed ModularFuelTanks config to use consolidated wildcard patch.
 - Removed "cryogenic" tank type assignments from the MFT configs.
 - Stack decouplers in sizes 1.25m, 2.5m, and 3.75m collider updates, now actually hollow.

 

Share this post


Link to post
Share on other sites
8 minutes ago, NecroBones said:

 

Updated. :)

 

1.12 (2017-04-07) - Tweaks & Fixes.
 - Corrected a typo that was preventing the B9PartSwitch patches from applying correctly on the radial tanks.
 - Slightly increased the performance of the 2m/3m stack decouplers, and increased their propellant maximums.
 - Changed ModularFuelTanks config to use consolidated wildcard patch.
 - Removed "cryogenic" tank type assignments from the MFT configs.
 - Stack decouplers in sizes 1.25m, 2.5m, and 3.75m collider updates, now actually hollow.

 

Wow, thanks a million, @NecroBones! :)

 

Share this post


Link to post
Share on other sites

I'm using a lot of Roverdude's USI suite - and now that includes Configurable Containers core. I had a lot of problems with IFS and CC along side Firespitter duplicating functions (some got one type of tank edit, some go the other, Z-Fighting, etc), so I ended up having to delete IFS and any mods that depend on it. 

@NecroBones I run a lot of your SpaceY & Extended, MFS, Lithobrake, but now I miss having your extended range of tanks, and the end caps tanks - so I'm trying to figure a way to install Fuel Tanks Plus to fit my current install.

I have Firespitter core installed because it comes with USI, same goes with Configurable Containers Core. Now that I have used it, I prefer Configurable Container's fuel tank manager editing over IFS, so I don't miss IFS at all. I also run Tweakscale to resize parts, but for fuel tanks I prefer stick with whatever size the part has natively. For anything else I use Procedural Parts to make tanks for specific situations (usually interstage adapters).  If I have all these installed, and not IFS, will this mod use FS to do the meshes, and let CC manage the modularity of the fuel tank contents?  The reason I ask is that CKAN marks IFS as a hard dependency.

Edited by Murdabenne
typos as usual

Share this post


Link to post
Share on other sites

Just started my career game, noticed the following error:

[ModuleManager] ModuleManager: 28433 patches applied, found <color=orange>7 errors</color>
7 errors related to GameData/FuelTanksPlus/Patches/FuelTanksPlus_ModularFuelTanks.cfg

Here is my full log:  https://www.dropbox.com/s/smwg443npfv6ivl/fueltankplusOutputlog.zip?dl=1

KSP 1.2.2, FTP 1.12, ModuleManager 2.7.5

all mods up-to-date

Error:

[ModuleManager] Error - Cannot parse variable search when editing key origLFO = #$RESOURCE[Oxidizer]/maxAmount$

 

edit:

Here are the two lines.  Deleting the 2nd line seems to fix the error,but somehow I don't think it is correct:

	origLFO = #$RESOURCE[LiquidFuel]/maxAmount$
	@origLFO += #$RESOURCE[Oxidizer]/maxAmount$

 

Edited by linuxgurugamer

Share this post


Link to post
Share on other sites

Just to follow up, it seems to be something with the Oxidizer, I tried just having the resource for the Oxidizer, but it still had errors on that line

Share this post


Link to post
Share on other sites
21 hours ago, Murdabenne said:

I'm using a lot of Roverdude's USI suite - and now that includes Configurable Containers core. I had a lot of problems with IFS and CC along side Firespitter duplicating functions (some got one type of tank edit, some go the other, Z-Fighting, etc), so I ended up having to delete IFS and any mods that depend on it. 

@NecroBones I run a lot of your SpaceY & Extended, MFS, Lithobrake, but now I miss having your extended range of tanks, and the end caps tanks - so I'm trying to figure a way to install Fuel Tanks Plus to fit my current install.

I have Firespitter core installed because it comes with USI, same goes with Configurable Containers Core. Now that I have used it, I prefer Configurable Container's fuel tank manager editing over IFS, so I don't miss IFS at all. I also run Tweakscale to resize parts, but for fuel tanks I prefer stick with whatever size the part has natively. For anything else I use Procedural Parts to make tanks for specific situations (usually interstage adapters).  If I have all these installed, and not IFS, will this mod use FS to do the meshes, and let CC manage the modularity of the fuel tank contents?  The reason I ask is that CKAN marks IFS as a hard dependency.

It works with just Firespitter (and USI).

I don't know if it has exactly the same functionality... but it switches fuels and colors.

Share this post


Link to post
Share on other sites

Hmm.  In that case the CKAN info needs to have the alternative dependencies changed.  I recall seeing this a couple years ago, and I remember attempting a complex hack in the netkan file to allow a multiple choice mod requirement ("must have/choose 1 from this list" type of thing.)  It wasn't on this one - I don't remember which one, or even if I ever got it to work.  Maybe it was never resolved. 

Anyway thanks @Nightside - now that I know this is viable with just FS, that makes it a CKAN issue not a FTP issue. I'll take this over to the CKAN thread.

Edited by Murdabenne
clarification

Share this post


Link to post
Share on other sites
30 minutes ago, Murdabenne said:

Hmm.  In that case the CKAN info needs to have the alternative dependencies changed.  I recall seeing this a couple years ago, and I remember attempting a complex hack in the netkan file to allow a multiple choice mod requirement ("must have/choose 1 from this list" type of thing.)  It wasn't on this one - I don't remember which one, or even if I ever got it to work.  Maybe it was never resolved. 

Anyway thanks @Nightside - now that I know this is viable with just FS, that makes it a CKAN issue not a FTP issue. I'll take this over to the CKAN thread.

Take a look at the KWRocketry netkans, they do just that

Share this post


Link to post
Share on other sites
19 hours ago, linuxgurugamer said:

Error:

[ModuleManager] Error - Cannot parse variable search when editing key origLFO = #$RESOURCE[Oxidizer]/maxAmount$

 

edit:

Here are the two lines.  Deleting the 2nd line seems to fix the error,but somehow I don't think it is correct:


	origLFO = #$RESOURCE[LiquidFuel]/maxAmount$
	@origLFO += #$RESOURCE[Oxidizer]/maxAmount$

 

12 hours ago, linuxgurugamer said:

Just to follow up, it seems to be something with the Oxidizer, I tried just having the resource for the Oxidizer, but it still had errors on that line

 

I don't know why it would be failing there. The variable is added, and then edited. This logic works pretty much everywhere else. Unfortunately the log isn't much use, since it's pulling cached copies of everything. I would need to see a log generated after deleting MM's ConfigCache file. In fact, stale cache data might be the problem (I've seen things like that before).

 

Do you have anything modifying Oxidizer? Like removing it as a resource? Otherwise, I can't imagine why it would fail on that.

 

11 hours ago, Murdabenne said:

Hmm.  In that case the CKAN info needs to have the alternative dependencies changed.  I recall seeing this a couple years ago, and I remember attempting a complex hack in the netkan file to allow a multiple choice mod requirement ("must have/choose 1 from this list" type of thing.)  It wasn't on this one - I don't remember which one, or even if I ever got it to work.  Maybe it was never resolved. 

Anyway thanks @Nightside - now that I know this is viable with just FS, that makes it a CKAN issue not a FTP issue. I'll take this over to the CKAN thread.

11 hours ago, linuxgurugamer said:

Take a look at the KWRocketry netkans, they do just that

 

The funny thing is that when this was all first getting added to CKAN, they preferred to keep it simple, and list only one prerequisite out of the set. FTP does indeed work with Firespitter and/or IFS, so the netkan can probably be improved. I don't have the time at the moment to dig into that, though. Mostly the CKAN folks handle all of the metadata, but I sometimes helped it along by adding my own.

 

Share this post


Link to post
Share on other sites
16 minutes ago, NecroBones said:

I don't know why it would be failing there. The variable is added, and then edited. This logic works pretty much everywhere else. Unfortunately the log isn't much use, since it's pulling cached copies of everything. I would need to see a log generated after deleting MM's ConfigCache file. In fact, stale cache data might be the problem (I've seen things like that before).

 

Do you have anything modifying Oxidizer? Like removing it as a resource? Otherwise, I can't imagine why it would fail on that.

On a very small install, I deleted all the MM files (except the DLL)

Still happened.  Strange thing is that MM didn't make a cache file this time, I'm guessing because of the error. It did make the ModuleManager.Physics and ModuleManager.TechTree files

Log file attached:  https://www.dropbox.com/s/fxl7o7bgombc6mc/Log3.zip?dl=0

Hmmm.  I went back to the basics. totally clean install.

With FT+ as the only mod, it works

When I add Modular Fuel Tanks, it fails.

It's in your patch, which is why I posted here, but I also just posted in the MFT thread as well

Edit:  Updated log file with miniscule install

 

Edited by linuxgurugamer

Share this post


Link to post
Share on other sites
21 minutes ago, linuxgurugamer said:

Hmmm.  I went back to the basics. totally clean install.

With FT+ as the only mod, it works

When I add Modular Fuel Tanks, it fails.

It's in your patch, which is why I posted here, but I also just posted in the MFT thread as well

 

 

Very strange. That logic should be 100% fine. I do the same calculations in RSB's Stoack-alike patches. I wonder if that would do the same thing.

 

It also makes me wonder if something changed in how MM does these things recently, that I'm not aware of.

 

 

Share this post


Link to post
Share on other sites

@NecroBones I've already made a rough edit for the .netkan changes that would be needed - basically add a virtual dependency in place of IFS in the main netkan (FuelTanksPlus.netkan - 1 line change), then add 2 more netkan files (something like FuelTanksPlus-FS and FuelTanksPlus-IFS) to provide the needed "and/or" dependencies on Firespitter Core and IntersteallarFuelSwitch core.

Once I have it checked and tested and it builds the .ckan files correctly, and they are verified (via a local file install), I'll send them to you, so you can check them and then push them at your discretion to CKAN's netkan data repo on GitHub. Or if you like, I can throw the PR in for CKAN, with your permission (after checking it of course).

Thanks for such great mods - they are among my "mandatory" mods.

 

Edited by Murdabenne
clarification

Share this post


Link to post
Share on other sites

 

@linuxgurugamer, I'm wondering if MM added an error-check phase that executes on the whole sequence before executing, so it no longer likes declaring a variable and then editing it at the same level. Maybe as an experiment you can try replacing that whole patch rule with the following:

@PART[TPtank*|TPcone*|TPdome*]:BEFORE[FuelTanksPlus]:NEEDS[ModularFuelTanks]
{
	origLFO = 0
}
@PART[TPtank*|TPcone*|TPdome*]:FOR[FuelTanksPlus]:NEEDS[ModularFuelTanks]
{
	@origLFO += #$RESOURCE[LiquidFuel]/maxAmount$
	@origLFO += #$RESOURCE[Oxidizer]/maxAmount$

	MODULE
	{
		name = ModuleFuelTanks
		volume = #$../origLFO$
		type = Default
	}
}

 

Notice that it initializes the variable to zero in a "BEFORE" rule, and then only modifies it in the "FOR" rule.

 

6 minutes ago, Murdabenne said:

@NecroBones I've already made a rough edit for the .netkan changes that would be needed - basically add a virtual dependency in place of IFS in the main netkan (FuelTanksPlus.netkan - 1 line change), then add 2 more netkan files (something like FuelTanksPlus-FS and FuelTanksPlus-IFS) to provide the needed and/or dependencies on Firespitter Core and/or IntersteallarFuelSwitch core.

Once I have it checked and tested and it builds the .ckan files correctly, and they are verified (via a local file install), I'll send them to you, so you can check them and then push them at your discretion to CKAN's netkan data repo on GitHub.

 

OK cool. Thanks!

 

Share this post


Link to post
Share on other sites
9 minutes ago, NecroBones said:

 

Very strange. That logic should be 100% fine. I do the same calculations in RSB's Stoack-alike patches. I wonder if that would do the same thing.

 

It also makes me wonder if something changed in how MM does these things recently, that I'm not aware of.

 

 

See this:

 

Share this post


Link to post
Share on other sites
Just now, linuxgurugamer said:

See this:

 

 

For that to be the problem, it would have to be that another mod is removing the Oxidizer from my parts. I would need to see the KSP.log with which parts are erroring out, but the patch should only be modifying tanks that I've given Oxidizer to, and not the monoprop tanks. I could add a check for it, sure, but I don't think it'll solve this for you.

 

Share this post


Link to post
Share on other sites

 

@linuxgurugamer - Another idea I had. It's possible that Modular Fuel Tanks is doing something to the fuels or the tanks before my patch executes. I might need to just move them earlier in the sequence. Is it just MFT that you're installing? I can probably do some testing here too. Just don't have much time at the moment.

Share this post


Link to post
Share on other sites

@NecroBones

Your nuclear engines don't have Oxidizer, which is causing the problems.

@Sigma88 suggested the following should fix it:

@PART[TPtank*|TPcone*|TPdome*]:FOR[FuelTanksPlus]:NEEDS[ModularFuelTanks]
{
	origLFO = 0
}
@PART:HAS[#origLFO[0],@RESOURCE[LiquidFuel]:HAS[#maxAmount[>0]]]:FOR[FuelTanksPlus]:NEEDS[ModularFuelTanks]
{
	@origLFO += #$RESOURCE[LiquidFuel]:HAS[#maxAmount[>0]]/maxAmount$
}
@PART:HAS[#origLFO[*],@RESOURCE[Oxidizer]:HAS[#maxAmount[>0]]]:FOR[FuelTanksPlus]:NEEDS[ModularFuelTanks]
{
	@origLFO += #$RESOURCE[Oxidizer]:HAS[#maxAmount[>0]]/maxAmount$
}
@PART:HAS[#origLFO[>-1]]:FOR[FuelTanksPlus]:NEEDS[ModularFuelTanks]
{
	MODULE
	{
		name = ModuleFuelTanks
		volume = #$../origLFO$
		type = Default
	}
}

 

Share this post


Link to post
Share on other sites
Just now, linuxgurugamer said:

@NecroBones

Your nuclear engines don't have Oxidizer, which is causing the problems.

@Sigma88 suggested the following should fix it:


@PART[TPtank*|TPcone*|TPdome*]:FOR[FuelTanksPlus]:NEEDS[ModularFuelTanks]
{
	origLFO = 0
}
@PART:HAS[#origLFO[0],@RESOURCE[LiquidFuel]:HAS[#maxAmount[>0]]]:FOR[FuelTanksPlus]:NEEDS[ModularFuelTanks]
{
	@origLFO += #$RESOURCE[LiquidFuel]:HAS[#maxAmount[>0]]/maxAmount$
}
@PART:HAS[#origLFO[*],@RESOURCE[Oxidizer]:HAS[#maxAmount[>0]]]:FOR[FuelTanksPlus]:NEEDS[ModularFuelTanks]
{
	@origLFO += #$RESOURCE[Oxidizer]:HAS[#maxAmount[>0]]/maxAmount$
}
@PART:HAS[#origLFO[>-1]]:FOR[FuelTanksPlus]:NEEDS[ModularFuelTanks]
{
	MODULE
	{
		name = ModuleFuelTanks
		volume = #$../origLFO$
		type = Default
	}
}

 

 

Ah! Excellent. That first one needs to change to a "BEFORE" since it's creating the variable, but otherwise that looks good. I'll add it.

 

Share this post


Link to post
Share on other sites
Just now, NecroBones said:

 

Ah! Excellent. That first one needs to change to a "BEFORE" since it's creating the variable, but otherwise that looks good. I'll add it.

 

Will you have an update out today?  Only asking because I'm streaming this evening, and if  you aren't, I'll do a local patch

Share this post


Link to post
Share on other sites
Just now, linuxgurugamer said:

Will you have an update out today?  Only asking because I'm streaming this evening, and if  you aren't, I'll do a local patch

 

Yep, I'm putting it together now. I'll get that out ASAP.

 

Share this post


Link to post
Share on other sites
Just now, NecroBones said:

 

Yep, I'm putting it together now. I'll get that out ASAP.

 

Ok, thanks for your fast response

Share this post


Link to post
Share on other sites
5 minutes ago, NecroBones said:

 

Ah! Excellent. That first one needs to change to a "BEFORE" since it's creating the variable, but otherwise that looks good. I'll add it.

 

as long as you put them in the correct order you don't need a BEFORE

Share this post


Link to post
Share on other sites
1 minute ago, Sigma88 said:

as long as you put them in the correct order you don't need a BEFORE

 

Good to know, but the old programmer in me doesn't like to trust things that aren't explicitly defined. :)

 

Share this post


Link to post
Share on other sites
2 minutes ago, NecroBones said:

 

Good to know, but the old programmer in me doesn't like to trust things that aren't explicitly defined. :)

 

it would be explicitly defined as in you use FOR for all the patches and they are executed in order :)

usually I put all steps in the same "time frame" so that if someone wants to do something before or after my patch they can use BEFORE or AFTER

 

but of course that's up to you :)

Edited by Sigma88

Share this post


Link to post
Share on other sites
2 minutes ago, Sigma88 said:

it would be explicitly defined as in you use FOR for all the patches and they are executed in order :)

usually I put all steps in the same "time frame" so that if someone wants to do something before or after my patch they can use BEFORE or AFTER

 

OK, I'll leave it for now. I still use a lot of BEFORE/AFTER in how I do things anyway, but sometimes it's very circuitous by necessity.

 

 

Posted:

 

1.12.1 (2017-04-09) - MFT fix.
 - Corrected some MM patch issues for ModularFuelTanks.

 

 

Share this post


Link to post
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.