Skip to content

[Suggestion] Extend the Ore Duplication Process #9

@mijsm

Description

@mijsm

Now, I'm pretty sure you've got something in the works for this, but I have a suggestion anyways. Doesn't hurt to toss ideas on the pile. :)

Make ore duplication (or an alternate method of) involve smashing a block multiple times, instead of just once. Currently we see the pistons activate and immediately smash the ore blocks into items. The automation for this is a simple exercise since you know that after one piston cycle the next set of ore needs to show up.

It would be interesting to have an extended process (again, possibly alternative or optional) which promoted users deal with the variable of when the blocks would break and need to be replaced with a weighted random breaking point. This would encourage cross-mod interactions to help solve the puzzle, with things like ComputerCraft, OpenComputers, ProjectRed and MineFactory Reloaded immediately jumping to mind. And it would still be manageable with vanilla redstone circuits.

Here are some ideas on how to implement this:

Similar structure as the current setup. Ore are placed, then the smashing block is moved downwards to touch the top of it, causing the smashing to happen. Instead of it breaking immediately into items, it...

[high chance] Does not break the ore, does not drop an item.
[low chance] Does not break the ore, drops an item.
[low chance] Breaks the ore, drops an item.
[optional low chance] Breaks the ore, does not drop an item.

Throw the percentages in a config file and set the defaults to your desired average outcome. This gives users the option to fiddle with balance themselves.

I'm not experienced with MC programming, so I dunno how you'd wanna implement this. Some things to consider:

Adding a cap on how many ingots you can get from a single ore/how long a single ore block may take to be processed is probably a very good idea. One method of doing this is to have this structure not accept the ore blocks themselves, but instead take a converted block from another processing step. Burn them into a rich slag, for example. Another method would be to simply convert placed ores into a placeholder block (can a block have a dynamic texture so it still appears the same as it's source?) which has damage values that are altered with each cycle of the smashy structure. Placeholder blocks that could be reduced in size/changed in appearance would make this visually appealing.

Why would this be a good idea? Because it adds more variables to the puzzle that the user solves. They need to account for how long each block is going to be in the processor when automating the system, as well as how to deal with semi-random output. Additionally, I just like the mental image of my ore processing plant having a place where I can watch as pistons (or whatever) smash furiously to turn my rough ore into precious, precious metals.

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions