BRLite is not traditional open source software. It is licensed under the AGPLv3 License with a Common Clause that specifically prohibts this source code, or any derived work of this body of code from being used in any commercial sense. i.e. you vibe coders that think you'll make it rich by selling this code can't. The license DOES NOT preclude you from creating rotation elements that are 100% your own and selling those as they are not part of this body of work.
Using this software involves a level of risk to your digital assets. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS". (See License File) It is 100% developed as a learning exercise and, really, should never be used in a live environment. Get yourself some TrinityCore action and use it there :)
This software currently requires NilName as it's the only software of that nature I currently have available to me. It should work with any other tool providing that the tool has the ability to support an Object Manager, JSON File reading, general unlocking, and Click-To-Move functionality. If you really want your tool wired up feel free to contribute, or message me.
The current full build of BadRotations requires a fairly old DieselLib for UI development. This library is not maintained and as such has been manually patched progressively throughout the years. It's not very nice to play with when it comes to the various versions out there. As such I have decided to utilize a different UI library named AbstractFramework. It is available for all versions of retail from 11.1.0 onward, and all flavors of retail such as classic, mop, etc. You must install this library yourself -- it's not included here. BRLite will ensure it's loaded and notify you if it can't find the library.
***NOTE: Make sure you install the Abstract Framework for your specific Client Version: ***
Abstract Framework UI Library
All of the other libraries are included in this package, and adhere to the license of the original creators. This includes LibDataBroker-1.1, LibDBIncon-1.0, and LibStub.
BRLite is simply a light-weight redeveloped version of the traditional BadRotations without a lot of the overhead. It is designed to do one thing only, provide you with combat rotations. Well it does a touch more than that but we'll get to that in a minute.
-
Only the minimal of items will be tracked. If we can determine something dynamically using standard API we try to do so. We try to avoid creating large tables that require regular iteration and use CPU cycles. let the standard API call into the game's engine do that as it's much faster. An example of this is how we track buffs. Yes there's a table made in the Player object but it's just a table of what buffs we are looking for and associated helper functions. When we go to check if a buff is up we don't rely on cached info and just call the API. Hopefully this will reduce memory and CPU load requirements over the previous version that cached everything.
-
Only Combat Rotation and Related features will be supported. The only exception here is a fishing module I threw in because, well, you know, fishing.
-
No Heal-bot stuff. Once this code base stabilizes I'll probably work on a Healing specific version but the level of crap you have to track for a good heal bot is out-of-control.
-
Code must support ALL versions of WOW from 11.1.0 onward, classic, classic era, or whatever other retail flavors they release. To do this you'll notice that Spells, Auras, and Talents are defined inside of the rotation (Or not, as Cata/Mop don't have the same Talent stuff). Where there are API changes that the bot itself uses we'll proxy that out by version. Each rotation will have a Minimum and Maximum TOC version that it supports. So yes, you can run this on your private 11.1.5 server with one rotation, and use the same code base to load it up under Retail MOP. It would just be a different rotation.
-
Intellisense. All core objects have Intellisense notations where possible. This helps all you vibe coders create rotations.
-
One core object to rule them all. the BR object is the root object. All other components, like say logging, are referenced there. The code base is so small compared to BR that doing
local log = br.Loggingseemed so much easier than using a module loader, and we don't really have dynamically loaded modules here.
after you install NN or your tool of choice place this code inside of the 'Scripts' directory in a directory called 'BRLite'. This is really important. These unlockers require a bootstrap and our bootstrap needs to know where to go to find the source code.
Once you've put that there then either copy or create a symbolic link to the specific unloader into the scripts file. For example you could do this inside of an Administrator Powershell window:
PS D:\WOW\NN_BRLite\scripts> New-Item -ItemType SymbolicLink -Path _BRLiteLoader.lua -Target ./BRLite/unlocker/_BRLiteLoader_Nn.lua
then when you pull newer versions of the source code you'll not need to worry about updating the bootstrapper; it's symbolically linked and just a reference to the sources file.
- Install NN or whatever, following all the instructions for that tool. I can't help you there.
- Once installed open a PowerShell script as administrator (You'll need to learn to do this anyway, most unlockers require command line admin access)
- cd into the Scripts Directory
- git clone repository BRLite (this will download source code into folder named BRLite)
- Run the Symbolic Link command shown above.
- Start NN (or your unlocker) I really hoped you renamed it but TBH Big Brother can see through that crap now.
- Look in chat dialog for anthing amiss.
Once loaded you should see a couple of things. You should see the standard "fire" BR minimap icon, you should see the rotation toolbar itself (if you have a valid rotation for your class, spec, and Client version) and you should see some items in the chat frame.
The current bot kinda spams the chat log during usage with every spell being cast. This will definitely change in the future but I consider this an early beta product and the chat log is the only way to do debugging. The important part is during startup:
TODO: Add Images
The minimap icon is the standard BR fire/flame icon. It has tooltips that tell you what it does.
Left-click will bring up the main BR Lite Settings window (A WIP) Right-click will toggle the BR Toolbar on and off Shift-Left-Click will pull up the "MOVER" screen which will allow you to reposition the BRLite UI Elements around your interface.
*** TODO: Elaborate ***
Note: The toolbar will not appear unless you have an active rotation that matches your class, specialization, and is designed to run on the version of the client you are using.
Toolbar icons are wrapped in either a green or red border. Yeah; red = off, green = on.
From left to right:
- The rotation toggle button. This turns the rotation on and off. Is represented by your class icon
- The fishing icon. You've got this, I bet I don't even need to explain it. FWIW the fishing bot will auto-accept BOP items such as threads.
- The Movement Icon. This will prevent the bot from performing any movement activities. The only movement the bot currently supports is Line-Of-Sight Click to Move to current target. And that's if it's actually called in the rotation. That method is
br.ActivePlayer:CloseToMelee(target) - The Facing Icon. This toggles whether or not to have the bot maintain your player's rotation so it's always facing your active target.
- The Looting Icon. Yup, bet you know what this button does too.
I'm going to go through a rotation file so you know what parts are what. Hopefully YOU can contribute by building rotations. Rotations are the life-blood of a bot and they really do take a while to build. Mostly because testing requires you to level through a character and that process isn't just a few hours, sometimes it's DAYS of working on getting a character's rotation where you want it. And that's nothing compared to tweaking a rotation up enough to handle Heroic, then M+ crap. Ugh.
The first part of the file has the initial parameters of the rotation.
---@type _,br,_ #Must include typing to get intellisense in VSCode
local _,br,_ = ...
---------------------------------------------------------------------------
-- Rotation Information, Required to determine if the rotation can be used
---------------------------------------------------------------------------
local RotationName = "Stock Monk BM 11.1.5"
local RotationShortName = "StockBM110105"
local RotationVersion = 1.0
local RotationDescription = "Standard BM rotation for 11.1.5 TWW "
local RotationTOCLower = 110105
local RotationTOCUpper = 110105
local RotationClassName = "MONK"
local RotationSpecializationID = 1
Each rotation needs to have these elements defined. It's what allows the bot to determine if the rotation is proper for your class, specialization, and client version. Pay special note to the RotationTOCLower and RotationTOCUpper variables. These define which client versions are valid for this rotation. If I felt this rotation worked just as well in 11.1.5 and 11.1.7 then I would change the RotationTOCUpper to 110107. These #s are the same numbers used by Addons. If you're confused about what these numbers mean there's this whole thing called the internet, and search and ai tools to help you find what you're looking for. Don't make me google it for you.
-----------------------------------------------------
--- Spell List. Yes I know the previous BR had all of
--- these inside the core code but they vary so much
--- by client release that to support multiple versions
--- we need to have them defined per rotation.
--- ------------------------------------------------
local SpellList = {
TigerPalm = 100780,
BlackoutKick = 205523,
RisingSunKick = 107428,
...
}
Each rotation must define the spell list. These are then used to construct the Player:Cast table. we do this so you can use familiar methods in your rotation like cast.able.TigerPalm() or cast.RisingSunKick() etc.
--------------------------------------------------------
--- Aura List
--- List of Buffs to track in the player.buffs table or the Br.Debuffs table
--- --------------------------------------------------------
local AuraList = {
CombatWisdom = 129914,
TeachingsOfTheMonastery = 202090,
Provoke = 116189,
Bok_proc = 116768,
Chi_Wave = 450380,
...
}
Same with the Aura List. These are then used to construct two helper tables, Player.Buffs and br.Debuffs
--------------------------------------------------------
--- Talent List. if you use Player:HasTalent() you can
--- use this list to define the talent ID rather than
--- typing in talentID
--- ------------------------------------------------------
local TalentList = {
FluidityOfMotion = 387230,
ScaldingBrew = 383698,
}
Again, a local list that tracks talents. Used in Player:HasTalen(TalentList.FluidtyOfMotion). This one is kinda optional as you could always just pass the ID # of the talent into that method. Up to you.
---------------------------------------------------------
--- Map your functions locally here for ease of use
--- -----------------------------------------------------
---@type br.Logging
local log = br.Logging
---@type Player
local player = br.ActivePlayer
---@type Player.cast
local cast = br.ActivePlayer.cast
---@type Player.buffs
local buffs = br.ActivePlayer.buffs
---@type Unit?
local target = br.ActivePlayer:TargetUnit()
---@type number
local energy = br.ActivePlayer:Power()
---@type number
local stagger = UnitStagger("player") or 0
In the above code we map out a bunch of locals with Lua Language annotations that help with your intellisense. By using these notations you'll see all (well most) of the fields of each object.