[1.9.1 - 1.10.x] Beyond Home 1.5.0 (Supports Parallax)

[BlackEyedPhantom]

15 hours ago, Dunbaratu said:

I have almost the same problem, but for me it happens right away, at Rhode, near the start of the game.

KSP 1.10.1.

BeyondHome 1.4.0, installed via CKAN, telling CKAN to only grab KSP 1.10.x compatible versions of things.

And yes, I have terrain detail on high.

Here's two screenshots:

https://imgur.com/a/BWBGO83

Yup same problem! I also have everything on max but yea... Well the best fix so far i found is quicksave and load. I guess we will hope for @Gameslinx to update asap!

[Dunbaratu]

1 hour ago, BlackEyedPhantom said:

Yup same problem! I also have everything on max but yea... Well the best fix so far i found is quicksave and load. I guess we will hope for @Gameslinx to update asap!

At any rate it can kind of be a problem with using airplanes because the midair trees often get in the way of takeoffs and landings (i.e. a levitating group of trees 50 meters in the air at the end of the runway).  Also, when I have this problem it sometimes spawn trees right IN the runway.  Even when the trees are on the ground, they're often not avoiding the runway space like they should.

It feels like the trees are basing their position on a false notion of where the terrain is.  They're either using terrain from the wrong position (i.e. "let's put this tree on the slope of that mountain over there, oh wait we placed it 30 kilometers east of the mountain where the terrain is flat"), or they're maybe using the wrong notion of what the body looks like, like maybe using the stock version of what would be on Kerbin at that lat/lng instead of what would be at Rhode at that lat/lng?  I have no idea but it's bizzarre.

Edited August 20, 2021 by Dunbaratu

[Dunbaratu]

The problem with trees and scatter rocks levitating in midair: Recent Kopernicus changes have this bug:

@BlackEyedPhantom  I got it to work (I think - it's hard to prove it's fixed just because it stopped happening, since the problem was intermittent in the first place.)

tl;dr:: Use an older version of Kopernicus.  Instead of getting the latest Kopernicus release that CKAN claims works for KSP 1.10.1, get whatever Kopernicus release existed *on the date when Beyond Home happened*.  That will be the version as it existed when the author of Beyond Home was testing things and released Beyond Home.

Apparently Kopernicus started having this floating scatter problem a while ago, and the most recent changes in the last few months *claim* to have fixed it, but they don't entirely fix it and it's probably dependent on your computer performance whether you still have the problem.  I had a brief eyeball scan of Kopernicus's code and it seems to have something to do with the when Kopernicus creates and positions scatter objects versus when KSP populates the final fine-grain terrain polygons.  It seems to sometimes be picking where to put the trees based on a low-res approximation of the terrain, before the fully populated terrain is loaded in.

At any rate, whether I'm right or I'm wrong about the actual cause, an older Kopernicus seems to fix it for me.

Edited August 20, 2021 by Dunbaratu

[BlackEyedPhantom]

On 8/21/2021 at 2:45 AM, Dunbaratu said:

The problem with trees and scatter rocks levitating in midair: Recent Kopernicus changes have this bug:

@BlackEyedPhantom  I got it to work (I think - it's hard to prove it's fixed just because it stopped happening, since the problem was intermittent in the first place.)

tl;dr:: Use an older version of Kopernicus.  Instead of getting the latest Kopernicus release that CKAN claims works for KSP 1.10.1, get whatever Kopernicus release existed *on the date when Beyond Home happened*.  That will be the version as it existed when the author of Beyond Home was testing things and released Beyond Home.

Apparently Kopernicus started having this floating scatter problem a while ago, and the most recent changes in the last few months *claim* to have fixed it, but they don't entirely fix it and it's probably dependent on your computer performance whether you still have the problem.  I had a brief eyeball scan of Kopernicus's code and it seems to have something to do with the when Kopernicus creates and positions scatter objects versus when KSP populates the final fine-grain terrain polygons.  It seems to sometimes be picking where to put the trees based on a low-res approximation of the terrain, before the fully populated terrain is loaded in.

At any rate, whether I'm right or I'm wrong about the actual cause, an older Kopernicus seems to fix it for me.

Ok thanks but will the 1.10 version of Kopernikus work on 1.12.2 ?

[Dunbaratu]

5 minutes ago, BlackEyedPhantom said:

Ok thanks but will the 1.10 version of Kopernikus work on 1.12.2 ?

I don't know.   It sounds like a question for the Kopernicus dev.  I have no idea when the change was first introduced that started making scatter levitate (Where none of the recent changes after that to fix it really seem to fix it).  It would depend on when that change was relative to when Koperinicus was updated to 1.12.2.

Edited August 22, 2021 by Dunbaratu

[Neebel]

On 8/21/2021 at 1:45 AM, Dunbaratu said:

The problem with trees and scatter rocks levitating in midair: Recent Kopernicus changes have this bug:

@BlackEyedPhantom  I got it to work (I think - it's hard to prove it's fixed just because it stopped happening, since the problem was intermittent in the first place.)

tl;dr:: Use an older version of Kopernicus.  Instead of getting the latest Kopernicus release that CKAN claims works for KSP 1.10.1, get whatever Kopernicus release existed *on the date when Beyond Home happened*.  That will be the version as it existed when the author of Beyond Home was testing things and released Beyond Home.

Apparently Kopernicus started having this floating scatter problem a while ago, and the most recent changes in the last few months *claim* to have fixed it, but they don't entirely fix it and it's probably dependent on your computer performance whether you still have the problem.  I had a brief eyeball scan of Kopernicus's code and it seems to have something to do with the when Kopernicus creates and positions scatter objects versus when KSP populates the final fine-grain terrain polygons.  It seems to sometimes be picking where to put the trees based on a low-res approximation of the terrain, before the fully populated terrain is loaded in.

At any rate, whether I'm right or I'm wrong about the actual cause, an older Kopernicus seems to fix it for me.

  Fun fact: If you had closely followed the installation instructions on the first page, you wouldn't have had the issue in the first place. The latest release you get to via this link is from August last year.

On 3/7/2019 at 9:25 PM, Gameslinx said:

Kopernicus (CHOOSE ONE):

• FOR 1.10.1 - https://github.com/prestja/Kopernicus/releases

 

[rukhafi]

Hello, Gameslinx. As always you have done a great job, thank you!

I have a few questions: where to get the config file for Sigma to rescale x3.7 and are there any other launch sites or airfields on Rhode? And does the mod Research Bodies work?

[Morphisor]

1 hour ago, rukhafi said:

Hello, Gameslinx. As always you have done a great job, thank you!

I have a few questions: where to get the config file for Sigma to rescale x3.7 and are there any other launch sites or airfields on Rhode? And does the mod Research Bodies work?

I made a 3.5x config if that's what you were looking for, here: https://github.com/Morphisor244/Beyond-Home-Rescale. There's no other sites on Rhode itself by default. There's no specific config for Research Bodies included, but it could still work on default behaviour - may find a few oddities however.

[Catto]

cant believe the core of this system is a cat

[PeterPutoAmo]

On 9/9/2021 at 3:50 AM, siklidkid said:

cant believe the core of this system is a cat

*a very bright cat

[Catto]

yes.

a bright kitty cat

[Teoras]

Hi, I have a problem with the 1.10.1 version of the mod I'm running. It seems that whenever I'm close to a surface of a body, the texture "chunk" glitches out and black squares form in the vicinity, meaning I can't see the surface. I can send a screenshot of this if needed.  The textures only disappear when I'm close to the surface and reappear when I get some distance to them. 
Does anyone have any clue why this might be?

[Morphisor]

11 hours ago, Teoras said:

Hi, I have a problem with the 1.10.1 version of the mod I'm running. It seems that whenever I'm close to a surface of a body, the texture "chunk" glitches out and black squares form in the vicinity, meaning I can't see the surface. I can send a screenshot of this if needed.  The textures only disappear when I'm close to the surface and reappear when I get some distance to them. 
Does anyone have any clue why this might be?

Yeah, you didn't install Parallax properly. Make sure to get the right version for BH, as it's not the latest.

[captainradish]

Just as an installation note: if you include 1.10 as a compatible version of KSP in CKAN it will install the proper version of Parallax.

 

EDIT: on a side note, are there any MM files floating around so I can use Mechjeb's autoland with this? I just noticed the landing site cfg and really don't want to hunt through the files to find the coordinates of all the sites.

Edited September 24, 2021 by captainradish

[koimeiji]

I've been fiddling around with Gateway's configs for the better part of the week, trying to fix the terrain so it generates correctly.

I've narrowed it down to an issue with the PQS settings, at least as far as I can tell. However, I am not a modder, let alone a Kopernicus modder, and have mostly been doing this by trial by error and seeing what does and doesn't work.

Specifically, it seems to be the vertex height map and height noise settings, as replacing those with, say, Janus' config lines allows terrain to generate (though with Janus' settings, of course). Again though, I am not a Kopernicus modder, so this could entirely be a fluke. Someone more knowledgeable on planetmaking would likely know more.

 

 

EDIT: Under VertexHeightNoiseVertHeightCurve2 and VertexHeightNoise, change the deformity values from negative to positive. This will add land back to Gateway, though I'm certain it's not exactly as it should be (it seems much more spikey than in 1.8.1)

Edited October 9, 2021 by koimeiji

[Dobelong]

 

On 10/9/2021 at 4:15 PM, koimeiji said:

I've been fiddling around with Gateway's configs for the better part of the week, trying to fix the terrain so it generates correctly.

I've narrowed it down to an issue with the PQS settings, at least as far as I can tell. However, I am not a modder, let alone a Kopernicus modder, and have mostly been doing this by trial by error and seeing what does and doesn't work.

Specifically, it seems to be the vertex height map and height noise settings, as replacing those with, say, Janus' config lines allows terrain to generate (though with Janus' settings, of course). Again though, I am not a Kopernicus modder, so this could entirely be a fluke. Someone more knowledgeable on planetmaking would likely know more.

 

 

EDIT: Under VertexHeightNoiseVertHeightCurve2 and VertexHeightNoise, change the deformity values from negative to positive. This will add land back to Gateway, though I'm certain it's not exactly as it should be (it seems much more spikey than in 1.8.1)

That sounds pretty hard, but I do admire your effort.
On my end, installing the latest Beyond Home with the indicated version of Parallax (CKAN wants to auto update it but I don't let it) and the newest Kopernicus seems to be working fine, though I haven't explored worlds that thoroughly beyond the Rhode system at this point. 
If we can get a replicable bug or terrain error, we could report that and maybe get a patch if possible. 

[Dobelong]

Does anyone have any tips for finding the various easter eggs? Do they show up on anonmaly scanners for Kerbnet?

[Dunbaratu]

Has anyone run into this problem before?

The stock KSP API call vessel.heightFromTerrain is giving the wrong answer for me in Beyond Home on planet Verna.  (i.e. the AGL is being returned as equal to the ASL).

Example: Landed base on Verna, Clicking the sea-level altimeter (blue wavy lines button) shows 1294m, And Clicking the terrain-level altimeter (Green mountain button) shows 2m.

In this situation

vessel.heightFromTerrain

SHOULD be showing the 2m number, but it's returning 1294.93977.

Because of that wrong answer, I get the following bug symptoms:

- Parachutes on planet Verna refuse to ever full-open.  They will partial-open (triggered by atmo pressure) but will never go from partial-open to full-open (triggered by altitude above terrain), resulting in a smashed lander.  If I set the chutes' terrain height setting high enough, enough to match the ASL reading instead of the  AGL reading, then they will full-open, indicating this is directly caused by the confused API returning the sea-level altitude instead of the ground-level altitude.

- Wheels don't work right.  I can't tell if this is because of the altitude confusion or not.  But they just don't act like they're getting any traction at all, and they spin in place.  This could be unrelated, I don't know.  But the same design of base station with wheels drives fine on other worlds like Lua and Rhode.

- EDIT: Additional effect- EVA kerbals instantly go into "ragdoll" mode when I leave the capsule and try to walk on the surface.  My controls are locked out and they refuse to respond, slowly sliding along the ground.

- As I was playing using kOS, I decided to have kOS print the ALT:RADAR( which should always match the in-game terrain altitude), and it prints the SEA LEVEL altitude, not the terrain level altitude. Any kOS scripts using this end up doing the "wrong thing".  This is where I traced down the problem being that vessel.heightFromTerrain is giving the wrong answer, as that's what ALT:RADAR is reading.  Presumably the chutes are reading the same thing which is why they have the same problem.

I never encountered this problem before I went out to Verna, which is the first planet of Kerbol I tried landing on.  When landing on the closer-in bodies that didn't require heading out to Kerbol, things were still working fine.

 

EDIT: Further testing, where I just keep printing out the diff between alt:radar (AGL altitude) and altitude (ASL alttitude), I found that while *in flight* above the ground, it would sometimes be correct (AGL and ASL differ) and other times be incorrect (AGL and ASL look the same), and it would keep toggling back and forth between  being right and being wrong.  It would be right for a second, then wrong for several seconds, then right for a second, then wrong for several seconds, then right for several seconds, etc.  This feels like race condition behavior.  As if something (maybe in Kopernicus) needs to keep over-riding a value again and again, and it comes out wrong only when that step doesn't happen "first" like it needs to relative to other things.)

Note, once I landed, then it was consistently wrong all the time.  (and wheels don't work right, making it impossible to take off again as they always vibrate and "jam".)  When I was flying above the ground in a jet, then it was wrong only *most* but not *all* of the time, exhibiting that race-condition-like behavior.

EDIT EDIT: I should point out that the stock GUI altimeter at the top of the screen was always doing things correctly, where ASL and AGL differed all the time.  Even when the API call vessel.heightFromTerrain was wrong, the GUI still showed the right answer for some reason.

Edited October 22, 2021 by Dunbaratu
addendum about alt when flying.

[Aborted Yolk]

vasto has no oceans? the water is there but its invisible ash lava and rhode water is fine but no oceans on vasto... is this a kopernicus issue beyond home itself or is it the parralex ? my guess is parralax as ive had some new issues on the newest version of ksp like the terrain does not match the ground in most places and so anything with a wheel becomes useless and the tyres spin like its floating.  this is a huge issue for me because it makes rovers wheeled bases or anything else wheel related useless.. does anyone or the creator have any information about this? do i need to post logs for this?

[Dunbaratu]

On 10/22/2021 at 10:10 AM, Dunbaratu said:

Has anyone run into this problem before?

The stock KSP API call vessel.heightFromTerrain is giving the wrong answer for me in Beyond Home on planet Verna.  (i.e. the AGL is being returned as equal to the ASL).

Because of that wrong answer, I get the following bug symptoms:

- Parachutes on planet Verna refuse to ever full-open.  [etc snipped]

- Wheels don't work right.  [etc snipped]

- EDIT: Additional effect- EVA kerbals instantly go into "ragdoll" [etc snipped]

I did a bit of googling and I believe this is caused by the older version of the Parallax mod that Beyond Home uses.  Parallax was doing some kind of tricks with the terrain that confuses parts of KSP's system.  If so, then the bug was fixed in a newer version of Parallax itself, but Beyond Home uses the older version that still has the bug.

The instructions for installing Beyond Home are *VERY* adamant about installing exactly version 1.0.1 of Parallax and not the latest version, so I don't think there's much I can do to fix this other than to hope a Beyond Home update eventually happens that moves the dependency to a newer Parallax.

[gilflo]

hello this sounds awesome!

Which version of KSP do you recommend to play without any bug?

 

 

[Dobelong]

14 hours ago, gilflo said:

hello this sounds awesome!

Which version of KSP do you recommend to play without any bug?

 

 

I use the latest 1.12. Be sure to carefully follow all the instructions (there's multiple pages) and run the game a couple times after installing. 
Even then I still do get occasional bugs and my brand new gaming laptop still struggles with rendering the map screen at first, before the farther away planets disappear.

[Puggonaut]

10 hours ago, Dobelong said:

I use the latest 1.12. Be sure to carefully follow all the instructions (there's multiple pages) and run the game a couple times after installing. 
Even then I still do get occasional bugs and my brand new gaming laptop still struggles with rendering the map screen at first, before the farther away planets disappear.

Which version of Kopernicus are you using please ? I get really confused by so many versions of this and usually never get the thing to launch , i'm using KSP Ver 1.12.2 if that helps .

[joacobanfield]

This is probably the best planet pack I've ever used. It runs well and doesn't take ages to load. Good job!

One thing though - I'm still getting the stock sicence messages. Are there custom messages in this pack or is one of my other science experiment-adding mods acting up? (Those would be SCANsat and the USI mods.)

 

Edit: Removing SCANSAT fixed it.

Edited October 29, 2021 by joacobanfield

[JimLim8510]

i am having the black square on ground when vessel is near surface problem. i am using kopernicus 1.12.1-60 and Parallax 1.0.1

How to fix this?