Commits
The VS Code gradle extension was running the gradle file from the extensions working directory, so it couldn't find the file path.
This commit looks up the full path on the user's machine so that it doesn't matter which working directory is used to call the gradle script.
I no longer use Twitter, so I'd prefer to direct traffic to LinkedIn where I am more active.
It's often confusing for new developers to configure a server for testing.
This commit adds a gradle task called `runDevServer` which builds the plugin,
and loads it into a new server for testing.
closes #16
Co-authored-by: Caleb1H <Caleb1H@users.noreply.github.com>
Brings a bolt of lightning wherever it lands!
closes #15
closes #14
Co-authored-by: Caleb1H <Caleb1H@users.noreply.github.com>
During testing, I increased the power of the explosive arrow.
This commit restores the power to its normal level.
Co-authored-by: Caleb1H <Caleb1H@users.noreply.github.com>
- Renamed the package space to use my new personal branding (jhale.dev)
- Updated dependencies to base off of Minecraft 1.19
NOTE: One of the SniperArrowTests refuses to complete, so it has been
commented out. Interestingly the build only hangs on that one test,
unless I remove the `MockBukkit.unmock()` call, in which case it hangs
in a later test. The issue seems similar to this bug report on
MockBukkit, which is marked as resolved, but the associated PRs appear
to have been closed OR contain reports that the issue persists:
https://github.com/MockBukkit/MockBukkit/issues/263
I don't have the time to resolve the hanging test issue right now, so
though I hate to commit a commented test, that's what's happened after
manual testing to verify that the Sniper Arrow still works as expected.
The namespace changed long ago, so we're bringing it back to where it
should be.
The bstats Metrics class does not need to be represented in my unit test
coverage.
Now my test coverage has jumped to 71%!
Jail Arrows surround hit enemies with iron bars to trap them in place.
Closes #8
The `util` package's main class `Utilities` was starting to get large
due to the many different types of methods contained within it.
This commit splits those methods into more classes with names that are
more semantically meaningful.
Step 5 had included too much in the echo statement, so the output
of the PRODUCE_RELEASE calculation wasn't getting saved into $GITHUB_ENV
Hopefully this finally resolves things...
The example in the [docs](https://docs.github.com/en/actions/reference/environment-variables#about-environment-variables) uses the workflow syntax `${{env.VARIABLE}}` to evaluate environment variables during `if` gates.
I'm hoping this allows the runner to correctly publish a new release when the `PRODUCE_RELEASE` environment variable exported in step 5 is found to be `'true'`.
I think the environment variable is saved as the string 'true' or 'false'
instead of a boolean.
The pipeline now gates on a check against the string `true` instead of
the pure boolean.
The generated changelog only reports on closed issues, which means it's
only useful after a merge to master (because that's when commit comments
like `Fixes #XX` close GitHub issues).
As such, the changelog should only be created if a release is allowed.
Since this means that multiple steps are now gated by whether or not
this workflow should produce a release,
I've added an extra step that computes and saves that boolean to an
environment variable.
Added additional build tasks and GitHub Actions steps to enable
full CI/CD for Power Projectiles
Closes #2
So far, I've had to manually update both the `build.gradle` file and
the `plugin.yml` file whenever I wanted to bump up to a new version.
Now the gradle build script reads in the version number from plugin.yml
which means I only have to track the version in one place now!
Fixes #3
All the arrows have now been unit tested.
Jacoco Test Coverage has also been integrated, and we're already at 75%
code coverage!
All arrows now have some test coverage due to the RegisteredArrowsTest
that ensures the abstract methods of PowerArrow are implemented
properly. Additional, detailed tests have been added for the Explosive,
ForestFire, and Net Arrows.
Now just to write full tests for the Sniper and Teleport Arrows!
By using Mockito I can work around all the limitations of the MockBukkit
server's dearth of implemented methods.
Since Sniper Arrows aren't affected by gravity, there needs to be a
mechanism beside hitting the ground or another entity that will remove
them from the game (i.e. if they are shot straight up).
This commit automatically removes a Sniper Arrow after 400 ticks
(20 seconds) to keep resource usage lower.
Explosive arrows grant fewer per recipe but do more damage.
Teleport arrows now cause the standard 5 ender pearl damage.
Shapeless recipes are also supported for arrow crafting.
I welcome people using this plugin, but I'm not okay with people trying
to sell it or sell similar clones without making arrangements with me
first.
I may make the license more permissive in the future, but for now, usage
is free, including in servers that have paid components (assuming they
are in compliance with Mojang's EULA), but changes, redistribution,
sales, etc. without my written consent are not.
Net Arrows spawn a bunch of cobweb around their impact site.
Great for drastically slowing down opponents!
Also, since Net Arrows require so much cobweb to craft, I also added in
a new recipe that allows for the crafting of cobwebs.
This will make it easier to implement other types of arrows that place
blocks around their impact site.
Abstracted the common components of the onProjectileHit
method into the PowerArrow parent class.
Also added particles to the trails of Power Arrows.
Harness the power of the blaze rod to engulf your enemies in flames!
The Forest Fire Arrow uses a blaze rod instead of a stick and will start
a 3x3x3 fire around its impact site. No special enchantment required!
Explosive arrows share one tnt among four arrows and create a small
explosion (of 1/4th the power of a TNT explostion) at their impact site.
It will now be much easier to add in new power arrows!
Torch arrows also drop as an item if they hit the bottom of a block.
I decided that discovering torches, which happens upon making a stone
pick, was too easy of a pre-condition for Torch Arrows.
Since Torch Arrows require a bow with the Flame enchantment to have an
effect, it makes sense to require the player to have enchanted something
before they get the recipe for Torch Arrows.
- Renamed the package space to use my new personal branding (jhale.dev)
- Updated dependencies to base off of Minecraft 1.19
NOTE: One of the SniperArrowTests refuses to complete, so it has been
commented out. Interestingly the build only hangs on that one test,
unless I remove the `MockBukkit.unmock()` call, in which case it hangs
in a later test. The issue seems similar to this bug report on
MockBukkit, which is marked as resolved, but the associated PRs appear
to have been closed OR contain reports that the issue persists:
https://github.com/MockBukkit/MockBukkit/issues/263
I don't have the time to resolve the hanging test issue right now, so
though I hate to commit a commented test, that's what's happened after
manual testing to verify that the Sniper Arrow still works as expected.
The example in the [docs](https://docs.github.com/en/actions/reference/environment-variables#about-environment-variables) uses the workflow syntax `${{env.VARIABLE}}` to evaluate environment variables during `if` gates.
I'm hoping this allows the runner to correctly publish a new release when the `PRODUCE_RELEASE` environment variable exported in step 5 is found to be `'true'`.
The generated changelog only reports on closed issues, which means it's
only useful after a merge to master (because that's when commit comments
like `Fixes #XX` close GitHub issues).
As such, the changelog should only be created if a release is allowed.
Since this means that multiple steps are now gated by whether or not
this workflow should produce a release,
I've added an extra step that computes and saves that boolean to an
environment variable.
I welcome people using this plugin, but I'm not okay with people trying
to sell it or sell similar clones without making arrangements with me
first.
I may make the license more permissive in the future, but for now, usage
is free, including in servers that have paid components (assuming they
are in compliance with Mojang's EULA), but changes, redistribution,
sales, etc. without my written consent are not.
I decided that discovering torches, which happens upon making a stone
pick, was too easy of a pre-condition for Torch Arrows.
Since Torch Arrows require a bow with the Flame enchantment to have an
effect, it makes sense to require the player to have enchanted something
before they get the recipe for Torch Arrows.