Conversation
…ument column entries are consistent
for more information, see https://pre-commit.ci
…ting and "simulating" print
…rs throughout codebase
…ate tests with more tolerance for interpolation discrepancies
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
DRAFT
This PR uses the new exported fields from the MFP "Cruise Data" (see #362) to auto-fill the waypoints times using a user-prescribed
--start-dateand timedeltas from MFP when doingvirtualship init --from-mfp.Also, now that the ports of arrival/departure have been added to the MFP export these are now incorporated into the expedition.yaml, including a new
Portmodel class. These act as special waypoints with times and locations but no instruments.Further notes
Schedulemodel gets pydantic field validators, ensuring that departure and arrival ports are always ingested in an expedition (dummies are added when not specified invirtualship init). Ensures compliance with logic throughout codebase (e.g. with the RLCs).Schedule, as a 'minimum standard' in order for other logic to work. Further checks (e.g. that waypoints can be reached in time) remain inSchedule.verifymethod. This is a design choice whereby these verification checks require more user thinking/interaction to relate to real-life.virtualship initlogic to a new module (cli/_initialise.py). Should help with readability and maintainability now that there is a lot more logic associated with this command, plus is consistent with the structure for other commands (planandrun).# Port of Departure,Waypoint 1,Waypoint 2and so on. This helps with config readability and is a previous user-feedback request.TODOs
runalways has an departure and arrival port (even if empty placeholders), to ensure consistent problems module behaviourplanorrunSchedule,InstrumentsConfigandCheckpoint.verify()methods, plussimulate_schedule).plantooltest_initialise.pyfile w/ new tests.Closes #362