[WIP][1.8.x] SSTULabs - Low Part Count Solutions (Orbiters, Landers, Lifters) - Dev Thread [11-18-18]

[Sudragon]

will KIS/KAS storage be an option?

[tater]

31 minutes ago, Sudragon said:

will KIS/KAS storage be an option?

Literally two posts up, shadowmage said:

Quote

yes I will be figuring out a way to enable KIS storage to be seen as a resource type if it is installed).

Helps to read the mod dev's posts (particularly mage's as he's amazingly transparent about what's going on... reading this thread is an interesting insight into the process).

[Sudragon]

Dang it. my bad.

[blowfish]

@Shadowmage I like having choices, but I've found the MFT/RF tank interface to be quite difficult to work with, so much so that if I actually want to split the tank, I usually end up with separate parts (thus kinda defeating the purpose).  Are there any simplifications that could be made?  I do have a couple of suggestions there:

• Create a global or per-tank resource whitelist to limit the number of options you actually see.  CRP has quite a lot of resources, and I don't really see the use case for filling a fuel tank with dirt .  I think not having to scroll to adjust the common options is critical.
• Make the common fuel mixtures into actual switchable options.  I know that this complicates determining the correct resource amounts ever so slightly, but I think it would improve usability a lot.  What if I have a tank that's 90% LFO and 10% Monopropellant, and I want to just it to 95%/5%.  Do I need to carefully adjust the LF and O options individually to fill the difference in space?

And I apologize in advance, because this is probably going to come off the wrong way, but could you justify to me again why such a complicated switching system is necessary?  I know that adding fuel options makes fuel switching a bit more complex, but I fail to see the use case for splitting tanks arbitrarily.  The primary fuel/rcs/battery split on the SSTU parts is already pretty good, and UI_ChooseOption actually makes switching a large number of options quite easy and usable.

[JoseEduardo]

in MFT/RF/RO you literally need to put a engine under a tank, then right click on the tank and click a button to auto-fill, I fail to see why it is complicated... the only complicated parts I see are the realism parts (ullage, ignitions, locked thrust etc... which mage said he wouldn't include) and the GUI if you want to put anything other than fuel for the engines (although it is pretty easy to get used to)

even if you want to split as in your example, 95% LFO and 5% Mono, you can set in the GUI the 5% mono manually (math needed) and then right click on the tank to fill the remainder 95% volume with LFO

I do however think that if the GUI allows for setting a percentage and a specific value that would be pretty neat, like, I could set manually 1k MMH and 1k NTO, or set it automatically to 2, 5, 10, 17 or 25% of the tank volume for MMH and NTO

EDIT: now that I looked closer at the pic (my monitor is 2m away from my face) I see that the percentage option is already there, sweet (but a option for a specific ammount could be useful )

Edited April 15, 2016 by JoseEduardo

[Shadowmage]

8 hours ago, blowfish said:

@Shadowmage I like having choices, but I've found the MFT/RF tank interface to be quite difficult to work with, so much so that if I actually want to split the tank, I usually end up with separate parts (thus kinda defeating the purpose).  Are there any simplifications that could be made?  I do have a couple of suggestions there:

• Create a global or per-tank resource whitelist to limit the number of options you actually see.  CRP has quite a lot of resources, and I don't really see the use case for filling a fuel tank with dirt .  I think not having to scroll to adjust the common options is critical.
• Make the common fuel mixtures into actual switchable options.  I know that this complicates determining the correct resource amounts ever so slightly, but I think it would improve usability a lot.  What if I have a tank that's 90% LFO and 10% Monopropellant, and I want to just it to 95%/5%.  Do I need to carefully adjust the LF and O options individually to fill the difference in space?

And I apologize in advance, because this is probably going to come off the wrong way, but could you justify to me again why such a complicated switching system is necessary?  I know that adding fuel options makes fuel switching a bit more complex, but I fail to see the use case for splitting tanks arbitrarily.  The primary fuel/rcs/battery split on the SSTU parts is already pretty good, and UI_ChooseOption actually makes switching a large number of options quite easy and usable.

1.)  Resources available in any specific part will be able to be setup in any number of ways;  you can add specific resources at the config level, or add entire sets of resources at the config level, or specify it as 'generic' where it will have access to all pumpable resources.  So if a specific container might be intended for 'dry' goods only this will be doable.  There will be pre-configured 'resource sets' that cover the majority of cases (dry goods, fuels, liquids, construction stuff?); these are mostly intended as a convenience when setting up a part with many potential resources.

2.)  Yep, already done (or planned).  See the screenshot on the last page; that is what those fuel type buttons are for.  Only..you can also combine them/customize them.  Want an LFO mix..but then a bit of MP and EC?  simple... press the LFO button and then slide the MP and EC sliders a bit.  Want to pre-fill with proper ratios of TAC-LS supplies?  Simply press the 'TAC-LS' button (or whatever it ends up being called).  Also want some MP in that tank?  Press the MP button (or slide the MP slider); your TAC-LS ratios will not be disturbed.  New fuel types can be added through config nodes and will automatically be added to the GUI for parts where those fuel types are applicable (e.g. their potential resource list contains all resources for the fuel type).

3.) It will all be ratio based, so the ratio for an LFO preset will not be changed when you add/remove other resources using the sliders or ratio input boxes.  I wan't to figure out a way so that you can just use the buttons to increase the proportional ratio between various preset types.  Want a 75% HLOX mix and 25% LFO mix?  Hit the LFO button x1, and the HLOX button x3....  and then you can still add some extra EC or MP without disturbing the LFO/HLOX stuff.

4.) The complexity for 95% of uses will be mitigated by still having the basic 'Next Fuel Type' controls on the basic part right-click menu.  All the old 'Fuel Type' stuff is not going away; you'll still be able to simply cycle through pre-setup resource groups for common fuel types.  But if you want to open the GUI to customize things?  Well... now you can (or will be able to).  What is changing is that I'm not going to be making up a thousand different resource groups to cover every potential combination of resources.  So if all you want is a fuel tank... very little will be changing on the UI front; there will just be an extra button at the bottom of the GUI you'll have to ignore (or patch the configs to disable the button)

5.) This allows for a well defined system for splitting up of a part into separate internal containers that might be applicable to different types of fuels.  For example the MUS parts where a certain percentage of volume is intended to be dedicated for MP and EC.  Currently I hack around this with special code in the MUS module... and it is painful to work with and error prone.  Or perhaps you have a cargo craft that has 'dry' and 'wet' storage areas.  Or a Command Pod with a small bit of integrated storage for various supplies.

6.) I did mention KIS integration, right?  Yeah.. no way I'm going to try to code that into every single modular part; but if I have a single module that does the interaction?  That I can likely figure out how setup and deal with.

 

In the end... I'm not doing this for the users.  I'm doing this to save my sanity when trying to setup various 'utility' type containers (e.g. the SC-C-SMX).  I've struggled for three weeks to think up what kind of resource swapping I wanted on it for the default distribution.  No single set of resources would be 'perfect' for every need; nor could I potentially plan out pre-set resource sets that would be perfect for every need;  nor do I even know what my 'needs' are (no clue what mod-set I'll be playing with next or what resources it will use); the only way to do it is to let the user select their resources from -all- of the resources available.  If all I were ever planning on doing was more fuel tanks... the existing system works fine for those.  But I have lots more plans than just fuel tanks.  This also saves me from duplicating all of the resource handling / fuel type handling code in every module that I write, giving me a nice unified interface for all 'modular' parts that deal with resources.  This will be needed with the upcoming module and model-switch enabled parts, and is what is going to enable the LC-POD parts to be added back into the mod.

And as usual, this will all be config driven so you can further customize the presets, fuel types, resource-sets, container types... everything.

 

3 hours ago, JoseEduardo said:

in MFT/RF/RO you literally need to put a engine under a tank, then right click on the tank and click a button to auto-fill, I fail to see why it is complicated... the only complicated parts I see are the realism parts (ullage, ignitions, locked thrust etc... which mage said he wouldn't include) and the GUI if you want to put anything other than fuel for the engines (although it is pretty easy to get used to)

even if you want to split as in your example, 95% LFO and 5% Mono, you can set in the GUI the 5% mono manually (math needed) and then right click on the tank to fill the remainder 95% volume with LFO

I do however think that if the GUI allows for setting a percentage and a specific value that would be pretty neat, like, I could set manually 1k MMH and 1k NTO, or set it automatically to 2, 5, 10, 17 or 25% of the tank volume for MMH and NTO

EDIT: now that I looked closer at the pic (my monitor is 2m away from my face) I see that the percentage option is already there, sweet (but a option for a specific ammount could be useful )

Well, there will be no 'auto fill' button.  You will need to use the 'Fuel Type' buttons (either in the part menu or the resource GUI), which will do the same thing.  I'm not going to mess with trying to figure out what engine it is supposedly attached to (fuel flow logic is fubar'd and I'm not going to try to decipher it), and this feature doesn't make as much sense when there is only a single ratio per fuel type;  I'm not trying to replace or duplicate RF.  This doesn't preclude one being added in the future, but it certainly will not be there for the initial releases.

No, there likely will not be any controls for specific 'units' of fuels.  Or at least I haven't thought of a way to allow that to work with the ratio based setup (would like to have a 'units' input box as well... but unsure how to decompose that back into a ratio cleanly).

[RedParadize]

Sounds good.

I was a bit worry about the new interface. The nice thing about the old one was that it was quick. I could built a SLS style luncher in 5 min. Would have been sad to lose that.

[Shadowmage]

So... the bug with procedural drag-cubes on root parts breaking map mode was fixed.  But now if you update the drag cube for any non-root part it breaks map mode (previously this worked fine).  The fix for one is breaking the other more than likely

Had intended on posting the first 1.1 testing release today, but alas... it is now more broken than it was last week and unusable in this state.  Can't even test things outside of the editor.

Issue is already open and apparently fixed in dev code; so mostly waiting for an updated pre-release build.

Maybe next weekend  
I'll likely have the new resource system in place by then... so timing may work out well.
 

[Shadowmage]

1.1 dev testing version is available for download:

https://github.com/shadowmage45/SSTULabs/releases/tag/0.4.31-pre1

Please read the change log and known issues. 
WARNING: Most resource-containing parts will have breaking changes to them within the next week for the new resource container system; so don't go all gung-ho and think this is a stable release... it is not.

This release requires the KSP-1.1-pre-1215 build (released this-morning); anything earlier and there will be major issues.

There are likely major bugs in many things -- go find em

 

Here is a specific list of things that need tested for functionality:

• TESTING - Verify that career tech-limitations work for all modular/procedural parts
  • MSRB
  • MFT
  • MUS
  • ISDC
  • PDC
  • IPA
  • MHS
• TESTING - Verify that fairings work properly on all fairing enabled parts (many...)
• TESTING - Verify that split-thrust setup engines work in multi-engine clusters (RS-68)
• TESTING - Verify that gimbals work properly on all parts (SC-A/B/C/E)
• TESTING - Need tons more testing and feedback on Modular Heat Shield; please play around with the heat-curves and other parameters in the config... the goal is to balance them for stock heating for a reasonable payload for the size and type of shield being used.
• TESTING - UI controls for all modular/resizable parts.  Do the change selection properly?  Do they maintain selection on vessel/editor reload?  Does everything persist properly across launch/revert/reload scenarios?

[Sudragon]

Its alive!  ITS ALIVE!!!!

[GoldForest]

@Shadowmage Found a bug, idk if it's because of all the mods I have or just your mod, but the side decoupler when right clicked expands to 10m and stays there.

Mods:

http://imgur.com/eV7JP0Q

Edit: Checked the debug menu, I get no errors when placing the part or right clicking it.

 

Edited April 18, 2016 by GoldForest

[GoldForest]

Found another bug, No exhaust or flame for the RS-68 engines. They still produce thrust though.

I am using Realplume and Smokescreen if that's the problem.

[JoseEduardo]

@Shadowmage, remember that hate-mail idea? well, it worked out for us, the lower house has approved the impeachment of dilma and now she'll be sent to the senate to be judged, where it will be even harder to stop

maybe it can work out for ya too

btw, I couldn't test it today because of the event mentioned above (which is still going, but she's already out), so I might test it tomorrow (considering venezuela, bolivia or communist guerrillas doesn't start attacking us, of course... they have threatened, but we'll see if they have the courage...)

[RedParadize]

I opened it up quickly, the orion servise module make funny stuff happen on the lunch pad, I will test it further tomorrow.

Your stuff looks nice on full rez!

[blowfish]

Just a note for everyone, it looks like the way RealPlume is structured doesn't play well with having more than one plume on the same engine, so the engines with separate verniers are incompatible with RealPlume at the moment.  This means the RD-107/8, RD-0110, and RS-68.  I'm going to log an issue in RealPlume's repository and see where it goes. @GoldForest this is (part of) your issue with the RS-68.

[GoldForest]

1 hour ago, blowfish said:

Just a note for everyone, it looks like the way RealPlume is structured doesn't play well with having more than one plume on the same engine, so the engines with separate verniers are incompatible with RealPlume at the moment.  This means the RD-107/8, RD-0110, and RS-68.  I'm going to log an issue in RealPlume's repository and see where it goes. @GoldForest this is (part of) your issue with the RS-68.

Thank you for confirming my issue.

[GoldForest]

@Shadowmage I can't seem to run your mod on my laptop. I have the latest 1.1 build of ksp. The only mods I have on it are ModuleManager and your mod.

Laptop specs:
Windows 8.1 64-bit
AMD A8-4500M APU
6(5.5 useable) GBs of 1600 mhz ram

It loads up until the AJ10-137 engine and then just stops loading, the loading bar not moving off of that AJ10-137. Any insight into this problem?

 

Edited April 18, 2016 by GoldForest

[Theysen]

13 minutes ago, GoldForest said:

@Shadowmage I can't seem to run your mod on my laptop. I have the latest 1.1 build of ksp. The only mods I have on it are ModuleManager and your mod.

Laptop specs:
Windows 8.1 64-bit
AMD A8-4500M APU
6(5.5 useable) GBs of 1600 mhz ram

It loads up until the AJ10-137 engine and then just stops loading, the loading bar not moving off of that AJ10-137. Any insight into this problem?

 

Make sure to drop CommunityResourcePack in, I thought Shadowmage bundled it but the latest download doesn't seem to include it. CommunityResorcePack is needed to make the LH2 engines work. 

 

[GoldForest]

16 minutes ago, Theysen said:

Make sure to drop CommunityResourcePack in, I thought Shadowmage bundled it but the latest download doesn't seem to include it. CommunityResorcePack is needed to make the LH2 engines work. 

 

That was it, thank you!

[Shadowmage]

Heads up / reminder;

Bug reports belong here:

https://github.com/shadowmage45/SSTULabs/issues

I cannot keep track of them in the forums, they will be lost and forgotten about if not posted on the issue tracker.  Include log files for anything that isn't a basic spelling/typo/texture problem... logs will be needed to track down the problem.  Take note of the exact steps needed to duplicate the problem and include those in your bug report.  If the problem only occurs with other mods' installed, include that information as well.

Also another general reminder:  KSP build 1209 broke nearly every plugin for most mods -- so make SURE that if you are reporting an issue it is not caused by another mods' broken plugin.

[Shadowmage]

14 hours ago, JoseEduardo said:

@Shadowmage, remember that hate-mail idea? well, it worked out for us, the lower house has approved the impeachment of dilma and now she'll be sent to the senate to be judged, where it will be even harder to stop

maybe it can work out for ya too

btw, I couldn't test it today because of the event mentioned above (which is still going, but she's already out), so I might test it tomorrow (considering venezuela, bolivia or communist guerrillas doesn't start attacking us, of course... they have threatened, but we'll see if they have the courage...)

LoL, glad it is working out for someone

No worries on the testing stuff; whenever you have time.  Still have a few weeks before I think it'll be ready for anything serious.

 

12 hours ago, RedParadize said:

I opened it up quickly, the orion servise module make funny stuff happen on the lunch pad, I will test it further tomorrow.

Your stuff looks nice on full rez!

Re: SM issues -- please make sure there are no other broken mods causing problems.  If the issue still persists with just SSTU+Stock, please open a bug report with logs (logs mandatory for that kind of a problem).

 

7 hours ago, Theysen said:

Make sure to drop CommunityResourcePack in, I thought Shadowmage bundled it but the latest download doesn't seem to include it. CommunityResorcePack is needed to make the LH2 engines work. 

 

 

Hmm... strange.... though I had bundled it all up... but perhaps I missed some things (or just fubard' my build script).  If CRP is indeed not present in the .zip file from yesterday, please open a bug report so that I don't forget it for the next release

 

[CobaltWolf]

10 hours ago, blowfish said:

Just a note for everyone, it looks like the way RealPlume is structured doesn't play well with having more than one plume on the same engine, so the engines with separate verniers are incompatible with RealPlume at the moment.  This means the RD-107/8, RD-0110, and RS-68.  I'm going to log an issue in RealPlume's repository and see where it goes. @GoldForest this is (part of) your issue with the RS-68.

@VenomousRequiem, @Jso and I were able to get multiple plumes working on BDB engines. @Shadowmage I've never actually installed your mod, does it use a propriety engine module or do you still use a stock one? For the MM patch you need to use the selections system to select and modify each individual ModuleEngineFX.

[VenomousRequiem]

11 hours ago, blowfish said:

Just a note for everyone, it looks like the way RealPlume is structured doesn't play well with having more than one plume on the same engine, so the engines with separate verniers are incompatible with RealPlume at the moment.  This means the RD-107/8, RD-0110, and RS-68.  I'm going to log an issue in RealPlume's repository and see where it goes. @GoldForest this is (part of) your issue with the RS-68.

 

1 minute ago, CobaltWolf said:

@VenomousRequiem, @Jso and I were able to get multiple plumes working on BDB engines. @Shadowmage I've never actually installed your mod, does it use a propriety engine module or do you still use a stock one? For the MM patch you need to use the selections system to select and modify each individual ModuleEngineFX.

Oh, yeah, there are several engines in BDB with separate verniers. 

 

@PART[bluedog_LR91_mod1]:NEEDS[RealPlume,SmokeScreen]
{
	@MODULE[ModuleEngines*]:HAS[#thrustVectorTransformName[thrustTransform]]
	{
		@name = ModuleEnginesFX
		%powerEffectName = Kerolox-Upper
	}
    PLUME
    {
        name = Kerolox-Upper
        transformName = thrustTransform
        localRotation = 0,0,0
        localPosition = 0,0,0
        plumePosition = 0,0,0.9
        flarePosition = 0,0,0.9
        fixedScale = 0.75
        energy = 1
        speed = 1
    }
	@MODULE[ModuleEngines*]:HAS[#thrustVectorTransformName[VernierTransform]]
	{
		@name = ModuleEnginesFX
		%powerEffectName = Kerolox-Vernier
	}
	    PLUME
    {
        name = Kerolox-Vernier
        transformName = VernierTransform
        localRotation = 0,0,0
        localPosition = 0,0,0.1
        fixedScale = 1
        energy = 1
        speed = 1
    }
}

Here's a good example of how it's executed.

[blowfish]

2 minutes ago, CobaltWolf said:

@VenomousRequiem, @Jso and I were able to get multiple plumes working on BDB engines. @Shadowmage I've never actually installed your mod, does it use a propriety engine module or do you still use a stock one? For the MM patch you need to use the selections system to select and modify each individual ModuleEngineFX.

It works fine with multiple engine modules (assuming they're using different plumes), the problem is that now it's one engine module.  I did find a workaround though, and also added an issue in RealPlume's repository (will see where that goes)

[GoldForest]

*Sighs* The mod is broken thanks to build 1224.