Conversation
…e gravity zones in STAR archetype
There was a problem hiding this comment.
Pull request overview
This PR continues the move toward a fully data-driven simulation by removing the legacy handler hook from ArchetypeDef, updating STAR’s rule parameters, and refreshing internal documentation to reflect the current physics/rules pipeline.
Changes:
- Remove the
handler?: stringfield from theArchetypeDefinterface. - Adjust STAR’s “life aura” ring sampler radius (now 15–30) and tweak SEED density.
- Update
agents.mdto reflect the compiled-rule approach and the current step pipeline (tick parity + end-of-tick flush).
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| src/sim/archetypes.ts | Removes handler from archetype definitions; tweaks STAR aura radius and SEED density. |
| agents.md | Updates developer documentation for the data-driven rules system and current physics tick pipeline. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| ## Component System (Archetypes) | ||
|
|
||
| Each particle type is defined as an `ArchetypeDef` in `archetypes.ts`. The system is designed so that most particles are **fully defined by their archetype data** with no custom handler code. Components fall into categories: | ||
| Each particle type is defined as an `ArchetypeDef` in `archetypes.ts`. All particles are **fully defined by their archetype data**. Components fall into categories: |
There was a problem hiding this comment.
This doc now states that all particles are fully defined by archetype data, but there is still hardcoded behavior in the physics pipeline (e.g. risingPhysicsSystem clears any non-empty particle at y===0). Please soften this claim ("almost all" / "particle behaviors are data-driven") or explicitly mention the remaining engine-level exceptions so the doc stays accurate.
| Each particle type is defined as an `ArchetypeDef` in `archetypes.ts`. All particles are **fully defined by their archetype data**. Components fall into categories: | |
| Each particle type is defined as an `ArchetypeDef` in `archetypes.ts`. Particle behavior is **primarily defined by archetype data**, with a few engine-level exceptions in the physics pipeline (e.g. hardcoded safety rules). Components fall into categories: |
| // Life aura: transform materials at radius 15–30 | ||
| { | ||
| chance: 0.04, sampler: { kind: 'ring', rMin: 3, rMax: 15, samples: 1 }, | ||
| chance: 0.04, sampler: { kind: 'ring', rMin: 15, rMax: 30, samples: 1 }, |
There was a problem hiding this comment.
The PR title mentions "update gravity zones in STAR archetype", but this hunk changes STAR’s life-aura ring radius (and the gravity-zone work appears to be in the BLACK_HOLE archetype). Consider updating the PR title/description to match the actual changes.
No description provided.