sumghai

Not sure what you mean, could you please elaborate? According to various Unity forum threads: - The prevalent solution seems to be to assign the objects you don't want to be lit to a different layer, then specify a culling mask for the light transform; however, in the context of KSP one cannot move IVAs or props outside of the Kerbal layer. - There's also some discussion on vertex vs. pixel lighting. Apparently, pixel lighting would properly account for obstructions by meshes but are resource intensive, and so Unity games often put a limit on how many pixel lights you can have in a scene; any lights that go over the limit get turned into vertex lights, which are (AFAIK) computationally "cheaper" to render but do cause raycasts to pass right through objects. Here's one of the more comprehensive threads on the subject, with varying (and sometimes conflicting) suggestions. I'm still trying to figure this out, so any help would be appreciated. Thanks! It's still very bare-bones at the moment while I work on higher level functionality like cabin lighting, master-slave shutter control and emissives

Looking at your log file, I'm seeing lots of errors of the form: IndexOutOfRangeException: Array index is out of range. at JSI.InstallationPathWarning.Warn (System.String path) [0x00000] in <filename unknown>:0 at JSI.RPMVesselComputer.OnAwake () [0x00000] in <filename unknown>:0 at VesselModule.Awake () [0x00000] in <filename unknown>:0 UnityEngine.GameObject:Internal_AddComponentWithType(Type) UnityEngine.GameObject:AddComponent(Type) VesselModuleManager:AddModulesToVessel(Vessel, List`1) Vessel:Awake() UnityEngine.GameObject:Internal_AddComponentWithType(Type) UnityEngine.GameObject:AddComponent(Type) UnityEngine.GameObject:AddComponent() Part:decouple(Single) Part:Die() Part:explode() Part:HandleCollision(Collision) Part:CheckCollision(Collision) Part:OnCollisionEnter(Collision) Can you please double check you've installed the correct version of JSI RasterPropMonitor correctly? Failing that, you may need to remove all your mods, and re-add them one-by-one until you've narrowed down the actual culprit of the crash.

I'm making a station crew module whose internal consists of a common galley area and four sleeping compartments, each of which will have their own independently-controlled light transforms. In other words, light from one zone should not spill into others if there is a wall panel or prop blocking the light. However, I find that the door panel props aren't blocking the light coming from the galley: I've tried using cube primitives with double-sided shadows to try and block the light, as well as playing around with shaders, but none of that seems to have worked. Any ideas?

You can't directly link to a file on your computer. Nobody can see it. You need to upload the contents of the file to a file hosting service on the internet like Pastebin, Dropbox or Google Drive, then provide a link to that online file in your forums post.

Could you please provide the log files after your latest crash, as per the instructions for this subforum? Upload your log file to a file sharing service, and then provide us with a link to the log file. Do NOT paste the log file directly on the forums.

Progress Report, 30 July 2017 After a little bit of banging and shouting, I've managed to make each of the viewport shutters on the Hab independently controllable via a pushbutton on the corresponding internal viewport prop: There is a minor difference in the appearance of the shutters when the JSI Adv Trans Pod plugin is enabled and when it is disabled. I suspect it is due to the way internal props and external parts are rendered, but I'm not going to lose sleep over it. Now, going back to the master/slave viewport shutter control system, here are the detailed requirements: - Each shutter must be individually controllable with the "local" switch built into the internal viewport prop (implemented) - If the cabin master viewport shutter switch is set to the "close" position, all shutters close and remain closed as local switches are disabled - If the cabin master viewport shutter switch is set to the "open" position, all shutters open and can then be controlled individually by local switches - No skipping animations. For instance, when closing a shutter in the process of opening, it will not immediately skip to the fully opened state and then close; this would be implemented by reversing the animation while it is still running, or waiting for the animation to play out in full before reversing. And for the cabin lights: - Each lighting zone has a local switch that controls both the corresponding internal light transform, as well as the corresponding viewport emissive (when the viewports are in the opaque state due to the absence of JSI Adv Trans Pod) - If the cabin master light switch is set to the "off" position, all lights and viewport emissives are turned off, remaining off as local switches are disabled - If the cabin master light switch is set to the "on" position, all lights and viewport emissives are turned on, and can then be controlled individually by local switches - Skipping of light and emissives won't be an issue they will be instant on / instant off Would you guys be happy with this setup? I'm going to try pick @alexustas and @MOARdV's brains to get the various custom variables/logic working.

MAS is sounding better and better by the minute - I just read the primer on Lua scripting on the MAS GitHub wiki. On the other hand, keeping the desired feature backwards-compatible with RPM would be nice. @alexustas, would you be interested in weighing in as well? Progress Report, 25 July 2017 A quick diagram detailing the extent of the master/slave control scheme for viewport shutters, as well as the various lighting zones: In anticipation of whatever control logic solution that ultimately arises, I think I'll start off by moving the individual shutters and animations from the viewport props to the part exterior, so that the shutters would work with both opaque and transparent windows.

Progress Report, 24 July 2017 I'm currently working on the main crew modules (Hab, Science lab and Utilities/Command). Thanks to @InsaneDruid, I managed to figure out how to fix vertex normals around viewport cutouts: Now, let's talk about viewports and transparent pods. Originally, none of the FusTek pod windows were meant to be transparent, but when I conceived the Kupola Observation Module, I felt that its windows were large enough to justify investing time in using a third-party plugin like JSIAdvTransparentPod. For consistency's sake, I decided that the other crew modules should also have transparent windows, but there were a number of factors to consider: - Cabin lighting is dynamically controlled via RPM; the lights can be toggled on and off via pushbuttons, and will also automatically shut off if the vessel runs out of ElectricCharge - The viewports all have integrated blast shutters controllable from IVA, which will obviously block out the cabin lights from the viewports. - Finally, there is a very small (but extremely vocal) minority of players in this thread that have made their dislike of what they perceive as "unnecessary" dependencies known. So how do I balance all these requirements? I believe a hybrid approach is best: - On the pod exterior model, the outermost pane on the viewport frame will have fixed transparency. - Immediately behind the outer pane is the animated blast shutter - The inner pane, meanwhile, will by default be an opaque diffuse emissive controlled by the internal cabin lighting state, and become transparent only when JSIAdvTransparentPods is installed - The viewport frame prop in the internal will just have a button controlling the corresponding shutter (I believe RPM supports driving external part animations from IVA) So far, I've set up the transparent windows and IVA cutaways for the Hab: The Problem My original intention was for each of the viewport shutters to be individually toggleable from the corresponding viewport wall panel in IVA, with master open all/close all switches located near the ends of cabin IVAs, as well as in the part context right-click menu. However, I'm not sure if JSI RPM supports the complex master-slave animation control scheme I have in mind for this to work. Another complication is cabin interior lighting - the Utilities and Science modules are easy because they have one single contiguous "zone", but the Hab has a total of five zones (the main galley area/corridor, and the four individual sleep stations). For the Hab, each sleep station was intended to have its own independent lighting controls, while yet another part context right-click menu would provide the master lights on/lights off capability. Is this a bit too much for you guys and gals and players? Is this too difficult to implement in JSI RPM? What alternative setups would you guys suggest? This isn't just a muse - I actually do seriously need help on this.

[MOD - Moved to Add-on Discussions, as this about tweaking add-ons.]

[MOD - The moderation team has examined this topic, and as it makes use of real science, it has been deemed appropriate for this subforum. Carry on ]

[MOD - Moved to Kerbal Network subforums, as this is the appropriate place to report site/forum/wiki/CurseForge issues.]

Progress Report, 2 July 2017 As I have indicated elsewhere, I'm still working on FusTek Station Parts, despite various things getting in the way (such as SDHI SMS and a real-life career change). I've finally managed to finish the IVA for the Kuest Airlock, as well as the Flight Scene cutaway views - the cutaways are quite small because they have to line up with the geometry of the internal FLEXracks props, and the corner areas would have been occupied by integrated monoprop / life support oxygen tanks that would block the view anyway. As such, the Kuest Airlock is now 100% complete. Going forward, I am going to slowly work on each module and its corresponding IVA to completion, before moving on to the next one. My system of modular structural panels makes life a whole lot easier, especially now that I have less time to develop mods than in the past. EDIT: For those wondering about the IVA shadow casting and light leaking through opaque walls issue, I've been told it's a KSP bug. Nothing I can do about it.

Could you show a screenshot of the folder this CFG file resides in?

I've started reading up about the requirements to port old RPM configs for props/spaces to MAS, but how soon would I need to change over to the new plugin?

This falls outside the original scope and intention of this add-on, so I'm going to have to reject your request. You're better off making your own parts and models from scratch, rather than depending on re-purposed versions of SDHI SMS parts.