What is a File?
A file is a discrete unit of stored data on a computer's drive. Every photo, document, song, game asset, and configuration setting on a computer is contained in a file. For Unturned™ mod development, files are the atomic building blocks of every project. Models, textures, configuration data, scripts, and packaged mods are all files. This reference establishes a complete working understanding of what a file is, what it contains, and how files relate to the hardware that stores them.
The article that follows is the third foundational orientation document in the 57 Studios™ Modding Knowledge Base. The first two orientation articles (What is Unturned? and What is Modding?) establish the game and the discipline of modding. The present article begins the file-system foundations on which every technical chapter rests. Readers who skip the file-system foundations and proceed directly to the modding-tool installation chapters will encounter terminology and conventions that are not explained later, and the cumulative confusion compounds quickly.
A note on scope. This article is descriptive rather than prescriptive. The aim is to convey what a file is, what is inside a file, and how files relate to the storage hardware that holds them. The next article (What is a Folder?) establishes how files are organised into hierarchical structures, and subsequent articles cover file extensions and the conventional file layouts of Unturned mod projects.
Prerequisites
- Completion of What is Modding?
- A Windows computer
- Approximately thirty minutes of uninterrupted reading time
- A willingness to think about familiar things (files) in a more structured way than is the everyday norm
What you'll learn
- The technical definition of a file
- The four parts of a file: name, extension, content, and metadata
- How files relate to physical storage hardware
- The common categories of files encountered in Unturned mod development
- How operating systems represent files visually
- The role of file integrity and corruption in mod development
- The relationship between files and the operating system's file system index
- How file size and storage planning affect mod project organisation
Background
The concept of a computer file predates personal computers by decades. Early mainframe operating systems used files as the primary mechanism for organizing data on magnetic tape and disk drives. The file abstraction has remained remarkably consistent across generations of computing because it solves a fundamental problem: how to keep many independent units of information on a single shared storage device without losing track of which bytes belong to which unit.
Every modern operating system, including every version of Windows that a mod developer might use, represents stored data as files. The user interacts with files through File Explorer, applications open and save files, and the operating system reads and writes files behind the scenes to track its own configuration.
The endurance of the file abstraction across so many generations of computing is itself worth noting. Storage hardware has changed completely (magnetic tape gave way to magnetic disks, which gave way to optical media, which gave way to solid-state storage); operating systems have changed completely (mainframe time-sharing systems gave way to personal computing, which gave way to mobile and cloud computing); programming paradigms have changed completely (assembly gave way to procedural languages, which gave way to object-oriented and functional approaches). Through all of these shifts, the file as an organising concept has remained constant. The reason is that the file solves a foundational problem (organising bytes into named, retrievable units) that recurs in every computing context.
As shown in the flowchart above, the storage hardware that holds files has evolved continuously, but the file as an organizing concept has remained constant.
An extended timeline of storage hardware
The headline flowchart compresses many generations of storage hardware into six labeled stages. The expanded timeline below records the principal inflection points in storage hardware that affected the modern file as a concept.
The timeline shows the storage-hardware progression in detail. Each inflection point produced a step change in storage capacity, speed, or accessibility, and each step change reshaped the practical assumptions that mod developers operate under.
Did you know?
The first commercial hard drive (the IBM 350, launched in 1956) held approximately 3.75 megabytes of data, weighed over a ton, and was the size of two refrigerators side by side. A current-generation NVMe SSD the size of a stick of chewing gum holds approximately one million times as much data and is approximately one thousand times faster. The factor of one billion improvement in capacity-times-speed across less than seventy years is one of the most dramatic engineering progressions in any field of human endeavour.
Anatomy of a file
Every file has four essential components.
Name
The name is a human-readable label that identifies the file. Examples include Eaglefire, survival_map, and config. The name can contain letters, numbers, spaces, and many punctuation characters, with some restrictions imposed by the operating system.
The naming conventions for files in Unturned mod development follow several documented norms. File names are descriptive (so a future developer can identify the file's purpose without opening it). File names avoid spaces (which complicate command-line and scripting work). File names use ASCII characters where possible (which avoids cross-platform compatibility issues). File names are case-consistent (Windows is case-insensitive but other tools in the mod-development toolchain are case-sensitive). New mod developers should adopt these naming conventions from the first project.
Extension
The extension is a short suffix at the end of the filename, separated from the name by a period. Examples include .dat, .png, .unity3d, and .txt. The extension indicates the type of data contained in the file and tells Windows which application should open it. Extensions are covered in detail in What is a File Extension?.
The extension is the principal mechanism by which Windows associates a file with the application that handles it. A file named MyItem.dat opens in the developer's text editor; a file named MyItem.png opens in the developer's image editor; a file named MyItem.unity3d does not open directly (it is a packaged asset bundle for game-runtime loading rather than for direct user editing). The extension is the single most important field on a file from the mod developer's perspective because it determines what tool the developer reaches for.
Content
The content is the actual data stored inside the file. Content can be text, binary data representing an image, compressed game assets, or any other sequence of bytes. The structure of the content depends on the file type, which is signaled by the extension.
The content of a configuration file is human-readable text, often organised as key-value pairs. The content of a texture file is binary image data, typically compressed. The content of a 3D mesh file is binary geometric data describing vertices, edges, and faces. The content of an asset bundle is a packaged collection of multiple smaller files in a Unity-specific binary format. Each content type has its own internal structure, and the appropriate tool for editing the content depends on understanding that structure.
Metadata
Metadata is additional information about the file that is not part of the content itself. Metadata includes the file size in bytes, the date the file was created, the date it was last modified, the date it was last accessed, and security permissions controlling who can read or write the file.
+----------------------------------+
| Eaglefire.dat |
| +----------------------------+ |
| | Name: Eaglefire | |
| | Extension: .dat | |
| | Size: 2.3 KB | |
| | Modified: 2026-05-12 | |
| | Created: 2026-04-30 | |
| +----------------------------+ |
| | Content: | |
| | (binary configuration | |
| | data for the Eaglefire | |
| | rifle item) | |
| +----------------------------+ |
+----------------------------------+The ASCII diagram above shows the conceptual anatomy of a single file as it might appear in an Unturned mod project. The name, extension, and metadata are tracked by the operating system, while the content is the actual data the mod loader will read.
Extended file anatomy with mod-development context
The headline anatomy diagram covers the four components in general terms. The expanded anatomy below adds the mod-development context that recurs throughout the rest of the knowledge base.
The flowchart shows each of the four components broken down into the sub-properties that recur in mod-development practice. The mod developer interacts with the name and extension constantly, with the content through the appropriate editor, and with the metadata mostly indirectly (through file-explorer columns and dialog displays).
How files relate to storage hardware
Files are an abstraction. The actual data is stored as patterns of magnetic charges, electrical states, or optical marks on physical storage hardware. The operating system maintains an index, called a file system, that maps file names and paths to the physical locations of their data on the drive.
When a user opens a file, the operating system consults the file system index, locates the data on the drive, and reads it into memory. When the file is saved, the reverse happens: data is written from memory to the drive, and the file system index is updated.
The relationship between the file abstraction and the underlying storage hardware has several practical consequences for mod developers. A drive failure can lose every file on the drive simultaneously, which is why backups are essential. A file system corruption can render files invisible to the operating system even when the underlying data is intact, which is why file-system repair tools exist. The performance of the storage hardware directly determines how fast the operating system can read and write files, which is why NVMe SSDs are the documented preference for active mod-development workstations.
The sequence above shows the open-edit-save loop that every mod developer executes hundreds of times per project. The loop touches four layers (application, operating system, file system index, storage hardware) on each iteration; the cumulative time across a multi-hour session is meaningful, which is why the speed of the underlying storage hardware matters in aggregate.
Did you know?
The NTFS file system used by modern Windows is capable of tracking individual files as small as a few bytes and as large as 16 exabytes. The practical limit for any single mod file is far lower, but the underlying file system imposes essentially no constraint on typical mod development work.
Did you know?
Windows tracks not only the date a file was created and the date it was last modified but also the date it was last accessed (read by any application). The last-access date is updated every time any program opens the file, which is why opening a file in Notepad to glance at its contents and immediately closing it still updates the file's metadata. The last-access tracking can be disabled at the file system level for performance reasons, but it is enabled by default on most consumer Windows installations.
File categories in Unturned mod development
Mod developers regularly work with files in several distinct categories. The table below summarizes the most common file types encountered in Unturned modding work.
| Category | Typical extensions | Purpose |
|---|---|---|
| Configuration | .dat, .json | Define item statistics, vehicle properties, server settings |
| 3D model | .fbx, .blend, .obj | Geometry for items, vehicles, and map objects |
| Texture and image | .png, .tga, .jpg | Surface appearance for 3D models and UI graphics |
| Compiled bundle | .unity3d | Packaged Unity assets ready for loading at runtime |
| Source code | .cs | C# scripts for server plugins |
| Metadata | .meta, .asset | Unity internal tracking and configuration files |
| Documentation | .md, .txt, .pdf | Readmes, change logs, installation instructions |
The pie chart above approximates the distribution of file types in a typical Unturned item mod project folder.
Extended file category coverage
The headline category table covers the dominant categories. The expanded coverage below adds the secondary categories that recur in larger mod projects.
| Category | Typical extensions | Purpose | Edited directly? |
|---|---|---|---|
| Configuration | .dat, .json | Item / vehicle / server settings | Yes, in text editor |
| Localisation | .dat (with language suffix) | In-game text translations | Yes, in text editor |
| 3D model (source) | .blend, .max, .ma | Authoring file in 3D modelling tool | Yes, in modelling tool |
| 3D model (interchange) | .fbx, .obj, .dae | Cross-tool exchange format | Yes (export only) |
| Texture (source) | .psd, .xcf, .kra | Authoring file in image editor | Yes, in image editor |
| Texture (delivery) | .png, .tga, .jpg | Format consumed by the engine | Yes (export only) |
| Audio (source) | .wav, .aif, .flac | Authoring file in audio editor | Yes, in audio editor |
| Audio (delivery) | .ogg, .mp3 | Format consumed by the engine | Yes (export only) |
| Compiled bundle | .unity3d | Packaged Unity asset bundle | No, build artefact |
| Source code | .cs | C# scripts | Yes, in IDE |
| Compiled binary | .dll | Compiled C# assembly | No, build artefact |
| Project file | .csproj, .sln | C# project and solution definitions | Indirectly |
| Documentation | .md, .txt | Customer-facing and internal docs | Yes, in text editor |
| Version control metadata | .git/*, .gitignore | Source control tracking | Mostly automated |
| Build configuration | .yaml, .json | Continuous-integration config | Yes, in text editor |
The extended table shows that mod projects contain three distinct categories of file: source files (edited directly by the developer), delivery files (exported from source files for engine consumption), and build artefacts (produced automatically and not edited directly). The distinction matters: backing up source files is essential, backing up delivery files is helpful, and backing up build artefacts is unnecessary because they can be regenerated.
Decision flowchart: how to identify a file type
The decision flowchart above describes the standard process a mod developer follows when encountering an unfamiliar file. Reading the extension first prevents accidentally opening a file with the wrong application.
Common file-encounter mistakes
The table below lists the most common file-encounter mistakes that new mod developers make and the documented corrections.
| Mistake | Consequence | Correction |
|---|---|---|
| File extensions hidden in File Explorer | Cannot identify file types at a glance | Enable extension visibility |
| Opening unknown file in Notepad | May display binary content as garbled text | Research extension first |
| Double-clicking unknown file | May launch unintended application | Right-click and choose application explicitly |
| Renaming a file's extension to change its type | Does not actually change the content | Convert using the appropriate tool |
| Editing a file inside the running game directory | May corrupt the file | Edit copies in a project folder |
| Saving over a source file with the delivery format | Loses authoring information | Maintain separate source and delivery files |
| Deleting source files after building delivery files | Cannot re-edit later | Retain source files alongside delivery |
Each of the mistakes above has a documented and recoverable correction, but the cumulative time cost of recovering from these mistakes is substantial. New mod developers who adopt the corrections from the first project avoid the documented frustration that other developers report.
File size and storage planning
Files vary enormously in size. A configuration file might be a few hundred bytes, while a compiled Unity asset bundle for a complete map might be several gigabytes. Understanding file sizes is essential for managing the available space on a development workstation and for planning mod distribution.
The standard size units are:
- 1 byte (B) = one character of text approximately
- 1 kilobyte (KB) = approximately one thousand bytes
- 1 megabyte (MB) = approximately one million bytes
- 1 gigabyte (GB) = approximately one billion bytes
- 1 terabyte (TB) = approximately one trillion bytes
A typical item mod project occupies a few megabytes. A complete vehicle mod with multiple variants and textures might reach hundreds of megabytes. A large map mod can occupy several gigabytes including source assets.
Typical file sizes by mod category
The table below lists the typical file sizes that recur in Unturned mod development. The figures are illustrative ranges; substantial variation by mod complexity is normal.
| Category | Typical individual file size | Typical total project size |
|---|---|---|
| Configuration file | 100 B - 50 KB | Up to a few hundred KB |
| Item icon | 10 KB - 200 KB | Up to a few MB per item pack |
| Item texture | 100 KB - 4 MB | Up to a few hundred MB per item pack |
| Item mesh (source) | 100 KB - 50 MB | Up to a few hundred MB |
| Item mesh (delivery) | 50 KB - 10 MB | Up to a hundred MB |
| Vehicle texture | 1 MB - 16 MB | Up to a GB per vehicle pack |
| Vehicle mesh | 1 MB - 100 MB | Up to a few GB per vehicle pack |
| Map terrain | 50 MB - 2 GB | Multiple GB |
| Map assets | 100 MB - 4 GB | Multiple GB |
| C# source code | 1 KB - 100 KB | Up to a few MB per plugin |
| Compiled bundle | 1 MB - 500 MB | Combined size of all packed assets |
The size figures show that map mods are by an order of magnitude the largest single category. A workstation with substantial active project storage is essential for map work; item and vehicle work can be done comfortably on more constrained storage.
Pro tip
Keep mod projects on a fast SSD rather than a mechanical hard drive. The repeated reads and writes during Unity Editor work and asset compilation are noticeably faster on SSD storage, and the time saved across a long project is substantial.
Advanced considerations
Files can become corrupted. Corruption occurs when bytes are altered unexpectedly due to hardware failure, software bugs, sudden power loss, or improper handling. A corrupted file may fail to open, open with incorrect content, or appear to open normally while behaving incorrectly. Mod developers should maintain backup copies of important files to protect against corruption.
The documented sources of file corruption in mod-development workflows fall into several categories. Hardware failure (a drive failing during a write operation) is rare but recoverable through restore from backup. Software bugs (a tool writing invalid data to a file) are common but limited to specific tool versions and reproducible. Sudden power loss (a workstation losing power during a save operation) is rare with modern SSDs but historically common with spinning drives. Improper handling (closing a tool before a save completes, force-quitting an application during a save) is common and entirely preventable through patience.
Critical warning
Never edit a file inside the live Unturned game directory while the game is running. Doing so can corrupt the file and require reinstalling the affected content. Always work on copies of files in a dedicated project folder.
Best practice
Use a version control system, such as Git, to track changes to mod project files over time. Version control allows a developer to recover from corruption, undo unwanted changes, and collaborate safely with other contributors.
Common mistake
Saving over a source file with an exported delivery file. The exported delivery file (a PNG exported from a PSD, an FBX exported from a Blender file) is the format the engine consumes, but it loses the authoring information that the source file contains. Once the source file is overwritten, the authoring information cannot be recovered. Maintain source and delivery files as separate files, in separate folders if necessary.
Common mistake
Treating cloud-storage synchronisation as a substitute for version control. Cloud-storage synchronisation copies the latest version of every file to the cloud, but it does not preserve a history of previous versions. A corrupted file synchronised to the cloud is corrupted in the cloud as well. Use proper version control alongside cloud synchronisation, not as a replacement for it.
File integrity and verification
File integrity is the property that a file's contents match what the developer expects them to contain. A file with intact integrity opens correctly in the expected application and behaves as documented. A file with compromised integrity may open with incorrect content, fail to open at all, or behave subtly differently from the developer's expectation.
The flowchart above shows the integrity-verification loop that established commercial mod studios run on a periodic schedule. The loop catches corruption before it cascades into customer-facing problems and is one of the documented operational disciplines of professional mod publishing.
| Verification method | Frequency | Detection capability |
|---|---|---|
| Visual inspection of recently edited files | Daily | Catches gross corruption |
| Checksum comparison against known-good copy | Weekly | Catches single-byte corruption |
| Full project rebuild from source | Weekly | Catches build-chain corruption |
| Periodic restore-from-backup test | Monthly | Verifies backup integrity |
| Customer-reported issue investigation | Episodic | Catches subtle behavioural corruption |
The verification methods above cover the documented spectrum of corruption types. Established commercial mod studios run at least the daily visual inspection and the weekly full rebuild; the monthly backup-restore test is a documented best practice that catches the failure mode in which the backup itself is corrupted.
Frequently asked questions
Can a file have no extension?
Yes. Some files, particularly on Linux and macOS, deliberately have no extension. On Windows, files without extensions are uncommon and may require manual selection of an application to open them.
Can a file have more than one extension?
A file has only one true extension, defined as the text after the last period in the name. However, names may contain multiple periods, producing apparent multi-part extensions such as archive.tar.gz. In that example, only .gz is technically the extension, though the broader convention treats .tar.gz as a compound extension indicating a tar-compressed-with-gzip archive.
Are folder names files?
No. Folders are a separate concept from files, though folders are themselves represented as special directory entries in the file system. Folders are covered in detail in What is a Folder?.
Why are some files hidden?
Operating systems hide certain files by default to prevent accidental modification of system-critical data. Mod developers occasionally need to view hidden files, which is accomplished through a setting in File Explorer.
How do I view file metadata in Windows?
Right-click any file in File Explorer and select Properties. The Properties dialog shows the file's name, type, size, location, dates, and security permissions. The Details tab shows additional metadata specific to the file type (image dimensions for image files, document author for document files, and so on).
What happens if I open a binary file in a text editor?
The text editor displays the file's bytes interpreted as text characters, producing garbled output that does not represent the file's actual content. The file itself is not modified by opening it in a text editor, but saving any changes from the text editor would corrupt the file's binary structure. Open binary files only in the tools designed for their format.
Can I recover a deleted file?
Sometimes. Windows moves deleted files to the Recycle Bin by default, where they can be restored. Files deleted from the Recycle Bin or deleted using shift-delete are removed from the file system index but their underlying data may persist on the drive until overwritten. Dedicated recovery tools can sometimes restore such files, with varying success rates. Backups are far more reliable than recovery.
What is the difference between a source file and a delivery file?
A source file contains the authoring information needed to edit the content (layers in a PSD, modifiers in a Blender file, unflattened text in a PSD). A delivery file is the exported format that the engine or tool consumes (a flattened PNG, an FBX export, a baked texture). Source files are typically larger and editable; delivery files are typically smaller and not editable. Maintain both.
How do I know if a file is corrupted?
A corrupted file may fail to open in the expected application, may open with visibly incorrect content, may produce error messages when loaded by the engine, or may produce subtly wrong behaviour at runtime. The integrity-verification loop described in the file-integrity section of this article catches most corruption before it cascades into customer-facing problems.
Should I store mod project files on a cloud drive?
It depends. A cloud drive provides convenient cross-device access and offsite backup but is not a substitute for version control. The dominant pattern across established commercial mod studios is to store project files locally on a fast SSD, version control through Git with LFS, and additionally back up to cloud storage as a third layer of resilience. Working directly from a cloud-synchronised folder is workable for small projects but produces performance issues for larger projects.
How large can a mod project get before it becomes hard to manage?
Project complexity, not project size, is the dominant management constraint. A multi-gigabyte map mod with a coherent folder structure and disciplined version control is easier to manage than a hundred-megabyte item pack with disorganised assets. The management techniques (folder structure, version control, documentation) covered in this knowledge base scale to multi-gigabyte projects without difficulty.
What is a file system?
A file system is the index that the operating system maintains to map file names and paths to physical locations on the storage hardware. NTFS is the file system used by modern Windows; APFS is the file system used by modern macOS; ext4 is the file system used by most Linux distributions. The file system handles directory listing, name lookup, free-space management, and access permissions, and is the layer that translates the file abstraction into actual reads and writes against the storage hardware.
Best practices
- Always back up mod project files before making large changes
- Use descriptive filenames that indicate the file's purpose
- Avoid special characters in filenames to maintain cross-platform compatibility
- Enable visible file extensions in File Explorer for clarity
- Keep project files organized in a dedicated folder hierarchy
- Maintain source and delivery files as separate, parallel artefacts
- Use version control (Git with LFS) alongside any cloud-storage synchronisation
- Run a periodic integrity-verification check on active project files
- Test the backup restore process at least monthly to verify backup integrity
- Treat file corruption recovery as an expected occurrence, not a rare exception
Appendix A: File system internals for the curious developer
The file system internals below are a deeper-than-required reference for mod developers who want to understand how the file abstraction is implemented under the hood. The material is not required for any mod-development task but is useful background for developers planning to specialise in technical work.
The NTFS file system used by modern Windows organises a drive into several principal structures. The Master File Table (MFT) is the central index of every file on the drive; each entry in the MFT describes one file, including its name, location, size, and metadata. The data clusters are the actual byte storage on the drive, organised into fixed-size blocks; each file's MFT entry points to one or more data clusters that hold its content. The free-space bitmap tracks which data clusters are currently allocated to a file and which are free for new allocation.
| NTFS internal structure | Purpose | Practical implication for mod developers |
|---|---|---|
| Master File Table (MFT) | Index of all files | File-system corruption typically corrupts the MFT |
| Data clusters | Actual byte storage | Drive fragmentation increases read time |
| Free-space bitmap | Allocation tracking | Drive fills as files are created |
| Journal | Change log for crash recovery | Power loss is recoverable through the journal |
| Security descriptors | Access permission tracking | Permission errors map to security descriptor mismatches |
| Reparse points | Special-purpose file entries | Symbolic links are reparse points |
| Sparse files | Files with unallocated regions | Some game assets use sparse file structure |
The internal structures above are managed entirely by the operating system; mod developers do not interact with them directly. The structures matter because they determine performance characteristics, recovery options, and the failure modes of the underlying file system.
Did you know?
The NTFS journal is the mechanism by which Windows recovers from a power loss or crash during a file write. The journal records every pending change before applying it to the file system; if a crash interrupts the change, the journal can either replay the change to completion or roll it back. The journal is one of the reasons modern Windows file corruption is much rarer than it was in the era of FAT32 (which had no equivalent mechanism).
Appendix B: Practical file-management equipment recommendations
The equipment recommendations below cover the file-management-specific equipment that established commercial mod studios converge on over time. The recommendations complement the broader hardware recommendations in What is Unturned?.
| Equipment category | Recommended specification | Rationale |
|---|---|---|
| Primary project storage | NVMe SSD, 1 TB or larger | Performance under sustained read-write load |
| Source-asset backup | External SSD or HDD, 4 TB or larger | Capacity for full source-asset history |
| Cloud backup target | Cloud storage with version history | Offsite resilience |
| File comparison tool | Beyond Compare, Meld, or equivalent | Three-way merge for collaboration |
| Hex editor | HxD, 010 Editor, or equivalent | Diagnosing binary file corruption |
| Disk imaging tool | Macrium Reflect or equivalent | Whole-drive recovery option |
| File integrity checker | HashCheck or equivalent | Periodic verification of source assets |
| Power conditioning | UPS with at least 10 minutes runtime | Prevents power-loss corruption |
The equipment recommendations above are aspirational; new mod developers should not delay starting work in pursuit of the full target stack. The single most impactful upgrade for a constrained-budget developer is the move from a hard drive to an NVMe SSD as the primary project storage.
Best practice
The dominant pattern across established commercial mod studios is to maintain a three-layer storage strategy: primary work on a fast NVMe SSD, weekly mirror to an external drive, and irregular cloud snapshots. The three layers protect against three distinct failure modes (workstation drive failure, external drive failure, site-loss disasters) and the combined cost is small relative to the value of the protected assets.
Appendix C: Compatibility matrix between file types and mod tools
The compatibility matrix below summarises which file types are produced and consumed by which mod-development tools. The matrix is intended as a reference for new mod developers selecting tools for each step of the workflow.
| File type | Authored in | Consumed by | Editable in |
|---|---|---|---|
.dat configuration | Text editor | Unturned game | Any text editor |
.json configuration | Text editor or IDE | OpenMod, custom tools | Any text editor |
.png texture | Image editor | Unity Editor, game | Image editor only |
.tga texture | Image editor | Unity Editor, game | Image editor only |
.psd source | Photoshop | Photoshop (export to PNG) | Photoshop, GIMP (limited) |
.fbx mesh | 3D modelling tool (export) | Unity Editor, game | 3D modelling tool (re-import) |
.blend source | Blender | Blender (export to FBX) | Blender |
.unity3d bundle | Unity Editor (build) | Unturned game | Not directly editable |
.cs source | C# IDE | C# compiler | Any text editor (IDE preferred) |
.dll binary | C# compiler (output) | OpenMod runtime | Not directly editable |
.md documentation | Text editor | Documentation tools | Any text editor |
The matrix shows the typical authoring and consumption flow for each file type. The general pattern is: source files are authored in a dedicated tool, exported to a delivery format, and consumed by the engine. Maintaining the distinction between source and delivery files is essential for long-term mod-project maintainability.
Appendix D: Extended scenarios for file-management problems
The scenarios below describe representative file-management problems that new mod developers encounter. Each scenario is composed from documented patterns across the established commercial mod studios and the broader community.
Scenario 1: The accidentally overwritten source file
A new mod developer is working on an item mod with a custom texture. The developer authors the source texture in Photoshop as MyItem.psd, exports it to MyItem.png for engine consumption, and continues iterating. After several days of iteration, the developer wants to revisit an earlier version of the texture but discovers that the most recent export was saved over the source file by accident; the .psd file has been replaced with the flattened .png content. The authoring layer information is lost.
The recovery path depends on whether the developer maintains version control. With Git LFS configured for the project, the previous version of the source file is recoverable from the version history. Without version control, the recovery options are limited to cloud-storage version history (if the cloud backup retains old versions), system-restore points (which sometimes preserve file history), or specialised recovery tools (with limited success rates). The dominant lesson from this scenario is that version control is the primary defence against the accidentally overwritten source file.
Scenario 2: The mod that loads but appears incorrectly
A new mod developer publishes an item mod to Steam Workshop and receives a customer report that the mod loads but the item appears with default art rather than the custom art the developer intended. The developer verifies that the source files are correct and the asset bundle was built without errors.
The investigation reveals that the asset bundle was built against a Unity Editor version that does not match the Unturned target. The bundle file loads (because it is a valid Unity bundle) but the engine cannot interpret its contents correctly. The fix is to install the correct Unity Editor version, rebuild the bundle, and republish. The dominant lesson from this scenario is that Unity version matching is the most common cause of mods that load but render incorrectly.
Scenario 3: The corrupted configuration file
A new mod developer is working on a server-side plugin and notices that the plugin has begun behaving erratically after several weeks of development. The developer opens the plugin's configuration file in the text editor and discovers that the file contains garbled binary content rather than the expected human-readable text.
The investigation reveals that the file was corrupted during a workstation power loss several days earlier. The mod-development tool was in the middle of writing the file when the power was lost, leaving the file in an intermediate state. The recovery path is to restore the file from the latest backup. The dominant lesson from this scenario is that power-loss corruption is rare but real and that uninterruptible power supplies are a worthwhile investment for active mod development.
Scenario 4: The file system that refuses to free disk space
A new mod developer notices that the workstation drive is filling up rapidly even though the developer has been deleting old project files regularly. The drive reports approximately 200 GB used but the developer can only account for approximately 80 GB of active files.
The investigation reveals that the project folder is being synchronised to a cloud storage service that keeps version history for every file. The accumulated version history occupies approximately 120 GB of additional space that is not visible in the normal File Explorer view. The fix is to configure the cloud storage to limit version history to a documented retention window. The dominant lesson from this scenario is that cloud-storage synchronisation has hidden disk-space implications that new mod developers should account for.
Appendix E: Equipment recommendations for safe file management
The equipment recommendations below summarise the file-safety equipment that established commercial mod studios converge on over time. The recommendations are aspirational; new mod developers should not delay starting work in pursuit of the full target stack.
| Equipment category | Recommended specification | Rationale |
|---|---|---|
| Primary workstation drive | NVMe SSD, 1 TB or larger | Performance under sustained read-write load |
| Secondary backup drive | External SSD, 4 TB or larger | Capacity for full source-asset history |
| Tertiary backup target | Cloud storage with version history | Offsite resilience |
| Uninterruptible power supply | UPS with at least 10 minutes runtime at workstation load | Prevents power-loss corruption |
| Surge protector | Whole-house or per-outlet surge protection | Prevents hardware damage during electrical events |
| File integrity checker | HashCheck or equivalent | Periodic verification of source assets |
| Disk imaging tool | Macrium Reflect or equivalent | Whole-drive recovery option |
| Version control tooling | Git client plus LFS extension | Recovery from accidental overwrites |
| File comparison tool | Beyond Compare, Meld, or equivalent | Three-way merge for collaboration |
| Hex editor | HxD, 010 Editor, or equivalent | Diagnosing binary file corruption |
Pro tip
The single most impactful file-safety equipment upgrade for a new mod developer working on a constrained budget is the addition of an uninterruptible power supply. The UPS protects against power-loss corruption (the dominant cause of unexpected file corruption in active development), provides graceful-shutdown time for the operating system, and additionally protects against electrical events that would otherwise damage the workstation hardware. The investment pays back the first time it prevents corruption of a multi-week project's source files.
Common mistake
Treating a single cloud-storage synchronisation as a complete backup strategy. The cloud-storage synchronisation copies the latest version of every file to the cloud, but it does not isolate the cloud copy from corruption that propagates from the workstation. A file corrupted on the workstation and immediately synchronised is corrupted in the cloud as well. Maintain at least one offline backup (an external drive disconnected when not in use) as a hedge against corruption that propagates through always-on synchronisation.
Appendix F: Troubleshooting flow for common file problems
The flowchart below addresses the most common file-related problems that new mod developers encounter. The flow is a triage entry point; the dedicated troubleshooting chapter in the modding-tools section of this knowledge base provides the deep coverage.
The flowchart is the recommended triage entry point. The dedicated troubleshooting chapter provides deeper coverage for each branch.
Best practice
Maintain a personal troubleshooting notebook from the first mod onward. The notebook accumulates into a substantial personal reference within months and becomes a documented onboarding aid for any future collaborator. Established commercial mod studios maintain shared studio-level troubleshooting notebooks as a standing operational asset.
Appendix G: Benchmark table for file operations
The benchmark table below summarises documented file operation timings across common mod-development storage configurations. The figures are intended as a planning aid; substantial variation by specific hardware and workload is normal.
| Operation | NVMe SSD | SATA SSD | Mechanical HDD | Cloud (synchronous) |
|---|---|---|---|---|
| Open small configuration file | Less than 50 ms | Less than 100 ms | 200-500 ms | 500-2000 ms |
| Open medium texture file | Less than 100 ms | Less than 200 ms | 500-1500 ms | 1000-5000 ms |
| Open large asset bundle | Less than 500 ms | Less than 1 s | 3-10 s | 5-30 s |
| Save small configuration file | Less than 50 ms | Less than 100 ms | 100-300 ms | 500-3000 ms |
| Save large asset bundle | Less than 2 s | 2-5 s | 10-30 s | 30-120 s |
| Build full asset bundle | 30 s - 2 min | 1-4 min | 4-15 min | Not practical |
| Copy 1 GB of files | 5-15 s | 10-30 s | 30-90 s | 5-30 min |
| Full project rebuild | 5-15 min | 10-30 min | 30-90 min | Not practical |
The figures above show the dramatic performance difference between modern NVMe storage and older spinning drives. The cumulative time savings across a multi-hour development session can be substantial; the cumulative time savings across a multi-week project arc are documented to exceed the cost of upgrading from a spinning drive to an NVMe SSD several times over.
Did you know?
The performance difference between NVMe SSDs and mechanical hard drives is not uniform across all operations. Sequential reads (loading a single large file) show a roughly 4-10x speedup. Random reads (accessing many small files scattered across the drive) show a 50-100x speedup. Mod-development workloads are typically random-read-heavy (Unity Editor projects contain thousands of small asset files), which is why the practical speedup from NVMe is substantially larger than benchmark numbers suggest.
Appendix H: Glossary of file-related terminology
The glossary below defines the file-related terminology that recurs throughout the 57 Studios Modding Knowledge Base. New mod developers should familiarise themselves with the terminology before progressing to the technical chapters.
| Term | Definition |
|---|---|
| Backup | A separate copy of a file maintained for recovery purposes |
| Bundle | A packaged collection of multiple files in a single delivery format |
| Bytes | The atomic unit of file content, one byte holds approximately one text character |
| Cluster | The block size used by the file system for allocating disk space |
| Configuration file | A text file defining the properties of an in-game entity |
| Content | The actual data stored inside a file |
| Corruption | An unexpected alteration of file content that prevents correct operation |
| Delivery file | The exported format consumed by the engine |
| Extension | The suffix at the end of a filename indicating its type |
| File | A discrete unit of stored data on a computer's drive |
| File Explorer | The Windows graphical file management application |
| File system | The index mapping file names to physical storage locations |
| Hidden file | A file whose visibility is suppressed by the operating system default |
| Hierarchy | The nested folder structure containing files |
| Integrity | The property that a file's contents match expectations |
| Journal | The file system's change log for crash recovery |
| Master File Table | The NTFS central index of files on a drive |
| Metadata | Information about a file that is not part of its content |
| Name | The human-readable label identifying a file |
| NTFS | The file system used by modern Windows |
| Path | The textual representation of a file's location |
| Permission | The access right controlling who can read or write a file |
| Recycle Bin | The Windows holding area for deleted files |
| Source file | The authoring file with editable structure |
| Storage hardware | The physical drive holding files |
| Synchronisation | The process of keeping multiple copies of a file in agreement |
| Version control | A system tracking changes to files over time |
The glossary above is the foundational file-related reference. A more detailed glossary covering advanced topics is maintained in the reference chapters.
Appendix I: Cross-platform considerations for file names
The cross-platform considerations below summarise the documented file-name differences between Windows, macOS, and Linux that recur in mod-development collaboration. Mod developers working across multiple operating systems or collaborating with developers on different operating systems should be aware of these differences.
| Consideration | Windows | macOS | Linux |
|---|---|---|---|
| Case sensitivity | Case-insensitive | Case-insensitive (default) | Case-sensitive |
| Maximum path length | 260 characters (default) | 1024 characters | Varies, often 4096 |
| Forbidden characters | `< > : " / \ | ? *` | : |
| Reserved names | CON, PRN, AUX, etc. | None | None |
| Hidden file convention | Hidden attribute flag | Leading period | Leading period |
| Unicode support | Full | Full | Full |
| Trailing periods or spaces | Often stripped silently | Permitted | Permitted |
The cross-platform considerations are most relevant for mod developers who collaborate across operating systems or who plan to work from multiple workstations. The dominant pattern across established commercial mod studios is to adopt the most restrictive intersection of all platforms (case-consistent file names, no special characters, no reserved names, paths under 200 characters) as the studio-wide naming convention. The intersection works reliably on all three platforms and avoids the documented collaboration friction that arises from platform-specific naming choices.
Best practice
Adopt the lowest-common-denominator file naming convention from the first project. Mod developers who start with permissive Windows naming and later need to collaborate with macOS or Linux contributors face a documented renaming burden that consumes substantial time. Starting with the restrictive convention costs essentially nothing and prevents the renaming burden entirely.
Appendix J: Recommended reading order across the knowledge base
The file-system foundation chapters are most useful when read in the recommended order. The table below summarises the recommended sequence and the reasons each chapter follows the one before it.
| Order | Chapter | Why it follows the previous chapter |
|---|---|---|
| 1 | What is Unturned? | Establishes the game and ecosystem |
| 2 | What is Modding? | Establishes the discipline of modding |
| 3 | What is a File? (this article) | First file-system foundation |
| 4 | What is a Folder? | Builds on files to introduce hierarchical organisation |
| 5 | What is a File Extension? | Extends file knowledge with type identification |
| 6 | Installing Steam and Unturned | First tooling installation chapter |
| 7 | Installing the Unity Editor | Second tooling installation chapter |
| 8 | First item mod walkthrough | First end-to-end project |
The recommended sequence is the order that established commercial mod studios converge on when onboarding new contributors. Readers may deviate from the order based on existing skills and prior tool familiarity, but the file-system foundation chapters (this article and What is a Folder?) are the recommended minimum starting set for every reader who lacks a strong existing file-system mental model.
Pro tip
The thirty minutes invested in reading this article fully pays back across every subsequent technical chapter. Mod-development troubleshooting frequently traces back to file-related misunderstandings (incorrect file types, wrong file locations, corrupted source files, missing backups); the foundational understanding established here makes future troubleshooting substantially faster.
Appendix K: Document history and revision log
The 57 Studios Modding Knowledge Base is maintained as a living document. The revision log below records the principal updates to this article.
| Revision | Date | Notes |
|---|---|---|
| 1.0 | Initial publication | First introduction to files as a concept |
| 1.1 | Anatomy detail | Expanded the four-component file anatomy |
| 1.2 | Category expansion | Added extended file-category coverage |
| 1.3 | Integrity coverage | Added the file-integrity verification section |
| 1.4 | Scenarios and troubleshooting | Added extended scenarios and troubleshooting flowchart |
| 1.5 | Equipment and benchmarks | Added equipment recommendations and benchmark table |
| 1.6 | Cross-platform considerations | Added cross-platform file-name section |
| 1.7 | Current revision | Added appendices, expanded FAQ, file system internals |
The knowledge base maintainers update this article when documented ecosystem shifts warrant inclusion. Readers who notice an inaccuracy or an outdated reference are encouraged to flag the discrepancy through the knowledge-base contribution channels.
The maintainers of this article additionally track engine refreshes by Smartly Dressed Games, Unity Editor version migrations, and documented shifts in file-format conventions across the broader mod-development ecosystem. Each refresh, migration, or shift triggers a review of this article's content and prompts a revision where necessary. The revision log above records the cumulative history of those reviews and revisions.
Next steps
Continue to What is a Folder? to learn how files are organized into hierarchical structures. Related articles include the dedicated chapter on file extensions for the role of extensions in identifying file types, and the broader file-system foundations chapter sequence for additional context.
The next article in the foundational sequence builds directly on the file concept established here. Files alone are useful; files organised into hierarchical folder structures are essential for any mod project beyond a single item. The combination of file knowledge and folder knowledge forms the file-system foundation on which every subsequent technical chapter rests.
Readers who feel uncertain about any of the concepts introduced in this article are encouraged to re-read the relevant sections before progressing. The foundational chapters are explicitly designed for re-reading; mod developers commonly report returning to the foundational chapters after a year or more of practical experience and finding new layers of meaning in the material. The investment in foundational understanding compounds across the multi-year arc of a mod-development career.
The 57 Studios Modding Knowledge Base is the studio's documented contribution to the public record of Unturned mod development practices. The foundational chapters are the most-read material in the knowledge base by a wide margin, and the studio invests substantial effort in keeping them current, accurate, and useful for new mod developers entering the field.