# Upstream issue draft — Chorizite/DatReaderWriter

**Repo:** https://github.com/Chorizite/DatReaderWriter

This draft is for filing as a GitHub issue (or a 1-line-fix PR) against
the Chorizite DatReaderWriter project. The duplicate generated file
fails to build against its own enum and shadows the correct
`ParticleEmitter` registration for the `0x32xxxxxx` ID range.

---

## Title (under 80 chars)

`Duplicate ParticleEmitterInfo.generated.cs references missing DBObjType enum value`

## Summary

`DatReaderWriter/Generated/DBObjs/` contains two generated files for
the same DB type (`DB_TYPE_PARTICLE_EMITTER`, ID range
`0x32000000–0x3200FFFF`):

- `ParticleEmitter.generated.cs` — class `ParticleEmitter`, uses
  `DBObjType.ParticleEmitter` (correct, matches the generated enum)
- `ParticleEmitterInfo.generated.cs` — class `ParticleEmitterInfo`,
  uses `DBObjType.ParticleEmitterInfo` (does not exist in
  `Generated/Enums/DBObjType.generated.cs`)

The second file is byte-for-byte identical to the first apart from the
class name and the enum reference. Only `DBObjType.ParticleEmitter` is
emitted by the source generator (see line 179 of
`DBObjType.generated.cs`), so the duplicate fails to compile and also
registers a second `[DBObjType(..., 0x32000000, 0x3200FFFF, ...)]`
attribute for the same ID range, which collides at runtime in
`PortalDatabase.Get<T>(uint id)`.

## Reproduction

1. Clone `Chorizite/DatReaderWriter` at master.
2. `dotnet build DatReaderWriter.sln`
3. Build fails in `Generated/DBObjs/ParticleEmitterInfo.generated.cs`
   on the `DBObjType.ParticleEmitterInfo` reference (`CS0117: 'DBObjType' does not contain a definition for 'ParticleEmitterInfo'`).

If the file is hand-edited to compile (e.g. by switching the enum to
`ParticleEmitter`), two classes are then registered for the same ID
range `0x32000000–0x3200FFFF` and `Get<ParticleEmitterInfo>(id)` /
`Get<ParticleEmitter>(id)` ambiguously dispatch.

## Expected behavior

A single generated class for `DB_TYPE_PARTICLE_EMITTER`. The
`PortalDatabase.generated.cs` reader already exposes only
`GetParticleEmitter(uint id)` returning `ParticleEmitter?`, so
`ParticleEmitter` is the canonical name.

## Actual behavior

`ParticleEmitterInfo.generated.cs` exists and breaks the build. It
appears to be a stale artifact from an earlier pass of the source
generator when the type was renamed `ParticleEmitterInfo → ParticleEmitter`.

## Proposed fix (one line)

Delete `DatReaderWriter/Generated/DBObjs/ParticleEmitterInfo.generated.cs`.
If the source generator regenerates it, the generator's type-name map
needs the `ParticleEmitterInfo` entry removed too.

## Why this matters to downstream consumers

Downstream consumers (e.g. acdream, an open-source modern AC client
that vendors DatReaderWriter) cannot build the library as-is — we
have to manually delete the duplicate file in our vendored copy on
every update. Anyone trying to load `0x32xxxxxx` records and reaching
for `ParticleEmitterInfo` (the historical / decompiled-client name)
hits a broken type instead of being directed at the renamed
`ParticleEmitter`. A clean upstream fix removes the per-consumer
patch.

## Environment

- Commit: master @ HEAD as of 2026-04-26
- .NET SDK: 10.0
- OS: Windows 11