nli2work

best way to do that is load the stock pod IVA and replace the stuff with ALCOR assets. then create a MM config to swap the IVA depending on whether ALCOR props are installed or not.

I haven't tried multiple background handlers on the same page. I'd think they would conflict. SteerableCamera background handler is probably not the same as cameraTransform on a page. Camera have to render to transform with non-transparent shader, you could put textureInterlayURL on this screen to layer, but doesn't seem necessary. HUD can be rendered on 10% screen without using textureInterlay, interlay would be on top of the HUD not matter what, since HUD is rendered first, being background handler, then interlay texture, then page definition text and variables on top. You'd have to "bake" the transparency into the scrolling bar PNGs if you want it to render at the same time as the HUD. You can control the camera's brightness with the _MainTex color and alpha settings in the KSP Unlit shader before exporting the prop. but if you are using cameraTransform in the HUD page (I'm guessing that's what you've setup in the above HUD screen), the HUD will probably get dimmed as well. TL;DR: to get the slightly darker background only inside the vertical bars but under the white text, I think all you need to do is "bake" the shaded transparency into the PNGs.

you dn't have to use a 2nd map for emissive, any texture will work. the light on z100 is likely a separate mesh with emissive shader using the same diffuse map; while the rest of the battery uses standard ksp diffuse shader

yeah just saw it now... map size overkill aside... 69 mesh colliders... I'm amazed this thing loaded in KSP at all

4+ gigs??? what could possibly make this 4 gigs?

Awesome! The new design looks and works great!

Ok, finally sorted it out... something I didn't expect at all and seemingly unrelated. took out the mirrorRefAxis line; and all works and looks correct now. Just one of those voodoo things like airlock placement I guess.

Blender uses the same world orientation as Max, Z-up instead of Y-up like Unity and most other 3d apps. when you import from Blender a 90 degree rotation is applied automatically so the pivot matches Unity's world orientation. to rotate a mesh collider you use the transform like any other game object.

your module working fine; I just can't figure out a way to get give it the right orientation. this is as far as I've been able to get; as you can see the response should the other way around. Flight behaviour is correct, but visually it's switched. Maybe DYJ will shed some light if he resplies in the pWing thread. I've matched all the pivots orientations and transform names to his AllMove Wing piece from what I can tell (it's imported back to Blender, so I can't be sure it's correct), I simply don't know where else I should be looking.

amazing work you three! my hat off to yous.

you want some padding outside the UV edges. 3~6 pixels worth. this way when the mip maps get generated, you have less chance of the UV seams becoming visible due to pixel averaging. as far as painting actual texture, depends on the style you are going for. Stock textures are very simple, just some large sections of light-mid-dark grays and some seams. Use whatever you want to get the look you want. photosource, filters, whatever. I tend to source alot from photos from cgtextures.com and use masks and stamps to clone specific sections, and using adjustment layers to integrate everything together. others prefer painting textures from scratch.

I'm using the same setup as All move surface from pWings, if I remove obj_ctrlSrf; the whole thing doesn't move and I get constant NRE from get_MovableSection. I tried supplying a transform with movableSection = and MovableSection = neither worked as far as I can tell. I haven't been able to figure out a correct setup for the other types even after importing the pWing MUs to blender. The plane flies correctly, just that the surfaces move incorrectly.

hi ferram, what's the proper pivot alignment for obj_ctrlSrf transform for FARControllableSurface? like stock SPH Y-forward; Z-down; X-right? or something different? I'm making some pWings using your module, the control forces are correct, but the movement is rotated somehow... If I press Q/E to roll; the surfaces move like I'm pressing W/D. and vice versa. experimented at 90 degree increments. but no orientation seem to change the visible behaviour. changing ctrlaxis to yaw or pitch doesn't seem to make a difference either.

I'd put a quarter-sphere behind the nozzle. As the nozzle rotates to point down, the quarter sphere becomes visible and fills up the gap. simply texture it to look like layered bands.

hahaha that's awesome!

is the PNG extention capitalized? should be lower case. other than that I don't know why they wouldn't be showing up... Any png in Flags or Agencies folders should show up in flag selection. the size don't really matter.

I'd check the default MFD settings for MechJeb/SCANSat and see how they are set up. they have a config setting for Show No Signal that redirects to a generic blank page if the plugin is not installed.

Thanks! not the first time I made that mistake. damn tech node IDs lol ok fixed.

do you have a 2nd quad on the main part piece for flag decal as well? if so, you probably need give them unique names and use two FlagDecal modules. multiple transforms with identical names will confuse FlagDecal module. if not, the NRE could be because as you speculated earlier.

that duna lander command pod looks cool!

no way to add flag without using FlagDecal module. Mk1-2 pod's FlagDecal module is at the very bottom. what's an auto-shroud? like a ModuleJettison fairing?

How do I get all moving pWings to work? is the rigging setup different than standard pWing surface? I used the same modules from AllMovingSurface; by my part doesn't move after Launch. for the all moving pWing I have ModuleControlSurface; WingManipulator; FARControllaSurface modules. rigging parts are all named matching the sample pWing FBX. I'm missing a proper transform for FARControllableSurface... how do I give the correct transform? MovableSection= or movableSecation = didn't do the trick. edit: adding another transform obj_ctrlSrf did the trick... but movement is flipped... roll shows pitch movements, pitch shows roll movements. actual control forces are correct though.

Retro-Future v1.3 ; Link in OP New Parts heavy main landing gear redesigned WingMountA part; will likely break vessels using older WingMountA part. Recommend removing older part from vessels; or not replacing WingMountA until later. Changes Reduced heat production for JeyTew and Trianka (damn overheat alarm was getting really annoying) Upgraded crash tolerance for all landing gears Increased braking power of tail gear cockpit now has emissive for windows intake settings for Stock Aerodynamics, thanks to Taverius enabled thrust reverse on all engines improved sound synch on all engines

Yes that's known issue. most likely due to RPM internals trying to update while in Editor mode, even though the necessary variables are not created until Launch. Mihara is aware of the problem, we'll just have to wait for him to fix it. The error messages are harmless, albeit annoying. To get rid of the messages you can remove JSITransparentPod module from the command pod part configs. The exterior windows will be opaque, everything else will function normally. You should gain some frame rate as well.

you have to be more specific about which modules you are combining in a single part. some combinations are possible while others are not. it's a case by case basis and not a little bit of trial and error.