Project Zomboid mods
built from scratch

Original ask, last of four ideas from the same commenter: "A RTS overhaul ~ Very Hard". RTS means real-time strategy, like StarCraft or Age of Empires: a top-down view, selecting several units, giving them orders. The commenter gave no more detail. The answer was that it could be possible but is insanely hard and time consuming, so for now it goes to the long list.

What exists (Workshop search, Build 42 tag): nothing named RTS (4 results, none related). Nearby pieces, read from the Workshop listing only: Companion Command (638 subs; recruit survivors and give orders; needs Bandits2 and PZ Plus), Week One Command Wheel (1,009 subs; radial menu for Bandits Week One NPC commands), NPC Bases (Bandits Settlements) (18,790 subs), and the NPC mods they rest on, Bandits NPC (over 1,000,000 subs) and Week One NPC (330,010). None of them has an RTS camera or box selection.

Plan, untested: it would need an NPC system to command (the only one in Build 42 is Bandits NPC), a camera and selection of units like an RTS, and an order system, most likely with Java work. It is a very large project and is not planned in detail. Classified as Long by the user's decision.

Original ask: a freecam mod for Viewpoint with two things the current one lacks, for cinematic and editing shots. 1) A truly slow camera speed: the commenter says the slowest speed of the current one is about 2 mph, too fast for cinematic shots. 2) Being able to move your character while in the freecam; it does not matter if the freecam is driven by numpad keys (4, 5, 6, 8), which is how it is usually done. The commenter is not sure it is possible and does not name the "current" freecam they mean.

What exists (Workshop search, Build 42 tag): no true freecam found. The Workshop returned nothing for "freecam". Pages opened: Project Viewpoint Free Look (OSHZAK, 428 subs: hold ALT to look around without turning the character, walking recenters; needs Viewpoint and ZombieBuddy), Viewpoint: Director's Cut (Azakaela, 1,028 subs, updated Oct 11: cinematic cameras, tank controls and an invisible "Cameraman" that follows, wanders or stays put, directed with [ ] - = keys; its page never mentions a freecam, slow speed or numpad), Camera Tweaks for Viewpoint (coco, 4,015 subs: first-person fixes), Vanilla Camera Expanded (386 subs: photography with the game's cameras), LT Spectator Mode (19 subs: server admin spectating other players). Seen by title only: Immersive Camera Motion, Animated Camera Follow for Viewpoint, OldPoint, Viewbob / Cinematic Camera, Death Cam Mod for Project Viewpoint, CAM (NVThay).

Plan, untested: Free Look and Director's Cut show that Viewpoint's camera can be moved independently of the character, so a freecam with a very slow speed and a character that keeps moving looks possible. What I do not know is whether Lua alone is enough or it needs Java through ZombieBuddy like those mods; this PC has no javac, so a Java part could not be built here. Which keys drive it (numpad or others) would be rebindable. Classified as Long by the user's decision because of the likely Java work on top of Viewpoint.

Original ask: a counterpart to the trader mod I already made (Zamazon), more in-game and less "meme", very straightforward without a million bells and whistles. Players can sell items; admins can set up shops that buy and sell infinite items; players can claim whichever container they want, or a custom model could be made. Meant for dedicated servers. A follow-up from the commenter: they only tried a few of the many existing ones (no names given), one had a dev who did not troubleshoot a problem, another lacked obvious features such as infinite items from an admin shop. They want a good economy that feels authentic and lets admins add gameplay on top.

What exists (Workshop search, Build 42 tag, many pages): Player Shops by RFAlias (page opened, 805 current subscribers, 37 updates, last on Aug 31) already does most of this: convert almost any real container into a player shop kiosk with dollar prices (works while the owner is offline), admin-only Pawn Shops that buy items from players at set payouts, admin-only Vendors with unlimited stock, a cap on kiosks per player, a sale log file, and sandbox options for money drops and zombie wallets. Its comments report that money kept in backpacks or fanny packs was not charged on purchase; the last update says it fixed that, which I could not confirm. Requests still open there: paying with another item, selling cars. It has no custom counter model. Shops and Traders by Chuckleberry Finn (page opened, 62,320 subscribers, 104 updates, last Sep 4) assigns admin or player shops to any object; its description is short and does not say whether admin shops sell infinite stock. Also opened: SellAndShop (289 subs: admin shop plus player marketplace, Z-Points), OnionTrader (5,969 subs: placeable admin traders), Functional Vendors (1,675 subs: vending machines). Seen by title only: Traka - Player Shops, SimpleShop, Shops Expanded, PhunMart 2, Merchant Economy, Delirium Shops, Just Another Shop Mod, Shops B42 (discontinued).

Decision: the user wants a version better than Player Shops. Classified as Long by the user's decision: a multiplayer economy needs kiosk, admin-shop and payment syncing on a dedicated server, and beating Player Shops means covering what it does and adding something of its own, such as a custom counter model. Nothing designed yet; what "better" means is still to be decided with the user.

Original ask: a mod adding Jungle Jim's armor from the '68 series. '68: Jungle Jim is an Image Comics zombie series set in Vietnam; one web description of the character mentions a burlap-and-bamboo costume and a gas mask. I have not seen the exact design, so the list of pieces is still to be decided. Checked the Workshop's own search (Build 42 tag) for "jungle jim", "jungle armor", "bamboo armor", "burlap" and "vietnam": no mod found that adds this. The armor searches have 781 and 624 results and only the first page of titles was read.

Why Long: the work is the art — wearable clothing needs its own 3D models and textures, fitted to the character, built with the same Blender pipeline as my other mods. The code side is small: protection values and which body location each piece uses. Not tested yet, and the exact pieces (mask, body armor, others) are still to be defined.

Original ask: a mod that adds skeletons or bone piles to the world as textures that never disappear, purely for atmosphere, in the spirit of 10 Years Later. Checked the Workshop's own search (Build 42 tag) for "skeleton", "bones" and "corpse": no mod found that does exactly this. The closest ones are Trash and Corpses B42 stable (scatters trash, glass and corpses or skeletons as bodies, with a decorative-only mode) and Lasting Remains (turns expired zombie corpses into skeleton decals, singleplayer only). Neither places loose bone piles as permanent scenery.

Decisions (Oct 10, 2026): same feel as 10 Years Later (an abandoned world years after the outbreak), but with bones. Built as a script that places the sprites on map squares as they load, so it works on any map; if that turns out badly, fall back to baking them into the map data like 10 Years Later does (much heavier, map by map). Own artwork: if the vanilla skeleton sprites don't fit as ground decoration, new bone and pile textures will be drawn. Decorative only, no loot and no mechanics.

Why Long: the bulk is the art (several kinds of bone pile, skulls, ribcages, animal bones, packed into .pack/.tiles), not the code. Open points, untested: whether the vanilla skeleton sprites are usable on the ground, and how many decals the script can place before the save grows too much (the author of Lasting Remains warns about this on busy servers).

Original ask: Refresh Minimal Display Bars (drunkmunk, 3744180656) doesn't work for me, and I don't want just a reset fix — I want my own version of the Minimal Display Bars mod: same design and style, one single standalone mod (no other mods required), working properly, with every kind of way to change the settings. The reset fix (bars vanishing after pressing Escape in B42.19+) goes inside the mod itself, automatically, with no hotkey.

Verified with real code before tracking this: the base mod (Vorshim's Minimal Display Bars Nutritions B42, 3388844542) is ~5,400 lines of pure client Lua — the bars themselves, a properties panel, a text-entry box and a color picker. It reads standard Lua-exposed getters (hunger, thirst, endurance, fatigue, stress, boredom, unhappiness, temperature, health) and draws on OnRenderTick. No Java patch and no ZombieBuddy needed. The original idea is by ATPHHe (MIT license, credit required); the latest standalone 42.21 port (osushi256, 3775659041) still has unresolved errors and crashes, and running two bases at once duplicates the bars — which is why a clean from-scratch build is worth it.

Why this is Long by volume, not by technical risk: the core (draw the bars, read the data, re-add them after the Escape menu closes) is short. The real bulk is the settings system: position, size, orientation, color, icon, visibility, thresholds, moving bars individually or together, presets, and safe saving to a personal config file. No technical blocker found.

Original ask: an addon for [B42]Project RV Interior (Mickey Knox, 732,367 subscribers, the real working B42 remake — the original Maxwelt mod is B41-only and broken on B42) giving Sandbox Options to raise/lower the spawn rate of each of the ~70 vehicles it's compatible with (vanilla and third-party: KI5, Autotsar, Filibuster's Used Cars, Doomsday MotorHome, Winnebago Chieftain, etc). Checked: neither Project RV Interior itself nor Doomsday MotorHome (another popular RV, 44,351 subscribers) has any such option — real gap. Also checked RV Interior Expansion [B42] (Caçador) in case it already solved this: no, that one adds new interiors to more vehicles, doesn't touch spawn rate.

Verified with real code, not the Steam description, before tracking this (verification pass requested explicitly): vanilla's VehicleZoneDistribution.lua is a global Lua table the file's own comment says is meant to be altered by mods. Confirmed in KI5 Trailers' actual code (already installed) that each vehicle registers as VehicleZoneDistribution.<zone>.vehicles["Mod.Vehicle"] = {index = -1, spawnChance = N}, repeated per zone type it can spawn in. Of the 270 mods currently subscribed, 47 use this exact table (including Filibuster's Used Cars and Autotsar Trailers) — the real community standard, not a guess.

Why this is Long by clean volume, not by technical risk: a generic function can loop every known zone and scale a vehicle's spawnChance wherever an entry for its ID exists, with no need to know in advance which zones it uses. Any outlier that doesn't follow the pattern (e.g. Doomsday MotorHome, which warns "you must create a new world" and ships its own map — not confirmed, not among the 270 subscribed mods) simply has nothing to scale and the function no-ops safely. The real bulk of the work is clerical: pulling the exact script ID for each of the ~70 vehicles and wiring its own Sandbox Option.

Supporting note (Oct 1, 2026), from another person in the thread (not capnkirkland): says full-size RVs are nearly impossible to find in-game — real player confirmation that the rarity gap this addon targets is genuine, not just assumed. Explicitly asks for coverage of "every type of car that has the RV interior," i.e. exactly the scope already tracked here (all ~70 compatible vehicles, not just one).

Checked the Workshop first: nothing like this exists. Closest hits were Physiks ZOMBIE GORE PLUS (just doubles the existing per-kill gore chance, a Sandbox-level tweak, not new content), Chop Those Off! (a manual one-off action — cut a hand off with a knife to sell it, not automatic/passive gore), and Corpse Project (does the opposite — lets you process and remove corpses from the map). None of them add more gore in general or make blood/remains stick around.

Splitting this into what's confirmed easy vs. genuinely unknown. Turning up gore intensity/frequency is likely simple — vanilla already has its own blood-level Sandbox slider and gore-chance system on zombie kills, so pushing it further than the slider allows is a small Lua tweak, nothing new to build. The two real unknowns: (1) vanilla blood decals fade over time on their own — no one has confirmed yet where that decay timer lives in the engine or whether it can just be disabled; (2) whether a real severed-limb object (hand/foot/head, ideally each with its own sprite) can be spawned as a persistent world object depends on whether vanilla's own gib effects are already real map objects or just a decal/particle animation that vanishes with the corpse — unconfirmed, needs decompiling the zombie-death/gore code to know for sure. Evaluated as Long not because any one piece looks impossible, but because covering blood-decal persistence AND new limb-chunk world objects (multiple body parts, own art) is real build volume once the unknowns are resolved — same category as other Long entries on this board that just need a decompile pass before a real estimate.

Full control over what percentage of zombies spawn as each speed archetype (Crawler/Shambler/Fast Shambler/Sprinter), each toughness tier (Fragile/Normal/Tough), and smart/door-opening zombies — not vanilla's single global Speed setting plus one crude SprinterPercentage slider. Confirmed in vanilla's own Apocalypse.lua that Sight/Hearing/Cognition/Memory/Speed are single world-wide values applied to every zombie equally; there's no native per-type split. The classic mod for this exact feature, Random Zombies by belette (3,047 ratings), was retired by its own author for B42 ("vanilla basically caught up," though recent comments disagree and say the new "Custom" sandbox option is confusingly hidden behind an "Advanced" checkbox with no visible input). An unofficial third-party fix of that same mod is reported working on 42.20.4 as of days ago, proving the underlying mechanism is reachable in pure Lua with no Java patch needed — but the user does not want to use or reference any existing mod without the original author's permission, so this would be built fully independent from zero, including redoing the Java decompilation research to find the real per-zombie setters instead of reading anyone else's code. Evaluated as Long by volume, not by technical risk: a full Sandbox Options page with several percentage sliders that must sum to 100, plus the live-population correction loop the original author's own FAQ describes needing (checking configured zombies at intervals, not a single spawn-time hook), plus in-game statistical verification — same category as Real Nutrition or the Resident Medic remake on this board.

Let Sight and Hearing radius differ by zombie speed archetype (e.g. sprinters hear worse than shamblers), instead of vanilla's single global value applied to every zombie. Confirmed nothing does this — not even Random Zombies, the most established mod in this exact space. Directly asked, its own author (belette) answered: "Unfortunately, there's no way to do that that I know of today." Not necessarily impossible forever — this board has broken similar walls before with a Java patch via ZombieBuddy when no Lua hook exists (see Darker View Cone Opacity) — but nobody has confirmed whether zombie perception lives per-instance in the game's Java or is a single shared value at the engine level. Evaluated as Long due to genuine unknown scope: needs fresh Java decompilation before any time estimate is possible.

A commenter on Custom Radio Station asked if it could play a real live station (COPE was the example given), mentioning they'd done something similar for Euro Truck Simulator. Confirmed this is not a small extension of the existing mod — Custom Radio Station plays fixed local files using a "virtual clock" that needs each track's exact known duration to seek to the right second; a live stream has no known duration and no seek, it's continuous audio pulled from a network server. ETS2 isn't a mod doing anything special there — SCS built internet streaming into the base game engine itself; Project Zomboid has nothing equivalent built in.

Theoretically possible as a separate playback mode, not an extension of the current system — FMOD (the audio engine underneath) does generally support opening an http:// URL as a sound source, same as a local file. But there are 2 real unconfirmed unknowns: whether the specific FMOD binary shipped with this PZ build has network/streaming support compiled in, and whether the Java process running the ZombieBuddy bridge can open an outbound connection without being blocked. Next real step, not done yet: a minimal isolated test (same method already used to confirm real seek before building the mod) — a standalone .java compiled against the game's jars that just tries FMOD_System_CreateSound with a real streaming URL and checks for a valid handle. Needs the actual direct stream URL (not the station's website) to run. Separate consideration: redistributing a commercial station's live broadcast inside a game mod also raises a rights question, worth keeping in mind. Evaluated as Long — pending that verification test before any real estimate.

Sub-mod for [B42/MP] Irish's Dinosaurs (Workshop 3784875732) adding taming, riding and breeding on top of the base mod's raptors/rexes/carnotaurus/pachys/ankys/stegos. Confirmed via the base mod's own FAQ: the author explicitly ruled this out himself ("too complex, make a submod... extreme scope issue"), and grants open permission to fork/expand the mod as long as it isn't reposted unchanged. Vanilla Project Zomboid has zero mount/ride system of its own, so this would need a full custom-built mounted-movement system layered onto Irish's existing rigged dino models — the same category of undertaking as the Horse Mod's own from-scratch "Gear" riding system, not a reuse of anything that already exists. As of 16 sept 2026 the author is already teasing dino eggs "to lay the groundwork for future farming/herding/breeding" in the base mod, so this may get partly superseded by an official update before work starts. Evaluated as Long — check back before starting in case the owner has already added it.

The ALICE Belt/Suspenders vanish completely when worn under a jacket and a bullet-resistant vest, unlike the Chest Rig which stays visible. Confirmed 100% in vanilla's own files: clothing on the webbing slot can define an alternate model (m_AltMaleModel/m_AltFemaleModel) the engine swaps to when a jacket or vest is worn over it (BodyLocations.lua, setAltModel(JACKET, WEBBING)). The Chest Rig has a real alt model (different file size from the base model). All 3 ALICE Belt/Suspenders variants have that alt-model slot completely empty — it was simply never made, not a rules/priority bug. Fixing it for real needs a new 3D model: adjust the existing mesh in Blender (rigged/animated, needs testing across multiple poses, not a static texture) and ship a custom clothingItem.xml pointing to it. Evaluated as Long, not Quick — this kind of rigged-mesh adjustment historically takes several in-game test rounds on this project (Nissan 300ZX, garage doors), not one shot.

Be able to turn trailers that end up wedged badly into corners.

A full remake from scratch, with fully custom lore and extraction.

Make crafting stations movable that currently aren't.

Remove the ruined-building effect from a specific area. Not 100% sure if it's possible yet.

A bigger hospital near Brandenburg/Irvington/Riverside. Can't say for now, need more details and a new model to learn.

A bigger, more realistic fire model for fireplaces.

Hand models with individual fingers.

A placeable object that waters itself for a few days.

Be able to administer food/medicine to another player, aimed at doctors.

A from-scratch remake of the detailed engine mod, discontinued and locked by its original author.

A full military profession, exclusive traits and clothing. Just noted, nothing confirmed yet.

An update to a mechanic that already exists but is unconfirmed on the current build.

Make rabbits, passive in vanilla, turn hostile.

Hordes that gather zombies that already exist instead of spawning new ones, with multiplayer support.

See and grab nearby items without opening container after container.

Solar panels, batteries and alternative power for bases.

Noted on the list, haven't checked yet if it's doable.

A rope hook to reach high places.

Jump out of a moving car, with damage scaling with speed.

An update to a mod that makes infections survivable, broken since March 2025.

A big overhaul of CDC airdrops and medication, stalled since December 2024.

Hollow point, explosive, incendiary, AP, API and AP-explosive rounds, found as loot alongside regular ammo, each with real ballistic effects when fired. Real gap — nothing does exactly this for vanilla weapons/ammo. But vanilla's list of real ammo types is closed to exactly 10 hardcoded values with no modding hook to add an 11th, so a real drop-in special-ammo item needs either a Java patch to open that registry, or a scaled-down Lua-only version limited to effects that can be applied right after a hit lands (like an ignite chance), not ones that need to change the shot itself (like ignoring armor). Not Quick as originally asked.

Real money in bank safes and security deposit boxes.

Build ceiling/roof tiles on the floor above without building a staircase first.

Not a promised fix — an attempt to ease the chunk-streaming freeze while driving/fast traveling. Needs research into engine-level patching first; may get cancelled if it turns out not to be feasible.

A small truck carrying a propane tank, for refueling the blowtorch on the go. No mod does this — closest ones are item-level propane refills, not a vehicle. Needs a new vehicle model.

A proper combat stance/animation set for the katana. Every mod that did this is broken on current stable — needs custom animation work, not just a data mod.

Show calorie info on drinks, gated behind the Nutritionist trait, like food already does. Confirmed real vanilla gap by decompiling the game — drinks track calories internally but the tooltip only reveals it in debug mode, never to normal players. The code that needs changing lives in compiled Java with no clean Lua hook found so far — not a promise, just an attempt.

Mutual actions between two nearby players — hugging, cuddling, petting, playing cards, dancing — that lower Unhappiness and Stress for both at once. Checked the Workshop: pose mods like TTRP Poses cover the visuals but do nothing to moodles, and Lifestyle: Hobbies is individual-only and currently breaking saves/multiplayer on 42.20.2. Would need custom multiplayer actions and animations built from scratch, syncing both players' moodles.

A flashy one-handed spin-cock animation for the lever-action rifles, like Arnold's move in Terminator 2. Nothing like it exists — the closest mod only swaps in a faster two-handed rack, and vanilla has since added its own racking animation anyway. The good news: a proven code hook for custom lever-action rack/reload animations already exists (used by that same mod, 12,500+ subscribers), so the injection point is de-risked — the real cost is animating the one-handed spin flourish itself.

A controllable flying/scouting drone. Corrected on Oct 16: this entry used to say nothing real exists on the Workshop, and that is no longer true. PzDrones (Build 42, 3,781 subs, published Sep 9, updated Sep 16; page opened) is a quadcopter you fly: a vehicle built from scavenged parts, with a battery, an RC transmitter with an LCD screen (altitude, heading, battery), a picture that blurs if the lens cracks, cargo lifting and bombs, while your survivor stays standing on the ground. FPV Kamikaze Drone (16 subs, Oct 10; listing only) is an FPV drone for scouting or with a warhead. I have not installed or tested either, so I do not know whether they fully cover the remote-camera idea. What was seen on Aug 16 (historical): the only mod named "drone" was LvDrone, with no description and 1 subscriber. Vanilla has no flying, freely-controllable entity or camera to build on (the closest thing is fixed security cameras viewed through a TV/monitor), so this would be a new discipline for this board — battery/range, a camera that moves independently of the player, and multiplayer sync if it's ever meant to run on a dedicated server.

Old-school house phones with real numbers — call a friend and they actually have to be home to answer, no cell phones. A mod that does exactly this already exists (Infoteo's LandLine, published for 42.20.2 specifically), but the requester doesn't want to subscribe to someone else's mod and its license forbids forking or reusing any of its code, so this would be built independently from scratch. Same calibre as Zamazon or force-feeding another player — a phone interaction menu, a number registry tied to safehouses, a call state machine (dialing/ringing/busy/timeout), and server-side proximity checks for multiplayer. No confirmed vanilla hook yet for the phone objects themselves.

Functioning traffic signals — red/yellow/green cycling, tied to the global power grid so they go dark when the power does — at every intersection on the map, not just one. A mod that does this for a single Riverside intersection already exists (Texas Ranger's Riverside Traffic Signals), but its own author lists map-wide tile detection as an unimplemented "planned feature," and it currently has a confirmed, unfixed dedicated-server bug (null IsoGridSquare during object-sync packets). Scaling to every intersection means automatic tile detection tied to chunk loading instead of hardcoded coordinates, real performance work across hundreds of lights instead of one, and solving that sync bug first so it doesn't multiply. Biggest scope item on this board's difficult list right now.

Remove every abandoned train carriage blocking Knox County's railway so the whole line can actually be used — vanilla-only, no dependency on the (hugely popular, 26k+ subs) Railroader mod that makes a locomotive drivable on that same track. Checked the game's code: carriages aren't a special engine object type (no IsoObjectType entry) and aren't part of the Moveables system (only Train_Signal is registered there) — so they're plain map-authored objects, not something with an existing hook to reuse. Real Railroad Deconstruct's own changelog confirms they ARE destroyable via the standard vanilla sledgehammer+Destroy system already, just one at a time. The one thing that can't be nailed down without opening the game and checking a real carriage's sprite name: exactly what to search for when scanning the map. Flagged as long/uncertain until that's confirmed in-game.

Bring computers to life with a barebones 90s internet, working for the first several days or until the power grid goes out. Randomly generated website names unique to each playthrough, discovered via addresses scattered on notes and fridges around the map, browsable recaps of shows/news, downloadable content limited by era-accurate storage, and floppy disks that must be swapped by hand between PCs to move files — with the mandatory dial-up connection sound. Checked the Workshop: a mature, actively maintained mod already covers similar ground in huge depth (Computer Mod, Build 42 tagged, updated 10 Aug 2026, 1,320 ratings) — read its actual shipped code: website names are a fixed table, not randomized per playthrough, and floppy disks/dial-up only exist as flavor text with no real mechanic behind them. Its license requires asking the author before any patch or addon, so this is being built independently from scratch instead, same precedent as Zamazon Trading. Confirmed buildable: vanilla has zero interaction hooked to the decorative Computer furniture object, but reading Computer Mod's own code confirmed the standard Events.OnFillWorldObjectContextMenu event — the same generic technique any mod uses to add right-click options to a world object — is all that's needed, so wiring up interactivity is a solved problem, not a risk. Needs, from scratch: object interactivity, a custom browser-style UI, a procedural site/name generator with per-save persistence, a new floppy disk item with partial-download tracking, in-world clue notes added to loot tables, and a tie-in to the power grid/generator state. Same calibre as Zamazon Trading or bigger — no day estimate yet, needs breaking into pieces before promising anything.

A fully working, from-scratch rebuild of the classic Common Sense QoL pack, confirmed asked for by name: prying doors/windows/vehicles open with a crowbar, picking up loose junk from the ground, reloading every selected magazine at once, clipping a flashlight to the toolbelt, an ammo counter HUD, opening canned food with scissors or a screwdriver, swapping out dirty bandages, equipping items straight off the ground, washing only equipped or only unequipped items separately, crafting sheets from scrap materials, disinfecting dirty bandages with alcohol, and easier fuel transfer at campfires/BBQs/fireplaces. Checked the Workshop: the dominant fork, Sentido Común [B42.20+] (217,600 subscribers), claims full B42.20 stable support in its own FAQ, but today's comments say otherwise — the crowbar no longer forces vehicles or doors despite the sandbox option being on, plus a live exploit letting grass be farmed infinitely off a single bush that can no longer be removed — and the author's own pinned discussion admits ongoing multiplayer problems. Built independently from scratch rather than patching any existing fork, same precedent as Zamazon Trading and the Functional Computers idea. Each individual mechanic maps to a real, previously-proven vanilla hook, but this is 12+ distinct features bundled into one mod, already at 217k+ subscribers in its most popular existing form — same calibre as Zamazon Trading or bigger, needs breaking into pieces before promising a timeline.

Everyone goes to bed at once and picks a duration — a week, a month, a whole season — and the next time anyone wakes up, that much time has genuinely passed. Confirmed in the game's own code and by two mods already published this build (True Sleep - Better Multiplayer Sleep, Multiplayer Sleeping): vanilla's real fast-forward-the-night mechanic already exists and works in MP (server options SleepAllowed, SleepNeeded, FastForwardMultiplier — a full night in ~15 seconds by default), but it is strictly a group mechanic — it only fires once every connected player is asleep at the same time, because there is one shared world clock, not one per player. Neither existing mod breaks that wall; the closest attempt (True Sleep's "solo nap") deliberately leaves world time untouched when only one player rests, specifically to avoid time-warping everyone else mid-session. So a literal solo hibernation ("I sleep, everyone else keeps playing, then I wake up weeks later") isn't possible without two world clocks existing at once — the engine has one. What is real and buildable: extending the existing all-asleep group skip from "one night" to "however long the team agrees on," turning it into a genuine whole-server hibernation — but it needs every player online at that moment to go to bed together and accept it, same requirement vanilla's own night-skip already has, just scaled up. Unverified: how cleanly crops, zombie migration, weather and vehicle/generator state catch up over a multi-day or multi-week jump instead of a single night — nobody's pushed the existing mechanism that far yet.

A warship docked near Louisville, explorable below deck, repairable, and — the big ask — able to actually fire its guns once repaired, with sub-levels holding parts needed to unlock other content at a specific Louisville location. Checked the Workshop: the core "docked warship you can explore for loot" concept already exists and worked well — The Frigate (Gabester, 1,350 ratings), a frigate on the Ohio River between West Point and the road up to Louisville, with military loot and hazardous below-deck corridors. But it's Build 41 only (no B42 port, unanswered request) and its license is on lockdown — no extending or altering without permission, so this would be built independently from scratch. Louisville already has real port infrastructure in the mod ecosystem too (Louisville Shipping Port, just west of the airport), confirming the location makes sense.

Nobody combines the three pieces this asks for: the ship itself for B42 (mapping work — TileZed/BuildingEd, same new discipline as the pending 2-3 story hospital, not 3D modeling), a working gun that can actually fire after repairs (no functional ship weapon exists in any PZ mod found — new mechanic from scratch, no vanilla hook to lean on), and a cross-location progression system gating Louisville content behind parts found in the ship's sub-levels (no precedent found either). Same calibre as Zamazon Trading or bigger — mapping + a brand-new weapon mechanic + a two-location dependency system, not something to promise a date for yet.

A non-destructive Lua layer on top of vanilla's nutrition system, brought as a full written design: punish eating pure fat (butter, lard, margarine, cooking oil, mayo) standalone with escalating sickness — a second dose the same day triggers real food sickness, pain, unhappiness and a 12-hour stamina debuff, and directly wipes the calories just gained — while rewarding real food with bonus calories for protein sources, and a bigger bonus for eating protein + carbs the same day. Diet variety and nutritional-deficiency effects are planned as later phases.

Confirmed in the game's own code that every piece of the core design is real: Calories/Proteins/Carbohydrates/Lipids already exist as per-item data on ~400 vanilla foods, and the player's own Nutrition object exposes matching getters/setters straight to Lua (confirmed live in vanilla's own debug menu). The real food-sickness pipeline this needs is proven working in production already — a published B42.17+ mod (Immersive Diets Mod) routes lactose intolerance and peanut allergy through that exact same engine pipeline. The one worry in the original design — telling standalone eating apart from a recipe ingredient — turns out to need no extra detection at all: eating and cooking already run through two separate game systems, so butter used in a stew never triggers the "eaten" hook in the first place. Checked the Workshop: nobody combines punish-the-exploit with reward-the-real-food this way — the closest competitor, Real Calories and Nutrients Overhaul, takes the opposite, more invasive route (rewriting ~400 item values directly) and is currently on hold waiting for a stable build. No blocking risk found anywhere in the core design — Long only because of the sheer number of interacting systems and the calibration work needed, not because anything is unproven.

A general utility that changes where the byproduct of an interaction lands. Flagship example: ejecting a gun's magazine always dumps it into your main inventory — the ask is a way to mark a container as its actual destination instead. Confirmed directly in the game's own code: ISEjectMagazine.lua hardcodes self.character:getInventory():AddItem(newMag), no hook, no setting. Checked the Workshop first: the closest thing, Quartermaster - Auto-Sort & Store Loot (Deckard, B42, 73 ratings), solves a different problem — it's a manual "Distribute Loot" button that walks already-owned items to designated boxes after the fact, not a real-time redirect of what an action produces the instant it happens. Nothing found does that.

The same "result of an action shoved straight into getInventory(), no hook" pattern repeats in roughly 100 separate vanilla Lua files — unloading bullets, stripping a vehicle part, skinning an animal, washing clothes, and more — each its own function, so there's no single chokepoint to patch once for everything. The real build is: a right-click "set as destination" option on any container (saved per character), plus overriding a curated handful of those ~100 functions one at a time (same copy-the-function-and-change-one-line technique used elsewhere) so each checks for a marked destination with room before falling back to normal inventory. Starts with magazines/ammo as the proof of concept, expandable to more interactions in later updates — Long because of the new UI plus the per-function patching, not because any piece is unproven.

A throwable that drops a zone which pushes zombies away from the center, buying time to reload and reposition on high difficulties — able to shoot out through it, with a color-coded integrity bar (blue → orange → red → breaks) from zombie/bullet hits, or it expires after 10 in-game minutes. Checked the Workshop: nothing like it exists — searched "shield grenade", "repel zombies", "push zombies away" and variants, nothing combines a thrown item with a zombie-repelling zone. The closest hit, 推僵尸入水/Push Zombies Into Water, confirms pushing zombies from Lua is a real, done-before thing, but a completely different mechanic (shoves into water, not a standing zone).

Confirmed in the game's own code that the hard parts already have real building blocks: the throw itself doesn't need custom projectile physics like Boomerang did — vanilla's own Molotov is a pure data item (SwingAnim = Throw, PhysicsObject, MaxRange = 8.0) and the engine already resolves the throw arc from those fields alone. Detonating something at a specific tile is a real Lua-exposed function already proven by the game's own admin panel: IsoFireManager.explode(cell, square, power) (ClientCommands.lua, the "add explosion" debug command). The one-way part falls out of the design for free — a repel zone isn't a physical wall, so the player's own shots/swings out are never blocked, nothing to build there. The integrity bar has a direct vanilla precedent: barricades already swap sprite by remaining health on every hit — same data pattern, new object. The 10-minute timer reuses the same game-time tracking already used in Exact Minute Clock and the sunrise/sunset mod.

Not confirmed yet, needs an in-game test before promising anything: whether IsoFireManager.explode() pushes/damages zombies on its own or the push has to be done by hand (radius + a tick loop nudging nearby zombies), and the actual look of the "dome" — realistically not real 3D dome geometry but a circle of ground tiles that change color, like a rug, far cheaper than inventing new geometry. Long because of the number of new systems (placed object + damage-state art + timer + push logic), not because anything found so far is a dead end.

A static, non-moving trader you approach and right-click their safehouse door for — not a wandering, dialogue-driven NPC. He offers up to 3 retrieval jobs (bring him a specific item/category, get a reward) and 3 delivery jobs (carry a package to the other trader) at a time, paid in real in-game Gold/Silver Coins, weight-tiered so heavier/harder items pay more. Two traders, each with a labelled Incoming/Outgoing/Purchase box outside their safehouse. Checked the Workshop first: nothing combines this exact set — Shops and Traders (Chuckleberry Finn, 320 ratings, updated 31 Aug 2026) is buy/sell shop assignment on any object, not fetch-quests; TRADER NPC (GIK, 208 ratings) is a random wandering seller.

Key finding, confirmed on two separate mods: a real, living, AI-driven NPC is single-player only in this engine, full stop — Braven's NPC Framework (1,179 ratings) says so in its own FAQ, and Pat's NPC - Project Remnants, a huge companion-NPC mod actively updated for the current 42.20 stable and using its own Java agent, still carries "[B42 SP]" right in the title. Not a coding gap, an engine boundary. Since the design already routes every interaction through right-clicking the door rather than talking to the trader, the actual character doesn't need to be a functional NPC at all — decided with the user: build the trader the way GIK's mod does, turning a passive zombie into the "person" (confirmed working in multiplayer by that mod's own author), keeping the mod fully MP/dedicated-compatible.

Everything else is well-trodden ground on this board already: Base.GoldCoin/Base.SilverCoin are real vanilla items, no currency to invent. The job-matching, weight-tiered rewards, and delivery/purchase boxes are the same kind of container/context-menu/ModData work already vetted for Zamazon Trading — just doubled, one system shared by two traders. Long for the sheer number of moving pieces (2 traders × 3+3 job slots, categories, weight curve, boxes), not because any piece is unproven.

Drillable peepholes on specific wall or door tiles, giving a small narrow one-way line of sight outside. Checked the Workshop: nothing exists — searched "peephole", "door viewer peep", "murder hole wall slit" and variants, nothing.

There's a real fork here with very different risk on each side. The naive route — a genuinely narrow line of real vision punched through an otherwise-solid wall/door — is the risky one: the game's own vision-cone math runs in LightingJNI.calculateVisionCone(), a native (JNI) method, not Java, and nowhere near Lua. Confirmed by a real published mod that touches it, [B42] 360º Vision, whose own description says plainly "PZ natively offers no framework for mods to alter its base methods" — same territory that forced Darker View Cone Opacity into a full ZombieBuddy Java patch, and that mod only had to change a number, not the cone's actual shape.

The safe route already exists for real in the game: B42 windows are wall entities (same discovery as Fencing Kits) with genuine two-way vision already solved natively, no patch needed — that's the exact mechanism that makes looking through a window work at all. Clean path: a new tiny window-style entity with a round-hole sprite instead of glass, flagged so it can't be opened or climbed through unlike a real window — real vision, zero engine risk, same "new entity, existing system" pattern as Fencing Kits. Doors are a separate question — IsoDoor isn't the same class as IsoWindow (confirmed while building Start As A Prisoner), unverified whether a door tile can host a window-like child element. If the window trick can't be narrowed enough, the fallback with zero vision-system risk at all: skip rendering entirely and just query what's in that direction (same nearby-zombie-counting pattern used in several mods already), reporting it as text instead of a real view — less immersive, but nothing left to prove.

Attack zombies on the other side of chain-link/chicken-wire/prison-bar doors, gates and metal bar barricades with guns and spears, without damaging the door itself. The wall segment of a wire fence can already be attacked through; the door/gate version of the same fence oddly can't, or only unreliably by standing at an angle. Checked the Workshop: nothing does exactly this, but a real, published, proven mod does the same trick for a different case — Shoot Through Barricades (RedChili, 132 ratings): aim a ranged weapon through a wooden plank barricade and it swaps to a see-through state just for your shot, snapping back to solid the instant you stop aiming, one-way only, MP-safe (client-side only, never sent to other players). Its own FAQ says plainly "Does it work on metal barricades? No, only wooden plank barricades" — and a comment from 14 hours ago on that same mod: "metal bar fence stabbing is a mechanic i've been waiting s[for]" — someone else asking for exactly this gap.

A plausible, not-yet-confirmed explanation for the wall-vs-gate inconsistency: prison bars/mesh are already known to read as not-solid (isSolid()/isSolidTrans() both false, confirmed while building Start As A Prisoner), so the material itself likely isn't what blocks the attack — more likely the game's attack-target selection excludes anything classed as a door (IsoDoor, a separate class from IsoThumpable, same finding from Start As A Prisoner) regardless of what it's made of, solid oak or chain-link. Needs an in-game test to confirm before promising a fix, not just reading code.

The real build: same technique RedChili already proved works (temporary see-through swap while aiming/thrusting, one-way, reverts instantly, no damage to the object) but extended to chain link, chicken wire, prison bars and metal bar barricades, and to both firearms and melee spear thrusts instead of just guns on wood. That mod's license requires permission to extend, so this gets built independently from scratch, same precedent as Zamazon Trading. Long for covering two attack types across several fence/gate variants plus the unconfirmed root cause, not because the core trick is unproven — it demonstrably works already for barricades.

More wall/floor finishes available in the player build menu, pulled from the finishes already used by B42 stable's own pre-placed houses on the map — so a custom-built house doesn't look so much plainer than a map one. Checked the Workshop: nothing does this with vanilla's own tiles — the closest, Rocco's Tiles - Buildable (biffdit, 148 ratings), makes a third-party asset pack's objects buildable, not vanilla's own house tilesets.

Confirmed in the game's own code why the gap exists: every buildable wall level is its own separate entity pointing at one fixed tileset row — entity_wood_walllvl1.txt: component SpriteConfig { face W { layer { row = walls_exterior_wooden_01_44, } } ... } plus its own component CraftRecipe. There's no "pick a skin" dropdown — each finish that exists today (wood lvl1/2/3, brick lvl1/2, metal lvl1/2, log) is a hand-made entity+recipe pair. The map's pre-placed houses draw on many more tileset rows than these, and that art is already loaded with the base game — it's just never been wired to a player recipe.

Same low-risk, proven pattern already used for Fencing Kits and Craftable Salt: new entity + SpriteConfig row pointing at an existing tileset (zero new art) + a CraftRecipe copied from vanilla's own pattern. Long, not Quick, because the scope is open-ended — "all the new houses" is dozens of possible finishes, each needing its own name, menu category, balanced materials and translation — needs narrowing down to a first batch when picked back up, not because the technique is unproven.

Sleep in multiplayer that can't be broken by anything until the scheduled wake time — no accidental early wake-ups. Checked the Workshop: nothing fixes this. True Sleep - Better Multiplayer Sleep (yoona, 90 ratings) and Multiplayer Sleeping solve the "everyone sleeps together" fast-forward problem, but neither touches the actual early-wake triggers; comments on True Sleep from Sept 1 still complain about a separate re-sleep cooldown bug. Let Me Sleep! (Memori) fixes that adjacent cooldown issue, not this one.

Decompiled IsoPlayer.processWakingUp() (the real function deciding whether the character wakes) and found the exact, MP-specific root cause: if (GameClient.client || numPlayers > 1) { forceWakeUp = forceWakeUp || this.pressedAim() || this.pressedMovement(false); } — vanilla deliberately wakes the player on any movement/aim key press while asleep, but only in multiplayer; that branch doesn't exist in singleplayer. That's why "anything" cuts sleep short in MP. Two more real triggers confirmed in SleepingEvent.class: a nearby zombie wakes with no sandbox check at all, and any other player can force-wake you via ISWakeOtherPlayer.lua, a pure-Lua context action with zero protection. (The separate "zombie break-in" sleep event already has a real sandbox toggle, SleepingEvent option — no mod needed for that one.)

Long: all three real triggers live in compiled Java (IsoPlayer.processWakingUp(), SleepingEvent.update()) with no clean Lua hook to override — needs a Java patch via ZombieBuddy, the same proven pattern already used for Darker View Cone Opacity, Unequip And Listen, and Instant Item Transfer on this board. The "other player wakes you" piece is pure Lua and trivial alone, but since the ask is "immune to everything," the full mod needs all three pieces together.

Add a lightbar on top of any vehicle, not just the ones that already ship with one. Checked the Workshop: nothing does this for literally any car. Easy Lightbar Repair / Vehicle Repair Overhaul only fix a lightbar the vehicle already has; Simple Wheels and Lightbars Expanded (SVU3-based, 46 ratings) says plainly in its own description "Currently only police cars have lightbars" — its own author lists Ranger/Firetruck/Ambulance as still TODO, and ordinary cars aren't on that list at all.

Confirmed in the game's own code why the gap exists: a lightbar isn't a real attachable object like a trailer (the only generic "attachment" point vanilla vehicles have) — it's baked straight into the vehicle's 3D model and texture. CarLightsPolice is a wholly separate vehicle entity from the plain sedan, pointing at its own mesh (Vehicles_CarLights_NoRandom) and its own lit texture (vehicle_carlightspolice_lights); the template = lightbar just wires up the siren sound and a mechanic slot on top of geometry that's already there. Nothing in vanilla can put that geometry onto a car that was never modeled with it.

Not a dead end though: the community already proved a generic "exterior part installable on any vanilla vehicle" system works — Standardized Vehicle Upgrades 3 (an actively maintained B42 framework) already lets players craft and bolt armor plating onto every single vanilla car through one standardized recipe, and the same ecosystem already swaps wheels and antennas across the whole vanilla+PZK vehicle roster. Extending that same modular-attachment approach to a roof lightbar is buildable, but needs real new 3D/texture work per vehicle body shape (sedan vs pickup vs van each need their own mesh and mount point), not a one-field script edit — Long, not Quick.

Save your character's name, appearance and full gear — everything worn, held and stashed in your bags, with zero detail lost — then start a brand new world with all of it intact, isekai-style. Checked the Workshop thoroughly: nothing does the full package. Vanilla itself lets you copy a save's players.db/WorldDictionary.bin into a new save to carry name/appearance/traits/skills/vehicles across, but the inventory comes out randomized, not yours. Simple Character Export and Import (real, published, B41 and an attempted B42.13.2 port) covers the same name/appearance/traits/skills half through a file outside the save folder — but by its own description carries zero items, none at all.

Confirmed by decompiling the game's own code why "zero detail lost" is the hard part: items aren't flat data — a Clothing carries bloodstains/rips, a Weapon carries condition/attachments/ammo loaded, a Food carries age, a Literature carries pages read, and a bag is a full ItemContainer that can nest more containers inside it — dozens of item subclasses, each with its own extra fields, all currently spawned fresh by vanilla's own loot tables rather than rebuilt from scratch. The character-only half is Quick, reusing the export mod's own proven trick (write to a file outside any save folder, so it survives moving to a brand new world). Explicitly asked for and confirmed by PorrisV99: full fidelity, not the cut-down "basic stats only" version — so this stays Long, not Quick. The real work is a general-purpose item serializer/deserializer that walks the player's worn+held+bag contents recursively and captures every field a subclass can carry, then rebuilds each item from that data on the new world's first spawn — a new mechanism, not a reuse of something already demonstrated elsewhere on this board.

Design refined by Wikke, the original requester: less "restart on death," more a Dark Souls-style kindle-the-flame moment — trigger it as a real action on a lit campfire/wood stove, then land on a menu to pick the new world's options from your own saved custom world presets, carrying forward current traits (including any negative trait already shed mid-playthrough), not just the creation-time ones. Investigating this changed the verdict on the riskiest unknown piece: NewGameScreen.lua, MainScreen.lua and SandboxOptions.lua turn out to be plain client-side Lua, not compiled Java, and SandboxOptions.lua already has a real Sandbox_SavedPresets combo box with save/delete buttons — "your saved custom world presets" is an existing vanilla feature, already listable and selectable from Lua, not something to invent. On the trait side, confirmed in B42 that only weight-tied negative traits (Overweight/Obese/Underweight) actually get auto-removed as the character's real weight crosses the threshold — every other negative trait stays fixed all game regardless of stats — so reading the character's current traits at kindle time (instead of the creation-time list) already reflects anything shed along the way, no extra tracking system needed.

A full from-scratch rebuild of Resident Medic, the beloved Resident Evil-style herb healing system (Green/Red/Blue/Yellow herbs, mixed combos, First Aid Sprays/Boxes, an Anti-Virus that resets Knox infection progress without curing it) — Cosmic's original (28,002 subs, 574 ratings, huge fan following) is B41-only, last updated January 2023, author offline. Checked the Workshop thoroughly: no B42 version exists, and comments through July–August 2026 are a steady stream of unanswered "B42 plz" — including one from a player saying a third party's unofficial B42 update briefly existed and then vanished, so this gets built independently from scratch, not touching that or the original's code, same precedent as Fencing Kits and Zamazon Trading.

No engine blocker found — every real piece reuses a technique already proven and shipped on this board: new forageable/craftable herb items follow the exact same pattern as Craftable Salt's foraging additions, and healing specific wound types (bleeding, lacerations, bites, fractures, burns) by reading/writing BodyPart/BodyDamage fields from Lua is the same real, confirmed-working mechanism already shipped in Immune & Bitten Traits and Customizable Infection Chance. Long not for risk but for sheer volume — 4 base herbs, 5+ mixed combinations, sprays/boxes, 2 special medical items, 2 lore books, full loot/recipe tables and 7-language translations, same reason Real Nutrition and Functional Computers & 90s Internet landed here instead of Quick.

Cooler-looking gasmask models — a hooded gasmask especially — since the vanilla one looks kinda plain. Checked the Workshop: the only close hit is a GP-5 gasmask mod, but it doesn't hook into the base game's filter system, so it's not practical to actually use.

Confirmed by decompiling the real Java (ItemCodeOnCreate.onCreateGasMask()): the vanilla filter system is 100% script-driven, nothing hardcoded per item. Any clothing item with Tags = base:gasmask (or base:respirator/base:improvisedgasmask/base:scba) + OnCreate = ItemCodeOnCreate.onCreateGasMask + a WithDrainable/WithoutDrainable pair automatically plugs into the real drainable-filter mechanism — confirmed line by line in vanilla's own Hat_GasMask/Hat_GasMask_nofilter. That's almost certainly the exact piece the GP-5 mod skipped.

The filter hookup itself is trivial once the tags/OnCreate/Drainable pair are set correctly — the real cost is the 3D content: vanilla gasmasks aren't a texture overlay, they're a separate mesh (ClothingItem = Hat_GasMask) rigged onto the head, plus a ground/world model. A hooded design means modeling and rigging a new mesh (covering more of the head/neck than the stock mask) with the already-installed PZ Blender Toolkit pipeline, plus texturing and a world-drop model. Same calibre as Celestial Weapons or the Dildo weapon (a full custom model built from zero), not a script-only fix — Long, not Quick.

Two players craft together on one recipe, each donating their own skill (e.g. one donates Mechanics, the other Metalworking to build an automotive part), both locked into the crafting animation and progress bar together, with the lower skill determining the fail rate — based on a real, unimplemented suggestion posted on the official Indie Stone forums (Jan 2025, zero replies, never picked up by the devs). Confirmed no mod does this: nothing matching on the Workshop under any close name (collaborative/co-op/assisted/shared crafting) — the closest hits are UI-only crafting mods (Neat Crafting, Intuitive Crafting, Craft Helper) with nothing to do with multiplayer cooperation.

Confirmed via decompile that B42 does ship a real engine-level primitive for two characters locked in one synchronized shared animation — GrappleTech (IGrappleable, getSharedGrappleAnimNode()/getSharedGrappleAnimFraction()), the tech behind carrying/dragging corpses. But it's 100% Java, tightly coupled to combat/corpse states (PlayerDraggingCorpse, GrappledThrownOutWindowState...) with no Lua exposure found anywhere, and its shared animation nodes are almost certainly baked engine data rather than something a mod could register a new "crafting embrace" state into — not a clean reusable hook.

Real build path instead: two ISBaseTimedActions synchronized over the network (one player starts, the other accepts), a shared ModData progress value, input blocked on both while it runs, and the skill-combination/fail-rate logic resolved in pure Lua once it completes — each player plays their own existing crafting animation locally rather than a true engine-level character fusion. Confirmed this needs no ZombieBuddy Java bridge (unlike Custom Radio Station, which hit a real Lua wall on FMOD seek) — everything here (timed actions, ModData, client/server messaging) is already reachable from pure Lua, the same pattern already shipped in this board's other MP-synced mods. Long not for a technical wall but for genuine novelty: no existing mod here has done a synchronized two-client joint action before. Long.

Small animals (rats, squirrels, birds, etc.) shouldn't slow/jolt a moving vehicle as much as they currently do when run over. Confirmed no existing Workshop mod does this specifically — there's a real Steam Discussions thread on the official PZ Suggestions board complaining running over small animals feels too impactful, but nothing modded it. The closest Workshop mods (Better Car Physics, Realistic Car Physics, Controlled Impact, Proper Vehicle Injuries for MP) touch general collision damage/handling, not animal-specific inertia.

Long because the actual collision resolution (how much a hit object slows/pushes the vehicle) runs in the native Bullet physics engine, not exposed directly to Lua — needs decompiling the vehicle collision class first (same approach used for the AA-12 and the 300ZX reskin) to find whether there's any per-object-mass hook reachable from Lua before this can even be scoped.