Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixes #2899 terrain raycast now ingores parts. #2900

Merged

Conversation

Dunbaratu
Copy link
Member

Fixes #2899

The fix I went with was to detect whether or not a raycast hit
is inside a Part. If it is, then start a new raycast just past
the hit and keep looking.

The solution involved writing a wrapper around Raycast that
includes this extra logic, such that it could be lifted and
put in a utility library later if any other classes need to
use it.

Using the same example script and craft as in the issue #2899, with this change it now looks like this:
screenshot26

The fix I went with was to detect whether or not a raycast hit
is inside a Part.  If it is, then start a new raycast just past
the hit and keep looking.

The solution involved writing a wrapper around Raycast that
includes this extra logic, such that it could be lifted and
put in a utility library later if any other classes need to
use it.
@Dunbaratu Dunbaratu added the bug Weird outcome is probably not what the mod programmer expected. label Mar 16, 2021
I thought I had solved this in the previous commit but
noticed it failed in gameplay.  My math wasn't quite right.

The problem fixed in this commit only shows up when you aren't
on the equator, which is why it wasn't seen in testing on the KSC
runway.

The issue is that I changed algorithms partway through implementing
this but didn't fully edit the code to reflect the new algorithm.
What I had was a mix of the two.

Prev algorithm was "calculate new raycast start by adding
(distance plus a bit)*aimvector to the previous start
point".

New algorithim was "Calculate new raycast start by just
using the hit location directly, plus aimvector times a little".

The old algorithm required a +=, and the new one just an =.  I missed
that edit, and that mistake caused it not to work when not on
the equator (essentially, when the Z axis of world coords isn't zero,
the bug manifested.)
@Dunbaratu Dunbaratu merged commit cbff572 into KSP-KOS:develop Mar 17, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Weird outcome is probably not what the mod programmer expected.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Geoposition terrainheight is wrong for LATLNG's that are very close to a rover scanner arm
2 participants