InsaneDruid

Same here. The Tank with Engine, without the landing gear would make a nice Part for an upper Stage, a small Satellite etc.

Well, in my experience, Unity has absolutely no problem handling such an physics set-up, which my experiments from the last hour show. First Row: a quick test using my Breeze and a MK2 Pod. The breeze core decouples, falls down and the MK2 Pod, as its an frustum, collides with the droptank and the breeze core+mk2pod assembly just hangs nicely without any issues, wobbling, jumping or anything. Just like in real world a frustum would sit in a ring shape. Second row: a quickly made LK dummy consisting of a frustum shaped top and a fitting counterpart (ring-like) as a base (Mesh is 48 sides, colliders are 12 sides). You can decouple the top and it will not move a millimetre, as it is set up perfectly fitting. You can than start the engine and slowly take off, you can even just land back into the base witch will set you up into the position of the start, perfectly fitting, auto-centred through the frustum shape, no issues at all. As said before: issues can arise from colliders clipping into each other, when the parts are assembled. This can easily the case with nodes that are not set up using the node{} system, as these coordinates there are imprecise as hell and prone to all sorts of rounding errors, compared to the actual meshes. you can find the test parts and a craft file here: https://www.dropbox.com/s/vyjvr8yv3gokebc/LKTest.zip?dl=0 you can find the blendfile here: https://www.dropbox.com/s/c2zog2rwfbx1iue/LKTest.blend?dl=0

Import Normals, Calculate tangents, Split tangents on. You could tick the checkbox in blenders FBX-exporter (under "geometry") to include tangents in the fbx, and then use "import" in unity though, should be the same. Smoothing angle is only active if normals are calculated in unity (which you should avoid, as you have way better control over them in your 3d modelling software (sharp vs smoothed edges etc).

I have to say I don't understand what you are saying here. These two are coupled via Nodes, so why should the lander segment "fall trough" the lander (if the latter would be annular). This would only be true after decoupling. And then it would be like in reality. Also, if the colliders don't intersect during assembly, then there is no uncontrolled bounce. I have ring colliders on my 2.5 meter (proton) fairing extenders (the interstage between a proton and a TKS or DOS derived vehicle), and you can "land" a stock mk2 pod nose first in it, and it will center itself, like in reality. PS: if a part bounces/shakes weirdly it might be an mass issue. Had it on my Proton S2 quad adapter. This would begin tho shake and explode if you used really strong engines on it. Increased the mass just a bit -> all is well.

But this is not true, as my Breeze-M with Droptank clearly shows. You just need to make a ring of colliders for the landing legs, so that is is hollow where the fuel tank goes. And the central collider needs not to intersect with them. Left:Droptank with its colliders Middle: Core with one collider Right: Core and Droptank together, like they will be in game during launch. The Core separates nicely without ANY problems. PS: bonus of the real RCS system: roll control. Without the need for unrealistic reaction wheels.

Unfortunately, they lack the roll control thrusters. (sideways from the main ones). or: (left original, right mock up) See here, too: http://novosti-kosmonavtiki.ru/forum/forum9/topic9992/?PAGEN_1=5 Also, the Contact Plate isn't round, it as a cut-out to make room for an rendezvous omnidirectional antenna to be raised: https://upload.wikimedia.org/wikipedia/commons/thumb/0/04/RP1357_p18_Kontakt_docking_system.svg/2000px-RP1357_p18_Kontakt_docking_system.svg.png

Its probably an alpha channel issue, i.e the texture having one and either one of the material settings in blender or unity is not correctly using it (correctly). We need the texture and a screenshot of your material settings.

Another update is online. This time, its mostly around fairings and finalizing the transition to unity5 for the build environment. Everything is re-exported from Unity5, the fairings have a better UV layout and updated textures. You can also choose from some fairing logos or add your own via firespitter like so: (instructions are also in the firespitter.cfg) Place your files anywhere and add a .cfg containing @PART[HGAProtonFairingA*|HGAProtonFairingB*]:NEEDS[Firespitter] { @MODULE[FStextureSwitch2] { @textureNames ^= :$:;my_path/my_texture;my_path2/my_texture2: @textureDisplayNames ^= :$:;My Texture Name;My Texture Name2: } } I'll upload a layered template later this day. Also, I included a togglable guide mesh in all fairing bases (right click on the base). Use it if you want to use the built in procedural fairings and you want to built a fairing shape that is original to the proton. The upper edge is the reference for the extended payload fairing, the lower edge is the guide for the standard fairing. EDIT: I added the link to a .psd template for those who want to create their own fairing logos in the starting post.

So you mean an engine cover/Interstage/jettisonable thingy?! Like MODULE { name = ModuleJettison jettisonName = fairing bottomNodeName = bottom isFairing = True jettisonedObjectMass = 0.1 jettisonForce = 5 jettisonDirection = 0 0 1 } ? You can play with isFairing, as this determines if the fairing stays attached to the part that was connected to the Node specified in bottomNodename or disconnects as debris. also check if the bottomNodename is correct (correctly defined and aligned), if the jettisionDirection is correct. You could post your cfg for us to check. 2) no. Just an arrangement of small, convex meshes (or boxes).

If all you want is a smaller NavBall, then stick with your native screen resolution and just use the ingame settings for UI scale along with to allow for an individual scaling of every UI element. (I.E.: only make the navball smaller etc) If you insist on using a bigger resolution, you have to turn on your dynamic super resolution (DSR, on Nvidia) or virtual super resolution (VSR, on ATI) in the system wide settings of your graphics hardware.

DOOOH! After fiddling and fiddling and trying and checking in-game I noticed: I had not set anything for tangents on the models when I switched to Unity5. After a calculation the render view is 1:1 with the material preview.

Thanks!

@KasperVld These threads could surely be resurrected into the modelling and texturing forums for good.: http://forum.kerbalspaceprogram.com/index.php?/topic/135597-iva-overlay-setup/ http://forum.kerbalspaceprogram.com/index.php?/topic/135682-iva-multiple-uv-setup-and-shared-assets/ http://forum.kerbalspaceprogram.com/index.php?/topic/135250-landing-legs-in-11/ http://forum.kerbalspaceprogram.com/index.php?/topic/135364-parttools-11-new-shaders/

I use Shadermap to generate bumps from height maps (that are made in PS). The height maps themself are also not just anything overlayd, but multiple layers of smart objects, each tweaked witrh layer styles.

Its a shame the modding threads of the 1.1 pre-release sub-forums got deleted instead of being moved into the regular modding forums. So many useful informations (that not only where viable for the pre-release, but for 1.x in general) wasted.

So I am fiddling with a slight overhaul of my proton fairings (better UV mapping, some detail changes in the textures etc) and noticed that the bumpmaps give a lot less effect with the new shaders that come with the unity5 part tools than with the legacy shaders. Here is a screenshot: see the difference in bump strenght in the areas marked with the green and pink arrows. Only difference here: the part marked in green is using the "new" KSP bumped spec shader (you can see the settings of it on the right side of the screen) and the part marked in pink is using the KSP legacy bumped spec shader. Notice how little (barely anything) effect the bumpmap on the part with the green arrow has despite the fact that the material preview window for that particular material in the lower right corner of the screen looks absolutely OK. So I tried increasing the effect of the bumpmap through modifying the bumpmap itself with stronger contrasts, but then artefacts appear (very dark accented edges) while the majority of the features is still not visible correctly. You can see it in this screenshot, marked with a red arrow. Also note: the matrial preview window looks ok again, just with stronger bumpmapping through the new bumpmap. So: just using the legacy shaders for now? Any suggestions?

(voice of the templar knight from the Last Crusade) You noticed wrongly! (/voice of the templar knight from the Last Crusade) Given that there aren't that many russian (and american) manned spaceship designs, only one of them (the vostok/voshod - which I count as one as it was one design, just modded) was spherical. Sojuz is a combination of spherical heat shield, a (slightly angled) frustum shaped main section and hemispherical top. The VA capsule, the first reusable capsule was a frustum which clearly falls under you "pointy" description. The Federatsiya will be a frustum shaped object, too.

Shameless Plug: For a "HD" Proton-M with Breeze-M upper stage and soon(-ish) a TKS/VA that can be combined easily with stock and tantares parts.

High Blood Pressure in your Head, acting on every tissue in your brain, possible damaging and rupturing blood vessels...

You can use the provided sub-assembly or the craft file for reference. Start with a Breeze-M Core Take the Breeze-M Fuel Duct, hit "R" to switch from cyclic to mirror symmetry, enable angle snap with "C", increase the (mirror) symmetry to 2 part symmetry using "X" and place the fuel ducts where the fuel lines are on the breeze core. Place a Breeze-M Tracking Antenna on the centre of the smaller angle between the fuel ducts. (see image 01) Place a pair of Breeze-M Telemetry and Glonass Antenna like shown in the picture. (see image 01) Use the move tool +"F" to fine-tune the depth of these antennas, if you like. Add one of the Breeze-M decouplers on top of the core. Place 4 Breeze-M RCS Blocks around the Mounting Brackets on the lower end of the core. (see image 02) Place the Drop-tank on the core. (see image 03) Place the 14D30 Engine in its mounting hole on the bottom of the core. (see image 03)

1) CKAN is based around a metadata-file called .netKan. In this file, which is created semi-automatically when you tick a checkbox while uploading a mod to spacedock, or if wanted manually there is a line that defines the location where the actual mod files are hosted (for instance: "$kref": "#/ckan/github/InsaneDruid/Proton-M" for a mod hosted on GitHub or "$kref": "#/ckan/spacedock/177" for a mod hosted on spacedock). Whenever the mod is updated in these places, the CKAN entry gets updated, too, automatically. With the logical exception for simple commits on GitHub. CKAN only seeks actual releases on CKAN. Which is cool for modders, as this allows for betatesting (manually downloading the latest version from github) with automatic releases (whenever you push an release on GitHub). In the .netKAN file, you can also specify the compatible version of KSP, or ranges of them (1.1 will mark compatibility with 1.1.0 -> 1.1.99). This line has to be edited manually when a mod is hosted on GitHub. But if a modder hosts its own .netKan, this is easy as it gets. The decision to flag a mod as compatible lies complete on the modder in any case.

"Nachtstrom" (night time energy prices) where a thing in the past here. There where even "Nachtspeicheröfen", electrical furnaces that ran on night energy and stored it using stoney material for the day. Today such pricing can be bought in special tariffs, but the usual tariffs are one price for any time of day. The average price here is about 28,8 Cent/ kWh!

^^ Also interesting to see the digital flight computer performing the roll manoeuvrer. The older Soyuz get rotated into the flight azimuth with the launch table.

And I say: it is! First, mods not working is: a) incorrect, as the majority of them was ported well during the prerelease. CKAN alone lists nearly 500 working mods out of 1700, but those 1700 are including those that stopped at anything between 0.25 and 1.0.5 b) not a problem of squad or the game itself. Actually, squad is one of the mod-friendliest developer. Then, crashes and issues. Well it depends of how common and severe these are. For me, they are acceptable if the majority of them gets fixed within the next month. Nothing gamebreaking. Nothing that is stopping me to enjoy ksp. Then, software is never free of bugs. I mean, they lost space missions due to bugs in a code that is (should) be more severely checked. Also, like stated in another thread: when is KSP "finished"? Where is the end? KSP is (for me) much more of a service. Does this mean squad are the best devs ever? No. But is KSP worth 40 bucks if you are interested in space and physics and you are in search of a sandbox to let the lego spaceships of your childhood actually fly? Oh yea. IMHO. And the last words in the previous sentence are key here in the discussion. Value of a Game is very individual. And there are tons of people that I would not recommend KSP to. But you stated your , well, statement is a very general fashion as "KSP is not worth it because bugs". And that's not true. And if you earned all that money, what are you going to do with it? If not earning more money, than you WILL "waste it". One way or the other. Having a fancy dinner with my gf in y well tailored suit and she in a dress to die for... well that's also wasted time in which we both could have studied. Or worked. To earn money so that then we could sail the world in a yacht.. oh that would then be also wasted time.

It does. Its a good, baseline AV scanner. Nothing fancy, nothing bad. No scanner gives you immunity versus unknown, zero-day exploits for the simple reason that they are per definition unknown. Heuristics can help, but only so far. Even if a scanner scores 100% at AVlab, this only means that the used virus/malware samples where detected. You can get an infection an hour later by 2 others, newer viruses. Better close down the weak points in the system. Adobe flash? Thanks, but no thanks. Even if that means that i use a greasemonkey script to watch twitch using HTML5. Unfortunately, the ads by AV vendors fool the users to feel overly secure (when in fact some of these tools ADD more weak points in the system (see above), which leads to them being careless.