[1.12.x] SimpleFuelSwitch v1.4.2: Toggle tanks' fuel type in the editor. Simple and lightweight.

[DStaal]

7 minutes ago, Tyko said:

Hey Snark, just FYI, 7-Zip will open .rar files and it's a well established third party app

It's still a proprietary format that's extremely uncommon off of Windows.  (Rar does have advantages, mostly in compressed file size.  But it's not an open format, and there's only a couple of programs that can use it because it's proprietary.  Some newer open formats can match it's advantages - but aren't as common yet as .zip.  And really, for small text files .zip does just fine.)

[Snark]

3 hours ago, Tyko said:

Hey Snark, just FYI, 7-Zip will open .rar files and it's a well established third party app

Ah yes, yet another third party app that I don't have installed and am not super inclined to.  But thanks for the recommendation. 

3 hours ago, 4x4cheesecake said:

That's no problem at all and already done

Updated link is in my previous post.

Excellent, thanks! 

Anyway... now that I can see all your config files, I have a better idea of what you're doing.  You're looking for total mix-and-match choice on exactly which categories of tanks have exactly which resource choices available.  Okay, yeah, I can see why that would be kinda tricky to do with just plain MM, without having a combinatorial explosion of "if you want <set of options>, install <one of a bazillion folders to choose from>".

Will bear in mind when I (presumably) eventually getting around to setting up a repository for this kinda stuff to live.  Thanks!

If I might offer a suggestion... a way to avoid having to tell people "delete such-and-such" (which is kinda the point of MM):

[4x4cheesecake]

45 minutes ago, Snark said:

Okay, yeah, I can see why that would be kinda tricky to do with just plain MM, without having a combinatorial explosion of "if you want <set of options>, install <one of a bazillion folders to choose from>".

Also, IMO it's a simple solution which is easy to understand. I'm not totally happy so far but it's start to get shape

45 minutes ago, Snark said:

If I might offer a suggestion... a way to avoid having to tell people "delete such-and-such" (which is kinda the point of MM):

What's your suggestion? Do I need to buy the Snark-DLC first to continue the story? Always these cliffhangers...
I couldn't think of a different way to solve this so I'm really curious (I know the point of MM though but sometimes I lose the forest for the trees...)

Edited January 11, 2019 by 4x4cheesecake

[Snark]

37 minutes ago, 4x4cheesecake said:

What's your suggestion?

Edit snafu.    Started to write that, realized (after reading your stuff) that you were doing something completely different than I had assumed you were doing, realized I had no suggestion, changed my post but forgot to delete that last bit. 

[4x4cheesecake]

6 minutes ago, Snark said:

Edit snafu.    Started to write that, realized (after reading your stuff) that you were doing something completely different than I had assumed you were doing, realized I had no suggestion, changed my post but forgot to delete that last bit. 

Dang it, I was hoping for a suggestion since I actually would prefer to create a setup config instead of deleting stuff but I cannot think about a solution so far (well, I have an idea but that's probably overly complicated...even more than my solution/workaround to 'I don't know how to multiply fractions of numbers in a MM patch').

But since the actual state of the configs can be a bit confusing without knowing where I want to go, I'll try to explain it a bit and hope there are still some missunderstandings so you (or someone else) may be able provide an idea anyway^^

In generall, I filter the tanks by stock resource and exclude some other parts like commands pods with mono prop, engines with LFO, and so on.
Then, there are the two 'stock' configs: one will add the default/stock fuel configuration for every tank and the 'ModuleSimpleFuelSwitch' module (This has to happen here because I try to use the new module to prevent the default config to intercept). The other config will remove the stock resources. I seperated these steps to be able to fire up these patches with a different timing. The xenon tanks were always skipped because the stock xenon resource got removed before I was able to filter these tanks to add the new resources.

One idea to refine these patches: Add the 'ModuleSimpleFuelSwitch' only if at least two fuel types are available.

The other patches will just add the new resources to the tanks and calculate the required amount of fuel to reach the same wet mass of the stock tanks. That's no possible for both 'LF_Only' AND 'Ox_Only' since I want to balance them in a different way, so I decided that 'Ox_Only' will be slighty heavier (instead of making 'LF_Only' lighter).
The filter used on these are the same as before in the stock configs.

Regarding the ordering (not finished yet since it still has some issues with your default config), I thought about this:

• Add the 'ModuleSimpleFuelSwitch' module and the stock fuel configuration
• Add all the other fuels
• Remove stock fuel resources

My ideas for the next step:

• Add a config file which adds a 'dummy' value to choosen parts
• Use the dummy value instead of the stock resources to filter the parts which needs to be patched.
• Try some nested logic operators to identify which part got multiple fuel configs or
• I guess it is possible to add something like a 'loop counter' to identify which part got more than one fuel configuration to determine which part needs the 'ModuleSimpleFuelSwitch'

This is nice opportunity to improve my MM knowledge

I'll work on it tomorrow again, already curious if I can manage to reach all the goals

 

[Snark]

Hi gang,

Just a note that I've found a couple of bugs around part-copying in the vehicle editor.  Am currently working on fixing them; no ETA yet, there's a helluva lot of trial-and-error "no, that didn't work" type of stuff, as resource-copying logic in the KSP editor is super gnarly and hard to figure out (for me, anyway).  Just wanted to give you a heads-up that these bugs are out there, so that you won't get bitten by them unawares.

Here's what I've found so far:

• If you attach a part, and then you change it to have a resource amount other than the default (e.g. you attach an LFO tank that normally has a full load of fuel, and you reduce it to, say, 50%), and then you use alt-click to copy the part... the copied part always ends up with the default fuel load, rather than copying the parent's.
• Even worse.  If you alt-click to copy a part that has child parts equipped for SimpleFuelSwitch, then all of the child parts (and their children, and so forth) end up with no resources at all-- that applies to the original part tree, and also the new copy.

So yeah, that's a snarled rat's nest to figure out.  Have already been going around in circles for hours on it, mainly succeeding in establishing the various attempted fixes that don't work.

Anyway, just be aware:  issues with copying parts.  Sorry I didn't catch earlier, folks.  Will announce when I have a fix.

[Snark]

Update:

Holy hecking crap, this is gnarly.  It's seriously fugly.  Unless there's some magic bullet for working with resources simply in KSP, this is going to take serious boatloads of my time, as in, probably days' worth of time.  That's "days" as in "days spent full-time trying to unravel this knot", not calendar days.  Given that I've got IRL stuff going on, that means there's no way this is gonna get fixed over the weekend-- and it could be quite a few days beyond that.  Ugh.

Technobabble in spoiler, if anyone's curious.

Spoiler

Underlying problem:  KSP seems to have some rather unfortunate assumptions built into its part-copying logic, where "copying" includes several varieties of copying.  Basically, when it copies a part, it doesn't take the original's resources and move them right over-- instead, it populates the clones' resources from the default "I just made a new part" template, and then copies them across, assuming that the resources line up between parent and clone.  The assumption is seriously baked in, so it barfs all over the place if the original's resources aren't exactly what the default template is.

This is seriously exacerbated by the lack of useful hooks saying "yeah, I just copied this thing even though it's being copied as the result of being in a child part tree or as a symmetry operation".

Basically, the only thing I can think of at this point is to build some seriously arcane multiple-nested-levels-deep data structures that span the recursive child tree and the N-way symmetry group, and somehow try to hook enough notifications that when a copy happens, I can strip all the resources out of the entire source tree before the copy, and then remember where they all were, and then do the copy, and then not only put everything back exactly the way it was, but also somehow find all the corresponding clones and copy resources over to them.

It's currently looking like it'll end up being a body of code that's going to end up being several times bigger and more complex than the entire corpus of the mod's code up to this point.   I confess to having some unkind thoughts about the KSP editor logic at this point, though I suspect I'm being unfair and that that's just the frustration talking.  It's just that this feels like something that ought to be trivially simple (i.e. shouldn't even be a thing), and instead is needlessly tortuously complex.  To put it in perspective, this is easily the gnarliest programming problem of all the mods I've ever developed up to now-- or at least that's how it's looking thus far.

Maybe there's some really elegant and simple solution that I'm missing (i.e. some hook buried somewhere in the game that if I do this one simple thing, everything "just works" and I don't have to worry about it).  I'll ask around.

But until and unless I can find such a silver bullet, this is going to be a very long hard slog.

In other words:  I'm working hard on it, but no fix soon, folks.  Sorry about that.

[linuxgurugamer]

On 1/10/2019 at 7:36 PM, Snark said:

Anyway, yeah, that's a good idea, and (at least for the BigS delta) I'll plan to fix that in the next release.

Take a look at the Mk2.5 Spaceplane Parts mod, it has 5 different sizes of the BigS Delta, if you are going to add this to the BigS, then you might as well add it to these as well.

Specifically, the following parts (partnames listed):

• mk25WingShuttleDelta
• mk25WingShuttleDeltaLong
• mk25WingShuttleDeltaLong2
• wingShuttleDelta-2x
• wingShuttleDelta-3x

[4x4cheesecake]

@Snark Sounds like a serious issue I hope you can find a elegant solution for it  

In the mean time, I rewrote big chunks of my config which is now configurable without deleting stuff
This new version comes with a 'alternative_config.cfg':

SFS_Alternative_Config
{
	//Change values to 'false' to prevent the fuel type from beeing added.
	//LF_Only tanks	
	LF_Add_LFO = true
	LF_Add_Ox = true
	LF_Add_Mono = true
	LF_Add_Xe = true
	
	//LFO tanks	
	LFO_Add_LF = true
	LFO_Add_Ox = true
	LFO_Add_Mono = true
	LFO_Add_Xe = true
	
	//MonoProp tanks
	Mono_Add_LF = true
	Mono_Add_LFO = true
	Mono_Add_Ox = true
	Mono_Add_Xe = true
	
	//Xenon tanks
	Xe_Add_LF = true
	Xe_Add_LFO = true
	Xe_Add_Ox = true
	Xe_Add_Mono = true
}

If you don't want a specific fuel type in a specific tank type, just set the value to 'false'.

For example: If you don't want MonoProp in LFO tanks and no fuel changes to the xenon tanks at all, change the entries to:

SFS_Alternative_Config
{
	[snip]

	//LFO tanks	
	LFO_Add_LF = true
	LFO_Add_Ox = true
	LFO_Add_Mono = false
	LFO_Add_Xe = true

	[snip]

	//Xenon tanks
	Xe_Add_LF = false
	Xe_Add_LFO = false
	Xe_Add_Ox = false
	Xe_Add_Mono = false
}

Still not compatible with the default config though, these files still must be removed

Engines, Air Intakes and Command Pods are still not affected (on purpose)

Download: https://www.dropbox.com/s/651dlu5q4ahokdn/SFS_Alt_Conf_v2.zip?dl=0

Edited January 12, 2019 by 4x4cheesecake

[DMagic]

@Snark I don't know if it helps, but there is a PartModule.OnCopy method that can be overridden for any part module. I think it fires for all of the child parts as well.

There are OnWillBeCopied and OnWasCopied methods as well, but they don't seem to work correctly (a bug report was filed a while back).

[Snark]

7 hours ago, linuxgurugamer said:

Take a look at the Mk2.5 Spaceplane Parts mod, it has 5 different sizes of the BigS Delta, if you are going to add this to the BigS, then you might as well add it to these as well.

Yep, that's not a bad idea-- however, taking time to support any specific 3rd-party mods at all is outside of my personal scope for the work I'm willing to do, unless it happens to be a mod that I myself want to use (which Mk2.5 Spaceplane Parts is not). 

However, it would be really nice to support as many mods as possible, even if I myself don't feel like doing the work-- so what I'm thinking is that once the dust settles a bit (i.e. I've worked through my current set of bugs, and am not in the midst of doing any major feature work), that'll be a good time to set up a companion "community compatibility library" mod, for user-supplied configs.  I'll just curate it, not author it.  That way, hopefully folks will step up with contributions and we'll all get nice support for the things we like. 

3 hours ago, DMagic said:

@Snark I don't know if it helps, but there is a PartModule.OnCopy method that can be overridden for any part module. I think it fires for all of the child parts as well.

There are OnWillBeCopied and OnWasCopied methods as well, but they don't seem to work correctly (a bug report was filed a while back).

Thanks!  Unfortunately, I've already looked at all of them, and none of them do what I need.  Technobabble in spoiler.

Spoiler

So here's the problem that's currently the bane of my existence:

[EXC 14:26:07.812] ArgumentOutOfRangeException: Argument is out of range.
Parameter name: index
	System.Collections.Generic.List`1[PartResource].get_Item (Int32 index)
	DictionaryValueList`2[System.Int32,PartResource].At (Int32 index)
	PartResourceList.get_Item (Int32 index)
	Part.OnCopy (.Part original, Boolean asSymCounterpart)
	EditorLogic.createSymmetry (Int32 mode, .Attachment attach)
	EditorLogic.<SetupFSM>m__D ()
	KerbalFSM.UpdateFSM ()
	EditorLogic.Update ()

Here's what's happening:  A part is getting "copied" for some reason (either due to an alt-click on the part, or an alt-click on some parent part in its tree, or spawning symmetry counterparts).  The following sequence of events happens:

1. OnWillBeCopied gets called.
2. KSP presumably does some stuff.
3. OnWasCopied gets called.
4. KSP does stuff, and eventually calls Part.OnCopy, which does the following:
   1. Stuff.
   2. Copy resources across.  This is where the exception gets thrown.
   3. PartModule.OnCopy for all the modules.
5. Eventually (in the case of an explicit alt-click copy) the EditorPartEvent fires for ConstructionEventType.PartCopied.

 

What's happening when it barfs, I think, is that it's trying to copy the resources across from the origin part to the clone part... and that part-copying logic doesn't actually simply copy from A to B.  If it would just do that one simple thing, then none of this would be any issue at all.  But, alas, to my neverending torment, that's not what it does.  Instead, what it does is first set up the resources on the clone based on the resource prefab template for that part type, and then it just assumes there's a 1:1 mapping between resources on the origin part and resources on the (pre-initialized) clone.  Which means if the resources currently on the origin part are different in any way from what the part prefab says... boom!

So that's the bad thing that's happening.  The problem is... it is super gnarly trying to find a way around it, since I don't have any hooks where I need them (at least, none that I've been able to discover).

• OnWillBeCopied and OnWasCopied are completely useless, because they happen too soon-- the barf happens after they're done.
• PartModule.OnCopy, on the other hand, is useless because it happens too late-- the barf has already happened by then.

And as far as I can tell there's no hook that does what I really need it to, in the spot where I need it, in order to prevent the problem.

So far, the only approach I've been able to think of-- which I am currently working to implement-- is going to be a big cumbersome thing where I strip out all resources from the part and its tree when the part is detached or created-as-a-copy, and remember that, and then when attaching it to the model, re-populate all the resources at attachment time.

With, of course, the added complexities of dealing with symmetry groups and descendant-part trees.

Blech. 

 

[linuxgurugamer]

@Snark

The thought just hit me that the other fuel-changer mods (IFS, Firespitter, etc) may not have the same issue.  I don't know, but it would be worth looking at them and maybe not duplicating code???

[Snark]

I glanced, I saw nothing obvious... And they're architected fairly differently from mine, and also apparently not everyone shares my habit of commenting code lavishly... or, indeed, at all.

Anyway, an idea is starting to gel, and when it's finally implemented it may not be too bad in terms of code complexity-- much of the hassle is the lengthy reverse engineering process of just figuring out all the detailed semantics of what's going on.

[Snark]

Hi all,

I'm pleased to announce the release of SimpleFuelSwitch v1.0.2, which fixes those infuriating NRE bugs. 

No new features, it's just a bug fix.

(The logjam broke when I finally figured out exactly what was giving it indigestion-- turned out to be something completely different from what I thought it was, which made the solution a lot simpler than I thought it would need to be.)

Anyway, enjoy!

[Snark]

Hi again,

I've just released SimpleFuelSwitch v1.1, which adds the ability to use part variants to select resource types.

If you're simply installing and using SimpleFuelSwitch as a player, this doesn't affect you, since none of the configs I install by default actually do this.  However, it's functionality that's now fully supported in config, so if you're developing a third-party mod (or just tinkering with some ModuleManager config), you now have the ability to do this.

Thus, for example, if you're producing a life support mod that has "Chips", "Soda", and "Pizza" as three new resource types... you could create a "Snacks Container" with different variants for those, and tie them together in config so that when you switch variants in the editor it would automatically configure it to the correct resource type.  See the examples folder on the github repo for how to do this.

Thanks to @theJesuit for the feature suggestion! 

[4x4cheesecake]

@Snark Great update and you didn't even mentioned that you have fixed the missing resources on copied parts

[Snark]

3 minutes ago, 4x4cheesecake said:

@Snark Great update and you didn't even mentioned that you have fixed the missing resources on copied parts

Well, that was fixed in 1.0.2.

[4x4cheesecake]

12 minutes ago, Snark said:

Well, that was fixed in 1.0.2.

Huh? Guess I just downloaded 1.0.2 then and forget to actually install it  

Btw.: Do you plan to put the mod on CKAN or should it be there but the bot messed up while creating the .netkan file?

[Snark]

Just now, 4x4cheesecake said:

should it be there but the bot messed up while creating the .netkan file

Ding ding ding. 

Not being a CKAN user myself, the sum total of my involvement with CKAN is that whenever I create a new mod, I check the little checkbox on SpaceDock that says "do you want to put this on CKAN?"  Past that point it's beyond my ken.

You can tell that I've done this because if you look at the mod's page on SpaceDock, it has a little "CKAN" badge next to the mod's title.

However... apparently SpaceDock doesn't handle this very gracefully (translation: often simply doesn't work), which I have no awareness of until someone like you comes along and asks about it.  At which point @linuxgurugamer usually steps in and fixes it for me because he's nice.    (And also very patient with me, since he keeps very nicely doing this for me in spite of this happening multiple times, including just recently when I created the AttitudeAdjuster mod.)

[theJesuit]

40 minutes ago, Snark said:

Thanks to @theJesuit for the feature suggestion! 

You're welcome. Great and awesome job!  This is such a useful addition.  

Peace.

[linuxgurugamer]

2 hours ago, Snark said:

Ding ding ding. 

Not being a CKAN user myself, the sum total of my involvement with CKAN is that whenever I create a new mod, I check the little checkbox on SpaceDock that says "do you want to put this on CKAN?"  Past that point it's beyond my ken.

You can tell that I've done this because if you look at the mod's page on SpaceDock, it has a little "CKAN" badge next to the mod's title.

However... apparently SpaceDock doesn't handle this very gracefully (translation: often simply doesn't work), which I have no awareness of until someone like you comes along and asks about it.  At which point @linuxgurugamer usually steps in and fixes it for me because he's nice.    (And also very patient with me, since he keeps very nicely doing this for me in spite of this happening multiple times, including just recently when I created the AttitudeAdjuster mod.)

Ta da!!!!!!

All done

[4x4cheesecake]

Took me some time to find the correct syntax, but I finally managed to make my config working along the default config
Well, to be more precise: I'll undo the changes made by the default config. This will work even if more parts are added and everything should work fine, regardless if the default config is present or got removed.

Installation
You can install my config like every other mod: just extract the content of the .zip file into your KSP install directory. This will merge my config folder into the mod folder.

Configuration
Open the config.cfg, located in 'GameData/SimpleFuelSwitch/configs/Alternative Config/'. This file contains a list of every (stock) fuel tank type and available fuel types. To add a fuel type to a tank, the corresponding entry must be set to 'true'. If you want to remove a fuel type, set the value to 'false' instead. By default, everything is set to 'true'. Do not remove or comment any of these entries!

Affected parts
So far, every tank which contains any stock fuel will be affected, except for:

• Engines
• Air intakes
• Command Pods

What's not possible
You cannot remove the 'default fuel'. For example: A xenon tank will always carry xenon and, if you want so, some other fuel but it is not possible to put just LFO in it.

Known issues
So far, I'm not aware of any issues but I've just tried my config on stock parts. It is possible that mod parts will behave differently.

Have fun

Download: https://www.dropbox.com/s/cil42bwhp4eyd25/[SFS]cheesecakes_alternative_config.zip?dl=0

[RealKerbal3x]

@Snark Yeah! This opens up a lot of possibilities!

Including one I’ve been thinking about ever since SQUAD teased the Terrier revamp. The ‘Shrouded’ variant for that part looks a lot like Porkjet’s revamp, which had a small amount of LFO storage. So I was wondering if it would be possible, using Simple Fuel Switch, to give the Terrier a small amount of fuel storage, but only when it’s on the shrouded variant. If it was on the Truss Mount or Bare variants, then there would be no fuel.

Just wondering if this would be possible or not.

(By the way, I already posted a thread about this very topic, but now that SFS allows linking fuel switching to part variants, I decided that this would be the best place to enquire about this).

[4x4cheesecake]

1 hour ago, RealKerbal3x said:

Just wondering if this would be possible or not

Yes and no.

Yes, you can add a small amount of LFO to the shrouded variant of the terrier but not just the shrouded variant, but the fuel will be available for other variants as well. Linking the variants to different fuel types works perfectly fine but as soon as you switch to a variant with no fuel, the part will still use the previously added fuel.
In the first moment, I thought that this is an intended behaviour since the mod is designed for switching fuels and not to remove them but since the examples of @Snark contain also custom resources, it's possible that's a bug.
I haven't tried it yet (and cannot try it until this evening) but I guess, as soon as you switch to a variant with no linked resource, it should switch back to the default resource. Since the engine does not carry any fuel on default, there is just no function to remove the previously added resource. But these are just a few assumptions

[Snark]

11 hours ago, RealKerbal3x said:

Including one I’ve been thinking about ever since SQUAD teased the Terrier revamp. The ‘Shrouded’ variant for that part looks a lot like Porkjet’s revamp, which had a small amount of LFO storage. So I was wondering if it would be possible, using Simple Fuel Switch, to give the Terrier a small amount of fuel storage, but only when it’s on the shrouded variant. If it was on the Truss Mount or Bare variants, then there would be no fuel.

Just wondering if this would be possible or not.

Hey, nice idea!    That's a great use case, I hadn't thought of that one.

It absolutely ought to be possible-- I see no reason why the mod shouldn't be able to support that.  I went just now to check whether it's already possible... and it almost is.  However, there are a few spots in the code where I just assume (because I didn't really think about it) that a selectable option will always have at least one resource in it, with the result (on SimpleFuelSwitch's current version, 1.1) that if you try to configure this, the code barfs in a few places.

(It's currently possible, I think, to set it up so that they all have different kinds of fuel, or that they all have the same kind of fuel but different capacities.  But it's not possible to make it so that one variant has fuel and the others don't have it at all.)

The good news, though, is that they're not hard to fix-- there's no reason that the design can't handle that, it's just the case that there are a few spots where it doesn't handle the zero-resources case but could easily be made to do so.

So, I'll take this under advisement-- shouldn't be too hard to produce a version 1.1.1 that would enable this scenario.  No promises about ETA, since I've got IRL stuff going on too ... but yeah, this is a good idea, I'll make this happen when I can.

Thanks for the idea!