I'm up way too late (past midnight, still have chores to do before being able to sleep! Work early tomorrow), but I've had an odd urge to implement a tool bar of sorts, even though I realize I should still be focusing on project organizing 
So I went ahead and did so - very primitive, lots of hacks, first draft, no added "tools" yet - but pushing it out there for early review in case it looks handy
https://github.com/Cervator/Blockmania/ ... 3ae560da5c
It is one more step on my silly quest to implement a "slime-shooting gun" via the Groovy plugin system to validate that - but I can't do that until we can select a mode in which we can do stuff other than place/remove blocks! And now we can. In theory
In keeping the focus on building plugin support in at the ground level the "hot bar" can contain both native actions in Java (place/remove block) and custom actions in Groovy via plugin files. That's not done yet, but the foundation is there.
Some of the naming is still inconsistent - will fix soon. The _selectedTool in the new ToolBelt class really should be more of a selected hot bar slot, so it'll make sense in the future with an inventory from which you can drag and drop tools or even blocks. When a tool action is triggered (which is handled by ToolBelt now instead of in Player) the new gadget looks up what it has mapped to that hot key / tool slot entry and performs the related action. That should work the same for native Java tools as well as for Groovy plugins, there's just an extra lookup for the Groovy tools.
Note that on graphics especially I'm taking shortcuts, so the new spinning cube in the lower left is misleading - it doesn't at all relate to what block you're placing, instead if you've got the dirt block there (default, active in "slot 1") then you'll place whatever the right spinning cube represents.
You can select both with 1-10 (1-0) and use the mouse scroll wheel
Lots of assorted logging active so it is easier to see how everything works
More to do, lots to refactor, but feedback appreciated! I'm not very sure if it is structured sensibly, nor exactly where to put the rendering of the new thing (when eventually it'll actually be represented by appropriate graphics). I just cheated and copied an existing method
To add a new "tool" put a new case in the switch inside ToolBelt.activateTool and be sure to add a statement in the constructor to add it to the _toolBinding map. There's a boolean provided to differentiate between left-button and right-button actions
So I went ahead and did so - very primitive, lots of hacks, first draft, no added "tools" yet - but pushing it out there for early review in case it looks handy
https://github.com/Cervator/Blockmania/ ... 3ae560da5c
It is one more step on my silly quest to implement a "slime-shooting gun" via the Groovy plugin system to validate that - but I can't do that until we can select a mode in which we can do stuff other than place/remove blocks! And now we can. In theory
In keeping the focus on building plugin support in at the ground level the "hot bar" can contain both native actions in Java (place/remove block) and custom actions in Groovy via plugin files. That's not done yet, but the foundation is there.
Some of the naming is still inconsistent - will fix soon. The _selectedTool in the new ToolBelt class really should be more of a selected hot bar slot, so it'll make sense in the future with an inventory from which you can drag and drop tools or even blocks. When a tool action is triggered (which is handled by ToolBelt now instead of in Player) the new gadget looks up what it has mapped to that hot key / tool slot entry and performs the related action. That should work the same for native Java tools as well as for Groovy plugins, there's just an extra lookup for the Groovy tools.
Note that on graphics especially I'm taking shortcuts, so the new spinning cube in the lower left is misleading - it doesn't at all relate to what block you're placing, instead if you've got the dirt block there (default, active in "slot 1") then you'll place whatever the right spinning cube represents.
You can select both with 1-10 (1-0) and use the mouse scroll wheel
Lots of assorted logging active so it is easier to see how everything works
More to do, lots to refactor, but feedback appreciated! I'm not very sure if it is structured sensibly, nor exactly where to put the rendering of the new thing (when eventually it'll actually be represented by appropriate graphics). I just cheated and copied an existing method
To add a new "tool" put a new case in the switch inside ToolBelt.activateTool and be sure to add a statement in the constructor to add it to the _toolBinding map. There's a boolean provided to differentiate between left-button and right-button actions
