> For the complete documentation index, see [llms.txt](https://stylizededge-devs.gitbook.io/aqs-doc/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://stylizededge-devs.gitbook.io/aqs-doc/getting-started/core-concepts.md).

# Core Concepts

Five ideas explain almost everything about how AQS works. Understanding these makes every other page in this doc make sense immediately.

## 1. Two Layers, Every Preset

Every `AQS Graphics Preset` has two layers of settings:

* **Layer 1 — named fields.** 23 typed properties (`ResolutionScale`, `bBloom`, `ShadowQuality`, etc.) — see [The 23 Fields](/aqs-doc/authoring-presets/the-23-fields.md). These are validated, editor-friendly, and automatically picked up by the descriptor system for menu generation.
* **Layer 2 — `CVarOverrides`.** A raw key/value map for anything not covered by Layer 1. Applied *after* Layer 1, so it always wins.

Layer 1 covers 90% of what any project needs. Layer 2 is the escape hatch.

## 2. Descriptors Are Generated, Not Hand-Written

You never manually declare "this field is a slider, this one is a checkbox." A generator reads Layer 1's fields via C++ reflection and builds that list automatically — including the value type, a sensible default control type, and a player-friendly description.

This is what eliminates the old "hand-wire every slider" workflow entirely. Add a field to the data struct, re-bake, and it appears in every menu built from that bake.

## 3. Baking Exists Because of a Real Engine Limitation

The generator's reflection step only works with full information *inside the editor*. Packaged (Shipping) builds strip that metadata out — it's how Unreal works, not a bug. So the generator's output gets **baked** into a separate, plain-data asset (`AQS Baked Descriptors`) once, in the editor. That baked asset is what actually ships and gets read at runtime.

This is also why there's a **staleness warning** — if you add a field to the data struct and forget to re-bake, the editor will tell you, loudly, right on the preset's Details panel.

## 4. Overrides Are a Second, Optional Layer on Top of the Descriptor List

Just like presets have a Layer 1 / Layer 2 split, the *descriptor list* has the same shape:

* **Default** — whatever the generator derived automatically
* **Override** — an optional `AQS Descriptor Overrides` asset that lets you rename, recontrol, reorder, group, or hide any row — without touching C++

If you don't assign an override asset, you get sensible defaults. If you do, your changes always win.

## 5. The Auto Panel Is the Only Widget With Logic

`WBP_AQS_AutoPanel` does all the work: reading the baked list, spawning the right row template per field, applying changes, syncing rows when a preset switches. The 9 row templates themselves contain **zero logic** — they're pure visual templates that call one function (`SetFloatValue`/`SetBoolValue`/`SetIntValue`) when their control changes.

This split is what lets you restyle a menu completely — colors, layout, fonts, animations — without ever touching the part that actually works.

## How These Fit Together

```
FAQSPresetData (your 23 fields)
        │
        ▼
UAQSDescriptorGenerator   (reads via reflection, editor-only)
        │
        ▼
UAQSBakedDescriptors      (baked once, ships safely)
        │
        ▼  (with optional UAQSDescriptorOverrideAsset applied on top)
        │
UAQSAutoPanel             (reads the bake, builds the menu)
        │
        ▼
9 Row Templates           (pure visuals, zero logic)
```

Once this shape clicks, every other page is just "which knob do I turn for this specific thing."


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://stylizededge-devs.gitbook.io/aqs-doc/getting-started/core-concepts.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.