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

[stratochief66]

Hmm, so for some reason I can't get RealPlume effects on the Orion SM, after much tweaking.

https://github.com/stratochief66/RealismOverhaul/blob/898b6c5968dda86bb9f2b3e7b6222c66a856a360/GameData/RealismOverhaul/RealPlume_Configs/SSTU/SSTU-SC-B-SM.cfg

Any ideas appreciated.

 

I was able to get it to apply just fine on the Apollo SM.

https://github.com/stratochief66/RealismOverhaul/blob/898b6c5968dda86bb9f2b3e7b6222c66a856a360/GameData/RealismOverhaul/RealPlume_Configs/SSTU/SSTU_ShipCore_A_SM.cfg

[Jimbodiah]

Don't know, will check, but for the flare you can use that together with the other definition, you don't have to add it later:

@PART[SSTU_ShipCore_B_SM]:FOR[RealPlume]:NEEDS[SmokeScreen]
{
	@MODULE[ModuleEngines*]
	{
		@name = ModuleEnginesFX
		%powerEffectName = Hypergolic-OMS-White
    }
    PLUME
    {
        name = Hypergolic-OMS-White
        transformName = SMEngineThrustTransform
        localRotation = 0,0,0
        plumePosition = 0,0,0.1
        flarePosition = 0,0,0.1
        fixedScale = 2.0
        energy = 2.0
        speed = 1.5
    }
}

 

Edited January 27, 2016 by Jimbodiah

[Shadowmage]

5 hours ago, SpaceBadger007 said:

So to download the new update do I go on the first post n click the link saying latest stable version? I don't won't the one a few posts back because it says it might break saves.

 

-Every- update for this mod is going to break stuff.  That is why it is under the 'In Development' section.  The 'Recommended' Release will be updated rarely, and even then those will be save-breaking between releases at this stage; there is no way around it.  That is part of using a mod that is under development -- things get changed, and some of those changes are going to break things.

Your choices are:  keep using an outdated version, update to the new test releases and accept occasional breakage, or not use the mod.  The ONLY reason this mod is even available for download is to help with testing, use for non-testing purposes is not actively supported. (You might get away with it, but then it is on -you- to deal with it when things break)

 

[Shadowmage]

3 hours ago, stratochief66 said:

@Shadowmage

At a size of 8.4m, the interstage petal adapter is about 141T with 0.3.27-pre2, so I take it that you didn't have a chance to look at changing the massing equation? I am trying to fix/learn some stuff to improve our RO representation of the SLS, using the new interstage petal adapter

I will have to take a closer look into what is needed to update the parachutes. Previously the parachutes failed to slow things (I was using RO & FAR, so one or the other was probably not yet compatible, things should obviously be better for @davidy12 once he updates to your newest and if using RO, in a week or so when I have had time to figure out the new chutes and adapt.

@JoseEduardo added this bit of code so that engine support and aero fairings would be generated appropriately, depending on whether the user attaches the ICPS or EUS (your HUS)

https://github.com/KSP-RO/RealismOverhaul/blob/master/GameData/RealismOverhaul/RO_SuggestedMods/SSTU/SSTU_Orion.cfg#L406-L433

When the part is first spawned into the VAB, the EUS/HUS engine support appears, even though we want neither to appear. Once you toggled the EUS node on and off again using "Toggle EUS1 node" no engine support appears until you attach something to one of the base nodes. Do you have any insight into what might keep that from showing up when the part first spawns? I barely understand the trick that allows these fairing/support parts to be auto-generated, but I really like them.

Petal Adapter -- the fields that control mass/etc are all config based -- so you are free to try out some values and let me know what works.  I have limited time for in-game testing of things (which doing config changes requires), and all of my time over the past few days was spent fixing up FAR.  However, it is on the issues list, and scheduled for this weekends update, so will be done by then at the latest.  (I should probably be more precise when I say 'for the next release'... the mid-week unscheduled releases are often a 'whatever is currently done' type deal, and may not include all of the scheduled stuff...).

Parachutes, in RO -- you should merely need to adjust the 'mainFullDeployArea' to compensate for any change in pod mass.  It uses standard real-world drag equations to calculate drag force, so the proper canopy size can easily be derived through the equations.  Let me know and I can point you towards the proper equations, or even make up a calculator spreadsheet for it.  (simulated parachute area is completely separate from visible canopy size; you can have a tiny visible parachute but tell it that it is 10,000m2 in area if you want...).

Orion-SM Nodes -- Honestly, I have no idea; its really not setup to be used that way, and would have to spend some time playing with the config to figure it out.  From what I remember the things Jose was trying to do were 'not supported' and only working by chance/through side-effects. (BTW, the ICPS/HUS -already- have secondary top attach nodes for use by the SM, decouplers, whatever; they are hidden inside the tank top...).  That patch is also using some -very- old syntax for the NodeFairing config; so has not been kept up-to-date with the other changes; that is likely part of the problem.

[Shadowmage]

1 hour ago, stratochief66 said:

Hmm, so for some reason I can't get RealPlume effects on the Orion SM, after much tweaking.

https://github.com/stratochief66/RealismOverhaul/blob/898b6c5968dda86bb9f2b3e7b6222c66a856a360/GameData/RealismOverhaul/RealPlume_Configs/SSTU/SSTU-SC-B-SM.cfg

Any ideas appreciated.

 

I was able to get it to apply just fine on the Apollo SM.

https://github.com/stratochief66/RealismOverhaul/blob/898b6c5968dda86bb9f2b3e7b6222c66a856a360/GameData/RealismOverhaul/RealPlume_Configs/SSTU/SSTU_ShipCore_A_SM.cfg

No idea -- my patch works just fine for it, so it is not a problem with the part or modules:

https://github.com/shadowmage45/SSTULabs/blob/master/GameData/SSTU/Patches/RealPlumes.cfg#L240-L256

The only difference between your two (SC-A/SC-B) is the !EFFECTS{} line in the SC-B-patch -- this looks like it is malformed anyway, and is likely causing it to skip the rest of the patch.  I believe that syntax should be !EFFECTS,*{} in order to blanket delete them (really still a bit inexperienced with MM myself though, so could be wrong).

[Jimbodiah]

I took my RealPlume patch from an example from Real Plume Stock patches, they do not delete the original FX at all. I don't think it is needed as I've never had issues without it.

Re the save-breaks... a lot of times nothing it wrong, but there is a chance existing ships may behave differently (like insane) or when parts get deprecated, it will remove that entire craft from your save file upon loading. Mage announces parts that will be removed, so you have time to replace/remove your craft safely in your save. And always make a backup of your saves before installing mod updates, that way you can test if everything it OK without destroying your game. I use SSTU parts in my career saves, but have had to hyper-edit in some new ships twice now. It is something you have to be mindful of and just accept if you want to play this mod in a career. 

[blowfish]

3 hours ago, DarthVader said:

I'm loving this mod. Nearly every us liquid engine ever made, combined in absurd monstrosities.

Not even close  But it does cover many of the major US engines.

6 hours ago, SpaceBadger007 said:

So to download the new update do I go on the first post n click the link saying latest stable version? I don't won't the one a few posts back because it says it might break saves.

As Shadowmage said, this mod is in development, so frequent breaking changes are to be expected.  But to be specific about what could actually break, certain parts have their functionality changed and certain parts are deprecated.  So as long as you don't have any craft in flight, you should be fine.

Edited January 27, 2016 by blowfish

[Shadowmage]

4 hours ago, stratochief66 said:

 

@JoseEduardo added this bit of code so that engine support and aero fairings would be generated appropriately, depending on whether the user attaches the ICPS or EUS (your HUS)

 

https://github.com/KSP-RO/RealismOverhaul/blob/master/GameData/RealismOverhaul/RO_SuggestedMods/SSTU/SSTU_Orion.cfg#L406-L433

When the part is first spawned into the VAB, the EUS/HUS engine support appears, even though we want neither to appear. Once you toggled the EUS node on and off again using "Toggle EUS1 node" no engine support appears until you attach something to one of the base nodes. Do you have any insight into what might keep that from showing up when the part first spawns? I barely understand the trick that allows these fairing/support parts to be auto-generated, but I really like them.

Thinking a bit further on this -- the problem is probably related to the inclusion of the 'SelectableNode' module.  The NodeFairing relies on the attach node always being present on the craft if it is set to watch that node.  The selectable node module -deletes- the attach nodes from the part.

Combine (node needs to always be present), with (node gets deleted), and you can probably see the conflict.

Try it after removing the selectable node module and see if the problem persists.  (and after cleaning up the definition for the fairing module to the updated standards; many of those config values have changed).

What is likely happening is that the nodeFairing is checking for the node when the part is initialized, but the node does not exist, so it does not create a fairing.  The selectableNode module has no inter-linking back to the fairing module, and as such the fairing module has no way to know that its 'missing' node has been added to the craft.  However, when you attach a part it triggers an 'EditorShipModified' event to be fired, which the NodeFairing module monitors to check for parts being attached/detached so it knows when to enable/hide/unhide the fairing parts.

[Shadowmage]

...

 

[davidy12]

Deployed and still at 120m/s.

[Shadowmage]

3 minutes ago, davidy12 said:

Deployed and still at 120m/s.

You are missing the most important thing -- LOGS.  Why do I even need to post that?  Why is it not common courtesy to post logs when you have a problem?  It even says so in the OP -- POST LOGS IF YOU WANT HELP.

You also didn't answer the other questions --

What version are you using?  If it not the most recent, you must update, or you will not get assistance.

Any customizations that you have made?  If so, you must remove them and test again -- I do not offer support for customized instals.

Third -- does the bug still manifest on a basic SSTU + stock only install?  -- IF YOU DON'T TEST THIS I AM NOT HELPING YOU.

Fourth -- I need EXACT STEPS TO DUPLICATE THE PROBLEM ON A STOCK+SSTU INSTALL -- if you don't include this information, I'M NOT HELPING YOU.

 

Edited January 27, 2016 by Shadowmage

[Jimbodiah]

@davidy12  My Orion (latest release) slows down to 25m/s with just the drogues, 20m/s with unopened main chutes and 6.5m/s with opened chutes, ie working as intended. Are you using any mods like FAR/RealChutes perhaps? 

[Shadowmage]

26 minutes ago, Jimbodiah said:

@davidy12  My Orion (latest release) slows down to 25m/s with just the drogues, 20m/s with unopened main chutes and 6.5m/s with opened chutes, ie working as intended. Are you using any mods like FAR/RealChutes perhaps? 

Those shouldn't even matter anymore;  it works the same regardless of stock or FAR (and indeed, was reworked specifically to make sure it functioned in FAR).

If I had to guess (and I do, as he's given me no useful information), I would guess that he was using an old version with FAR or has a nullref somewhere that is keeping things from working.

[ComatoseJedi]

• CHANGE - Update SC-B-CM heatshield stats for new pod mass. It is rated for up to 4000m/s re-entry speeds for direct-capture, can/will re-tune as soon as I have more information regarding duna/eve return velocities.

Okay, I've exclusively tested this pod from Duna and Eve. This is a stock physics test only. Duna: Achieved a approx 4100 m/s upon reentry with a prolonged aerobrake node at 38*, only burned off 295 heat shield. Eve: Achieved approx 3800 upon reentry with a short 85* aerobrake node and only burned off 200. Seems this pod can survive re-entry from both these planets and at extreme angles of attack. I would imagine a more aggressive angle of attack would result in more being burned off, but I feel the modification for stock only works just fine. I'm not sure about RO, since I do not use that mod.  

[Jimbodiah]

I've run out of ablator in the past, but nothing happens after that. Is there any use to this mechanic?

[stratochief66]

4 hours ago, Shadowmage said:

No idea -- my patch works just fine for it, so it is not a problem with the part or modules:

https://github.com/shadowmage45/SSTULabs/blob/master/GameData/SSTU/Patches/RealPlumes.cfg#L240-L256

The only difference between your two (SC-A/SC-B) is the !EFFECTS{} line in the SC-B-patch -- this looks like it is malformed anyway, and is likely causing it to skip the rest of the patch.  I believe that syntax should be !EFFECTS,*{} in order to blanket delete them (really still a bit inexperienced with MM myself though, so could be wrong).

Ahh, weird. I will have to take a second look at that one. I just threw in the !EFFECTS{} at the end, since it wasn't working without it (and it isn't working for me with it. Perhap our patches are fighting, but I didn't see your effects, which is why I was trying to add them (adding the effect also triggers RealPlume to convert it to an RF engine, which causes throttling to act like we want it to. Like I said, I'll have to give it another pass.

Edited January 27, 2016 by stratochief66

[davidy12]

3 hours ago, Shadowmage said:

You are missing the most important thing -- LOGS.  Why do I even need to post that?  Why is it not common courtesy to post logs when you have a problem?  It even says so in the OP -- POST LOGS IF YOU WANT HELP.

You also didn't answer the other questions --

What version are you using?  If it not the most recent, you must update, or you will not get assistance.

Any customizations that you have made?  If so, you must remove them and test again -- I do not offer support for customized instals.

Third -- does the bug still manifest on a basic SSTU + stock only install?  -- IF YOU DON'T TEST THIS I AM NOT HELPING YOU.

Fourth -- I need EXACT STEPS TO DUPLICATE THE PROBLEM ON A STOCK+SSTU INSTALL -- if you don't include this information, I'M NOT HELPING YOU.

 

Wait, I found out what happened.

It's due to FAR. I've tried it three times Without FAR and three times with it. It's definitely due to that.

@Shadowmage: May I ask, why not make it FAR/Realchute compatible? 

[Shadowmage]

8 minutes ago, davidy12 said:

Wait, I found out what happened.

It's due to FAR. I've tried it three times Without FAR and three times with it. It's definitely due to that.

@Shadowmage: May I ask, why not make it FAR/Realchute compatible? 

It -IS- FAR compatible (RC is impossible, they use different modules).

Here is a screenshot of it working in FAR:

(this is with drogues deployed; it will slow to ~6m/s with mains deployed) (note the FAR toolbar button)

If it -doesn't- work in FAR for you, then you need to make sure you have the 0.3.27-pre2 release (https://github.com/shadowmage45/SSTULabs/releases/tag/0.3.27-pre2), and post all of the info that I requested (I cannot merely guess as to the cause and solution; logs and steps-for-reproduction are mandatory if you expect me to solve the problem).

Edited January 27, 2016 by Shadowmage

[Shadowmage]

21 minutes ago, stratochief66 said:

Ahh, weird. I will have to take a second look at that one. I just threw in the !EFFECTS{} at the end, since it wasn't working without it (and it isn't working for me with it. Perhap our patches are fighting, but I didn't see your effects, which is why I was trying to add them (adding the effect also triggers RealPlume to convert it to an RF engine, which causes throttling to act like we want it to. Like I said, I'll have to give it another pass.

I'll look into this a bit next time I feel like messing with my RO install and configs.  Its probably a pretty simple patch-side/syntax/formatting/order-of-operations problem; as the plumes work fine for my patch, there shouldn't be any technical issues preventing the RO patch from working (and my patch auto-disables itself when RO is installed; so that should not be conflicting either).

If you wanted to tackle it yourself, I would recommend starting with my patch and adapting it for RO.  First change the definition to the standard :FOR[RealPlumes]:NEEDS[SmokeScreen] while leaving the rest intact.  If that works, start adding in the next modification (change the plume type), and retest.  If it still works, add in the lines to change the engine module; so-on and so-forth until you find what line(s) are causing the problem.

I'll attempt to look into this sometime this week (and your attach-node/fairing problems) for this weekends' release, though no guarantees;  I already have 3 models to finish (mostly texturing) and quite a bit of plugin work to do still (finishing the texture-set stuff for fairings and procedural parts).

 

[ComatoseJedi]

I have Real Chutes and it does not conflict with this mod's parachutes one bit. Or at least I haven't experienced any problems. When I was doing my Duna/Eve Test for the SC-B-CM, the chutes deployed and worked like Shadowmage's picture depicts.  

[Shadowmage]

4 hours ago, ComatoseJedi said:

• CHANGE - Update SC-B-CM heatshield stats for new pod mass. It is rated for up to 4000m/s re-entry speeds for direct-capture, can/will re-tune as soon as I have more information regarding duna/eve return velocities.

Okay, I've exclusively tested this pod from Duna and Eve. This is a stock physics test only. Duna: Achieved a approx 4100 m/s upon reentry with a prolonged aerobrake node at 38*, only burned off 295 heat shield. Eve: Achieved approx 3800 upon reentry with a short 85* aerobrake node and only burned off 200. Seems this pod can survive re-entry from both these planets and at extreme angles of attack. I would imagine a more aggressive angle of attack would result in more being burned off, but I feel the modification for stock only works just fine. I'm not sure about RO, since I do not use that mod.  

Sweet, thanks for the testing and info.  Sounds like I might need to tune it a bit more to use more ablator, or perhaps leave it as-is in case someone wants to do a bit more violent/steep re-entry.

 

4 hours ago, Jimbodiah said:

I've run out of ablator in the past, but nothing happens after that. Is there any use to this mechanic?

Technically the pod should begin heating quite fast as soon as ablator runs out; it should be as if the heatshield no longer exists, and start overheating and eventually explode like any other part.  However, there -might- be a bug in my implementation that is keeping it from doing so (will need to do a bit more testing / more info).  Does the pod explode if you try re-entering when you set the ablator to 0 in the editor prior to launch?

[Shadowmage]

9 hours ago, stratochief66 said:

Hmm, so for some reason I can't get RealPlume effects on the Orion SM, after much tweaking.

https://github.com/stratochief66/RealismOverhaul/blob/898b6c5968dda86bb9f2b3e7b6222c66a856a360/GameData/RealismOverhaul/RealPlume_Configs/SSTU/SSTU-SC-B-SM.cfg

Any ideas appreciated.

 

I was able to get it to apply just fine on the Apollo SM.

https://github.com/stratochief66/RealismOverhaul/blob/898b6c5968dda86bb9f2b3e7b6222c66a856a360/GameData/RealismOverhaul/RealPlume_Configs/SSTU/SSTU_ShipCore_A_SM.cfg

@stratochief66

Here is a working config for your RO-realplume problem:

@PART[SSTU-SC-B-SM]:FOR[RealPlume]:NEEDS[SmokeScreen]
{
    @MODULE[ModuleEngines*]
    {
        @name = ModuleEnginesRF
        %powerEffectName = Hypergolic-OMS-White
    }
    @MODULE[ModuleEngineConfigs]
    {
        %type = ModuleEnginesRF
        @CONFIG,*
        {
            %powerEffectName = Hypergolic-OMS-White
        }
    }
    PLUME
    {
        name = Hypergolic-OMS-White
        transformName = SC-B-SM-ThrustTransform
        localRotation = 0,0,0
        localPosition = 0,0,0.25
        fixedScale = 2
        energy = 1
        speed = 1.2
    }
}

Results in:

I'm not really sure what the problem was; I merely deleted everything that didn't look necessary (including the late-run block to adjust the effects; with only a single effect, all setting should be done in the base plume config as far as I know; unless there is some reason I'm unaware of that they need adjusting at the EFFECTs level).

Also note that I'm not doing this on a full RO install; I've merely used the RO patch to rescale the SM, and the RO real-plumes patch for the effects; I also installed RealFuels for this test to make sure the swap to the engine module did not effect anything.

If I had to guess, it might be that you were missing the %powerEffectName = Hypergolic-OMS-White from the ModuleEngines* patch; but I have not tested it to confirm.

 

Nodes -- Looking into this at the moment, but it does appear to be a conflict between the SelectableNodes module and the NodeFairing module -- NodeFairing was never intended to be used with a node that could be deleted or toggled.  As such, the fairing initializes during OnStart, detects a missing/deleted node and disables itself (as it should, as a missing node is a setup error as far as it is concerned).  The SelectableNodeThis forces you to 1.) attach a part to that node, and 2.) press the 'enable fairing' button.  Appears to be a few other inconsistencies as well due to this interaction -- will know more after I can do a bit more testing and debugging.

I'll give a bit of thought on how to get this working, but honestly it was never intended to function with a toggle-able node, so it might not be cleanly possible.

[Shadowmage]

@davidy12

The parachutes are confirmed to work fine in FAR -- whatever the problem is, it is on your end (wrong versions, wrong setup, wrong patches... something).  (They also work fine in stock, and work regardless of if RealChutes is installed or not; RC has zero effect on them)

SC-B-CM-Drogues with FAR:

 

SC-B-CM-Mains with FAR

 

[Jimbodiah]

I can still re-enter, there is more heat build-up but nothing blows up, like with older versions where the heat was not balanced yet.

[davidy12]

Re-downloaded and it WORKED!!!