barfing_skull

I'm not using kOS...didn't know about that one. I looked it up and at first glance it seems like it might have some promise here, though I'm guessing there's at least some learning curve to it. I suppose being a software engineer I should at least understand the programming aspect, but how that works in the KSP environment and what it actually does to craft could be something interesting to explore. The rover is actually fairly flyable, with the Vertical Velocity mod which will use engine power to keep it at a preset distance above ground, and just SAS for decent but not great stability. Set VV to 1000 m above surface, it'll stay there as long as it's got enough power and the orientation of the thrust allows it. Obviously if the craft tilts in pitch or roll, that changes the thrust orientation, which can be useful in small amounts to move forward, back, sideways. But I'd like something that returns it to flat with zero pitch and roll for even finer grained control, and the ability to let it just cruise for a while without worrying about the roll or pitch going off level. The purpose of the craft is that I'm playing the Beyond Home planet pack, and Hydrus has a non-oxygen atmosphere, and floating islands (like on Pandora in Avatar) that I want to land on. So I'm working on this hovering rover using electric fans to get onto those. Thanks for the tips!

This *almost* works, the problem being that when I rotate (yaw) the craft more than 90 degrees it pitches over upside down in an attempt to point the nose in the original direction, which is not what I want. I need it to ignore which direction the nose is pointed in the horizontal plane.

So here's the craft in question below. I added the docking port on top as suggested, but it changes all the controls and the navball, since the control point is relative. The nav ball shows it pointing up, but the craft is not pointing up, it's pointing east. The control point needs to remain pointed forward/east to have the controls and navball act correctly, unless there's some way to change the nav/control not to follow the "control from here" part, but have MJ follow that new control point. I'm guessing that's not possible?

I've done similar things before with attaching a probe facing up, but in that instance the control point is facing upwards....which screws with the navball when you're trying to fly something in the same horizontal orientation of a plane. So maybe if there were a way to have the navball follow something other than the point of control. I'd have to experiment with that and research if there's some way to do it. The funny thing is that in concept what I want to do is really simple...and multiple mods don't really implement it that way.

Thanks, I looked at it a bit more carefully, still not quite what I want. I probably should have elaborated in that what I'm trying to fly is essentially a VTOL rover using lift fans, with a propulsive fan at the back for forward thrust. No wings. So, a helicopter, more or less. So the traditional spaceplane stuff doesn't really help, since it seems geared toward flying a fixed wing aircraft, and this isn't that. The roll component of MJ's Aircraft Autopilot is useful, but there's no way to zero the pitch. I've tried Kramax autopilot, too, but it has some odd side effects on this type of craft. Kramax has worked well for me in the past for fixed wing craft, but it's not quite the same with this. Tried Atmosphere Autopilot but that's way more complicated than what I'm looking for. I've got a mod for vertical control of the VTOL with an auto-height function that works well. Vertical Velocity Controller Redux. I just need a way to keep the VTOL flat, zero pitch, zero roll, for cruising. Obviously it's good to be able to turn that off and fly manually for landings using pitch/roll, but for longer flights keeping it flat and just letting Vertical Velocity keep it at a constant altitude above terrain is what I'm looking for.....so something more akin to Smart A.S.S. Except, that doesn't flip the craft over when I turn it around. Flying a VTOL upside down is what is often called "undesirable" unless you're practicing lithobraking. One would think this would be a simple, common thing to desire in attitude control, but a lot of these mods don't really seem to implement it quite that way. Cheers, and thanks!

[Moderator's note. This series of posts was originally split off from the MechJeb thread, since it's really more about "how to accomplish a thing" with various mods being discussed as possibilities, rather than being about MechJeb itself.] Hey all. I'm having a problem doing something that seems simple with Smart A.S.S. but yet the way to do it is eluding me. Essentially I want to keep my craft's roll and pitch at zero when it's in the air, regardless of which direction it's facing or moving. What I want is SURF-> Up (which does a pitch of 90 degrees) to have a pitch of 0 degrees, and complete freedom in the horizontal plane. I've tried ADV -> SURFACE_HORIZONTAL but it requires a horizontal reference which in my case is irrelevant, I want control over where it's pointing in the horizontal direction. I could probably do this by having a "control from here" part that's oriented vertically, but "forward" for this craft needs to be in the horizontal plane as it's designed for atmospheric flight. There's SURF -> SURF then check both PIT and ROL to 0, HDG unchecked. which works fine until I point the craft in another direction more than 90 degrees, at which point it flips it over on its back to point it in the original direction, which is definitely not what I'm looking for. The craft needs to stay horizontal relative to the ground regardless of the heading, not flip over front to back. Any hints on how I can achieve this? Cheers!

I think just switching to Parallax 1.0.1 did the trick. Figured I'd try one change at a time until it worked. Thanks!

I'm seeing the same thing. At closer than about 500m distance, the terrain goes black. Unfortunately, that's not a playable condition. In order to rule out mod conflicts, I started with a clean install and added just the Beyond Home necessities on top of stock 1.12.2 + expansions. Disappearing terrain still happens. Parallax is 1.3.1. I'd like to know if there's something I can do with this version of KSP to fix this as well.

I'd only seen it on re-entry before, but a launchpad test produced the same problem when I hooked up the drive section with the nuclear salt water engine and the radiators to something that would at least launch. I found a lot of these in the KSP.log at the time this was happening: [EXC 09:38:11.820] NullReferenceException UnityEngine.Renderer.get_material () (at <7d9ec060e791409ab3eb85c61e312ed6>:0) SystemHeat.ModuleSystemHeatColorAnimator.Update () (at <c7392b4010df46a7af1d4bc1aaa6002c>:0) [EXC 09:38:12.235] NullReferenceException UnityEngine.Renderer.get_material () (at <7d9ec060e791409ab3eb85c61e312ed6>:0) SystemHeat.ModuleSystemHeatColorAnimator.Update () (at <c7392b4010df46a7af1d4bc1aaa6002c>:0) [EXC 09:38:12.650] NullReferenceException UnityEngine.Renderer.get_material () (at <7d9ec060e791409ab3eb85c61e312ed6>:0) SystemHeat.ModuleSystemHeatColorAnimator.Update () (at <c7392b4010df46a7af1d4bc1aaa6002c>:0) [EXC 09:38:13.067] NullReferenceException UnityEngine.Renderer.get_material () (at <7d9ec060e791409ab3eb85c61e312ed6>:0) SystemHeat.ModuleSystemHeatColorAnimator.Update () (at <c7392b4010df46a7af1d4bc1aaa6002c>:0) As an aside, I'm on 1.11.1, Linux, with a bunch of other mods as well. Cheers!

So I'm having a problem with the XR-500 and XR-600 radiators, namely, that when they break off in the atmosphere it completely brings the game to a standstill, and I'm getting about 1 frame per 4 seconds. I have a fairly beefy setup. I put these on sacrificial stages, or I de-orbit the vessels, but as soon as they blow off the vessel, performance drops to where the game is unusable. I'm going to take a guess in that this results from the game needing to handle the physics and aerodynamics of the 8 billion little pieces that come off as they disintegrate. The particular stage I'm using has 8 XR-500's and the same number of XR-600's. Is there any way to have these parts meet their aerodynamic demise with more grace? Could they break off in one part? They're just flotsam at that point anyway. Cheers!

Well, starting from scratch, adding RSS, then my other mods, seems to have solved the immediate problem and it works well with fast FPS and looks fantastic. Although I'm still getting the popup about no RSS textures installed, even though they are. I'd love to have clouds and the like, but from reading back, the only thing I see is RSSVE as an add-on to EVE, and that no longer works from what I read? Are there any other visual enhancements for clouds or the like that work with the current RSS? I have scatterer and EVE there, but I think they'd need configs for RSS. Cheers, -BS

Yeah, from a few posts above it was noted that it should work with 1.11. I'm not seeing any actual problems other than the huge FPS drop. I actually added RSS to an existing installation with other mods already in place. Again, no problems with that other than the expected odd placement and disappearance of vessels when their planetary bodies are moved or no longer exist. I think a lander I had on Mun ended up on Titan, presumably because the configs just renamed it. Perhaps I should start with a fresh install and add mods from there. I don't care about my savegame much, but I do want to copy over some of my craft. The 8192 textures look fantastic. 4096 are good, but it's a huge improvement to 8k. Mostly I'm wondering what kind of graphics settings seem to work for people. Again, one other thing I could try is run the game at HD res, but I have a good video card and a 4k monitor for a reason...but there are at least a couple things here I can work on.

So this is one of those mods I've known about for some time and finally wanted to get around to trying it. The installation seems like it worked properly, although it gives me a popup about not having textures installed. They are installed under GameData/RSS-Textures, right where the documentation says they should go, and the textures look like they're present in-game, from what little I've looked at it. So any idea why the warning for no textures? But my big problem is a huge drop in FPS when entering any flight scene with physics, to the point of being unplayable. With the stock planetary system, my FPS was fine. I tried both the 8192 and 4096 textures, as my machine is fairly beefy. Both had about the same amount of FPS problem. Tracking station and map views were lightning fast. RSS 18.3 KSP 1.11.0 (Linux) KopernicusBE_1.11.0_Release67 My machine is an i9-9900k, 32G RAM, RTX 2080. I play the game at 4k res. Any idea if some kind of setting might be causing this? Anything I could tweak or change? What are reasonable graphics settings, if it is actually graphics rather than physics, for the above? I know CPU can be a bottleneck, too. If it's the physics, what's different about them in this mod? Cheers, -BS

Found this mod while looking for planet packs and from the descriptions and from what I was able to try of it, it looks really cool and really promising. However, while I can see the new planets in the tracking station, they appear pink/purple when on the surface. I can think of two reasons for this, one, that I'm on KSP 1.11 or two, that I'm on Linux. I suspect it's the latter. I got the version of Kopernicus (build 58 I think) that was compiled for 1.11. Everything seems to work except for the planet surfaces, and it gives me errors about BeyondHome and Parallax not being installed upon game startup. I have Parallax 1.0.1 as the documentation states. Reading through this and the Parallax forum, does this sound like a synopsis of the state of affairs? 1. Parallax only currently runs on Windows machines. I think this is because of a DirectX 11 dependency. I saw mention of working being done on this, but also that you lacked a Linux dev machine? Parallax is what gives the terrain detail, and makes things look really cool, from what I gather. 2. There is an effort to decouple BeyondHome from Parallax, and that would make it work as a standalone planet pack. However, this would ditch a lot of the cool graphics, right? So, if 1. were to come to fruition on Linux, it would have the same eye candy as intended. This is obviously the best outcome. 2. would result in a playable planet pack but without some of the graphics that seem like they make it more special. So is that pretty much the state of affairs? Cheers!

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