linuxgurugamer

Yup

I didn't say make the allShaders public, I said it had to be static. To make it more general, so that it can be used in multiple mods, GetShader() should be public and static

Oh, I missed that it wasn't a separate file. good catch

you should make the GetShader a public static, so it can be accessed from anywhere, would also need to make the allShaders a static

Looks fine to me

Hmm, you're right, there is an updated version in CKAN for 1.3. Also, the best way to do make sure that only good releases get pulled by CKAN is to do a full release; CKAN by default will NOT look at a pre-release on github, so you'd be save doing multiple pre-releases. Since I don't see a release, I'll hold off for now. Let me know when you have a release. No rush since TR is available. I'll make sure that CKAN will NOT install both, will only install one or the other.

@sarbian I'm trying to use your code to display a wireframe for an entire vessel in flight. I'd like to use this in KRASH. In KRASH, I change a camera setting to get the wireframe, but it isn't as good as I like. So I modified your code to draw the colliders for all parts in the current vessel, while it works, it has a very significant performance hit. I'm assuming this is because the OnRenderObject is not doing any hiding, so it has to display everything? Is there anything I can do to improve the performance of it? Here is the code I changed: public void OnRenderObject() { if (showUI && currentDisplayedObject) { foreach (var p in FlightGlobals.ActiveVessel.Parts) { //var c = GetRootObject(p.gameObject); DrawObjects(p.gameObject); } } } I also noticed that it was still displaying the textures, under the wireframe, how can I stop that? Thanks

Probably in the log file, I'll take a look at the code Edit: Confirmed, it is in the log file. Which might also be shown in the console, depending on the settings. First, you don't really need the MM compatibility to have it available on CKAN. That is an enhancement for future-proofing it. Second, there are a number of mods which depend on TR aka TRR. Not having this listed in CKAN means that those mods will be unavailable in CKAN for now. It seems to be working (based on the comments above), so it would be nice to have it available. However, it's your mod, so I'll follow your wishes.

Have you tried the Probe Control Room mod?

Thinking about a mod. Only a pilot could do anything with engines. This essentially means that if there isn't s pilot on board, the throttle stays where it is. Or, the engines are disabled. What happens to a vessel which is running and the pilot leaves it? What about if an Engineer or a Scientist is on board? What about RCS thrusters? What about SAS? What about a small probe within a certain distance of the pilot? Mechjeb is unusable unless there is a pilot onboard. Same with Gravity Turn These questions need to be answered to be able to design a mod. Some of them, while the answer is obvious from the discussion above, are asked to make the mod more general (you KNOW someone will be asking for something).

VOID is now updated in CKAN. I had been so busy getting all my mods updated, I had forgotten that VOID was in a beta state until this release, and I had never added the new version to CKAN. All done now, should be available for 1.3

I'll check on it tomorrow.

I've recompiled it for 1.3, available here: https://github.com/linuxgurugamer/KSP-ProbeControlRoom/releases/tag/1.2.2.7-beta This is NOT an adoption, unless @Virindi doesn't come back. Some minor changes needed to be made for 1.3. Nice idea, care to make the IVA for it?

No need, already there. It's built with FMRS, so when FMRS got updated, so did this. I just updated the OP

New release, 0.6.9.1: Added KopernicusSolarPanel alias

Because I'm not copying the whole node, and this is a template for my applying the same thing to other cameras.

No, I need it because some parts have multiple. I've gotten it working, see below: @PART[aerocam|aerocam180|hc_booster|hc_kazzelblad|hc_launchcam|hc_navcam|hc_nightvision|hc_scicam|hc_wideangle|kerbpro|Telescope|Pictozoom_2000] { %CF = #$MODULE[MuMechModuleHullCameraZoom,0]/cameraForward$ %CU = #$MODULE[MuMechModuleHullCameraZoom,0]/cameraUp$ %CP = #$MODULE[MuMechModuleHullCameraZoom,0]/cameraPosition$ MODULE { name = cccam cameraForward = #$../CF$ cameraUp = #$../CU$ cameraPosition = #$../CP$ } } @PART[hc_booster] { %CF = #$MODULE[MuMechModuleHullCameraZoom,1]/cameraForward$ %CU = #$MODULE[MuMechModuleHullCameraZoom,1]/cameraUp$ %CP = #$MODULE[MuMechModuleHullCameraZoom,1]/cameraPosition$ MODULE { name = cccam cameraForward = #$../CF$ cameraUp = #$../CU$ cameraPosition = #$../CP$ } } // Delete the variables to avoid log spam @PART[aerocam|aerocam180]:FINAL { !CF = 0 !CU = 0 !CP = 0 }

I'm trying to write a patch which will take some values in an existing module, and use them when adding a new module: @PART[aerocam|aerocam180] { MODULE { name = cccam speed = 0 cameraForward = #$MODULE[MuMechModuleHullCameraZoom,0]/cameraForward$ cameraUp = #$MODULE[MuMechModuleHullCameraZoom,0]/cameraUp$ cameraPosition = #$MODULE[MuMechModuleHullCameraZoom,0]/cameraPosition$ } } Unfortunately, it's returning an error: [ModuleManager] Applying node HullCameraVDS/CCTVPatch/@PART[aerocam|aerocam180] to HullCameraVDS/Parts/aerocam/part/aerocam [ModuleManager] Error - Cannot parse variable search when inserting new key cameraForward = #$MODULE[MuMechModuleHullCameraZoom,0]/cameraForward$ [ModuleManager] Error - Cannot parse variable search when inserting new key cameraUp = #$MODULE[MuMechModuleHullCameraZoom,0]/cameraUp$ [ModuleManager] Error - Cannot parse variable search when inserting new key cameraPosition = #$MODULE[MuMechModuleHullCameraZoom,0]/cameraPosition$ [ModuleManager] Applying node HullCameraVDS/CCTVPatch/@PART[aerocam|aerocam180] to HullCameraVDS/Parts/aerocam/part/aerocam180 [ModuleManager] Error - Cannot parse variable search when inserting new key cameraForward = #$MODULE[MuMechModuleHullCameraZoom,0]/cameraForward$ [ModuleManager] Error - Cannot parse variable search when inserting new key cameraUp = #$MODULE[MuMechModuleHullCameraZoom,0]/cameraUp$ [ModuleManager] Error - Cannot parse variable search when inserting new key cameraPosition = #$MODULE[MuMechModuleHullCameraZoom,0]/cameraPosition$ The ",0" was added because some of the parts have multiple modules, but the same error happens without it. I know that the module being referenced is there MuMechModuleHullCameraZoom: MODULE { name = MuMechModuleHullCameraZoom cameraName = Pictozoom 1000 cameraForward = 0, 1, 0 cameraUp = 0, 1, 0 cameraPosition = 0, 0.18, 0.00 cameraFoVMax = 60 cameraFoVMin = 0.5 } So what am I doing wrong? Thanks in advance

no, it is supported and I updated the Wiki

As long as you don't change the name of the methods or classes, you won't break anything Re. CKAN, let me know, and I'll set things up to not break anything which depends on this

It has to do with the fact that both mods are touching the same internal values, and don't know about each other. Too much work for me right now.

It's not designed for it, but if the following is true, the sim is active: KRASHShelter.persistent.shelterSimulationActive It's not a true API, so you will have to first find if it's loaded, and then use reflection to get the value, this so you don't have a build dependency. I'll see if I can come up with a simple API for you (similar to the toolbar API) so you won't need to jump through hoops. May not be for a few days, if you write something, I can certainly include it

What does this mean, what's the difference? It has to do with the way parts are sorted in the editor list It's using a stock IVA for the Mk 3 cabin. Check the Mk3, see how it looks

too late! And actually I can't do it

Oh, one more thing. When (if at all) do you expect this to be updated to 1.3?