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

[gunt3rgam3r]

Hello team,

 

This is a great mod I love your parts...quick bug report, I was experiencing crashes in my modded game, so I installed sstu on a clean version of 1.2.1.  In the game every time I use the built-in parachutes on the Apollo and Orion reentries pods It creates a null reference...in almost all cases it leads to a full game crash right around touchdown.  If I use attached parachutes and not the internal ones there is no issue.

 

Not sure exactly what is the problem, but this should point you in the right direction...FYI it sends a null reference to the log with both the drogue chutes and the main chutes.  Using the latest version 0.5.33.128 from github.

 

thx

[tater]

I would suggest zipping up the log, and posting a link to it.

[Shadowmage]

2 hours ago, gunt3rgam3r said:

Hello team,

 

This is a great mod I love your parts...quick bug report, I was experiencing crashes in my modded game, so I installed sstu on a clean version of 1.2.1.  In the game every time I use the built-in parachutes on the Apollo and Orion reentries pods It creates a null reference...in almost all cases it leads to a full game crash right around touchdown.  If I use attached parachutes and not the internal ones there is no issue.

 

Not sure exactly what is the problem, but this should point you in the right direction...FYI it sends a null reference to the log with both the drogue chutes and the main chutes.  Using the latest version 0.5.33.128 from github.

 

thx

In the future please include logs with bug reports; saves considerable time in having to ask for them, and often can point out exactly what the problem is.

However you are in luck today as I was able to duplicate this bug with a simple craft. Have fixed the problem, and it will be available with the next update (likely this weekend).  Note, this fixes the nulref.  No clue what is causing your crashing, as I did not experience any crashes during testing.

The problem in this case was some back-end changes to the KSP code in regards to the setup of temporary debris objects; in this case they require that the rigidbody be manually assigned to the 'physicalObject.rb' field (in prior versions this field did not exist, or at least had an intelligent get method and would pull and cache the value automatically).  So now during creation of debris I manually assign the pO.rb field, and all is well.

 

Edit:  As far as crashing goes, apparently there is a pretty severe bug in vanilla KSP related to part highlighting, aero-fx, and aero-debug displays that can cause crashes after a few minutes of gameplay.

Edited November 15, 2016 by Shadowmage

[mechanicH]

i actually get that bug myself, but its not all the time. when i reload the game back to my save it works as intended. 

[StickyScissors]

This new stuff looks amazing! Now, to re-discover my will to play this game. Don't ya just love slow internet, broken patches and essential mods never getting updated?

[AlphaKerman]

Is there any ways to somehow edit the ablator heat shield durability? (.cfg file?) Because recently i started using Kerbol 64K, and their reentry speed is close to 5.4 km/s and it makes my kerbals toasted within few seconds of reentry 

[Jimbodiah]

Yes, but you can adjust heat production in the ksp settings which might be easier. Else use this (change to reflect the mod you are using or just remove).

@PART[*]:HAS[@MODULE[SSTUModularHeatShield]]:NEEDS[RealSolarSystem]:AFTER[SSTU]
{
    @RESOURCE[Ablator]
    {
	    @amount *= 3
	    @maxAmount *= 3
    }
}

 

[FrancoisH]

Hello there,

Before submitting a bug as I did yesterday for something not related to SSTU, I would like to ask here for a clue

I do like a lot Action Groups Extended as it improve greatly your capacity to create actions, even in flight.

But, with the SSTU fairing bases, it generates a flow in my log file, enough to make the game freezing every second.

LOG 17:27:09.317] AGX Flight Update Error 7i System.NullReferenceException: Object reference not set to an instance of an object
  at ActionGroupsExtended.AGXFlight.LoadVesselDataFromPM (ActionGroupsExtended.ModuleAGX rootAGX) [0x00000] in <filename unknown>:0 
  at ActionGroupsExtended.AGXFlight.Update () [0x00000] in <filename unknown>:0 

It's the only parts (the fairing bases) that generate this error yet... I will have to check with others.

Do you think it's an AGX issue or SSTU, or both? That's really curious.

Thanks

Edited November 16, 2016 by FrancoisH

[Shadowmage]

1 hour ago, AlphaKerman said:

Is there any ways to somehow edit the ablator heat shield durability? (.cfg file?) Because recently i started using Kerbol 64K, and their reentry speed is close to 5.4 km/s and it makes my kerbals toasted within few seconds of reentry 

The proper way is to increase the 'fluxMult' value in the parts 'SSTUModularHeatShield' module.

@PART[*]:HAS[@MODULE[SSTUModularHeatShield]]:AFTER[SSTU]
{
	@fluxMult *= 1.5
}

Can up that multiplier further if 1.5 is not enough.

What this does is make each unit of ablator carry away even more heat.  As the ablator use is determined by a curve keyed to heat values, this effectively increases the heat rejection at all given points along the curve, while keeping the ablator use constant (same heat input with more heat rejection = slower heat rise / less heat making it into the part / faster cooldown once past peak heating).

 

Although, as Jimbodiah points out, I believe the correct way to get proper heating in rescaled systems is to down-scale -all- stock re-entry heating;  the stock heating is setup to generate earth-level re-entry heating at about 1/4 of the velocity; so it is not at all cheating to reduce this value proportionately to your rescale (otherwise you will end up with heating -far- worse than what is experienced on real re-entries).

 

20 minutes ago, Jimbodiah said:

Yes, but you can adjust heat production in the ksp settings which might be easier. Else use this (change to reflect the mod you are using or just remove).

@PART[*]:HAS[@MODULE[SSTUModularHeatShield]]:NEEDS[RealSolarSystem]:AFTER[SSTU]
{
    @RESOURCE[Ablator]
    {
	    @amount *= 3
	    @maxAmount *= 3
    }
}

 

That patch might work to increase ablator resource (not sure, as it gets manipulated by the heat-shield module when changing types, so the patch might not stick), but increases overall mass of the part.  Also would not do anything about the increased heat load on the heat shield from the faster temps -- as my module is designed to allow the part to overheat even when there is still ablator on it (peak heat), merely upping the ablator might not fix the problem.

I haven't tested the heat shields outside of stock though... so they may work with merely increased ablator (but shouldn't... the increased peak heat should overload the shield, and things should still explode...).  You probably know better than I do on that, so if I am wrong (and increasing ablator does allow them to function in rescales), please let me know so that I can fix the plugin code to work as it should.

 

 

Also a bit more playing around with texturing the torus parts...

More fun with normal maps; have pushed them about as far as they can go, there is not much more effect that a normal map could do.  For reference, that is a standard torus mesh, all of the beveling and bulging is part of the normal map.

1 minute ago, FrancoisH said:

Hello there,

Before submitting a bug as I did yesterday for something not related to SSTU, I would like to ask here for a clue

I do like a lot Action Groups Extended as it improve greatly your capacity to create actions, even in flight.

But, with the SSTU fairing bases, it generates a flow in my log file, enough to make the game freezing every second.

LOG 17:27:09.317] AGX Flight Update Error 7i System.NullReferenceException: Object reference not set to an instance of an object
  at ActionGroupsExtended.AGXFlight.LoadVesselDataFromPM (ActionGroupsExtended.ModuleAGX rootAGX) [0x00000] in <filename unknown>:0 
  at ActionGroupsExtended.AGXFlight.Update () [0x00000] in <filename unknown>:0 

It's the only parts (the fairing bases) that generate this error yet... I will have to check with others.

Do you think it's an AGX issue or SSTU, or both? That's really curious.

Thanks

More than likely is an issue in AGX -- I don't do anything strange with action groups in my plugins.

[FrancoisH]

3 minutes ago, Shadowmage said:

More than likely is an issue in AGX -- I don't do anything strange with action groups in my plugins.

Even with my really low skills in parts development, I think you're right, but as I don't like things not working, I prefer to ask and get all info I can

AGX is widely used and it would be a shame if I couldn't use it with my beloved SSTU parts

Thanks for your answer.

[Shadowmage]

Just now, FrancoisH said:

Even with my really low skills in parts development, I think you're right, but as I don't like things not working, I prefer to ask and get all info I can

AGX is widely used and it would be a shame if I couldn't use it with my beloved SSTU parts

Thanks for your answer.

Chances are you just need to report it to Diazo; he's a pretty good modder and can probably fix whatever the problem is, or at least he can tell you (or me) what my code is doing wrong if it turns out to be SSTU related (I don't think it is, but is still a possibility).

So, you might not be able to use them together -right now- and may need to merely wait for an updated release of one mod or the other -- don't lose hope

[FrancoisH]

Just now, Shadowmage said:

So, you might not be able to use them together -right now- and may need to merely wait for an updated release of one mod or the other -- don't lose hope

My kerbal adventure is a on-off story. I come back after major releases... Now that I can load (almost) what I want without worrying with multiple tools (to unlock x64, to reduce texture sizes, etc...) I'm quite happy and will try to stick a bit longer.

So I never lose hope. I love this game.

[FrancoisH]

1 hour ago, Shadowmage said:

Chances are you just need to report it to Diazo; he's a pretty good modder and can probably fix whatever the problem is, or at least he can tell you (or me) what my code is doing wrong if it turns out to be SSTU related (I don't think it is, but is still a possibility).

He'll have nothing to update... I just had to get rid of Procedural Fairings and it's done... The lastest updates all fairings including yours and is the cause of th bug. I had it before your fairings were available. Thanks.

[Shadowmage]

You guys probably are sick of seeing the technical images... but some of this stuff is just so neat that I have to share   (I also find it neat that I'm still learning new techniques for modeling + texturing, things that I just didn't know were possible, or had no idea how to implement)

This is some of what a properly setup normal map can do for an otherwise low-poly mesh;  contrast the top two torus with the bottom two, all four are using simple flat geometry for the torus mesh.  This render is done with normal map only, diffuse+specular textures have been disabled.  The effect wont' be as pronounced on the finished models as most of what is seen below comes from the specular highlights, where these models will have very little specular highlighting on the inflatable portions.

They can bring such smooth details and shading to otherwise simple models that most models just don't look correct to me without some sort of normal mapping.  Whether it be just a simple noise pattern of bumps, striations, etc, most models could be improved through a bit of normal mapping.

Granted, on these models I could have accomplished the same thing through adding more edge loops and carefully setting the vertex/edge/face shading, but it would have more than doubled the poly count of the torus meshes and increased the complexity of the UV and animation processes unnecessarily.

Same geometry as above, but with the diffuse and specular textures enabled (textures nowhere near finished, but the general layout is probably staying mostly as shown):

I'm not entirely happy with the segmenting (think it is a bit too much), but I'm not sure I'll be able to do it any differently due to how it is unwrapped/laid out (without adding a bunch more unique UV islands / increasing texture size / reducing texture resolution).  Got a few ideas I'm going to try out though, might be able to reduce the segmenting on the lower two torus by half.

 

[RedParadize]

Segmenting is fine, however the line is a bit thick, if you would make it thinner it would look better. Look at the size of the structure around the connecting tube, that should be your benchmark for size of details. On the same subject, if you subdivide the segmenting, the torus will look bigger. Think about Star wars destroyers: Smaller details = Looking bigger.

Having said that, it look awesome!

Edited November 16, 2016 by RedParadize

[FrancoisH]

Just a question about textures : Is there any "gold" texture like those on satellite? I thought there was a texture pack available for SSTU but probably am I wrong

[Shadowmage]

3 hours ago, FrancoisH said:

Just a question about textures : Is there any "gold" texture like those on satellite? I thought there was a texture pack available for SSTU but probably am I wrong

Yes, but probably not exactly what you are looking for.  The MFT tanks should all have a 'gold' texture option, which with the shaders in use by KSP results in more of a 'shiny yellow' look to it.  Sadly I could not get any acceptable 'gold foil' looks without proper reflective shader support (they are possible to 'fake' through the diffuse channels, but look terrible on a moving object or non-fixed camera as the reflection does not change with perspective, environment, or lighting).

There was a texture pack for <=1.1 versions but it has not been updated after the changes to shaders on the fuel tanks.  I think @JoseEduardo was going to add it into one of his SSTU expansion packs, but unsure on the status of it at the moment.

[JoseEduardo]

7 minutes ago, Shadowmage said:

There was a texture pack for <=1.1 versions but it has not been updated after the changes to shaders on the fuel tanks.  I think @JoseEduardo was going to add it into one of his SSTU expansion packs, but unsure on the status of it at the moment.

in between GTA V, Elite Dangerous, and pending finishing this: http://imgur.com/a/HprcB and the stock engines conversion into clustered engines

I might also wait to include ABLaunchers and DIRECT tanks to it too...

EDIT: forgot to mention, it has improved already since this album was made

Edited November 17, 2016 by JoseEduardo

[Jimbodiah]

1 hour ago, JoseEduardo said:

in between GTA V, Elite Dangerous

Spoiler

pew pew

 

[Shadowmage]

Updated deploy animation sequences, with current texturing.  This is the 'final' rigging and animation that will be used for the parts, and the geometry at this point is complete (any further changes will require complete re-rigging of the models, due to the blendshape animations in use which do not tolerate mesh changes very well).  Notable changes from previous renders include making the segment lines a bit thinner, updated normal mapping on segments, and rotated the cloth noise texture 90' (helps with distortion in retracted state, and generally looks a bit better).

10m:

20m:  (noticed some z-fighting in the animation on the crew tubes that has been fixed up...)

35m:

50m:

Texturing is still only about 50% done; the torus meshes are the most complete and probably won't have too much more done to them, but the rest of the structure has not yet been touched aside from playing around with coloring and noise.  Will be adding a bit more detail to the central pillars / rotating sections, clean up the details on the counterweights, and possibly changing the external bracing to look less metallic.

Should be able to release all of these over this weekend.  Will include an initial balance pass on the configs so that they should be at least usable, and will try to do an initial USI-LS config as well (no idea how well it will be balanced).  Going to try and sneak in some time to clean up the solar panel shader as it has some...odd... issues that I noticed recently; going to require some additional dev tools to debug shaders, which apparently is still some sort of arcane voodoo requiring jumping through more than a couple hoops to get it set up.

Next week will be working on finishing up the force-based wheel implementation and at least getting it usable for the shuttle landing gear (SC-E) -- already was working last I used it, so probably won't take too much work to get it usable; far more effort will be put into cleaning up the edge cases and some of the less-desirable side effects (sliding on hills, multi-frame force smoothing, reducing/eliminating jitters when used in KSP).  Have most of next week and part of the week after off from work so should be able to make very substantial progress and hopefully even get it finished up to surprise Lo-fi when he returns (would make a lot of people in the KF thread very happy).

[mechanicH]

2 hours ago, Shadowmage said:

SC-E

@shadowmage that word  alone makes me  extremely happy. Thank you so much for working on it.

Forgot to ask, are you going to put in the option to inflate the HABs without rocket parts? 

Edited November 18, 2016 by mechanicH

[JoseEduardo]

On 11/15/2016 at 9:43 PM, Shadowmage said:

In the future please include logs with bug reports; saves considerable time in having to ask for them, and often can point out exactly what the problem is.

However you are in luck today as I was able to duplicate this bug with a simple craft. Have fixed the problem, and it will be available with the next update (likely this weekend).  Note, this fixes the nulref.  No clue what is causing your crashing, as I did not experience any crashes during testing.

The problem in this case was some back-end changes to the KSP code in regards to the setup of temporary debris objects; in this case they require that the rigidbody be manually assigned to the 'physicalObject.rb' field (in prior versions this field did not exist, or at least had an intelligent get method and would pull and cache the value automatically).  So now during creation of debris I manually assign the pO.rb field, and all is well.

 

Edit:  As far as crashing goes, apparently there is a pretty severe bug in vanilla KSP related to part highlighting, aero-fx, and aero-debug displays that can cause crashes after a few minutes of gameplay.

same issue, crashed twice shortly after deploying Orion's drogue chutes, here's the log: https://dl.dropboxusercontent.com/u/58212317/KSP (9).log

tell me if you need the crash logs as well

[tater]

I just had an LR81 engine firing (visual effects alone, not using fuel, or doing damage) as soon as the craft spawned to the launch site. Was "on" the whole flight. Functioned normally, but visual effect was always on. Might be other mods. Need to test clean.

Edited November 18, 2016 by tater

[Jimbodiah]

Another mod that uses a RealPlumes patch the wrong way?

[tater]

I don't have real plumes installed, but I suppose it could still conflict. I have TRAILS on now (a Gemini capsule), that's the only new parts mod I think.

Trails had a real plume cfg installed, which I yanked, and the problem went away.

Edited November 18, 2016 by tater