Shadowmage

Happy bday! No rush on that stuff, enjoy your birthday. Mine is fast approaching as well, could be a busy Sunday for me. Thankfully I took Mon and Tues off work.

Aye, if you felt like working out the settings for the surfaceFX modules that would be great; could save me a bit of time on the config end of things If you want we can set up a time to do some chat/IM stuff regarding the config setups. As I wrote the code to the CM ablator/heat shield module, I can probably (hopefully) help figure out what numbers to tune to get it more in-line with the stock mechanics. I know there will be some pretty large changes to the default/current values, as the CM has a much different shape and mass characteristics than the stock heatshields; it has a much higher internal mass to skin mass ratio, and a larger surface area in general. I would suggest making a default stock config and having that as the default values in the part.cfg file, and then have second set of configs for RSS/RO use through a MM patch. General development update: Sorry I've been a bit inactive; have had my head buried on code for the past few days. Trying to work out the mechanics for an in-editor PartModule swapping capability, but running afoul of KSP and C# limitations (I could do it if it was written in Java, as it allows you to mess with more things (that you probably shouldn't mess with...)). The game is setup in such a way that dynamic module swapping is very much unsupported, and there is no clean way to implement it (a couple of hacks could work, but I'de rather not go down that route). Ohwell, I have a backup plan for implementation that I know will work; it just requires custom coding any PartModules that are intended to be used by the moduleswitch mechanics (e.g. I may need to write custom Engine, RCS, SAS, and Light modules in the near future, at least if I want those usable with the moduleswitch/part variant mechanics). Currently working on coding an externally controlled generic animation module - this should make it so that I don't need to recode animation control for every animated partmodule I make, and can rely on the generic animation module for the animation code/control. Should save significant time on future plugin coding that involves animation. Will likely have this finished up tonight and work on converting some of my existing animated modules over to use it (solar panels, landing legs). As I have not made very significant progress on the plugins needed for the Lander Core series of parts (moduleswitching), I will work on cleaning up configs and bugs for the rest of the parts series (Series B and Series C) and see about getting those released (public beta) over the weekend. So, potentially Saturday for the initial releases, though I can make no promises at this point.

Aye, I intend the module to only be used on parts that I create, as I realize there would be issues where other mods' parts (or even stock) are concerned especially where they might use a custom part subclass. I'll begin by investigating the OnSave/etc game events; would much prefer to not subclass Part as it is a bit of a hacky solution, and stock itself has been moving away from it in favor of PartModules. Thanks again for the info; will let you know how things turn out.

Crazy idea, regarding the solving of the 'extra data'. At one point you could subclass 'Part', the same way that you currently do PartModules. I believe it is still used on a couple of stock parts, at work so I cannot verify through their configs. Is this still possible? I have no problem with parts that use the ModuleSwitch functionality requiring a special Part sublcass to be specified in their part.config fie; it is a fairly heavy-duty game-altering mechanic and a few caveats are likely unavoidable. If it is still possible, it seems like I should be able to hook into (read: override) the Part.OnSave() method to scrub out the extra PartModule data from the extra inserted modules. The only other alternative that I could think of would be to subscribe to the OnPartPacked gameEvent and remove the extra PartModules from the ModuleList before they were serialized; this would likely have some issues though. Alternatively, if part sublcassing is allowed/functional, I might be able to find a better way to manage the entire system. -- I suppose this will be my experiment for tonight.

Thanks for the support guys To those interested in testing: I'm working on cleaning up some module stuff before I can put out the next test release. Hopefully a day or two, and I will get you all links / instructions /etc. I'll see about sending out links to the current dev versions, but please keep in mind that there are a few known issues and that there will be many changes in the next update (save/part breaking changes). IVAs - as noted, only the Orion CM currently has a finished IVA. The lander pods have blank/unfinished/basic geometry only IVAs, and the Series-C stuff has no IVA at all at the moment. I will be finishing up the lander part IVAs once the rest of the lander parts are finished (textures/coding/configs). Series-C IVAs will likely come after the lander parts are done (don't even have basic Geo on those, so will take a bit, don't want to needlessly delay other things). On the Orion and Series-C stuff; they are mostly needing config tweaking and another balancing pass before they can be released. As the lander stuff is going to take longer than I had originally anticipated, I will see about putting together releases for the other (finished) parts series later this week/weekend. No reason to hold that stuff back as it won't be seeing too many/any changes. I guess I should get off my butt and do some config updates instead of coding all night Lander parts - have some cool ideas in the works. Currently working on coding a plugin that allows for partmodule swapping (works along-side a mesh-switch module) that will allow for some very interesting part-variant setups for the lander fuel sections (and cleans up some attach-node issues with the current setup). The next testing release is waiting for this to be finished/cleaned up, as the parts in their current-state are kind of a PITA to use and assemble (they do work, but it is not very intuitive).

Update: The sub-module method does work. I had to add the modules to the part.ModuleList otherwise GUI actions would not be available (I'm actually just feeding the config node data in through part.AddModule()). That actually simplifies things a bit because now I don't need to worry about other lifecycle events, as long as I call the initial OnLoad / OnStart that would be expected. This results in the sub modules writing their data out to the persistence file as regular modules, and then they are stored a second time as data within the master-modules persistence data (so I have easy access during the next OnLoad of the master module/manually manage their data). The part does complain about having extra module info in the persistence file upon part or vessel reload... [WRN 23:28:34.925] [Part]: PartModule ModuleReactionWheel at SSTU.LanderCore.LCTest, index 1: index exceeds module count as defined in cfg. Looking for ModuleReactionWheel in other indices... [ERR 23:28:34.925] ...no ModuleReactionWheel module found on part definition. Skipping... ...but as long as there are no duplicate modules in the base un-switched set of modules, I don't -think- it should cause any problems. I'll be doing some thorough investigation on it though before I'll be willing to call this solution 'stable'. Ideally I will find a way to trim that extra config data out of the part/vessel ConfigNode. Will check on what events I can hook into; there might be 'vessel saved' or 'about to write to disk' even that I can hook into and clean out the extra data. Thanks again for your input Diazo, put me on a totally different path than I would have originally gone down, and it does seem like it will work out to be cleaner in the end.

After a bit of setup and testing, and it is -so far- looking promising using the dummy module route. The dummies are just there to re-save/persist the data from the original module. The trick is when the OnSave code is called on the dummy module, it needs to alter the config node that is passed in to alter the name it is saved under. As you are correct, KSP references the module by a string during save/load, specifically the Type/Class name for that module. But KSP also feeds you the entire config node for the module in the OnSave() method; so you can alter the auto-written dummy module class name and replace it with the original class name and add back in any persistent data from the original module. So far, it is working about as I had intended. I just need to find the best time in the part lifecycle to do the initial swapping, and some way to re-enable the removed module/swap it back in as needed (instatiate a -new- module, feed it back the config data I had stored in the dummy, and swap it back in while removing the dummy? seems like it might work...) It should work out like this in the end: Editor - new part: Part is cloned from prefab/ProtoPart/AvailablePart (editor) At the earliest life-cycle event where -all- modules have been initialized, the ModuleSwap partmodule does its swapping, replacing original modules with dummies while grabbing the current config node data from the original. When OnSave() is called on the dummy module, it hacks in the ConfigNode data from the original module that it replaced (e.g. replacing class name, adding persistent data that was saved from original module). Part is then saved out when editor exited or vessel is launched. The persistence file for the craft will -look- exactly as it would had those original modules never been removed/swapped. Vessel is reloaded: Part is cloned from prefab/ProtoPart/AvailablePart (editor re-load, vessel launch, vessel re-load) The -original- module was cloned from the prefab, and is fed the data that was saved out from the dummy module. Since it saved out the original modules' data, there is no problem here. The original module loads properly, and it is unaware anything has happened (in theory). At the earliest lifecyle event where all modules have been initialized, the ModuleSwap partmodule does it swapping again, same as above (saving original module data for the dummy module to save out). Gameplay proceeds...tick, tock, etc. Game is saved; the craft persistence file again looks exactly as it would had those original modules been active and present the entire time. ... Will update later after a bit more testing and verification. Will also give some thought to your proposed method as it might work out to be cleaner in the end (master module, with sub-modules). I'm thinking it would require defining the to-be-removed modules as a bunch of config nodes -inside- the ModuleSwap module config (so they are not loaded/added to the part.ModuleList initially). But as KSP uses the simple config-node system to instatiate the modules in the first place, there shouldn't be too much trouble manually instantiating them (only if needed/enabled from the ModuleSwap). Still trying to fathom how that would work on the save-out though; if these sub-modules were added to the part.ModuleList proper (for updates ticks/etc), they would end up saving to the persistence file for the part/craft. I would also have to duplicate any persistence data for that sub-module inside the master module so that the master could have access to the data to recreate the module layout on craft/part reload. Hmm...worth a bit more though, and perhaps some poking and prodding (testing..) Edit: After more thought, I think I am going to try fleshing out your idea a bit more. I realized that for most purposes I probably don't need the sub-modules to be added to the part.ModuleList. I need them for the script behavior that they contain. I could route all calls to KSP-derived methods (OnSave, OnLoad, GetInfo), from the master module to the sub-modules on an as-needed / sanitized basis (e.g. only calling update/save on the enabled/loaded modules). And as they would be MonoBehaviors attached to the part (rather the parts Unity gameObject) just as any other module/script, they would automagically receive the Unity-derived method calls and lifecycle events (FixedUpdate, Update, etc). I anticipate that there might be some compatibility issues with a few modules, but I'm going to give it a try and see where things lead. Thanks for the input and ideas

Thanks for the info. I intend to have the modules on the parts in the config files / in the game database / on the prefabs. So they will exist on the ProtoPart/AvailablePart. They will only be removed from the part (replaced) after everything has loaded/initialized; this is to prevent some of the problems you point out (the initial loading issues). The biggest problem that I'm facing is how to handle the save-out of an already existing part that has had module changes. As far as I'm aware simply removing the module would run afoul of the problems you have pointed out during reloading of the vessel; as the indices would get out of synch and it would not restore the proper data to the proper module on reload. I'm really leaning towards inserting a 'dummy' module to replace the actual module instead of fully removing the module at that index. The dummy module would then act as a delegate for the config-data/ConfigNode from the original (removed) module, and re-save out that data to the config node passed in to the OnSave() method. This -should- allow the part to be reloaded from the prefab with all of the original modules (and associated config data), which would then be re-replaced by the MeshSwitch module dummies once loading had finished. I was hoping that there would be a more robust/supported way of accomplishing this; but I'm (grudgingly) willing to venture into the land of 'dirty hacks' when I have to... Anyhow... off work here in a bit, so I'll do some testing of a few things and let you know what I find out.

Hi all, I'm in the process of writing an advanced mesh-switch module that allows for swapping in/out meshes and their corresponding functionality(PartModules). This would allow, for example, a part to -optionally- have landing legs, RCS thrusters, solar panels, or whatever, dynamically added/removed/swapped as part variants. So far I have it working well with swapping out -custom- PartModules that track their own internal enabled/disabled state and make the corresponding changes (e.g. disable GUI actions and update methods when the module is disabled). It works, but the disabled modules remain in the Part.Modules list, still receive update ticks, and are still serialized into the parts persistent data (an empty update method is not much overhead, but it -is- un-needed overhead..., I don't really care about the serialization data overhead, disk space is cheap). However this method is not easily extensible as it requires writing a custom PartModule for any module that is intended to be swapped via the mesh-switching functionality, and even then it requires special coding/care to make sure everything is properly disabled. What I would like to do is dynamically add/remove the modules from the part completely at runtime. This should completely remove any functionality from the module (gui actions, action groups); the mesh/colliders are already taken care of though the basic mesh-switch code. In theory I would grab (and save) a reference to all of the mesh-switch controlled partModules; remove all of the disabled ones from the part.Modules list, and add/swap them as needed for the part variants. And then -before- the part was serialized (saved) I would have to re-add (in original config order!) all of the part-modules so it did not mess up part loading/de-serialization. At least that is how I understand the current part/module serialization process (it serializes all partModules, in listed config order, and having them not present/extra modules present will royally mess-up any reloading of that part, as it will feed the wrong data to any out-of-place modules). Is anyone aware of how to properly add/remove modules at runtime while handling the serialization problems issues? Is there a callback/event for a part during the loading process -after- the part has had the modules instantiated, but -before- they have been fed the loading data? Is there a similar callback -before- a vessel/part has begun its saving process? At work for the moment, or I would probably just dive in and skip the asking of questions; however I'm hoping someone has some experience with these issues they are willing to share. Thanks in advance, Shadowmage Edit: Further questions would be - How does the part.ModuleList handle null values? Can I remove (null) a module by index after it is initialized without messing up the OnSave()/serialization code? Alternatively, could I insert a dummy module into the original (disabled) module index, feeding it the original modules config data (by calling OnSave() on the original/disabled module manually and storing the config node in the dummy module), and allow the dummy-module to write out the original modules data in its OnSave method (thus preventing any deserialization issues due to mismatching module indices and/or data). Hmm..going to have to try that out later, as that is probably the most likely-to-work solution I've come across/thought through.

Yah, I somehow forgot to remove that testing part from the first dev release. It was made to help test the multi-landing-leg module initial development, and will be removed from any future releases.

Shadow Space Technologies Unlimited - Labs Division This is the public discussion thread for ongoing development of SSTU parts and plugin code. Downloads: The latest versions may be found at: http://www.curse.com/ksp-mods/kerbal/241283-sstu-shadow-space-technologies-unlimited And are also available on Github: https://github.com/shadowmage45/SSTULabs/releases (Github will always be more up-to-date than curse, as they are auto-published there; I have to manually update Curse; so please check the GitHub link if you are looking for the latest versions) Please keep in mind that these are all testing releases. Things may break between releases. There will be bugs. Many things are unfinished and/or unoptimized. The test versions are for ironing out bugs in new features and for testing out prototype parts before they are finished; as such they will always have bugs, often severe, and there will often be unfinished parts (no textures, missing features, etc). Please only use these versions if you wish to contribute to testing and are comfortable with the state of the releases. Wiki (WIP): https://github.com/shadowmage45/SSTULabs/wiki Contribution: IVA Modeling: SSTU could greatly use someone with interest and experience in modeling IVAs. If you think you are that person, please contact Shadowmage through PM to work out the details. Testing: If you would like to contribute to pre-release testing (and get to try things out in their pre-release state), please follow the link above; the most recent test version will be at the top. Please submit issue reports for any problems you encounter via the GitHub issues tracker: https://github.com/shadowmage45/SSTULabs/issues (If you do not report the issue there, it will not be resolved; issues posted in the thread or through PMs will be forgotten about and likely never fixed; so please, do the organized thing and use the bug-tracker). Configs/Patches: I welcome pull requests and contributions for adding patches for mod compatibility, adding new part configs, or fixing issues in existing part configs. Documentation: One very major part of the mod that could greatly benefit from public contributions is the Wiki: https://github.com/shadowmage45/SSTULabs/wiki While this is the 'dev version' wiki, I will be using it to form the basis of the public release wiki; so any/all information and details that can be filled in now will be transferred over to the public release repository and wiki when it is created. Feedback, suggestions, comments, etc: Please feel free to post feedback, suggestions, questions, etc regarding development releases and/or any posted previews. Even if you are not on the testing team, I still value your feedback and suggestions. Please use the issue tracker for any 'official' feature requests; it may be found at: https://github.com/shadowmage45/SSTULabs/issues Bug Reports: Please submit issue reports for any problems you encounter via the GitHub issues tracker: https://github.com/shadowmage45/SSTULabs/issues. No other method for submitting bugs will be supported; posts on the forum or through PM will be forgotten about before I can ever get to them. Opening up a ticket ensures that your report does not get lost in the forum or forgotten about. No ticket = no fix. Enough with the disclaimers, and onto the parts! The Parts: The goal of SSTU is to provide low-part count, CPU-efficient parts for common uses. To this end many of the parts are designed with additional integrated functionality beyond the base functions, for instance integrating RCS ports and engine(s) into a fully fledged service module. I have tried to maintain a stock-compatible appearance, though as I am not an artist or modeler (at least not by training/profession), how well this has worked out is subject to opinion. Master list of parts; current, planned, the whole lot: https://github.com/shadowmage45/SSTULabs/wiki/Parts---Master-List Ship Core: Engines A set of engines in many varieties, including pre-built engine clusters. Many more engines, mounting options, and cluster designs will be added over time. Ship Core: Series A A set of parts modeled after the Soyuz CSM stack. Includes Orbital Module, Descent Module, Service Module, and LAS. Ship Core: Series B A set of parts modeled after the Apollo CSM stack. Includes two command modules (one with integrated heatshield and parachutes), launch abort system, and Apollo-inspired service module. Ship Core: Series C A series of parts heavily inspired by and based on current NASA - SLS project. Includes representations of SLS upper stack initial configuration, and lifter parts designed in the vein of the lower/core portions. The upper stack is designed to allow for a low-part-count manned orbiter setup, while the lower-stack parts are intended for super-heavy-lift capabilities. Command module and upper-stack are 3.75m, while the lower-stack lifter parts are 5m. Ship Core: General A line of generic / utility parts. Fairings, RCS, Science experiments, and procedural decouplers of various types. Includes a full line of configurable/dynamic fuel tank parts in standard cylinder, sphere, R-7 booster (integrated decoupler), and upper-stage (integrated rcs) form factors. Includes a full set of truss based cargo bay modules. Also includes a full line of interstage fairings and petal adapters, and standard payload fairings. (Many parts not shown in album) Lander Core A series of parts specially crafted to enable low-part-count non-atmospheric lander designs for use in the stock Kerbol system. Station Core A line parts for low-part-count station use. Includes inflatable Bigelow-inspired inflatable modules, inflatable centrifuge modules, ISS inspired habitat and lab modules, and a line of TKS/DOS inspired single-part station cores (integrated solar, engines, rcs, docking ports, sas). Also includes a full line of stand-alone solar panels and a 'welding' docking port. (Album not yet available) Craft Files None currently available, will possibly start becoming available when the mod has reached a stable state (not for the foreseeable future). Additional Addon Compatibility and Integration RealPlume -- Optional but highly recommended. SSTU includes a set of patches for RealPlume for all engines as well as most other engine-enabled parts. More will be added over time. Stock effects are also included, but options and configuration for those are much more limited. If you want pretty-looking exhaust effects, get RealPlume. MechJeb -- If MechJeb2 is installed, Command Pods (and some service modules) include a built-in MJ module. The tech-unlocks for these are based on the default MJ tech-settings. Kerbal Joint Reinforcement -- As of KSP 1.2+, KRJ is no longer necessary, as the stock Auto-Struts can eliminate most of the wobbles. Might still have utility on extremely large craft designs, but should no longer be nearly-mandatory. USI-LS -- Patches for most parts are included, and will be enabled when the requisite mods are installed. These patches add a few days worth of life-support to each of the pods and some of the service modules. (WIP, needs updating) TAC-LS -- Some patches are included. Not up to date, and not all parts are patched. ConnectedLivingSpace - A simple CLS patch is included to add CLS passability to all SSTU crewed parts. FAR - Unsupported. You are on your own if you choose to use FAR. Any problems involving FAR needs to be brought up in the FAR thread. RO/RSS - Unsupported. Take any support requests regarding RO to the RO threads. KR&D - Known to be incompatible. Some config edits can be made to allow them to work in the same install, but KR&D cannot adjust stats on most SSTU parts. Introductory video by MrMeeb Known Issues IVAs - Many are incomplete. WIP. They'll be finished 'eventually'. Textures - Many unfinished textures. Please see the Github issues tracker for a complete list of known issues: https://github.com/shadowmage45/SSTULabs/issues Future Timeline / Future Plans Please see the Github Milestones and Issues Tracker to see future/current development plans. Milestones (long-term plans): https://github.com/shadowmage45/SSTULabs/milestones Issues Tracker (current in-dev stuff): https://github.com/shadowmage45/SSTULabs/issues Legal: Source: All source code and compiled plugin binaries for this addon are distributed under the GNU General Public License (GPL) 3.0, except where noted below, where that code is distributed under its own license. The text of this license may be found at: https://github.com/shadowmage45/SSTULabs/blob/master/LICENSE-SOURCE.txt EXCEPTIONS: None at this time Source code for plugins is included in all releases packs (source may also be found for the most current version at: https://github.com/shadowmage45/SSTULabs/tree/master/Source). Models/Art/Configs All Assets and Artwork in this addon are licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License, except those areas noted below, which are distributed under their own licenses. The text of this license may be found at https://github.com/shadowmage45/SSTULabs/blob/master/LICENSE-ASSETS.txt EXCEPTIONS: None at this time ModuleManager Module Manager is distributed under its own license (CC-SA). Source code and licensing details may be found at: https://github.com/sarbian/ModuleManager Community Resource Pack Community Resource Pack is distributed under its own license (CC-BY-NC-SA). Source code and licensing details may be found at: https://github.com/BobPalmer/CommunityResourcePack Mini-AVC This mod includes version checking using MiniAVC. If you opt-in, it will use the internet to check whether there is a new version available. Data is only read from the internet and no personal information is sent. For a more comprehensive version checking experience, please download the KSP-AVC Plugin KSPWheel KSPWheel is a dependency for the SC-E (shuttle) landing gear, and is distributed under its own license (GPL 3.0+ https://github.com/shadowmage45/KSPWheel/blob/master/License-GPL3.txt). It may be found at: https://github.com/shadowmage45/KSPWheel TexturesUnlimited Textures Unlimited is distributed under its own license (GPL3). Source code and licensing details may be found at: https://github.com/shadowmage45/TexturesUnlimited Forum Page: https://forum.kerbalspaceprogram.com/index.php?/topic/167450-18x-textures-unlimited-pbr-shader-texture-set-and-model-loading-api/ The Team: Development: Shadowmage - Modeling, animation, texturing, plugin code, concept development, and most configs (balance). And a special thanks go out to all others who are making this add-on possible: JoseEduardo - Co-Conspirator, Testing and feedback, RO and RF Integration, Craft files, additional texture sets blowfish - Testing, feedback, and concept development MrMeeb - Intro video, testing and feedback. StratoChief - RO and RF Integration VenomousRequiem - Concept development and feedback. MeCripp - Testing and feedback _Augustus_ - Testing and feedback drtedastro - Testing and feedback riocrokite - Testing and feedback, concept development for part reduction falken - Testing and feedback martinezfg11 - LC-POD IVAs Jimbodiah - Craft repository and testing -if I missed you on this list, sorry! (feel free to send me a PM if you think you deserve a mention in the credits) Donations: I work on this mod during my spare time, and use vast amounts of caffeine in the process. If you would like to help contribute to my coffee fund, please see the link below. This is purely optional, but can help keep me motivated and energized ( = more work getting done!).

125m/s = 450kph = 279.61695mph (unless my math is way off...) I'm not sure you can realistically go much faster on water without rapid disintegration problems (and probably not even that fast? ... not really a boat guy.) Okay, so a quick wikipedia search turned up some speed records for water-surface travel: 317.596 mph (511.121 km/h) by Ken Warby on 8 October 1978 (https://en.wikipedia.org/wiki/Water_speed_record) (and there is an 80% fatality rate associated with water-speed record attempts... rapid disintegration at those speeds is very real). Not many people are aware of just how fast 30m/s really is, let alone 125m/s .... -- Sorry, but no, I do not know of a way to change the speed cap, just adding some information for reference and perspective.

I had similar pitch-over stability problems when I was designing my Orion-inspired parts. Would get to 8-12k altitude and 200-350 m/s, the top end would start to wobble/noodle a bit, get caught in the airstream, and rapidly flip or disassemble the rest of the rocket. IIRC I solved them by reducing the drag created by all of the 'extra' parts - LAS/BPC, and all of the adapters - I figured it was an acceptable work-around as the stock drag mechanics did not properly account for the shielding those parts -should- have provided anyway. I left the drag on the CM, SM, and ICPS at stock values, only the adapters and stuff had drag reduced. To the LAS/BPC I added (any lower and it would overheat and explode during ascent....): [TABLE="class: highlight tab-size js-file-line-container"] [TR] [TD="class: blob-code blob-code-inner js-file-line"]MODULE[/TD] [/TR] [TR] [TD="class: blob-code blob-code-inner js-file-line"]{[/TD] [/TR] [TR] [TD="class: blob-code blob-code-inner js-file-line"] name = ModuleDragModifier[/TD] [/TR] [TR] [TD="class: blob-code blob-code-inner js-file-line"] dragCubeName = Default[/TD] [/TR] [TR] [TD="class: blob-code blob-code-inner js-file-line"] dragModifier = 0.5[/TD] [/TR] [TR] [TD="class: blob-code blob-code-inner js-file-line"]}[/TD] [/TR] [/TABLE] and all of the structural adapters got: [TABLE="class: highlight tab-size js-file-line-container"] [TR] [TD="class: blob-code blob-code-inner js-file-line"]MODULE[/TD] [/TR] [TR] [TD="class: blob-code blob-code-inner js-file-line"]{[/TD] [/TR] [TR] [TD="class: blob-code blob-code-inner js-file-line"] name = ModuleDragModifier[/TD] [/TR] [TR] [TD="class: blob-code blob-code-inner js-file-line"] dragCubeName = Default[/TD] [/TR] [TR] [TD="class: blob-code blob-code-inner js-file-line"] dragModifier = 0.1[/TD] [/TR] [TR] [TD="class: blob-code blob-code-inner js-file-line"]}[/TD] [/TR] [/TABLE] Seemed to solve the initial problem for me. It is still on the edge of instability (and requires staying within a certain flight envelope), but quite usable, and at this point I think it is more mass related than drag. Hope that info is of use, though no guarantees on anything. Edit: Wow..not sure what is up with that formatting... Futher Edit: FYI - I don't think that the maxDrag/minDrag/angularDrag config values are used anymore; it is all done through drag-cubes as far as I can tell.

Not sure what you are referring to on the engine stuff? My Orion inspired design is based from a ton of different resources, but not necessarily any particular reference drawing, or from any particular time. Many features were averaged from the various sources; others were adapted to stuff that would suit KSP better, or completely altered just to make it be able to at all work in KSP. AO bakes = Ambient Occlusion, a way to add basic shading through a pre-rendered texture. Can add a lot of depth and detail to a model without too much effort as long as everything is setup properly for it. Will probably have more complete previews of all of the lander parts soon, most stuff is down to just texturing left. I've gone with smaller fixed solar panels on the 2m and 3m lander pods; still undecided on the 5m pod, it may get deployable panels. Would be nice to allow electricity on a deployable panel while undeployed, but is a bit more complicated than I want to tackle at the moment. I'll give it some thought, but pretty sure it would at least require some pretty hefty plugin code changes to make it work. Perhaps -after- I've finished the parts I can look into it. I'm pretty sure I need to rebalance the heat on the ICPS. I'm pretty sure I had originally based it on the 'full' tank weight, so as you drain the tank it produces far too much heat. Could likely also use a conductivity decrease to limit the heat spread, and an emissive/radiative/convective increase to help it disippate heat a bit better. SM Engine nozzles - nothing I can do about those at the moment, it is a stock limitation of having multiple engine modules on the same part, and a further stock limitation on the staging system (a part can only have a single staging icon). You can add in an engine-switch module (used by the stock Rapier engine), but then you can only toggle between one engine or the other and lose the ability to use both at the same time. CM Re-entry angle - you can try tweaking the COP / COL offsets that are in the config; lower the value closer to zero and it should reduce the re-entry stability enough that you can re-enter at a different angle. The current values are probably a bit too much as they make it very hard to change capsule angle at all as you point out. RCS Ports - yes, I added extra ports to help with RCS balance as it is represented in KSP. I believe the positions and angles that I have used are also off a bit from the real thing, but were needed to make it usable with stock KSP RCS mechanics (lack of proportional thruster control, and individual thruster control). I hear you on the out-of-date info bit - the more stuff you read on Orion, the more conflicting information you have about it. About the only thing I've seem remain semi consistent was the overall size and shape of the CM. The SM has had at least 3 major revisions that I've seen. And the configuration of the upper stages seems to change daily, or at least is different in nearly every resource I've run across. SM Solar panel angle - would be nice from a realism perspective, but unecessary for my KSP gameplay. I might look into it if I'm bored some day -however it would require a bit of plugin code changing/additions, as well as adding more buttons and controls onto the SM right-click panel (which I was trying to avoid).

Google-fu led me to:http://forum.kerbalspaceprogram.com/threads/28214-wheel-problem where someone stated that wheel colliders are disabled by default. Okay, so.. apparently... wheel colliders are -disabled by default- in KSP. A big ... there (why disable something that you had to intentionally put on a part/model to begin with?). As soon as I hooked it up to a simple module that just called wheelCollider.enabled=true in the OnStart() method, the wheel collider started colliding properly. Hooray...now I can start working on things in earnest - testing suspension animation code, playing with spring/damper values/etc. That was a fun two days.... So... future note to anyone with wierd wheel-collider problems -- they have to be manually enabled through plugin code in order to function (as well as be set up properly).

Hi all, How are wheel colliders supposed to behave when -not- updated by any Modules? As far as I can tell the default Unity behavior for them is supposed to be to act like a collider -and- manage the suspension/etc internally. The docs/examples do not use any additional colliders for the wheels and rely on the wheel collider for collision detection and keeping the main body object off/out of the ground. It -looks- like they are supposed to be a plug and play affair. Edit: Testing in the unity editor, this is indeed the case. Create a rigidbody, add some wheel colliders to empties setup around the geometry appropriately, create a plane/surface for it to collide into. Elevate your rigidbody a bit above the plane to start, and hit the 'play' button. The rigidbody will fall down and rest -on the wheel colliders-. Now, what I'm seeing in KSP is that wheel colliders just fall completely through the terrain? I am asking because I'm working on writing a custom multi-suspension point landing leg module, but cannot get the wheel colliders to... well.. collide with anything. Rather, I can see the wheel collider has positioned itself just above the terrain, but the ship/part is being held up by the other box colliders in the model... if I remove those box colliders, the entire thing falls through the ground. Are wheel colliders supposed to actually collide with terrain/objects and stop falling movement, or am I supposed to be using other colliders for this purpose and manually lining them up with the wheel collider bounds? (seems counterproductive, and might as well write my own wheel collider at that point) I suppose the actual question is; how do I get wheel colliders to actually -collide- with things and use their suspension values to properly push back/push up on the parent object? Screenshots to show the problem: Unity setup: Unity behavior (comes to rest on the wheel colliders): KSP Start: KSP behavior (wheel colliders fall through the ground):

The main reason I have it hollow is so that other (ascent stage) engines can have their thrust-vectors/exhaust go through the hollow cutout - if I use a single solid collider, the thrust from upper-stage engines will hit that collider and result in...well... probably explosions after not too long The hollow also needs to be...well, actually hollow, as other parts need to be able to pass through the area without collision. Oh..what I wouldn't give for a game engine that could handle concave colliders properly with good performance. Sadly, I've written my share of collision-detection code, and I know from experience that it is a -very- difficult problem to solve and still have enough performance to work in a game. I'm still working on trying to find the root cause of the problem... will be trying various different engine modules from other mods as I'm fairly certain that the issue is somewhere in the stock ModuleEngine code (I just don't have access to that source to say for certain, or even offer a solution). In the end I will likely just use some of the aforementioned work-arounds or writing a custom engine module (-really- don't want to...but might have to).

Publicly available repository for SSTUTools.dll source (and original versions of the parts released in this pack) is available at: https://github.com//shadowmage45/SSTUProductions . All source code is licensed and released under GPL 2.0, but I have granted _Augustus_ permission to redistribute through his pack under CC-BY-NC-SA 4.0 for simplicity sake. If you dont' mind editing this info into the OP, that would be great (I don't think _Augustus_ will be back for a couple of weeks at least.) Thanks, Shadowmage

Question regarding the upcoming lander parts. 1.) Any want/need for a 'Service Module'? It would be intended for use on the descent stage (or re-usable lander), and would include larger folding solar panels, all science experiments that are currently unlocked in the tech tree, and KAS/KIS storage for inclusion of a small payload (on-lander rover delivery, such as the later Apollo LM missions). Would likely also include a secondary set of RCS ports in the SM for help in balancing the RCS while the descent stage is attached. This is something that could be added later, does not necessarily have to be created/included immediately. I'm thinking this would be a 1/2m tall section, positioned directly below the CM/pod, with one SM for each LC-pod size (2.4, 3.65, 4.9m), and include the hollow cutout center section to still allow for use of an ascent stage/embedded ascent engines. If there is any interest I'll see about putting together a mockup and check on the functionality. Preview Images:

Sorry, I thought _Augustus_ had linked that all up with his repository. I'll get a public facing repository set up this morning with the source, link will follow shortly (dev repo is private, as people had a tendency to try and use unfinished stuff straight from the repo and then complain when it didn't work properly=\). Thanks for the warning/heads up.

(_Augustus_ is on vacation for awhile, so I am tending to the thread in his absence) As a developer who has recently started contributing to this project, this concerns me greatly. What 'code' are you referring to? I was aware that _Augustus_ started off with some potentially questionable choices regarding model/part acquisition, but it looked like he had cleaned things up and had everything in order license-wise. And the only code that -I- have contributed was written 100% by me (SSTUSolarPanel part module), so I know that you cannot be referring to that. Looking through the distribution, the -only- code that is included (plugin), is the SSTUTools.dll (authored by me, and most certainly not 'borrowed'). So, I truly am curious as to -what- code you are referring to? I take copyright concerns very seriously (even though I disagree with/hate the entire system). So, if you could provide more information as to what code was being used without permission/license I will look into getting it removed from the distributions. Please keep in mind though that most open-source licenses explicitly allow for copying and use of code without permission (that is the entire reason for the license). In fact, with most open source licensing you cannot stop people from using the code even if you wanted to. I'm not sure if this applies in this situation, would need more information regarding the issue.

Yes, most lights (in stock) are animation based. You can only have one of each type of light welded (might be just 1 light total if they happen to use the same animation name).

If I just spawn the engine it will intersect immediately (and stick with multiple colliders in use). If I use launch clamps and fire the clamps+engine at the same time it will take off like the rocket that it is. If I use launch clamps and let it fall to the ground before firing the engine, it still sticks. Or if I land it on the engine after taking off using launch clamps or wiggling, it will stick. Landing legs exhibit the same symptoms; stick to the ground with legs retracted, and take off just fine with legs deployed. The previous parts that have had this problem had landing legs involved, and if I remember correctly adding in the landing leg module and wheel collider 'fixed' the sticking issues. One of those parts only had a single engine transform, while the other part had four animated engine transforms. But the one thing that they all had in common was multiple parallel and flat non-animated colliders all in contact with the terrain at the same time. I'll try playing around with the multiple collider setup and see if perhaps rotating or staggering the y-transform a bit will help with the stickiness. I've also examined every other engine cluster that I had in my fairly modded install, and it seems that every single one uses a single collider for terrain collisions (including stock). A few seem to use non-convex mesh colliders for additional mouse-over interaction on each engine, but appear to use a single collider further up for terrain interaction (e.g. on those the engine bells will fall through the ground). So, perhaps this is a 'known' issue. I really wanted to be able use a couple/few individual colliders for these pieces, as you are intended to be able to utilize the hollow portion in the middle for additional (smaller) engine clusters or inner stage access. I could perhaps go with the multiple colliders and just put a note in the part description that says to always use landing legs and not land directly on the engines

Hi all, I have a problem with parts sticking to the ground, launchpad, runway or any terrain whenever they are spawned or landed (not -just- on initial spawn/launch, but also if landed manually). The current part exhibiting the issue is an engine cluster for a series of lander parts I'm working on. When I have a separate collider (box, capsule, or cone-shaped-convex-mesh) for each separate engine the entire part sticks to the ground when launched. If I have a single box collider covering the entire bounds of the engines there is no problem and the part lifts off as it should. During the times when it is 'stuck' I can often use the SAS or RCS to wiggle the vessel a bit and get it unstuck, where it willy promptly shoot into the air as it should given the TWR of the vessel. I've had a similar problem in the past with other parts and usually ended up abandoning the part (or vastly reworking it) as I could never figure it out, but that is not really an option this time. I've tried various size and shape/type of colliders, but the only thing that seems to work is either removing the colliders entirely or giving it a single collider for the entire part. Has anyone else seen this issue? Any known solutions (other than single colliders/no colliders)? Edit/Update: It has something to do with multiple colliders on an engine that is resting on the ground. If I add other engines to the vessel, they can lift the problematic engine cluster off the ground just fine (i.e. smooth ascent, no sticking or jerking loose). If I use a single collider the problematic engine can lift itself with no problem. Unity setup:

Just setup 1.04 for some testing / verification of dev version stuff. So far, everything is looking good. Parts seem to function properly still, no random explosions. Tried a direct-from-Mun return/re-entry with the Orion CM (no ablator/heat-shield) @ 30k Kerbin periapsis. Hit atmo at around 3200 m/s, as normal for a Mun return. Things got a bit hotter than they used to, but still nothing to worry about. Used to hit ~400k on the CM, now peaks at about 615k for the same re-entry vector. So, they definitely cranked up the re-entry heating, but still not enough that you actually need a heat-shield (ablator module) on the CM, at least on normal heating levels. I would imagine that with some minor vector tweaking / shallower angle, the heat could be minimized even further, allowing direct-from-Minmus (3400 m/s) returns without any concern for overheating. On higher heat levels, the heat-shielding -might- be a good idea. If I can get the math for the ablator module worked out, should be able to add it in officially with the next release/update for those parts.