nli2work

because they are sharing the same shader (KSP name); or material (Unity name). if you want Part A to have say... Diffuse/Specular, and Part B to have Bumped/Specular; even though they use the same diffuse texture. you need to create 2 materials, assign each the same diffuse; and a normal map for the Bumped/Specular shader.

they won't be in a crate crate. they will be in the same cubic form. the drill will have the most animation; still need to take a look at the existing drills for the config setup. the generator won't move a whole lot, just a little dial that loops while it's on. I'll let Rover configure them so they attach like the rest of the packrat crates. most reasonable use would be to extend the range of rovers without relying on solar panels or RTGs I suppose.

ActionGroupSwitch triggers Initialization Error when used in conjunction with TransparentPod module

I have a few small rover parts in the cooker for you folks that like to build small designed for KAS and Roverdude's Packrat Rover kit. for now a half size Ka fuel jug; regular size portable generator; and a deployable drill; all in the same format as Packrat Rover crates.

KSPI adds AtmosphericIntake and IntakeAtm resrouce to parts with ModuleResourceIntake for IntakeAir, and IntakeAir resource. it's probably done in code as I can't find a MM patch that does this.

These are pretty harmless. RPM comes with several patch configs files that adds screens to stock IVAs and some other Mods IVAs. if you don't have some of the IVAs, you get errors like these. all it means is the IVAs will load without RPM screens, assuming you have those parts to begin with.

it's downloadble here http://snjo.github.io/

the seams are appearing between pieces of mesh right? no along all UV seams. you sometimes get z-fighting between adjacent thin pieces of mesh when zoomed out farway. it's dependent on Near Clip setting on Unity camera, I don't know why, all I know is it happens in Unity. probably not much you can do about it.

surface lights; B9 also has a few lights

I'd keep it symmetrical. dealing with 4 nozzles and trying to balance them is a pain. even with RCS Build Aid to show you the torque resulting from engine placements.

looking good! it handles better than any VTOL i've ever tried to build.

yeah this was done with SCANsatRPM's maprenderer background handler; with a special RPM page defined to display the SCANSat map on a sphere instead of normal flat surface. From what I understand, RPM screen is mapped to UV space from 0,0 to 1,1. upper left corner being 0,0. non-square texture displayed is either stretched to fill the UV space, or some flat color is used to fill the extra space. Which is what I think I'm seeing. the upper right inset is the RPMscreen at the time I took the screen shot; the middle band is part of the large map, centered on the active vessel. then spill overs of the large map is used to fill the top and bottom bands that's not filled by the large map initially. The large map is 2x1; so it could simply be shifted up so it fills the top 1/2 of the UV space. Rescaled to 1x0.5 in other words, with upper left corner at 0,0. and I can map the sphere (or curved cylindrical) surface accordingly. I'm not sure how I would do this at all with the newer SCANsat versions. I'll get the prop and config together for you look at tomrrow. Although this might be as far as it gets since transparent shaders doesn't render in correctly on internal props. a solid sphere in IVA is more annoying than none at all I think.

yeah problematic... I tried place the intlight action in the slave module and no luck... having 2 slave modules, one for animation, one for intlight action doesn't seem to work either. might need to create an animated prop as the light source.

did you give the additional cameras proper ID? when you first place them they are all ExtCam 1. right click on each and use the +/- sign to set them to different ID #s. you can have up to 8 distinct external cameras.

true, technically that's two master modules. I'm pretty sure the slave module doesn't need switchTransform; I'll have to check the configs tonight, I have a master-slave setup between 2 props.

Ah I see, thanks. looks like I'll have to wait until you guys change it. I'd be in over my head trying to code it myself.

sorry, we're both typing and posts go in off sync... I think all you need to add in the slave module is actionName = dummy. it doesnt' have a default value from the docs. the AG rocker switch has actionName = custom01 in the slave module as well, so it works either way. master-slave module(s) linked by the perPodPersistenceName. your master module turns the light on/off and does the emissive texture change; the slave module doesn't do any action; just plays the animationName = b9rockeranim2

I dealt with this issue recently, not sure how it was fixed. seemed like all of a sudden slave module just started working.

I think slave modules need actionName = dummy? but why would you use a slave module to run the rocker switch anim at all? the lightswitch action doesn't interfere with triggering animation. something like this should work both to control the internal Light and trigger the rocker switch animation I think { name = JSIActionGroupSwitch switchTransform = Collider animationName = b9rockeranim2 // animationName from slave module actionName = intlight internalLightName = CockpitLight perPodPersistenceName = TurnInternalCockpitLights needsElectricCharge = true switchSound = ASET/ASET_Props/Sounds/click-027 coloredObject = Rocker disabledColor = 255,171,0,0 enabledColor = 255,171,0,255 }

RasterPropMonitor's JSITransparentPod module. It does much more than just making the IVA visible, all the prop animations will be visible, the RPM monitors will update as well. There're few caveats, mostly with transparent shaders in IVA, limited by KSP's rendering order when dealing with those shaders. but for 90% of things you might have in the IVA it's perfectly good

sounds good, I'll give it a go. Edit: I look a peek at the FSengineWrapper code... if I understand it correctly, it sets the 1st loaded engine module (ModuleEngine, ModuleEngineFX, FSengine, in that order) to an FSengine type, which drives the other FSengine related modules. correct?

would it be possible to add that capability? specifically I'm looking to do mixed mode engine where one mode spins propeller, another mode doesn't. switching to non-propeller mode would be treated as if propeller engine is shutdown and the propellers would spin down as normal.

docking module would be the best way to do it without a plugin and without giving unmanned capability. set the "nodeType =" to something unique so it won't try to dock with other stock docking ports.

would that set the FSengineSounds to only activate when in AirMode?

would something like this work as one might expect? MODULE { name = MultiModeEngine primaryEngineID = AirMode secondaryEngineID = VacuumMode } MODULE { name = FSengine engineID = AirMode ..... } MODULE { name = ModuelEngineFX engineID = VacuumMode ..... } MODULE { name = FSengineSounds engineID = AirMode ..... }