linuxgurugamer

I found the problem, needed to use the right transform. Thanks for the suggestions

Sounds reasonable, but for right now, I'll just update the local patch, we can coordinate later how to merge the two. I;ll be able to push out an update this evening. One question I have is that one or more of the cameras are just showing a black picture (not totally black, but a solid very dark color) when RPM is set to that camera. Any idea what's wrong? Would it be an incompatibility of the camera model itself being used?

I found the main problem in a cfg file included with Hullcam. Apparently it was added sometime in the past to add new cameras which weren't included in your 3rd party patch

Found most of the problem in a cfg included with Hullcam

@MOARdV I got a report in the HullCameraVDS thread which I believe belongs here: KSP: 1.2.0.1586 (WindowsPlayer x64) Problem: The following cameras have issues when trying to view them from within RPM: Wide Angle Cam = black screen (within the RPM screen that is) Kazzelblad 500 = no option to assign a camera ID from right click menu and RPM does not appear to recognize it as a camera Nightvisioncam = gives two Camera IDs and two sets of ID + / ID -. Only the first one appears to work. The image is also plain (ie not green) NavCam = image is plain and no fisheye effect BoosterCam = only one Camera ID and One set of ID +/-. The dashed lines that normally run down the center of the image in both the horizontal and vertical direction do not show (not that im complaining. never particularly cared for those lines myself) KerbPro = image in RPM is rotated by 90 degrees counter clockwise Mods installed: HullCameraVDS 0.1.2.2 RasterPropMonitor 0.28.0.29319 I haven't done any testing with RPM b2 yet, but took a quick look at Hullcam, and don't see anything relevant. I'm assuming you are adding the HSIExternalCameraSelector to the parts on the fly, and it's possible that what you are looking for in the part is not what is there. If it's an issue with the cameras, please let me know Also, a minor issue, you have the following code in the JSIExternalCameraSelector.cs: [KSPField(guiActive = true, guiActiveEditor = true, guiName = "Camera ID: ")] You don't need the colon, I'm seeing a double colon in the game

It actually seems to be a problem in RPM. It's RPM which puts the Camera ID on the camera. I haven't tested with RPM, since it's still in beta. I'll post this in the RPM forums Pinging @MOARdV

Just released 0.3.0: Added random time to pre-failure reporting time Added Science gain after failure Added Science gain adjustment Added increased chance for experimental part to fail

Reasonable, but if the setting is already above 10%, I'll double the chances for that part, I think. But if someone is playing at those levels, they are probably gluttens for punishment I think I'll add a setting for the chance for an experimental part to fail

@inigma Might I suggest the following (all available for 1.2): Champagne Bottle, to give unique names to vessels EVA Enhancements, to give a better EVA expience EVA Parachutes & Ejection Seats, for those times when things go boom The Janitor's Closet, for housekeeping (doesn't change gameplay at all) Kerbal Launch Failure, for occasional random failures. Getting an update which will let you get science from a failure, allowing you to learn from experience, also experimental parts have much greater chance of failure Part Commander Continued,for ease of gameplay Total Time, to see how long you have been in a game

So, if there is one (or more) experimental parts on the craft, how much should the odds change for those parts?

Apparently there is a problem with this mod, look at the end of the new Tweakable Everything thread for details

Well, yes sir, but it can get very crowded

Why?

This Mod needs to get the toolbar wrapper updated and recompile the whole mod. It's a problem which was hidden until CC was released for 1.2

Me likes!!!!!!!

But that doesn't seem to work in the flight scene :-( I suppose it helps if "startingPart" is actually initialized :-)

I'm hoping this is it: ProtoTechNode techNode = ResearchAndDevelopment.Instance.GetTechState(startingPart.partInfo.TechRequired);

Safe to remove, yes. Not sure about adding, may need to be recompiled

Value of vessel is easy, I'm also trying to link it to the science costof the failing part. So for example, something I'm toying with is: sci = science cost of node part is in cost = vessel cost (excluding fuel) scienceAwarded = sci /10 * cost /100 I'm not sure of the numbers yet, I still haven't yet figured out how to get the science cost of a part in the flight scene It is a chance of 1:50 (ie: 2% chance of failure every fligh), not exactly once every 50.

I'd like to be able to take a part, and find out how much science was needed to buy the node that that part is in. Obvioiusly this would be for a science and career game. So I know that first I need to find the TechRequired for the part, and then given that, find the find and get the science cost. But so far, I haven't had any success. The tech tree is only spawned when going into the science building, I need to do this in a flight scene. Thanks

Great thinking that the rest is already implemented. I think getting some science is a great reward and incentive to not revert to launch. "Damn that sucked... but at least I got 10 science out of it" or something along those lines. The amount of science could be proportional to the launch cost (and top out at a maximum). So your $200,000 fuel launcher might blow up spectacularly, but hey, 12 science! Kaching! After thinking about it, great idea. I'm implementing it now, any suggestions for how much science to generate in the event of a failure?

Chances are set in the settings Science reward isn't really the aim. If there's interest, I could add it Incidents already appear in the F3 window

Like, a min and max time? Or just something totally random?

While Squad doesn't like random events, this is interesting. Kerbal Launch Failure (which I revived and maintain) does something along those lines, but it's totally random. It wouldn't be that difficult to code some random issues during descent in an atmosphere, but, from my point of view, it would be nice to know IF there was a sandstorm or high winds at the landing location. This is where things get tricky, cause now you are starting to get into some sort of weather simulation in an atmosphere.