# Module data

A module is mostly a container. The actual settings live in its **data** entries: `Module_Engine` holds `Data_Engine`, `Module_Deployable` holds `Data_Deployable`, `Module_Drag` holds `Data_Drag`. When you want to change a number on a part, you are almost always reaching into a data entry. This page covers that level.

## Reaching a data entry

Inside a module callback, the data entries use the same five methods as everything else, one level down:

* `module:AddData(type, callback)` adds a new data entry and errors if it already has one.
* `module:PatchData(type, callback)` edits an existing entry, doing nothing if absent.
* `module:EnsureData(type, callback)` adds it if missing or patches it if present.
* `module:RemoveData(type)` removes it.
* `module:HasData(type)` tests for it.

The callback receives the data entry. This is where the editing happens:

```lua
PM.Parts:Patch("AirbrakeControlSurfaceActuation")
        :Named("airbrake_1v")
        :Do(function(part)
            part:PatchModule("Module_ControlSurface", function(module)
                module:PatchData("Data_ControlSurface", function(data)
                    data.IsCtrlSurfaceActive = true
                    data.AllowControl = true
                    data.UseAirbrakeControl = true
                    data.CtrlSurfaceRange = 90.0
                end)
            end)
        end)
```

The form is always the same: patch the part, patch the module, patch the data, set fields.

## The nesting reads like the tree

A part is a tree (part, module, data, field), and the callback nesting mirrors it exactly. Read it top to bottom and each `Patch` call goes one level deeper:

```
part
  PatchModule("Module_X")
    PatchData("Data_X")
      data.someField = value
```

When you only need a single field and you are sure the path exists, the property chain from the [modules page](/doc/part-modules-PG9FsLYQ5t) is shorter (`part.Module_Deployable.Data_Deployable.deployMaxTemp`). When you are setting several fields, or the module might be absent, the nested callbacks are clearer and safer.

## Editing values inside a data entry

Inside the data callback, the entry behaves like any other [JSON value](/doc/working-with-json-fWfY8KrejF). Plain fields are assignments. Lists have the list methods, and you can iterate them. This real patch walks a drag module's cubes and edits the one named `DEPLOYED`:

```lua
module:PatchData("Data_Drag", function(data)
    for _, cube in pairs(data.cubes) do
        if cube.Name == "DEPLOYED" then
            -- ... edit this cube ...
        end
    end
    data.UpdateExposedArea = true
end)
```

## Data names

Data entries are named `Data_<Something>`, matching their module: `Data_Engine`, `Data_Deployable`, `Data_Drag`, `Data_ControlSurface`. That is the string you pass to the data methods. As with modules, your editor will offer the data types it knows about from `pm-parts.d.lua`.

## Engines are special

`Data_Engine` is large and has a typed helper for its modes, so it gets its own page. See [Engine modes](/doc/engine-modes-W4COLIYupq). Everything on this page still applies to it: you reach `Data_Engine` through `PatchData` on `Module_Engine` exactly like any other data entry.