Skip to main content

Redpower Meets Millenaire, Anno 2070

Update on Minecraft "Millenaire Meets Redpower2" game:

Though I've, thus far, only met the Hindi culture in the game (no sign of Normans, Mayans, or Japanese yet), I've built a few interesting devices in Redpower2 Minecraft to assist me in building their societies:

Unlimited Cobblestone Generator
An unlimited cobblestone generator is simple enough, it just takes a block breaker and a timer, and a transposer is a simple output for the pneumatic tube system.  Of course, the core of this would be the Minecraft mechanic that creates a cobblestone block wherever flowing water and flowing lava meet.

Normans and Mayans are the big users of cobblestone, and if I ran across any of them they'd probably be quite overjoyed with the amount I can produce out of thin air.  I've also got a string of blulectric furnaces set up, so I could potentially give them stone without a spending a single unit of coal!

Theoretically, I should be able to make an unlimited obsidian generator that also works by combining lava and water.  However, it would require I devise a means to make unlimited lava source blocks.  Would having four lava source blocks surrounding a block do it?   The machine that generates the blocks would need to utilize a circuit of buckets (full and empty) making their way back and forth to two deployers, one to fill lava buckets and another to empty the lava buckets.  Likely I would need to use a sticky piston to halt the water flow while a new lava source block is being laid to come into contact with water in order to create obsidian.

Automated Chicken Coop

Chickens lay eggs, and chickens walk around.  Throwing eggs has a 1 in 8 chance of generating more chickens.  So here is a device that collects all the eggs laid by the chickens with a pair of transposers and simply throws them back in the coop again with a deployer.  The entire device is activated by chickens stepping on and off the stone pressure plates.  In theory, the amount of chickens should increase over time until this pen is positively bursting with them.

Come to think of it, I could simultaneously save a lot of pneumatic tubes and expand my chicken coop by placing four transposers with their back to a single block.  Each transposer scoops up an area 3 wide and 2 long.  I could even get more use out of them if I place them in the ceiling... but just how many chickens do I think I need, anyway?

Originally, the plan was to have an igniter convert "extra" chickens into roast chicken legs but for some reason all the chickens kept killing themselves off even though the igniter was separate from the pressure pads that triggered it.  I suspect they were running around in a panic, and maybe it's possible for one flaming chicken to ignite others.  How horrifying!  Perhaps the solution will be to eject the "extra" chickens into the moat and cook them in the monster punishing device.  Speaking of which...

The Monster Punishing Device

I'm so annoyed at all the monsters that linger near my base of operation.  So I basically built the moat to surround my entire base, and have the water continually flow downhill and in one direction until it reaches...

...the monster punishing device.  Once they fall out of the water, they land in front of an igniter and transposer on a timer that goes off every 10 seconds.  The mobs burn to death, and their remains end up in the chest.

Water-based transport is pretty flawless, if you do it right, so once the mobs are in the moat it works like a charm.  I could use some more mobs getting flung in the moat, and there's several such devices that could make it happen, from pistons to snowball deployers.  In my experience, I'd say the most reliable method would probably just be a bunch of water pouring into the moat from all sides, but I would have to be careful not to have the water actually enter the moat or else it would disrupt the directional flow.  Although, if I were to abandon the idea of having the sides of the moat be perfectly straight, I could build a number of "channels" that lead down into the sides, hmm...

I also use the moat transport means to collect the wheat from my...

Automatic Wheat Farm
It actually should not be flooded right now.  I fixed this by breaking the wood block
and placing it down below where it can be retrieved by the sticky piston later.
This is probably an issue caused by the chunk being out of scope, or sleeping in a bed.
Truth be told, it's a pretty lousy wheat farm, for several reasons:
  • First, without the use of Buildcraft distribution transport pipes (I don't have buildcraft installed) or the rather-expensive regulator Redpower component, it's difficult to distribute seeds evenly to all of the deployers which replant the seeds (I'm considering stuffing them full of cobblestone so they can receive, at most, 64 seeds, but 64 seeds per deployer is a lot of seeds!).
  • Second, there's currently no means of detecting when the wheat is ready to harvest.  Instead, I just cycle the water that sends the wheat and seeds to the receiving area off of a series of timers and sequencers.

    One sequencer is set to 300 seconds, another sequencer is set to 75 seconds, and a timer is set to 35 seconds.  When all three activate an AND gate, a cycle is sent to a sticky piston to remove the block that unleashes the water, and 35 seconds later to replace that block.  Every 35 seconds regardless, the timer tells the deployers to replant seeds.  Seeds and wheat that fall on a wooden pressure plate simultaneously activate a filter that collects seeds to recycle into the system and a tranposer that ejects everything else (such as wheat) into the moat.

    The end result is that the field gets harvested once a Minecraft day (1200 seconds) and only has a 75 second (or possibly 110 second if the water is blocking the deployers) down time before the next crop is replanted.  I could theoretically replace all this with a single sequencer, but then the farm would be shut down for half the time, as the seeds cannot be replanted instantly after the floodgate is closed (because the water needs to clear first).  At the very least, two sequencers that would leave the farm flooded for a quarter of the time are necessary.
  • Third, the volume of produced wheat is rather poor.  I currently only have 5 deployers set up, which means a maximum of five wheat per cycle: I'd starve first!  In theory, I could simply duplicate this wheat farm design (perhaps even have multiple fonts of water) until I reach a reasonable output of wheat, but the cost in redstone would be astronomical, particularly if I decide to use regulators after all.

Oh well, while the wheat volume of my Redpower solution may not be great, it's still getting something for next to no effort.  I bet a set of Thaumcraft3 golems could do a better job than this, not to mention something like a Forestry farm, but the thing about those methods is they're sort of too easy - they do all the work for you because they're special blocks programmed to know when to harvest things and do it.

If starving is my concern, I'm better off with my chicken coop setup.  But there's actually several good reasons to have a powerful farm working for me:
  • Millenaire cultures love wheat, it's necessary for their birth rate to climb.
  • I could use the extra wheat to feed cows, sheep, and pigs.
  • I could use the extra seeds to feed chickens.
Come to think of it, the problems and solutions I have found for my farm are very similar to my...

Automatic Millenaire Mud Brick Building Factory

Lets face it, the whole reason I was excited about combining Redpower2 and Millenaire was all about the production of Hindi Mud Bricks for Millenaire.  I'm happy to report that it actually works!

It's actually two factories, due to a glitch:

The first factory (which you can see in the back of the screenshot) uses a deployer along with a brick mould (pardon the British spelling, that's how it's spelled in the game and online resources) to produce the wet mud bricks from sand and dirt.  The brick mould's JAVA code is apparently partially dependent on a player using it, as there are three glitches that come into play:
  • The first glitch is that, oddly enough, each triggering of the deployer will place two blocks: a mud brick block and either a sand or dirt block.  This is easily enough solved by just using two block breakers and a filter to kick anything that's not a mud block back into the deployer.  
  • The second glitch forces manual intervention: if the deployer ever runs dry of mud or sand, trying to deploy the brick mould causes a null pointer glitch that crashes the game. Thus, this whole first factory has been put on a lever to be manually deactivated when resources are low.
  • The third glitch is actually an advantage of sorts: the brick moulds are not consumed when they are used up.  Instead, they just go back to being fully repaired! 

    Or maybe it's just cosmetic, because I am noticing that the deployer seems to have moved further down to the next brick mould... oh well, if it ever reached the end of the deployer queue and simply deployed sand or dirt directly, it'll just kick it back into the deployer and possibly create an endless loop.  This would mean I need to manually replace the deployer every time it burns through 7 brick moulds.
This first factory can produce one mud brick a second provided it has the necessary dirt and sand.  I need to hang around to manually toggle it off when it runs low on either.  The resulting mud bricks go straight into the same chest that's used by the second factory.

 The second factory is simply a string of deployers that place mud bricks, and each deployer is paired with a block breaker that breaks the mud bricks.  I simply have two separate circuits set up to two timers:
  • The first timer is responsible for triggering all block breakers, which (per usual) eject the broken block out the back and (in this case) into the pneumatic tube system.

    If the mud brick has been dried by the sun, it is filtered to a finished brick chest.  Otherwise, the wet mud brick is simply fed back into the wet mud block chest where it can then by distributed back into into the deployers.

    I am currently experimenting with the timing of this first timer to see what is the optimal rate of mud brick "drying" time.
  • The second timer is responsible for the distribution of the wet blocks into the deployers and activation of the deployers.

    Upon circuit activation, a transposer kicks out a single wet mud brick from the chest and through a chain of regulators set to make sure there's no more than 2 wet mud bricks in the deployers at a time.

    It is manually set to the time of the first timer divided by the number of deployers to be restocked.  The reason is so that all of the deployers should be restocked with wet mud bricks by the time the first timer goes off again.  Of course, there's no harm to activating the deployers even if there's already a mud brick in front of them, it just causes nothing to happen.
It's a fairly simple design that has the same advantages and disadvantages of my automated farm:
  • Regulators are expensive, in terms of redstone, and it would be better if I didn't have to use them.
  • Just as I have no means of detecting if wheat is fully grown, I have no means of detecting if a block is dried, and in both cases the amount of time needed is actually randomized.  So I have to guess at it and plan for what happens when I harvest them too soon. 
  • The actual yield of dried bricks is pretty poor, to the tune of maybe 20-30 a day, but that's 20-30 a day without me having to lift a finger!  If I wanted to make more, I could simply expand the design out as far as I like, with the main problem being that this would be an awful lot of redstone.
Honestly, I wonder if it would be better to do Millenaire brick drying semi-manually?  I could just have a line of pressure pads hooked up to a corresponding line of block breakers.  The advantage would be that I would never need to unequip the block breaker; I could just be stepping back and forth from pad to pad, replacing the bricks as they dry.  This would create a greater yield of bricks per day than I would be capable of doing without by eliminating the time involved in switching to a pickaxe or having to dig up the dried blocks.

Overall, I guess you could say I was having fun in Minecraft, but I still feel a bit hallow in consideration of the greater purpose of my activities in the game, which likely will simply be to start over again from scratch in the next major Minecraft revision.

Another Game Entirely: Anno 2070

I gave Anno 2070 a spin last night and, I'm sorry to say, I find the game significantly less interesting than Tropico 4.  That's probably because the focus seems relatively simple in comparison.
  • Your primary goal in Anno 2070 is simply to slap down as much population-buildings as possible, preferably keeping them within accessible range of various service buildings that upgrade the workers to the next level, unlocking more buildings.

    Most buildings have a maintenance cost, but population equals money input, so it feeds back into a loop where all you're really doing is kicking up your population while having the necessary sundries (such as food) to keep them and the necessary building supplies to put down more buildings.
  • In Tropico 4, population does not equal money.  Instead, there's a balance between tourism and the various types of goods produced which makes making money actually quite interesting.  How you should make money this scenario will have a lot to do with what the resource market looks like.  If you simply slapped down population buildings in Tropico 4 as you do in Anno 2070, you'd actually be losing money to maintenence costs and possibly face a drastic increase of unemployment and crime.

    On top of that, buildings in Tropico 4 take time to build.  You're often sitting around waiting for your workers to get around to it, although you can (and should) force building earlier by dumping twice the money into it.  Perhaps this "construction worker dependence" factor, as well as the personalized names of every one of your inhabitants, contributes heavily to the feeling of "life" that Tropico 4 has that Anno 2070 seems to lack.
Completing the first four missions of the Anno 2070 campaign was laughable, but perhaps it was intended as a mere tutorial of seeing if you could figure out how to move units around and build buildings.  That's pretty much all I had to do, as there was no challenge to overcome other than basic interface manipulation: move unit here, move cargo from unit to dock, build certain kind of building.  I then moved on to a "continuous, easy" campaign game and found it to be what I outlined in the bulleted points above: constant population expansion.

All things considered, I'm rather surprised how well-rated Anno 2070 was.  It probably gets more complicated as you get higher-tier workers (I've only reached the third tier so far) but it seems to me that the core interactions are very simple.  It's technically a very solid city builder, but it plays like a spreadsheet, extremely straightforward in execution.  Is the difference between a good player and a bad player in Anno 2070 simply a matter of how fast you can slap down neighborhoods?  That's boring!  Oh well, good thing I got the game half-off.

Comments

Popular posts from this blog

Resonant Induction Really Grinds My Gears... In A Good Way

From about 2pm yesterday until 8pm today, I've been dabbling with my latest custom mod mix for Minecraft 1.6.4, which is this time very much Universal Electricity focused.
Aside from the usual GUI enhancers and Somnia, the primary contenders in this mix were:
Calclavia Core - Of course: this is the base of the Universal Electricity system.Resonant Induction - This seems to be largely focused on increasingly more advanced methods of refining ores divided across 4 ages of technological progression.  It also includes some really cool things such as assembly lines.  I'll primarily be talking about just a few blocks out of this mod today.Atomic Science - A mod dedicated to generating more of those lovely universal electricity volts via the power of splitting the atom.  Build your own nuclear reactor!  Deal with nuclear meltdowns!  You maniac!ICBM - A mod dedicated to generating more destruction using those lovely universal electricity volts (and more than a little gunpowder), it cer…

Empyrion Vrs Space Engineers: A Different Kind Of Space Race

In my quest for more compelling virtual worlds, I have been watching Empyrion: Galactic Survival a lot this bizarro weekend, mostly via the Angry Joe Show twitch stream.  What I have concluded from my observations is Empyrion is following in Space Engineers' shadow, but it is nevertheless threatening the elder game due to a greater feature set (the modding scene notwithstanding).

Empyrion is made in Unity, whereas Space Engineers is built on a custom engine.  While this does put Empyrion at a disadvantage when it comes to conceptual flexibility, its developers nevertheless have a substantial advantage when it comes to adding features due to a savings of time spent that would have gone into developing their own engine.  Examples include:
Planets.  Empyrion already has planets and space to explore between them, whereas in Space Engineers planets are in the works but still awhile away (so you just have asteroid fields to scavenge).Enemies.  Space Engineers' survival mode boasts onl…

Greasing The Grind: Adding Lasting Appeal To Virtual World Sandboxes

Game design, being about entertainment, is not as much science as art.  We're coming up with interesting things that the human mind likes to chew on that "taste" good to it.  Different people find different things, "Fun," and a game designer is tasked with coming up with fun, appealing things.  As pertains to virtual world sandboxes, I identified three of them.

Challenge Appeal.

Dwarf Fortress and Fortresscraft Evolved have the same end game appeal preservation mechanic: wealth equals threat.  The more money your Dwarf Fortress is worth, the bigger the baddies who will come for you, including a bunch of snobby useless nobles who do nothing but push dwarves around and eat.  The more energy you make in Fortresscraft Evolved, the more and bigger bugs come to shut down your base.  Rimworld does something a little different based off of which AI Storyteller you choose, but it generally adds time to your wealth accumulation when deciding what kind of threats to throw a…