Kerbocracy

@GameslinxAlso wondering if an update to BH is in the works or if 1.5.2 will be the final; thinking about a new run. Cheers!

I had a similar issue - see a few posts back. It was because I was using the latest parallax. Gameslinx advised me to roll back to parallax 1.0.1 until BH gets updated, and this fixed it for me. edit- whoops saw folks answered this; my browser hadn’t updated the forum:s

Anybody having issues with BH since the Parallax update? CKAN updated me to 1.1.1 and 1.1.1b and in both cases I have KSP looking like this: https://imgur.com/a/Vn71RlJ Prior to the Parallax update i had terrain texture. I checked fury and it has the same 'missing' terrain contour. Perhaps @Gameslinxis presently revising BH and I should be patient...:)

I was going to ask if that ‘liquid’ tesselation was normal/expected. It’s a bit strange but the overall look is so good I can accept it I think. There’s also some apparent draw radius 50m or so out from the camera that looks like a blast effect when you are landing but it’s actually the tesselation drawing in I think.

I’ve been using rescale 3.5x @Morphisorconfig and have noticed that certain interesting objects Are not landeable- they don’t seem to have hitboxes and my craft/kerbal fall through them. I’m suspecting an issue BH I’m the context of rescale because Anyone else have this issue and/or fix?

For those of you using Beyond Home with Sigma Dimensions / Rescale, perhaps you can help me with the following issue: I've been using @Morphisor's rescale config (3.5x) and I found that the ground scatter - particularly the trees - were unnaturally huge. I found that in the rescale config when I set "resizeScatter = 0" it brings the trees back to normalish scale. However, when visiting a nearby celestial body, I found some interesting things that seemed to be bigger than they should be: My sense is that these were intended to be 3.5x smaller; if so there might not be the harsh clipping that is evident. Are any of you having this issue and/or have found a fix? Is it possible that these scatter objects do not use the same size variable as the trees/rocks etc? The other possibility is that this was just an unlucky random scatter placement that put them too close so they clipped. But I wonder if these are appearing as 'intended'. Also, they don't seem to have hit-boxes; my craft & kerbals pass through them. I was under the impression that certain BH scatter objects of great interest can be landed on. Any thoughts on these issues? Thanks!

Currently using it for 1.10.1 and it seems to work but having read the last few pages I expect some things could be borked. I currently have remotetech and NF installed and stuff -seems- ok. However thinking back I had at least one instance of an unlocked part not appearing available in VAB. So it probably needs an update... the part progression seems really nice though. I love starting unmanned with remotetech!

@lemon cup thanks - yes those pics were rhode. What’s your landscape setting for sigma? Also I looked at scatterer settings but saw so many and tweaked a few - couldn’t seem to adjust the haze. Am I missing an obvious setting for atmosphere thickness? Thx. Also will check into TUFX. Cheers.

@lemon cup I’m also amazed by how awesome this mod + parallax is and am loving the 3.5 scale; I echo your praise! One thing I wondered looking at your screencaps - are you using scatterer? I am finding that my atmospheres (both rhode and lua) look very white/hazy such that the terrain from orbit is not as clearly visible. I have some pics here showing a different issue but you will see the haziness: https://m.imgur.com/a/KEpdlu0 https://m.imgur.com/a/AX3V68L is this how yours appears on ascent? I’m wondering if this is the intended appearance of these bodies/atmospheres or if I am having a graphical issue. I wonder about scatterer configs..

Ok I'll look into that and thanks for the quick reply. For your install, do some of the terrain scatters appear to not dim/lower contrast with distance? I'm noticing on Rhode that some of the tall trees (Eucalyptus like ones) are dark at maximum draw range, while the cactuses and the purple flowers appear to dim/lower contrast with range. I think maybe the contrast dimming on terrain scatter is also driven by scatterer? Just wondering if everyone else is having this issue. Cheers. https://imgur.com/a/83WqPrz

Wow great find! This indeed worked for me and the surface is Lua is now _much_ more firm. I still have a remaining issue that I wonder if you have or have had. It is related to the black lines/jaggies seen on the horizon - usually during ascent. I think it might be related to a scatterer config or something or maybe EVE: https://imgur.com/a/AX3V68L Those thin black lines, which seem to be the edges of terrain features, are seen to dance around on ascent and it is distracting. Without Sigma/Rescale this is either not present or so slight it is unnoticeable. I found that it reduces when I jack up the AA, and is least noticeable at 8x AA, but this screencap is from 8x AA. I also notice that some terrain features appear black on the horizon - larger hills appear as black triangles/polygons - not sure if this is related to the above 'jaggies' issue but seems like maybe: https://imgur.com/a/KEpdlu0 Have you encountered this? Note that I"m using Morphisor's Rescale 3.5x BH config rather than regular Rescale 3.5x. Thanks in advance for any help! My mod list again for ref:

I'm having a similar issue using Sigma Dimensions / Rescale 3.5 (Morphisor config posted above). On descent to Lua I get some land flickering in and out showing the ocean below (don't know why imgur link won't draw here): https://imgur.com/a/ZPuv9go and then I fall through the ground: https://imgur.com/a/sTwrYju I'm using several mods but nothing that I think would cause this: EDIT: I removed sigma and rescale, and the terrain issues have gone away - it looks and behaves beautifully. I also noticed that some black polygons/jaggies on the horizon have gone away. So I think the Sigma/Rescale was the cause of the problem. Too bad because I agree that Rhode is a bit to easy to get into orbit. Perhaps though the challenges lie elsewhere in the solar system...

Ok - that worked. I added the missing guy back to the roster according to the example and it the game seems back to normal. Thanks, but wow this bug needs to be fixed in a patch!

I've lost my second career to this bug. It appeared after about 20 missions. I entered the VAB and the UI stopped working. Come to think of it, I had just lost a kerbal in an accident and this had also just happened when I had my first career corrupted in this way. I play Dead-Is-Dead on Hard, so losing kerbals is an inevitable part of the process. I killed the process and then restarted the game and reloaded the save. It let me enter the contract building, and indeed as Driveness said above, my Active Contracts was shown as 99 [Max: 00]. When I click the exit button, the bottom bar for the space center screen appears (contract menu still there though) and the exit button in the bottom right actually brings up the menu, but the menu doesn't work properly - i can't exit to main menu and have to kill the process. Unfortunately I have now sunk like 20 hours into two careers that have been corrupted by this bug. I'm really discouraged - because this game on career (especially on hard mode) requires such a massive time investment to make progress, save corruption is that much more of a burn. I don't want to invest any more time on this game until this bug is fixed. I will send in my persistent and log files if that helps - can I email them somewhere? Please advise on a method for this.

I just encountered this problem. Running unmodded 0.90.0.705 beta on Windows 8.1. Played a save yesterday and today; ran a few missions. After running a mission today I returned to the VAB and discovered I couldn't exit it - the exit button clicks but doesn't do anything. Also couldn't exit to main menu. Killed the process and reloaded the game. Wasn't able to enter the tracking station... Tried to exit to main menu and the button clicks but doesn't do anything. The UI seems corrupt for this save. I've played the previous versions of KSP and have never encountered such an issue.

i wonder if the thermometer instrument gives different readings depending on light exposure...

I work it out such that my spent stages either fall back to Kerbin or else go on a Kerbin exit trajectory. If you dump stuff into Kerbol orbit you won't encounter it again. Even if you wanted to it would be hard.

Nineteen asparagused mainsails that separate in pairs. I've used this to lift a fuel node composed of 4 orange tanks with two RCS nodes into LKO. In this pic it's attached to a smaller fuel node. The central orange tank in the lifter can act as a dockable tug if it has remaining fuel; or else it just disposes of itself in the ATMO when payload is delivered.

I try to keep mine under 1000. Around 1000 the launch is laggy and I can't time my asparagus releases well. I like to release them just at the point that they run out of fuel, so that they don't jerk the whole structure down when they stop, and also so that they don't leap forward when they release with a bit left. Around 1000, things start to get unmanageably laggy. I've also been getting some VAB infinite hangs with part counts around 1000 (where I have to kill the program). This has prompted me to try to reduce my count overall (I'm currently rebuilding my heavy lifter to minimize parts).

Ok I totally neglected this. Thank you.

I was wondering - with my spaceplane, after I'm done running my jet engines (at say 17km altitude, 750m/s), I engage my rocket and go into orbit. When I'm orbiting, I realize that the jet engine fuel tanks are carrying a lot of oxidizer. I'm guessing that this is because they don't use it when burning in the atmo. So essentially it's a waste because my rocket engine has the right fuel/oxidizer ratio in its own tank. Is there any way to a) bring less oxidizer so that when my jets are done burning there is no extra weight in oxidizer going into orbit or dump the oxidizer at that point? It seems like a waste to dump it; I could have carried extra jet fuel instead of oxidizer for the jet engines. It sounds like we might need a jet engine fuel tank that only carries fuel and no oxidizer...

thanks buddy; I'm asking because a) I'm too lazy to do it myself and I assume that with all nerd wisdom available here, someone will have tried it. The good thing about sharing knowledge in writing is that everybody doesn't have to redo every science experiment from scratch.

Thanks for the replies. Struts really have zero mass? I feel like adding struts changed my dV... Have to check again. If struts are free, then I'm going big on them. Also good that the mass goes with the decoupled piece. But for probe (stack?) decouplers, I think the body of the decoupler (at least graphic) stays with the part that is at the base of the arrow - I point the arrow towards the probe/engine, and that part detaches cleanly, seaming to leave the rest of the decoupler with the parent. But maybe the mass goes with the probe anyway despite the graphic?

Thanks for the replies guys; it makes sense. I see that my dV on Eve is the same, but that the gravity well is deeper and steeper, so I spend the dV of my rocket and only get part way to escape compared to on Kerbin. In addition to the gravity well being deeper and steeper on Eve vs. Kerbin, the negative acceleration due to gravity following lift off is eating into my total dV, and worse so on Eve than Kerbin, correct? That is, immediately following lift off, on Kerbin I'm losing 9.8 m/s just hovering, and on Eve I'm losing 16.7 m/s doing same. So I'm getting the sense that deltaV as it is expressed in Engineer Redux is like 'total delta V in a vaccuum', and I'm more concerned with something like 'effective delta-V' which is the amount a rocket system can actually change it's velocity on a given body and with a given ascent profile and subtracting gravity effects, drag, etc.... Perhaps harder to estimate. On the Wiki when it say that you need 12.5km/s to orbit Eve from sea level, is this in total deltaV in a vaccuum or is it in effective deltaV? I worry that I might need much more than 12.5km/s... Right now my system has about 10.5km/s and 100,000kg. Don't want to go much heavier... Also, I'm probably getting a bit confused because I was trying to estimate a rocket's effective dV empirically by taking off from kerbin, straight up, and seeing what my velocity above the navball reads when I'm out of fuel. My 10.5km/s rocket was finished at about 8.8km/s navball reading. Is that a good measure of effective dV (e.g. total - drag/gravity from kerbin)?