Skip to content

What is a Folder?

A folder is a container for files and other folders. Folders allow a computer's storage to be organized into nested, hierarchical structures rather than a flat list of every file on the drive. For Unturned™ mod development, folders are essential. Every mod is a folder containing a specific set of files arranged in a conventional structure that the game engine and modding tools expect. This reference explains what folders are, how they relate to each other, how paths describe folder locations, and what the inside of an Unturned mod folder looks like.

The article that follows is the fourth foundational orientation document in the 57 Studios™ Modding Knowledge Base. The previous three orientation articles establish the game (What is Unturned?), the discipline of modding (What is Modding?), and the foundational concept of files (What is a File?). The present article completes the file-system foundations by introducing folders, the hierarchical structures that folders form, and the conventional folder layouts of Unturned mod projects. Together, the four foundational articles form the conceptual scaffolding on which every later technical chapter rests.

A note on scope. This article is descriptive rather than prescriptive. The aim is to convey what folders are, how they organise files into hierarchies, and how Unturned mod projects use folders. The next article (What is a File Extension?) introduces extensions in more depth, and subsequent chapters cover modding-tool installation and the first end-to-end mod project.

Prerequisites

  • Completion of What is a File?
  • Familiarity with the concept of a file
  • Approximately thirty minutes of uninterrupted reading time
  • A willingness to think about hierarchical organisation as a discipline

What you'll learn

  • The technical definition of a folder
  • How folders form hierarchical tree structures
  • Windows path notation and how to read it
  • The conventional structure of an Unturned mod folder
  • Practical folder organization principles for mod projects
  • The distinction between absolute and relative paths
  • The role of folder permissions in mod-development workflows
  • The conventional folder layouts for different mod categories

Background

Folders, also called directories in some operating systems, predate personal computing. The earliest hierarchical file systems appeared in mainframe operating systems in the 1960s. The folder concept solves the problem of organizing large numbers of files: rather than scrolling through thousands of items, a user can group related files into folders and navigate the hierarchy.

The term "folder" was popularized by graphical operating systems beginning with the Apple Lisa in 1983 and Apple Macintosh in 1984, and was adopted by Microsoft Windows shortly thereafter. The visual metaphor of a paper folder containing documents inside a filing cabinet remains the dominant mental model for the concept.

The endurance of the folder concept across decades of computing matters because it shapes the expectations every operating system, every tool, and every mod-development workflow encodes. A mod developer learning Unturned mod work in 2026 is using an organisational concept that has remained stable in its essentials since the 1960s. The investment in folder-organisational discipline pays back across every later project because the underlying concept does not change.

The flowchart above traces the evolution of the folder concept from text-only mainframe directories to the modern graphical folder hierarchies used by Windows mod developers.

An extended timeline of folder organisation

The headline flowchart compresses many smaller events into the four labeled stages. The expanded timeline below records the principal inflection points in folder organisation that affected the present-day Unturned mod-development workflow.

The timeline shows the folder-organisation progression in detail. Each inflection point produced refinements to the folder interface, but the underlying organisational concept has remained constant across the entire arc.

Did you know?

The technical term in Unix and Linux operating systems is "directory" rather than "folder." Both terms refer to the same underlying concept, but "folder" emphasizes the visual metaphor while "directory" emphasizes the technical function of looking up files by name.

Did you know?

The earliest version of MS-DOS, released in 1981, did not support subdirectories. Every file on the drive lived in a single flat list. MS-DOS 2.0, released in 1983, added subdirectory support and transformed the practical use of personal computers; before subdirectories, organising more than a few hundred files was extremely difficult. The introduction of hierarchical directories was one of the most significant single advances in early personal computing.

Folders as containers

A folder can contain three kinds of things:

  1. Files of any type
  2. Other folders, which can themselves contain files and folders
  3. Nothing, in which case the folder is described as empty

A folder that contains other folders is called the "parent" of those folders. The folders inside it are called "children" of the parent. A folder with no parent is called a "root" folder. On Windows, each drive has its own root folder, typically C:\ for the primary system drive.

The parent-child terminology recurs throughout file-system documentation and recurs throughout the rest of the 57 Studios knowledge base. A new mod developer should commit the terminology to memory: the parent contains the child, the child is inside the parent, the root has no parent, and the leaf nodes (the actual files) sit at the bottom of each branch of the tree.

Folder relationships in detail

The table below summarises the principal folder relationships and the terminology used to describe them.

RelationshipDescriptionExample
ParentThe folder that contains another folderC:\Users is the parent of C:\Users\Butter
ChildA folder contained inside another folderC:\Users\Butter is a child of C:\Users
SiblingTwo folders sharing the same parentC:\Users\Butter and C:\Users\Guest are siblings
AncestorAny folder above the current folder in the hierarchyC:\ is an ancestor of C:\Users\Butter\Documents
DescendantAny folder below the current folder in the hierarchyC:\Users\Butter\Documents is a descendant of C:\
RootThe folder at the top of the hierarchyC:\ is the root of the C drive
LeafA folder with no children, or a file at the bottom of a branchMyItem.dat is a leaf in the file system tree

The relationships above are the foundational vocabulary for discussing folder structures. Mod-development documentation, tool error messages, and collaboration discussions all use this vocabulary consistently.

Hierarchical structure

When folders contain other folders, the result is a tree structure. The tree starts at a root and branches downward through parent folders to child folders to grandchild folders, and so on, until it reaches the leaves: the actual files at the bottom of each branch.

C:\
├── Program Files\
│   ├── Steam\
│   │   ├── steamapps\
│   │   │   └── common\
│   │   │       └── Unturned\
│   │   └── userdata\
│   └── Unity\
└── Users\
    └── YourUserName\
        ├── Documents\
        └── Desktop\

The ASCII tree diagram above shows a small portion of a typical Windows file system. The root, C:\, contains the Program Files and Users folders, which in turn contain further folders that eventually lead to specific applications and user data.

File Explorer showing an expanded folder tree in the left navigation pane

A deeper file-system tree example

The headline tree is intentionally compact. A more representative tree for a mod developer's workstation includes additional branches that recur in everyday work.

C:\
├── Program Files\
│   ├── Steam\
│   │   ├── steamapps\
│   │   │   └── common\
│   │   │       └── Unturned\
│   │   │           ├── Bundles\
│   │   │           ├── Maps\
│   │   │           └── Modules\
│   │   └── userdata\
│   ├── Unity\
│   │   └── Hub\
│   │       └── Editor\
│   │           └── 2021.3.x\
│   └── Blender Foundation\
│       └── Blender 4.x\
└── Users\
    └── Butter\
        ├── Documents\
        │   └── UnturnedMods\
        │       ├── ItemMods\
        │       │   ├── MyFirstItem\
        │       │   └── MySecondItem\
        │       ├── VehicleMods\
        │       │   └── MyFirstVehicle\
        │       └── MapMods\
        │           └── MyFirstMap\
        ├── Desktop\
        └── AppData\
            ├── Local\
            └── Roaming\
                └── Unturned\
                    └── Workshop\

The deeper tree shows the folder structure that a typical Unturned mod developer maintains across the workstation. The Program Files branch holds the installed development tools (Steam, Unity, Blender). The Users branch holds the developer's personal project folders organised by mod category. The AppData branch holds the runtime data that the game and tools maintain across sessions.

Windows path notation

A path is a textual representation of a folder's location in the hierarchy. Paths read from left to right, starting at the root and descending through each parent folder, separated by backslashes on Windows.

The path C:\Program Files\Steam\steamapps\common\Unturned describes a specific folder by listing every parent from the root down to the target folder. This notation is universal in Windows and appears throughout mod development tools, configuration files, and documentation.

The flowchart above visualizes the same path as a left-to-right traversal of the folder hierarchy. Each arrow represents descending one level into a child folder.

Pro tip

Click into the address bar of any File Explorer window to see the current location as a complete path. Copying this path is the fastest way to share a folder location with another developer or paste it into a tool that expects an absolute path.

Path components and their meanings

A Windows path consists of several distinct components. The table below summarises each component and its role.

ComponentDescriptionExample
Drive letterThe letter identifying the storage deviceC:
Drive separatorThe colon and backslash after the drive letter:\
Path separatorThe backslash between folder names\
Folder nameThe name of each folder in the pathProgram Files, Steam
Trailing separatorAn optional backslash at the end of a path\
File nameThe name of the file at the leaf of the pathMyItem.dat
File extensionThe suffix indicating file type.dat

The path C:\Program Files\Steam\steamapps\common\Unturned\Bundles\MyItem.dat contains each component: drive letter C, drive separator :\, path separators \ between folder names, six folder names, and the file name MyItem.dat with its extension .dat at the leaf position.

Anatomy of an Unturned mod folder

Unturned mods follow a conventional folder structure that the game engine recognizes. The exact structure varies by mod category, but most mods include similar elements.

MyCustomItemMod\
├── English.dat
├── Asset.dat
├── Item.dat
├── Icon.png
├── Mesh.unity3d
└── README.md

The ASCII tree above shows the structure of a small item mod. Each file plays a specific role: configuration files define the item's properties, the icon file provides the inventory thumbnail, the bundle file contains the 3D model and texture data, and the readme provides installation instructions to end users.

Larger mods, such as vehicle packs or map mods, typically nest content into subfolders for organization.

MyVehiclePack\
├── ReadMe.md
├── English.dat
├── Vehicles\
│   ├── PoliceCruiser\
│   │   ├── English.dat
│   │   ├── Asset.dat
│   │   ├── Vehicle.dat
│   │   └── Bundle.unity3d
│   └── DeliveryVan\
│       ├── English.dat
│       ├── Asset.dat
│       ├── Vehicle.dat
│       └── Bundle.unity3d
└── Bundles\
    └── Shared\
        └── SharedAssets.unity3d

The vehicle pack tree above demonstrates how subfolders separate individual vehicles into their own organized units. This pattern scales cleanly as the number of vehicles in the pack grows.

Best practice

Name folders descriptively and consistently across all mod projects. Generic folder names such as New Folder and stuff make a project difficult to maintain. Names such as Textures, Models, and Configuration communicate the purpose of each folder at a glance.

Conventional folder structures by mod category

The table below summarises the conventional folder structure for each major mod category. New mod developers should adopt these conventions from the first project; established commercial mod studios converge on essentially these conventions across their portfolios.

Mod categoryTypical top-level structureTypical subfolders
Single itemFlat folderNone
Item packOne folder per itemItems\ItemName\ for each item
Single vehicleFlat folderNone or Bundles\
Vehicle packOne folder per vehicleVehicles\VehicleName\ for each vehicle
MapMulti-level folderTerrain\, Assets\, Localization\
Server-side pluginStandard C# projectSource\, bin\, obj\, Configuration\
Total conversionMulti-level folderAll of the above by category

The conventional structures above are the documented norms across the established commercial mod studios. Deviating from the conventions is permitted but produces collaboration friction and complicates tool support.

Comparison of folder organization patterns

PatternDescriptionBest for
FlatAll files in a single folderSingle-item mods
By typeSubfolders by file category (Textures, Models, Configuration)Medium mods with many similar files
By featureSubfolders by feature or item (PoliceCruiser, DeliveryVan)Large packs with distinct components
MixedTop-level by feature, second-level by typeComplete vehicle packs and total conversions

The pie chart above shows the approximate distribution of folder organization patterns observed in published professional Unturned mods.

Side-by-side comparison of a disorganized mod folder and a well-organized mod folder

Pattern selection criteria

The selection criteria below help new mod developers choose the appropriate folder organisation pattern for a given project. The criteria are heuristics; experience eventually refines the developer's intuition for pattern selection.

CriterionFlat patternBy-type patternBy-feature patternMixed pattern
Project sizeLess than 10 files10-50 files20-200 filesMore than 100 files
Number of features11-33-30More than 5
Collaborator countSoloSolo or small teamSmall teamTeam
Asset diversityLowHigh (many file types)High (many distinct items)High both axes
Customer-facing modularityNot applicableLimitedHighHigh

The criteria above are not strict rules. A solo developer building a small vehicle pack with three vehicles may legitimately use either the by-feature pattern (one folder per vehicle) or the mixed pattern (top-level by vehicle, second-level by file type). The dominant lesson is that some discipline is far better than none; any of the four patterns is preferable to a disorganised folder.

Decision flowchart: choosing a folder structure

The decision flowchart above helps a mod developer select an appropriate folder structure for a new project. The right structure depends on the project's scope and complexity.

Absolute and relative paths

Paths come in two varieties.

An absolute path begins at the root of the drive and specifies the complete location of a folder. Example: C:\Users\Butter\Documents\UnturnedMods\MyMod.

A relative path begins at an assumed current location and describes how to reach the target from there. Example: ..\Textures\Eaglefire.png means "go up one folder, then into the Textures folder, and find Eaglefire.png."

Mod configuration files frequently use relative paths to remain portable. A configuration that references Textures\Icon.png will work regardless of where the user installs the mod, while a configuration referencing C:\Users\OriginalAuthor\Desktop\MyMod\Textures\Icon.png will fail on any computer except the original author's.

Common mistake

New mod developers sometimes hard-code absolute paths into configuration files, then wonder why the mod fails for end users. Always use relative paths in mod configuration. Absolute paths leak the developer's local directory structure and break installation on any other machine.

Path notation in detail

The path notation conventions below recur throughout mod-development documentation, tool error messages, and configuration files. New mod developers should commit them to memory.

NotationMeaningExample
.The current folder.
..The parent folder..
\Path separator (Windows)Folder\Subfolder
/Path separator (cross-platform, often accepted on Windows)Folder/Subfolder
C:\The root of the C driveC:\
~The user's home folder (Unix-style, supported by some tools)~/UnturnedMods
%USERPROFILE%Windows environment variable for the user's home folder%USERPROFILE%\Documents

The notation ..\Textures\Eaglefire.png reads as: go to the parent folder, then into the Textures subfolder, then locate Eaglefire.png. Each .. ascends one level in the hierarchy; multiple .. segments stack to ascend multiple levels.

Folder permissions

Folder permissions control who can read, write, or modify the contents of a folder. On Windows, system folders such as C:\Program Files and C:\Windows have restrictive permissions that prevent accidental modification. Mod project work should happen in a user-writable location, such as a folder inside C:\Users\YourName\Documents or a dedicated project folder elsewhere on the drive.

The flowchart above shows the hierarchy of folder permissions on Windows. Each higher level includes all lower levels: full control includes modify; modify includes write and read; write includes read.

Critical warning

Never store the only copy of an important mod project in a system-protected location such as C:\Program Files. The combination of restrictive permissions and frequent Windows updates can render such folders inaccessible or cause work to be lost.

Frequently asked questions

What is the difference between a folder and a directory?

The two terms refer to the same concept. Folder emphasizes the visual metaphor used in graphical file managers, while directory is the technical term used in command-line interfaces and programming contexts.

Can a folder have the same name as a file in the same parent?

Yes, technically, because the file system distinguishes between files and folders. In practice, this is confusing and should be avoided. Pick unambiguous names.

Is there a maximum number of files a folder can hold?

The technical limit imposed by NTFS, the file system used by modern Windows, is approximately four billion files per folder. Long before reaching that limit, performance degrades and File Explorer becomes unresponsive. Folders with more than a few thousand files should be reorganized into nested subfolders.

Why does Windows hide certain folders by default?

System folders containing configuration data are hidden to prevent accidental modification that could break the operating system. Mod developers occasionally need to view hidden folders, which can be enabled through a File Explorer setting.

How deep can a folder hierarchy go?

The technical limit is approximately 260 characters for the total path length on default Windows configurations. The practical limit is whatever depth remains navigable; folder hierarchies deeper than about six or seven levels become difficult to read in File Explorer and tedious to address in path notation. Most established commercial mod studios converge on hierarchies of three to five levels.

What happens if I delete a folder that contains files?

Deleting a folder deletes everything inside it: files and any nested subfolders. Windows moves the deleted content to the Recycle Bin by default, where it can be restored. Folders deleted using shift-delete are removed from the file system index immediately. Always verify a folder's contents before deleting it.

Can a folder contain itself?

No. The file system enforces a strict tree structure with no cycles. A folder cannot be a child of itself or of any of its descendants. Attempts to create such a structure are rejected by the operating system.

A symbolic link is a special file system entry that points to another location. Opening a symbolic link to a folder behaves as if the user opened the target folder directly. Symbolic links are sometimes used to create alternate access paths to folders without duplicating content; they are an advanced feature not commonly required in mod development.

How do I copy a folder?

In File Explorer, select the folder and use Ctrl+C to copy, then Ctrl+V at the destination to paste. The operation copies the folder and all of its contents. Copying a large folder may take several minutes depending on size and storage speed.

How do I rename a folder?

In File Explorer, right-click the folder and select Rename, or select the folder and press F2. The folder's name changes immediately. Note that renaming a folder may break references to it from other tools or configuration files; always check whether any references need to be updated.

Can two folders have the same name?

Two folders cannot have the same name within the same parent folder. Two folders in different parent folders can have the same name without conflict. The full path (including all ancestors) is what uniquely identifies any folder in the file system.

What is the difference between Program Files and Program Files (x86)?

C:\Program Files holds 64-bit applications on 64-bit Windows. C:\Program Files (x86) holds 32-bit applications. The distinction matters because some older tools install into the 32-bit folder even on 64-bit Windows. Mod-development tools are typically installed in C:\Program Files, but some legacy tools may install in C:\Program Files (x86).

Best practices

  • Use clear, descriptive folder names
  • Mirror the conventional Unturned mod folder structure for compatibility with modding tools
  • Use relative paths inside configuration files
  • Keep project folders inside user-writable locations
  • Limit the depth of folder hierarchies to what genuinely aids organization
  • Avoid spaces in folder names to prevent command-line and scripting issues
  • Adopt a consistent folder-organisation pattern across all projects
  • Reorganise folders proactively when they exceed a few thousand files
  • Verify folder contents before deletion
  • Document any non-conventional folder structures in the project README

Appendix A: Extended folder layouts for each mod category

The folder layouts below show the conventional structure for each major mod category in greater detail than the headline anatomy section. New mod developers should refer to these layouts when scaffolding new projects.

Single-item mod folder layout

MyCustomItem\
├── README.md
├── English.dat
├── Asset.dat
├── Item.dat
├── Icon.png
└── Bundle.unity3d

The single-item layout is the simplest viable mod folder. All files sit at the top level. This layout is appropriate for the first item mod a new developer ships and for any single-item commercial release.

Item pack folder layout

MyItemPack\
├── README.md
├── English.dat
├── ChangeLog.md
└── Items\
    ├── Pistol\
    │   ├── English.dat
    │   ├── Asset.dat
    │   ├── Item.dat
    │   ├── Icon.png
    │   └── Bundle.unity3d
    ├── Rifle\
    │   ├── English.dat
    │   ├── Asset.dat
    │   ├── Item.dat
    │   ├── Icon.png
    │   └── Bundle.unity3d
    └── Shotgun\
        ├── English.dat
        ├── Asset.dat
        ├── Item.dat
        ├── Icon.png
        └── Bundle.unity3d

The item pack layout uses the by-feature pattern with one subfolder per item. The pack-level README.md and ChangeLog.md describe the pack as a whole, while each item folder contains its individual configuration and asset files.

Vehicle pack folder layout

MyVehiclePack\
├── README.md
├── English.dat
├── ChangeLog.md
├── Vehicles\
│   ├── PoliceCruiser\
│   │   ├── English.dat
│   │   ├── Asset.dat
│   │   ├── Vehicle.dat
│   │   ├── Skin.dat
│   │   └── Bundle.unity3d
│   └── DeliveryVan\
│       ├── English.dat
│       ├── Asset.dat
│       ├── Vehicle.dat
│       └── Bundle.unity3d
└── Bundles\
    └── Shared\
        └── SharedAssets.unity3d

The vehicle pack layout extends the item pack pattern with an additional Bundles\Shared\ folder for assets shared across multiple vehicles. Sharing common assets reduces the total pack size and simplifies maintenance.

Map mod folder layout

MyMap\
├── README.md
├── Config.dat
├── English.dat
├── Localization\
│   ├── German.dat
│   ├── Portuguese.dat
│   └── Russian.dat
├── Terrain\
│   ├── Heightmap.dat
│   ├── Materials.dat
│   └── Roads.dat
├── Bundles\
│   ├── Buildings.unity3d
│   ├── Vegetation.unity3d
│   └── Props.unity3d
└── Navigation\
    └── NavMesh.dat

The map mod layout uses subfolders for each major category of map content: localisation files, terrain data, asset bundles, and navigation mesh. This separation makes large map projects substantially easier to maintain.

Server-side plugin folder layout

MyServerPlugin\
├── README.md
├── ChangeLog.md
├── MyServerPlugin.csproj
├── MyServerPlugin.sln
├── Source\
│   ├── Plugin.cs
│   ├── Commands\
│   │   ├── BalanceCommand.cs
│   │   └── PayCommand.cs
│   └── Services\
│       ├── EconomyService.cs
│       └── PlayerService.cs
├── Configuration\
│   └── default.yaml
├── bin\
│   └── (compiled output)
└── obj\
    └── (build artefacts)

The server-side plugin layout follows the conventions of any C# project. Source code lives in Source\ organised by subdomain. Build outputs land in bin\ and obj\; both folders are conventionally excluded from version control.

Appendix B: Equipment recommendations for folder-organised mod development

The equipment recommendations below address the folder-organisation-specific equipment that established commercial mod studios converge on over time. The recommendations complement the broader hardware recommendations in What is Unturned?.

Equipment categoryRecommended specificationRationale
File explorer enhancementTotal Commander, Directory Opus, or equivalentMulti-pane navigation accelerates folder work
Path-copy utilityPath Copy Copy or equivalentOne-click path copying for sharing
Folder comparison toolBeyond Compare or equivalentDiff folder structures for collaboration
Symbolic link managerBuilt-in mklink or GUI wrapperAlternate access paths without duplication
Folder visualisation toolWinDirStat or equivalentVisual breakdown of folder size and content
Folder hashing toolHashCheck or equivalentVerify folder integrity across copies
Bulk renamerBulk Rename Utility or equivalentFolder and file renaming at scale
Folder backup toolFreeFileSync or equivalentTwo-way folder synchronisation

The equipment recommendations above are aspirational. The single most impactful upgrade for a new mod developer is the move from default File Explorer to a multi-pane file manager (Total Commander or Directory Opus); the productivity uplift is documented and substantial.

Pro tip

A multi-pane file manager such as Total Commander or Directory Opus is the single most impactful folder-management upgrade for an active mod developer. The multi-pane view (two folders side by side) accelerates folder comparison, file movement, and collaboration workflows. The productivity uplift compounds across hundreds of folder operations per day.

Appendix C: Cross-platform folder considerations

The cross-platform folder considerations below summarise the documented 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.

ConsiderationWindowsmacOSLinux
Path separatorBackslash \Forward slash /Forward slash /
Root notationC:\ (drive letter)//
User home folderC:\Users\Name\/Users/Name//home/name/
Hidden folder conventionHidden attribute flagLeading periodLeading period
Case sensitivityInsensitiveInsensitive (default)Sensitive
Maximum path length260 characters (default)1024 charactersOften 4096
Forbidden characters in folder namesVarious:/ and null byte

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 cross-platform-safe folder naming and path conventions from the first project; the small upfront discipline prevents documented collaboration friction.

Best practice

Use forward slashes in configuration files where the tool accepts them. Many modern Windows tools accept forward slashes as path separators, and forward-slash paths are portable across Windows, macOS, and Linux without modification. Backslash paths require translation when collaborating with non-Windows developers.

The flowchart below addresses the most common folder-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.

The glossary below defines the folder-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.

TermDefinition
Absolute pathA path beginning at the root and specifying the complete location
AncestorAny folder above the current folder in the hierarchy
ChildA folder contained inside another folder
DescendantAny folder below the current folder in the hierarchy
DirectoryThe technical term for a folder, used in command-line and Unix contexts
Drive letterThe letter identifying a storage device on Windows
Empty folderA folder containing nothing
File ExplorerThe Windows graphical file management application
FolderA container for files and other folders
Hidden folderA folder whose visibility is suppressed by the operating system default
HierarchyThe nested folder structure forming a tree
LeafA folder with no children, or a file at the bottom of a branch
ParentThe folder containing another folder
PathThe textual representation of a folder's location
Path separatorThe character separating folder names in a path
PermissionThe access right controlling who can read or write a folder
Relative pathA path beginning at an assumed current location
RootThe folder at the top of the hierarchy
SiblingTwo folders sharing the same parent
SubfolderA folder inside another folder
Symbolic linkA special file system entry pointing to another location
TreeThe nested folder structure as a whole
User home folderThe folder containing the user's personal files

The glossary above is the foundational folder-related reference. A more detailed glossary covering advanced topics is maintained in the reference chapters.

Appendix F: 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.

RevisionDateNotes
1.0Initial publicationFirst introduction to folders as a concept
1.1Relationship terminologyAdded parent/child/sibling/ancestor coverage
1.2Pattern selectionAdded pattern selection criteria
1.3Layout coverageAdded extended layouts per mod category
1.4Cross-platform coverageAdded cross-platform considerations
1.5Current revisionAdded appendices, expanded FAQ, troubleshooting flow

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.

Next steps

Continue to What is a File Extension? to learn how the suffix at the end of a filename determines which application handles the file. Related articles include What is a File? for the foundational concept of files and the broader file-system foundations chapter sequence for additional context.

The next article in the foundational sequence builds on both files and folders by introducing extensions as the principal type-identification mechanism. Together, the three file-system foundation articles (files, folders, extensions) form the complete 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. Readers planning to specialise in a particular mod category (items, vehicles, maps, server-side plugins, or total conversions) should complete the foundational chapters before progressing to the category-specific chapters; the category chapters assume the foundational vocabulary and conventions established here.

Readers planning commercial mod publishing should additionally complete the commercial-distribution chapters once the foundational orientation is complete. The commercial chapters cover storefront configuration, customer-support workflow, license-key delivery, and the operational disciplines that distinguish a sustainable commercial mod studio from a hobbyist publisher.

The progression from this foundational article into the technical chapters is the studio's recommended onboarding sequence for new contributors. New mod developers who follow the sequence in order are documented to ship their first mod faster, with fewer recoverable mistakes, than developers who skip the foundational chapters. The thirty-minute investment in this article pays back across every later session in the form of avoided confusion, faster troubleshooting, and stronger collaboration with established mod developers who share the foundational vocabulary established here.

Folders are not glamorous. The conventions documented in this article will not produce a visible feature in any shipped mod. The conventions do produce something more durable: a workstation organisation that scales across multiple projects, a collaboration vocabulary that aligns with the broader community, and a maintenance discipline that prevents the dominant categories of long-term project failure.

The discipline of folder organisation is one of the documented differentiators between mod developers who sustain commercial publishing over multi-year arcs and developers who burn out after a single year of disorganised work. New mod developers who internalise the conventions documented in this article are positioned for sustainable long-term mod development; the foundational discipline pays back across every later project and every later collaboration.