Shadowmage

Hmm.. strange.. it is using the same stock module as the SCA side panel fairings (and all the stock engine fairings)... I'll see if I can reproduce any weirdness; I honestly have never tested it aside from briefly in the VAB to make sure it appeared when something was put on that node. Good news on the SLS stuff, should give you at least the entire Block I configuration and setup. I'll have to take a look at the new (old) stuff

More info? What exactly are the odd bugs? (I might have forgotten a fairing=true/false setting in the config, or rather have it inverted...auto fairings are a bit strange).

ICPS - should- have two upper nodes; the far-upper one is intended for use by non Orion stuff.. it generates an auto-fairing. The lower of the top nodes, which is slightly inside the geometry, is intended to be used with the MSA adapter. It should also have two bottom nodes (with auto fairings); one for 3.75m fairing, and one for 5m fairing. Same thing with the CM; it should have two bottom nodes. The lowest one comes with an auto-fairing, and is intended for use on other 3.75m stacks. The internal one is intended for use on the SM. -- I couldn't really find any better way to deal with allowing multiple configurations for these pieces; it was either add double nodes and allow player choice that way, or duplicate (quadruple?) the pieces to accomodate every option. Regarding bugging Squad to fix their stock bugs -- from my previous experiences with attempting to get bugs fixed in games that only effect mods, I'm going to pass. Coming from Minecraft modding, we created an entirely community driven API and series of stock-bug-fixes, as the devs were unwilling (or unable) to make an API or fix the bugs themselves (see Minecraft Forge). It really sucks that companies that advertise the modability (heck, they have an Add-Ons link on the main game menu!) of their games so heavily are so unwilling to fix problems in their code to help out the modders that help sell their games. However, from a developer standpoint, 'if it ain't broke, don't fix it' is the general rule; and if it works in stock/vanilla, they generally don't consider it broken and are unwilling to devote developer resources to fix problems that only effect external mods (even if it is a legitimate problem and easy to fix, such as the animation layering). Squad -might- be better in this respect; but still likely a waste of my time to try and have them fix their bugs. Re- Orion interior; Yep, I already have every image that I could find on the web (especially that one... was one of the best images that I could find of the controls). If you note the cockpit panels from the IVA preview screenshots, they are eerily similar to those in the image _Augustus_ has posted (minus the MFD panels.... which are present now, but did not make it into those screenshots). I went for 'close' rather than mimic the real one exactly; as I needed it to still be usable, hence it needed things like altimeter and speed gauges that the real controls do not have (theirs are all done through the MFD panels... which will be non-functional in the stock IVA); and the real layout is still under development as near as I can tell. The current MFDs I have now are just a placeholder / blank display... no image or interactivity, and will probably stay there for the 'stock' IVA. I will investigate adding in RPM or other more interactive props for alternative IVA setups. Will be doing RPM setups -after- I have the rest of the IVA done (model/texture) (maybe...I do not use RPM, so no real motivation...).

Nope, no separate heat-shield part, model or anything. The CM works fine with no additional shielding, at least in stock (most of the other command pods that are designed for re-entry, such as the mk1 and mk1-2 are fine as well). Granted, I have not attempted to aerobrake just the CM into Eve at orbital insertion velocity; but I would wager that it would fare better than the stock mk1 and mk1-2 pods comparing their relative heating performance on Kerbin re-entry. And if you use (semi)-realistic multiple-pass aerobraking to reduce your speed to just-above orbital velocity (2400ms on kerbin), the dang thing doesn't even heat up at all if given a gentle re-entry vector (srsly, think I saw a 350 as the highest temp on a gentle re-entry). It was designed to be used exactly as it is with no heat-shield module, nor additional heat shield parts. At least, that is how I am using it in my career-hard-mode game without issue. I've noticed heat-shields to be most useful when returning non-capsule stuff from orbit. Every capsule that I've added a heat-shield to (stock capsules) just ended up performing worse and hardly using any ablator (100-200 was the highest I saw); and that amount of heat can easily be absorbed by the capsule to be radiated off in the lower atmosphere or upon splashdown. I will generally include a heat-shield for testing of a new re-entry capable design; but have always ended up ditching it after the first couple flights result in it not using up any ablator. I mean... what -does- it take to use up a stock 2.5m heat shield? 4500+ms direct-to-ground re-entry? This is all from my personal testing though; I have not yet tried dropping any CMs onto Eve at high velocity, but I would imagine Laythe and Duna to be gentle on the re-entry compared to Kerbin. If anyone has any personal experiences that contradict my findings, please let me know and I will gladly investigate and update my knowledge. Anyhow... you are free to do as you wish with the config either way. I'll be keeping my un-edited version with no heat-shielding

A: Ablator -- the CM was NOT designed to have a HeatShield Module. _Augustus_ added that himself. It does -NOT- need a heat shield for a direct-from-Minmus-return trajectory (3600+ m/s @40k alt on return), even at 120% heating (seriously, try it with the ablator removed/module removed from the .cfg). It is big and wide and has lots of drag and slows down quite quickly. Any issues from ablator/heat shield, please take them up with _Augustus_. (Honestly, it just needs to be removed, as it is _NOT_ supposed to be there). B: Solar panels -- stock bugs. Nothing can be done about them for now (neither the breaking on fairing jettison, nor the animation problems, nor the action group probems). Seriously, stock was never meant to handle this complex of a part. The problems stem from: Multiple simultaneous animations (stock does not allow for animation layering/separation); mutliple same-named action group keys (because it is using stock solar panel modules, and those do not allow custom group names); and the breaking is caused by stock not respecting the 'breakable=false' flag in regards to collisions (and it also for some reason adds physical colliders to supposedly non-physical fairing debris). In my personal games I have written a custom plugin (and solar panel module) that handles the solar panels much better (animation, persistence, non-breaking, action groups.... pretty much fixes all the bugs); but it will likely be a few weeks/months before I am willing to release it (if ever)(was a huge PITA to write, and may or may not have some licensing problems preventing it from being released... will need to speak to some others for more info). Lots of testing will need to be done, and probably quite a bit of code cleanup and refactor (still learning the KSP API), but it didn't make my game explode even once last night, so it is off to a good start. C: Stack nodes -- feel free to add them yourself. Quite simple to do via MM patch or even direct config editing. I will -not- be adding them to the base model as it is meant to be used exclusively with the SCA and MSA adapters at the bottom (which allow it to fit on a 3.75m stack seamlessly). D: ICPS Stats -- yes they are greatly nerfed compared to real-life. Beacause if I went with the real-life dV stats, you would never need any other upper stage. In reality the ICPS is -just- enough to do a moonshot (and orbital insertion? I think the SM engine actually does that part...); so the ~1200 dV I gave it is still 50-100% more than it should/would have (relatively scaled). It is called an 'Interim' propulsion stage, as it is meant to be replaced by (or combined with) larger and more capable upper stages for missions to more distant destinations (and I believe the ICPS is really only scheduled for one mission before they start using larger upper stages?). So, in those regards, the upper CSM stack is extremely overpowered; it should probably only have 400-600 dV when scaled down to KSP system, but it was the portion that I would prefer be overpowered if given a choice. But to each his own; if you feel it needs more performance, there is nothing to stop you from doing a patch like you have. That is one of the great things about KSP/modding/mods (I love the fact that I can alter so much about the game with just a text-editor). In the mean-time; some preview of a very early WIP IVA for the CM (and some other misc stuff) --

More precisely, I believe the inventory for each pod in the VAB is supposed to be representative of the inventory of Kerbals inventory. So no kerbals in a pod = no accessible inventory. IF you had a kerbal in the seat with the wrench, he should have it on him/in his inventory when he leaves the pod. The reason for loss of inventory when having a kerbal enter a pod, is that the kerbals inventory is overwriting the inventory setting for that seat. You -might- be able to work around the problem by putting a wrench in seats 2+, that way when the kerbal enters @ seat 1, the other inventories -might- still be intact (have not looked at source code, so cannot say for certain if this would work or not).

Post Deleted

Series C is mostly (aside from IVAs and config tweaks) complete. So it may well come before A and B Series-A is technically complete, but there are a few issues that will require model recompiles to fix, and Series-B has some texturing, animation, and config stuff yet to do. It is looking likely that the Series-A CSM (but not LM), and entire Series-B core sets will be released under the Bacon Labs banner in the near future -- http://forum.kerbalspaceprogram.com/threads/121217-Bacon-Labs-Stockalike-Ariane-More-Version-1-0-Official-Release!-13-May . So keep an eye out there over the next few days/week or so, and you will likely see them pop up. The Series-C parts (and other misc. pieces) will probably be packaged up and released independently in the near future. I have to decide how best to organize the parts and assets for release given some of the texture sharing that is going on. It is all available on github currently (in the GameData folder) if you want to go through the effort to get it from there; just be mindfull of the WIP/unfinished state of some things.

Thanks I've tried to keep them as stock-alike as possible, at least the later stuff that I've done. The Apollo stuff is... meh, but were also some of my first attempts at texturing, and I tried to keep them 'real' looking...but unfortunately super-shiny/silver is a really hard look to do without reflective shader support. As to dimensions (will update the OP with this info shortly) Apollo stuff is 2.5m core, with 0.625m docking port (which is actually really close to the proper scaled size it should be). LM is 2.5m-3.7m; it -barely- fits inside a 3.75m fairing. Included is a 3.75m -> 2.5m petal adapter to house the LM (shown in screenshot). Orion CM is 3.75m core (some fairing/adapter parts are a bit wider...but thats how they really are...). The CM alone -will- fit on top of a 3.75m stack; it even includes a fairing for its heat-shield. The ICPS has lower fairings to support both 5m and 3.75m lower stages. Some of the misc-parts... I'll have to get some good screenshots for scale on those...

Post deleted...

As far as I know those are all still valid concerns. Multiple animated/module driven parts will often not work correctly when welded together. For instance with landing legs; only a single leg will function. Same with solar panels (at least, only a single one will function for the suncatcher transform, so you may get power from multiple panels, but only one will responsible for updating the power curve, and may not accurately represent the sun-angle/power output that should happen from multiple panels). No clue on what happens with struts or fuel lines, though both are 100% uneccesary. The vessel becomes one big part; there are no inter-part reinforcements needed, so struts are useless. And as one big single part vessel, there are no parts for fuel to flow through, only the single part that it resides in; so fuel lines too are un-needed. IR and Procedural parts are a big 'no'. Any part that messes with meshes is going to have problems as they are generally designed to only have their modifiable mesh in the part. There -might- be a few that work, but I haven't found them.

In unity inspector, select your blend/.fbx/model file, go to the 'rig' tab, and change animation type from 'generic' to 'legacy'. Not sure exactly what this does, but it has been necessary for many of my animations imported from blender. And... as lo-fi said... configs would be great to see to be able to help more.

Yep. Take the 3.7m tank and attach it to your rocket. Empty the rocket fuel. BAM! instant storage for a 3.75m tank! (You can then use KIS to attach/detach it as needed...) (Seriously, how do you expect a Kerbal to store a giant tank inside of something smaller? )

Even the newer ones (NASA pack) should be usable in welding, but you will need to search/replace the URL in the MODEL{} node to point to the updated model location. So, not exactly drag-and-drop, but I believe they should work after the changes (Have not yet gotten around to transferring my welded parts yet, though it is looking more likely that I will be doing it over the weekend... will post up any details/issues that I find).

I have had general sucess using multiple ModuleAnimateGeneric on the same part / in the same .cfg file. Just don't have them share any objects/meshes between the animations and there should be no problems. For example one of my command modules has 3 ModuleAnimateGeneric implemented on it (docking light, cabin lights, and extending a transmitter): https://github.com/shadowmage45/KSPMods/blob/master/GameData/SSTU/Parts/ShipCore/series_c/SC-C-108a-CM.cfg, and all function without issue (both on .90 and 1.x). I really think the problems often come from attempting to use multiple animations that animate the same part, or in a few cases I have seen where it is merely a hierarchy issue (I solved a couple animation issues by adding the secondary animations directly to the animated part rather than on the root part as is common practice).

Yes, Though last I played with it you had to dock and then return to space center and back to the vessel or swap vessels and back in order for the connection stiffening to occur (basically force a re-unpack of the vessel). Using this I was able to send 250t+ payloads connected by nothing more than a single Docking Port Sr. -- no struts or multiple docking ports required.

Okay, thanks for the response; Perhaps I will have to rethink my parts/layout a bit. Was trying to cut down on the excess part count on finished vessels by including always-needed functionality into the parts that always needed them, but apparently KSP is not designed to properly handle these / is setup specifically to encourage part spam. Not the first time I have encountered difficulties while trying to use multiple unrelated modules on a single part; it appears that the KSP devs did not intend to ever combine functionality of many of these modules... which is unfortunate. Just trying to combine an emissive animation with a parachute module on a command module has caused no end of headaches (drag cube issues...). Thanks again for the response; apparently I have some redesigning to do in order to conform to the KSP way of things.

Hi all, I am working on a set of parts, many of which have multiple actions available to them that normally would activate through staging. For instance I have a command pod that has a decoupler on the bottom node and also has included. Hitting the 'stage' action for that part will activate the decoupler -AND- the parachutes; which is often not what the user would want (e.g. you want to decouple prior to re-entry, and activate parachutes quite a bit later after most of re-entry is complete). Is there any stock method to split the staging actions of a single part? Is it possible to accomplish this through a custom plugin-module code (e.g. if I wrote a custom decoupler and/or parachute module); is it at all possible to have a single part with multiple staging icons/actions? Alternatively, is there a way to specify certain modules to -not- activate through staging? For example, is there a stock method to disable the staging action from the decoupler or parachutes? Having just a single action trigger through staging could be an acceptable work-around.

Yes, I have tried it with the procedural flag; that is what it defaults to for my part. This does not work when trying to utilize the parachute drag-cube modifier modules in my part .cfg file to enable proper parachute draginess; the part plummets to the ground with seemingly normal drag regardless of deployed status of the parachutes (animation works properly for both semi- and full-deploy, including the altitudes when they should activate). Regarding the stock issue; if you take a look at the stock parts that override the drag cubes in their part.cfg (stack separators are one example) -- while the drag-cube names are properly set in the part .cfg file, the drag cube names are incorrectly parsed when they are loaded into the PartDatabase.cfg. The entries in the PartDatabase.cfg file instead of being named 'cube = Default, [values...]', are named such as 'Default = Default, [values....]' (it writes the drag cube name twice, once where it should have written 'cube'). When this problem is applied to the drag-cubes for parachutes loaded from my part .cfg file, it results in the PartDatabase entries reading like 'DEPLOYED = DEPLOYED, [values...]', rather than the properly specified 'cube = DEPLOYED, [values...]', and these values fail to load/be recognized properly in regards to the parachute module. I cannot confirm if the in-part-.cfg file overrides actually work properly for the stock parts that have them, I am not sure of a way to view the numerical values for the drag cubes while in-game to see what was loaded. Still working on putting together all of the information/etc so that I can open a proper bug-report, if that is what it turns out to be. Sorry for the semi-off-topic posts and thanks for the response; been trying to sort out this problem for a few days now, and this is about the last recourse I have (other than removing all other non-parachute animations from my part... which allows it to work/be auto-calculated properly... but I'd rather keep the functionality/animations if I could). Edit: Just to update; I was/am not looking for you to add additional functionality/create extra work for you; mostly just inquiring -if- it was possible, and explaining the problem. I still have a couple of possibilities to investigate for solving the problem (such as writing a custom animation module that does not interfere with parachutes/drag cube calculations, or perhaps even just trying out the FS animation modules).

You can use NODE based attach nodes to precisely position and orient your attach points. Create empty transforms in your model, positioned and rotated properly, and reference that transform name in your config. Problem solved; all of your attach nodes are exactly where they should be, and pointed exactly the direction you specify For more info: http://forum.kerbalspaceprogram.com/threads/96100 http://forum.kerbalspaceprogram.com/threads/36455?p=460394&viewfull=1#post460394 http://forum.kerbalspaceprogram.com/threads/95336-Workaround-How-to-convert-angle-to-unit-vector-%28angled-stack-nodes%29/page3 Alternatively, you can use a slightly modified method of the above to use the traditional node_stack_top type node declarations. Create the empty transforms in your model positioned where they should be, and note their location coordinates; copy these coordinates into your node definition, and manually calculate the axis (works best for axis-aligned nodes... calculating off-axis node angles can be a PITA) (might need to swap and or invert Y/Z coordinates, depending upon your modeling program and rotations). It is not in-game; but in-model-editor... which I generally find to be more precise and easier to work with. As far as in-game tools, I am unfortunately not aware of any...

Hi all, I was wondering if it is possible to patch lines (drag cube entries) in the PartDatabase.cfg file using ModuleManager? The reason I ask is that I have a complex part that refuses to properly auto-calculate drag-cubes when all of its animation modules are enabled (a conflict between ModuleParachute and ModuleAnimateGeneric prevents proper calculation of the ModuleParachute drag-cubes), the ability to manually specify/override drag-cubes in the part.cfg file itself is bugged and will not load them properly (they are not named properly when loaded from the part.cfg file), leaving my only recourse to manually patch in the proper drag-cube entries into the PartDatabase.cfg file. Is this feature currently supported?

SSTU - my in game Company / manufacturer of my modded parts.

The way I solve thrust differential problems in my RC model airplanes is to A: Offset the angle of the motor, usually it is pointing a few degrees to the right and downward. (to the right is to counteract the body torque from p-forces, probably not necessary in KSP as these are not prop driven motors, and likely even the prop motors do not model air vortex correctly / at all) B: Offset the angle of the wings C: Offset the angle of the rear horizontal stabilizer D: Trim the dang thing to fly straight at a given speed/attitude and ignore the rest They all result in more drag (not sure how this is modeled in KSP), but can make your craft much friendlier to fly. Option D is kind of a joke...but also serious one. If the problem is not too bad, or too hard to fix another way, just use the trim settings (ALT + WASD) to trim it to fly level at cruising speed.

I found how to get the game to auto-calculate the drag cube for a part with non-parachute related (or really any) animations.... comment them out of the part config, and reload the PartDatabase.cfg. It will them properly calculate the parachute drag cubes and insert those values into the PartDatabase.cfg. Now the problem I'm coming across is that the method for custom-specifying a drag-cube in the part config file is not fully implemented/does not work for multiple named cubes. All three named cubes get inserted into the PartDatabase.cfg, but instead of starting with cube = DEPLOYED, etc... they start with DEPLOYED = DEPLOYED, and are not registered/loaded properly as far as the parachute module is concerned. I examined the stock pieces that have drag cube overrides in the part.cfg file, and they have the same bug/issue in the PartDatabase.cfg file; their drag cubes are started with 'Default = Default', rather than the proper 'cube = Default'. So for now, I've removed the extra animations from my part (some cabin light emissive stuff....), so that the game auto-calculates the drag cubes properly, I can use the parachute drag-cube-multiplier modules, and possibly be able to release my parts one day. I suppose I should probably report this find to the KSP Bug Tracker?