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

[01010101lzy]

On 2015/12/21 at 3:46 AM, Shadowmage said:

You are more than welcome to include this in your personal games; but no, I am not going to offset the COM laterally.

Including an in-flight COM change - possibly, but not for months.  Have too much to work on already.

Also note, the CMX pods are -not- intended to be used for re-entry.  They have no parachutes, no heat-shield, and no regular CoP/CoL offset; they are intended more for orbital freighters/tugs/busses and long-term missions that do not require atmospheric entry/re-entry.

Oh, wrong for the CMX one, but I just didn't recognize its use. THX.

--

One more thing, the 3.75m pod(I couldn't remember the name) may actually need 1800 Ablator instead of 800.

Edited December 24, 2015 by 01010101lzy

[Shadowmage]

So, for real-plumes (and RO/etc):

change the engine-cluster creation patches to the following starting line (really, just add the :FOR[SSTU_ENGINES] at the end) (i will be doing this with the next release for all engines):

+PART[SSTU_ShipCore_ENG-F1]:NEEDS[SSTU]:FOR[SSTU_ENGINES]

and then your real-plumes patch should be such as:

@PART[SSTU_ShipCore_ENG-F1]:FOR[SSTU_ENGINES]:NEEDS[RealPlume]:BEFORE[SSTU_ENGINES]:BEFORE[RealPlume]
{
    PLUME
    {
        name = Kerolox-Lower
        transformName = F1-ThrustTransform
        localRotation = 0,0,0
        localPosition = 0,0,2.5
        fixedScale = 1.4
        energy = 1
        speed = 1
    }
	@MODULE[ModuleEngines*]
	{
        %powerEffectName = Kerolox-Lower
	}
}

results in:

Note the :BEFORE[SSTU_ENGINES] and :BEFORE[RealPlume]  notations; without either of these it did not work properly (had stock effects, or had stock+realplume), you need both of the BEFORE blocks to ensure proper ordering  (the FOR[SSTU_ENGINES] should actually be a NEEDS... but w/e.. it works, and should work either way).

Setting it up for RO should be a very similar process.

@stratochief66

In addition, I have fixed up the incompatibilities with the deployable engines (I hope), so that they can now use the standard ModuleEnginesFX based patches.  This too will be available with the next update (likely saturday or so).  The animation control is now an external module, and will work with any ModuleEngines-derived or subclassed modules (including ModuleEnginesFX, etc).  It now works by simply turning off the engine-modules action groups/gui stuff in favor of its own, which it then routes back through the engine interface methods after deployment/etc.

 

 

[Shadowmage]

19 hours ago, lynwoodm said:

Okay, from the looks of things, everything seems to be in working order. Deployment altitudes are configurable in flight. The chute safety indicator seems to be working as intended. The engine bell warmed up to a nice red glow when hot, a little less red than most of the engines you have (then again i was in the sunlight), but it was real enough to know it was hot, so tuning it down isn't really necessary, at least not on my computer. The only real issue is the staging of the parachute. It -says- it's staged, but it doesn't show it's staged on the stage list icons. I don't know if that's intentional, a minor thing or something that comes with the territory on modifications such as this. 

Another thing that caught my attention is that you have two control options in the gui on the a series pod. I know you were going for a one piece system on this, but couldn't you put a difference in control, like "control from command module" and "control from docking port" to tell the difference? It may of been a silly request, but that's all I seen. But, as far as the parachutes, they work great and nice coloring on the pod chute. that red/olive drab is awesome! Drogues and chutes work as intended. If there's anything I missed, I'm sure Jim will pick it up lol. 

EDIT: The parachute module shows staging and is configurable in the bay and in flight, sorry forgot to mention that. 

 

Thanks for the thorough testing  

Staging icons - nope, I'm not touching the icon for the pod-integrated parachutes -- standalone chutes (rather the docking port/chute combo items) will have the parachute icon and should likely update for staging properly (dunno, that is all stock code)... though probably will still just be a plain white icon.

The 'Control From Here' stuff is part of stock modules, and is not under my control.  One is added by ModuleCommand, the other added by ModuleDockingPort, neither of which have config controls for naming that function.

[Shadowmage]

14 hours ago, 01010101lzy said:

One more thing, the 3.75m pod(I couldn't remember the name) may actually need 1800 Ablator instead of 800.

Its far more likely that it just hasn't been rebalanced yet for the new heat-shield module (as was noted in the change-logs).  It will receive its rebalance when the pod is redone (so, possibly this next update; 0.3.25).  With the default settings it is probably burning off ablator too fast to begin with (staying too cool), which results in a much higher temp delta and higher incoming flux, thus continued higher ablator usage for less overall heat dissipation (basically less efficiency).

[Jimbodiah]

Thanks for the x-mas present Mage!!!!   Happy holidays!

[ComatoseJedi]

48 minutes ago, Shadowmage said:

 

Thanks for the thorough testing  

Staging icons - nope, I'm not touching the icon for the pod-integrated parachutes -- standalone chutes (rather the docking port/chute combo items) will have the parachute icon and should likely update for staging properly (dunno, that is all stock code)... though probably will still just be a plain white icon.

The 'Control From Here' stuff is part of stock modules, and is not under my control.  One is added by ModuleCommand, the other added by ModuleDockingPort, neither of which have config controls for naming that function.

Okay, just touching all bases just in case something was missed. Yes, the icon for the stand alone chutes did show staging, but the pod stuff I didn't know the internal details. Other than that, everything seems to be in working order, unless you want some more testing on other systems. 

Just to add on the Orion's heat shield, I've not noticed any huge loss during re-entry with stock physics. And, I've done many re-entries with this pod under all kinds of speed and trajectory entry angles. Could Deadly Re-entry mod be a cause for the greater loss of heat shield?

[Shadowmage]

Updated testing pre-release is available:

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

Lots of new parts, lots of old parts marked deprecated, totally reworked parachute module (works much better, easier to code in), and several other general fixes. 

Sorry, no SC-B-CM/SM/BPC yet, but I have all of the precursor stuff done now, so nothing else standing in the way.  SM/BPC are pretty much done being reworked, but waiting on finishing of the CM so I can release them all as a group.  CM is being completely redone and not just reworked, so is going to take a bit longer.

I've decided I'll be merely marking the old/existing parts as deprecated -- the new stuff will be completely new parts, so you will need to convert old craft to use the new ones.  It means you can also keep the old ones around for personal use if you wanted (though obviously, unsupported).

[01010101lzy]

One more thing, may I use your plugins in my own mod (and or and not redistribute it)?

If I can, how should I redistribute it and where (in GameData) should the plugin be placed to avoid conflict with other versions of it?

If not, ....

Edited December 27, 2015 by 01010101lzy

[ComatoseJedi]

Good job on those RCS blocks and docking port. They look like they took a lot of time to model. So far no complaints or anything visibly a problem. I haven't tested the docking cam yet, but I will soon. Trying to figure out how to use Blender/Unity and coming along as fast as an old fart can do it. Going through all these tutorials on how to do things not even knowing if it's current information, which will all change anyways when 1.1 comes out. Trying to find out how to add "greeble" to things so it looks more space-like. 

[Atlas2342]

Saw this on the forums today and i absolutely love this mod. Great job guys...

[Jimbodiah]

The AJ-190 looks nice!!!

[drtedastro]

I just wanted to stop by and say how nice the entry video looks.  Nice job.

And of course, the parts pack is great.  

Great work.

Cheers.

[Shadowmage]

13 hours ago, 01010101lzy said:

One more thing, may I use your plugins in my own mod (and or and not redistribute it)?

If I can, how should I redistribute it and where (in GameData) should the plugin be placed to avoid conflict with other versions of it?

If not, ....

Yes, you are free to use and redistrubute them, under the terms of the licenses as posted in the OP -- for the source/plugins, that would be GPL 3.0.

Folder layout should be the same as it is for my distributions;  plugin should be in GameData/SSTU/Plugins/SSTUTools.dll

Let me know if you run into any issues/had any further questions.

 

3 hours ago, drtedastro said:

I just wanted to stop by and say how nice the entry video looks.  Nice job.

And of course, the parts pack is great.  

Great work.

Cheers.

Be sure to give MrMeeb a like / follow on his video page then, as he is the author of the vid.  I'm sure he will appreciate it

 

12 hours ago, Atlas2342 said:

Saw this on the forums today and i absolutely love this mod. Great job guys...

 

11 hours ago, Jimbodiah said:

The AJ-190 looks nice!!!

 

Thanks guys

[Shadowmage]

13 hours ago, lynwoodm said:

Good job on those RCS blocks and docking port. They look like they took a lot of time to model. So far no complaints or anything visibly a problem. I haven't tested the docking cam yet, but I will soon. Trying to figure out how to use Blender/Unity and coming along as fast as an old fart can do it. Going through all these tutorials on how to do things not even knowing if it's current information, which will all change anyways when 1.1 comes out. Trying to find out how to add "greeble" to things so it looks more space-like. 

Docking camera -- needs RPM installed, -and- I still need to create some patches for it (need to tell RPM that the camera exists/where to look for it).  However, as with other external/optional mods, my motivation and time to do the setup and extra work needed is often lacking.  I'll see about re-setting up RPM and getting the cameras working in the next few weeks.

Other than that, thanks   Still a lot of WIP stuff, textures to finish and such, but things are coming along nicely.

 

Yes, greeble....something I've always had a bit of a hard time with -- mostly due to poly and texture limitations.  Mostly it comes down to adding more and more little unnecessary bits;  the question is 'what is enough'?  Followed closely by 'how much detail' (or how small)?  Not easy questions to answer in a broad fashion.

[MrMeeb]

4 hours ago, drtedastro said:

I just wanted to stop by and say how nice the entry video looks.  Nice job.

And of course, the parts pack is great.  

Great work.

Cheers.

 

Hehay someone likes it :3 

 

[ComatoseJedi]

1 hour ago, Shadowmage said:

Docking camera -- needs RPM installed, -and- I still need to create some patches for it (need to tell RPM that the camera exists/where to look for it).  However, as with other external/optional mods, my motivation and time to do the setup and extra work needed is often lacking.  I'll see about re-setting up RPM and getting the cameras working in the next few weeks.

Other than that, thanks   Still a lot of WIP stuff, textures to finish and such, but things are coming along nicely.

 

Yes, greeble....something I've always had a bit of a hard time with -- mostly due to poly and texture limitations.  Mostly it comes down to adding more and more little unnecessary bits;  the question is 'what is enough'?  Followed closely by 'how much detail' (or how small)?  Not easy questions to answer in a broad fashion.

I can understand why you lack the motivation. This modding business is like another job, instead of fun. So many things to do just to get something working and sometimes it doesn't go according to plan and you bang your head against the wall. But, it happens so often that effort of wanting to mod with headaches versus just doing something else is a very viable option. 

But, this is your mod. You can choose to work on it as much as you see fit. If you lose motivation, you can always back away for a little while and pick it back up, if you do decide to do so. You don't get paid for this and you certainly don't need to do something that seems like another job when you do it. The only benefit of doing this is gratification of others enjoying your work. And you see many people on here who use this mod and appreciate the work you put into it. 

[Jimbodiah]

Maybe this is already in the planning somewhere... But I tend to shoot up a lot of resupply rockets with things that ressemble and ATV/HTV. Would such a concept fit in the lifters series? ie with configurable containers for life-support (TAC and USI), KIS, and fuels  like LF/Ox/MP/CommResources (or just cfg hackable)?

Edited December 28, 2015 by Jimbodiah

[Shadowmage]

On Sunday, December 27, 2015 at 11:04 AM, lynwoodm said:

I can understand why you lack the motivation. This modding business is like another job, instead of fun. So many things to do just to get something working and sometimes it doesn't go according to plan and you bang your head against the wall. But, it happens so often that effort of wanting to mod with headaches versus just doing something else is a very viable option. 

But, this is your mod. You can choose to work on it as much as you see fit. If you lose motivation, you can always back away for a little while and pick it back up, if you do decide to do so. You don't get paid for this and you certainly don't need to do something that seems like another job when you do it. The only benefit of doing this is gratification of others enjoying your work. And you see many people on here who use this mod and appreciate the work you put into it. 

Its not the motivation to do modding that is lacking; it is the motivation to deal with external mods that I do not use.  Which it seems like 3/4 of the requests are for.  And honestly, I don't understand it -- why would someone ask me to go out of my way to support a mod that I do not use?

 

 

6 hours ago, Jimbodiah said:

Maybe this is already in the planning somewhere... But I tend to shoot up a lot of resupply rockets with things that ressemble and ATV/HTV. Would such a concept fit in the lifters series? ie with configurable containers for life-support (TAC and USI), KIS, and fuels  like LF/Ox/MP/CommResources (or just cfg hackable)?

Hmm... perhaps.  Seems like it is something the 'Modular Service Modules' should be capable of.  Perhaps make it so they have a dedicated fuel amount (for a given size/scale), with additional 'optional' storage that the user can configure as-needed/wanted (even just for more fuel).

If you were asking for a separate payload-type container part;  not really... those other mods already offer containers for their resources.  I might consider something in the future, but it would be part of the 'orbital/interplanetary' series of parts, rather than lifters, and would probably be special-shaped containers for the ships form-factors.  (still part of Ship Core, but quite a ways down the road)

 

[Jimbodiah]

If you have a modular SM then I guess I can hack the cfg for my resource needs. It's mainly for esthetics; I can use the default containers, but it looks awfull with all the strapped on parys and different containers. I tend to use ProceduralParts or the WildBlue tanks with personal configs to keep part count down and looking decent.

i guess I could use the current SM-A for this.

[Shadowmage]

CM Geometry, unwrap, and bake done; colors shown are a very rough first pass only, has no detail/spec/norm, and even many of the colors will be changing a bit.

 

As the unwrap and geo are done, I'm going to work on getting the RCS transforms setup, and exporting all the new parts to KSP (CM, SM, BPC) and getting the part configs setup/working with some initial values for the modules.

Going to try something a bit different with the SM by breaking its RCS up into groups; upper (L/R/U/D translation, roll rotation), lower (F/B trans, yaw/pitch rotation), and rear (forward translation, secondary engines).  Might make the rear a secondary engine set via MultiModeEngine / engine switching...still debating a bit.

Will post up a testing pre-release with all of the parts as soon as I get them in KSP and working, so we can have a few days/rest of the week to do balancing and bugfixing on them.  Possibly tonight, but more likely tomorrow.

 

[Jimbodiah]

Looking good!!!

[Shadowmage]

And as I already have the geometry done for the rest of the parts; I figured I might as well make this a 'complete' refresh, so...

 

Minor geometry adjustments to ICPS, remove the old engine, add in the proper RL10B-2 model.  Mostly required redoing the AO bake for the geometry changes.

Will be redoing the HUS as well, -might- get them both finished off today.  Likely will not have time to re-export/setup these pieces in KSP for tonight's testing release, so they will probably wait until a bit later in the week for initial testing.

[Jimbodiah]

You make it all sound so easy, Mage!  I admire your work and can't think of playing KSP without these parts anymore.

 

Recognise this one?
 

Spoiler

 

Edited December 29, 2015 by Jimbodiah

[Shadowmage]

And first pass at rework on the HUS:

 

Still need to go back over the spec masks on both parts and bring them up to my new standards, and perhaps add a few details, but these appear to be mostly done as it is.  -Might- be able to get them into tonights testing release with the rest... a bit of config work to do on them, but should be able to get it sorted quick enough.

[Jimbodiah]

Would be a cool ending to the year