Azarion Creator Documentation

World Map Editor is the spatial composition tool for authored map overrides in Life, Xolo, Planet and Allure. It places catalog objects and special gameplay markers on metric tiles while leaving the large procedural world system responsible for areas that have not been manually authored.

Choose the target reality and tile, then place terrain/world objects, effects, gates, quest NPCs or Jigsaw content using the available tools. Use RANDOM when any suitable catalog variant is acceptable, or choose and lock an exact asset ID when the design depends on a particular model. Publish the tile when it is ready for runtime clients.

Prepare reusable models in Forge, particle effects in Spark, skies in Skies, quests in Quest, puzzles in Jigsaw and gated destinations in Allure before trying to place those specialized items. Work in meters and use the preview camera to verify scale and walkable spacing. Xolo Studio can later capture a Xolo map snapshot from this editor.

For Life tiles you can also choose a climate override or leave AUTO REGION so weather follows deterministic regional inference. Planet tiles can reference authored sky profiles. Mark only genuinely essential tiles as CORE / ALWAYS LOADED; ordinary published maps should remain chunkable so future large worlds do not force every player to download everything at startup.

PUBLISH TILE writes readable authoring truth under assets-src/worlds/<reality>/map.json and regenerates the compact VSP2 discovery/core/chunk resources under public/data/spatial. Hosted clients load core data plus the relevant 8×8 world chunks instead of reading Azarion source files.

Shop Builder creates bounded Planet shop interiors that players can enter from the world. It combines reusable catalog props with a vendor, an exit and stock definitions so commerce spaces can be authored visually instead of hard-coded per district.

Open or create a shop, arrange its interior objects in the center view, place the vendor and exit, and choose which inventory or Infinity-backed goods the shop should expose. Use the Inspector to refine shop identity and placement data, then publish once the interior and stock are ready.

Prepare furniture, counters, shelves and decorative assets through Forge so they appear as shop-compatible catalog content. Prepare the goods you want to sell through Infinity or the existing inventory definitions. The Planet district and shop entry that will lead here should already have a stable identity so the interior can be referenced consistently.

Keep the interior compact enough for reliable navigation and leave clear space around the vendor and exit interaction zones. Test that decorative meshes do not block the path unexpectedly and that the camera/player can move between the entrance, merchandise and vendor without clipping. Shops are small shared resources, so avoid unnecessary unique heavy assets when reusable catalog props will do.

PUBLISH SHOP writes assets-src/shops/<district>/<shop>/shop.json and regenerates the VSP2 spatial resources. Shop definitions remain in the always-loaded core because they are compact and commonly needed, while their referenced models continue to come from the normal asset catalog.

Forge is the main 3D asset intake tool for props, vegetation, buildings and other reusable world models. Its purpose is to take source files from the local developer inbox, inspect them safely, and turn them into assets that Life, Planet, Xolo and the other creator tools can address by a stable catalog ID.

Start by putting a model pack under developer/raw, open Forge, and select the model from Explore. Review its category, bounds, transform and material slots in the Inspector, correct anything the automatic analysis guessed incorrectly, then choose PROCESS INTO VIRTUA. Forge performs the Blender and asset-pipeline work for that selected model and refreshes the runtime catalog when it finishes.

Prepare FBX, OBJ, GLB, GLTF or Blender source files at a sensible real-world scale, preferably using meters. Keep related textures inside the same top-level raw pack so Forge can discover them. For environment assets, place the origin near the ground contact point and avoid applying unusual root transforms unless they are intentional.

Forge relies on Blender being available from the command line for formats and operations that need Blender. The normal Node dependencies must also be installed. Texture names that clearly describe roles such as base color, normal, roughness or opacity reduce manual material mapping, while clean mesh names and separated materials make later debugging easier.

Processing writes an authoring asset under assets-src with its asset.json metadata, generates the optimized runtime model under public/assets, and refreshes public/assets/catalog.json. The resulting catalog ID is the reference used by World Map Editor, Infinity, Viewer and other systems; the original developer/raw source remains untouched.

Viewer is the runtime-model inspection tool. Its purpose is to show the optimized catalog asset rather than the raw source, so you can confirm what players will actually download and render before using that model in maps, objects or other authored content.

Browse or search the runtime catalog, select a model, inspect it in the center viewport, and use the filters to focus on buildable, world, shop or Xolo-compatible assets. Open DETAILS when you need the exact catalog ID, URL, geometry statistics, materials, textures, bounds or impostor information.

Viewer expects assets to have already passed through Forge or another supported asset build path. If a model is missing, return to the intake tool and process it first. Use Viewer after important changes to scale, material mapping or optimization because it catches problems that may not appear in the raw preview.

Pay attention to real runtime bounds, visual scale, transparent materials and payload size. A model that looks correct but has a very large footprint or unusually heavy triangle/texture count can still cause problems when repeated many times in Life or Planet. COPY ASSET ID gives the exact identifier other creator tools should store.

Viewer does not normally produce a new asset. Its output is a verified runtime catalog entry and a stable asset ID that you can safely reference in World Map Editor, Infinity, Jigsaw and other tools; items that need correction can be sent back through the authoring pipeline.

Armature is a quality-assurance viewer for characters that are already in the runtime catalog. Its purpose is to show whether an avatar skeleton and its animation clips behave correctly with Virtua movement, combat and retargeted motion before that character is used widely in Life or Xolo.

Choose a catalog avatar, inspect the character in the center viewport, and use the clip controls to play runtime, own or retargeted animations. Toggle the skeleton overlay when you need to see the actual bone structure, use PREV and NEXT to move through clips, and change playback speed to make foot sliding, snapping or incorrect bindings easier to notice.

Armature expects a processed avatar under the actors/avatars catalog path. If you are starting with an FBX or a raw rig, prepare it in Mecha first. The avatar should have a sensible rest pose, stable bone names and at least the clips or mappings needed by the gameplay context you plan to test.

Retarget tests depend on compatible skeletal structure and bone naming. A clip may technically play while still looking wrong, so inspect hands, feet, hips and root movement rather than only checking that the model moves. Problems found here are normally corrected in Mecha or the original source rather than inside Armature.

Armature is primarily an inspection tool and does not create a new runtime asset by itself. Its useful output is validation: a confirmed avatar/animation mapping that can safely be referenced by inventory, NPCs, Xolo Studio and world content.

Orinoco is the audio intake tool for sound effects, ambience, music, voice and interface sounds. It lets a creator keep audio beside the rest of a purchased or handmade asset pack while still producing standardized runtime files and audio metadata for Virtua.

Select a raw sound from Explore, preview and scrub it, then confirm the guessed category or choose another one. The category applies a normal Virtua audio profile for bus, loop behavior, spatial mode, normalization, channels, bitrate, gain, priority and voice budget; only disable the automatic profile when the sound genuinely needs a special case.

Place common WAV, FLAC, AIFF, MP3, OGG, Opus, M4A, AAC or WebM files under developer/raw. Use clean recordings when possible and leave enough headroom to avoid clipping before normalization. Short positional effects are usually best as mono, while music and broad ambience may remain stereo.

FFmpeg must be available from the command line, and ffprobe is recommended so duration, channel and sample-rate metadata can be read reliably. Decide whether a sound is meant to loop before processing, and listen for clicks at the loop point if it is intended as continuous ambience.

PROCESS INTO VIRTUA copies the source into assets-src/audio with asset.json metadata, encodes an optimized Opus/WebM runtime asset and refreshes public/assets/catalog.json. The resulting audio catalog entry can be used by worlds, effects and future gameplay systems without depending on developer/raw.

Materia creates reusable surface definitions from PBR texture sets. Its purpose is to make grass, rock, sand, snow, water, concrete, wood, metal and other tiled surfaces consistent across Life, Planet and creator previews without requiring every world map to manage raw texture files itself.

Put related texture maps in developer/raw, select the detected material group in Explore, and use AUTO MAP or manual role assignment for Base Color, Normal, Roughness, Metallic, AO, Height, Opacity and Emissive. Preview the material on a sphere, box, cylinder or plane, adjust tiling and normal strength, then process the confirmed set.

Prepare texture files with recognizable role names such as BaseColor, Normal and Roughness and keep maps for one surface close together. All maps in a material should describe the same physical surface and ideally use matching dimensions and UV orientation. Remove or dismiss unrelated images when automatic grouping cannot separate them cleanly.

Use physically sensible maps: normal maps should be true tangent-space normals, roughness should not be mistaken for gloss unless converted, and opacity should only be included when the material really needs cutout or transparency behavior. The processing pipeline requires the normal project dependencies; KTX2-capable runtime optimization is handled by the existing asset build.

Processing writes the confirmed source set and asset.json metadata under assets-src/materials, generates optimized runtime textures, and refreshes the catalog. Terrain categories are discovered automatically by the shared world material system, while the saved tiling metadata lets Life and Planet reproduce the intended scale.

Sprite is the image intake tool for visual assets that are not full PBR material sets. Use it for interface icons, object icons, portraits, tutorial or editorial images, Xolo cabinet art, effect sprites and other 2D imagery that needs a stable runtime catalog entry.

Place images in developer/raw, select one from Explore, choose its category and output name, then tune maximum size, quality and lossless behavior in the Inspector. You can dismiss irrelevant images without deleting them, or assign related images to an atlas group and build an atlas when many small sprites should share one texture.

Prepare PNG, JPG or similar source images at the best quality you have. Transparent assets should keep a proper alpha channel, and icons are easier to reuse when the artwork has comfortable padding. If a folder mainly contains PBR maps such as normal and roughness textures, use Materia instead of Sprite.

For cabinet art, portraits and interface images, decide the intended aspect ratio before processing so resizing does not surprise you. Use clear filenames because Sprite uses names and paths to help infer categories. Atlases work best when the source sprites belong together and can share the same sampling and transparency expectations.

Processing creates an isolated assets-src/ui authoring folder and an optimized public/assets image, then registers it in the catalog as a UI image. Atlas builds additionally produce the packed atlas and frame metadata. Other tools such as Infinity and Xolo Studio can then select the Sprite output by its catalog ID.

Spark is the particle-effect authoring tool. It creates lightweight reusable presets for things such as smoke, sparks, dust, magic effects or local ambience, using the same pooled particle runtime that the worlds use instead of creating one-off effect code for every map.

Choose or create a preset in Explore, then edit emission, pool size, lifetime, size, speed, opacity, direction, shape, drift, buoyancy or gravity, color and optional Sprite texture in the Inspector. Use the center preview to watch the effect while you tune it, select whether it loops, fires once or waits for interaction, and save when it behaves correctly.

Prepare a Sprite asset first when the effect needs a custom textured particle; primitive sphere or box particles do not require one. Decide whether the effect is ambient, a one-shot burst or something the player activates, because this affects how World Map Editor will use it. Keep particle counts conservative so one attractive effect does not become expensive when many copies are visible.

Test the effect at roughly the distance and scale where it will be used in the world. Very small lifetimes combined with high emission rates can produce unnecessary work, and very large transparent particles can be expensive because of overdraw. The preview is intended to help you find a visually useful result before placing many instances.

SAVE TO VIRTUA writes a compact preset under assets-src/effects/particles/presets, publishes the runtime JSON into public/assets, and registers a particle-preset in the asset catalog. World Map Editor can then place that preset as an EFFECT object in authored maps.

Skies is the HDR environment authoring tool. It prepares equirectangular sky images that can be used as visible Planet skies and environment lighting, including simple day/night or four-phase time-of-day profiles.

Place HDR files in developer/raw, select a sky in Explore, preview it, choose a phase such as Dawn, Afternoon, Dusk or Night, and process it. After processing, World Map Editor can assign those catalog skies to Planet tiles and control the cycle length and crossfade behavior.

Prepare a true equirectangular HDR image with a 2:1 layout when possible. The horizon should be level and exposure should be reasonable enough that both the background and lighting response are useful. Very large source HDR files are acceptable because the pipeline can reduce them for runtime use.

Blender is used when HDR resizing is requested, and FFmpeg can be used to create a lightweight preview. Both should be available from the command line for the full workflow. Think about how multiple skies relate to one another: a four-phase set looks best when the environments describe the same location across different times rather than unrelated scenes.

Processing writes the authored sky under assets-src/environment/sky, publishes the optimized HDR and optional preview under public/assets, and adds an hdr-environment entry to the catalog. Planet map definitions then reference those stable sky assets rather than raw HDR files.

Infinity defines what a virtual object is. Instead of treating an inventory row as a pile of duplicated display information, Infinity combines a stable object ID with its name, category, description, 3D representation, icon, rarity, stacking rules, tags and reality availability so many systems can reference the same definition.

Create or select an object in Explore, choose an optimized model from the Forge catalog and an icon from Sprite, then complete its metadata in the Inspector. Adjust the display transform while looking at the center preview, choose which realities may use it, and save once the object has enough information to be marked ready.

Prepare the visual resources first: the 3D model should already be processed through Forge and the icon should already be processed through Sprite. Decide on a stable human-readable ID because that ID is intended to survive later migrations from local simulation to wallet and blockchain-backed ownership.

Keep ownership-specific information out of the object definition. Quantity, owner, acquisition time or eventual Avenge object IDs belong to inventory or chain state, while Infinity should describe the reusable product itself. Use consistent categories and concise descriptions so shops, quests and creator tools can present the object without special-case code.

Saving writes assets-src/objects/<category>/<id>/object.json and rebuilds public/data/objects.json. Inventory, Allure, Quest, Jigsaw and future Avenge integration can reference the stable object ID while using the same model and icon metadata everywhere.

Sense is the visual contract-design tool for the future Avenge Move chain. It lets developers describe virtual-good creation, ownership and simulated settlement logic as a node graph now, before a live Cedra/Avenge network is connected to Virtua.

Create or select a contract in Explore, place nodes in the center graph, connect compatible ports, and edit the selected node or package metadata in the Inspector. Use Infinity object IDs when the contract refers to a known virtual good, and use the built-in simulation to reason about state changes before treating the generated Move as deployable code.

Before starting, understand the object or transaction you want the contract to represent. Prepare any Infinity definitions that should be referenced and decide which actions are administrative, which are user calls, and which values will eventually come from runtime or chain arguments rather than being hard-coded.

Sense currently targets the Cedra/Avenge-style Move architecture but intentionally does not connect to a blockchain. Generated code should therefore be treated as design output that still needs future compilation, package-address configuration, security review and integration testing when the actual Avenge fork is available.

Saving keeps the versioned Sense graph as readable authoring truth and generates a corresponding simulated Move package/runtime catalog entry. That gives later tooling a stable graph and source representation without locking the editor to today's temporary local simulation.

Twilight is the dynamic liquid-material editor for water-like surfaces. Materia handles the reusable PBR texture set; Twilight adds time-based shader behavior such as flowing normals, waves, Fresnel response, foam and liquid color so rivers, pools or oceans can share a consistent authored graph.

Create or select a Twilight graph in Explore, add and connect nodes in the center graph, then switch between GRAPH and PREVIEW to see the result on a live surface. Choose a processed Materia surface as the static texture foundation and tune palette, flow, waves, Fresnel, foam and output controls until the liquid behaves as intended.

Prepare any reusable texture surface in Materia first, especially normal maps or foam-supporting textures you want the liquid to reference. Decide roughly whether the material represents calm water, a fast river, thick liquid or another effect because that guides the useful range of wave scale, speed and foam.

Twilight runs on the shared WebGPU/TSL material approach, so keep the graph compact and prefer reusable parameters over stacking unnecessary animated operations. Test the preview from several angles because Fresnel and transparency-like cues can look good from one view while failing at grazing angles.

Saving writes the Twilight graph as authoring data and publishes a reusable shader-preset/runtime definition that references the Materia surface rather than copying its textures. World and rendering systems can later bind that preset to water surfaces with the same stable identity.

Xolo Studio is the composition tool for turning existing Virtua content into a playable arcade title in the Xolo Library. It does not replace the asset tools; instead it combines a Xolo map, player avatar, enemy rules, scoring, cabinet art and an optional achievement reward into one game definition.

Create a game, capture the intended Xolo lane from World Map Editor, select the fixed player avatar, add one or more enemy spawn rules, choose Sprite-produced box art, and configure scoring, session time, achievement reward and the custom X intent text shown for the game action. Preview the composition in Tetra, save it, and use PLAY TEST to launch it through the normal Xolo runtime.

Prepare the Xolo map first in World Map Editor and make sure the avatars you want to use are available to the runtime. Prepare cabinet art in Sprite and create an Infinity object if the title should award a reusable virtual item. Enemy avatars should be appropriate for the movement and combat expectations of the selected game.

The captured map is intentionally a snapshot, so choose the version you want the released arcade title to keep. NPCs from the general map are not copied into the game because Xolo Studio owns enemy composition. Keep spawn counts and scoring rules understandable enough that a player can discover the objective quickly.

Saving writes assets-src/xolo/games/<game-id>/game.json and regenerates public/data/xolo-games.json. The normal Xolo Library loads that catalog, displays the selected box art on a cabinet, launches the stored map snapshot and exposes the title to leaderboards without requiring Azarion mode.

Allure creates special bounded destinations that are reached through gates placed in Life or Planet instead of appearing as ordinary directly selectable maps. These areas are useful for secret locations, branded spaces, event rooms or places where exclusive Infinity objects can be acquired or traded.

Create an area in Explore, set its identity, allowed origin realities and optional item offers, then use EDIT MAP to build the bounded space in World Map Editor. Place a GATE object in a Life or Planet map and point it at the stable Allure area ID; at runtime the player walks into the gate zone and interacts to warp into the area.

Prepare any world models, materials, effects and special Infinity objects before composing the area. Decide whether the Allure should be always loaded as core content or lazily loaded only when entered. If the area offers Lightning trades, also prepare the intended destination address and satoshi prices.

Keep the map bounded and intentional because an Allure is closer to a designed experience than an endless Life region. Verify there is a safe arrival space and a clear route back to the return gate. Access flags should match the places where you actually intend to place entrance gates.

Publishing writes readable area authoring data under assets-src/allure and updates the spatial VSP2 resources. Core areas join the always-loaded spatial resource; non-core areas receive their own lazy-load file. Runtime gates reference the same stable area ID, while offers reference Infinity object IDs.

Quest is the Life mission authoring tool. It gives an NPC a reason to involve the player and supports kill, gather, follow, go-to and find-NPC objectives, along with success, failure, cooldown, repeatability and reward rules.

Create a quest in Explore, choose its quest-giver identity, objective type and target values, then write the short offer, active reminder, success closing and failure closing text in the Inspector. Preview each dialog state, choose an Infinity reward when needed, save the quest, and finally place a static or radiant quest NPC in World Map Editor.

Prepare any referenced Infinity object, enemy type, NPC avatar or destination before authoring the quest. For go, find and follow objectives, use positions that make sense on the Life map where the giver will be placed. Keep the narrative short enough for the bottom dialog layout and make the objective clear in normal language.

Choose cooldown, repeatability and time limits carefully. A failed quest resets through its cooldown, while a successful non-repeatable quest stays complete. Radiant quests should be generic enough to make sense when assigned by the runtime, whereas static quests can depend on a specific giver and local story.

Saving writes assets-src/quests/<quest-id>/quest.json and regenerates public/data/quests.json. Published Life NPC rows can bind directly to the quest ID or select from radiant definitions, and the runtime quest service tracks progress, failure, cooldown and reward claiming.

Jigsaw creates interactable puzzle mechanisms for Life and Allure. It covers simple triggers that open or remove a passage, exchanges that require inventory items or a simulated Lightning payment, combined-key puzzles and two- or three-step interaction sequences that grant a reward.

Create a puzzle in Explore, choose the puzzle family, select catalog models for the trigger, target and any sequence parts, then configure the required Infinity items, payment or interaction order in the Inspector. Preview the arrangement in Tetra, save it, and place the complete Jigsaw instance from World Map Editor at the desired anchor point.

Prepare all visible models through Forge and any required or rewarded goods through Infinity. For an exchange puzzle, decide whether required items are consumed or simply checked according to the available Jigsaw settings. For mechanisms, make sure the target model and movement direction leave a usable passage when opened.

Sequence puzzles support at most three ordered interactables, so design them as a readable local challenge rather than a long memory game. Leave enough physical spacing that interaction prompts do not overlap, and test collision after the target changes because a door that disappears visually must also stop blocking the player.

Saving writes assets-src/jigsaw/<puzzle-id>/puzzle.json and rebuilds public/data/jigsaw.v1.json. World Map Editor stamps linked parts with a shared puzzle and instance ID into the spatial data, allowing Life or Allure to restore progress and update collision when the puzzle is solved.

Mecha is the character preparation pipeline for animated avatars. It is used when you have a raw FBX, GLB or GLTF with an armature, or separate files that mainly contain animation clips, and you want to turn them into a standardized Virtua avatar plus reusable animation libraries.

Place one actor package under developer/raw/armature/<actorname>, open Mecha, select the primary render model, inspect the Blender analysis, assign missing PBR textures, set target height or yaw if needed, and classify animation clips into locomotion, combat, vehicle, gestures, special or dying. PROCESS AVATAR then performs the conversion and updates the chosen master-armature libraries.

Prepare a clean skinned character with a stable armature and sensible rest pose. Put the main model, animation-only files and related textures in the same actor folder. If textures are not embedded, use clear filenames and verify that the correct maps are assigned before processing.

Blender must be available from the command line. Retargeting is easiest when bone names and hierarchy are consistent with existing Virtua characters, so avoid unnecessary helper bones and rename only when you understand the impact. Safe cleanup is deliberately conservative and only removes unused non-deforming leaf bones rather than aggressively rewriting a rig.

Processing creates an optimized avatar authoring asset under assets-src/actors/avatars, updates the runtime avatar catalog, and stores reusable category master armatures under developer/mecha/master-armatures. Those masters make future retargeting faster because locomotion, combat and other clip groups can be collected once and reused.

AZTEQ Content is the editorial authoring tool for the News, Radio and Video feeds used by Virtua. Its purpose is to keep readable source content separate from runtime code so editors can update programming, stories and media listings without rebuilding the creator application itself.

Choose News, Radio or Video in Explore, edit the readable source JSON in the Content Studio, and use SAVE SOURCE to validate and keep the private source. When the feeds are ready, PUBLISH PACK builds the independent content distribution and refreshes the local public fallback used during development.

Prepare editorial data under assets-src/content and keep each feed internally consistent: categories, items, identifiers, titles, media references and any feed-specific fields should remain valid JSON. Treat the source files as editorial documents rather than generated runtime artifacts so they remain reviewable and versionable.

AZTEQ Content requires Azarion creator mode because saving and publishing use loopback-only creator APIs. Production clients should consume the published /content/ pack or another mounted content origin; creator endpoints and local source paths are not part of the public runtime.

The output is a validated content pack written independently from the main application, including content-dist/ and the local public/content/ fallback. This lets News, Radio and Video evolve on their own release cadence while Virtua continues to consume a stable published feed.

AZTEQ Optima is the application-image maintenance tool. It scans public icon sources, reports dimensions, source size and reference counts, and helps reduce the weight of UI artwork without forcing creators to manually locate every place an image is used.

Search or select an icon, choose AUTO, WebP or AVIF, set the desired quality, and optimize either the selected file or the full icon set. AUTO prefers lossless WebP for artwork with transparency and AVIF for opaque imagery. Reference replacement is optional and only occurs after a new output has been written successfully.

Use Optima after the interface and creator tools have accumulated stable PNG or JPEG artwork. Review images that depend on transparency, verify that the selected quality still preserves legibility, and use the reference count to understand how widely an icon is used before migrating its source path.

Optimization runs through the local Azarion maintenance API and therefore belongs in creator mode. Original PNG/JPEG files are retained for rollback, and reference migration should only be enabled when the generated file has been checked in the application.

The output is a smaller WebP or AVIF variant together with measured byte savings and, when requested, safely migrated source references. Optima is a maintenance tool rather than a general image editor: its job is to make already-approved interface assets lighter without making recovery difficult.

AZTEQ Library is the publishing tool for comics and books. It keeps covers, ordered page images and title metadata together so long-form visual reading material can be prepared for the Virtua Library without hand-building feeds or file structures.

Create a Comic or Book, enter its title, author, format, language and description, then optionally set a dedicated cover. Import PNG, JPEG or WebP pages in reading order, remove incorrect pages when necessary, save the metadata, and use PUBLISH PACK when the title is ready to enter the independent content distribution.

Prepare clean page images before import and choose the format that matches the publication: A4 or Letter for larger page layouts, or Pocket for compact books. Page order is significant because imported pages are numbered automatically; when no dedicated cover is supplied, the first page is used as the cover.

Library authoring uses the loopback-only Azarion API and stores editable source under assets-src/library. The creator should confirm page orientation, readability and metadata before publishing because the runtime reader consumes the optimized published representation rather than the raw import files.

The result is an optimized page library, cover representation and reader metadata included in the independent content pack. Comics and books can therefore be updated as content while the main Virtua application continues to use a stable library feed.

Tetra Docs is the in-product reference browser for Azarion creators. It gives each major creator tool a short practical guide so a creator can understand the purpose of an extension, the normal workflow, what to prepare, what it depends on and what it produces without leaving the working environment.

Open Tetra Docs, search by tool or keyword, filter by category, and choose a guide from the card grid. Opening an article presents the five-step reference and marks it as read locally in the browser. The reader is intentionally lightweight so it can remain available while the actual creator extensions continue to be the source of authoring work.

The in-product guide feed is served from public/data/tetra-docs.json. Each guide has a stable id, title, category, caption, optional image and keywords, plus five body paragraphs corresponding to Purpose, Workflow, Preparation, Prerequisites and Output. Keep those entries concise enough to work as an operational reference rather than a second whitepaper.

Tetra Docs itself does not write creator assets or invoke privileged authoring APIs. It only requires the documentation feed to be present and valid. Documentation should describe current creator behavior and should be updated when an extension changes meaningfully so the guide does not preserve an obsolete workflow.

The output is knowledge rather than an authored asset: a searchable creator reference inside Azarion. The public Creator Documentation on azteq.one mirrors the same chapter-per-extension principle for people who want to learn the toolchain before opening creator mode.