Home / Coming from the Access editor

Coming from the Access editor

If you have used the old MS-Access Platform Editor (pfBuild2005.mdb over pfData2005.mdb), most of what you know still applies: same 16 annexes, same ids, same soft cross-references. What changed is almost everything about how you get from opening the database to shipping a change. This page is that diff.

One app, not two files and a batch script

The Access editor never touched a .RES file itself. It ran against a CSV working set that start_edit.bat and end_edit.bat produced and consumed around it, and the front-end's own forms were bound to linked tables in pfData2005.mdb, a separate data file from the one holding the forms. Getting from a commondb.res to an editable record meant running Import first, and getting an edit back out meant running Export, then closing the loop with the batch file that copied the rewritten commondb.res and commondb.rsr back into the battleset directory.

This editor skips that whole pipeline. It reads a commondb.res (or its own .hcpe.json project file) directly, and Export .res writes a commondb.res directly — there is no CSV directory, no start_edit.bat/end_edit.bat, and no separate db_make / res_implode / hcompress step to run afterwards. The menu item runs the same preflight checks the game itself would fail on, then builds the container bytes itself. See Getting started for the whole open-edit-export loop end to end.

Nothing is committed until you say so

The Access editor's forms were bound straight to the linked tables, and a new record got its id from GetNextID the moment you started one — before it had a name, before you had decided to keep it. This editor's create form works the other way around: opening Add on an annex grid renders a blank form and writes nothing. The record only exists once you press Add to database, which parses the form, appends the record, and logs one create entry, so nothing typed can be half-saved. An empty name is refused rather than added. Leave the screen before pressing it and nothing happened at all.

That save can finish more than the bare record. A mount's weapons-carried grid renders on the create form itself, so a mount and a mixed load — the same find-or-create Z2 multi-mount the stored mount editor produces — go in as one Add, not a record you go edit afterwards to give it something to carry.

What stayed the same, and what did not

In the Access editor	Here
New records get an id from `GetNextID`: the lowest free slot in the annex's 4096-id window.	The exact same window and the same lowest-free-slot rule — shown on the create form before you press Add, not after.
`db_make` could write ids in a "fudge-mode" hex form.	Export always writes plain decimal ids. There is no fudge mode.
A dangling reference surfaced as a line in `tMessageLog` during the next Import, if anyone read the report.	A dangling reference is not a database error at any point: 65535 always means "none", and a reference to a missing record is a Check finding — blocking or advisory depending on what it would actually do to the game — not something that stops an Import or an Export on its own.
`dComponentUsers`, "who uses this component", was a dialog you opened yourself.	Every record's own screen carries a "Used by" section, folded away when nothing refers to the record. Delete shows you the same list before it lets you remove anything.
Merging duplicate records (`dMergeRecord`) redirected every reference to the survivor — except for ships, where it was turned off.	The guided merge on the Duplicates screen works the same way on every annex, ships included.
`tPlatformHistory` logged every edit under a single-timestamp primary key, which could collide if two edits landed in the same second.	Every change-log entry carries its own generated id, not a timestamp, so two edits in the same second are still two entries. Each is independently revertable from History.

A quirk fixed rather than carried over

Not everything unfamiliar here is a design choice — some of it is a bug in the old schema that this editor does not repeat. A ship's six armor sectors, Engineering, Bridge, Deck, Hangar, Cargo, Sensors, all decode against the same armor-class lookup in this editor. In the Access schema, ARMHangar had no such lookup at all: a mis-built constraint had been duplicated onto ARMSensors instead, leaving the Hangar sector as a bare number with nothing to check it against. See Armor in the ship field reference for the fixed, six-sector field.

What this one does not have

Being straight about the gap: the Access editor's switchboard offered a rCountrySummary report, a platform count broken down by country. There is no equivalent screen here yet — the closest you can get today is an annex grid's Country column, filtered to one country at a time from its header funnel.

The Access editor also shipped satellite tools solving a problem this editor does not have: AccessChecker detected whether a compatible Access was installed at all, and, if not, offered to install the Access 97 Runtime just so the front-end could open. This editor is a native program for Windows and Linux: unpack it and run it, so there is nothing to detect, license, or install first — that whole category of setup problem does not carry over because there is nothing on the other side of it to be missing.

For everything else, the destination is the same as it always was: a commondb.res the game loads. Getting started walks the open-edit-export loop, and Tools covers Find, Check, Duplicates, Compare, replacing references, and the change log in full.