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

[Shadowmage]

2 minutes ago, blowfish said:

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.

Hmm.. will look into the agency stuff; haven't poked around that end of things much/at all.

1.) Buttons -- Yes, but not until 1.1 is available with the new GUI system; not going to spend time making a bunch of custom GUI controls that will just be thrown out with the next KSP update.  And I would -love- to be able to use KSPAPIExtensions (as it has many of the exact GUI controls that I need); but aside from licensing issues there is one blatant problem -- the authors requirement that my mod be listed on his 'mods using this' list -before- I can release it... that just does not work for me; the mod is already released, and I am unwilling to wait an unspecified period of time in order to publish the next release (esp. since the author seems to no longer be active).  The licensing stuff I could possibly live with / work around / comply with; but the pre-release listing requirement kills my interest to use it / link to it.  And then there is still the problems associated with external code regarding updating; having to wait for them to update / their unrelated updates breaking my mod.

2.) I consider moving the root part to be wrong.  Under no circumstances do I want my craft moved around in the VAB.  Yes, the moving right-click info box is... annoying, but I consider that a stock GUI implementation error rather than something I should need to address (e.g. the info-box should not move as long as it is -still- open; it should only reposition when re-opened).  I might investigate adding a toggle to these parts in the future to determine their behavior, but it will not be high on the priorities list.

[blowfish]

Fair enough ... I wonder it there's a way to "force" the part action window to stay in the same place ... maybe I'll investigate this at some point.

[Jimbodiah]

Thanks Mage!!!

- The RCS is fubar... it works OK if you do it manually, but if you let Mechjeb run the RCS it's like he's a drunk Kerbal

- Tabs for other than engines: To make life easier   I mainly use SSTU parts so make my own tabs to have them handy and not have to dive through 15 other tabs each have 100 parts. Less headache. The Manufacturer tab would essentialy bunch all your components together, sort of like your eniges tab but for everything made by SSTU.

- I will check out gtihub and see how it works. I just launch things, blow stuff up or kill Kerbals (pref al 3 at once), not really a developer   I'll also be suggesting smaller steps for tank lengths 
 

 

Edited December 1, 2015 by Jimbodiah

[Shadowmage]

2 minutes ago, blowfish said:

Fair enough ... I wonder it there's a way to "force" the part action window to stay in the same place ... maybe I'll investigate this at some point.

Hmm...  I have not yet even looked at the stock GUI implementation; but from my experiences with other GUI libraries, as long as you could grab a references to the instance of the window in use, you could cache the existing window position prior to updating the part, and re-force-set the original position after updating the parts' position.  No way to know though if it would try to auto-reposition itself on the next update tick or not...  Heh, I probably shouldn't speculate on code that I've never looked at/played with.

If you do run across something, please let me know - would be glad to get rid of the repositioning window.

BTW - your advice on using PartModule.Start() was spot on; using it as part of the multi-pass loading sequence has worked out well so far where I have implemented it (granted, there are other unrelated problems I need to clean up on some of those modules).  So, thanks for that info; very useful, and will come in hand with some of the upcoming modules as well.

[Shadowmage]

There have been a few questions/comments/feedback regarding the GUI stuff, so I figured I had better post this now before things get out of hand.

Yes, I will be improving the GUI interactivity of these parts.  No, I will not be doing it until 1.1 is available.

-When- I do update to custom GUIs, they will likely be implemented something like this:

Concept shot of what a mount-selection GUI would look like.  Just grabbed some random editor screenshot from google, so please pardon the craft/icons/etc that are shown, they are for example purposes only.  Basically you would right-click the part and then hit the 'Select Mount' button, and it would pop up a selection list as shown in the image below -- a similar setup would be used for any/all parts that have selectable components or modular model setups.  Could possibly even implement something similar for selecting texture sets.
 

 

Edit - I -really- dislike the new forum software; it can't even handle HTML formatted image links properly

Edited December 1, 2015 by Shadowmage

[Jimbodiah]

I just molested your Github issue function 

[Jimbodiah]

Thanks for actually considering input, I have some funky ideas sometimes and it's so very cool to see them taken into consideration. You da man Mage!!!

[Autochton]

5 hours ago, Shadowmage said:

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).

[...]

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.

Hmm, honestly, I haven't ever been satisfied with the git GUI tools out there. They're horribly restrictive and limited, the merging is crap, and they at best only fit a single work flow. I'm command line for life, on that front - not least because then if I need anything in particular, I can script my way out of it. I have a command that when I'm on a release branch and have committed a fix or something, I can then merge it downward across active release branches (potentially multiple, in practice only ever one), and down to master. Making that easy prevents the branches from getting too far out of sync.

Anyway, the command you're looking for is cherry-pick, as in git cherry-pick <checkoutable>, where checkoutable is a reference to the commit you want - I usually copy the SHA code from a log listing - and possibly adding the -x switch to annotate the commit message with the SHA you picked. That applies that single commit to your current branch, as a separate commit.

If merging conflicts are a massive chore for you, I'd also look into a good merging tool. I pretty exclusively develop on Linux, which has an extensive list of just such tools, all wired up to work with git. Then it becomes as simple as running git mergetool if something conflicts, and getting a good, transparent UI allowing you to pick code lines, or merge them. (Binaries in general should be merged by picking which of the two conflicting versions to use, and anything that's the output of a script has no place in a git repository.)

Anyhow, I'm happy to help, and if you want, I'll gladly answer questions, help you find information or methods that work, etc. I'm 'gertsonderby' on Github, my git scripts and shortcuts are stored as gists there if you want to see them.

[RedParadize]

 

6 hours ago, Shadowmage said:

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).

So sorry! I realy appreciate it, but please don't answer my request if it doesn't fit your planning. I don't want to slow you down.

7 hours 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

Tantares have a Soyuz, but its in 1.2m5 and part are extremely light. HGR have one too, better balanced and in 1.875, but not maintained anymore. Fasa have a good Mercury, Gemini, Apollo, but they come in allot of parts. My point is at this point every relevant capsule have been done already. That should not be a guideline. Whatever Shadowmage will come up with will be radicaly different in nature. It won't be just part, but part that are driven by his plugin and philosophy. In that spirit, I would like all relevant capsule to be remade by Shadowmage. (exept aset's Alcor, but thats another story) But I don't see that happening, because Fallout 4. So I won't be picky.

 

7 hours ago, Shadowmage said:

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.

My two cents about Gemini:

I am not a big fan of American design in general, It feel that the all in one capsule is sub optimal engineering wise, trough it might make sense in the case of the Apollo, Soyuz 7k-lok plus the LK lander setup seem a bit too complex to be reliable. Anyway, I did like the SSTU's Orion, so If you end up doing Gemini I am sure I would like it too.

My two cents about Soyuz:

If you end up picking the soyuz, I would suggest to have both the 2 and 3 crew variant. The Control panel is the same in both version, just one more seat. Having 3 Kerbals cramped in such a small space would be quite funny, and a accurate depiction of how it feel to be in a Soyuz.

The real chalange is the orbital module, lunching a Soyuz without its orbital module is quite OP, specialy for a 3 crew variant. I don't see how you could inforce its use, but I don't its the way to go. I think the return capsule should be minimalist, 40 battery and thats it. On the other side, orbital module should stack allot of fonctionality, making it almost essential, like large battery, experiment, KIS, life support and whatever else you come up with. Given what your mod have to offer, the final product could be quite exeptional.

And now I will go see what I can do with SSUT-0.2.22-beta

Edited December 1, 2015 by RedParadize

[Jimbodiah]

Doing some plugging for SSTU in my spacecraft exchange topic

http://forum.kerbalspaceprogram.com/index.php?/topic/126830-jimbodiahs-nasa-rockets/

[RedParadize]

I like these upper stage. its quite nice to be eable to do a delivery system with so few part.

Another bug to report:

When you connect struts to fuel tanks, the second connection also select the part. same with fuel connection. Annoying, but not game breaking.

 

[astovall321]

I haven't had a chance to really get into it, but wow this is gorgeous.   

[Shadowmage]

5 hours ago, RedParadize said:

 

[...]snip[...]

My two cents about Gemini:

I am not a big fan of American design in general, It feel that the all in one capsule is sub optimal engineering wise, trough it might make sense in the case of the Apollo, Soyuz 7k-lok plus the LK lander setup seem a bit too complex to be reliable. Anyway, I did like the SSTU's Orion, so If you end up doing Gemini I am sure I would like it too.

My two cents about Soyuz:

If you end up picking the soyuz, I would suggest to have both the 2 and 3 crew variant. The Control panel is the same in both version, just one more seat. Having 3 Kerbals cramped in such a small space would be quite funny, and a accurate depiction of how it feel to be in a Soyuz.

The real chalange is the orbital module, lunching a Soyuz without its orbital module is quite OP, specialy for a 3 crew variant. I don't see how you could inforce its use, but I don't its the way to go. I think the return capsule should be minimalist, 40 battery and thats it. On the other side, orbital module should stack allot of fonctionality, making it almost essential, like large battery, experiment, KIS, life support and whatever else you come up with. Given what your mod have to offer, the final product could be quite exeptional.

And now I will go see what I can do with SSUT-0.2.22-beta

Don't feel bad about the time, its not like it was wasted, and it wasn't the fuel tank stuff that took up the time anyhow.


Soyuz - I'm a bit torn as to whether I should get into the Russian parts much/at all.  On one hand they are a huge part of space history/tech.  On the other hand, their unique shapes (for the main rocket) and configurations (such as the 3-piece CSM) are not as conductive to the low-part-count multi-use parts.

However, if I were to do the pod, It would likely end up with three pieces: 1 - Orbital Module (Docking port, transmitters, fuel cell?, micro-science lab?, probe core, rcs?), 2 - Descent Module (crew capacity, parachutes, heat-shield, rcs?), 3 - Service Module (Main engine, rcs, solar panels).  Would be one part more than the Apollo/Orion CSM setups, but might be an acceptable compromise.  Could very easily ship a second config for a 3-crew variant, though I doubt I would want to do any more IVAs.

Alternatively to Soyuz I'm considering a scaled-down Apollo/Orion type capsule (probably similar to the VA capsule Jose linked earlier, but unsure yet), perhaps even a custom design.

 

Fairly certain I'll be doing a 1.875m CM/SM one way or another, even if I just end up scaling down the Apollo stuff (once finished).  Every career game I've played I've ran into the huge gap in tank sizes/command pods, and would love to have these ready for 1.1.

 

4 hours ago, Jimbodiah said:

Doing some plugging for SSTU in my spacecraft exchange topic

http://forum.kerbalspaceprogram.com/index.php?/topic/126830-jimbodiahs-nasa-rockets/

Nice work

 

6 hours ago, Autochton said:

[...]snip[...]

Anyhow, I'm happy to help, and if you want, I'll gladly answer questions, help you find information or methods that work, etc. I'm 'gertsonderby' on Github, my git scripts and shortcuts are stored as gists there if you want to see them.

Aye, the GUI tools are sorely lacking compared to the command line capabilities, and I've had to resort to command line more than a few times to solve various problems.  Sadly though, I'm developing on windows, where the command line integration and tool availability is not quite as hot, or at least not as easily available.

Thanks for the tips and info.  I probably should find a good Git reference manual to keep around, and investigate my workflow a bit - some is still based around 'bad' habits enforced from Minecraft modding (ugh... that setup... so painful);  I'm sure there are a few places where it is my setup/workflow that has caused the problems rather than any fault of Git.

Will definitely take a look over your scripts and such; not sure how many would be directly usable through windows, but I might be able to adapt some into win-batch files.

 

 

In development news --

Working through the custom fuel tank rework:

• Doubled length-choices for the tanks; the range is now 0.5x to 8x the diameter, in 0.5x increments (previously was 1-8, in 1 increment).
• Added free-scaling of the tank diameters, from 0.625 - 10m (configurable), in 1.25m increments (configurable), with fine-tune adjustment slider.
• Added career tech-limit support; can specify certain tech-tree nodes that can unlock larger diameters and/or lengths.  The same length can be unlocked by multiple nodes to allow for multiple possible paths to unlock larger tanks.
• Added support to use all existing engine mounts as lower-cap options, with fuel volume (no fairings, yet).
• Combined the split fuel tank textures into a single larger texture; makes texturing a bit easier, but does slightly increase memory use for some texture sets.  Will facilitate splitting the texture sets up into multiple packages without duplication of assets.
• (Temporarily) Removed support for multi-coupler parts (quad-adapters).  Support for the nodes is problematic and will take time to convert/clean up the code from the existing fuel tank module.  Might have these worked back in for the next release, but if not will add them in a future update.  I wasn't overly happy with the models either, so they might wait for a model re-work to be added back in.
• Will be leaving the existing fuel tanks available as-is for a release or two, so that craft can be converted/etc.
• Have not yet added in all single-node adapters, but they should be done soon (config based)

Will be moving on to finishing up textures and implementing tech-limits for the upper stage tank parts next.  Probably won't be time for too much more this week, but would like to try and get a set of RCS blocks for the upper stage parts done.

 

 

[Jimbodiah]

In fear of asking something that is already there... Is there a Jupiter style engine mount?

[JoseEduardo]

50 minutes ago, Jimbodiah said:

In fear of asking something that is already there... Is there a Jupiter style engine mount?

you mean the DIRECT mounts? yeah, they allow for DIRECT V3 designs, the 4 engine mounts is one of the last ones though

7 hours ago, Shadowmage said:

Don't feel bad about the time, its not like it was wasted, and it wasn't the fuel tank stuff that took up the time anyhow.


Soyuz - I'm a bit torn as to whether I should get into the Russian parts much/at all.  On one hand they are a huge part of space history/tech.  On the other hand, their unique shapes (for the main rocket) and configurations (such as the 3-piece CSM) are not as conductive to the low-part-count multi-use parts.

However, if I were to do the pod, It would likely end up with three pieces: 1 - Orbital Module (Docking port, transmitters, fuel cell?, micro-science lab?, probe core, rcs?), 2 - Descent Module (crew capacity, parachutes, heat-shield, rcs?), 3 - Service Module (Main engine, rcs, solar panels).  Would be one part more than the Apollo/Orion CSM setups, but might be an acceptable compromise.  Could very easily ship a second config for a 3-crew variant, though I doubt I would want to do any more IVAs.

Alternatively to Soyuz I'm considering a scaled-down Apollo/Orion type capsule (probably similar to the VA capsule Jose linked earlier, but unsure yet), perhaps even a custom design.

 

Fairly certain I'll be doing a 1.875m CM/SM one way or another, even if I just end up scaling down the Apollo stuff (once finished).  Every career game I've played I've ran into the huge gap in tank sizes/command pods, and would love to have these ready for 1.1.

 

Nice work

 

Aye, the GUI tools are sorely lacking compared to the command line capabilities, and I've had to resort to command line more than a few times to solve various problems.  Sadly though, I'm developing on windows, where the command line integration and tool availability is not quite as hot, or at least not as easily available.

Thanks for the tips and info.  I probably should find a good Git reference manual to keep around, and investigate my workflow a bit - some is still based around 'bad' habits enforced from Minecraft modding (ugh... that setup... so painful);  I'm sure there are a few places where it is my setup/workflow that has caused the problems rather than any fault of Git.

Will definitely take a look over your scripts and such; not sure how many would be directly usable through windows, but I might be able to adapt some into win-batch files.

 

 

In development news --

Working through the custom fuel tank rework:

• Doubled length-choices for the tanks; the range is now 0.5x to 8x the diameter, in 0.5x increments (previously was 1-8, in 1 increment).
• Added free-scaling of the tank diameters, from 0.625 - 10m (configurable), in 1.25m increments (configurable), with fine-tune adjustment slider.
• Added career tech-limit support; can specify certain tech-tree nodes that can unlock larger diameters and/or lengths.  The same length can be unlocked by multiple nodes to allow for multiple possible paths to unlock larger tanks.
• Added support to use all existing engine mounts as lower-cap options, with fuel volume (no fairings, yet).
• Combined the split fuel tank textures into a single larger texture; makes texturing a bit easier, but does slightly increase memory use for some texture sets.  Will facilitate splitting the texture sets up into multiple packages without duplication of assets.
• (Temporarily) Removed support for multi-coupler parts (quad-adapters).  Support for the nodes is problematic and will take time to convert/clean up the code from the existing fuel tank module.  Might have these worked back in for the next release, but if not will add them in a future update.  I wasn't overly happy with the models either, so they might wait for a model re-work to be added back in.
• Will be leaving the existing fuel tanks available as-is for a release or two, so that craft can be converted/etc.
• Have not yet added in all single-node adapters, but they should be done soon (config based)

Will be moving on to finishing up textures and implementing tech-limits for the upper stage tank parts next.  Probably won't be time for too much more this week, but would like to try and get a set of RCS blocks for the upper stage parts done.

 

 

about the 1.875m pod and russian rockets... I think Angara can launch TKS-based modules, and Angara is quite different from the traditional russian rocket designs, and A-5 is intended to replace Proton


here are some links:
http://www.russianspaceweb.com/angara5.html
https://en.wikipedia.org/wiki/Angara_(rocket_family)
http://www.b14643.de/Spacerockets_1/East_Europe_2/Angara/Description/Frame.htm

there's also Zenit (ripoff from Energia Booster, which could also fit SSTU I think):

http://www.b14643.de/Spacerockets_1/East_Europe_2/Zenit-LL/Description/Frame.htm

Energia:

http://www.b14643.de/Spacerockets_1/East_Europe_2/Energiya/Description/Frame.htm

Tsyklon:

http://www.b14643.de/Spacerockets_1/East_Europe_2/Cyclone-4/Description/Frame.htm
http://www.b14643.de/Spacerockets_1/East_Europe_2/Tsiklon/Description/Frame.htm

and some projects that haven't flown include:
Soyuz 5:

http://www.b14643.de/Spacerockets_1/East_Europe_2/Soyuz-5/Description/Frame.htm

Rus-M:

http://www.b14643.de/Spacerockets_1/East_Europe_2/Rus-M/Description/Frame.htm

a Kerbal rocket Vulkan:

http://www.b14643.de/Spacerockets_1/East_Europe_2/Vulkan/Description/Frame.htm

Energia-M:

http://www.b14643.de/Spacerockets_1/East_Europe_2/Energiya-M/Description/Frame.htm

and Yamal:

http://www.b14643.de/Spacerockets_1/East_Europe_2/Yamal/Description/Frame.htm

basically only new engines, maybe some mounts and a lattice decoupler/interstage/fairing

apart from the lattice interstage these are pretty "normal" rockets

and if I had to vote, I would vote for Zenit (if you include a RD-0120 for the core tank it would also be possible to make Energia, Energia-M and that crazy kerbal rocket) and Angara, and maybe Soyuz 5, these could pretty much be used in the role of the Soyuz and Proton rockets (or maybe go kerbal and make a Titan instead, and launch russian stuff aboard a USAF rocket )

about the 1.875 pod, what about having the VA+TKS (which would later help out on the station parts for russian modules) but also a rescaled version of the Apollo and/or Orion SM for it? and maybe use a scaled down Orion LAS for it

another alternative for the SM could be one based on Eyes Turned Skywards Apollo Block V SM:

http://wiki.alternatehistory.com/doku.php/timelines/eyes_turned_skyward_chapters <-- has some technical details based on RW stuff (IIRC the guys behind it are RW rocket engineers or something like that)

13 hours ago, Jimbodiah said:

Doing some plugging for SSTU in my spacecraft exchange topic

that will save me some time for stock

btw, once the new tanks come out I'll send you some Saturn and Nova .craft files and engine mounts and layouts to include on that, if you want them of course, I have a stock config for Nova stuff ready already (ported from RO and tested in stock scale), I'm holding them because of the new tanks though

Edited December 2, 2015 by JoseEduardo

[Jimbodiah]

An Apollo suite would be cool, means I can do without FASA.

Direct engines: You mean from th DIRECT mod or are they called that in real life?  It's the 4 engines in-line, found under the Jupiter rocket proposal. The Direct mod has one, but uses a copied shuttle engine version and is 5 parts in total. One of the reasons I don't like the SpaceX pack is that they have 9 engines, so their Heavy version is 3x9 parts + 3 adapters for just the engines.

Saturn/Nova: Would love them   Working on a Saturn V right now, but the tank lengths make it look funky.

 

BTW: Those russian rockets are another reason for a slanted nose cone version on LF tanks

 

 

Edited December 2, 2015 by Jimbodiah

[JoseEduardo]

it's called DIRECT

have fun: http://www.directlauncher.org/media.htm (it has a LOT of variants )

[Jimbodiah]

yeahyeahyeah, that's the one... Me wanna build!!!!

 

Will build a few with SSTU parts I have now and change them later.

The Direct is basically an Ares V with different engine cluster by the looks of it. LOL, Ares is DIRECT :)))  I just noticed they have different engine clusters from 2-4 engines, that is what threw me off.

Edited December 2, 2015 by Jimbodiah

[Shadowmage]

General Development update:

• Moved texture sets over to a format that allows for patching of new sets into parts - this will allow for splitting up the texture sets into optional downloads.  Does not break existing parts
• Updated all but SLS texture set to be patched in by default; so when I'm ready to split these off they can be quickly packaged up.
• Added fairing support to the new modular fuel-tank, WIP
• If I didn't already mention it, I have decided that I will be leaving the existing fuel tanks available as-is for at least a week, to allow for conversion of craft / finishing of missions.  They have had their part-descriptions in-game updated to reflect this.  After the new resizable tank is available, please do not use the old ones (will cause loss of craft when they are removed).
• Added a master parts list to the Wiki, added link to OP; will be filling in over the next week or so with -all- of the planned parts for the mod, from all different parts series (at least as far as I've done concept development). - https://github.com/shadowmage45/SSTULabs/wiki/Parts---Master-List  -- You might notice a few new previously unannounced parts on there if you look closely.  No promises on dates, many have not even been scheduled yet.
• Tons of work on wiki prep, working towards public release / having data available at that time.

Still have not quite settled on a 1.875m pod design, but I've got probably a week or two to get it figured out (will likely take me that long to rework the other pods).  Heavily leaning towards the VA/TKA style pod, or other custom apollo-shaped command module.

[astovall321]

I'v become a fan of the Cryogenic engine mod, any plans to support real fuels or Interstellar Fuel Switch? 

[RedParadize]

I have been thinking about that 1.875 pod. In its current status, what make your mods realy spectial is its custom fuel tanks and engines clusters pluggin. If I would have to chose, I would rather have even more tank setup, upper stage, engines, fairing, clusters and textures. All the fancy stuff that can be done using your pluggin. Revisiting your lander tanks could be great too.

Don't get me wrong, I realy like the Orion cm/sm and I would still like to have the Soyuz or, to a lower extent, the VA as well. But not as much as the as the rest.

Some reference:

http://historicspacecraft.com/Rockets_Upper_Stage.html

33 minutes ago, astovall321 said:

I'v become a fan of the Cryogenic engine mod, any plans to support real fuels or Interstellar Fuel Switch? 

You do not need the fuel switch, just edit the following, should be self explanatory:

SSTU\Data\FuelTanks\FuelTypes.cfg

SSTU\Data\FuelTanks\ResourceVolumes.cfg

Edited December 3, 2015 by RedParadize

[astovall321]

10 hours ago, RedParadize said:

 

You do not need the fuel switch, just edit the following, should be self explanatory:

SSTU\Data\FuelTanks\FuelTypes.cfg

SSTU\Data\FuelTanks\ResourceVolumes.cfg

Thanks,

so upon examining the config files I see that LH and LHO are already included as resources , the fuel tanks were just not mapped to those resources(if thats the proper terminology)  And also in the FuelTypes config, LH and LHO were preceded with forwarded slashes on each line, I know little about code so I can only presume that was to keep it hidden from the selection options. Then of course there is the problem of balancing  everything to work with Nertea cryo engines (so now I have not understanding C# and not being a rocket scientist working against me)I know LH2 is more efficient, less dense, lighter... I just have no idea how much so.  I changed the Fuel/oxidizer ratio to 10/1 and that seemed to help but the fuel volume and or tank mass factor might be off.  

This is to  Shadowmage, so since LH2 is part of the mod already ,are there plans to use it? will there be  Cryo specific tanks and or engines ?   

[RedParadize]

17 minutes ago, astovall321 said:

Thanks,

so upon examining the config files I see that LH and LHO are already included as resources , the fuel tanks were just not mapped to those resources(if thats the proper terminology)  And also in the FuelTypes config, LH and LHO were preceded with forwarded slashes on each line, I know little about code so I can only presume that was to keep it hidden from the selection options. Then of course there is the problem of balancing  everything to work with Nertea cryo engines (so now I have not understanding C# and not being a rocket scientist working against me)I know LH2 is more efficient, less dense, lighter... I just have no idea how much so.  I changed the Fuel/oxidizer ratio to 10/1 and that seemed to help but the fuel volume and or tank mass factor might be off.  

Balancing should be relatively easy, comparing resource definition and  some math. When I get back from work I will take a look.

[Shadowmage]

 

11 hours ago, RedParadize said:

I have been thinking about that 1.875 pod. In its current status, what make your mods realy spectial is its custom fuel tanks and engines clusters pluggin. If I would have to chose, I would rather have even more tank setup, upper stage, engines, fairing, clusters and textures. All the fancy stuff that can be done using your pluggin. Revisiting your lander tanks could be great too.

Don't get me wrong, I realy like the Orion cm/sm and I would still like to have the Soyuz or, to a lower extent, the VA as well. But not as much as the as the rest.

Some reference:

http://historicspacecraft.com/Rockets_Upper_Stage.html

You do not need the fuel switch, just edit the following, should be self explanatory:

SSTU\Data\FuelTanks\FuelTypes.cfg

SSTU\Data\FuelTanks\ResourceVolumes.cfg

I need the 1.875m command pod far more than I need more fuel tanks, upper stages, or even engines.  I need to fill a gap in the early stock career-games (as I only play career mode..) in the part-tree regarding manned-space access for multiple kerbals.  The jump from 2.5 -> 3.75 isn't so bad, seems a bit more 'natural'.  But the jump from 1.25 -> 2.5 is... unnecessarily more difficult than it should be.

As far as upper stages go - I'm done.  There might be more textures, but the two styles of upper stage that I have made cover 95% of the upper stage designs that I've seen (excepting SRB upper stages and the strange Russian multi-tank design). 
Fuel tanks are mostly the same state - I have no need for more fuel tanks, at least after the WIP refresh is done.
Most of the other parts you mention are in about the same state (excep perhaps payload fairings); they are quite usable, and offer enough functionality for stock/non-RO game setups.

 

Thanks for helping out with the info regarding fuel-setups

 

11 hours ago, astovall321 said:

I'v become a fan of the Cryogenic engine mod, any plans to support real fuels or Interstellar Fuel Switch? 

Real Fuels - compatibility is built in, you merely need to create a set of patches to enable it.  It will then give RealFuels/ModularFuelTanks complete control over the tank contents (for both regular fuel tanks and upper stages).  Please see the RO patches for what is needed to enable this.

However, I do not use real-fuels, so I will not be making patches for it personally.  If someone is kind enough to submit some for inclusion into the stock mod though, I would happily accept such a PR, and am willing to ship the stock-RF-compatibility patches with the mod..

Fuel Switching - built in, as noted.  You merely need to edit or patch the fuel-definition config files appropriately.  Note though, there is a bug with the current fuel-tank dry-mass calculation, where it is still based off of usable volume rather than fuel mass for that volume;  should have that fixed in the next update.  It works fine for stock fuels, as they are mostly 1t/m3, but for LH2 you would end up with overweight tanks.

 

 

9 minutes ago, astovall321 said:

Thanks,

so upon examining the config files I see that LH and LHO are already included as resources , the fuel tanks were just not mapped to those resources(if thats the proper terminology)  And also in the FuelTypes config, LH and LHO were preceded with forwarded slashes on each line, I know little about code so I can only presume that was to keep it hidden from the selection options. Then of course there is the problem of balancing  everything to work with Nertea cryo engines (so now I have not understanding C# and not being a rocket scientist working against me)I know LH2 is more efficient, less dense, lighter... I just have no idea how much so.  I changed the Fuel/oxidizer ratio to 10/1 and that seemed to help but the fuel volume and or tank mass factor might be off.  

This is to  Shadowmage, so since LH2 is part of the mod already ,are there plans to use it? will there be  Cryo specific tanks and or engines ?   

 

See the note above regarding the current fuel-tank-dry-mass bug, is likely the problem you are seeing regarding the LH2 tanks.

Those configs are disabled/commented out by default, for good reason -- there is no LH2 in stock! (and I don't feel like bundling / dealing with updating CRP constantly).  So no, I will not be moving to support cryo engines, or alternate fuel types, until they are part of the stock game.  I had the stuff in the configs from the initial testing and setup for it, but then ran into the problems regarding run-time fuel switching for engines and compatibility with RO (needs to be one or the other, can't be both, as RO does its own switching).  At that point I decided it would not be worth it to do the fuel-switching for the engines, as it is already implemented somewhere and would -only- create problems if I did it as well.  If you -really- want to use LH2 on them, I would recommend using real-fuels or the RO suite of mods.

That ratio sounds right, as long as they are whole numbers it should 'work'.  As long as my resource 'volumes' config data is correct for the given resources, the fuel volumes should be correct as well.  However, note the bug I mentioned above regarding the tank masses.

[JoseEduardo]

I wonder why no one tried to port the RO configs for a stockalike RealFuels patch... I would try myself, but you know... Just Cause 3, I have some stuff to blow up  (if the game stops lagging everytime I turn the camera) plus, tiny kerbin feels so wrong to me that I see no fun in playing on stock system anymore, so balancing should be off if I try

Edited December 3, 2015 by JoseEduardo