Add NASAMs to MERAD unit list for campaign template (#3406) #3410
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.
Adds NASAM launcher B and C to the list of units that can be placed in a campaign template to define a MERAD spawn location.
This is needed to maintain compatibility with the new versions of my campaigns.
Pull requests should be made against the
develop
branch. Any backportsnecessary will be handled by the development team.
Pull requests should be focused on one task. Multiple bug fixes should be
multiple PRs. We cannot merge half a PR, and combined PRs are much more
difficult to review. PRs that do not adhere to this will have their review
delayed.
Prefer rebase to merge, and squash commits as needed to preserve a readable
commit history. This project maintains linear history in the develop branch, so
we will either rebase or squash your PR when merging. It is much easier for us
if your branch already has a readable commit history (ensure that your commit
subject lines are clear enough to identify the patch in the git log). An
exception to this is made for large PRs that are likely to require multiple
rounds of review; in that case it's easier if you don't do this (GitHub
does not preserve the history of old commits, so we cannot filter a PR for only
new changes if a branch is force pushed) and we will squash it when merging.
New features and bug fixes are usually worth mentioning in the changelog.
Exceptions are fixes for bugs that never shipped (were only present in a canary
build), and changes with no intended user observable behavior, such as a
refactor. If you're comfortable writing the note yourself, add it to
changelog.md
in the root of the project in the section for the upcomingrelease.