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 for several exceptions #42

Merged
merged 5 commits into from Oct 30, 2018
Merged

Conversation

Wyzard256
Copy link
Contributor

This is a set of fixes for several exceptions that I noticed while using AH:

  • A NullReferenceException after launching, reverting, and launching again, caused by the Relay.potentialRelays list having outdated information.
  • Endless NullReferenceExceptions in the tracking station after recovering a vessel, caused by AHShipList.listFlyingVessel having outdated information.
  • Endless KeyNotFoundExceptions in the tracking station when AH is open and the selected vessel is an asteroid or EVA kerbal, caused by trying to lookup a marker that doesn't exist.
  • NullReferenceExceptions when leaving the flight scene, caused by accessing fields of AHMapMarker components that have already been destroyed. (This one was only on the dev branch after the v1.0.4 release.)

The Relay.potentialRelays list was being built just once, in the class's
static constructor, with a subset of the Vessel objects (those with
comms) that were available at that time.  This was problematic for two
reasons: first, it wouldn't notice changes that occur later (e.g. new
vessels with comms being launched), and second, each entry to the flight
scene seems to create a new set of Vessel objects, so the GetRelayVessel
wouldn't find anything matching the new objects because the relays in
the list would still hold references to the old ones.

Rebuilding the potentialRelays list at each entry to the flight scene
keeps it up-to-date with the current set of vessels and their Vessel
objects.
Although the AHShipListListener calls ParseFlyingVessel when the player
returns to the space center, that event fires while the vessel-recovery
window is still open and before the recovered vessel has actually been
removed from FlightGlobals.Vessels, so listFlyingVessel will include the
recovered vessel in that case.  If the player then goes to the tracking
station, AHTrackingStation.CreateMarkers would throw exceptions trying
to create a marker for it, since it wouldn't be found in
FlightGlobals.Vessels anymore.  Updating listFlyingVessel on entry to
the tracking station avoids that.
This prevents KeyNotFoundExceptions every frame when the player selects
something like an asteroid or EVA kerbal.
When leaving the scene, its GameObjects get destroyed, in no particular
order.  Sometimes it happens that an AHMapMarker's parent GameObject
gets destroyed before the Vessel that the marker is associated with.
Destroying the parent GameObject also destroys the AHMapMarker
component, so if AHFlight.VesselDestroy later tries to access the
component's gameObject property, it throws a NullReferenceException
because the component is no longer associated with a GameObject.

To avoid that, AHFlight now stores references to the actual GameObjects
that it'll need to destroy later, instead of to the AHMapMarker
components attached to them.
If the current vessel is a relay satellite, other vessels may have
communication paths that go through it.  If they do and the current
vessel isn't in the potentialRelays list, GetRelayVessel returns null
for it and LinkPath.SetLinks causes a NullReferenceException when it
tries to construct a Link with a null relayB.
@Wyzard256
Copy link
Contributor Author

I've added one more fix: a NullReferenceException at entry to the flight scene if the active vessel is part of some other vessel's communication path, caused by the Relay.potentialRelays list excluding the active vessel.

It's not entirely clear why the code that builds potentialRelays was written to ignore the active vessel, but I'm guessing it's because the active vessel's relay power can change, e.g. by the player deploying or undeploying an antenna. If so, that sort of change will need to be handled some other way.

@Li0n-0 Li0n-0 merged commit 6a1ca37 into Li0n-0:DEV Oct 30, 2018
@Wyzard256 Wyzard256 deleted the exception-fixes branch October 31, 2018 01:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants