💡 Check the Wiki and
Feature Request Tracker
before reporting a feature request.
There you can find a lot of useful information and solutions for common problems.

Is your feature request related to a problem? Please describe. 🤔
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
I'm frustrated when I look at the wiki and it doesn't explain what mobs can be farmed in each type of mob farm (ie. plains, desert, swamp, etc.). How can I figure out what mobs go in each type of farm?

Describe the solution you'd like 💭
A clear and concise description of what you want to happen.
Add a section to the wiki explaining what mobs can go into each farm type, and maybe a suggestion in the description in-game.
Describe alternatives you've considered 🔄
A clear and concise description of any alternative solutions or features you've considered.
I've considered doing testing on my Config and Testing world, but that would take valuable time that I don't have to spare.

Additional context 📝
Add any other context or screenshots about the feature request here.
Saying a mob is "arid" isn't good enough, unless they are described as such on the Minecraft wiki itself, and I'm being stupid (or need to configure something).

Thanks for the feedback. In the new version, there are no restrictions on "which mob can go into the farm." All mobs will work in any farm type, as long as there is a corresponding loot table for their drops.

Some farms, however, offer bonus drops when specific mobs are used, such as bees in the bee hive farm.
These bonuses can be adjusted via the configuration files if needed.

I'll update the wiki to include an overview of these bonus drops and will ensure it clearly states that there are no default restrictions on mob compatibility.

Thanks for pointing this out!

And on the topic of adding to the wiki. . .

What's this thing???
I couldn't find anything on the wiki and I haven't seen that number change.
Is it something from the old system or something?

Yes, you have the right idea! A simplified status system could be easier to understand (-1 for error, 0 for idle/full, 1 for operational).
However, the current setup adds extra granularity for debugging, automated-testing and helps distinguish between different "not running" states (like IDLE vs FULL).

IDLE (Status: 0): This state is reached when the farm isn’t doing anything because there are no inputs to process (e.g., no mobs or items queued). It’s essentially "waiting for work."

IDLE = no input → farm doesn’t start., does nothing.

FULL (Status: 400): This state means the farm can’t process more because its output storage is full. The farm pauses all operations until space is freed up.

FULL = no output space → farm stops mid-operation, checks regular if output storage is freed up.

As mentioned, I will include a human-readable status message in the next update.
However, if you have a specific need for a simplified status (for scripting, modding, ...), please let me know!

I did not realize the [ i ] was still there when no mobs are inserted. That's my bad. 😅

What's this thing???
I couldn't find anything on the wiki and I haven't seen that number change.
Is it something from the old system or something?

The new farm is built on an entirely new codebase, meaning no remnants of the old system remain.

Currently, the farm uses numeric codes, similar to HTTP status codes, to represent different statuses. For example:

IDLE: 0
PROCESSING: 102
WORKING: 200
FULL: 400
DISABLED: 401
ERROR: 500

These codes were chosen due to limitations in syncing text between client <-> server, as only items and numbers could be synced. However, in the next update, I plan to replace these numeric codes with more user-friendly, readable text to improve clarity and usability.

Ok. . . but I still don't know what the "status" stat refers to.
Ya know, the thing I asked about and circled in big red ink. 😅

Like, all the other stats in the intel box are self explanatory. Don't take this the wrong way, but I can't tell if your response was even addressing the initial question that the post was made for; if the response was just hyper-focusing on the last part rather than the main question or if your response was just too technical to easily explain what the "200" was trying to tell the user. Or is it even telling the player anything to begin with?

Can you help clarify that initial inquiry.

EDIT:
After re-reading. . . I think what you were were trying but failed to get at. . . maybe. . . is that "status" is supposed to say if the farm is ON or OFF??? If that's what it refers to, why not do 0 and 1 instead since it's a binary state anyways? It's either that or you meant to say it's just a debug stat and not actually useful information to the player.

The "status" stat represents the current state of the Mob Farm. Here's what the different status codes mean:

• Status: 0 - The farm is "idle", so not doing anything.
• Status: 200 – The farm is "working," actively processing items or mobs.
• Status: 400 – The farm is full, so it can't process anything until space is freed up.
• Status: 102 – The farm is generating drops (only appears when progress is at 100%).
• Status: 500 – Something is wrong, and the farm isn't processing loot drops.

It's good that you haven’t seen status codes like 500, as it indicates an error. Most of the time, you should only see 200 or 102 when the farm is running smoothly.

English is not my native language, so I may occasionally mix things up.
Apologies if anything is unclear!😅

So one is a debug state, another is a state that would only exist for a single frame (thus unneeded outside of debugging as well), one just says that the farm is pretty much doing farm stuff. . . That just leaves IDLE and FULL. When these statuses are reached, is there a behavior difference between what happens in IDLE vs what happens in FULL?

How would one even achieve a Status-0??? If it's not actually a state that exists in normal gameplay, is it even worth giving a value? Or I'm guessing FULL still progresses the processing bar till it reaches 100%, after which it then switches from full to idle maybe?

Cause for simplicities sake, we coulda broke this down into "-1" for error, "0" for not running (due to status-400 or status-0) and "1" fully operational.

Do I have the right idea?