Jump to content

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


Shadowmage

Recommended Posts

Maybe the procedural SRB's thrust is a bit too large? I only want to build a Ares-I replica in my RSS-RF save...

Issue: MFT can't switch texture with the newest version. I'll test again some time later.

090af62a5670be1e.png

(as you can see, TWR starts at 4+ and ends at 13...

p.s. MechJeb has issues calculating delta-v

Edited by 01010101lzy
Link to comment
Share on other sites

43 minutes ago, Jimbodiah said:

Mechjeb twr is never correct in the vab, takw it to the launchpad. My experience is that it is off by as much as 20x.

In fact the TWR is right but the delta-v is not. It has a little bit more than what it showed in the vab.

 

1 hour ago, JoseEduardo said:

I'm pretty sure that's optimized for stock, not RSS/RO/RF, and what indicates that to me is the fact that it uses SolidFuel instead of PBAN or HTPB

In fact I'm using RFStockalike, so all SRBs are using SolidFuel. But yes it should have been optimized for stock, so for now maybe I should decrease the thrust and increase the Isp.

Link to comment
Share on other sites

@01010101lzy The SRBs are set to have a burn time of 1 minute regardless of size or shape.  If that's too much thrust, just bring down the thrust limiter.  The real shuttle SRBs burnt for over 2 minutes.

But SSTU doesn't have RF Stockalike configs yet, so everything is going to feel unbalanced.

@DarthVader the custom upper stages already have probe cores built in.  They don't have reaction wheels (deliberately), but they have plenty of RCS fuel for maneuvering.

Link to comment
Share on other sites

5 hours ago, 01010101lzy said:

Issue: MFT can't switch texture with the newest version. I'll test again some time later.

You need to update to the latest texture-set pack (see OP for link).  Delete your old texture-set directory and install the new pack in its place (if you have both installed, there may be conflicts).

Link to comment
Share on other sites

15 hours ago, stratochief66 said:

Nah, that is alright. Perhaps I will pick the current (or next) version of SSTU as the official one for RO, since there is still plenty of it that we still need to configure for RO. Spending more time to reconfigure to get the same function that already exists is sort of counterproductive. Perhaps when @JoseEduardo gets back and starts helping out again?

Sure :)  Or perhaps when I officially deprecate them I can submit a PR for it.  Did a quick test yesterday, and it looks like it wouldn't take too long to setup the replacement parts.

Link to comment
Share on other sites

Played around with making a viable low-part-count shuttle.  After a bit of mucking about with stock aero...strangeness... and splitting it into a few more parts than I would like... I think I have a set of prototype parts that is fairly viable.

Shuttle consists of 7 parts - cockpit+cargo bay, 2x wing, 2x elevon, 1x rudder, 1x propulsion unit.  Ended up splitting the engine section off due to how stock handles gimbals, and the elevons/control surfaces into separate parts for a cleaner lift/control setup.  Everything attaches with stack-nodes.

This craft mostly makes it to orbit.  Still need to play around with the COM setup on both the launcher and the shuttle itself.  Shuttle itself is fairly stable during glide, though I'm still working on the initial balance and prototyping of everything.

3GPPeaA.png

 

And... bit of prep work on RD-107/108

C0yv0el.png

 

Link to comment
Share on other sites

9 hours ago, Shadowmage said:

Sure :)  Or perhaps when I officially deprecate them I can submit a PR for it.  Did a quick test yesterday, and it looks like it wouldn't take too long to setup the replacement parts.

If you find the time at any point to replicate the proportions of the existing ones with the new system for RO, that would be awesome. That falls in the class of "things I am terrible at"

Link to comment
Share on other sites

13 hours ago, blowfish said:

@01010101lzy The SRBs are set to have a burn time of 1 minute regardless of size or shape.  If that's too much thrust, just bring down the thrust limiter.  The real shuttle SRBs burnt for over 2 minutes.

But SSTU doesn't have RF Stockalike configs yet, so everything is going to feel unbalanced.

I see, only one thing that I'm at minimum thrust in the picture.

p.s. Except for the SRB and pods, everthing else are RO.

11 hours ago, Shadowmage said:

You need to update to the latest texture-set pack (see OP for link).  Delete your old texture-set directory and install the new pack in its place (if you have both installed, there may be conflicts).

Got it, thanks.

Link to comment
Share on other sites

1 minute ago, 01010101lzy said:

I see, only one thing that I'm at minimum thrust in the picture.

Ah, I didn't see that.  It looks like a calculation error then, maybe an issue with the RO configs?

I couldn't reproduce without RO, but @Shadowmage I did discover that the burn time doesn't account for the thrust limiter ... I think this would be an easy change, just divide the burn time by (thrustPercentage * 0.01).

Link to comment
Share on other sites

so... does a separate propulsion unit means we can try making a Buran-alike? like, replacing the RS-25 with another engine? :)

wuld be interesting to try making a US Shuttle with Buran style rear section :P

one question, is is possible to have an alternate mesh (and toggleable) that removes the shoulders (and could possibly have a straight aft. section to place engines without being angled) or is that going to mess with the stock game/aerodynamics/FAR?

would be neat to have a option to switch between full shuttle or customizable engine section :P

Link to comment
Share on other sites

12 hours ago, StickyScissors said:

Gimmie gimmie gimmie! That shuttle stack looks a lot cleaner with the modular parts than some of the mods that are dedicated to shuttles :o

Those SRBs look a wee bit too tall, however

Aye, the SRB's are a bit too tall, but not overly so.  Could certainly use some slightly smaller ones from a thrust / dV perspective (that craft had like 5k dV, ~half of that from the SRB's).

 

11 hours ago, stratochief66 said:

If you find the time at any point to replicate the proportions of the existing ones with the new system for RO, that would be awesome. That falls in the class of "things I am terrible at"

Aye, I'll put some together to replace the ones being removed; you'll likely see them in a PR this weekend.  That is one of the...benefits(?) of how I've set things up, all of the models and assets for the modular parts are usable on their own, just needs a bit of positioning setup in the MODEL nodes.

 

6 hours ago, SpaceBadger007 said:

will the shuttle cargo bay be the same size as the biggest stock bay (give or take)?

It is actually 2 of the longest + 1 of the shortest stock bays in length -- the cargo bay is the entire length of the shuttle.

 

4 hours ago, Joco223 said:

I don't know why but this mod's lifter seem a litle bit overpowered for for stock? Or am i just imagining stuff?

Going to need a bit more information to even know what you are talking about.  What lifter?  (Or rather, which engines, tanks, and intended payload?)

 

3 hours ago, JoseEduardo said:

so... does a separate propulsion unit means we can try making a Buran-alike? like, replacing the RS-25 with another engine? :)

wuld be interesting to try making a US Shuttle with Buran style rear section :P

one question, is is possible to have an alternate mesh (and toggleable) that removes the shoulders (and could possibly have a straight aft. section to place engines without being angled) or is that going to mess with the stock game/aerodynamics/FAR?

would be neat to have a option to switch between full shuttle or customizable engine section :P

Possible, sure.  Will -I- be modeling them?  Not likely, at least not initially. 

I had briefly considered making an alternate propulsion module that was intended more for SSTO use; with a set of rapier/sabre/multimodal engines (and intakes in place of the OMS pods)... but then realized that I'm still not sure if I'm even progressing with the shuttle stuff -- had to make so many compromises just to get it usable... the entire situation leaves me feeling a bit... bitter.  Such as having to split the propulsion module off at all... there is no legitimate reason that should have been needed.  It was only needed to compensate for the buggy method that stock uses to calculate the gimbal direction; using the parts origin location compared to vessel COM rather than the gimbal transforms origin location compared to vessel COM.  Same with the wings tail, and control surfaces... there is no legitimate reason why they should need to be separate parts -- only because of bugs and poor aero 'guesstimation' of stock (that would be a 'simulation' that 'guesses' instead of simulates; maybe I expect too much that a physics simulator actually _simulate_ physics).  Heck, there is no legitimate reason why this -shouldn't- work as a single-part craft; only poor and/or buggy implementations in un-moddable and un-fixable areas of the game.  Going to stop now before I work myself up and decide not to finish those parts, or get myself banned for saying unkind things.....

 

8 hours ago, blowfish said:

Ah, I didn't see that.  It looks like a calculation error then, maybe an issue with the RO configs?

I couldn't reproduce without RO, but @Shadowmage I did discover that the burn time doesn't account for the thrust limiter ... I think this would be an easy change, just divide the burn time by (thrustPercentage * 0.01).

-Should- be an easy fix, but I cannot rely on the engine module always being present/initialized.  It was initially implemented this way, but was causing null-refs during a GetComponent<ModuleEngines>() call -- so I couldn't even -test- if the engine module was null (would crash while trying to find the module; probably because the event was being called while the module was in the process of being added, this was during an OnEditorShipModified event callback during vessel creation/load).

Will take another pass over it, but not sure of any other non-tick-based way of doing it (options are Events for event-based, or Update/LateUpdate/FixedUpdate for update-tick based; I try and stay away from tick-based stuff unless absolutely necesary).

Link to comment
Share on other sites

On Sunday, February 14, 2016 at 6:39 AM, 01010101lzy said:

A question: about how many triangles does each of your engine contain in average? I'm making new models but I don't want to crash others' computers...

<10k tris, per engine.  However, they use a simple box collider for their collision mesh (about as simple/performant as it gets; could only do better with a sphere collider).

Note that the HUS comes in at ~40k tris (~8k x4 engines, ~8k for the part itself).

Triangles really are not the main limiting factor in KSP -- it is physics (part of that being colliders).

22 minutes ago, blowfish said:

@Shadowmage that really shouldn't be the case with the gimbals.  Note that a single, on-axis RAPIER can provide roll authority by moving all the gimbal transforms independently.

It -shouldn't- be, but is.

The gimbal determines if it should invert the pitch/yaw axis output dependent upon if the COM for the vessel is above or below the COM for the part which contains the gimbal (not the actual gimbal transform, which it -should- be).

Note that ROLL is always correct / not inverted with COM, it is only the pitch/yaw inputs that change.

Simple test case -- take a Twin Boar motor as root part, and see what happens as you move the vessel COM above/below the part's COM.  When the vessel COM is below the PART COM, the PITCH/YAW inputs will be inverted for that gimbal.

Link to comment
Share on other sites

1 hour ago, blowfish said:

@Shadowmage that really shouldn't be the case with the gimbals.  Note that a single, on-axis RAPIER can provide roll authority by moving all the gimbal transforms independently.

Hmm... thinking a bit more on this, I -think- I have a solution where I can move the propulsion module back into the main body -- CHEATING.  (When all else fails... cheat).

Basically I can setup the main body segment with its reference transform/origin near the rear of the part, and use in-config ComOffset = 0, XX, 0 to set the COM up properly.  As the gimbal doesn't actually query the parts COM, but its reference transform location (e.g. base.transform rather than base.transform.position+(transformed)part.CoMOffset).

Will do some additional testing on this tonight to see if I can clean up that bit at least, and bring the part-count down to 6 for that craft (which is still 6x more than I would like...).

Link to comment
Share on other sites

Mmm... looking pretty tasty even without proper schematics.  Some stuff -will- be a bit off... but.. silly Russians... they just don't publish their rocket-related engineering blueprints apparently (still cannot find any good blueprints/diagrams/schematics... so proportions, measurement, and placement is all guessed at from various images... which thankfully there are at least a couple high-res ones available).

XSHVq0B.png

Nowhere near completed, still doing initial rough geometry layout... many things will be changed up a bit.  Still have the entire fuel plumbing to do as well (oxidizer plumbing is there... it just dumps right into the MCC).

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

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.

×
×
  • Create New...