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

[JoseEduardo]

1 hour ago, Jimbodiah said:

Been playing with the SSTU mod and having a blast. Built the SLS and Delta IV with the Orion capsule, Just awesome...

A couple of things I run across, maybe for future consideration:

- RCS on the Orion CM/SM are not balanced, they make the ship wobble all over the place, is hell to dock with anything. If I disable the RCS on SM and CM and add four stock one just under the SM collar, it is balanced perfectly. Perhaps make the actual rcs point come from someplace other than the actual graphical representation?

- A possibility to have chutes integrated into the top cone, or something that can be added without making it look funky.

 

Parts folder things:
- The largest engines do not show up under my stock-engines tab, only the SSTU tab
- Could you add a tab with all your other parts, just like with the engines?
- Could you make a manufacturer tab so all your parts show up in one place when filtering on brands?

there's a docking port with built in parachute

59 minutes ago, DarthVader said:

Lovely mod, so many options, maybe more craft files?

these are being made

[RedParadize]

Hello

I have a bug to report: The weight of new tanks reset at lunch/load.

Outside of that, its qulte nice! I will have few question for you guys, but I will wait until forum get a bit more stable.

Thanks 

Edited November 30, 2015 by RedParadize

[Jimbodiah]

jose, how would that work?

[JoseEduardo]

6 hours ago, Jimbodiah said:

jose, how would that work?

there are two docking ports in the utility tab, one without parachutes (for stations) and one with parachutes (for Orion), they are visually the same, so you need to check the part title to check which is which, just grab the one with the parachute (the parachute staging icon will show up) and put it atop Orion

[Jimbodiah]

I was talking about a parachute for the boosters that seperate, not the main craft.

[JoseEduardo]

ah, then no, I asked shadowmage about that a few months ago and it would require a new separate part and some rework

you can however use RealChutes and get the cone parachute and use it on top of the SRBs (just need to change the top endcap option), I guess you could use the old CSS one too but I don't think that will work...

(with top cone I thought you meant like Orion's top cone )

[Shadowmage]

2 hours ago, JoseEduardo said:

ah, then no, I asked shadowmage about that a few months ago and it would require a new separate part and some rework

you can however use RealChutes and get the cone parachute and use it on top of the SRBs (just need to change the top endcap option), I guess you could use the old CSS one too but I don't think that will work...

(with top cone I thought you meant like Orion's top cone )

Thanks Jose for offering up some alteratives

Parachutes in SRBs = no.  Not until/unless stock supports runtime module switching (otherwise, there is no way to remove the parachute module when the 'flat' nosecone is selected).  There is also the same old problem of you cannot have multiple staging actions in the same part.

Parachutes integrated into command modules = looking into this for a near-future update (likely within the month).  Will likely be integrating docking port and parachutes into SC-B-CM, as well as having them integrated into the 1.875m + 2.5m command pods

 

12 hours ago, RedParadize said:

Hello

I have a bug to report: The weight of new tanks reset at lunch/load.

Outside of that, its qulte nice! I will have few question for you guys, but I will wait until forum get a bit more stable.

Thanks 

Thanks for the report, will look into it.  I must say I honestly don't think I tested the mass stuff.  Spent far too much time reworking the fairing modules...   Will have this fixed up for the next release.

 

 

In other news; the upgrade to Unity 5 and the new Physically-Based-Shader system looks.... very interesting.  I'm not normally one to get excited about rendering improvements... but some of these are... huge.  Heh... sooooo many shader options.  If they are all supported (which they should be...), will open up so many new options for part aesthetics

http://blogs.unity3d.com/2015/02/18/working-with-physically-based-shading-a-practical-approach/

 

 

And, regarding this weeks development plans/schedule:

• Fix up forum OP - re-add images/etc.  Seriously don't understand why they had to break everything in their forum conversion ( how hard is it to write a script to convert bb-code to the new html style?  not bloody hard at all)
• More work on Upper Stage stuff
  • Finish off textures
  • Add texture switch support
  • Custom RCS blocks
• Convert SSTUCustomFuelTank parts into a single in-editor part with free-diameter scaling -- WARNING - this will break any craft using existing fuel tanks.  Will also be adding support for all engine mounts to the fuel tanks, and support for exising fuel-tank 'endcaps' to be used as mounts for the engine clusters / upper stages.
• If time allows, start working on custom plugin(s) for upcoming CM reworks.  This will involve at least a custom parachute plugin (needs drogue + main parachute support, with support for 4 total drag cubes rather than just 2)..

 

[MrMeeb]

I agree about the stupid BB code thing...my cooperation forum post is total broken and I don't want to have to fix it 

[RedParadize]

3 hours ago, Shadowmage said:

Thanks for the report, will look into it.  I must say I honestly don't think I tested the mass stuff.  Spent far too much time reworking the fairing modules...   Will have this fixed up for the next release.

Thanks! If you manage to fix them before your next release, could you tell me how to fix them?

[Shadowmage]

3 minutes ago, RedParadize said:

Thanks! If you manage to fix them before your next release, could you tell me how to fix them?

Fairly certain that I'll manage to get them fixed, likely in the next day or two.  However, it is nothing that you'll be able to fix on your end -- is a plugin-side / code change that needs to happen.

Chances are though that there will be other unrelated changes in the .dll that will prevent it from being published until the next full release -- such as I have already started on the fuel-tank conversion, and have changed the existing fuel-tank modules name, which would require publishing the updated configs as well, and updated RO configs, and I do not have time during the week to pack up full releases. 

Really wish I could get to the 'public release' stage; as once there, I will have no problem releasing out-of-cycle dev updates (as they will come with no testing, etc, just package-and-release).  Currently though, with the 'dev' releases also being the 'public' releases, I have to at least -try- to test things prior to packaging and release; and I do not have the 4-6 hours necessary for testing and cleanup on weekdays (4 hours is often more time than I have in the evenings for doing dev stuff, not to mention that is that many more hours that I'm -not- doing actual dev stuff....).

[RedParadize]

If you are looking up for someone to test your stuff. I could probably do that for you. I do understand that testing is only a very small part of the full package/cleanup process, I am just offering.

[JoseEduardo]

5 hours ago, Shadowmage said:

• Convert SSTUCustomFuelTank parts into a single in-editor part with free-diameter scaling -- WARNING - this will break any craft using existing fuel tanks.  Will also be adding support for all engine mounts to the fuel tanks, and support for exising fuel-tank 'endcaps' to be used as mounts for the engine clusters / upper stages.
• If time allows, start working on custom plugin(s) for upcoming CM reworks.  This will involve at least a custom parachute plugin (needs drogue + main parachute support, with support for 4 total drag cubes rather than just 2)..

well... I'll wait for the new tanks to have the .craft files done, got more time for Just Cause then

about the parachutes, I know you don't want dependency, but RealChutes allows for drogue and main chute, you only need two transforms, one for the drogue and one for the main, and Bobcat and Raidernick released their Soyuz with both, drogue and main chutes in one part for stock... maybe you could have a working stock version and a patch for realchute?

[Shadowmage]

1 hour ago, RedParadize said:

If you are looking up for someone to test your stuff. I could probably do that for you. I do understand that testing is only a very small part of the full package/cleanup process, I am just offering.

Well, if you are using the current dev releases, then you -are- testing to help stuff

It is less that I need testers, and more that I need a separation between dev (untested, updated often) and public (tested/stable/not updated often) releases, which currently I do not have.  As a -compromise- I have limited the dev-release schedule to once per week and implemented a (short/internal) pre-dev-release testing period -- however, that puts us in the situation we are in now -- no ability to do out-of-cycle releases due to lack of time for testing (due to needing testing on dev releases, due to them being the public releases as well).

So, for the time being, sadly, there is not much to be done.  You are currently using the -testing- versions, and as such there will be bugs (as the few hours that I can dedicate to testing is nowhere near enough to re-test all of the features).  So... please be patient with the releases until I can get the proper public/dev release schedule setup (need a stable set of parts/plugins first, nearly there).

 

46 minutes ago, JoseEduardo said:

well... I'll wait for the new tanks to have the .craft files done, got more time for Just Cause then

about the parachutes, I know you don't want dependency, but RealChutes allows for drogue and main chute, you only need two transforms, one for the drogue and one for the main, and Bobcat and Raidernick released their Soyuz with both, drogue and main chutes in one part for stock... maybe you could have a working stock version and a patch for realchute?

No way to release a 'stock working' version, if the parachutes don't work in stock   (No, I'm not going to compile/release two separate models with different parachute setups.. waste of time; would rather do it once, properly).

Hence the need for a custom parachute plugin.  I would consider bundling others plugins' - but licensing always stands in the way (specifically the clauses regarding linking of libraries), not to mention the problems with having to wait for them to update in order to do my updates / or their updates breaking my parts (forcing me to update just to keep things working).  Would rather have the plugin code under my control so that I know I'm the only one going to break things, don't have to worry about licensing, and generally save a ton of headache in the long-run.

 

Regarding 1.875m 2-kerbal command pod --

Soyuz, or ??  Looking for suggestions, as I don't really have time at the moment to do investigations regarding properly scaled sizes/etc.  I know that Soyuz would scale fairly appropriately for 1.875m, but I'm unsure as to the size of the other more recent 'commercial' offerings.

Basically looking for any 2-man re-entry capable pod designs, preferably around 3m actual size (*.64 = 1.875).

[RedParadize]

1 hour ago, Shadowmage said:

Regarding 1.875m 2-kerbal command pod --

Soyuz, or ??  Looking for suggestions, as I don't really have time at the moment to do investigations regarding properly scaled sizes/etc.  I know that Soyuz would scale fairly appropriately for 1.875m, but I'm unsure as to the size of the other more recent 'commercial' offerings.

Basically looking for any 2-man re-entry capable pod designs, preferably around 3m actual size (*.64 = 1.875).

 

I would like the Soyuz, and as you said it make sense for the 1.875. (Thats why I am using the HGR version.)

One thing, soyuz is a 3 crew design (most of the version). Its important because it reflect the orbital/reentry capsule philosophy. Soyuz have more usable internal space than the Apollo, while being much lighter. Going for 2 crew would make it equivalent to gemini capsule, that would be unfair.

Thinking about it, if you really want to go for two crew, Genini would be a good idea I think.

[Jimbodiah]

Built an Ares I and a Delta IV today, and working on a Saturn V now (using FASA for CM/CSM/LEM though, hint hint). Next up will be a Jupiter and maybe an STS/Shuttle to get a larger collection of NASA rebuilds. SSTU is awesome!!!!

[ComatoseJedi]

While just having dl this mod and just messing around with the engines and other systems, I have to say the modular design to change parts while keeping part count minimal is genius. The menus are a bit hard to understand, but it's something to get used to if I plan on using this mod. I read on another thread you wanted to use this mod and the cormorant aeronology parts to create a sts. As soon as Pak updates his mod (there are some part discrepancies that effect flight dynamics and the OMS pod seems to fuse with the body of the ship making it non select-able) I will push out sts trials on this as soon as possible. I need to know what parts you would like tested with an STS, let me know. I absolutely love the SRB sep module, why hasn't anyone thought of that one besides you guys? It works like a charm and I can see it getting more use as I come up with ship designs to implement them. 

So far, everything seems to be working great, you guys even took the time to make some IVA's for this, but my guess is that you'll be switching to ASET as soon as the major portions of this mod are completed. The ones you have work well and set up great. The integrated cam on the lander module is another awesome feature. I will continue further testing on engine systems and other parts and let you know if I run into any snags, but so far so good, things are working well and looking awesome for just a development mod, which could go live right now and no one would complain. 

The biggest asset you guys have is the fact that you are active in keeping the people who play ksp apprised of your progress. This is a big plus in my book. I know that some modders put a post here and there and let people know what's going on, but you guys are constantly posting things you are doing and letting us know that the work you are doing is going to schedule and you keep an open ear to suggestions and feedback, another huge plus. Keep up the good work guys. 

[Shadowmage]

Updated bugfix release is available:

https://github.com/shadowmage45/SSTULabs/releases/tag/0.2.22-beta

• fix up mass for upper stage parts not persisting
• fix up solar panels tracking in the dark
• fix up solar panels lerping towards origin rotation on retract (may have bugs, please report them)

[Autochton]

Shadowmage, it sounds like a problem of release management. I happen to have some experience there, if you want some advice, an unsolicited opinion, or the like.

Given that you use GitHub, here's one approach that we use at my work:

A master branch holds new feature development - major features typically have feature branches that come off it and are merged back when done before freezing release versions.

When we freeze a new release, we create a branch for it (usually named v1, v2, v3, etc. as needed), which we then do debug work on, and merge down to master on a regular basis. While doing this we tag prereleases from it, in order to deploy them to our testing servers - in your case you could have separate pre-release publishing channels (a pre-release KerbalStuff mod instance, for example, would also allow CKAN to have a separate line of releases and pre-releases).

Once a release is made from a release branch (let's say we release v4.0.12 - i.e. first production release of v4, 13th tagged build; v4.0.0 through v4.0.12 were pre-releases) by pushing it to the full-release KerbalStuff instance, you can then still do pre-releases if you want, but patches can just as easily be added to the release version. Then, a while later, you make another release branch (in our case v5, at this point you might have v4.3.1 in full release), and any fixes to v4 you merge first to v5, then to master. Then once you release v5, you can let the v4 branch slide into the grave and forget about it.

Something similar to this approach might enable you to have your separation of pre- and full-releases, with a little care to how to use KerbalStuff/CKAN etc.

[JoseEduardo]

15 hours ago, Shadowmage said:

Regarding 1.875m 2-kerbal command pod --

Soyuz, or ??  Looking for suggestions, as I don't really have time at the moment to do investigations regarding properly scaled sizes/etc.  I know that Soyuz would scale fairly appropriately for 1.875m, but I'm unsure as to the size of the other more recent 'commercial' offerings.

Basically looking for any 2-man re-entry capable pod designs, preferably around 3m actual size (*.64 = 1.875).

either Soyuz (after Soyuz-11, only 2-men crew have been sent until Soyuz-T, plus LK/LOK was planned to be a 1-man lander and a 2-man spacecraft) (2.72m RW), Gemini (3m) (could later be re-used as Big Gemini) or VA Capsule (2.79m, 3-man) (TKS FGB part could also be re-used later for station parts, as russian modules base)

You already know which one I would vote for, don't you?

btw, quick links that could be helpful:
VA: https://en.wikipedia.org/wiki/VA_spacecraft http://www.astronautix.com/craft/tksva.htm http://www.astronautix.com/craft/almzapos.htm
TKS: https://en.wikipedia.org/wiki/TKS_(spacecraft) http://www.astronautix.com/craft/tks.htm http://www.russianspaceweb.com/tks.html
Soyuz/LOK: https://en.wikipedia.org/wiki/Soyuz_(spacecraft) (LOK was 2.93m btw)
Gemini: https://en.wikipedia.org/wiki/Project_Gemini
Big Gemini: https://en.wikipedia.org/wiki/Big_Gemini
Excalibur Almaz (plans to use newly built VA pods): https://en.wikipedia.org/wiki/Excalibur_Almaz

EDIT: actually, the Soyuz pod is 2.2m wide, what's 2.7m wide is the bottom part of the SM:


EDIT again: btw, if you go for Soyuz, this was a thing that happened:
 

they slapped a APAS in one of the Soyuz to test everything in preparation for Buran, and that APAS looks like your current docking port

Edited December 1, 2015 by JoseEduardo
moar links

[RedParadize]

8 hours ago, Shadowmage said:

Updated bugfix release is available:

https://github.com/shadowmage45/SSTULabs/releases/tag/0.2.22-beta

• fix up mass for upper stage parts not persisting
• fix up solar panels tracking in the dark
• fix up solar panels lerping towards origin rotation on retract (may have bugs, please report them)

Thank you so much for this!

[MrMeeb]

I'm against the idea of a Soyuz because of the Tantares mod already providing an excellent stock-alike version. I'm not sure about an alternative though...there weren't many 2-man spacecraft to my knowledge, other than the Gemini...hmm

[Shadowmage]

14 hours ago, RedParadize said:

 

I would like the Soyuz, and as you said it make sense for the 1.875. (Thats why I am using the HGR version.)

One thing, soyuz is a 3 crew design (most of the version). Its important because it reflect the orbital/reentry capsule philosophy. Soyuz have more usable internal space than the Apollo, while being much lighter. Going for 2 crew would make it equivalent to gemini capsule, that would be unfair.

Thinking about it, if you really want to go for two crew, Genini would be a good idea I think.

 

Soyuz has been both a 2 and 3-man design, depending upon the era / specific model reflected (model Soyuz-7K-T, flights Soyuz 12-40).  This was the model (well, a derivative of this model) that was used in the ASTP.  I'm also unsure of the ability to cram 3 giant-headed kerbals into a tiny little Soyuz pod.  So, -if- I do one, it will be a 2-man pod.

Mostly though, I'm looking for alternatives because I hate the way Gemini looks (and Mercury too...).  That horrible 'tunnel' bit sticking out the front screams... bad engineering to me.  The engineering was probably fine, and they likely had good reason to do it as such; but I've always though it was one of the most tacked-together looking spacecraft, which while probably more 'Kerbal', just doesn't appeal to me.

 

14 hours ago, lynwoodm said:

While just having dl this mod and just messing around with the engines and other systems, I have to say the modular design to change parts while keeping part count minimal is genius. The menus are a bit hard to understand, but it's something to get used to if I plan on using this mod. I read on another thread you wanted to use this mod and the cormorant aeronology parts to create a sts. As soon as Pak updates his mod (there are some part discrepancies that effect flight dynamics and the OMS pod seems to fuse with the body of the ship making it non select-able) I will push out sts trials on this as soon as possible. I need to know what parts you would like tested with an STS, let me know. I absolutely love the SRB sep module, why hasn't anyone thought of that one besides you guys? It works like a charm and I can see it getting more use as I come up with ship designs to implement them. 

So far, everything seems to be working great, you guys even took the time to make some IVA's for this, but my guess is that you'll be switching to ASET as soon as the major portions of this mod are completed. The ones you have work well and set up great. The integrated cam on the lander module is another awesome feature. I will continue further testing on engine systems and other parts and let you know if I run into any snags, but so far so good, things are working well and looking awesome for just a development mod, which could go live right now and no one would complain. 

The biggest asset you guys have is the fact that you are active in keeping the people who play ksp apprised of your progress. This is a big plus in my book. I know that some modders put a post here and there and let people know what's going on, but you guys are constantly posting things you are doing and letting us know that the work you are doing is going to schedule and you keep an open ear to suggestions and feedback, another huge plus. Keep up the good work guys. 

 

Thanks      Really wish it was 'us guys', but its only just me!  (To be fair, JoseEduardo has been helping out quite a bit on testing and configs recently, mostly for RO integration).

I try hard to keep everyone informed of what is going on with the mods' development -- always has bugged me that so many developers go silent for so much of the time.  I understand (and sympathize) with their reasons, but just don't think it is the right way to do things.  Can't say its been easy, and it certainly chews up a good chunk of my developer time, but I think it is probably for the better in the long run.

[Shadowmage]

 

7 hours ago, Autochton said:

Shadowmage, it sounds like a problem of release management. I happen to have some experience there, if you want some advice, an unsolicited opinion, or the like.

Given that you use GitHub, here's one approach that we use at my work:

A master branch holds new feature development - major features typically have feature branches that come off it and are merged back when done before freezing release versions.

When we freeze a new release, we create a branch for it (usually named v1, v2, v3, etc. as needed), which we then do debug work on, and merge down to master on a regular basis. While doing this we tag prereleases from it, in order to deploy them to our testing servers - in your case you could have separate pre-release publishing channels (a pre-release KerbalStuff mod instance, for example, would also allow CKAN to have a separate line of releases and pre-releases).

Once a release is made from a release branch (let's say we release v4.0.12 - i.e. first production release of v4, 13th tagged build; v4.0.0 through v4.0.12 were pre-releases) by pushing it to the full-release KerbalStuff instance, you can then still do pre-releases if you want, but patches can just as easily be added to the release version. Then, a while later, you make another release branch (in our case v5, at this point you might have v4.3.1 in full release), and any fixes to v4 you merge first to v5, then to master. Then once you release v5, you can let the v4 branch slide into the grave and forget about it.

Something similar to this approach might enable you to have your separation of pre- and full-releases, with a little care to how to use KerbalStuff/CKAN etc.

Git / branching -- I've only ever ran into problems with git's branch management.  More precisely its inability to cleanly merge disparate branches without necessitating manual conflict resolution.  If I ever have to manually resolve a conflict, git has failed in its purpose, and has become more of a burden than the utility that it offers.

With that said, my current (private/unlisted) dev setup is not too far off from what you are describing; only I end up manually merging changes from disparate branches (e.g. change made in 2.04 branch that is not in master, but needs applied to 2.05 branch; I end up manually merging it into master (by copying files...), and from there doing a proper upstream merge to the 2.05 branch -- the problem is this leaves the 2.04 branch 'out of synch' with master / unresolvable).  <--- this is my main problem with git branch management;  how do you merge -just one change/commit- back into master from a sub-branch, using the Git-GUI tools?  (I don't want -all- the changes from the dev branch, but just a very particular subset).  I will certainly admit that my 'skills' using git are, perhaps lacking in a couple areas; but really... should I need to take classes / read 100 page manuals just to use a 'productivity enhancement tool'?  (would rather spend that time learning new programming concepts, new libraries, or new APIs).

What I need is not multiple-branch management, what I need is a separation of release and development threads / forums / posts / downloads.  If I offer a 'stable' and a 'dev' download on the same page, I guarantee some kid is going to download the dev one by mistake, and start moaning about why Y is broken/why X has no texture/why Z is unavailable.  And the biggest part of this that I need is the ability to just pack/release the dev stuff instead of spending all night testing it; but as long as there isn't a 'stable' release, I have to do at least some minimal amount of pre-release testing (you would be surprised how much I actually catch/fix during this period; silly bugs that you guys never have to even see/deal with).

Regarding branch management / git use in general - it -can- be a great tool.  For example for last-nights 'bugfix', I was able to start a new branch, revert to a previous commit (from master), do the codeside fixes for the Modular Upper Stage, pack it all up, and then un-revert and merge in the new 'fixes' to the master branch.  Whole ordeal took maybe 10-15 minutes.  What took the rest of the night was doing testing and fixing up on the changed solar panel stuff (which I probably should have just reverted and saved for the weekend) (apparently, for some reason, Unity-animations don't update in the same tick as which they are 'played' (could actually be a bug in my animation control module); so I had to invent a workaround to get the solar-panel default 'extended' orientation that didn't involve relying on the animation state being alterable and query-able).

Anyhow, thanks for the suggestion and info, certainly one of the more intelligent/informative/helpful posts that I've come across, and I likely will change up a bit of my workflow to help clean up a few of these issues.

 

 

3 hours ago, JoseEduardo said:

either Soyuz (after Soyuz-11, only 2-men crew have been sent until Soyuz-T, plus LK/LOK was planned to be a 1-man lander and a 2-man spacecraft) (2.72m RW), Gemini (3m) (could later be re-used as Big Gemini) or VA Capsule (2.79m, 3-man) (TKS FGB part could also be re-used later for station parts, as russian modules base)

You already know which one I would vote for, don't you?

btw, quick links that could be helpful:
VA: https://en.wikipedia.org/wiki/VA_spacecraft http://www.astronautix.com/craft/tksva.htm http://www.astronautix.com/craft/almzapos.htm
TKS: https://en.wikipedia.org/wiki/TKS_(spacecraft) http://www.astronautix.com/craft/tks.htm http://www.russianspaceweb.com/tks.html
Soyuz/LOK: https://en.wikipedia.org/wiki/Soyuz_(spacecraft) (LOK was 2.93m btw)
Gemini: https://en.wikipedia.org/wiki/Project_Gemini
Big Gemini: https://en.wikipedia.org/wiki/Big_Gemini
Excalibur Almaz (plans to use newly built VA pods): https://en.wikipedia.org/wiki/Excalibur_Almaz

EDIT: actually, the Soyuz pod is 2.2m wide, what's 2.7m wide is the bottom part of the SM:


EDIT again: btw, if you go for Soyuz, this was a thing that happened:
 

they slapped a APAS in one of the Soyuz to test everything in preparation for Buran, and that APAS looks like your current docking port

 

Thanks for the refs and resources, will take a look over these as I have time today.  Still quite a ways off from even being able to start on the parts... but I generally like to start doing concept work a few weeks before I start the modeling.

 

25 minutes ago, MrMeeb said:

I'm against the idea of a Soyuz because of the Tantares mod already providing an excellent stock-alike version. I'm not sure about an alternative though...there weren't many 2-man spacecraft to my knowledge, other than the Gemini...hmm

See above regarding my stance on Gemini.

What I'm looking for, more than any specific design, is an early-mid-career game 2-man+ capsule; something that can bridge the (massive) gap between 1.25 and 2.5m parts in the tech tree and the current stock command modules.  Needs to hold at least two kerbals, for tourism contracts, rescues, and training missions (no, I don't believe stacking a 1.25m in-line cockpit is an acceptable solution).

Other mods' having a part does me... very little good.  Especially a mod that I haven't really heard of and certainly have not ever used or intend on using (if it were one of my 'normal' mods, I would have a completely different stance, and would have no problem just using the part from other mod in my own games).  This perhaps though is just fallout from the lack of 64-bit support;  when I only have ram for a small subset of mods, my willingness to try out new part mods is non-existent (as I couldn't use them even if I wanted, with my game being already full of 'mandatory' part mods); heck the last 'new' parts-mod that I tried out was KW rocketry, something like 6-8 months ago (before I started doing KSP modding).  Nope, I've never checked out FASA, SPACE-Y, b9, or any of the other big part mods.  I have no idea what they offer, nor am I particularly interested as long as A: RAM is limited, and B: vessels are part-count limited.

 

 

2 hours ago, RedParadize said:

Thank you so much for this!

 

I'm glad you appreciate it, as it cost me my entire night worth of development time last night doing testing =\.  -That- is why I don't do out of schedule releases, as now I'm behind schedule for the rest of the week (and its only Tuesday =\).  So, will not be doing that from now on, at least until there is a proper public release thread/setup in place (which, with any luck, should only be a few weeks).

[Shadowmage]

On Sunday, November 29, 2015 9:10:11, Jimbodiah said:

Been playing with the SSTU mod and having a blast. Built the SLS and Delta IV with the Orion capsule, Just awesome...

A couple of things I run across, maybe for future consideration:

- RCS on the Orion CM/SM are not balanced, they make the ship wobble all over the place, is hell to dock with anything. If I disable the RCS on SM and CM and add four stock one just under the SM collar, it is balanced perfectly. Perhaps make the actual rcs point come from someplace other than the actual graphical representation?

- A possibility to have chutes integrated into the top cone, or something that can be added without making it look funky.

 

Parts folder things:
- The largest engines do not show up under my stock-engines tab, only the SSTU tab
- Could you add a tab with all your other parts, just like with the engines?
- Could you make a manufacturer tab so all your parts show up in one place when filtering on brands?

 

RCS unbalanced -- yep, the positions/etc were based on the real spacecraft.  Unfortunately, KSP has a rather... primitive rcs 'balancing' scheme (e.g. it doesn't...).  Blame KSPs terrible (complete lack of..) balancing implementation, not the craft=\   Unfortunately, you cannot have thrust transforms without effects;  the effects are located by the RCS module to the exact position of the thrust transform; so no, you can't cheat like that.  When I am reworking the command pods/etc I will be revisiting the RCS on the SC-B-SM, and at least removing/rewroking the awful forward/rearward angled ports.

Engine Clusters - fully intended.  I do not want to overload the stock engines tab with a bunch of mostly-identical engine clusters.  So they reside only in the engine clusters tab (hey.. a tab mad specially for them?  why would they -not- go there?).

Additional tabs - perhaps in the future.  Would need a very good reason to do so though, which I am not currently seeing.

Manufacturer - I honestly have no idea what it takes to do that, nor is it any kind of a high priority.  Perhaps at some point in the future.  If you would like to open up an issue ticket on Github, that will ensure that it does not get forgotten about (if you open a ticket it -will- get take care of, probably sooner than later; if you -don't- open a ticket, it will not get done...).

 

[blowfish]

13 minutes ago, Shadowmage said:

Manufacturer - I honestly have no idea what it takes to do that, nor is it any kind of a high priority.  Perhaps at some point in the future.  If you would like to open up an issue ticket on Github, that will ensure that it does not get forgotten about (if you open a ticket it -will- get take care of, probably sooner than later; if you -don't- open a ticket, it will not get done...).

It just requires that the manufacturer have an agency definition.

A couple of observations on usability:

• I've found the next/previous buttons to be very error prone, particularly when there are a lot of them (which there are here).  Would it be possible to, at some point in the future, switch to something like UI_ChooseOption in KSPAPIExtensions?  I get that this might not happen until release due to licensing concerns.
• Likewise, having parts move around as you update them makes it very difficult to make multiple adjustments.  Would it be possible to move the parent part around the part being edited, at least if it's stack attached?  I believe this is the way Procedural Parts does it - it annoyed me at first but now I see why they do it that way - having the window move around makes consecutive adjustments very painful.