1.1.0
Compatibility
Changes
Pueblo Vivo
Pueblo Vivo is a Forge 1.20.1 mod that turns vanilla Minecraft villages into living settlements with reputation, contracts, builder villagers, shared resources, threats, chronicles, and Age-of-Empires-style progression.
The goal is to make villages feel alive without replacing Minecraft's vanilla identity. Pueblo Vivo uses vanilla villagers, vanilla blocks, vanilla items, and vanilla-style systems to create a deeper settlement gameplay loop.
Main features
- Player reputation with villages.
- Village contracts and rewards.
- Citizenship Module for village management.
- Village stats: food, security, prosperity, fear, trust, morale, population, beds, and golems.
- Village projects such as walls, wheat fields, houses, torch zones, watchtowers, wells, corrals, and plazas.
- Builder villagers that visually move between the storage chest and construction sites.
- Gradual construction, block by block.
- Village storage chest used as a shared warehouse.
- Dynamic village traits and specializations.
- Living village ages: Refuge, Village, Villa, Bastion, and City.
- Emergencies based on real village conditions.
- Threat phases such as rumors, scouts, dangerous nights, and small attacks.
- Village chronicles that remember important events.
- GUI panels for reputation, contracts, projects, and citizenship.
Vanilla-friendly design
Pueblo Vivo is designed to stay close to Minecraft's vanilla style.
It does not add custom entities or custom blocks. The mod focuses on systems, progression, villagers, vanilla items, vanilla blocks, and gameplay depth.
Current status
Pueblo Vivo is currently in beta. Systems are playable, but balance, UI, village behavior, and progression may continue changing based on player feedback.
Requirements
- Minecraft 1.20.1
- Forge 47.x
- Java 17
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:eHek4dwc:rpNRaMns"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:eHek4dwc:rpNRaMns"
}

