Enables the pf4j [development mode](https://pf4j.org/doc/development-mode.html)
to support loading external plugins from sources, which enables java's
hotswap functionality.
To use this feature set the `plugin.development.path` property or
`PLUGIN_DEVELOPMENT_PATH` environment variable to the directories
containing your plugins, e.g. `../plugins;../my-custom-plugins`
Once set the `ExternalPluginManager` will ignore the configured
repositories and externalmanager directory, and instead load all
the built plugins from the specified directories.
Utilizing this feature does require some additional configuration
of the build of the plugins `build.gradle.kts`. Within the `subprojects`
section add:
```
tasks.register<Copy>("copyDeps") {
into("./build/deps/")
from(configurations["runtimeClasspath"])
}
```
See https://github.com/open-osrs/plugins/pull/260 for the `openosrs/plugins` change
This enables the following workflow:
0. Optional tip: Set the `external.system.substitute.library.dependencies` registry value to `true` to force classpath resolution within the project
1. Open the `runelite-client` project in IntelliJ
2. Add the `plugins` repository as a module (Gradle -> Plus symbol ->
`plugins/build.gradle.kts`)
3. Gradle build the client with: `build publishToMavenLocal :runelite-client:publishToMavenLocal :runelite-api:publishToMavenLocal :http-api:publishToMavenLocal`
4. Gradle build the plugins with: `build copyDeps`
5. Add the `PLUGIN_DEVELOPMENT_PATH` environment variable to the run
configuration
Once the above is done the edit -> reload -> edit cycle can begin:
1. Start the client in debug mode using the run goal
2. Edit the external plugin
3. Perform Build > Build Module
4. Observe hotswapping in action!
5. If hotswapping failed, or your change requires a plugin restart,
click the hotswap button in the plugin list to instantly restart it
Instead of fixed color offsets for outer and inner border colors switch
to multiplicative offsets. This also makes overlay color alpha
recoloring work properly with background component border.
Signed-off-by: Tomas Slusny <slusnucky@gmail.com>
In spite of being a hard coordinate clue, this clue step is an exception
to the rule that a Saradomin Wizard will spawn at all non-wilderness
locations. No enemy spawns at this spot.
I can't find any instances of npc indexes being reused in instances,
which just causes the respawn timers to incorrectly identify a random
npc later which happens to use the same id.
See 01f134795d
One master clue step requires the player to wear "any full barrows set."
Previously the emote clue logic for this step allowed only levels of
degradation from 0-100, but not the non-degraded item (whose item ID is
disjoint from the others).
Wrap those item range checks with an 'any' clause which also allows the
non-degraded item.
Add tests for degraded and non-degraded barrows sets.
This fixes npc tags for dynamic npcs sometimes erronously tagging the
wrong npc if the npc index gets reused. This happens regularly when
tagging bloat manually a few times, since the Verzik webs are all npcs
and there are many of them, thus a high chance of index collision.
