Guild
The guild is the part of Shakes & Fidget most likely to be missed, because most of it happens at a time somebody else picked. A guild fight is announced, and if you are not there to ready up, you are not in it.

Turn it on with auto_guild.
What it covers
| Task | Setting | Default |
|---|---|---|
| Guild portal | auto_guild_portal | on |
| Hydra | auto_guild_hydra | on |
| Raids | auto_guild_raid | off |
| Attack ready-up | auto_guild_attack | on |
| Defence ready-up | auto_guild_defense | on |
| Take part in attacks | guild_fights_attack | on |
| Take part in defences | guild_fights_def | on |
| Take part in raids | guild_fights_raid | off |
The daily guild instructor and the fortress donation are handled alongside these.
Readying up, and the timing rule
This is the part that used to be wrong in a way worth documenting, because if you have used an older build the behaviour you remember is not the behaviour now.
guild_min_wait_mins and guild_max_wait_mins describe how long to wait before readying up for a fight you have just been told about. The wait is drawn from that range starting when the fight was first seen, which is what "wait 5 to 40 minutes" plainly means.
The draw varies per fight but is stable within one, so the bot does not change its mind between cycles. And it is clamped: a delay that would land after the fight has started readies up one minute before it instead, because a late ready-up is worth nothing.
What it used to do
The old rule anchored the window to the fight, not to now, and drew the delay from a hash of the character's name. So "min 5" did not mean "wait at least five minutes", it meant "do not ready up until the last five minutes before the fight", and a character whose name hashed low did nothing at all until the fight was nearly over.
It was also not random. The same name produced the same delay on every fight, forever. The reported symptom was "it will not ready up for attack or defence with min 5 and max 40, I have to turn the setting off before it readies up again", and turning it off setting both bounds to zero is exactly what made it work.
Both bounds at 0 still means "ready up immediately".
Ordering against the rest of the day
| Setting | Default | What it does |
|---|---|---|
guild_portal_after_quests | off | Hold the portal fight until the day's questing is done. |
guild_hydra_after_quests | off | Hold hydra fights until the day's questing is done. |
guild_hydra_rush_before_midnight | off | Push hydra fights through before the day rolls over. |
The two "after quests" settings are separate on purpose. The hydra gate used to read the portal's setting, so switching on "portal after quests" silently delayed hydra fights as well and there was no way to want one without the other.
Scheduled raids and fights
For guilds that run on a schedule, the start times can be set rather than waiting to be told:
start_guild_raid,start_guild_raid_datetimefor a one-off,start_reoccurring_guild_raid_dayandstart_reoccurring_guild_raid_timefor a weekly one,start_guild_fight_1/start_guild_fight_2withstart_guild_fights_time_1/_2for the daily fights,guild_fights_favorite_guildsfor the opponents you would rather draw.
Guild upgrades and donations
All off by default, because they spend guild resources and that is a decision for whoever runs the guild rather than a sensible default.
| Setting | Default |
|---|---|
guild_upgrade_treasure | off |
guild_upgrade_master | off |
guild_upgrade_pet | off |
guild_upgrade_max_level | 0 (no cap) |
guild_donate_mushrooms | off |
guild_donate_mushrooms is the catapult donation, and it costs real money. It is off, and it stays off unless you turn it on.
guild_donate_long_cityguard_only restricts donating to the times the character is on a long city guard shift anyway, which is the cheapest moment to do it.
See also
- Hellevator for the guild hell attack signup
- Battle simulator for previewing a guild fight
- Settings