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

[Jimbodiah]

Yeah, the 0.40 matches then as that is 40%. Some engines are around 50% and others around 33% though, but it depends on what you use for the source material. I just averaged it at 2.5, and turns out I was not wrong

Edited March 2, 2016 by Jimbodiah

[Shadowmage]

9 hours ago, tater said:

The ablator on the 2.5m reentry pod is set to 450. The stock 2.5m pod's heatshield is rated at 800. 800 is overkill for stock, but on a larger kebin, 450 is not nearly enough for even a Mun direct reentry based on some testing I just did (entry at ~5200 m/s). It;s easy enough of me to change it, but the stock mk1-2 is just fine, even with a 3.2X kerbin and a 6.4x distance setting. Perhaps with rescales being a common thing, the ablator could default to 450, but you could add it up to 800 (with a mass penalty) in the VAB?

 

2 hours ago, Jimbodiah said:

The ablator was balanced for stock use, so anything needed for other mods would need to be made by yourself. The stock values kind of make having an ablator resource a moot point as you never run any risk of using it all up anyway. Kind of makes no sense to even have the mechanic if they use cheat values.

At 3.2 Kerbal there is not enough ablator on any of the pods, but you can patch that yourself in the cfg or with a MM config. I have the same issues now with my own 3.2x game where I am coming in at 5500m/s (mun return) and the Orion's ablator is gone about half way through the atmosphere. On stock Kerbin it is more than enough though unless you need two aerobraking passes, but even then it should still survive the heat. I will probably make a MM patch to check if 365 is running and then multiply ablator on the pods by 1.5 or something, might upgrade engine thrusts a little as well but have no idea about a balanced ratio for 3.2

 

 

Indeed, in fact not only is it balanced for the stock system, it is balanced to be usable only for Mun/Minmus re-entry, and -should- run out of ablator if used for interplanetary return.  This is completely intentional.  The stock 2.5m heat shield, by nature of being a 'generic heat shield', cannot be balanced so carefully, and needs to be overkill for the stock system if it is to be useful for interplanetary return or aerobraking through eve/jool.

Yes, a patch would be the proper way to handle changes for rescale mods.  If you come up with something that works (and is only enabled when the rescale mod is installed), feel free to put up a PR for it.  I have no problem with including support for mods that I don't use (my problem is with people asking me to use my time to support their mods).

[Jimbodiah]

OK, so I can't change the thrusts on the new engine modules, is that correct Mage? Ablator is patched and works when K365 is detected. Now for the engines. This is what I use (both with @ and %) but it will not change the values. I have it working on my B-SM though to raise the thrust, so I must be overlooking something with the other engines.

 

@PART[SSTU_LanderCore_LC5-DESE or any other engine]:NEEDS[Kerbin365]
{
    @MODULE[ModuleEnginesFX]
    {
        %maxThrust *= 1.27    
    }
}

 

If I can get it working I will send a PR on github.

Edited March 2, 2016 by Jimbodiah

[Shadowmage]

1 hour ago, ComatoseJedi said:

Is there a mod that changes the crew capacity to 7? I thought the highest was 6?

Hmm.. thought I had set it at 7?  Will look over this in the next few days.

 

1 hour ago, Jimbodiah said:

@ComatoseJedi  Ah, I took 7 as the shuttle had 7 people on board most of the time. It only has 6 in SSTU? Didn't even notice. Will it stay at 6 Mage? Else I need to change the LS patches. I also took 3 as the number for the Soyuz at the time looking at the current missions   "Assumption is the mother of all f_ck-ups".

@JoseEduardo I don't want to change the fuel types or their ratios, I'm not aiming for an RO-style patch, just a minor tweak on thrusts/isp.

 

Testing a nicer patch for the ablators right now that checks for the directory and just mulitplies the stock values instead of setting an absolute value, this way they will scale up with whatever Mage uses in stock.

I see the shuttle does not use the ablator mechanic at this point, will add it later.

Shuttle will likely not use ablator either way -- is going to use thermal soak type of setup, -similar- to how those parts currently work... but less buggy, and with better thermal management.  Will know more in a few weeks when I start working on the balance for it

 

1 hour ago, JoseEduardo said:

IIRC KSP stock isp are weaker than the RW values... you could tweak them to match the RW values and leave the thrust as it is?

The LH2 patch -should- be using real-world ISP values for all engines -- you should only need to scale the thrust (and possibly engine model scales) for solar-system rescales.

 

49 minutes ago, JoseEduardo said:

64%² = 40.96%

I remember mage saying a long time ago (in a galaxy far far away) he would do this math for it

I just wasn't sure if he also scaled the isp at 40.96% or if he used a "standard" isp value for a given use/fuel

ISP uses a remapping of a linear scaling.

(Example values, not the ones really use, just using numbers from the top of my head for example)
Real world vaccum ISPs = 280 - 465  (delta = 185)
KSP vacuum ISPs = 260 - 350 (delta = 90)

So, if a real world engine sits at 350 ISP, this would be 37% of the way between min and max for real-world, and gets mapped to 37% of the way between min and max for KSP.

350 - 280 = 70
70 / 185 = 0.37  (37%) (this is the percentage along the delta line)

0.37 * 90 = 33.3  (multiply the ksp delta by the percentage along the line)
260 + 33.3 = 293.3 KSP-scaled vacuum ISP

The sea-level ISP is then determined from the new vacuum ISP and the vacuum ratio for an engine (original sea level thrust / original vacuum thrust (or isps)).

 

53 minutes ago, Jimbodiah said:

I just made an excel sheet with the values from the link you sent me and what Mage uses. The thrusts are around 0.4x real-world values, but ISP is the same as real-world.

Kerbal is Earth/9.66

Mage uses 0.4x RL values (1/2.5)

Earth = 0.4 * 9.66 = 3.864

K365:   3.864/(9.66/3.2) =  = 1,27x stock thrust or 0.79xRL 

 

Please check my math, as I may just be having a brain fart. If it checks out I will patch the engines later today for K365.

Sounds about right...  will do some further checking here in a bit, after I wake up more and get a bit more caffeine in my system

 

12 minutes ago, Jimbodiah said:

OK, so I can't change the thrusts on the new engine modules, is that correct Mage? Ablator is patched and works when K365 is detected. Now for the engines. This is what I use (both with @ and %) but it will not change the values. I have it working on my B-SM though to raise the thrust, so I must be overlooking something with the other engines.

 

@PART[SSTU_LanderCore_LC5-DESE or any other engine]:NEEDS[Kerbin365]
{
    @MODULE[ModuleEnginesFX]
    {
        %maxThrust *= 1.27    
    }
}

 

If I can get it working I will send a PR on github.

The engines use a new naming format, so make sure you have the names properly.  Also need to make sure you are running the patch -after- the LH2 patch runs (as it sets thrust values for many engines).

Also, you can't use the % (add or modify) command when using a *=  (as the % allows it to add a non-existant value; you cannot multiply a non-existant value by anything...)

Try this:

@PART[SSTU-SC-ENG-J-2X]:NEEDS[Kerbin365]:AFTER[SSTU]
{
    @MODULE[ModuleEngines*]
    {
        @maxThrust *= 1.27
    }
}

 

[Shadowmage]

9 hours ago, ComatoseJedi said:

The shuttle works great. A little bit more tweaking on my entry so I won't overheat as bad. I did notice, however tiny of a detail this is. The IVA is facing the cargo bay. I mean, I love how it looks and everything, too, but I use instrumentation and cockpit visualizations to land V.I.A. the ASET mk3 cockpit and it's kinda hard to line up for an approach, however much like a brick it's supposed to be on approach (which yours handles very smoothly, I might add) while facing an empty cargo bay. But, other than that detail, wonderful work. It's definitely going to replace a lot of shuttle mod packs out there. And it's looking beautiful, too. Needless to say, I did make a landing, but I was off by  50 feet to the left of the runway, which is the closest I've ever came to landing a shuttle without crashing into the side of the mountain. 

 

Nothing can be done about that until stock adds an IVA model offsetting capability (ability to specify IVA location and rotation in the config file), and/or updates PartTools to be able to rework the mk3 cockpit (cannot even import it currently, as it crashes the part-tools plugin due to the new IVA shader they use but never released parttools for).  Even then the windows will not line up properly.

In short -- don't expect any IVAs out of this mod, now or ever (at least until/unless someone steps up offering to model them).  I don't use them, and -really- don't like working on them.

I'll remove the stock IVA from that part, as it doesn't fit appropriately, nor does it even have the right # of seats.

 

It is looking like the two biggest things this mod needs are:

1.) An RO patch person -- someone who has a few hours a week where they can update the RO patches for the latest SSTU updates.  Would need to be familiar with both RO -and- plugin coding (so they can look at the source-code to figure out how to fill-out the config).

2.) An IVA modeler --  I would gladly supply source/asset files for the models to anyone interested in modeling some IVAs for the various capsules (and upcoming station parts).  I just don't have the desire or patience to do them myself.

(A third would be a complete balance pass, but that is already scheduled... just have some patience)

If anyone is interested in either of those duties, please let me know through PM.  Would gladly give a 'co-author' spot to anyone willing to step up for those jobs (including access to the private dev repository, etc).

[blowfish]

@Jimbodiah I don't think it's reasonable to include patches for specific rescales, since (1) there are many available, and (2) they're not necessarily distinct anymore.

For re-entry, you should probably just reduce re-entry heating slider in the settings.

For engines, I don't think scaling the thrust is the right way to go unless you're scaling the parts too.  The nozzle area is 41% of its real life value, therefore the thrust should be scaled similarly.  I've actually found SSTU's balance to be quite reasonable for creating reasonably-proportioned rockets with a ~10% payload fraction in a 3x system.

[tater]

Makes complete sense, shadowmage, that's why I tried to present my suggestion within the very "adjustable" nature of the mod's parts (which is just stunningly awesome!), not that it generically change to ablator to 800 or something.

The only downside to the adjustable nature of the mod is in fact the right-click menus. I wish there was a way around this, while still keeping the minimal part counts. I cannot get to the bottom of some command pod menus, they exceed the window size, lol. Partially the chute status adds more lines as well.

The "jettison fairing" button doesn't seem to do anything (this covers the chutes, right?), at least in static and some right over the pad tests I have done. Also, there are 2 "control from here" buttons, which is presumably because it has a built-in probe core. The cabin and dock lights are also turned on via the light control by the GUI altimeter... (wondering if they could leave the right click menu, therefore). On the enable parachute staging, KSP is not super consistent in this regard. When you click the enable cabin lights button, the lights go on, then it switches to disable (as you would expect). What happens when you enable parachute staging? There is no feedback (I was sort of expecting a parachute icon to then appear in the staging list to the left).

This mod is, well, pretty amazing, truly innovative.

Edited March 2, 2016 by tater

[Shadowmage]

31 minutes ago, blowfish said:

@Jimbodiah I don't think it's reasonable to include patches for specific rescales, since (1) there are many available, and (2) they're not necessarily distinct anymore.

For re-entry, you should probably just reduce re-entry heating slider in the settings.

For engines, I don't think scaling the thrust is the right way to go unless you're scaling the parts too.  The nozzle area is 41% of its real life value, therefore the thrust should be scaled similarly.  I've actually found SSTU's balance to be quite reasonable for creating reasonably-proportioned rockets with a ~10% payload fraction in a 3x system.

Apparently I might need to give more consideration to my 'stock' balancing

But yes, I generally end up with realistic-proportioned rockets with about 3x the dV necessary for the stock system; during testing on Monday I made a Saturn-V/Apollo rocket, with >12km/s of dV, >9k of that was all in the lower stages! (the S-I stage got me to orbit alone, and I pretty much dumped an entirely untouched S-II).

 

Edit:

Edited March 2, 2016 by Shadowmage

[tater]

12km/s sounds about right for a munar mission in a 6.4X rescale.

 

[JoseEduardo]

is that a engine-less Shuttle?

[Jimbodiah]

@blowfish  Is there a way to detect the 3.2 scaling perhaps, that way I could check that (uses Kopernicus & scaling = 3.2) to scale them up for all the mods.

The fun thing of K365 is that it is focussed towards still using stock parts, just making it a bit more realistic vs a stock SSTU Delta IV taking you to Duna instead of just LKO. I've found that a realistic looking SLS (Orion, ISPC & lander) is just enough to get the 2nd stage into LKO and make a Munar burn (20-50dV left) and the lander needing to do the munar injection burn as well as land, leaving the orion to do some maneuvers and send itself back to kerbin. I think this is the best ratio for using stock parts without the need to rescale them in size, and get realistic looking RL rockets that are not OP as .... Rescaling the engines would mean rescaling the other parts as well, ending up with a not-quite-RO setup, IMHO negating the purpose of K365.

The current large engines would give just enough for their jobs as-is, but the smaller ones are just lacking a bit to make orbit in time without resorting to clusters of 5-7 engines (might as well use a J2 then for a small second stage which deviates the build from anything realistic looking). It's a compromise between stock and realism, won't be to everyone's taste, but neither is K365 I think with it's 3.2 bodies and 6.4 distances. You can go either way depending on who flips the coin. I'm just patching to keep the current part sizes with minimal work into the patch, yet make it a tad more playable in 3.2 without resorting to using more a larger engine cluster.

I think, correct me if I am wrong, that 64K would be a better place for an RO-style overhaul on parts sizes and specs, but other people more knowledgable than me should make those. I just hack some cfgs to suit my game play in the end.  can ask Mage to include it or just offer a seperate download for as long as I play it myself (which could be ofrever or until I freak out tonight with something). ROFL.

Edited March 2, 2016 by Jimbodiah

[Jimbodiah]

32 minutes ago, Shadowmage said:

But yes, I generally end up with realistic-proportioned rockets with about 3x the dV necessary for the stock system; during testing on Monday I made a Saturn-V/Apollo rocket, with >12km/s of dV, >9k of that was all in the lower stages! (the S-I stage got me to orbit alone, and I pretty much dumped an entirely untouched S-II).

Hence the 3.2 scaling is just about perfect for SSTU  mwuhahahahaha   

 

 

And Mage... the thrust works now!

Edited March 2, 2016 by Jimbodiah

[Shadowmage]

37 minutes ago, tater said:

Makes complete sense, shadowmage, that's why I tried to present my suggestion within the very "adjustable" nature of the mod's parts (which is just stunningly awesome!), not that it generically change to ablator to 800 or something.

The only downside to the adjustable nature of the mod is in fact the right-click menus. I wish there was a way around this, while still keeping the minimal part counts. I cannot get to the bottom of some command pod menus, they exceed the window size, lol. Partially the chute status adds more lines as well.

The "jettison fairing" button doesn't seem to do anything (this covers the chutes, right?), at least in static and some right over the pad tests I have done. Also, there are 2 "control from here" buttons, which is presumably because it has a built-in probe core. The cabin and dock lights are also turned on via the light control by the GUI altimeter... (wondering if they could leave the right click menu, therefore). On the enable parachute staging, KSP is not super consistent in this regard. When you click the enable cabin lights button, the lights go on, then it switches to disable (as you would expect). What happens when you enable parachute staging? There is no feedback (I was sort of expecting a parachute icon to then appear in the staging list to the left).

This mod is, well, pretty amazing, truly innovative.

GUIs -- with 1.1's updated GUI system I plan on doing some custom GUI's for many parts that will cut down on the extra buttons and clutter.  This should make the modular parts easier to setup in the editor, as well as removing/changing some of the options while in-flight.  I'm also working on a module that will disable some of the stock right-click actions (WIP, works for some, but not for the 'control from here' apparently).  Mostly though, this is a stock problem that there is little that I can do about at this point.

Parachute staging -- there already is a staging icon for the command pod, and the staging action is dedicated to the decoupler; so it is not surprising that the icon does not change.  This is a stock problem with its assumption that a part will only have a single staging action, and there is nothing that I can do about it at this point (and likely will not be changing any time soon / at all; either way, the fix needs to come from SQUAD in the form of supporting multiple staging actions for a part, with their own distinct icon and placement in the staging list).

Jettison Fairings -- the button -would- do something if you set your fairing-sections to >1 (where they will jettison outwards); otherwise, it is attempting to jettison the fairing only to find that it is still attached to the part below it.  Yes, could probably do some GUI cleanup of that module so the button only shows up if it is possible to jettison; patience... all of that is already scheduled for the 1.1 update.

Lights -- again, have some patience and see what the 1.1 update has in store for the GUI's.  Most of the GUI related stuff should be a lot cleaner.

Otherwise... thanks   I'm aiming to make something a bit unique...  KSP has lots of parts-packs, but none others dedicated to modular parts/low-part count setups (that I could find...).

 

 

[tater]

The SC-A-CMX has the temp int/skin listed in the description as 3400/3400, vs 2400/2400 for the other SC pods. The stock mk1-2 lists 1400/2400.

The LC pods are all 2400/2400, whereas the mk1 lander can is 1000/2000, and the mk2 lander can is 1200/2000.

Presumably they'll get balanced with lower heat tolerance, all around. (1400/2400 for the reentry pods, and closer to 1200/200 for the LC pods, I suppose).

EDIT: Yeah, this mod has become an instant favorite. I love the idea of variant pods. It's very, very cool. Well done.

Edited March 2, 2016 by tater

[Shadowmage]

30 minutes ago, JoseEduardo said:

is that a engine-less Shuttle?

Well, yes, and no.  Its just the geometry that I'm using for unwrapping and texturing doesn't have any engines attached to it (easier to keep a set of geometry to work on without rigging, and a second set that is all rigged up for export; at least for this part).  However that is what an engine-less shuttle would look like   (which I -will- be releasing, as soon as I get a bit more work done on the actual part(s)).

[Jimbodiah]

You can also use engines to make a hard landing and survive intact  (screw engines or chutes!)  But I think this is the balancing pass that Mage mentioned. If you find anything in the meantime, you can always open a Pull Request on Github, or ask someone here to add it for you. This way Mage can see what people are requestion to be changed and implement it in a single location (github). I think any info that other people can give and have changed is less time Mage will need to go over all the parts himself. Hollar if you have anything and want me to PR it. José and Blowfish can help out too perhaps?

PS: Mage mentioned this earlier, but if you press your middle mouse button (scroll wheel button) then you can rotate camera view and see the rest of the GUI list. I didn't know about this either until Mage pointed it out a while back.

First pass on the Kerbin365 patch... hollar if I forgot something etc   http://kerbal.nl/sstu/K365.cfg

 

Edited March 2, 2016 by Jimbodiah

[Jimbodiah]

47 minutes ago, JoseEduardo said:

is that a engine-less Shuttle?

Warp drive: no nozzles. It's the enterprise after all

[blowfish]

@Jimbodiah I don't disagree that the scaling is about right, I just think it's problematic to include any such patches in SSTU.  Any patches you want to apply to your local setup are of course your choice

Re thrust: I've found it to be generally fine, especially for lower stages.  If you're comparing to the J-2, then presumably you're taking about the RL-10, which even in real life has notoriously anemic thrust - at full payload, the Delta IV Heavy's upper stage limps to LEO on a TWR of only 0.18.  In KSP that would be rather insane, but I've found that a reasonable 0.3-0.4 TWR is manageable if you tune your ascent path, angle upward to keep your time to apoapsis up, and accept falling a little bit before circularizing (and this is exactly what happens on real rockets, it's just a little more extreme).

[Jimbodiah]

I've already found myself pointing up longer to get out of the atmosphere quicker, as I do indeed fall a few km before reaching orbit. If I would use the same settings as stock kerbin, I would be going 3400m/s in the atmosphere and still not make orbit. And I was indeed referring to the RL10s; with stock kerbin 1-2 of these are plenty for my second stages (soyuz uses one I think,sometimes two if I am impatient and want a quicker ascent, but they do just fine). In 3.2x they just don't have enough thrust to make orbit without adding more dV to the first stage. I tend to have a first stage that gets me out of the atmosphere, then jetisson and use the second stage for circularizing or maybe a small part of the initial burn. It's a balancing act for sure, and as such more of a challenge then just do the standard near-straight up burn to 135km and then cicularize (I always go to 135km as time warp goes one notch faster above 130km, so rendezvous is quicker, lol).

[JoseEduardo]

1 hour ago, Shadowmage said:

Well, yes, and no.  Its just the geometry that I'm using for unwrapping and texturing doesn't have any engines attached to it (easier to keep a set of geometry to work on without rigging, and a second set that is all rigged up for export; at least for this part).  However that is what an engine-less shuttle would look like   (which I -will- be releasing, as soon as I get a bit more work done on the actual part(s)).

thought the engine-less version would be named Enterprise (because it was the aero testbed)

thinking about using RL-10A3 or CECE as main engines (instead of the Buran ones) and 2x jet engines in the OMS pods

1 hour ago, Jimbodiah said:

Warp drive: no nozzles. It's the enterprise after all

speaking of warp drives, which FSD should I use on it? 5A?

[tater]

How "variant" could you, or would you be willing to, make certain pods?

Right now it's just a matter of "saddlebag" tanks. A simple addition to that might be "storage" tanks/bins (KIS support). With enough volume, then you could pack small rover parts to assemble after landing... an SC-32 KIS container is 1000l. A box the same footprint as the ascent tanks would be at least that big, even on the LC2.

There is not too much you can do as far as variants go for conical pods, other than changing the texture.

What about the SC-C DM and OM? They seem to be just shy of 1.5m at the widest point. The DM is obviously limited to being a functional, 2-kerbal pod (though 2 kerbals with helmets might not fit in 1.5m).

Perhaps there could be color variants (a more stock color as an option)? The OM might have a shape change, I suppose (as a variant), perhaps a 1.5m cylinder, maybe with a taper to the docking port on one side, and a taper to 1.25m on the other? This would provide a variant orbital module for "stock" looking craft. This fills a role similar to the Mk1 Crew Cabin, while looking properly spacecraft like, vs aircraft like (and it's a command pod). Another SC-C OM variant could remove the docking antennae, and instead have 2 extra docking ports on the side (you can see what this looks like by adding 2 symmetrically in the VAB), this would be the "Hub" OM variant. 

[Jimbodiah]

34 minutes ago, JoseEduardo said:

speaking of warp drives, which FSD should I use on it? 5A?

I think it will only fit up to a 3. It only has 20t cargo capacity.

[ComatoseJedi]

@Shadowmage You have crew capacity set at 6 for the shuttle (just checked). As far as IVA's are concerned, I know they are a pain in the neck to do and take more time for hardly anything in return. I may find myself getting into that. But, as far as making one for your shuttle, you don't really need to make one. There's already one made, but it uses a dependency (other than RPM), which almost everyone has. Take it out if you want or keep it in, doesn't really matter, I just thought you didn't know (obviously I was mistaken). And I have noticed that the Part Tools have been acting kind of funky lately. I been working on an interplanetary command module to work with another mod and found that Unity has been acting strange. I wonder if Squad knows their tools are acting up? Meh, who knows what's going on with that. Anyways, thanks for your input on that. 

[Shadowmage]

3 hours ago, tater said:

The SC-A-CMX has the temp int/skin listed in the description as 3400/3400, vs 2400/2400 for the other SC pods. The stock mk1-2 lists 1400/2400.

The LC pods are all 2400/2400, whereas the mk1 lander can is 1000/2000, and the mk2 lander can is 1200/2000.

Presumably they'll get balanced with lower heat tolerance, all around. (1400/2400 for the reentry pods, and closer to 1200/200 for the LC pods, I suppose).

EDIT: Yeah, this mod has become an instant favorite. I love the idea of variant pods. It's very, very cool. Well done.

Aye, making all of the stats conformal will be part of the balancing pass.  Currently they use whatever the value was from the config that I copied (with some fixes to make sure the parts -work-).  Generally re-entry pods will be ~2400 (to keep the heat-bar from showing up during re-entry), most others will be ~1000 (including the orbital versions of SC-A/SC-B).

 

2 hours ago, JoseEduardo said:

thought the engine-less version would be named Enterprise (because it was the aero testbed)

thinking about using RL-10A3 or CECE as main engines (instead of the Buran ones) and 2x jet engines in the OMS pods

speaking of warp drives, which FSD should I use on it? 5A?

Actually was just testing the decal positions/sizes/rendering.  Think I've got them nearly figured out... now to code the module to support them, re-export the parts + textures, and get it all working in-game....

Hmm.. I think an A4 should be plenty for its weight and capacity (40t+20t cargo)

 

1 hour ago, ComatoseJedi said:

@Shadowmage You have crew capacity set at 6 for the shuttle (just checked). As far as IVA's are concerned, I know they are a pain in the neck to do and take more time for hardly anything in return. I may find myself getting into that. But, as far as making one for your shuttle, you don't really need to make one. There's already one made, but it uses a dependency (other than RPM), which almost everyone has. Take it out if you want or keep it in, doesn't really matter, I just thought you didn't know (obviously I was mistaken). And I have noticed that the Part Tools have been acting kind of funky lately. I been working on an interplanetary command module to work with another mod and found that Unity has been acting strange. I wonder if Squad knows their tools are acting up? Meh, who knows what's going on with that. Anyways, thanks for your input on that. 

Its not a problem with lack of availability of IVA models, its a problem with the -positions- of the models.  If you overlay the IVA model for the stock Mk3 (or any other shuttle-cockpit-iva) onto the SC-E-FS part, the model sits back in the cargo bay (where the origin of the part is).  This is due to all existing shuttle-IVAs being created for just a cockpit rather than an entire fuselage.

As far as I'm aware there is no way to solve this given the current IVA tools/setup/methods available.  Ideally I would be able to position, rotate, and scale an IVA the same as I can with models defined through MODEL nodes...

hmm...

@NathanKell  What are the chances of sneaking such functionality into 1.1 (IVA model repositioning through config) (if it doesn't already exist, and I'm just ignorant/blind?) (sorry, hate to bug you with mundane stuff like this....; feel free to ignore me or tell me no )

 

Edit:  I can likely fix this through some... hacks... once 1.1 is released with its fixes to the gimbal module COM stuff (can reposition the fuselage to line up with the stock IVA, and use config-based COM offset to position the COM where it needs to be).

Edited March 2, 2016 by Shadowmage

[NathanKell]

@Shadowmage I know scaling does exist. For submodels position certainly does; for the root model, I don't know offhand.

And NP. Also, pinging @Porkjet since he's been doing a lot on IVAs, and because some of the stuff I wrote I wrote for him.