Tags
Creators
Details
0.4.0
Compatibility
Required content
Changes
[0.4.0] - 2026-06-19
Built for Minecraft 1.20.1 / Forge, requiring MCA Reborn 7.6.x and Architectury API.
Save-data compatible with 0.1.0–0.3.0 worlds; the new village projects are additive and pre-0.4.0
worlds load cleanly. Datapack breaking change: chain.time_limit_ticks has been replaced by the
new failure block (see Changed/Removed). Network protocol bumped to v2 — client and server
must run matching versions (the project packets are rejected at handshake otherwise).
Added
- Quest failure states & deadlines — a new optional
failureblock makes a quest expire while it's active, with author-controlled triggers and outcomes. Failure is server-authoritative, persisted (the deadline is anchored to acceptance time, so it survives logout/restart), grants no rewards, and records aFAILEDoutcome that follow-up quests branch on via the existingmcaquests:quest_failedcondition.- Triggers (combine freely; first to fire wins):
deadline_ticks(relative deadline),deadline_time(fail at a Minecraft time-of-day, e.g. "before sunrise"),require_weather(fail when the weather stops matching, e.g. "while it's raining"), andfail_on_giver_death(per-quest, independent of the globalfailQuestIfGiverDiesconfig). - Outcomes:
failure_hearts(relationship penalty, or0for non-punitive),retry_after(cooldown before the quest can be offered again), andblock_retry(permanent lock). The giver'sdialogue.failedline is shown on failure; recovery quests are expressed withquest_failed. - A quest already complete ("ready to turn in") is not failed by a time/weather trigger — a grace window to hand it in. All failure paths route through one idempotent handler, so no quest ever double-fails or duplicates a completion.
- Triggers (combine freely; first to fire wins):
- HUD deadline countdown — the quest tracker shows a live
m:sscountdown for quests with a time deadline, turning red in the final minute. Weather/giver-death failures show no countdown. - 3 built-in failure examples —
guard/dawn_defense(kill zombies before sunrise),cleric/urgent_medicine(+cleric/urgent_medicine_recovery, a recovery quest gated onquest_failed), andfisherman/rain_catch(fish while it's raining). - Failure validation —
/mcaquests validatereports afailureblock with no trigger, afailure_heartsmagnitude past the hearts clamp, andblock_retrycombined withretry_after. - Village projects — a new, separate system of shared, multi-stage community goals loaded from
data/<namespace>/mcaquests/projects/**.json. A project's progress is shared (stored in the world save, not per-player), so multiple players contribute toward one common objective. Fully additive and backward compatible — existing quests are unchanged and pre-0.4.0 worlds load cleanly.- 5 scopes decide who shares the progress:
player,villager,family,profession, andvillage. The MCA-backed scopes (family/profession/village) resolve via MCA's village/ relationship data and fail safe (the project never appears) when that data is missing. - Phases run in order — a phase is entered only after every earlier phase completes — each with
its own dialogue, objectives, rewards, and an optional
unlockgate. - 4 project objective types that track shared progress:
donate_item(items consumed and banked into the pool, with an optionalper_player_cap),project_kill_entity,project_place_block, andproject_talk_to_profession. - Shared rewards wrap any existing quest reward with a
target(contributors,all_participants,sponsor_village,top_contributor) and add new reward types (hearts_with_sponsor,hearts_with_participants,village_reputation,unlock). Projects also carry independent mod-side village reputation deltas (on_phase_complete/on_project_complete/on_fail), and a newmcaquests:village_reputationcondition tests a giver's reputation in any quest or project condition tree. - Sponsors (by profession) surface a project via a View Project button in the MCA villager
menu; with
oneSponsorPerProjectPerDayonly one deterministically chosen villager per village offers a given project per day. Contributions are atomic and server-authoritative (items validated and consumed server-side, then banked, then synced); per-phase rewards distribute exactly once, with offline players' non-hearts rewards queued for next login and villager hearts queued via MCA. - 6 built-in example projects:
guardhouse_stockpile,library_restoration,festival_preparation,well_repair,after_raid_recovery, andmissing_villager_search. - Project commands —
/mcaquests project list,info <id>,validate,reset <id>,advance <id>(test-only force-advance), anddebug <id>(explains availability from the nearest villager); list/info/debug at op level 2, validate/reset/advance at op level 3. - Project validation flags unknown scope/objective/reward type ids, missing phases, and
unknown/disabled or circular
follow_upchains as errors, with warnings for empty non-final phases, MCA-dependent scopes while MCA is absent, disabled command rewards, and mismatched reward targets. Hard errors abort the load understrictJsonValidation. - A project menu, quest-log section, and HUD tracker (
showProjectTrackerHud/projectTrackerMaxEntries) surface active projects and their shared progress. - Network protocol bumped to v2. Project sync/contribution packets require a matching client and server; mismatched versions are rejected at handshake.
- 5 scopes decide who shares the progress:
Changed
- The
chain.time_limit_ticksdeadline is nowfailure.deadline_ticks— it works on any quest, not just chains, and gains the richer triggers/outcomes above. The two built-in chain quests that used it (farmer_family/3_apprentice,guard_safety/2_patrol) were migrated.
Removed
chain.time_limit_ticks(replaced by thefailureblock). Datapacks still using it will fail validation; move the value tofailure.deadline_ticks.
Projects on Modrinth are automatically available through a Maven repository for use with JVM build tools such as Gradle. To learn more about the Modrinth Maven API, click here.
Note: When available, you should use the creator's maven repo instead as it will have transitive dependency information that the Modrinth Maven API does not. You may also end up with duplicate dependencies if you use a mix of Modrinth and non-Modrinth Maven repositories for your dependencies, because the group identifier will be different when served through the Modrinth Maven API.
Maven coordinates:
Version ID:
build.gradle:
repositories {
exclusiveContent {
forRepository {
maven {
name = "Modrinth"
url = "https://api.modrinth.com/maven"
}
}
// forRepositories(fg.repository) // Uncomment when using ForgeGradle
filter {
includeGroup "maven.modrinth"
}
}
}
// Standard Gradle dependency
dependencies {
implementation "maven.modrinth:7Cq2Y0Rq:g2dFEKgr"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:7Cq2Y0Rq:g2dFEKgr"
}

