Jump to content

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

Shadowmage

By Shadowmage
in KSP1 Mod Development

 Share

Recommended Posts

OscarJade

OscarJade

Posted
Posted
On 1/16/2018 at 9:14 PM, Jimbodiah said:

Those should be the three folders you have moved to the gamedata directory. You also need the Community Resource Pack by the way.

Thank you very much! :)  One more question: I’m having problems docking with the SSTU docking ports. Do both ports have to have ‘docking port snap’ enabled? I’ve tried it both ways, and they just bounce around together, magnetically attracted, but won’t latch (?). Thanks for your help

Link to comment
Share on other sites
Shadowmage

Shadowmage

Posted
  • Author
Posted

Been a bit quiet of late, as I've been taking a bit of a breather from KSP.  Still working away at the update/rewrite on the ModularPart setup, but have been focusing more on 'long-term' development rather than 'get things done now'.  Little bit slower progress, but much more friendly code -- well documented, more robust, more expandable/compatible.  Still at least a month out, likely a bit longer.  At this point I have the core parts of the module written, but still need to work in most of the 'extra' features such as RCS positioning, solar panel integration, and animation handling.  Also still working on converting all of the model definitions and texture set configs, as how those are specified has changed quite a bit; this will likely be the most time consuming part of the project, as there are so very many files to update, and quite a bit of information to update in each file / model-def.  Lots of new information is needed in the model definitions to properly support the new features, so that adds even more time to updating each definition, but is necessary for the intended feature-set (e.g. can't put RCS on a part unless you know -where- on the part to put them, that info needs to be part of the model definition so it can be used by the rest of the system).

Current intention is to keep working on the rewrite until it is finished, working, and released, and then back into the grind of updating textures for PBR + recoloring.  Any new parts/models will unfortunately have to wait until after this as I really don't have enough dev time to be splitting it between multiple work-intensive projects.  There will also be some fairly major updates to TU during this time, but most of those are geared towards its stand-alone use and shouldn't impact its use in SSTU.

 

Have cleaned up a couple of issues in the outstanding versions over the past weeks though, and will hopefully be pushing out a new release over the weekend.  Should also have an updated TU, KSPWheel, and KF release, as they've all seen some bugfixes over the past weeks/months that need to be published (and those will likely come first, as they'll need to be updated in order to include the fixed versions in the SSTU release).

Notably, @Jimbodiah sent in a PR to add/update quite a few resources in the MFT tanks, as well as a couple bugfixes regarding the ISDC part's engine models.

 

Link to comment
Share on other sites
Shadowmage

Shadowmage

Posted
  • Author
Posted
On 1/19/2018 at 3:38 PM, SQUAD said:

Engine plates come in sizes from 1.85 through 5m, and the player can independently select from several node configurations (single, double, triple, quad, 6x1, and 8x1) with symmetry support.  The plates also include mesh switching that allow for up to five different lengths per engine plate.


So apparently the stock 'engine clustering' will be nothing like the SSTU setup.  Sounds like their 'clusters' are actually just lots of single-engine parts used in symmetry/mounted on these new 'engine plates'... yuck.  So fundamentally no different than stock-based 'engine clusters' in current versions.   If they were going to put the work in to make engine clusters.... why even consider this half-baked solution?  Who really wants the additional part-count from using individual engines?  What benefit does that really bring to the game/community?

 

Link to comment
Share on other sites
RaiderMan

RaiderMan

Posted
Posted

trying to build a liquid fuelled first stage for the ares I launcher, using liquid fuel/lox or hydrolox, and I just cannot seem to manage something that can get off the pad without use of not just one, but two F1 engines.

I'm using the mft-a-standard tank with the following settings: 
fuel type-can be anything as long as it gets the thing off the pad
body length 3.00x
body variant-kerolox
diameter-5.000
v.scale-1.0317 

engine mount used: sc-eng-f1 with the following settings:
layout-double
mount-generic
mount diam-5.0000

please help?

Link to comment
Share on other sites
tater

tater

Posted
Posted
55 minutes ago, Shadowmage said:


So apparently the stock 'engine clustering' will be nothing like the SSTU setup.  Sounds like their 'clusters' are actually just lots of single-engine parts used in symmetry/mounted on these new 'engine plates'... yuck.  So fundamentally no different than stock-based 'engine clusters' in current versions.   If they were going to put the work in to make engine clusters.... why even consider this half-baked solution?  Who really wants the additional part-count from using individual engines?  What benefit does that really bring to the game/community?

 

If they had a robust system of possible part faults and failure modes, then unique parts might actually matter. We know, however, that squad thinks random failures are anathema, so it just allows an n engine cluster adding n+1 parts.

It is certainly needed for the stock game, which has no engine clustering, though.

The other issue is that the career system is so fubar that I’m not sure what it adds there. Seems like a revamp is required to make different strategies a thing (more, smaller engines, vs developing larger engines).

Link to comment
Share on other sites
Jimbodiah

Jimbodiah

Posted
Posted
2 hours ago, RaiderMan said:

trying to build a liquid fuelled first stage for the ares I launcher, using liquid fuel/lox or hydrolox, and I just cannot seem to manage something that can get off the pad without use of not just one, but two F1 engines.

please help?

Stock, rescaled/rss system?

What is the dV of the upper stage? I take it you are using a 3.75m hydrolox tank with J2X engine?

You should not need a 5m first stage. And if you are playing stock, you should not need F1 engines for anything basically.

Link to comment
Share on other sites
RaiderMan

RaiderMan

Posted
Posted

stock, and I managed a miracle. first stage is using the rd-181 motor, x4 cluster, and the tank diameter down to 3.75..and I left the upper with the original configuration, which has a 3.75 hydrolox tank and a j2x engine.

 

..I swore I'd beat this thing into submission.

Link to comment
Share on other sites
Akira_R

Akira_R

Posted
Posted

@Shadowmage Just some further thoughts on that multi-node docking mechanism (I realize it'll be many months before it is worked on). What about a part that has two docking port type models with a slider that will adjust the distance between them? It could have one version with both ports the same for 'ambidextrous' use and a version where the ports on either end a different (different sizes, or different styles) for one orientation only use. You could also have a version with a purely aesthetic third docking port model that stays in the center, you know just for kicks.

Link to comment
Share on other sites
Mike`

Mike`

Posted
Posted
19 hours ago, Shadowmage said:


So apparently the stock 'engine clustering' will be nothing like the SSTU setup.  Sounds like their 'clusters' are actually just lots of single-engine parts used in symmetry/mounted on these new 'engine plates'... yuck.  So fundamentally no different than stock-based 'engine clusters' in current versions.   If they were going to put the work in to make engine clusters.... why even consider this half-baked solution?  Who really wants the additional part-count from using individual engines?  What benefit does that really bring to the game/community?

 

Well, one small thing that comes to mind is support by Testflight. Supporting testflight/manipulating the thrust of single engines of a cluster would probably require some extra work/an API, if it is easily possible at all.

Link to comment
Share on other sites
StickyScissors

StickyScissors

Posted
Posted (edited)

Already posted in the Jimbo's thread, but figured i'd get a faster/more in-depth response here. Im trying to replicate this (Aluminum and Metallic blue):

 -snip-

But all i end up with is this, no shinyness, just solid colors and a bit of glare:

-snip-

Using the same RGB/specular settings, and using either default DX9 or forcing DX11 with -force-d3d11. Probably overlooked some details when updating after being gone for a while? but im not sure

-

Edit: Game problem fixed, my reading problem...not so much :I

Edited by StickyScissors
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.

×
 Share
Go to topic listing
×
×
  • Create New...