NoMrBond

If you use something like KER to adjust its orbital period to 6:00:00.0, it'll stay in position for an awful long time

A diffuse texture is the visible (RGB) texture of a part, the specular is (usually) just a layer on the image (the alpha layer in this case) which specifies which areas of the base (diffuse) texture are shiny. So a 'plain' diffuse texture is RGB, and a diffuse+specular texture is RGB(A) A part which is matte (i.e. not shiny or reflective at all) could just have a diffuse texture (and it's mesh renderer attribute for shader type in Unity would /KSP/Diffuse and the texture would be an RGB image) A part which is shiny (i.e. a polished or finished surface) could just have a diffuse+specular texture (and it's mesh renderer attribute for shader type in Unity would /KSP/Specular and the texture would be an RGB(A) image) Cost wise, specular textures are bigger because they're four layers instead of three for plain diffuse. Performance wise specular parts probably cost more to render but unless your video card is a potato I would assume this cost to be almost insignificant?

Made for Eyes Turned Skyward but other people might want to dump some heat too

Huh, I was considering doing some streaming anyway now that my fiber connection has been installed

OK, the HRS panel is feature complete with texture, specular, normal and functionality (well appearance wise it pivots against sun, if you want it to actually radiate heat that'll need the plugin and whatever config changes required) Download HRS beta files Was there a list of what parts still need doing and/or who was interested in doing them? [Edit] Is there any way to hide the solar panel GUI reports from using the solar panel module for the pivot?

Awesome, congrats on your release RTG Team Now I have to find where I put AIES and the module manage patch for all the antennas

Great, that's working now thanks. A few behavior oddities switching over from Unity gameObjects to Blender empties (which KSP seems to recognize) so I don't have to break pre-fab's any more if possible, should save some time. I think the only way to do that would be to have them as one part, and the whole truss they're attached to would rotate so they're all fixed, or you'd need some kind of plugin, perhaps rotating them with rotatrons/washers via IR/MSI. I suspect this is why the LM-HRS panels don't individually rotate, so they stay edge on to each other the whole time

Need to add the textures for the pivot mount and finish the normal for the backplate and mount, otherwise... Animation plays when you pull the part out in the VAB/SPH for some reason, not sure where that is coming from

Hrm, you're using solarPivot but the report from the solarPanels2 shows sunPivot, oh well, try both I guess As for the suncatcher, is that a Unity object (like a plane) with no mesh renderer or just an empty gameObject, how is it positioned? [Edit] Well it all moves now, except now the animation plays as soon as you pull the part out in the VAB /headscratch (resolved) Works fine as soon as you launch, i.e. starts closed and opens/shuts properly

Thanks xEvilReeperx, still not having any luck so the v1 of the panels just might not pivot, more likely something is just set wrong and I'm due for a /facepalm when I see it I can't see the suncatcher (object? transform?) in that list either, unless they are also not in use any more and it's a layer or trigger option (kind of like airlocks/ladders) now?

I was one of the lucky ones for whom the drop-in method for x64'ing my KSP install just straight up worked with minimal fussing (only required switching from borderless window mode to fullscreen), so I suggest trying that before setting up a Linux VM for the Linux 64-bit build. If you do run a Linux VM, I'm assuming you can just install Steam for Linux and pull the Linux version of KSP that way? Some mods have a few errors with capitalisation which doesn't bother the windows install, but throws errors under Linux, but they seem fairly few and far between now

I don't think any amount of pressure would make Unity 5 arrive any earlier, assuming of course Unity Technologies want to get Unity-5 out the door and in peoples hands equally as much as people want it in their hands. That is a harsh assumption, which if it were true, Squad wouldn't be able to tell us that the x64 builds they have tried to make were not suitably stable for release because they never would have made them. Not having an x64 build doesn't mean Squad doesn't want to deliver one, why assume they're withholding the x64 release to spite you, when they probably just don't want complaints from ~1/3rd of their user base when it doesn't work? What are the numbers, 500k copies of KSP? macs+linux is what, ~10% so imagine 1/3rd of the rest (going by the survey) of 450,000 KSP users complaining that KSP doesn't work because of the x64 update, you want to man the phones for 150,000 complaints? Users are going to want to tick the x64/64-bit option in the launcher and have it work, and they're going to complain when it doesn't. There would be complaints from people with 32-bit OS installs that the x64 option doesn't work for them, it would happen. Assuming there is no interest in migrating to dx11 over dx9 ignores the cost/benefit in migrating to, or additionally supporting dx11 with a split code base, maybe it wouldn't provide enough benefit to enough users, what if its high development time coupled with excluding benefit of that dev time from anyone without dx11 capable hardware. Maybe there is dev time budgeted for implementing dx11 support after KSP is feature complete during the Beta stage? Maybe there will be a clear answer, but I suspect not because if Squad promises to deliver x64 or dx11 and it ends up being either impossible or cost prohibitive with the KSP codebase there would be a finger pointing quote-riot, so 'we would like to' is the best we can hope for.

Nope, the name = argument specifies the name of the module{} you are calling For example, even in your own .cfg a bit earlier you have MODULE { name = ModuleEngines etc } For ModuleGimbal it only needs to know the name of the transform to wiggle around, then all the child parts of that transform (in this case the nozzle mesh) are, well, wiggled.

You're not actually calling ModuleGimbal, you have name = nozzle in the config, so replace the MODULE { name = nozzle gimbaltranformname = thrustTransform gimbalrange = 0.5 } with MODULE { name = ModuleGimbal gimbalTransformName = thrustTransform gimbalRange = 0.5 }

Don't worry too much about it, I have my own list list of hair-pulling reasons why I check the Unity names match the config names now.

Your gameObject is missspelled thrustTranform in your Unity heirarchy, it should be thrustTransform

The particle effects are probably not showing for the same reason there is no thrust, they're looking for the transform to spawn at. The newer engines seem to have three thrustPoint (gameObject where the combustion effect visually comes from, Z+ for direction[blue arrow]) smokePoint (gameObject where the smoke effect visually comes from, Y+ for direction [green arrow]) thrustTransform (gameObject where the physical force produced is applied, Z+ for direction[blue arrow]) If you're usong ModuleEnginesFX then try adding these to your Unity scene (otherwise the engines section in the help thread)

I usually do add it to the part, but for this one I was breaking the pre-fabs all the time and deleting then re-adding the HRS model all the time playing with the new functionality I'm not familiar with, so I just stuck it on a root gameObject until I sort out what I need to do to make stuff work so I wouldn't need to re-add the details all the time. Some progress, added the piping details via normal (finally got it working) with texture and specular improvements. The axis mount has been added under the base-plate but have not sorted out the sunCatcher or made the pivot work as yet. Alpha-2 download here if you want to try it out.

Instead of tracking these expended stages to the ground, it could be simpler to model conditions for recovery Parts passing out of the 2.5kM 'atmospheric window' are checked for conditions (i.e. parachutes + will land in water, parachutes+legs+will hit land, etc) before being unloaded by the game, anything that meets the recovery conditions is automatically recovered at some calculated 'touchdown' recovery time (or appears in the tracking station to recover). Perhaps there will be a time delay or reduced value depending on how far away from KSC parts are recovered from

OK thanks Tiberion, that's the same sort of hierarchy I'm using for the unfolding animation at least but the panels just don't want to break for some reason, the whole part explodes, or the part it's attached to explodes first and I'd really like it to break into its component panels like the 1x6 and 2x3 solar panels do (at this point I'd temporarily accept the whole thing coming off like the XL). I hope it's not because of Unity not liking the way I rigged it in Blender using empties. I'll keep working on the sun tracking for now when I get some time, and get back to the breakable bit later, achieve overall functionality first

Tried over and over and over and over again to get Shadowplay to record ~one minute of footage so I could upload a youtube video Everything reports that it's working, all the icons pop up saying it's working, no video output is written, MFW

Solar panel destruction used to be config based (isBreakable = true) with a specified gameObject/transform showing which part shears off when damaged, however the latest (23.5) versions of the Squad KSP solar panels no longer have this config line. I'm not sure when this changed but since I'm making a breakable part right now I'd rather rig it in the 'new' fashion which will presumably be supported rather than a legacy method which may be depreciated and thus require updating at some point later when the method is fully depreciated. Has anyone rigged a breakable object in this new fashion that could please share how to build the Unity hierarchy for it (gameObjects+components+settings if possible), or could a developer please post a screenshot and/or a brief explanation of the 'new' breakable rigging is implemented. Thanks for your time, NMB.

RAID-0 is striping, do you mean RAID-1 (mirroring) for data security?

Thanks sirkut, still not having any luck with shadowplay, everything seems to work and then it just doesn't write the output file even though the flag pops up saying it is, will give it another go tonight when I have some time I'd rather work on finishing the upwraps, textures and butt heads with my old foe normal baking first though, maybe I can stream it to twitch and link that instead, whatever works The new animation is a smoothed curve which is slower at each extreme and about half the speed (on average) as the test one

Do the crew towers only attach in that way to crewed capsules? Further, do you need to line them up on the hatches so that your crew can walk across and enter the capsule? Just wondering if the walkway basically does the 'my job is done here' if some conditions aren't met at the launchpad