All The Mods 1 added Woot this past weekend, and we began testing Woot with Withers before our players found out. It is extremely OP with the highest modifications. So much so that I couldn't even expand my storage capacity fast enough to collect all the items and XP it was giving me.

We have reduced the settings so that tier 4 doesn't give quite as much and costs a bit more RF to run, but it still completely removes the game's existing limitations on spawning withers: the requirement that the user provide 3 wither skulls.

With Woot, the user only has to manually spawn a wither once, capture it, then press "go" on the farm to get nearly infinite nether stars and xp (I got 50k nether stars in about 8-12 hours).

Don't get me wrong, as a server admin, i love this mod. It drastically reduces the lag that other spawners cause by orders of magnitude.

I'd just like to see the ability to have an input slot so that users would still have to input wither skulls to get withers. This way, they could also have to run a Woot wither skeleton spawner alongside their woot wither spawner to keep things going.

I fully appreciate the OP nature of the Wither Boss, I've just never come up with a nice way to handle it.
I don't want to add internal slots to the factory, however I may have an alternative.

What if I add a config option that allows you to specify a block per spawn, that must be placed
On top of the factory mob controller block. After each spawn the block would be destroyed and need to be replaced. So you could say Wither Boss needs a wither skeleton head.

You could also apply this to other mobs.

This would only be per spawn, so mass upgrades would still only need one block.

The drawback will be that users are going to have to replace the block when their factory is running, meaning using a bud and block placement mechanism running.

Of course you could blacklist Wither Boss but that just seems cruel.

Ha, I agree about blocking Wither Boss being cruel. I really like the idea of having to place a head on top the factory. Yes, they would have to put a block placer of some sort, but they're already doing that right now to place all the required ingredients of a wither plus, they still get the wither spawned in world. Even if they implement one block placer with Woot, it should still be less lag than the current implementations without woot.

I would prefer a chest, which you can give a Item-Input.
So, a wither needs his components as Item-Input and a Dragon needs an Dragon Egg, or the Items from the Draconic Ressurection ritual.

Right now, Woot is kind of OP, but this could reduce it.

I've been thinking about this a little this week. We have a chest for loot output, couldn't we also have a chest (instead of an internal inventory) for spawning requirements (i.e. chest full of wither skulls to spawn withers)? A single skull on top the factory is still better than nothing, but I'd like to see wither spawning get a bit more expensive for the players.

It is more down to the extra cpu time to parse the items in the chest. I've always wanted to have a low footprint. Now I could be a little paranoid there.

I suppose if I was only checking at the very end of the spawn time it would have a limited impact.

Going to bump this to the next release.

Once I've tidied up the 1.10.2-1.3.0 release, I'll be adding something for this.
If I can find a nice, efficient way of scanning a chest (I hate inventory checking) and of making it configurable then I'll go with the chest idea. If not it will be the simpler block version.

Something has to happen. I started on a new server last week (probably thursday) and today I have 308,000 supremium essence because the Wither gives 2 supremium essence when it dies (default Mystical Agriculture setting). I also have 114,000 nether stars, which I'll never be able to use. That's even though I'm running 4 nether star generators (extra utilities 2) producing 300K RF/tick

Maybe with the block idea you could add a "wither block" that is crafted with 4 soul sand and 3 wither skulls. This would keep the same requirements needed to spawn the wither. It would also make players use the decapitation upgrade more, since wither skulls are the ones you need the most typically.

Oh... I am looking forward to the possibility of making it more hell for my players. :)

I don't know how difficult it would be, but have you seen BuildCraft's buffer? it has the requirement to lock slots before a player can place in items. So.. With that in mind.

• This would be an augment block
• It would read the config for the item stack required to spawn in mobs.
• It would set one slot locked to that item
  • Would be cool if you could specify two blocks per mob type.
• When placed on top of your mob factory, since you already set the slot that will hold the inventory, you only have to check that one slot.

I have no idea how difficult this would be

Another take on this suggestion, you could add a fluid requirement to spawn in particular mobs. This would be an Either/Or with the blocks I would think.

• Any mod added tank
• Fluid required per operation
• Config for if the efficiency upgrade reduces fluid required

The one thing that I really want to avoid is having any sort of inventory/gui, mainly because I had writing that sort of code and my guis are always ugly.
For 1.10.2-1.4.0 I'm going to try and come up with something flexible to (hopefully) allow a good few options for people to configure extra spawn requirements. Fluids hadn't occurred to me, so I'll see if I can work that in as well.

So as long as nothing gets in the way this weekend, I'm going to start implementing this - even if I do hate JSON parsing.

So the initial plan is to look at the block above the Mob Controller when it is time to generate the loot. That block can be a tank or inventory. The code will then check that block to see if the requirements are met. If they are not met then that loot generation is aborted and the power process starts again.

The inventory will be anything that implements CapabilityItemHandler.
The tank will be anything that implements CapabilityFluidHandler.

The will be configured via a json file a bit like the one below.
You will be able to specify it on a per mob - per enchant level.

The reason I'm using the block above the Mob Controller is that it gets round any chunk boundary issues.
The other reason if that there are no faces on the factory block left!
(For 1.11.2 I'm going to move the upgrades back one block, to give some more flexibility in this, so you could have a chest on the left and tank on the right ... but let us not get ahead of ourselves here!)

Nothing will be configured by default, it is all for the user to specify if they want to use this feature.

eg. To get the drops for a Sheep with no looting, you would need 4xglass, 1xegg.
(The chances of this being valid JSON are 0, but you get the idea)

{
"spawn" : [
    {
        "mob" : "Woot:none:Sheep",
        "reqs": [
            {
                "no_enchant" ,
                "items" : [
                    {
                        "name" : "minecraft:glass",
                        "meta" : 0,
                        "size" : 4
                    },
                    {
                        "name" : "minecraft:egg",
                        "meta" : 0,
                        "size" : 1
                   }
                ],
                "fluids" : [ ]
            },
            {
                "looting_i",
                ......
        ]
    }
   ]
}

How about on right click it says what the item is that is missing? You could just pull the localization for it.

On the other hand since mod pack makers are the ines changing things, they sould let players know how to do things.

@bookerthegeek - leaving it up to the mod pack makers was one of the options :)
I dont want to do the "what is missing" as that would mean checking what is present. To reduce the CPU usage, I'm only checking the contents of the chest/tank once per loot drop.

I've managed to get the fluid and items working, however they are still mutually exclusive.
An example config file is below.
Stacks are currently limited to the max stack size - ie. 16xender pearls.
Fluids are limited to one fluid.

I'll probably try and get a test-release up somewhere (not Curse as even if I mark it Alpha someone will put it in a modpack!) for people to play with, as this is going to need some testing in terms both of "does it work" and "is it flexible enough".

And I'll say it again, I had writing JSON parsing code ;(

[
  {
    "mob": "Woot:none:Sheep",
    "enchant": "NO_ENCHANT",
    "items": [
      {
        "item": "minecraft:egg:0",
        "amount": 4
      },
      {
        "item": "minecraft:wool:4",
        "amount": 1
      }
    ],
    "fluids": []
  },
  {
    "mob": "Woot:none:Zombie",
    "enchant": "NO_ENCHANT",
    "items": [
      {
        "item": "minecraft:apple:0",
        "amount": 64
      },
      {
        "item": "minecraft:iron_ingot:0",
        "amount": 4
      }
    ],
    "fluids": []
  },
  {
    "mob": "Woot:none:Spider",
    "enchant": "LOOTING_I",
    "items": [],
    "fluids": [
      {
        "fluid": "water",
        "amount": 1000
      }
    ]
  },
  {
    "mob": "Woot:none:Spider",
    "enchant": "NO_ENCHANT",
    "items": [],
    "fluids": [
      {
        "fluid": "liquid_sunshine",
        "amount": 1000
      }
    ]
  }
]

So question: is the "enchant" line useful or would you prefer it to apply the same requirements to all three looting levels? It could get repetitive as just now you have to put an entry in per-looting level.

The itemstack part is sort of working, not sure how to handle fluid name to fluidstack, but we will get there.
Interesting issue though ...... how does the user know what the extra requirements are ???????
JEI recipe handler would be the obvious one, but that is going to take a bit of effort.
Another option would be right-click the block and it will dump the information along.

Each mob can have items defined or a single fluid.
Different fluid per mob type.
I'll change the code to drop the enchant specification.

When you say exclusive, i assume you are refing to each mob, not the entire config?

And only one fuild, same flyid for all mods or one fluid per mob type?

Also, per mob and not per enchant level would be good enough and reduce the amount of code I would think.

By default I will be shipping the mod with no extra requirement so defined. This is only so mod pack makers or server owners can make additions if they want.

i don't see any points in the heads, they just add server load as they have to be generated, so it'll end up with 2 woot farms for most players, one which delivers heads and the other which delivers Netherstars.

It's nice as it is. my opinion :p

So I'm getting there with this support. I've removed the enchant section and added a boolean control for efficiency. If you set that to true then the efficiency upgrades will reduce the required items/fluid per mob.
And of course the required items/fluids you define are treated per-mob, so that mass upgrades will require more items.

I'm just trying to sort out any crashing when removing items from the chest, turns out you have to do that by hand, there are no helper functions :(

It is in, it is done.
Hopefully I've not broken anything.

@Ipsis you have a build for this somewhere?

• I need to test the hell out of this for you
• I look forward to unleashing this on my players once released.

Just uploaded one to Curse.
After upload I found out it wont start a server for some silly reason, but you can certainly use it on a client.
(I'll put a server friendly alpha1 up when I've fixed it)

The config file is partially explained on the wiki.
I've not done a lot of testing on the release - hence the alpha status.

May I have permission to edit your wiki please? Just for clarification and beautification. just the section here

Only reason being that below is more readable. Also, to point people to an online json formatter to validate their config file.

[
  {
    "mob": "Woot:none:Sheep",
    "efficiency": true,
    "items": [
      {
        "item": "minecraft:egg:0",
        "amount": 4
      },
      {
        "item": "minecraft:wool:4",
        "amount": 1
      }
    ],
    "fluids": []
  },
  {
    "mob": "Woot:none:Spider",
    "efficiency": true,
    "items": [],
    "fluids": [
      {
        "fluid": "liquid_sunshine",
        "amount": 1000
      }
    ]
  }
]

Also, the Efficiency upgrade increase, is that an [amount required] * [Efficiency Level] or [amount required] + [Efficiency Level]?

If I specify Items, do I need the Fluid Field and vice versa, or are both required even though we can only use one?

Is the Efficiency field required, if not does it default to true or false?

Will any inventory work for items, or only chest like blocks, or only Vanilla Chests?

I tried to format that json in the Wiki page and failed :( (I've fixed it at last, I found the magic inline symbol combination)

I'm not sure how to setup extra permissions for the Wiki - maybe just a pull request ?
(It seem to be a public Wiki or only me - doesn't have anything in-between that I can find)

The calculation I've used is below - if that helps - with efficiency maxing out at 30%

needed = stacksize * mobcount
saving = needed * efficiency %
stacksize = needed - saving

Just take the entire code block and replace it with this here. It will look all nice and pretty like.

You can learn more here about formating Code Blocks, and this is a good resource for getting your Wiki layout just the way you want.

I uploaded the alpha1 that works with servers .... I hope!
https://minecraft.curseforge.com/projects/woot/files

Will only show up on CurseForge, as it is an alpha.

So if i delete "factory_ingredients.jason" woot will go back to the way it was and only require energy for mob spawns right?

Sorry didn't see this. No, you have to edit factory_ingredients to remove the requirements. If you delete the file it will recreate it.
I think the following should work for you - assuming you are running MC 1.12.2.
{ "version": 1, "ingredients": [] }