inowen / skybot Goto Github PK

• Pvp: make sharpness in nametag bright green to see it better.

• Config: Create a ConfigOption for showing sharpness in nametags when PvpEnhancer is on.

• Config+MainMod: Make it so that if when starting the game there is no textfile for config, it creates one with default settings.

Need it to test my pathfinder by making it go anywhere I click, but later on it will probably be used in many different ways.

If the proof of concept has no valuable information, or the concept is already applied somewhere in the code base, remove it.

Test it with a Module that goes wherever the player clicks.

It works just fine when launching the game from IntelliJ, but after building and pasting the .jar into .minecraft/mods it doesn't do anything anymore.

Only one class should be allowed to subscribe to the Forge Event Bus. The mods give it code to execute. This class has a "general off switch" for everything related to events.

Remove comments where the code is self-explanatory, remove comments related to debugging

Test what happens when trying to read a block that's way too far away.

Things like how far the bots should reach, which item to farm, the radius of the zone in which the pathfinding works... all the options that can be changed around.

• Make a settings GUI.
• Database-type functionality that stores these options in .minecraft/config/Skybot/

Eliminate literals if possible, especially if there are helper classes which define them as constants.

A path block is basically an air block, but it renders a line inside it, depending on a property (in its BlockState) that tells it which orientation it has.

To test it, make it generate and print all children once (Module#onEnable) whenever a certain key is pressed.

Set up a few tests in the world to make sure all possible actions were considered.

Create moduleSystem.mods.gui, add all the gui mods there.
All Modules have to be added to ModuleManager.

Using a binary heap, generic, of anything that implements Comparator.

(only after path visualisation works)

Test it by giving it valid starting point and end point, quite close together (maybe in a world that's only a few blocks big), and see it it is able to work out a path.

Afterwards, make a quick implementation to go wherever the player clicks (use my raytracing helper to get this done).

AstarNode {blockpos, cost, combined_cost, parent}

closedSet a TreeSet of AstarNode, ordered by BlockPos (and O(logn) operation to check if node with certain BlockPos is in the set)

openSet a PriorityQueue of AstarNode, ordered by combined_cost (increasing).

Each time a node is extracted from openSet, check if that BlockPos is already in closed. If so, discard (because consistent heuristic and optimality and all). If it's already in closed, continue (jump to main loop start again).

The point is that this method doesn't update costs in the open set. Searching would be done in linear time and that's way too expensive. Instead of checking if a node is already in open and updating the cost, this approach uses a consistent heuristic so that every node in the closed set has an optimal path to it. When the "same" node appears twice in open, the cheaper one will be considered first and added to closed. Checking if a node is closed happens in log time, which is acceptable.

The amount of duplicated nodes in open is fairly small and the pathfinder is incredibly fast.

The only thing I could think of to improve efficiency even more is some kind of BlockPos hash...

Correct indentation, use {} for ifs even if the body is just one line

Delete helper classes such as ForgeKeys and JlwglKeys. Find out the standard Forge way of handling keyboard interaction. Implement that.

The onClientTick, onRengerGuiOverlayTick, ... should propagate the tick events to the modules.

It should at all times use the name of the class, not a custom string. Identifying a module using an arbitrary string is error prone.

A user's key-bindings should also be stored somewhere, in a config file for instance.

enum. INTERNAL, AUTOMATION, etc. Also change DropdownModListGui so it won't show INTERNAL mods listed. Category will later also be used to make a click-activation gui where modules are arranged by category.

Visualize the path, starting from location index i. Use openGL, Tessellator, world buffer, or whichever method of Rendering is the preferred custom in Forge.