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

[ComatoseJedi]

I don't think any of the cost balancing has been addressed yet. With getting the parts to work on 1.1 and his new tank features, I would dare say his plate is quite full. 

[SpaceBadger007]

Just a thought on your fairings, ever considered making the fairings bullet shaped or have different shapes? eg... 

Edited April 26, 2016 by SpaceBadger007

[GoldForest]

7 hours ago, SpaceBadger007 said:

Just a thought on your fairings, ever considered making the fairings bullet shaped or have different shapes? eg... 

The fairings are procedural. You make them the shape that you want.

[SpaceBadger007]

43 minutes ago, GoldForest said:

The fairings are procedural. You make them the shape that you want.

But you cant really make any curves just straight cones

.

 

[GoldForest]

Just now, SpaceBadger007 said:

But you cant really make any curves just straight cones

.

 

It's tough to do, but yes you can do curves. Not ones you're thinking about but they will be curves nonetheless. You just have to keep clicking and moving the fairing in little by little.

[GoldForest]

Anyone else having this problem? The srb is supposed to be white as is the fuel tanks. Only the fairing should be orange... This is bizarre....
 

[RedParadize]

never seen that before, did you install the texture folder as well ?

[GoldForest]

Just now, RedParadize said:

never seen that before, did you install the texture folder as well ?

yes

[Jimbodiah]

4 hours ago, SpaceBadger007 said:

But you cant really make any curves just straight cones

This is the reason I still use Procedural Fairings, plus some fairing pedals from Chaka Monkey with different shapes to the two standard ones. I'm always fighting with the stocks/SSTU fairings, plus they do not secure the payload like ProcFairings.

[Shadowmage]

3 hours ago, GoldForest said:

Anyone else having this problem? The srb is supposed to be white as is the fuel tanks. Only the fairing should be orange... This is bizarre....
 

Known issue; the texture-setting code for the stock fairings broke with 1.1 and I haven't had time to fix it properly yet.

[Theysen]

5 minutes ago, Jimbodiah said:

This is the reason I still use Procedural Fairings, plus some fairing pedals from Chaka Monkey with different shapes to the two standard ones. I'm always fighting with the stocks/SSTU fairings, plus they do not secure the payload like ProcFairings.

Last time I had ProceduralFairings installed in 1.1 they somehow automatically worked with the SSTU fairing bases.

[GoldForest]

2 minutes ago, Shadowmage said:

Known issue; the texture-setting code for the stock fairings broke with 1.1 and I haven't had time to fix it properly yet.

Thanks. Now to enjoy the Crayola rockets until it's patched. *gets and idea for a rocket*

[Jimbodiah]

Same on 1.0.5, the SSTU faring bases turn into PF compatible bases (they actually no longer work as SSTU fairings at all).

 

 

My new K365 rocket, a Duna Tourist ship with an atomic engine (Nertea) and droptanks, holding a 11-man capsule from LeBeau's Rocket Factory (the SSTU LAS fits like a glove). It uses 7x RS68 first stage and 3x RS25 second stage: boosters are for noobs  

 

 

Edited April 26, 2016 by Jimbodiah

[Shadowmage]

17 hours ago, Sudragon said:

Is anyone else having this problem?, It looks like tanks have had fairing controls removed.

The 'bug' is actually that the tanks are respecting the config settings for the mounts/models properly; but some of the mounts/models are not setup with the proper settings for fairings.

I'll take a look at a few of the mount types; I noticed a couple that should have had fairings enabled that did not (the skeletal types being the main ones).

 

15 hours ago, RedParadize said:

I have a balance issue to raise concerning the SRB, they are just too good. Unlike real SRB they present no security risk and they have a gimbal. There is no reason to go for anything else than a SRB for first and even second stage. 

I think the easiest way to fix this is to split the SRB in two family, gimbaled or not. Gimbaled SRB would be much more expensive than the regular one.

I don't know if its possible but it would be cool to disable the trust limiter bar, that would be a quite acceptable nerf as well.

 

14 hours ago, RedParadize said:

@blowfishIndeed. My post is mostly taken from the Ares I advanture, so is my conclusion. SRB are reliable, but from what I read they present a higher risk if failing. Neverless, you are right, my argument is about gameplay balance, not realism. Stock SRB, while being too cheap to my taste, do not have gimbal and thats a balancing factor. I believe it would be good if SSTU would balance SRB accordingly.

Does SSTUVolumeContainer have a cost multiplier field ? it would be quite easy to balance SRB if it had one.

First I must note that I have not even begun working on cost balancing of -anything- yet.  Whatever values are present on parts is a 'first case best-guess' type setup.

Well, there are a couple of ways that you can solve this for your personal games.

1.) Each ModelData has a field for 'cost'.  Currently these are all set to zero.  This is a cost, per model definition, that would be added to the cost of the part.  You could have some nozzles/bodies/etc cost more than others.  Check in the SSTU/Data/ModelData folder for these model definition files.
2.) The gimbal range can be adjusted on a per-nozzle basis; so you could have some nozzles with more or less gimbal range than the others (already setup that way, some have larger ranges).  You could make these nozzles cost more than the others.  Check in the part config files for these
3.)  VolumeContainer has a 'costPerDryTon' setting (per CONTAINER) that determines the cost per ton of tankage mass for that part; this is in addition to the 'cost' from #1.  Currently this is 750f per 1000kg (default value), roughly equivalent to the dry cost for some of the stock LFO tanks.
4.) A custom 'tankModifier' type could be made specifically for SRBs that had an additional dry-mass multiplier factor; not really needed though since #3 exists and is a less invasive solution.

 

However as noted, SRBs really are cheap and very effective, with fairly good reliability and safety history.  When it comes time for the balance pass (no, were not quite there yet) I'll make sure these are in-line with the stock SRBs (possibly a bit more expensive because of the gimbal and built-to-order setup) as far as cost / tankage ratio / mass ratio goes.

 

16 minutes ago, Theysen said:

Last time I had ProceduralFairings installed in 1.1 they somehow automatically worked with the SSTU fairing bases.

There -was- a patch written by  that @JoseEduardo that converted the SSTU fairings to use ProceduralFairings.  However this apparently was broken during the 1.1 update by some changes to ProceduralFairings code/modules, so you'll need to wait until Jose or someone else has time to fix the patch up.  I don't use ProceduralFairings, so likely won't be me.

 

[ComatoseJedi]

I say keep the SRBs the way they are. It's not called a "modular" part for nothing. When you are replacing every SRB ever made, it has to be flexible. 

[Shadowmage]

19 hours ago, RedParadize said:

So... the RL10B-2 is a fuel generator at sea level? lol

As ISP is a measure of imparted velocity per-mass-unit exhausted, I think it more refers to the fact that you are spending more energy pumping and combusting the fuel than you are getting as effective output.  You would be better off just throwing the fuel out the rear end...

Though more likely what it means is that I didn't have all the parameters setup properly

[Shadowmage]

General Development Update:

Rapidly narrowing down the list of things on the 1.1 update TODO list ( https://github.com/shadowmage45/SSTULabs/issues/203 ).  All of the larger things left are all Series-E / wheel / leg related.

So... the focus for this week will be getting the SC-E wheel/landing gear parts working.  Undecided if I want to continue/finish developing a custom wheel solution or not; there are a couple... issues... with my custom solution that I'm not entirely sure I'll be able to figure out in a timely manner.  (Unless there is a Unity/physx expert in the crowd that felt like pitching in some of their expertise?)  Most notably -- how to handle suspension that is at an angle to the ground without applying horizontal momentum to the vehicle?  Already have a fairly good sideways grip/slip model in place and basic suspension mechanics.  Need to figure out the forwards slip/grip/traction/friction model (based on wheel mass vs. rpm vs. suspension down force vs. side-slip angle), and solve the angled suspension-force-application problems.

Quick-and-dirty image to explain force application problems:

Notice how the net suspension force points somewhere not straight upwards; this results in a general velocity increase in the vehicle whenever the wheels are not aligned perfectly vertically.  This can be seen if, for example, the compression on the front wheels is more than the rear, resulting in all suspension vectors pointing slightly forwards, and thus imparting a forward momentum to the craft.

My initial... thoughts... on how to solve this would be to only apply the upwards (anti-gravity) portion of the suspension force-vector unless the wheel is -also- colliding with something in front of the vehicle.  But...seems there are some holes in that logic...

 

Working very well in the Unity-Editor so far for basic test cases... but did not work very well when I did a quick port/test into KSP (meshes/positions kept ending up.... incorrect).  Could have been a hierarchy problem or code problem... didn't play around with it enough to figure it out (other than to see that it wasn't ready/working yet).

Will likely just re-rig the landing gear to work with the stock module and attempt to use it for now; really not fond of the stock setup, but it should be workable now that I've split the models off to their own parts.  Will likely a ton of reworking of the model hierarchy in order to get things compatible with the stock module (which requires re-rigging and re-animating everything... ughghhghgh...).  Alternatively I might try and use the KF wheel system if/when it is updated for 1.1; apparently Lo-fi had at least some of the KF wheels semi-working in-game; and it is likely that his module will be a better fit for my parts than the stock module.

 

Anyhow... you guys keep playing with things, keep finding bugs and issues, and I'll keep squashing them.  Judging by some of the craft you all are posting it seems like most of the parts and functions are fairly stable and problem free, but given the complexity and interaction with some of these parts I'm sure there are still a few large bugs hiding in the cracks somewhere.

With any luck we'll be able to start moving onto the initial balance passes next week, and the first stable releases probably a couple weeks after that.  Good stuff

 

[Akira_R]

Very nice, what are your goals and vision for balancing and what are you planning to balance against?

For instance will they be balanced purely for use in RO/RSS, or will they be balanced for stock with patches for RO/RSS, or no RO/RSS support, if balanced against stock will they be balamced to achieve larger mass fractions? That kind of stuff, how do you see your pack being used?

Edited April 26, 2016 by Akira_R

[Shadowmage]

1 hour ago, Akira_R said:

Very nice, what are your goals and vision for balancing and what are you planning to balance against?

For instance will they be balanced purely for use in RO/RSS, or will they be balanced for stock with patches for RO/RSS, or no RO/RSS support, if balanced against stock will they be balamced to achieve larger mass fractions? That kind of stuff, how do you see your pack being used?

Well, I don't use RO/RSS, so they certainly won't be default balanced for use there, nor will the default balance be for any other system rescale.  So.. stock'ish I would guess.

Aside from that... no clue.  As has been stated, numerous times, I haven't even started on the balancing work yet (which includes figuring out what to balance it against).

The -intent- of the pack is to merely reduce part-count for stock-alike craft designs.  So in that regard everything should have the same payload fraction/mass fraction/fuel fraction as stock parts, with perhaps some parts performing slightly better or worse (as many stats are derived from real-life values they often fall a bit on either side of the 'stock balance' line).

[blowfish]

@Shadowmage I think the subtlety here is that the spring force is between the wheel base and the rest of the craft, not between the ground and the wheel.  Everything having to do with the suspension should be internal to the wheel assembly (no need to actually apply any forces in the rigidbody sense I don't think), and, for a non-rolling wheel, the external force from the ground should be strictly normal to the point of contact between the wheel and the ground.

[Akira_R]

11 minutes ago, Shadowmage said:

Well, I don't use RO/RSS, so they certainly won't be default balanced for use there, nor will the default balance be for any other system rescale.  So.. stock'ish I would guess.

Aside from that... no clue.  As has been stated, numerous times, I haven't even started on the balancing work yet (which includes figuring out what to balance it against).

The -intent- of the pack is to merely reduce part-count for stock-alike craft designs.  So in that regard everything should have the same payload fraction/mass fraction/fuel fraction as stock parts, with perhaps some parts performing slightly better or worse (as many stats are derived from real-life values they often fall a bit on either side of the 'stock balance' line).

Ok cool, for some reason I thought this pack was meant to be used in RO lol.

I was just curious what your plans are, thank you for the response.

[Shadowmage]

4 minutes ago, blowfish said:

@Shadowmage I think the subtlety here is that the spring force is between the wheel base and the rest of the craft, not between the ground and the wheel.  Everything having to do with the suspension should be internal to the wheel assembly (no need to actually apply any forces in the rigidbody sense I don't think), and, for a non-rolling wheel, the external force from the ground should be strictly normal to the point of contact between the wheel and the ground.

Sadly this isn't using Unity WheelCollider components; so the only way to make the suspension 'work' is by applying forces (as far as I know anyhow).  The implementation so far is entirely raycast and force based; as far as I am aware it is 'improper' to manually set any position/rotation/velocity components on a non-kinematic rigidbody.  I'm not even worrying about the visual representation of the suspension or wheel mesh locations; those are easy enough to sort out based the suspension compression/raycast length.  At this point I'm mostly worried about how to properly simulate the forces from a compressed suspension setup from an angled wheel;

E.G.  I'm not sure how to keep the rigidbody suspended above the ground without applying forces.  Nor am I aware of how to apply the forces from an angled suspension properly to not add directional input to the vehicle.  I might be able to zero out any non-gravity-vector related component of the force.... but then you would lose the ability to use wheels/etc as bumpers as they would only act in the direction opposite to gravity.

 

[blowfish]

1 minute ago, Shadowmage said:

Sadly this isn't using Unity WheelCollider components; so the only way to make the suspension 'work' is by applying forces (as far as I know anyhow).  The implementation so far is entirely raycast and force based; as far as I am aware it is 'improper' to manually set any position/rotation/velocity components on a non-kinematic rigidbody.  I'm not even worrying about the visual representation of the suspension or wheel mesh locations; those are easy enough to sort out based the suspension compression/raycast length.  At this point I'm mostly worried about how to properly simulate the forces from a compressed suspension setup from an angled wheel;

E.G.  I'm not sure how to keep the rigidbody suspended above the ground without applying forces.  Nor am I aware of how to apply the forces from an angled suspension properly to not add directional input to the vehicle.  I might be able to zero out any non-gravity-vector related component of the force.... but then you would lose the ability to use wheels/etc as bumpers as they would only act in the direction opposite to gravity.

 

I wasn't talking about wheel colliders.  Either way, the force exerted by the ground on the wheel should be perpendicular to the ground (again, if it's not rolling) ... is it even possible to figure out the angle to the ground based on the position of the wheel?  The angle that the wheel is attached at should not matter, only vector between the center of the wheel and the point of contact to the ground.  Of course, that should be determined relative to the position of the wheel. which will be affected by suspension, but the suspension itself should not exert and external forces on the wheel assembly (rather, it's an internal thing that affects the position of the wheel's center relative to the suspension parent).

[Shadowmage]

40 minutes ago, blowfish said:

I wasn't talking about wheel colliders.  Either way, the force exerted by the ground on the wheel should be perpendicular to the ground (again, if it's not rolling) ... is it even possible to figure out the angle to the ground based on the position of the wheel?  The angle that the wheel is attached at should not matter, only vector between the center of the wheel and the point of contact to the ground.  Of course, that should be determined relative to the position of the wheel. which will be affected by suspension, but the suspension itself should not exert and external forces on the wheel assembly (rather, it's an internal thing that affects the position of the wheel's center relative to the suspension parent).

Hmm...

Pretty sure I can get the angle between the wheel/suspension vector and the ground from the raycast; I believe it is the hit.normal.

Obviously there is something fundamental that I'm missing or overlooking here as real angled suspension does not impart forward velocity once the suspension has 'uncompressed' (and during decompression it depends on if the wheels are free to roll or 'locked'; if all wheels are 'locked' the suspension would either not decompress or force the wheels to slide (which would/could impart momentum to the vehicle)).  Probably something simple...

Off to do more reading and research   (bullet/jBullet, rigsOfRods, few other open-source solutions I can peek at)

 

Edit:  Just realized (at least part of) what I was missing.  When at stable-state the suspension would -not- exert any lateral force; lateral forces would only be exerted while the suspension is actively decompressing (and while actively compression the lateral force would be opposite).

Hmm... going to need to track previous suspension compression/forces and integrate vs. those + the new values.... ahh... physics are so... wonderful?

Edited April 26, 2016 by Shadowmage

[blowfish]

9 minutes ago, Shadowmage said:

Obviously there is something fundamental that I'm missing or overlooking here as real angled suspension does not impart forward velocity once the suspension has 'uncompressed' (and during decompression it depends on if the wheels are free to roll or 'locked'; if all wheels are 'locked' the suspension would either not decompress or force the wheels to slide (which would/could impart momentum to the vehicle)).  Probably something simple...

Evidently I'm not doing a very good job of explaining this, but I'll try one more time: The suspension exerts two equal and opposite forces: one on the suspension root, and one on the wheel hub.  Those forces are both exerted on the same part, so it results in no net force.  The only external force on the part is from the ground on the wheel (ignoring joints to other parts of course), which does not care about what the suspension is doing except insofar as it affects the position of the wheel's center relative to the suspension parent.

My advice: for a first pass, treat the suspension as completely rigid.  The tire itself should act as a (very rigid) spring (and even rigid wheels do to an extent), so that's where you will get your restoring force from.  Once that's all worked out, then maybe think about how the suspension affects the position of the wheel due to internal forces.