mszegedy

1.8.1, or 1.8.0? And what versions do you recommend for its dependencies? (Aside from Parallax, which I'm 96% sure has to be 1.0.1.)

No, I "solved" it by switching to Windows. I'm still not sure where the pink comes from. It must be something at the driver level. I don't think I tried it with both Nvidia's driver and Nouveau, just the Nvidia one. But I'm not optimistic.

It's worth noting that not everyone's ground turns the same color when that happens. The most common color people complain about is white. Black is kind of rare but I'm pretty sure this isn't the first person to complain about black. As far as I know, I'm the only one to complain about magenta. (I have made sure I'm using the right version of Parallax.)

I think something weird was going on. My CKAN says that the most recent Kopernicus is still revision 38, which came out over a month ago.

Oh, that's unfortunate. If I had the energy and patience, I'd look for a minimal example, but I don't. I guess it'll have to remain a mystery for the time being.

Yeah, it turns out I didn't fix it after all. The good news is that I have narrowed down the steps to reproduce: Enter the VAB. Load a vessel, or create a root part. (This step is unnecessary if the editor has already automatically loaded a vessel.) Pick up a part from the parts pane. Drop it somewhere other than on your vessel (so that it turns red and translucent). FAR will say in the log that the part has a mesh size of 0, and start spitting out these errors. @dkavolis, sorry for the ping, but I believe me and Grimmas have put together a complete bug report here. I think you have all the resources necessary now to fix the problem. Grimmas, since you have a fork of it, do you wanna just patch it yourself and submit it as a pull request? I'm an outsider here and I can't tell what your level of involvement is on the project (for all I know, you're the primary maintainer), but that's what I'd do in your position if I were a random user who actually understood the codebase.

Whenever FAR recalculates voxels in the editor (so, whenever I mouse over a part in the parts pane with any volume, or whenever I add a part to the craft), I get a KeyNotFoundException: The given key was not present in the dictionary error, which makes the editor stutter for almost a whole second, every time. This is hard to bear. Unfortunately, I'm a little out of energy to debug stuff, because I've been debugging an unrelated bug in another mod, but in any case, here's a sample log (the error can be found at the very end, repeated a hundred or more times). I can provide more details if needed. edit: It only seems to happen if "Allow higher-res subvoxels" is active, thankfully. I've unchecked it and I'm much, much happier now.

Oh, thanks, I didn't catch that. I guess between wipes, I must have wiped the custom CKAN boot command that boots it with access to the dedicated GPU. It doesn't change anything when I use the correct command, but it does change the BICH output a bit, insofar as I now meet the VRAM requirement: It's kind of concerning that it thinks Beyond Home isn't installed. Maybe it's something about the order of how the modules/patches are run. I'll try to figure out what that means. edit: Apparently it means that it can't find BeyondHome/BeyondHome_LICENSE.txt. But it's right there… I will see how this could possibly happen. I may recompile the installation checker from source, though I'm not used to compiling C# on Linux (or anywhere else), so I may botch it. edit 2: Oh, it thinks the game data directory is steamapps/common/Kerbal Space ProgGameData/. What the…? Oh, looking at the source, it specifically removes the last 12 characters of the path it gets, when it should be removing only 8. Weird. I'll try compiling my own BICH that uses the correct path, and see what it outputs. (edit: Ugh, it needs UnityEngine linked into it. Never mind.) edit 3: I've tried tweaking BeyondHome/Configs/Rhode.cfg (because Rhode's immediately visible upon loading a save) in a number of ways, such as figuring out how much I could delete before it stops being magenta (answer: it's magenta no matter what I do, unless I do something that makes it so that it can't be loaded in the first place), and seeing if changing the order/priority of the surface textures under Body.PQS.Material does anything (it doesn't). I've also looked through the Parallax source code for clues, but reading is very hard for me these days and I wasn't able to get very far. I haven't been able to get a Unity-linked compiler up and running on my Linux anyway, and it looks like I'd also need to figure out how to link in the Kopernicus code as well (though that shouldn't be hard). I'm giving up for now. Ironically, now I'm out of energy to try to move this install to my Windows partition.

(I am still having this problem. I am sorry for spamming but I don't have much else to do with my life anymore and I want to be able to get at least partways through this mod before I die. If this is breaking etiquette, I won't do it again, I'm just scared of it going unanswered for an indefinite amount of time. Though, presumably Gameslinx will eventually release the version of it that relies on the newer versions of Parallax, and that'll solve my issue as a side effect. But that might be many months away still, for all I know. Sorry again.) edit: Also, I have re-tested this on both 10.1 and 11.2 with nothing but Beyond Home and its dependencies installed. (I wasn't sure whether scatterer should count as a dependency, since this page doesn't list it as a dependency but CKAN does, so I tried it both with and without.) It didn't change the result at all. I made sure that the versions were correct beforehand: BH 1.5.2, Parallax 1.0.1, Kop 38. (The scatterer and ModuleManager were just whatever CKAN installed.) Here is a log from 1.10.1 with nothing but BH and its dependencies, not including scatterer. edit 2: Though somehow it fixed the issue I was having with the sunflares not appearing. Uninstalling scatterer completely may have done it.

here's the output of neofetch: the command i use to run ksp is prime-run ./KSP.x86_64. the demo utilities glxinfo, glxgears, and vkcube run fine with prime-run, so i don't think it's on the level of my gpu or my drivers.

I have recently installed Beyond Home. Unfortunately, Parallax can't load the planet textures, and they are completely magenta (or more accurately bubblegum pink). I tried many version combinations; my latest combination is Parallax 1.0.1 and Beyond Home 1.5.2 installed by hand, and everything else, including Kopernicus release 38, installed through CKAN. This seems to be identical to what CKAN installed, however. Additionally, I can't get Parallax to stop z-fighting scatterer. I'd uninstall scatterer, but CKAN lists its sunflare as a dependency to Beyond Home, so just to be safe, I'm not uninstalling it. My KSP.log is here. The relevant lines seem to be: An example of my problem is here: edit: I have tested this with both PlanetShine and scatterer uninstalled (both individually and together). It doesn't fix anything, except that uninstalling scatterer stops the z-fighting artifacts (duh). Meanwhile, I've also noticed that only Kerbol has a sunflare with scatterer; Destiny and Fate don't have so much as a shine. I assume this could be fixed just by installing the correct scatterer config. I don't think I noticed a link to one, though.

Thank you for your work on decoding the format. My genetic algorithm will be much easier to write now. One noteâ€â€I still can't figure out what sidx does. You said it's the symmetry index, and it makes sense, except for the fact that it seems to be assigned nearly at random. When I created a craft, the root part had sidx=-1, as well as the parts under it. The parts radially attached to it, in symmetry, have sidx=0. Then the parts radially attached to those have sidx=-1. If you radially attach a part to those, then sidx=0. If you radially attach a part to those, but without symmetry, then they'll have sidx=-1. If you radially attach parts to that with symmetry, then they'll have sidx=1. What? How does this work?