Shadowmage

In theory, it shouldn't matter where the science data comes from -- as long as the lab reports that it has science data to process, it should generate science points from it. (of course, those are the stock mechanics, using stock modules, your mods might alter any/all of that...). I just tested in a stock install, and the lab on the DOS-LAB works fine as far as stock mechanics and modules goes. I can run an experiment, add the data to the lab for processing, click the 'Start Research' button, and it generates science points. In the screenshot above, you can see where it lists 'Data 1/750', and 'Rate 0.0243/day' -- those are the important stats that state that the part is working properly. Could you please provide a screenshot of the LAB's right-click menu (such as the one above), showing its data/science values/other stats?

Did you load the lab with science reports first? (sorry, gotta check the obvious...) I'll do some quick testing this evening to see if the stock-science lab portion of those parts works in my dev setup; that will at least let us know if it is a part config problem, or a mod conflict/config problem.

What is a 'research-kit'? Certainly it is not stock.... ? (which is why I think this is all related to the mods you are using)

@vossiewulf Sounds like your problems are with whatever 'science moving' mod you are using. Or rather, if the DOS-LAB part functions poperly by itself (e.g. generates science, stores science, can transmit), then whatever the problem is must be with your 'science moving mod'. I don't do anything special with science modules -- the part uses the stock science lab and storage container modules. Thus, there is nothing in SSTU code that could be causing those types of problems. Now, if the LAB part doesn't work properly for the stock science-lab functions -- then that might be something I can fix up, as it is likely a configuration error (because, again, I don't do anything with plugin code regarding science modules or functions). In order for me to diagnose what is going on with that other mod I'll need to know what it is called. There is a very high probability that they have 'hard coded' support for special parts and/or mods, and SSTU simply isn't on their special handling list. What is the name of the mod, and do you have forum and/or github links for it?

All parts in the mods' default configuration are for Stock solar system (scales, thrusts, TWR). RO used to include a set of patches to adjust the engines for their real-world performance stats, but as I am not involved in RO/etc, I have no idea how up to date or maintained it is. To answer your question -- yes you will want to find/make some patches to adjust the engines for decent performance in an RSS setup.

Yep; the core tank should be 1.4375m -- with the Soyuz style nose adapter present, that should bring the upper diameter of the core to 1.875m. The nose option should be available for the MFT-A tank, but it might be listed in the UPPER options rather than NOSE.... (if it is not available.... then something went sideways with the recent releases, as I explicitly added it for the last update) Not removed to my knowledge.... it was a stock feature though.... so who knows what may be going on with it. Were there any config changes to the parts that you are having issues with in any of the recent SSTU releases?

That 'problem' has existed since before I even took over development on KF. A bit of history: Stock models (.mu files) store their texture references in the model file. The particular models in question have references to some textures that no longer exist (if they ever existed). The meshes in question receive their texture through plugin code, which is why there are no 'untextured' parts. The 'solution' would be to recompile the model with empty materials for those meshes. Now, I don't have the original modeling files for many of these parts, so I cannot recompile the models (without jumping through hours of work to import them into Blender, fix up the import errors, re-export to .fbx, and finally re-import into Unity). (Alternatively, one could 'edit' the .mu file to remove the reference.... but the .mu's are binary encoded and it is non-trivial to decode the files and rewrite them) As the 'problem' has zero actual effect on gameplay, or really anything aside from those few lines in the log file, I have opted to not spend those many hours of time. One of those 'effort vs productivity' trade-offs....

None; that is the new stock MK-whatever pod (3-kerbal, 2.5m) that was released with the Making History expansion. I believe it is part of the base game though, so everyone should have it.

Thanks for the confirmation and info. I've opened an issue ticket on it, and will investigate a fix for the next release (hopefully this weekend, or next, depending on if some of the craziness at work clears up). https://github.com/shadowmage45/SSTULabs/issues/729

@vossiewulf You may need to enable the 'angle snap' on the ports. IIRC there may be an issue where they refuse to dock unless it is enabled. (if that is the case, please let me know and/or open an issue ticket so that I can remember to get it cleaned up)

Taken down due to a polite request from Nertea asking as much. ^^^ is the reason I will not release any configs myself. As I don't use stock parts, they would all be for mods; most of those mods being the NF suite. So its kind of non-starter, as I respect Nertea's wishes regarding his works (and those of other mod authors who have expressed similar).

By default, this mod does nothing. It is an API that -others- can make use of. So, no; I will not be updating CKAN with any configs (because there are none there currently).... Any configs that you currently have/use are provided by a third party. I can do nothing about how complete/incomplete they are. Your best bet would be find the author of your configs, and ask -them- to finish them.

Nothing that I can do regarding incompatibilities in other people's mods. I.E. - any fix will have to come from the other mods' side. I already implement all of the stock interfaces that are available; but everyone feels that it is appropriate to hard-code for specific classes rather than find some generic implementation. Thus, as my classes are not the ones they have hard-coded for, there is no compatibility. (The root cause is that the stock API does not have a sufficient attribute/tagging system for PartModules; there is no way to say 'this part-module generates EC' or 'this part-module is an engine')

Yes, though with an older version that may lack some features. I believe this version should be compatible with 1.3.1 -- https://github.com/shadowmage45/TexturesUnlimited/releases/tag/1.0.0.8

No worries; glad you got it figured out. If you know the source of those folders (rather, the patches therein), and could link to their forum posts, I can check out what is going on with the patches and perhaps help the authors get them sorted out.