Initial Beta of Bashmatic
All checks were successful
ci/woodpecker/push/woodpecker Pipeline was successful
All checks were successful
ci/woodpecker/push/woodpecker Pipeline was successful
This commit is contained in:
27
readme.md
27
readme.md
@@ -2,15 +2,15 @@
|
||||
Bashmatic is a generic script package for mudlet. Many muds have a character visit areas and attack various denizens to gain experience to level up. This process is colloquially called bashing. Bashmatic is a very generic script package that automates this process.
|
||||
|
||||
# What does it support?
|
||||
Again, it's very generic. Because of that it supports pretty much anywhere that you can bash using a one line command to do so. However, because of the generic nature of the script it also doesn't support more advanced features games might have. It does however support sending commands to the game before and after fights. It also supports grouping bashing targets by areas if you use the mudlet mapper or your game supports gmcp. It also supports finding enemies by gmcp or general input scraping. So overall:
|
||||
Again, it's very generic. Because of that it supports pretty much anywhere that you can bash using a one line command to do so. However, because of the generic nature of the script it also doesn't support more advanced features games might have. It does however support sending commands to the game before and after fights. It also supports grouping bashing targets by areas if you use the mudlet mapper. Overall it supports:
|
||||
|
||||
* Supports sending a customized pre-bashing command
|
||||
* Supports sending a customized bashing command
|
||||
* Supports sending a customized post-bashing command
|
||||
* Supports specifying a custom mob death phrase
|
||||
* Supports specifying a custom mob death trigger phrase per game
|
||||
* Supports grouping bashing targets by area
|
||||
* Supports detecting areas using the mudlet mapper or by GMCP
|
||||
* Supports detecting enemies by GMCP or general input scraping
|
||||
* Supports detecting areas using the mudlet mapper
|
||||
* Supports detecting enemies by creating temp triggers based on target names
|
||||
* Provides a function `bmDisable()` that will disable the basher so you can rig a flee/wimpy trigger/alias
|
||||
|
||||
# Can I use this on my mud?
|
||||
@@ -22,25 +22,24 @@ A few but none that are too bad.
|
||||
## Switching To Area Group Mode
|
||||
By default, Bashmatic does not group by areas. This means if you switch the target grouping mode to areas you will erase your target list. This is by necessity. If area grouping is turned off, no area data is stored for targets. When you turn on area grouping, we have no way of finding out what area they should be in. So you'll have to readd them to get them in the right area. This is not true of the other way. If you are grouping by area and turn that off, then we will simply collate all targets into a giant list. You can then clear your target list using `bm clear` if you want.
|
||||
|
||||
## GMCP Usage
|
||||
GMCP requires you to tell the script where the variables are located. This isn't hard. You can type `lua gmcp` into mudlet to get back a listing of the gmcp data your mud sends out. If the list of enemies on your mud was at `Room.Info.Enemies` you could give me that information using `bm config egmcp=Room.Info.Enemies`
|
||||
|
||||
## Grouping Targets By Areas
|
||||
If grouping by GMCP areas, also see above.
|
||||
We can group targets by areas if you prefer as long as we can tell which area we are in. This can happen by the mud sending the area name by GMCP or by mudlet returning an area through `GetRoomArea(GetPlayerRoom())`. This can be useful for keeping your target lists manageable assuming you want to be able to look at them.
|
||||
## Grouping Targets By Areas
|
||||
We can group targets by areas if you prefer as long as we can tell which area we are in. This can happen by mudlet returning an area through `GetRoomAreaName(GetRoomArea(GetPlayerRoom())`. This requires you to have a map made in mudlet. Functionally, the real benefit to this is that we can reduce the number of tmeporary triggers made since we can only make ones related to the current area. However, unless you have thousands upon thousands of targets built into your list you probably won't notice the difference.
|
||||
|
||||
## Auto target switching
|
||||
Bashmatic doesn't technically support auto-target switching, but we have a jury rigged solution. Upon detecting an enemy's death we will look at the room again.
|
||||
|
||||
## Before, During, and After Bashing commands
|
||||
You should know that the only time we append the target name is bashing start command. Before, During, and After bashing commands do not receive the target name.
|
||||
You should know that the only time we append the target name is bashing start command. Before, During, and After bashing commands do not receive the target name. We also kill all triggers related to finding targets once we start bashing a target.
|
||||
|
||||
# Required Setup
|
||||
At the very least, you'll need to setup a bashing command. This can be as simply as just `kill` and we'll fill in the target. And you'll need some kind of death trigger. On a lot of muds this could just be the word `died`. A lot of muds just use some variation of the phrase `has died` and this script will match `.*word.*`. Then at least one target added using bm add target. So `bm add bunny` maybe.
|
||||
At the very least, you'll need to setup a bashing command. This can be as simple as just `kill` and we'll fill in the target so it late becomes `kill target`. And you'll need some kind of phrase that allows us to determine a mob has died: The death trigger phrase. On a lot of muds this could just be the word `died` or `has been slain` or `have slain` or some other combination. A lot of muds just use some variation of the phrase `has died` and this script will match `.*word.*`. Then at least one target added using bma target. So `bma bunny` maybe.
|
||||
|
||||
* A bash command, Possibly just: `kill`
|
||||
* A death trigger, Possibly just: `died`
|
||||
* At least one target, Possibly just: `bm add bunny`
|
||||
* At least one target, Possibly just: `bma bunny`
|
||||
|
||||
# How does this work?
|
||||
It depends. Under the hood, it's much more efficient if we can get enemy data from GMCP. Using GMCP, we can simply scan GMCP data for changes to enemy data and react to that. Without GMCP, we create temporary triggers and react to those as they fire.
|
||||
In general, we create temporary triggers that only fire once that look for matches against the targets given. So for our bunny example, we would create a temp trigger that will only ever fire once against the word bunny. This is not perfect, for obvious reasons. If the room description contains the word bunny or if someone is wearing an item with the word bunny in it, we're going to react to that word. Still, it's a simple enough solution that works most of the time for most situations especially given that the system has to be manually turned on and is likely to only even be turned on in situations where we are less likely to run into those odd situations. IE: If you turn on the autobasher, the bunny you run into is most likely to be the one you want to kill for gaining experience, not the random guy with his bunny cloak. Even if it does mess up, just kill something normally once and it will reset. Or simply toggle it off and on. You'll be ready to go again.
|
||||
|
||||
# In Game Help
|
||||
There is extensive and easy to understand help built in. Once installed in mudlet, see `bm help` and `bmc` for an indepth explanation of settings and features.
|
||||
Reference in New Issue
Block a user