InsaneDruid

Yeah, the old (1.16) version was wonky in this regard, as romanasul pointed out. If you hop over to GitHub and look at the history of the relevant file https://github.com/InsaneDruid/Proton-M/blob/1f7cfabfff0371bbf201a15c36a91cbad0f6c128/GameData/HGA/Proton/mm_config/realism_overhaul/ro_proton_lv_fairings.cfg you can grab the "RSS Fairing Fix" compatible with the 1.16 of this mod. This should help.

@CobaltWolf: Pics are linked in the starting post, as currently there is no way to implent an album directly into a post. @DarthVader: Version 1.2 of the mod? There are some changes included into the fairings - see above, since 5. October on GitHub, since, 1.2 in the main release. May I ask which side (A/B) hangs, and if this is so on all the Fairings, 4Meter, 5Meter, small and extended... @GERULA: Thanks! AS for flying her: Indeed there is no magic flywheel present in the launcher or upper stage only the gimballed engines and RCS for the briz, so she is trickier than others as you can't really hold her pointing away from prograde. But if you fly up for some moments to built up speed, then SLOOWWly turn over, throttle down a bit during first stage burn when the air is still dense time and keep her in the prograde-circle on the navbar the whole time, then it should be no problem. Use a rather steep trajectory during the first stage, stabilize before staging, hot stage (let the next stage ignite before staging (second one fully, third one only the RD0214). The third stage might even dip below the horizon while accelerating. Also note: to fly with the "hard" fairings (not the procedural ones) you NEED

You can use Armatures and Bones. Uses a bit more CPU to do the animation but saves the GPU usage when doing tons of small objects. My Proton Launch Pad for example is just one Mesh for the whole inner part with all the moving parts.

Is there a root folder entry in the cfg? Try removing it and enter the full path (out of gamedata) of each texture Like this here:

If it is a texture without transparency or without a specular map in the alpha channel (like your one) it should be saved as with DXT1 compression. Anything with transparency/stuff in the alpha should be DXT5. Normal Maps should be saved as DXT5n ideally. In the end, you also can save your stuff as TGA, or BMP or PNG and let this little converter do the rest automatically. PS: I think gimp default is S3TC compression, judging from the images in the web. I don't use gimp, so cant tell.

Besides that the image isn't completely green (you missed some parts here and there while painting - witch could indicate a calibrated monitor), it's saved in a dds format that KSP can't recognize. Compressonator also cant tell the format it is in. Surely not DXT 1, 3 or 5. Maybe BC1?

New Update is out. I could not resist and include the newly updated proposals for the Proton Medium, Light and M+ Versions. New Proton Medium Stage 1. New Proton Light Stage 1. New Proton Light/Medium Stage 2. Changed UV layout for all stage1 configurations accordingly. Added 5 meter fairings for proposed Proton M+ launch vehicle. Breeze-M Glonass antenna is now usable for KerbNet access. Breeze-M Tracking antenna is now usable for CommNet access. Breeze-M Telemetry antenna now adds SAS support. KerbalGPS is removed from Glonass antenna, as the mod is dead, incompatible with 1.2 and in parts replaced by KerbNet. Stage 3 and Stage 2 of Proton light/medium now have internal CommNet access. Adjusted fairing decoupler and separation motors for RSS. Added RD253->RD275->RD275M updates that can be unlocked in R&D building. Added small dark stripe between second (light/medium first) and third (light/medium second) stages, solving minor artefacting, while also improving realism. Improved mesh geometry dimensional accuracy and symmetry. Fixed transparency issues on Fairing Parts in VAB. Made inner side of fairings opaque again. Fixed spoiler toggle animation that wasn’t working. Prevented toggling of spoiler in mid-flight or on the pad. Removed TRReflection module from inside of fairings.

You will run into some nasty shading issues around that windows on the capsule and the cutouts on the front shield. I suggest you want to read these threads:

I can't really understand your question, as I don't know what you mean with "cards". Your normal map seem ok-ish on that image. The alpha channel of the diffuse texture is usually interpreted as a specular map. not a height map. But this only is needed in ksp_specular or ksp_bumped_specular. For ksp_bumped your diffuse texture should be 24bit, without an alpha channels.

They didn't even really ask. They just asked for an email address via twitter from a personal twitter account, while the roscosmos website states available telephone and fax contacts. (and a snailmail adress). A simple fax with a correct and formal header indicating that the question comes from a sciency game developer might have brought the answer.

With 1.2 part stats upgrades that can be unlocked in the R&D facility have been implemented: "PartModules now support upgrades. In a MODULE node, add an UPGRADE node. Inside that add one node per techID you wish to provide upgrades, in ascending order. Inside that place keys and nodes you wish to upgrade. e.g. `UPGRADES { basicRocketry { maxThrust = 250 } }` will change maxThrust to 250 once basicRocketry unlocks. Upgrades will never override persistent data. Further, by default they overwrite each other; to make a node apply on a clean slate (so you can, say, add two PROPELLANT nodes and not have them conflict due to the overwrite logic) set `IsExclusiveUpgrade__ = True` in the upgrade's node. That will clear the upgrade state and apply that upgrade fresh. Upgrades are applied only when you add a part to a craft in the VAB/SPH, they don't magically apply in flight. When a part on a craft is upgraded, a new option will appear in the PAW (when in VAB/SPH) where you can view the current stats of all those modules with upgrades." While this is nice and enables the implementation of performance upgrades for older parts when unlocking a new R&D-"node", the usability of this system is thwarted by the inability to activate them in sandbox mode. For example: if you model an rocket engine that existed over many decades and was constantly upgraded, you can do this for career & science mode, but you are stuck with the basic version of that part in sandbox mode, even as the sandbox mode should provide you with every possible part to play around with. So my suggestion is: we NEED a way to activate and deactivate existing part upgrades in sandbox mode in the VAB, giving us the ability to switch between the available states of upgrades for a part. This would also make developing and testing such upgrades easier and, if also available in career mode would give players the option to to NOT use an already unlocked upgrade, for example for cheaply launching a smaller payload where you don't need the upgraded parts.

@romanasul: try the version from GitHub (see first post in this thread). I have updated the settings for the decoupler and the separation motors for the RO fairings. Should work better now, decouples even on a ascending rocket, though not near maxQ, obviously^^. The GitHub Version is the dev version for ksp 1.2, but it works in 1.1.x, too. A release on ckan and spacedock will follow if 1.2 goes fully live.

I'll investigate on this.

If you want to scale a model within the cfg, you would not want to use reScaleFactor in any way. You just use scale within the model node like: MODEL { model = HGA/Proton/parts/proton_launchpad scale = 0.60976,0.60976,0.60976 } rescaleFactor = 1.0 scale = 1.0 works perfectly. Combine this with proper attachment node definitions using using the node-tag and a empty transform like NODE { name = top transform = launchpad_nodetop size = 3 method = FIXED_JOINT } instead of wiggling around with written out coordinates and you set yourself up a perfect re-scalability without any hassling while having perfect nodes without any rounding issues. Also, use metrics in blender, then a meter in blender is a meter in ksp no matter what, no need to wrestle around with arbitrary "unit" measures. I use this to model anything in a real 1:1 original scale and then down-scaling it within the model node of the cfg file for stock (0.60976 scale) or realism overhaul (1.0 scale)

Tried to re-install it on my testbed, ckan downloaded it fine from http://spacedock.info/mod/177/Proton-M / Breeze-M If this url is not available from your current location, maybe there is an ISP error/DNS not updating?

That's a whole different upper stage, using the cryogenic oxy +RP1 block-d instead of the hypergolic breeze-m. The smaller diameter of the "fairing" bit is actually a shroud around the block-d while the actual clamshell fairing starts with the widened diameter. So, it will need not only a different fairing (though you can get that shape approximated with the procedural fairings that all the fairing bases support), but also the block-d itself. So.. yea-ish. With big "ish" as the time spent with developing the TKS/VA shows. But it surely is a "i should do this" on my ever growing list and of course the Block-D has quite many variants used on the proton. xD

I updated the gitHub repository with first 1.2 compatibility patches for testing during the 1.2 pre-release time. Antenna changes The Breeze-M glonass antenna now acts as a part to access kerbnet. The Breeze-M telemetry antenna now acts the SAS-enabling part of the breeze. The Breeze-M tracking antenna now acts as a basic communication device for the breeze. I think putting the usability for SAS, kerbnet and even the basic antenna functions to the actual antennas instead of the breeze "probe" core itself is more engaging and logical gameplay wise, enabling these parts to fulfil an actual role that is even somewhat related to their real counterparts. The stage 3 of the proton LV (and upper stage for the "light" proton) have now built in short-range antennas like all probe cores. RCS Update The Breeze-M RCS modules now use the new audio and visual effects available for RCS parts. Compatibility Changes Rather little was needed to achieve compatibility with 1.2, as few things broke. The stages of the light ("soon to be updated with the proper medium and light variants) proton had to be renamed, as especially the light first stage gave very strange issues in-game, ranging from visual defects (half-transparent parts and world) to full crashes, that could only be fixed by renaming the parts internally, possible braking saves and/or part files. Search and replace for the following patterns can resolve these issues: HGAProtonStage1l replace with HGAProtonLightS1 HGAProtonStage2l replace with HGAProtonLightS2 You can find updated craft files in the repository. They also include auto-strut settings and the launch vehicles are fully tanked again, as the generators in the launch pad are currently not working properly. As this mod provides parts for disposable lifters (and not stations etc) I hope and think the needed rename isn't much of an issue. A full update of the mod will be realease when KSP 1.2 goes live.

@CobaltWolf just the summer slump.

The optical differences in the launcher itself are rather minor between k and m (and the different -m subversions). Mostly the bulges around the avionics compartment on the s3. The bumpmap of s2 is rather more on the old side as it is showcasing the older, sheet metal on spars version of the fore and aft compartments of the stage, instead of the actual composite structure. The bulges are already modelled, actually they where since the beginning. There will be a "proper" -k stage 3 in one of the next patches. Focus now is on the long avaited TKS/VA which is still in the texturing phase, after that, a k and also the newly announced medium and light versions of the Proton will follow. Which means the already included "light" variant will be overhauled and renamed to medium and a new light variant with additional fuel tank and only 4 engines (and outrigger fuel tanks) will be made.

Instead of the edge split modifier, one can use the "auto smooth" option under "normals" in the objects data tab.. It's slider value works like the edge angle setting in the edge split modifier and it also threads edges marked as sharp like the modifier. To give a "only edges marked as sharp, no angle based smoothing/sharpening, use 180 degrees. Using this method there is no vertex doubling on a sharp edge unless the final export to .mu in unity. This also needs to be used when using the data transfer modifier to use customs normals around holes in round surfaces etc.

You probably are running in some nifty legal problems here as you are not allowed to use squads assets like you want to. Even for work in KSP itself to my knowledge it is only accepted to use the parts inside the gamedata folder to create mods for ksp (like a re-skin of the original models, or modified parts using squad assets from the gamedata folder).

Is the part you exporting from unity actually changed in unity scene, not only in the unity assets folder? This might sound dumb but here is what I mean: There is this difference between the "model", the one you exported from your 3d editor and that resides in the assets/model folder of unity and the "object" you create in the hierarchy of unity by dragging it into the scene. The latter one usually consists of at least 2 objects: Game Object (with the part tools script bound to it) and the actual model object itself as the child of this Game object. The latter one now can be in two states: "prefab" or "not prefab". Prefab means (for me, surely there is a way better definition) the object is just some sort of "link" to the actual model (from assets/models). This means whenever you update the model (new export from the 3d app) the prefab that is the child of the game object with the part tools script in the actual scene in unity is updated, too. If you change the hierarchy of the model object in unity's hierarchy window (by deleting some part of it, or changing the hierarchy of it by changing a parent/child status of parts of the model (like the actual mesh, the collider or an empty or anything that will result in unity warning you "This action will break the prefab instance! Are you sure you want to continue?"), then you will loose the "linkage" between the model object and the model from assets/models. Than the object in the scene has no connection to the actual model any more. It is now a instance of its own. That means even if you re-export the model from your 3d application, and the model in assets/models gets updated, the object that is in the scene, as the child of the game object with the KSPpart tool script, is NOT updated and NOT changed. You then have to manually delete the object from the hierarchy of the scene in unity, re-drag&drop the models from assets/unity and make your changes that broke the prefab instance again. I have this problem with my parachute models. I use a bone armature to animate the different parts of the parachute differently, so that the cable doesn't change in diameter when the canopy inflates, and the canopy can change it's lenght when inflating while the risers dont change etc). To work properly the actual mesh of the canopy has to be a child of the armature, but whether or not i set this up in blender, after importing the two are siblings, not in a parent/child relationship, so i have to drag&drop the mesh to be the child of the armature, thus braking the prefab instance. So I have to repeat this process of adding the model to the scene whenever I re-export it from blender.

You can do this without the use of armatures by using the transformation constraint on the parts you had set up as described in your first post. Here is my version of it - on a much "neater to animate" setup with only 5 parts to animate per solar panel, but extending it is just adding the same settings to the rest of the parts. The round empty marked A is my "animation master". It is just an empty that will rotate on it's Z-axis from 90 to -90 degrees. The rest of the parts will move according to this rotation. I placed empties on the "hinges" between the parts of the solar array, but it will work with just putting the constraints on the actual meshes, too (which I did with the integrated radiator part just beneath the blue arrow). Part hierarchy is the same as yours, base (mesh) -> empty that is the pivot of the sun tracking animation ->empty A AND base of the folding animation ->empty B ->first solar cell (and the later added radiator) ->empty C->second solar cell ->empty D->third solar cell etc etc. As said, The empties B, C, D (and the unmarked F on the next segment) are the parts that use transformation constraints, but you can but these constraints on the actual mesh of the solar cell segments, too. The transformation constraint copies and scales the rotation of the animated empty A down to the needed range of rotation for each mesh. As the actual solar cells aren't flat the first segment has to travel 100° from its resting pose to its fully extended pose, so the 180° from empty A are converted in a rotation from -10 to 90 degrees on the empty B. C thus has to travel 190 instead of 180 degree, so it is set to move from +180 down to -10. D (and F etc...) needs to only rotate 180° as the parts are now symmetrical so they are set up accordingly (one moves from 180 down to -10 and one from -10. For your object B that needs to change its location, you could also set up such an transformation constraint, but mark the LOC under destination and set up your x(?) locations accordingly. Its quite easy, no need for bones etc, just add one or two constraints to an object under the constraints tab, edit the numbers, done. Especially with the "transformation" constraint. There is a "copy rotation" one, too that I tried to use first as it sounded obvious to copy the rotation from the animated empty A to, say B, but this made problems when there where rotations with ROT>180 degrees that would register as 360 -ROT etc etc. I then tried "track to" to let each segment track the origin of the other, but this was a hassle and gave incorrect animations, too sometimes. But the transformation constraint works fine and easy.

I wonder why no Sojus Mod ever gets the anti-multipath shields for the 2ASF-M-VKA narrow-angle antennas (along with the latter's arms) right. The bigger shields fold down with the arm to avoid clipping in the antenna arm, when the antennas are folded down. Can be even seen in the wiki images like: here you can see the different areas of the shields that can be folded only the very top part of the shield for the antenna that is up on the image, and nearly the whole shield on the "lower" one. You can clearly see the seems and even the hinges.

That is what I modelled. And that's what makes sense, for re-designing the thrust structure and all the plumbing of the original s2 (and shorten it?) would be insane for a cost effective smaller proton. But using the top most sub-assembly of the s2 mounted on s1 instead of the truss interstage and simply lengthen s3 shouldn't be too hard and cost-intensive.