zm_chests - Persistent Chests and Containers
Buy now on Tebex
Video Preview
zm_chests is a powerful RedM script designed to allow players to configure and place persistent chests, containers, and weapon racks in the game world. Through a user-friendly config.lua
file, administrators can define a range of chest types, customizable storage capacities, and lock-picking settings, providing a versatile solution for in-game storage and visual item placement. All containers are saved to the database, ensuring continuity across server sessions.
Key Features
-
Configurable Chest Types: Easily define multiple chest types in
config.lua
, each with unique properties, such as item type, prop model, lock-pickability, and capacity. Available containers include:- Small, medium, and large chests
- Hunting-specific and pelt-only chests and more
- Small and large weapon racks with slot-based inventory
-
Custom Weapon Rack: In collaboration with SPOONI MAPPING, a custom six-slot weapon rack was created specifically for this script. This unique weapon rack prop is included with the script, providing a tailored storage solution for RedM players.
-
Prop Placement System: The script includes a prop placement mode that enables players to visually position and rotate chests in the world before placing them. This system uses client-side rendering to provide a clear preview.
-
Persistent Storage: Each placed container is saved in the database, ensuring that all items and weapons stored remain intact across server sessions.
-
Lock-Picking Mechanics: Configurable lock-picking allows chests to be secured. For lock-pickable chests, a mini-game interface determines the success of the attempt, with a customizable number of retries.
-
Weapon Racks with Slot Management: Weapon racks are equipped with specific slots for weapons, supporting either six or twelve slots based on the rack type. Players can place or retrieve weapons, and each weapon’s slot position is visually rendered on the rack.
-
Owner Permissions and Key Sharing: Chest owners can grant or revoke access to other players. This allows secure co-owned chests where access can be dynamically managed, perfect for collaborative gameplay scenarios.
-
Inventory Interaction: Interaction prompts allow players to open chest inventories directly and manage stored items. Chests can be renamed or retrieved, provided they are empty.
Configuration Highlights (config.lua
)
The config.lua
file allows comprehensive customization of the script’s functionality:
- Chest Definitions: Define chests by name, item type, model (
prop
), capacity (slot
), lock-pickability, and allowed items (if item restrictions apply). - Interaction Distance: Set the player interaction radius for accessing chests.
- Lock-Picking Attempts: Customize the number of attempts allowed to pick a locked chest.
- Menu and Notification Texts: Easily adjust UI texts for better in-game integration.
Usage
- Placing a Chest: Use a chest item to trigger the prop placement system, allowing players to position and place containers within the game world.
- Opening and Managing Storage: Interact with a placed chest to open its inventory, add/remove items, or apply/remove locks.
- Key Management: Owners can assign and revoke access to other players through an intuitive key management menu.
Note: The script is built for VORPcore compatibility, using VORP’s inventory and prompt systems.
Advanced Options
- Debug Mode: Toggle
Config.Debug
to activate extensive print statements for testing and troubleshooting both client and server-side. - Database Persistence: All chest locations, contents, and owner data are stored persistently in the MySQL database, ensuring data integrity across server resets.
Dependencies
- VORPcore: zm_chests integrates with VORPcore and requires VORP’s inventory system for full functionality.
Unlock a dynamic storage experience in RedM with zm_chests
—an essential tool for players and administrators looking to enhance in-game immersion with persistent, interactive storage solutions!
Code is accessible | No |
Subscription-based | No |
Lines (approximately) | 350 |
Requirements | VORP Core |
Support | Yes |