Shadowmage

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

Recommended Posts

3 hours ago, linuxgurugamer said:

@Shadowmage

I had a report that EngineLight is acting oddly with the SSTU SRBs.  I took a fast look, and it seems that SSTU has lots of unexpected emmissives which stock engines don't. 

Would you have any idea about this?

On the SRBs?  Hmm... I don't even think -I- have any emissives on them.

Yep, double checked.  I have zero emissive modules/animations/etc in the part configs, and none should be being added by part-modules either.  Have some of the names/further information on these errant emissives? (and are you referring to textures, or animations?)

 

1 hour ago, RaiderMan said:

ISDC worked..thank you!

now..I have a slight..issue with the SRB contacting the center core..and I'm reasonably certain its something about the radial booster decoupler...dont suppose you can hazard a guess whats causing it?

48089303776_1516a4763b_t.jpgvulcan centaur 462 srb by XRaiderV1.7, on Flickr

Generally is solved by offsetting the SRBs downwards slightly on the decoupler, so that the decoupler gives the tip an outward push; aero forces take care of the rest (the SRB COM is on the default surface attach position, so the minor offset is needed).

Share this post


Link to post
Share on other sites

Ok, then I have no idea.  I don't use SSTU, and when I loaded it, I looked into the config (briefly).

 Take a look at these pictures.  The first two are normal, the third, fourth, and fifth are with the Engine Lighting Relit mod installed:

vTgidE1.png

1NbAcWk.png

 

The following three show the problem:

cGbdeK2.png

RZY6Cdt.png

RgV9Thc.png

 

Share this post


Link to post
Share on other sites

so..in otherwords, my srbs are dead tap centered on the decoupler..do I have that right?

Share this post


Link to post
Share on other sites
1 hour ago, linuxgurugamer said:

Take a look at these pictures.  The first two are normal, the third, fourth, and fifth are with the Engine Lighting Relit mod installed:

That does look odd, but that is an actual Light, and not an emissive.  I really couldn't say where it is from.

Does the engine light mod somehow cache the 'engine thrust transform' location (to determine where to place the light)?  As that does change with those parts in the editor/etc, esp as compared to the prefab part.

32 minutes ago, RaiderMan said:

so..in otherwords, my srbs are dead tap centered on the decoupler..do I have that right?

If you just place them on the RBDC, then yes they are 'centered' on the decoupler by default, and will be 'neutral' when decoupled.  Aero forces will likely cause them to tumble inwards and hit the center stack.

Moving the SRB downwards on the decoupler slightly forces the 'nose out' tendency upon decoupling, at which point aero forces seem to rip them away from the rest of the rocket.  Don't offset too much though, or you can end up with the opposite problem -- the bottom of the SRB smacking into the center stack.

Share this post


Link to post
Share on other sites

how far down would you recommend I offset?

Share this post


Link to post
Share on other sites
Posted (edited)

edit: ah, i missed out on the DefaultShaderAssignments-LC-POD.cfg and the LC2-POD-MET.dss, which creates the lattice.

 

Hello Shadowmage,

I tried to create a personalized variant of the two-person-lander-can without the solar panels on top of it. I changed the .dds, hoping it would suffice to turn the solar cell grid texture grey.

However, in KSP the grid itself is still being rendered. I exported the .mu to Blender but I found no trace of such a grid texture on the "plates" and they aren't part of the model list in  LC2-Pod.cfg

either.

Could you maybe give me a little hint? 

I just <3 the very kerbal style of your lander cans. :)

Edited by claustro

Share this post


Link to post
Share on other sites
16 hours ago, Shadowmage said:

Stock has some issues when the 'root part' uses dynamic drag cubes.  Not much I can do about that -- I'd file that bug on the stock issue tracker.  SSTU parts have to use dynamic drag cubes, period, and that includes if the player decides to use an SSTU part as root.

 

Again though -- is there an issue with JUST SSTU installed (no scatterer?).  If yes, please let me know, as the issue exists in SSTU.  If the problem only occurs with Scatterer, then it is Scatterer that is having problems, and again, I would suggest raising the issue there (I cannot solve problems in other mods).

Notably, if you look at the stack-trace, the SSTU code is executing just fine and completes its function calls without error.  No problems there.  The exception is occurring in Scatterer code.  "scatterer.ShadowRemoveFadeCommandBuffer.OnDestroy ()"

 

 

Dont misunderstand me Shadowmage, wasnt my intention that you had to solve scatterer's problem, not at all, i raised the problem in his thread aswell, and as you said, in stock with no scatterer there is no problem (tested it ofc lol). I was kinda hoping you might have a workaround the issue that could be used as a bandaid until scatterer looks at the issue. But i guess just clipping in a probecore and making it root part will do the trick for now.

Share this post


Link to post
Share on other sites
4 hours ago, Wackenhut said:

I was kinda hoping you might have a workaround the issue that could be used as a bandaid until scatterer looks at the issue. But i guess just clipping in a probecore and making it root part will do the trick for now.

That pretty much -is- the workaround. :)

Share this post


Link to post
Share on other sites

gonna try shifting my srbs down as suggested, will be taking video of this as well so you can see what exactly is happening.

Share this post


Link to post
Share on other sites

literally tried everything off the top of my head. here's the video.
had ONE clean launch..ONE.

 

everything else failed.

 

Share this post


Link to post
Share on other sites
1 hour ago, RaiderMan said:

gonna try shifting my srbs down as suggested, will be taking video of this as well so you can see what exactly is happening.

Are you sure all of the SRBs are attached to the RBDC, and not attached to the core?  At 2:52 in your video, it looks like two of them decouple fine, but two don't decouple at all?

It also looks like the SRBs may be a bit too close to eachother, and are colliding upon initially decoupling (9:53 in the video).  Additionally, it doesn't look like there is any gap between the SRBs and the core... whereas there should be if they are placed on the RBDCs properly.

It may also be that I'm not entirely understanding the issue?  (Thought the issue was that the SRBs were colliding into the central fuel tank, which is why I suggested offseting the parts).   SRBs colliding -after- they have been jettisoned though is quite normal for KSP in my experiences.


I'll try and make up a quick replica of your craft this evening to see if I can duplicate the issue at least.  Fairly certain I've used launchers similar to that in the past without too many problems.

 

 

14 hours ago, claustro said:

edit: ah, i missed out on the DefaultShaderAssignments-LC-POD.cfg and the LC2-POD-MET.dss, which creates the lattice.

 

Hello Shadowmage,

I tried to create a personalized variant of the two-person-lander-can without the solar panels on top of it. I changed the .dds, hoping it would suffice to turn the solar cell grid texture grey.

However, in KSP the grid itself is still being rendered. I exported the .mu to Blender but I found no trace of such a grid texture on the "plates" and they aren't part of the model list in  LC2-Pod.cfg

either.

Could you maybe give me a little hint? 

I just <3 the very kerbal style of your lander cans. :)

Indeed, if all you are wanting to do is to remove the solar panel grid/lattice, editing of the textures (ALL of them) should do the trick.  Notably you will need to edit both the DIFF and MET textures, editing out the solar panel bits in each of them as needed.  Note that the MET texture contains metallic information in the 'R' channel, and specular/gloss information in the 'Alpha' channel (and possibly AO information in the 'G' channel) -- all channels need to be maintained aside from the edited portions.

Share this post


Link to post
Share on other sites

that was my thought as well @Shadowmage but I am fairly religious about proper srb/decoupler seating, I know when the SRB gets twitchy during attaching, that I'm on the decoupler, not the core.

that said..I'm attempting to replicate as close as I can, the vulcan..from the reference images I've found, this is actually proper positioning...I could be wrong, the available reference images are..rather unhelpful there.

when I had stock seperatrons attached as dummy weights..they practically fell away from the core, so its not an attachment to decoupler issue(to the best of my knowledge)

 

attached is a screenshot of the booster attachment.

48094659812_c076816c2a_t.jpgvulcan srb attachment. by XRaiderV1.7, on Flickr

edit:

clean static drop release on SRBs

48094686127_a3d272b1a1_t.jpgclean srb sep by XRaiderV1.7, on Flickr

Share this post


Link to post
Share on other sites
1 hour ago, RaiderMan said:

attached is a screenshot of the booster attachment.

They are certainly close together, but it -looks- like there should be sufficient room to prevent basic collisions.  Putting together a test craft now and will let you know how it goes.

Share this post


Link to post
Share on other sites

lemme know what happens.. literally tried everything I can think of on my end.

Share this post


Link to post
Share on other sites
15 minutes ago, RaiderMan said:

lemme know what happens.. literally tried everything I can think of on my end.

Could I get a copy of your .craft file (assuming it is stock+SSTU only)?  My attempt to create a similar craft layout had no problems at all during decoupling of the SRBs.

z86djAL.png

 

e8z9UC2.png

nylwSgF.png

The only changes that I made were to set the RBDC lower motors thrust limiter to 90%, so the upper motor had just a bit more push to it, and to enable 'autostrut - grandparent' on each of the SRBs (so they were strutted to the central tank).  The SRBs were left centered on the decouplers, with no offset used.   I made those changes before the first flight (standard stuff for my designs), so no idea if they were actually needed; likely would have worked fine without the thrust adjustment, though auto-strut is a bit more of a necessity.

 

Share this post


Link to post
Share on other sites

yeah..gimme a bit, have to go yank off a few parts added for night time launch 'quality of life' reasons..read lights cause I cant see bubkiss with black on black(copper at night is black)

do you need the loadmeta file as well? I'll be including it to be on the safe side.

Share this post


Link to post
Share on other sites
Posted (edited)

prior to uploading the requested craft file, for curiosity's sake, I did a test flight with seperatrons on the nose cones..they pushed the boosters away cleanly...

the craft linked here has been sanitized of everything not sstu, that means not even launch support structures of any kind are included. you'll need to set those up as well.
also please note I've even gone so far as yanking the controllable 'dummy' test payload.
https://www.dropbox.com/sh/ne8ow3pc79ikhcy/AAA-BTvRLT18cobBMaqwDXmsa?dl=0

 

Edited by RaiderMan

Share this post


Link to post
Share on other sites

@RaiderMan@Shadowmage

Ditto on the autostrutting. Rigid connection helps too. The issue that I've always noticed with that decoupler part is the typical squishy KSP/Unity connection coupled with the long lever arm when the decoupler is scaled vertically. (you don't get that with individual sepratrons, Raider which is why it separated cleaner for you)

Share this post


Link to post
Share on other sites
3 hours ago, RaiderMan said:

prior to uploading the requested craft file, for curiosity's sake, I did a test flight with seperatrons on the nose cones..they pushed the boosters away cleanly...

the craft linked here has been sanitized of everything not sstu, that means not even launch support structures of any kind are included. you'll need to set those up as well.
also please note I've even gone so far as yanking the controllable 'dummy' test payload.
https://www.dropbox.com/sh/ne8ow3pc79ikhcy/AAA-BTvRLT18cobBMaqwDXmsa?dl=0

 

Thanks for the craft file.  Can confirm the described issues with the craft as provided.

Can fix(?) the issues with three simple(?) changes.

  1. Enable Autostrut-Grandparent on each of the SRBs.  The first test flight the SRBs sagged into the core on decoupling and lots of things exploded :)
  2. Set the bottom thrust limiter on the RBDCs to ~70%.  This forces a 'nose out' decoupling (same as offsetting the COM would).
  3. When decoupling, ensure that you are flying mostly prograde, or aero forces will push the 'lower' SRBs back into the stack.  This is probably the most important bit from my test flights.  If I let autopilot run 'dumb', it would be a few degrees off prograde at that point in flight, and cause issues quite often.  If I briefly toggled 'hold prograde' before and during decoupling, it was smooth every time.
    1. Kind of not surprising considering the decoupling is happening right around max-q for this craft and flight profile.  Normally this type of event would be programmed into the autopilot to compensate for such issues (throttling down and/or maintaining prograde (which isn't really a thing on a real gravity turn; you always point prograde)).

Note I switched off autopilot and turned on stock SAS 'hold prograde' a few seconds before decoupling.

1khT7NY.png

No collisions with central core.  A couple SRBs collided after jettison... which is perfectly Kerbal.

dVnoAPU.png

 

It does appear that the RBDC lacks some decoupling power at that particular scale and dynamic pressure; the engines aren't giving things quite the push that they need to in order to fight aero forces fully.  In my test craft the decoupling was happening much higher up, at much lower dynamic pressure (pretty much vacuum), so the puny engines were plenty.

As a bit of a more drastic 'test' you might try patching/editing the RBDCs to increase their thrust and fuel a bit, or adjusting the thrust/fuel scaling factors.  I feel the part works fine for my uses and craft designs, but perhaps it needs adjustment for other specific cases or play styles.

2 minutes ago, Starwaster said:

The issue that I've always noticed with that decoupler part is the typical squishy KSP/Unity connection coupled with the long lever arm when the decoupler is scaled vertically.

You know, I never even thought of that issue (the RBDC thrust and its single joint on the SRB)... but that would explain quite a bit of the off-axis thrust that I see on jettison with those parts.  The long lever arm + Unity joint slop = inconsistent thrust vectors, just enough to induce some spin.

Share this post


Link to post
Share on other sites
5 minutes ago, Shadowmage said:

You know, I never even thought of that issue (the RBDC thrust and its single joint on the SRB)... but that would explain quite a bit of the off-axis thrust that I see on jettison with those parts.  The long lever arm + Unity joint slop = inconsistent thrust vectors, just enough to induce some spin.

Yeah, it's the sucky very unfortunate nature of the beast; not much you can do about it.

Although I do wonder: Is it possible to make surface attach nodes themselves rigid and fixed joint? You can do it when nodes are defined using the NODE config but I'm not sure how or if you can define that as a surface attach node.

Share this post


Link to post
Share on other sites
On 6/18/2019 at 8:21 PM, linuxgurugamer said:

k, then I have no idea.  I don't use SSTU, and when I loaded it, I looked into the config (briefly).

 Take a look at these pictures.  The first two are normal, the third, fourth, and fifth are with the Engine Lighting Relit mod installed:

Were you able to track down any further information about this?  What is adding the light, why it is positioned where it is, etc?  (its not being added by SSTU)

Fairly certain it is being added by the mod in question; specifically

The Light field

https://github.com/linuxgurugamer/EngineLightRelit/blob/master/EngineLightRelit/EngineLightEffect.cs#L294

The code creating the light

https://github.com/linuxgurugamer/EngineLightRelit/blob/master/EngineLightRelit/EngineLightEffect.cs#L294

And I think the positional problem is likely to be found here:

https://github.com/linuxgurugamer/EngineLightRelit/blob/master/EngineLightRelit/EngineLightEffect.cs#L380-L382

Notably the thrust transform position for the MSRBS is not updated until Start(), which is fired long after OnStart() (and not until just before the first Update()).  So at the point where the mod is positioning the lights, the thrust transforms have not yet been positioned for the current part layout.

TLDR:  - Move your light initialization code to Start() to ensure that any external modules you interact with are fully initialized, and/or reposition them in the Start() call.  I would wager this simple change would fix the interaction issues with the SSTU SRB parts (and engine clusters, and other parts... as they all use the Start() based ModuleEngines interaction).

 

 

Share this post


Link to post
Share on other sites
1 hour ago, Shadowmage said:

Were you able to track down any further information about this?  What is adding the light, why it is positioned where it is, etc?  (its not being added by SSTU)

Fairly certain it is being added by the mod in question; specifically

The Light field

https://github.com/linuxgurugamer/EngineLightRelit/blob/master/EngineLightRelit/EngineLightEffect.cs#L294

The code creating the light

https://github.com/linuxgurugamer/EngineLightRelit/blob/master/EngineLightRelit/EngineLightEffect.cs#L294

And I think the positional problem is likely to be found here:

https://github.com/linuxgurugamer/EngineLightRelit/blob/master/EngineLightRelit/EngineLightEffect.cs#L380-L382

Notably the thrust transform position for the MSRBS is not updated until Start(), which is fired long after OnStart() (and not until just before the first Update()).  So at the point where the mod is positioning the lights, the thrust transforms have not yet been positioned for the current part layout.

TLDR:  - Move your light initialization code to Start() to ensure that any external modules you interact with are fully initialized, and/or reposition them in the Start() call.  I would wager this simple change would fix the interaction issues with the SSTU SRB parts (and engine clusters, and other parts... as they all use the Start() based ModuleEngines interaction).

I haven't had a chance, still deep inside another mod.  But I agree about the initialization code, will try that when I get some time this weekend

Thanks for looking

Share this post


Link to post
Share on other sites

what I want to know next..is did I scale this properly for what vulcan is supposed to be and do...had to guess on alot of her.

Share this post


Link to post
Share on other sites
Posted (edited)

..and second question..how do I enable autostrut/grandparent on the srbs?

edit: never mind, I had to turn on advanced tweakables..still need that scale question answered mind.

Edited by RaiderMan

Share this post


Link to post
Share on other sites
22 hours ago, RaiderMan said:

what I want to know next..is did I scale this properly for what vulcan is supposed to be and do...had to guess on alot of her.

Probably asking in the wrong place.  This isn't a ULA-replica thread.  I have no idea what that rocket is even supposed to be, so certainly, I'm the entirely wrong person to ask.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.