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

[Jimbodiah]

Someone say big? This thing will lift 500 tons into LKO and not even break a sweat. Jupiter III

Spoiler

 

 

 

 

Edited December 21, 2015 by Jimbodiah

[RedParadize]

Whats under that fairing must be realy heavy!

[Shadowmage]

1 hour ago, JoseEduardo said:

you don't, these are two distinct things, keep the plumes you have, but in order for it to be applied to the clusters you need to re-do the cluster patches like I did for RO, the big change is that it excludes the cluster part SSTU made, and re-creates it after everything has been applied to the engine (hence why it needs a :FINAL in it), so the way it works now is that SSTU clusters are made prior the effect has been added to it, and with that change they are applied after RealPlumes

unless something changed in the effect code, because in the early days of the module I managed to make FASA F-1, J-2, RL-10 and M-1 clusters and the Real Plumes were all working as intended (I have pics to prove that)

Hmm.. regarding the methods for adding real-plume configs; I might have to investigate it a bit.  It doesn't seem like the clusters would need to be completely redone just to add effects; you would just need to make sure the effects-adding-patch runs in an :AFTER[SSTU] block.  So the FOR[SSTU] block gets ran, and creates the initial part .cfg files, and then you can come along in an AFTER[SSTU] block and add/adjust/alter whatever was created in the initial patch.

Granted, I'm not a MM patch-guru, but I -believe- it was setup in a manner to handle cases just such as these.

[blowfish]

Hmm ... now that I think about it, it's possible that the current balance system is unfair to some engines.  Here's why:

*BEGIN LONG WINDED TECHNICAL DISCUSSION*

Hydrolox engines have much higher Isp than kerolox engines, but in real life that comes at a price - you need much larger tank volume and you have to deal with boiloff.  In KSP, neither of those things exist, so using raw, real world I_sp numbers for the comparison is going to make hydrolox engines look very good and kerolox engines look bad.  So I think it might make sense to scale the I_sp based on the mixture before doing the comparison.  KSP engines have I_sp values pretty close to real world kerolox engines (well, actually a bit closer to hypergolics but the difference is only about 5%.  The conversion factor that RealFuels uses to compare I_sp between hydrolox and kerlolox engines is 1.27 (vacuum) / 1.3 (sea level).  Applying a scale of 1.27 would give the RL10 a vacuum Isp of 364s, which is high for stock engines, but not way outside the range (particularly considering how low the thrust is).  If you apply the hypergolic scaling too, you get 346s ... at this point it might be more reasonable to apply the scaling you did to begin with.

[Jimbodiah]

1 hour ago, RedParadize said:

Whats under that fairing must be realy heavy!

That was just a test without a payload, but I use the final one to lift an entire space station into orbit.

https://www.youtube.com/watch?v=R7rXsdUbLpU for the current version with a very light load, just because it looks cool  Sorry for the choppy editing

Edited December 21, 2015 by Jimbodiah

[Shadowmage]

 

AJ10-190 semi-final geometry (Shuttle OMS, Orion-SM Main-Engine) -- This one is about 1/2 the diameter of the AJ10-137 (0.7m vs 1.6m)

Also uses a unique (so far that I've seen) three-ring gimbal assembly, where the thrust is actually transmitted through the ring structure.

Not sure if I like the current cage structure; but there needs to be some sort of truss-setup, as this engine traditionally mounts at the gimbal rings, and I need it to have an upper-mounting plane.  So, might change the truss-work up a bit to make it less busy looking, but it will likely end up very close to what is shown.

[Jimbodiah]

Noice!!!

[VenomousRequiem]

So when you add that, all we need is a mod for the OMS pod and lifting body of a shuttle and we've got a proper STS!

[JoseEduardo]

14 hours ago, Shadowmage said:

Hmm.. regarding the methods for adding real-plume configs; I might have to investigate it a bit.  It doesn't seem like the clusters would need to be completely redone just to add effects; you would just need to make sure the effects-adding-patch runs in an :AFTER[SSTU] block.  So the FOR[SSTU] block gets ran, and creates the initial part .cfg files, and then you can come along in an AFTER[SSTU] block and add/adjust/alter whatever was created in the initial patch.

Granted, I'm not a MM patch-guru, but I -believe- it was setup in a manner to handle cases just such as these.

if the clusters are made prior the engine edit, a new patch will need to be done specifically for the cluster, if the clusters are made after every change has been applied to the single engine they work great

that is why I had to make the RO patches in a way I excluded the original clusters and imediatelly re-created them after all patches have been applied to the single engine, because if I didn't do that I either would have to write a patch to modify a cluster alone instead of just doing the RO patch for the single engine and having the cluster patch multiplying them

I had to do it that way even in the beggining when you released the white F-1 and RS-68 and I was playing around with FASA engines, the FASA engines didn't get their RO patch done without the :FINAL in them, without that they were just copying the original stock engine, after I used the :FINAL even RealPlumes got added to them

8 hours ago, VenomousRequiem said:

So when you add that, all we need is a mod for the OMS pod and lifting body of a shuttle and we've got a proper STS!

like this? http://forum.kerbalspaceprogram.com/index.php?/topic/119951-cormorant-aeronology-dev-thread/

Edited December 22, 2015 by JoseEduardo

[stratochief66]

The Apollo SM w/engine included appears to gimbal, but not actually gimbal the thrust effect or the visual effects. NathanKell suggested that would be an issue with the model/mu and transforms.

[Shadowmage]

49 minutes ago, stratochief66 said:

The Apollo SM w/engine included appears to gimbal, but not actually gimbal the thrust effect or the visual effects. NathanKell suggested that would be an issue with the model/mu and transforms.

 

Hmm... now that you mention, I'm not sure if I ever tested that setup as far as thrust gimballing.  Yes, if there is an error it is likely in the model heirarchy.  Will investigate this shortly, and likely have a fix available later this afternoon (with a few other minor bits).

 

Edit:  Indeed, I have the thrust transform parented directly to the SM main mesh rather than the engine bell/gimbal.  Fixing now, will need to re-export/etc after I get home from work.

Edited December 22, 2015 by Shadowmage

[Shadowmage]

5 hours ago, JoseEduardo said:

if the clusters are made prior the engine edit, a new patch will need to be done specifically for the cluster, if the clusters are made after every change has been applied to the single engine they work great

that is why I had to make the RO patches in a way I excluded the original clusters and imediatelly re-created them after all patches have been applied to the single engine, because if I didn't do that I either would have to write a patch to modify a cluster alone instead of just doing the RO patch for the single engine and having the cluster patch multiplying them

I had to do it that way even in the beggining when you released the white F-1 and RS-68 and I was playing around with FASA engines, the FASA engines didn't get their RO patch done without the :FINAL in them, without that they were just copying the original stock engine, after I used the :FINAL even RealPlumes got added to them

like this? http://forum.kerbalspaceprogram.com/index.php?/topic/119951-cormorant-aeronology-dev-thread/

 

Hmm... I'll have to play around with the patch stuff a bit more.  Seems like there -should- be a way to do it.

From the MM wiki:
"The BEFORE and AFTER (and FOR?) keywords can be used to control in what order your patch is applied. The value passed to BEFORE or AFTER is the name of the mod, defined as the name of the directory directly under GameData? This lets you patch patches or patch patches of patches, as deep as you'd like to go."

So... if I'm gathering the details of the problem correctly -- what is happening is that

1.) the single-engine cluster parts get created from their .cfg file
2.) my patches get ran to create the clusters from the single-engine .cfg files
3.) RO would try and patch the original 'single-engine' cluster, and thus the changes would not be applied to the patch-created multi-engine clusters.

 

And what we need to happen is:

1.) Single engines parts created from .cfg
2.) RO/RealPlumes/etc apply patches to single-engine cluster parts
3.) Multi-engine cluster patches are ran, cloning the single-engine setup.


So, perhaps something like this would work:
1.) Single engine parts created from .cfg files
2.) RO patches are ran in a :BEFORE[SSTU] block -- this ensure they get ran before the FOR[SSTU] patches are ran (which create the clusters) (can still have a :FOR[RO] or whatever I believe)
3.) Multi-engine cluster patches are ran in either a FOR[SSTU] or an AFTER[SSTU] block; as the RO/real-plumes patches have already been applied to the single-engine parts, the newly cloned clusters should have all of the updated/patched values.

 

 

Will see about playing around with this stuff when I have a chance (perhaps this weekend).  I don't really feel like setting up all of RO to test things, but could certainly try setting up RealPlume for testing (as I believe the problem is the same in both cases).

 

 

[Jimbodiah]

Cool that you are looking into this Mage!!!! Would be an awesome way to accomodate the RO crowd and also allow real-plume effects.

Is there any way to just make the plumes (excl smoke) behave like real-plume but with the standard particle effects? This would bypass the need for SmokeScreen/Real_Plume alltogether and give the effect to everyone, without the need for other mods/plugins.

Edited December 22, 2015 by Jimbodiah

[blowfish]

1 hour ago, Jimbodiah said:

Is there any way to just make the plumes (excl smoke) behave like real-plume but with the standard particle effects? This would bypass the need for SmokeScreen/Real_Plume alltogether and give the effect to everyone, without the need for other mods/plugins.

What you can do with the stock FX is pretty limited.  There's a reason why RealPlume requires SmokeScreen.

[Shadowmage]

AJ10-190 - Unwrapped/baked/initial color and specular pass -- Still quite a bit to do, but is usable at this point.

 

[Jimbodiah]

E series... AJ10-190... Dude, you have shuttle fever, just admit it

[Shadowmage]

Not really -- I need the AJ10-190 for the SC-B-SM (Orion).  If it weren't for needing it for that, I likely wouldn't be doing it at all.  And series-E still sounds like it will not be going anywhere; will probably officially drop it later today -- the whole concept is pretty much doomed to failure due to stock limitations.

I would like to make a shuttle; but at the point where I have to make it a multi-part body -- sorry, not doing it.  And apparently that is the only way to make it work due to limitations on how stock 'fakes' the drag/lift/control systems.

[JoseEduardo]

If I can suggest something to replace Series E, or maybe for a separate future mod, would be Shuttle payloads, like either Shuttle (static) or Buran (extendable) docking adapters to go with the payload bay of the stock Shuttle, and payloads for the shuttle, like SpaceLab, SpaceHab, Payload racks (for sattelites and stuff), Telescope (well, there is Cacteye....)

the Shuttle adapter could be re-used btw


but I'm just throwing out ideas for a thing that I just found out (series E, which first reminded me of EMBRAER E-jets )

Edited December 22, 2015 by JoseEduardo

[Jimbodiah]

@Shadowmage  Re the RO/Plumes thing: An "easy" fix (in terms of not changing your code) would be to make a modular mount to let us just mount the separate engines on and that has an interstage node should anyone want to use a cluster on a second stage. Jose can implement his RO, I can do my plumes, you don't need to rack his brain, everyone wins with the least amount of effort?

@JoseEduardo Maybe for the planned Station/Satellite series down the road?

It's a shame RaiderNick no longer works on his modules, he basically had an entire run of satellites and those soyuz parts. I am using his US probes pack right now just to have an excuse to launch stuff

Edited December 22, 2015 by Jimbodiah

[ComatoseJedi]

Seems like you got your work cut out for you anyways with the rest of the implementations you want to do with the rover, station, satellite and base cores. I don't blame you for dropping the E series. On these issues, what did you have in mind of those looking like? I know you put something in the station core master part section. You going with nasa-inspired designs and concepts? As I say this, I know that there are some who love the "stock feel" of things and then there are people like me who lean towards looking familiar with something else while not being a replica.

 

[VenomousRequiem]

12 hours ago, JoseEduardo said:

like this? http://forum.kerbalspaceprogram.com/index.php?/topic/119951-cormorant-aeronology-dev-thread/

Yeah, that's what I meant by shuttle lifting body... I couldn't remember the actual name. :b

[Jimbodiah]

I'm not looking for a replica of the ISS (there already is one with Community ISS, but no longer maintained), but I think the functionality for every station is basically the same. Solar panels (huge, multi-axis following, but already planned Mage sais), hab modules, airlocks, cupola/command, resource storage, batteries, rcs, trusses... Seeing as the rest of SSTU is not  "Stock-alike" looking, I would love the rest of the parts to keep the same "Realistic looking" feel to mesh well with the current SM/CM/parts.

[ComatoseJedi]

5 minutes ago, Jimbodiah said:

I'm not looking for a replica of the ISS (there already is one with Community ISS, but no longer maintained), but I think the functionality for every station is basically the same. Solar panels (huge, multi-axis following, but already planned Mage sais), hab modules, airlocks, cupola/command, resource storage, batteries, rcs, trusses... Seeing as the rest of SSTU is not  "Stock-alike" looking, I would love the rest of the parts to keep the same "Realistic looking" feel to mesh well with the current SM/CM/parts.

When I think of the word "space station", 2001: Space Odyssey comes to mind. When I think of "surface hab/base": The Martian comes to mind and maybe the movie Moon. Rovers, boy oh boy, to numerous to count. Got my first taste of a real interactive functional rover with ERS. It's just so ticky at putting together. Then the Buffalo, which is cool that you can drop it on a surface and assemble it on site makes it even better. Then The Martian rovers were very cool looking (someone's already making that one, I think). Just so many ideas on how things can be incorporated into modding. If you can model it and make it function as it's intended, good to go (don't forget the gold foil). 

 

[Jimbodiah]

Angel has the Buffalo and Rover the Karibou, both based on real designs. I'd favor going for station parts first as there aren't really any mods out there catering to this. As to the Buffalo, I just tend to make a skycrane to drop them on the surface, as I suck at assembling on the ground; usually takes 3-4 refill flights because of all the parts I mess up. Thank god for Hyperedit in those moments.

[ComatoseJedi]

4 minutes ago, Jimbodiah said:

Angel has the Buffalo and Rover the Karibou, both based on real designs. I'd favor going for station parts first as there aren't really any mods out there catering to this. As to the Buffalo, I just tend to make a skycrane to drop them on the surface, as I suck at assembling on the ground; usually takes 3-4 refill flights because of all the parts I mess up. Thank god for Hyperedit in those moments.

LOL and I tend to suck at skycraning everything. I did use the Buffalo mod when the Mage had the cargo lander in it and drop it with the attachment, which worked nicely. So, I'd normally shove parts into KIS containers and drop them as landers, along with my hab systems. Usually takes about 4 of them, but I did manage to modify the smaller inline kis container to hold everything at one shot. A little easier that way, but it's a little cheaty, but it's better than flying 14 pods to one place to land 500 meters apart from each other. That's the first thing I learned how to do was assemble stuff on the ground. I haven't tried the Karibou, because I'm skittish about the life support that I'd might have to implement to use it. Same for KSPI-E. If I want complication, I'd try to understand women first. and after 41 years, I still haven't figured those creatures out.