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

Handle vessel destruction errors #24

Open
rallen10 opened this issue Dec 9, 2024 · 2 comments
Open

Handle vessel destruction errors #24

rallen10 opened this issue Dec 9, 2024 · 2 comments

Comments

@rallen10
Copy link
Collaborator

rallen10 commented Dec 9, 2024

Currently, if vessel's collide and one is destroyed (e.g. the Guard), errors are thrown during episode termination because calls to krpc reference a vessel that no longer exists

@rallen10
Copy link
Collaborator Author

This needs to be handled for all vessels (Lady, Bandit, Guard)

@rallen10
Copy link
Collaborator Author

rallen10 commented Jan 6, 2025

This is a tricky one because I think it requires finding everywhere in the code that calls something like vesLady, vesBandit, or vesGuard and writing logic to handle the case when those vehicles don't exist. These calls are ubiquitous (fortunately, I think they can only be made within the ksp_interface_loop process, so at least they shouldn't be spread across processes which should make the logic a bit easier).

Instead of implementing this error handling logic at every call to something like vesGuard, it should obviously be implemented in one centralized place; e.g. create classes for these vessels and use methods to access their information while implementing the non-existence case-handling within these methods. However, this would still likely involve updating the call signatures for vesGuard, etc. everywhere they appear. Even if the call signatures could be left as-is, this change would require a large amount of testing that I don't have time for at the moment

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

No branches or pull requests

1 participant