Shadowmage

I believe you need oxidizer as well. Verniers burn both LF and O, in the same ratio as a normal engine.

These two enhancements have been implemented in the dev-branch and seem to be working quite well. Still have a bit more testing/verification to do on them, but so far, so good. I made a test engine cluster using 3x RS-25; and have it swapping between several mounts, with different spacing and engine-layouts on a per-mount basis. Seems like it was a good addition, and was very clean to implement (as opposed to hacky).

Because I only issue updates once a week, unless it is a severe game-breaking/crash-on-load type issue. After I start moving things over to a finished release state and start using the 'public release' repository, I will be able to update the dev branch more often (e.g. this branch, the stuff you guys are using/testing). Until then I am A: Trying to keep the dev releases a bit more stable, and B: Trying to not overload myself with work to pack up and test new releases all the time (I generally do ~3 hours of testing before each release, and this is just not something I have time to do during the week while still making any new progress).

Think I also found/realized a few improvements that I can make to the engine cluster module now that things are a bit more settled/finalized. 1.) Allowing layout swapping by the mount-option definition for any layout with the same number of engines (cannot add/remove engines, only reposition them; stock limitation that I cannot workaround without introducing incompatibilities with tons of mods). This would allow for several mount/layout options for, for example, a 3x rs-25 cluster. 2.) Allow per-mount-option overrides of the layout spacing. This would allow for, for example, the SLS mount to be rescaled and re-used at 6.25m for the 4-engine cluster all within the same part, as well as potentially combining it with any other 4-engine variants/mount options. These two changes / enhancements would basically just allow for a bit more editor-part-count reduction, by combining the various mounts and layouts for a single engine type-count-combo into a single part, rather than potentially one part-per mount option. Most of the support is already there. The per-mount-option layout spacing override would be like 2-3 short lines of code. The per-mount-option layout override would require a few more lines of code, but not many more. So will probably get those implemented this week while I'm working on the engine mounting stuff. EDIT: Reproduced it in the editor too. It seems to be somewhat intermittent. Ran into this myself today, and think I have a test-case that can reproduce it reliably, so I should be able to get this one cleaned up for this weekend. Edit: And, resolved. Was a bug in the parsing code for restoring from persistent data... that would only effect the 2nd and subsequent fairing sub-parts for a module. All cleaned up now though, will be available with the next release.

Okay, so for those who were having problems with the radial decouplers, even with KJR installed, could you please help me track down the problem by doing the following: Download the test-craft file. It uses only SSTU parts, so you should have them all. It also ensures that I know how the craft was setup. https://www.dropbox.com/s/xzucor55n9t9mhg/JointTestCraft.craft?dl=0 Would be very helpful to test things first on a clean install. If not, there is little point to doing any tests, as the results would not really tell me anything more than I already know (that there is a conflict/config problem somewhere). So, set up a clean KSP instance (can copy the entire ksp folder, clear the GameData folder of everything but squad, sstu, and module manager). Either start a new game and add the test craft to that games ships' folder, or drop it in with the stock craft files (KSP/Ships/Vab). The first test will be without KJR, to ensure that the baseline in stock works consistently. Load up the test craft and launch it. Without struts (or KJR) the SRBs should sag pretty badly (See figure 1). Please take a screenshot at this point for comparison if anything looks different. Press the staging button to activate the SRBs. After the initial pad-explosion flames subside, you should see something very similar to figure 2 - if not, please screenshot it for comparison. If anything does not look like the posted shots for figure 1 or 2, please include logs in your post as well. The next test will be with KJR installed. Install KJR into the the previously setup testing instance. Go through the same steps of launching and comparison as before. The intended results are in figures 3 and 4. If your results differ, please post screenshots + logs + your KJR config files (let me know if you need help with those). Finally, load the test craft file into your normal playing KSP setup, and repeat the test a third time. If you have do not have KJR installed, you should see results as per figures 1 and 2. If you do have KJR installed, you should see results as-per figures 3 and 4. If neither of these is true, please post screenshots, if you have KJR installed or not, and any relevant information related to the mods installed. Thank you for your help in tracking down this issue, and sorry for the long and convoluted testing process. Unfortunately, due to potential mod conflicts or other strange interaction, this is the only way that I will know where to even begin investigating potential solutions, or if they are even a problem on my end and not some other mod interaction/'feature'. Figure 1: Stock, no-KJR, unlit SRBs Figure 2: Stock, no-KJR, lit SRBs Figure 3: KJR installed, unlit SRBs Figure 4: KJR installed, lit SRBs Yes, there is a few degrees worth of sag even with KJR installed. Pretty sure I noticed it being much better when I tested it yesterday morning, but I also had patched my decoupler to have higher mass ( 0.1 - 0.25) (am using one with 0.1 mass for these tests / in the test craft; which matches what was in Saturdays release). - - - Updated - - - On a separate note, I thought of a way that I could potentially include the jettison motors in the SRBs themselves. It would involve making use of the MultiModeEngine module, and a custom resource for the jettison motors (JettisonFuel or somesuch; doesn't matter at this point). I would then add a third custom module that would watch for a staging actions, or watch for the part being detached from the craft, and it would activate the MultiModeEngine switch and/or force-activate the secondary jettison engine module. And as MultiModeEngine/switching is fully supported through MJ and KJR, this solution would be fully compatible for the mods that I would be using. This would not obsolete the new booster-decoupler either, as it could still be used for liquid fueled boosters and non SSTU SRBs. About the only bit I haven't figured out would be how to manage the top end thrust transforms / disable the jettison motors when the flat-cap is selected (stack attached rather than radial). I guess I could even just check for that in the plugin, and/or have manual control to enable/disable the jettison motors. - - - Updated - - - As noted, the support exists, I merely don't ship configs for some of it. At all stages of the configurable parts I have enabled free-scaling through config of the model assets (and thrust/mass/resources/etc), so you can set things up for whatever you want. Will I do all of the work to make configs to ship those sizes with my releases? Umm, probably not. I don't use them. However if someone else designs configs for them and is kind enough to/wants to submit them, I am fully open to pull requests (either through GitHub proper, or contact me via-pm) and offering basic hosting for the more popular alternate config sets. I have done exactly that for the Pyrios styled mount, as that is kind of how it looked to be designed to me (the shrouds/side fairings extending up the side of the tank a ways). Was considering something similar for some of the other mounts as well, though it wouldn't exactly be 'realistic' -- the real articles seem to have a ton of room between the bottom of the tank and the mounting plane of the engines, at least all that I have found layout/plans/schematics for. I'm not too far along, so I'll see about some mock-ups to see how it would look/work out. Either way, fuel-resources can easily be added to any of the single-mount (non-switchable) engine clusters either directly or through patching. I could potentially add resource-switch-interlink capability to the engine-cluster module as well, though would be a slight bit more work.

It seems likely; yes. I just have a bit of a code-side mess that I need to clean up to allow the procedural mesh generator to more easily use different UV maps / texture layouts. Honestly, I could just add the texture switching as-is (using the existing UV layouts), but would rather clean up the mess first (would allow for greater re-use of the mesh-generator for other purposes). No particular ETA; this will likely be done when I am working on the procedural interstage decouplers (will be a double decoupler -top&bottom- with integrated ullage engines/rockets and separation rockets; if I can get it all to work out). Ah, no worries. Yes, the are still planned. I might just include some stock-rescale-patches for the interim for the 1.875 / 5 / 6.25m sizes. The finished articles will be very (-very-) similar to the KW rocketry fairing bases; might even use the same setup they have with a standard + widebody base. Have not yet decided entirely if I will be using the stock fairing plugin, or adapt the SSTUNodeFairing module to be piecewise buildable. Using the stock module would come with all the pros' and cons' that the stock fairings have (confetti, lack of control, a bit fiddly trying to make certain shapes, but works reliably and is quite configurable). Using the SSTUNodeFairing (or derivative) would have its own set of pros' and cons' to deal with. Would be highly configurable but would have a very complex GUI/setup system (I'm not interested in doing the mouse-driven system from stock; unless they have an easily usable API that I could just plug into); would require custom setting the height/radius for each segment individually, and would not pre-generate curves the way that stock does (you would have to generate whatever curve you wanted manually). However I could set it up to create sections whatever way was needed (e.g. split 2/3/4 section fairings lengthwise) rather than the stock confetti. Still a ways out on these though, so a bit of time yet to think this through / figure out the best methods. As already stated, yes. The engines and mounts will be surface attachable / you will be able to attach fins to them. Will it have a specific area intended -just for fins-, or attach nodes for them? No. Put them wherever you want, as many as you want, in whatever pattern/arrangement you want, angled whichever way that you want. (For reference, it will have the collider faces aligned properly for surface-attachment at those points, so they be able to be just slapped on there and 'just work') Edit: Will be posting up a .craft file here in an hour or so for testing of the radial decouplers. Will post testing instructions with the craft.

.... And.... The last promised preview of the last of the currently planned initial mounts: The Pyrios dual F1-B mount (3.75m base scale) This one is a bit unique in that the tank sits down inside the top of the mount a bit. And it also looks fairly good at 6.25m scale w/ 3x F1 Yep, learned some new work-flow process to get fairly clean results out of Boolean operations. Also lots faster than trying to do it all manually, and with the new cleaner results, it should greatly increase the speed that I can do a few of these parts.

Yah, I will probably look into cleaning up the fairing code over the next couple of weeks as well (rather, the procedural mesh generation code; specifically the UV mapping portions of it) to allow for texture-swapping of the procedural fairings. Would be nice to have some black/white striped interstages/engine fairings, or at least some more options for texturing on them. Although, I am curious why they would have orange insulation on the interstage -- there is no fuel there to insulate? And traditionally the interstages were often painted black/striped to help clear out condensation (if I remember reading that correctly). So... might have just been the artist having a brain fart moment. Also, there is no such thing as too much power. Anyone saying such a thing just needs to use more struts / reinforcement, or just needs to put more payload on it Apparently you did the right thing, and added more payload

In semi-related/unrelated news; NASA has _finally_ _officially_ confirmed that the SLS will -not- be painted (e.g. it will be orange foam). After only 5-8 years of showing it with Saturn-V style paint schemes.... (Was actually late last month (10-22-15), but I don't keep up on the news as much as I should). http://www.nasa.gov/press-release/nasa-completes-critical-design-review-for-space-launch-system - - - Updated - - - Very nice work. Does seem like you are having a bit of fun with the parts Lol, I love the engines clipped into the mounts. It seems that many engine mounts do actually extend down below the gimbal plane/mounting interface of the engines quite a ways. Still not quite sure how best to handle this in my mount designs (while allowing for re-use of the mount)... might just leave them open a bit (such as the preview of the new SLS mount). Heh, and is that an upper stage with 5xRS-25? LoL... need power much?

Why would they -not- be attachable? Yes, you will be able to surface-attach stuff to the engines/mounts.

No, I'm not messing with aero surfaces (for the foreseeable future). Use the stock ones. - - - Updated - - - How do fairing bases relate to engine mounts? Yes, I still intend to do some fairings, at least 5 + 6.25m (the sizes not offered by stock). However, they have zero relation to engine mounts, will be separate parts, and are not planned for at least a few more weeks/updates (they will likely come -after- the upper-stage stuff... so whenever the engines get finished + however long it takes to do the upper stages). Can only (reasonably, with any chance of success) work on one thing at a time....

A few previews of more mount geometry work; this stuff seems to be getting closer to final geometry. Generic Engine Mount - 5m base size, but could be rescaled. Includes easy mounting points for procedural fairing. SLS inspired 4/5 Engine Mount - Base of 5m, but could be rescaled for other sizes without too much problem. Saturn-V inspired 4/5 Engine Mount - Base of 6.25m, but could be rescaled for other sizes. Would likely work fine for an alternate SLS engine mount as well (would require different engine layout and spacing from default SLS layout/spacing). Unless I find major problems with the geometry on these, I will likely be including these mounts as the initial selection for the engine clusters (and one more, for the Pyrios boosters / 2x F1B on 3.75m; its an odd setup, and needs very special geometry for that configuration).

So, I did not notice any wobble or flex in my dev setup with KJR installed when I was testing it yesterday (yes, in stock/no KJR, they are really bad). It seemed to work exactly as I would expect given KJR... no flex, no wobble, even under thrust. But, to be fair, I have received one other report of joint flex even with KJR installed, so I will be doing some investigation on that point throughout the week. There is likely either a difference in the KJR configs (as joint stiffness is configurable with KJR) or some other mod conflicting/causing KJR to not do its job properly. To help out this cause, I will likely ask for some screenshots of a specific setup / craft file, along with logs + a dump of your current KJR configs; but, I need to do one more round of testing and prep before I will have the test-case/craft ready. Will hopefully get to this after I get home from work tonight. Awesome, thanks for your hard work and willingness to contribute . With all the work you guys have put in, I'll probably be giving RO a try in the near future as well. Thanks for the offer, it is much appreciated. I don't currently have anything publicly accessible/easily available to link. Will look into adding a Paypal link/button to the OP. Though, I am kind of averse to the whole monetization of mods and modding, as that was a part of the cause of my exodus from Minecraft modding. I'm not doing it for the money, nor would it be realistic for that to be any part of my motivation or reason to continue modding. The problem I ran into with MC was mostly ending up with a feeling that I was obligated to do modding work... which is not where I want to be this time; it results in sub-par work being done lots of 'rushed' features, and general feelings of resentment for the entire deal. But I have nothing against letting people buy me a drink or meal once in awhile, as it were. So if you (or anyone else) would like to send a small token my way, I would have no problem with that; it would be much appreciated. Will get the Paypal button added to the OP sometime this week; please keep in mind though that you are in absolutely no way obligated to make donations, now or ever. Spent a bit of time playing around with skinned mesh renderers yesterday. Powerful stuff, but I think it is likely overkill for my needs / the purposes I had intended, and would probably end up decreasing overall performance. I could likely get it implemented to be a good stand-in for the current fuel-line mechanics; but would need to implement nearly the full IK chain in order to get it looking good. Probably not worth the dev time to sort it all out and deal with the added complexities just for some minor visual improvement. Will keep it in mind for the future though; it has some very interesting capabilities (and applications) that I might find myself needing elsewhere. At least it opens up new opportunities for solving some problems, and being a bit more familiar with it, I will likely run across some good uses for it before too long. One decent alternative that I thought up for creating the fuel lines would be a custom procedural plugin that created each fuel line dynamically and managed updating its bones/geometry, but again it is probably not worth the work/effort to develop given how minor the feature is / how small the geometry is. Will likely aim to get at least one more engine finished up this week (F1, J2, other?), along with perhaps a couple of mounts for the RS-25 (mk3/shuttle, new SLS style 2/3/4/5 engine mounts). From my initial look over things, most of the mounts will end up being at least slightly engine-specific. Many will be re-usable for other engines, but will be more 'optimal' for the engine they were designed for. For example; the SLS style mounts won't work very well if scaled up to proper dimensions for the F1 engines (and actually have a different engine layout). Nor do the F1 style mounts scale down very well for use on an SLS inspired build (and in fact they look quite different). So.. my initial list of mounting options will probably be fairly short, something like: (stack size - preferred engine layout) 6.25m - 5 x F1 5m - 5 x RS-25 5m - Tapered, round, to be used for 2/3 engine mounts (and reusable/rescalable for other stack sizes and other engines). 3.75m - 2 x F1B (could possibly also be used for 3-inline engine configs where the outside engines slightly protrude). Mk3 - 3x RS-25 (if I can find a good way to make it work/if it will all fit)

Naming -- still deciding what I want to do for the engine naming / model numbers. Will likely keep it at least similar to the real model #'s, just for simplicity sake in keeping it all straight. Decouplers -- nothing I can (reasonably) do about joint stiffness. As others had replied, use KJR if you have problems. I just tested it with KJR this morning, and had zero issues using the 5-segment SRBs; there was no flex or wobble. For my stock screenshots, yes, I used struts. As stated by others, joints are a stock mechanic and there is nothing that I can reasonably do to fix them - especially considering KJR already exists. Yes, those are pretty much your only options; more struts, or KJR. EDIT: Reproduced it in the editor too. It seems to be somewhat intermittent. && Hmm.. that is definitely a new one. Likely related to the new method that I am using to store the persistent radius data and/or how it re-initializes from the persistence. If you can make a list of the steps needed to reliably trigger the problem, that would go a long ways towards helping me track down the cause and getting it fixed. I certainly did not see anything like that during my routine testing, though it is fairly limited to build, launch, revert to launch, revert to vab; build, launch, go to space center, return to vessel, revert to vab. These steps generally catch all of the KSP loading scenarios, but there may well be something that I'm missing. Will open up an issue ticket and work on getting this one cleaned up for the next release.

Thanks Think I've got the majority of the hard work done for the engines cluster stuff; from here on out it should just be creation of new mounts and engines. Which, I guess, is also hard work...but far less of a chance to break stuff than doing plugin work. Decoupler - noted, verified, and fixed. Thanks for the report SM -- Not seeing anything out of place with it? Which adapter are you using? There should no longer be any adapters necessary for the SM, and I thought I removed all of those pieces several releases ago, having replaced them all with procedural fairing modules. And... today I'm going to play around with something new (to me at least); skinned meshes / armatures / bone rigged models. I have a few intended features (and existing ones), that could greatly benefit from using skinned meshes as opposed to traditional animations (the fuel line stuff on the engines comes to mind). There are also a few other 'interesting' uses for these, if I can get them implemented / figured out in KSP.

Updated test release is available: https://github.com/shadowmage45/SSTULabs/releases/tag/0.2.16-beta Lots of changes, bugfixes, and several new features. Custom sized engine fairings may revert to default size on existing craft... See the link for the change-log for the exact details and the full list of changes.

Lol... Yes, they F1s have some odd stuff going on with them. Like I have said a few times; those engines are not intended to be actually used. They are there to test the engine cluster plugin with. As such, they are temporary parts. No effort has gone into balancing them or making them work beyond the scope of testing of the engine cluster plugin functionality. In fact, both the F1 and RS-68 will be removed from today's release, as they have fulfilled their intended purpose and still need considerable work done before they can return as usable parts.

Sure I can look into it, I've added your references to my folder of info. Seems like it might be a good higher-tech-tier engine. Note: The current F1 motors have -real world- thrust listed (and mass... and isp...), as they were put in merely to test the initial engine cluster plugin; as such, they will likely be changed/removed/breaking in a near-future update. Sounds like you got the tank stuff figured out with RedParadize' help. But yes, editing the fueltypes config file (or patching it with MM) is the proper way to change tankage fraction/mass fraction. There are actually two fields you can edit - The first determines how much volume is lost due to the difference in the actual tank compared to a cylinder (beveled/rounded tops/etc): tankageVolumeLoss = 0.15 The default is 0.15, or 15%. Stock uses a pretty wide range for their tanks, but generally falls between 10-20% The second field determines the dry weight of the tank - as a multipler of the volume lost, with the resultant value used as tons. tankageMassFactor = 1 The default is 1, meaning for every 1 m^3 of volume lost due to tankage loss, you will have 1 ton of dry weight. Generally this puts things in the ballpark of stock when left at default values. For your use case, realistic mass-fractions, I would actually suggest altering the tankageMassFactor rather than the tankageVolumeLoss. For stock liquid fuels, a 'tankageMassFactor = 0.3' would give you a ~5% dry-weight/mass fraction. Thinking on it... I will likely be changing that system up a bit to be a bit simpler to use. tankageVolumeLoss will still work the same, but I'll alter tankageMassFactor to work directly on the final computed mass of the resources; so you can just enter your desired mass fraction. Probably not for this update, but in the near future (perhaps next week). Thanks for helping out Much appreciated. Should start seeing the engines/clusters relatively soon. I have a bit more concept dev before I can start working on the upper stage stuff (and lots of stuff to finish/engines to make), but the upper stages will be based around the custom fuel tank module, with perhaps a few more additions for rcs/solar/ullage. Still working out the details, but I've got a bit of time yet. Will likely have the update available here in a few hours. Technically it is 'ready' now, but I'm trying to sneak in a last minute new toy, and it needs some texture work before it is ready.

My solution every time this problem pops up on my system is to edit the windows registry to re-force fullscreen mode (or disable it if it was currently enabled in the registry). Will try and update later with the exact key locations and what values need to be changed (if I remember); but basically there is a registry key that needs its value flipped from whatever it is (0-> 1; 1->0). You can also force-update your resolution while you are in there. After it is fixed I generally export the key to a .reg file so that I can re-fix the problem easily whenever it next occurs (which seems to be whenever I mess with the in-game video settings related to fullscreen mode). Ahh, here is a reference to the key location (mostly unrelated topic, but it explains where in the registry the key is located): http://forum.kerbalspaceprogram.com/threads/118264-Windows-KSP-won-t-accept-Joystick-axes?p=1888479&viewfull=1#post1888479

More multicoupler adapters -- definitely possible. Though rather than creating new geometry and needing new textures, I would rather just scale the existing parts along their Y axis. Would require some minor plugin/code changes to accommodate, but as there is already a scale field, I should be able to relatively easily turn it into a proper Vector3 to allow for per-axis scaling. Or even just create a second field for verticalScale that defaults to the regular scale value for that adapter. I just really don't want to create another set of adapters (right now)... doing the initial set and then trying to do the engine mount adapters nearly killed me (or my motivation at least). Certainly a possibility though, and with the way the plugin is set up these should be very clean and easy to add in at any point in the future. On that note, I need to spend a day or two and finish adding all the rest of the adapters/couplers to the new tanks too (I was just too lazy to figure out all the scales and attach node positions for the initial release of those tank sizes for that many adapters). Prev (tank/cap/texture) buttons -- Have already added a 'Prev Main Tank' button, and should be able to get the other buttons added. Was trying to keep the right-click menu clean/short until I can do some proper UI for it with the Unity 5 upgrade. But yah, I've often found myself clicking through 20 adapters just to get to the one that I missed... and having two extra buttons on there for now is probably worth the tradeoff for the added convenience. So.. consider it done (actually will be coding it as soon as I post this)

I was under the impression he was talking about the original ascent from Kerbin, where a 1.0 TWR should be plenty for the intended shallow ascent profile. However, I do need some larger engine options for upper stages for the heavier loads, 100t-300t. These will likely end up using J2X or RS-69 rather than the RL10, as the thrust on the RL10 is.... a bit lacking unless used in large numbers.

Not from me, at least not in the line of the current models. Future upper stages will consist of 2 parts -- a fuel tank section and an engine/cluster; so you will be able to make whatever size/TWR/crazy stuff you need. Gotta get all the engine cluster stuff finished first though.

Okay, thanks for your quick response and confirmation. I suppose I'll have to see if I can work around this on the plugin end of things then.

And here is just some of the fun that can be done using the engine-cluster plugin with just some stock parts: All 6 engines are a single part/engine cluster, including the rescaled quadcoupler as a mount option, note the part-count of 3 (MJ, tank, engines) The mount is just an option; the engine cluster can also be used by itself, and looks quite appropriate on a 6.25m tank.

Is it possible to insert a new module into a specific index in the part.cfg file with MM? (It states so in the instructions, but I have not been able to get it working). I am needing this for a partModule that has functions that need to run before other modules initialize (specifically, it needs to populate models and transforms prior to moduleEngines initializing and grabbing its transforms; hence my module needs to be inserted before the moduleEngines). for example: +PART[partName] { @name = exampleClonedPart MODULE,0 { name = insertedModuleName //rest of the inserted module fields } //rest of the patch } results in a URL/database dump of (excerpted for brevity) PART { name = exampleClonedPart //all the other stuff from the original file + patches are here, and exactly as they are supposed to be, except... //then, at the end of the file, it inserts the new/inserted module.... with the index value still attached, which does not load properly MODULE,0 { name = insertedModuleName //the rest of the module fields are intact and correct } } I did a fairly extensive search on the thread regarding this issue, and all I came across were multiple posts with the syntax examples saying that it is possible/supported. Is this in error, or is my patch structure incorrect, or? (https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Syntax#insert) Thanks for your help and understanding.