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

[Shadowmage]

8 hours ago, MaxZhao said:

Hi! @Shadowmage In the process of making patches for the class-E shuttle I realised that there aren't any decouplers especially made for the shuttle? I'm not sure if the booster decoupler was supposed to be used for the external tank, if so, I think it would be better if crossfeed can be allowed on it since a fuel duct would be needed otherwise. 

best regards

Yes, I use the RBDC for the shuttle external tank.  And also for the SRBs attached to the tank.  And yes, I use manual fuel lines; there was some sort of bug with crossfeed back when I setup those parts, no clue if it is still present or not (actually I think toggle-able crossfeed wasn't even a thing back then).

If you add crossfeed to the RBDC part are there any negative side effects in other uses of the part/craft designs?

[ComatoseJedi]

34 minutes ago, Shadowmage said:

If you add crossfeed to the RBDC part are there any negative side effects in other uses of the part/craft designs?

I've been wondering the same thing. I know if you add a reaction wheel to this part, it doesn't work. But, that was in 1.1.2/3. I don't see why it shouldn't work? Things that make you go hmmmm. 

-Update-

Upon looking at the RBDC config file, there's already a fuelCrossFeed configuration that's set to false. Maybe that was done as a reason? 

Edited April 28, 2017 by ComatoseJedi

[Shadowmage]

1 hour ago, ComatoseJedi said:

I've been wondering the same thing. I know if you add a reaction wheel to this part, it doesn't work. But, that was in 1.1.2/3. I don't see why it shouldn't work? Things that make you go hmmmm. 

-Update-

Upon looking at the RBDC config file, there's already a fuelCrossFeed configuration that's set to false. Maybe that was done as a reason? 

That field controls 'full time' crossfeed.

What needs to be tested is the ModuleCrossfeedEnabler (or whatever it is called), the stock module that allows for in-editor (and in flight?) crossfeed toggling.

[ComatoseJedi]

55 minutes ago, Shadowmage said:

What needs to be tested is the ModuleCrossfeedEnabler (or whatever it is called), the stock module that allows for in-editor (and in flight?) crossfeed toggling.

The stock module for this is ModuleToggleCrossfeed example from the stock TR-38-D

MODULE
    {
        name = ModuleToggleCrossfeed
        crossfeedStatus = false
        toggleEditor = true
        toggleFlight = true
    }

Trying it out now.  

*Update*

I added the ModuleToggleCrossfeed to the core RBDC file config. It gave the toggle for cross feeding, but using it on the Series E Fuselage resulted in a no go for a -pull- for the engines to use. So, I looked into the SC-E-FS config file and set the fuelCrossFeed=True. This allowed for cross feeding for use with the radial de-coupler and the E shuttle fuselage. Would you like me to put in a pull request on the GH for these features/changes @Shadowmage ? 

Edited April 28, 2017 by ComatoseJedi

[CVerts]

On 4/25/2017 at 7:10 AM, Shadowmage said:

This isn't really a 'modpack', but more of a single really large mod.  Due to the use of texture and mesh/model sharing across many of the parts it is extremely difficult to have a clean separation between the different series' of parts.  For example many of the engine models and textures are re-used in the various ShipCore part-series, as are the RCS blocks and docking ports.

If you have a specific list of parts that you do want to keep I can probably give you a quick write-up of what all would be safe to delete/remove.

I haven't really thought about which parts to remove in my 'Near Future' install. Maybe others beside the engines and cores and Series C? I would like to suggest an option for people to install a 'core' and install the other series as this would benefit a lot for those who wants specific parts or have a lower performance computer.

Edited April 29, 2017 by CVerts
Accidental multi-post.

[Shadowmage]

19 hours ago, ComatoseJedi said:

I added the ModuleToggleCrossfeed to the core RBDC file config. It gave the toggle for cross feeding, but using it on the Series E Fuselage resulted in a no go for a -pull- for the engines to use. So, I looked into the SC-E-FS config file and set the fuelCrossFeed=True. This allowed for cross feeding for use with the radial de-coupler and the E shuttle fuselage. Would you like me to put in a pull request on the GH for these features/changes @Shadowmage ? 

Yes, please (to pull-request).  As long as it is working appropriately and the crossfeed toggle works on it still, then it sounds good to me.  If you can, make the PR vs. the 'coloredAdapters' branch; will make it a bit easier to merge into the current dev stuff (but other branches as base should work as well, don't think I've touched the SC-E or RBDC files in the dev stuff).

[ComatoseJedi]

1 hour ago, Shadowmage said:

Yes, please (to pull-request).  As long as it is working appropriately and the crossfeed toggle works on it still, then it sounds good to me.  If you can, make the PR vs. the 'coloredAdapters' branch; will make it a bit easier to merge into the current dev stuff (but other branches as base should work as well, don't think I've touched the SC-E or RBDC files in the dev stuff).

Yeah, I can tell you haven't touched the SC-E files in a while, because your fuel gen is still running off of monopropellant, LOL. But, I will get on it now. I haven't made a pull request before, but I think I can muddle my way through it. 

*Edit*

Sorry for dinging everyone's GitHub email address a million times. Figuring out how to make a pull request. But, I think I did it now. Thanks for not shooting me. BanG BanG. 

Edited April 29, 2017 by ComatoseJedi

[Shadowmage]

Recoloring now has user-selectable specular control on masked portions of the texture; everything from super-shiny, to dull/matte:

 

3 hours ago, ComatoseJedi said:

Yeah, I can tell you haven't touched the SC-E files in a while, because your fuel gen is still running off of monopropellant, LOL. But, I will get on it now. I haven't made a pull request before, but I think I can muddle my way through it. 

*Edit*

Sorry for dinging everyone's GitHub email address a million times. Figuring out how to make a pull request. But, I think I did it now. Thanks for not shooting me. BanG BanG. 

No worries, and thanks for submitting it.  Should be able to get it worked into the dev versions shortly.

[ComatoseJedi]

1 hour ago, Shadowmage said:

No worries, and thanks for submitting it.  Should be able to get it worked into the dev versions shortly.

yeah, it's a small, minute contribution considering the huge amount of coding that went into the mod. But, it seemed simple enough to make happen. I will look into if there are any problems with making cross feed true on the SC-E-FS/FSX parts (It shouldn't, but doesn't hurt to test). 

[N3N]

Hey Shadowmage,

I'm currently trying to build a big space station and a spacecraft for longer travels and this mod (and its add-ons) is perfect for this. Thanks!

 

On 28.8.2016 at 5:35 PM, Shadowmage said:

Couple other points:

I will be using RocketParts as the construction resource for a base install, switching to MaterialKits/etc if UKS is installed.

Will be adding RocketParts/etc as resources to all MFT tanks so that they may be shipped/launched to the stations.  In the future I will be making custom container-style parts for 'dry' resources, but for now the tanks should be sufficient.

Initial balance for kit-out mass will be 20%/80% for all parts.  This will be adjusted/updated on a per-part basis in the future.

 

My Question is, if there is yet a possibility to change from RocketParts to the MKS resources, because I have installed all USI mods and his LS, but not EL.

 

 

 

Sorry for my english, but it's only my third language.

 

[Shadowmage]

11 hours ago, N3N said:

My Question is, if there is yet a possibility to change from RocketParts to the MKS resources, because I have installed all USI mods and his LS, but not EL.

Not currently available as a built-in; but you could try to make a patch for it yourself.

Should be something as simple as:

@PART[*]:HAS[@MODULE[SSTUInflatable]]:AFTER[SSTU]
{
	@resourceName = MaterialKits
	@inflationCost *= 1.33333
}

(Warning:  Untested....)

[tater]

The specular mask control looks pretty incredible, BTW.

[N3N]

11 hours ago, Shadowmage said:

Not currently available as a built-in; but you could try to make a patch for it yourself.

Should be something as simple as:

@PART[*]:HAS[@MODULE[SSTUInflatable]]:AFTER[SSTU]
{
	@resourceName = MaterialKits
	@inflationCost *= 1.33333
}

(Warning:  Untested....)

 

Hey Shadowmage,

Thank you!

 

If I understand this right, it changes "RocketParts" to "MaterialKits" and set the cost to inflate it 1,33333x higher than before.

Is this right? (I'm just learning about MM patches)

[Kerbal01]

engines have stopped gimbaling.

Mods: SSTU. RP-Stock

Log: https://www.dropbox.com/s/3rj2rv3zy7yvj70/KSP.log?dl=0

[Shadowmage]

4 minutes ago, DarthVader said:

engines have stopped gimbaling.

Mods: SSTU. RP-Stock

Log: https://www.dropbox.com/s/3rj2rv3zy7yvj70/KSP.log?dl=0

Whatever it is, it is a problem with one of your mods or your particular install/setup.

Try removing mods one at a time until the problem goes away.  Or start with a fresh install and add mods one at a time until the problem manifests.

Unless/until you can tell me which mod it is, there is nothing that I can do.

[Kerbal01]

Reinstalling everything fixed it.

[Shadowmage]

General development updates:

Work on the recoloring system is coming along well.  Most models+textures that will have recoloring support have been converted.  Should be finishing of the rest of the engine-mount masks and textures this evening.  Many of the engine mounts have had minor UV layout changes to allow for a few additional texture patterns/layouts.  All recolorable parts will have at least two masks / patterns / texture-sets, with many having quite a few more (tanks have > 10).  The old/existing color and pattern schemes should be able to be replicated with the new layouts, with most parts defaulting to a mask+color set equivalent to the old defaults. 

Up next will be working on converting the MUS models and textures to the new system.  Hoping to get the MUS models to use the same texture sheets as the rest of the MFT tank models, but they may still end up using their own textures.  Will also be breaking the model up a bit to allow for the top-cap / dome to be a modular adapter type.  Looking to also include a set of ICPS/HUS-style 'foam' domes/caps (probably ripped right from the HUS model+textures), for use on both the MUS and the rest of the MFTs.

If anyone is interested in giving the recolorable-parts-system a bit of a test-drive, send me a PM and we can work out the details (still doing dev on KSP 1.2.2).  Quite a few things in the dev version are....unstable.... so it is not ready for widespread/general testing yet, but quite a bit of it is usable enough for some feedback on the recoloring-system basics (and for creation of promo materials in prep for the next release).

[martinezfg11]

That recoloring system is awesome!!! I haven't checked your GitHub but will it's use be documented there? 

[Shadowmage]

9 minutes ago, martinezfg11 said:

That recoloring system is awesome!!! I haven't checked your GitHub but will it's use be documented there? 

Probably not initially.  It is pretty simple and straightforward to use though, even in its current rough prototype implementation.  I'll probably put together some quick-and-dirty instructions for it once I get the UI finalized; a bit too early to work on it right now though.

As the mod progresses towards the 1.0 version I plan on putting together full documentation of all of the systems, likely publish it as a .pdf to go along with the mod releases.  Still at least several months away though; only up to version 0.5 (current) -> 0.6 (upcoming releases), and already have several existing systems and parts that will be replaced or see major changes between now and 1.0.

[Shadowmage]

Quick question on preferred GUI setup for part-recoloring; options include:

1. Single GUI for entire vessel, with a list of all recolorable parts for the craft.  Launched from a button on the stock app-launcher.  Button on the GUI to highlight which part each GUI entry corresponds to.  This is the current setup for the dev GUI.  It works, but can be a bit difficult to locate the exact part that you want to recolor, especially on craft with lots of parts (many of which may have up to 3 GUI entries each).  On smaller craft it is nice to be able to recolor the entire craft from a single GUI, but quickly grows difficult to use with addition of more parts.
2. Per-part/module GUI controls from the stock part right-click menu.  Ideally it would only add a single button per part ('Recolor Part'), that would open a GUI showing each section for the part (up to 3 sections are used on the MFT parts).  Main downside is the extra buttons on the right-click menu, some of which are already quite busy.
3. Hotkey to open the recolor GUI for the part currently under the cursor.  I really like this system, except for the inherent conflict that mod added hotkeys bring.  Hotkey can be made configurable, but conflicts will still arise given a large enough pool of mods installed and using hotkeys.  As per #2, this GUI would only show recoloring options for the currently selected part.  No additional per-tick overhead as the input-handling can be added to existing classes that already have per-update/frame methods.

[blowfish]

#2 makes the most sense to me.  Key shortcuts can be handy but as you mention the chances of a conflict are high.  They're also harder for new players to find.

[rasta013]

I love the idea of #3 but I completely understand the hesitation in introducing something that is likely going to result in support requests.  With this in mind I favor #1.  Even though the part list may be extensive the nightmare of recoloring by having to select each individual part and hunt down each button on each part is worse.  With #1, would it be possible to use part highlighting to identify which part is being targeted as you scroll over the list? That bit would make identifying the part you're working on easier for large craft and keep us from having to constantly hunt down buttons in complicated lists.  

This could even be easier if the part list was able to be sorted by name (not necessary but a consideration maybe).  Just spit balling a bit here...

[ComatoseJedi]

I am in favor of #1, too. When you look at the vessel as a whole and the intention of the mod to have a lower part count. The idea of overwhelming part count for a GUI based as #1 suggests wouldn't be as bad as it would seem. But, also with that said, I don't see a problem with the color/texture system that's there now, unless you are looking for a simpler way to change textures with the parts. If you know me, I'm a "If it ain't broke, don't fix it" sorta guy. But, the specular work is spectacular. I love that, long time... you party? lol. 

[Rocketology]

@Shadowmage Seriously, epic mod! The tweakable parts design is ingenious, I think Squad would be wise to take notice! As many mods as I use regularly, I am surprised I have not run across this gem before now.

@Akira_R Thank you for the .cfg for SMURFF! All I needed to do was lower the thrust multiplier a bit and it and it nails realish values for my 10.6X GPP career.

[blowfish]

Had a chance to mess with the dev version a bit tonight and I can say that I'm still firmly for #2, maybe even moreso.  With even a moderate number of recolorable parts on the vessel, the whole vessel list quickly becomes challenging to navigate, or to even remember where you are when you're trying to recolor just one part.