barfing_skull

I think this is the thread already, looks like the same issue I saw: https://github.com/KSP-CKAN/CKAN/issues/2481 I'll see if I can add any relevant details since it looks like the initial report was OSX.

(Sort of) answered my own question. Looks like installing the .deb works, and CKAN launches. I had downloaded just the .exe which worked in the past. I think originally while I was futzing around with trying to get the newer version of Mono to work, I abandoned the .deb. So I'm not sure why it didn't work from the 'mono ckan.exe' command line, but at least the .deb seems to work. Thanks! I have no idea if this is specific to the new version, as I haven't fired up CKAN or KSP for quite some time....but I'm unable to get the version I just downloaded to run with mono on Linux Mint 18.3. I did manage to get my Mono version updated to 5.12. Here's what happens: $ mono ckan.exe exception inside UnhandledException handler: Object reference not set to an instance of an object [ERROR] FATAL UNHANDLED EXCEPTION: System.NullReferenceException: Object reference not set to an instance of an object at CKAN.GUIUser.DisplayMessage (System.String message, System.Object[] args) [0x00000] in <352d74f237564d2e9ff313cc9ac1989e>:0 at CKAN.NullUser.RaiseMessage (System.String message, System.Object[] args) [0x00000] in <352d74f237564d2e9ff313cc9ac1989e>:0 at CKAN.KSP.SetupCkanDirectories () [0x000dd] in <352d74f237564d2e9ff313cc9ac1989e>:0 at CKAN.KSP..ctor (System.String gameDir, System.String name, CKAN.IUser user) [0x00038] in <352d74f237564d2e9ff313cc9ac1989e>:0 at CKAN.KSPManager.LoadInstancesFromRegistry () [0x00060] in <352d74f237564d2e9ff313cc9ac1989e>:0 at CKAN.KSPManager..ctor (CKAN.IUser user, CKAN.IWin32Registry win32_registry) [0x00028] in <352d74f237564d2e9ff313cc9ac1989e>:0 at CKAN.Main..ctor (System.String[] cmdlineArgs, CKAN.KSPManager mgr, CKAN.GUIUser user, System.Boolean showConsole) [0x00039] in <352d74f237564d2e9ff313cc9ac1989e>:0 at (wrapper remoting-invoke-with-check) CKAN.Main..ctor(string[],CKAN.KSPManager,CKAN.GUIUser,bool) at CKAN.GUI.Main_ (System.String[] args, CKAN.KSPManager manager, System.Boolean showConsole) [0x0003b] in <352d74f237564d2e9ff313cc9ac1989e>:0 at CKAN.CmdLine.MainClass.Gui (CKAN.KSPManager manager, CKAN.CmdLine.GuiOptions options, System.String[] args) [0x00008] in <352d74f237564d2e9ff313cc9ac1989e>:0 at CKAN.CmdLine.MainClass.Main (System.String[] args) [0x000a1] in <352d74f237564d2e9ff313cc9ac1989e>:0 Any ideas about what's going on here? Cheers, -BS

So I've been trying this out with 1.3, mostly to see how it's working there. I loved the mod with 1.2.x and I've just started trying to play again after a hiatus, so wanted to go with 1.3. I realize the mod likely isn't stable or completely ready yet. So far my attempts have left me at the spinning Loading... graphic indefinitely after trying to load a save or start a new game. The log has an endless stream of these types of errors: [EXC 11:25:55.204] NullReferenceException: Object reference not set to an instance of an object Kopernicus.Components.KopernicusStar.LateUpdate () [EXC 11:25:55.221] NullReferenceException: Object reference not set to an instance of an object Kopernicus.StarLightSwitcher.Update () [EXC 11:25:55.221] NullReferenceException: Object reference not set to an instance of an object GalaxyCubeControl.Update () [EXC 11:25:55.221] NullReferenceException: Object reference not set to an instance of an object Kopernicus.Components.KopernicusStar.LateUpdate () [EXC 11:25:55.236] NullReferenceException: Object reference not set to an instance of an object Kopernicus.StarLightSwitcher.Update () I'm on Linux. Kopernicus and GPP are the only mods installed. I didn't see any previous posts with this kind of error, is there something else I should look at? Cheers, -BS

Greeting! I upgraded to 1.12.12 from 1.12.11 on CKAN. However, it appears my graphene radiators on existing vessels have stopped cooling NearFuture reactors. I haven't tried this on other parts, so I don't know if it's a cross-mod thing or if the config for the graphene radiators is having problems everywhere. I downgraded to 1.12.11 and low and behold, the radiators cool my reactors again. No other changes to other mods, so I'm pretty sure this is the culprit. I did a diff and the only significant thing I can find for the radiators was this in the config, something similar for most of the radiators: 18c18 < title = Graphene Radiator Folding Medium --- > title = Graphite Radiator Folding Medium 83d82 < areaMultiplierAtmosphere = 1 The "areaMultiplerAtmosphere" is new, so I'm guessing that's causing the problem. My vessels were not in any atmosphere. Thoughts, or am I off base here? Cheers, -BS

Greeting. Maybe I'm missing something here, but extra cooling I try and add to the Rontgen doesn't seem to actually be cooling it. I have NFE installed, so it's configured for that. I put a couple of extra stock radiators on there - attached directly to the Rontgen, but it doesn't cool down any faster than it does when the radiators are shut off. Unless I have the engine going, it doesn't seem to cool much at all when the reactor is at 100, and even then, it's insufficient. How do I cool this thing off more quickly? Obviously since it's in-atmosphere, any deployable radiator won't work. I don't know of any other mods for the current KSP version that provide better radiators. Maybe KSPI-E, but that's way more complicated than I want to deal with. Also, it doesn't seem to be producing any electric charge. Thoughts? Cheers, -BS

Yeah, it was a case of too many variables at once to pin down what was going on. My general approach to planet packs has been to load them, and go to the tracking station to see if I can see all the added bodies. I'd seen similar behaviour before in thick atmospheres, but didn't think to look for a rogue, invisible parachute. It was the RealChute mod that changed the stock parachute configuration, and must have broken it for at least the Mk16. As an aside, I noticed your initial post in this topic mentioned stripey planets with Linux/Mac. I do not have that problem out of the box with GPP. However, I've encountered this with other planet mods, it's generally that OpenGL and .dds files don't always play well together. I think using just .png for textures makes it the most portable. I ended up going back and writing a script that converts all the DDS to PNG (using ImageMagick) then edits the configs as well, and that fixed a planet pack or two for me. Cheers, -BS

Gah, I think your mod is fine, after doing a bit more research I'm pretty sure it's not the atmosphere, but a problem with a part. After enabling the aerodynamic overlay, the Mk16 parachute is acting as if it's open at launch. This both explains the slowness, and a propensity to immediately tip over. When I remove the parachute from the vessel, it flies about according to expectations. There's no animation or graphical manifestation of it being open at launch, but the aerodynamic overlay clearly shows a huge drag coming right from the tip of the vessel. I have a ton of part packs, but that's a stock part. Hmmm.... Cheers, -BS

Greetings, and thanks for this mod. Playing with the same planetary bodies over and over again makes the game a bit stale. Perhaps this has been asked before, but what exactly changed about Gael's atmosphere? I read on the wiki that it might not behave like stock, but this seems radically different. Vessels that would have no trouble making it to orbit in stock barely make it to 15km, and often then they flip over much more easily. Gravity lists as the same in the stats. The atmospheric stats don't seem all that much different, the scale height is slightly higher... So I'm wondering if there's some explanations out there, or pointers on how to actually get something to orbit. Or is there something else that might be going on? Cheers, -BS

Cool, I installed this and it's mostly what I've been looking for. However, as mentioned previously, it probably should be modular and read the parameters dynamically, so new planet packs don't require any modification or manual editing. I know they're there in the config files for each body. You mentioned module manager earlier. Might Kopernicus have something like this as well, hooks into planet parameters? Maybe a way to render the planet the same way the game does for the graphic of each, but I think that's less important than getting the characteristics? Seems like there should be some library to read the params rather than picking through the config files yourself. I know a more than a bit about development, but I work mostly in Java or Linux-related stuff. Not so much with Windows / C#. But I could possibly poke around the source code to see if anything looks promising, if you have a way to plug that into your current Wiki. Cheers, -BS

Went back a few pages, sorry if this has been addressed. Only mention I saw was changing the config to make the top speed a lot faster. I'm trying this with Extrasolar Planets Beyond Kerbol. Thing is, if I'm counting correctly, Valentine is 1.05 ly away. At the max speed of 40c, that means running the game for 9-10 days while it gets there (remembering to refuel with exotic matter every now and then). I also think it was mentioned that you can't keep the FTL velocity going during time warp and while the ship is not loaded. Is this correct? I actually tried warping while the ship was loaded, and it just exploded when I left warp. How is this usually solved? Cheers, -BS

Ah, so if it weren't for the memory thing, it would almost make sense to go with PNG as a best practice in planet packs, given both the Mac/Linux and dx11 proclivities for choking on dds. Memory was never a problem for me, I'd start becoming concerned at about 20-24GB of usage for the game. I do wonder if there's some other way to package the mods so that they're platform agnostic? Oh, the Perl script calls sed to modify the .cfg files. It would have taken a lot more work to actually use the file I/O in Perl when you can just launch a system command from the script to do the same thing. Perl is mostly useful for generating and manipulating the filenames to convert from/to, and for using similar information to feed to sed in order to modify the configs. This is meant to be run under the OPM directory before it's copied to KSP's GameData folder. Yeah, it's inefficient as it searches every config for each string to replace, but that's not the bulk of the processing. I mainly just wanted to get the mod to work correctly, it could certainly be more thorough and a bit more elegant. It's specific to OPM but would probably work with a slight bit of modification for other mods that are only distributed with dds. #!/usr/bin/perl my @ddsfiles = `find CTTP OPM -name "*color.dds" -o -name "*normal.dds"`; my @configs = `find CTTP OPM -name "*.cfg"`; ## backup existing config files foreach my $config (@configs) { chomp $config; print "Backing up $config to $config.bak\n"; system "cp $config $config.bak"; } foreach my $ddsfile (@ddsfiles) { chomp $ddsfile; (my $pngfile = $ddsfile) =~ s/\.[^.]+$//; $pngfile .= ".png"; print "Converting $ddsfile \>\> $pngfile\n"; system "convert $ddsfile $pngfile"; my @fileparts = split '/', $ddsfile; my $replacestr = $fileparts[$#fileparts]; my @newparts = split '/', $pngfile; my $newstr = $newparts[$#newparts]; print "Replace $replacestr WITH $newstr in *.cfg\n"; foreach my $config (@configs) { chomp $config; # print "Executing 'sed -i s/$replacestr/$newstr/g $config'\n"; system "sed -i s/$replacestr/$newstr/g $config"; } } Cheers, -BS

Ah, so it is. Needed HyperEdit to test things out. Looks like just going back to the Tracking Station and reloading the craft does the trick. I did end up writing a short Perl script do make the changes, along with the ImageMagick 'convert' utility. My Perl is rusty. Dunno if this would be useful overall, or if planet packs might have or include a Linux/Mac friendly version that uses png instead of dds? Any idea what the impetus behind using dds in the first place is? Cheers, -BS

This actually worked pretty well, I scripted all the conversion and replacing strings in the .cfg files. Things are definitely better, they look perfect from orbit and right on the ground, however, there's one glitch.... The height maps for OPM wouldn't convert. Normal and color worked fine. convert.im6: image type not supported `./GameData/OPM/KopernicusConfigs/UrlumMoons/PluginData/Polta_height.dds' @ error/dds.c/ReadDDSImage/346. convert.im6: no images defined `./GameData/OPM/KopernicusConfigs/UrlumMoons/PluginData/Polta_height.png' @ error/convert.c/ConvertImageCommand/3044. I'm guessing the height maps are in some format that convert doesn't understand, might be a deprecated DDS format. What did you use to convert the height maps? Would that cause the mid-altitude issues like the below? Cheers, -BS

Hmmm....sounds like a job for a shell or Perl script or something. ImageMagick will apparently do the conversion on the command line. If there's not something like that out there, I might look at creating one. Cheers, -BS

Hi all, I'm still having that problem with barred textures with some planet packs. Outer Planets has it, but Extrasolar Planets does not. EDIT: Just a note that things seemed to work fine up through 1.1.2 (OPM was fine), but broke in 1.1.3 and now 1.2. Linux Mint 17.1, KSP 1.2. I remember hearing it might be something with the graphics drivers, and not sure if this is a common issue? I had to set "useOnDemand = false" to get some celestial bodies to show up at all, in both mods. I'm wondering if it's a PNG vs. DDS thing? Both mods have files of both types, but I'm not exactly sure how they're being used in each case. Not sure if it would help to try and convert the .dds to .png, though I wouldn't know how to tell the mod to use the converted png instead. There are some [WRN] in the logs, that only look mildly suspicious, as they happen for both bodies with the issue and those without. I know debugging issues like this can be difficult when developers don't have the same environment to reproduce the issues, so if there's anything else I could try/provide that might be helpful, I'd be happy to do so. Any other ideas? Thanks again for the time and effort put into these mods. Cheers, -BS