-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mine: going deep down for ores #24
Comments
Proposed design:
Challenge: we will need to do something to load unloaded areas, but a voxel manipulator in a coroutine is probably only safe to use until the next yield, so will need some care around getting blocks loaded and making the changes, Perhaps try to load a block a little before it is needed and be willing to wait if it is not ready on time. Include some randomness: tunneling, rough stairs, ladders straight down if there are ladders in inventory. Ability to craft torches, stone pickaxes. Other tools need to come by trading/gifting. I'm debating how much attention to safety. Certainly players sometimes are careless and fall, drown or die in lava. We might want a well-defined generic API for simulated mobs, so that there can be simulated interactions in the depths. I am especially thinking about goblins, monsters, etc. |
"The challenge here will be that, naively, the miner will not be active underground unless the player goes along." That's not really a challenge. My mayor bot will keep her block loaded. It's quick and dirty, though. I need to add logic to detect whether she's left her current block, and allow it to be unloaded. We also need to add all sorts of logic for actually tracking villages, and then I can try to get her to wander around the village without leaving it. The challenge with the miner is that he likes to burrow to the depths of Hades, and creating a dangerous pit that he can't get out of. At this level, jobs should be fairly simple: the bot should really just do one task. I want to build more complex logic (ie job-changing) logic on top of this. For example, hostile mobs should go about their business (in the working_villages sense of the word) unless in the presence of a player or otherwise provoked. In my setup, I've got three "miners" with the same logic.
re: tunneling, rough stairs, ladders straight down if there are ladders in inventory. Have you tried the builder? Both the builder and the current miner would have to function more smoothly before combining their functionalities. re: Ability to craft torches, stone pickaxes. Other tools need to come by trading/gifting. I've added a craftsman based on the My dye mixer bot is a predecessor to the craftsman. She tracks the dependencies for her recipes, hinting at the complexity that would be required to write a more generic craftsman, especially if we want to craft the correct numbers of doors, windows, bricks, chests, etc., for, e.g., the builder to complete a task. I think the easiest solution is to use the same craftsman AI with different recipes, to make a carpenter, mason, etc., and then some down stream craftsmen to make things like doors, windows, gadgets, etc. Then there would need to be some sort of middle management AI to decide how much of any given resource should be distributed to a particular job title. I think simulating mob interactions is a heavy feature that belongs in a separate mod. Goblins, monsters, etc., definitely should be separate from this mod. I do intend to create some hostile mobs built on this mod once I get some combat strategies implemented here for e.g., the guard. |
Create a miner who travels deep underground to search for ores. The challenge here will be that, naively, the miner will not be active underground unless the player goes along.
The text was updated successfully, but these errors were encountered: