danfarnsy

Yagami, Blowfish may be nearly done with the maintenance port. He may be able to answer any questions about immediate needs. Bac9's update to the MK2 frames seems to be on hold, and I think the mod may still benefit if we could do some IVA work, but K3|Chris is a tough act to follow. I'm taking a look at Blender (and maybe Maya), but I'm not an experienced artist. The closest I've come to this sort of stuff is apparatus design with SolidWorks. If you've got some skills in this vein and can match the style / aesthetic of this mod, my guess is nobody will turn you down (though I'm not in charge of anything). While I have seen some tutorials on modding wiki.kerbalspaceprogram.com/wiki/Category:Modding_Tutorials, I haven't really gotten much use from them. If you have programming experience, you can likely pick up the syntax of C# fairly easy (if you already know it, even better), which is used to make .dll files for mods which add to or change game behavior. I know there are a few mod-makers who learned to program specifically to make KSP mods. It might be worthwhile to go through config files of stock and mod parts, as well as looking at the source code available from different mods to see how they're structured. Those are just a few starting points from a guy who is just starting.

Jared, thank you very much! I made small translation and scale changes, and they came out beautifully: Blowfish, I have posted an updated download with Jared's smoother PFD overlay, and I will be removing the previous link. Can you incorporate it into the dev version, because AWESOME! https://www.dropbox.com/s/r8c6gx24zj9v5ov/Danfarnsy_B9_MFD_Changes_20150730.zip?dl=0 Hopefully we can get some feedback on any other bugs with the MFD. In particular, I think there may still be some funkiness with the AFPDs' vertical bars.

I got the PFD and APFD working, including fixing textures that needed to be resized or flipped and changing the config files to match the new RPM format. Everything properly uses the B9 textures again, as well. The inversion on the APFD ladder was just a texture issue, too. I didn't convert any textures to .dds format, though it may be a worthwhile project as it may reduce overhead and load times. Blowfish, I installed git and a gui front-end, but I don't have permission to access your git repository on bitbucket. So here it is on dropbox: removed link, see http://forum.kerbalspaceprogram.com/threads/92630-0-90-B9-Aerospace-Release-5-2-8-%28updated-30-12-14%29?p=2111662&viewfull=1#post2111662 for updated link JaredTheDragon, The relevant texture is in that dropbox link in /GameData/B9_Aerospace/Props/B9_MFD/images/pfdStatic.png . You can compare the old with the new and see if you can improve it any. In particular, the old one was already fairly harsh (no transparency fade on the border), so when I upscaled it, it simply reinforced the pixellation and isn't very pleasing. Compare it with StaticMask.png, which is much easier on the eyes. Otherwise, it's sized correctly and functional.

I've finished the config files, with only a couple of remaining issues: First, the original static masks for the navball were too small under MOARdV's changes (they need to take up the full 512x512 space now). I've resized them with GIMP, but the pfdStatic.png came out fairly harsh and pixellated (and StaticMask came out pretty!), even though I used cubic interpolation on both. If somebody has the original resources used to make those, or isn't a n00b with GIMP, they may have better results. Or I can suck it up and soften it pixel-by-pixel... *shudder*. Second, the HUD/APFD changes were a little beyond me right now. I did change them, and they're somewhat better, but the ladders are still upside down and the vertical bars are now defined in /JSI/RPMPodPatches/BasicMFD/PlaneHUD.cfg, rather than in B9's HUD.cgf and B9_MFD.cfg, which means they're now using RPM's vertical bars instead of /B9_Aerospace/Props/B9_MFD/images/HUDPFD/ADI_rightscale and ADI_leftscale. Vertical bars used to take up several lines in the .cfg; now they've been replaced by this: "verticalBar = RadarAltOceanBar;VSIBar", which is given in PlaneHUD.cfg as JSIHUD_VERTICAL_BAR { name = RadarAltOceanBar texture = JSI/RasterPropMonitor/Library/Components/HUD/rightscale useLog10 = true variableName = RADARALTOCEAN position = 480,160,64,320 scale = 0, 10000 textureLimit = 855,170 textureSize = 640 } JSIHUD_VERTICAL_BAR { name = VSIBar texture = JSI/RasterPropMonitor/Library/Components/HUD/leftscale useLog10 = true variableName = VERTSPEED position = 96,160,64,320 scale = -10000, 10000 textureLimit = 1845, 208 textureSize = 640 } I don't know if it's safe to create our own versions of these, e.g. name = B9RadarAltOceanBar, such that we're not calling the ones in the RPM package and instead we get to use the original B9 vertical bar textures. Do you want what I've got so far, or should we wait until I've learned the difference between my asymptote and a hole in the graph? And how would you like to receive it?

Does somebody want to point me in the right direction for taking a look at fixing/updating the MFDs for the cockpits (in particular, the navigational displays)? I have programming experience, but I haven't really tried my hand at mods besides playing with config files. Or if there is some other gap you all could use some help with, I'd love to help out.

FreeThinker, The configuration files for the radiators are inconsistent. I was just messing around with the radiators in KSPIE 1.2.6, saw you posted an update, and I installed it. Part radiator1 has these lines added: emissiveConstant = 1.6 heatConductivity = 0.5 thermalMassModifier = 25.0 skinThermalMassModifier = 100.0 skinInternalConductionMult = 200 radiatorHeadroom = 0.5 There are values for circradiatorKT, but they are missing for radiator2, SmallFlatRadiator, LargeFlatRadiator, RadialRadiatorzzz. Also, does an emissive constant of 1.6 make sense? I thought a value of 1 corresponded to a perfect black body, and values less than that for imperfect radiators. Of course, the effective surface area of these radiators could be larger than is defined in the part config file, but that gets funky because a larger value also means the radiators will absorb more heat from the sun than a perfect black body as well, which is very unphysical even with a larger effective surface area (since it can't absorb more energy than is incident on it). I suppose that would matter more for the flat panels than the rotating deployed ones. Maybe we can assign the static panels emmisivity values of 0.95, consistent with the stock radiators? I can go ahead an update the missing values and post a link to google docs, if you like. - - - Updated - - - Here's a link with values to copy/paste in the radiator part files: https://docs.google.com/document/d/1BrawPD0j29GWOGusTYjc6CUFM6ZpxlLatoYzz5FRrzc/edit?usp=sharing I tweaked the thermalMassModifier for flat panels ( = 15) and the emissiveConstant for the flat panels and radial/inline convective radiators ( = 1.0). I've left the deployable radiators at emissivity 1.6 with the idea that they have higher effective surface area for radiation without having to worry about absorbing too much solar input because they rotate out of the way.

Antilochus, Thanks for running this down. I'm having the same issue, even with small part-count craft. The slower rise in the first graph is where I paused the game. The second image is when I switched to the KSC, where the sawtooth was much slower. http://imgur.com/a/WePDj I have a large number of mods running in 64-bit Linux, with 5 GB of memory use for KSP. I'm trying to figure out how to force the framerate lower with the NVidia settings in Linux.

Basic.syntax, thanks for the link. I'm having the same issue and my log has entries like this: [EXC 10:08:06.907] NullReferenceException: Object reference not set to an instance of an object FerramAerospaceResearch.FARGUI.FARFlightGUI.FlightGUI.FixedUpdate () [EXC 10:08:06.932] NullReferenceException: Object reference not set to an instance of an object FerramAerospaceResearch.FARGUI.FARFlightGUI.FlightGUI.FixedUpdate () [EXC 10:08:06.957] NullReferenceException: Object reference not set to an instance of an object FerramAerospaceResearch.FARGUI.FARFlightGUI.FlightGUI.FixedUpdate () [EXC 10:08:06.976] NullReferenceException: Object reference not set to an instance of an object FerramAerospaceResearch.FARGUI.FARFlightGUI.FlightGUI.FixedUpdate () Then it switches to complaining about a different mod instead of FAR: [EXC 10:08:13.712] NullReferenceException: Object reference not set to an instance of an object Clouds.Clouds.Update () [EXC 10:08:13.713] NullReferenceException: Object reference not set to an instance of an object Clouds.Clouds.Update () I'll follow the other thread and post more there, if I can't find a solution in that thread.

Zuqq, I had the same issue with thermal turbojets. When I'd first build them in the SPH, the COT would be centered, but then the craft would yaw hard to one side or the other. Then when I went back to the SPH to see why, COT was no longer centered. For that one, I was using a separate fission reactor for each engine. I resolved the issue by giving up. Instead I went for a 2.5m reactor, a 2.5m hybrid turbojet, and generally just a lot more spaceplane than I wanted to build.

After I updated to KSP 0.21 and then replaced my old Kethane install with 0.7.4, I've been getting a strange issue where the kethane detectors can't find any electrical power. I've got plenty on-board my ship, but it still says insufficient power. Anyone have any ideas what is going wrong? Here is an example:

Negative, ghost rider. A *heading* of 90 degrees has always corresponded with an *inclination* of 0 degrees (more or less, depending on launch latitude). MechJeb has also always had this straight. Heading is "north, south, east, west," while inclination is "trajectory angle with respect to the equator."

Capitan: it's less tiring if you don't take the time to read it. I think the enthusiasm for this mod is fantastic. It's a great mod, and I'm looking forward to having the flexibility it offers. I think the fact that people are still posting questions, even if they can go back six pages to find the answer, is a great measure of fan interest. Yes, r4mon is working on it. (Thanks!) I'm still happy to let r4mon know I'm excited for it. My 0.20 mining bases aren't what they could be with this very useful addition.

Bob's Big Blob, SSTO. It started with a TWR of 0.97, and was up to 4.24 by the time it reached a 75 km orbit, with 2251 m/s delta-V left. There's nothing to do with it, but it sure is ... blobby.

He's the author on kerbal spaceport. My guess is: if he says he's working on it, and he's the author, he's probably the dude working on it. http://kerbalspaceprogram.com/damnedrobotics/