The DWG writer truncates an XRecord Chunk to u8::MAX bytes, so a sketch's constraint set or named-parameter table silently lost every entry on the next DWG open once serialization passed ~255 bytes (found live: a 23-constraint demo round-tripped fine through DXF but came back empty through DWG). Split the blob across multiple same-code 310 entries on save and reassemble them on load, entirely on the OCS side. Co-Authored-By: Claude Sonnet 5 <[email protected]>
6.2 KiB
Changelog
Notable changes on feature/parametric-constraint-system since each push to
GitHub. Newest entries first. "Unreleased" covers local changes not yet
pushed.
Unreleased (since 3d0a41b6)
-
Fix: a sketch's constraint set (or the named-parameter table) silently lost all of its entries on the next DWG open once its serialized size passed 255 bytes — roughly 5-6 constraints, easily reached by a real sketch. Root cause: the vendored DWG writer packs an
XRecordbinaryChunkentry's length as a singleu8and truncates anything longer (cadcodec'sencode_xrecord_entries), so the truncated bytes then failed tobincode::deserializeon load and the loader silently dropped the whole scope rather than erroring. DXF was unaffected (its writer has no such cap), which is what made this findable — the exact same document round-tripped constraint-for-constraint through DXF and came back empty through DWG. Fixed entirely on the OCS side, no dependency patch needed: the blob is now split across as many same-code310entries as it takes (below 255 bytes each) on save, and every entry for that key is concatenated back together on load, instead of just the first one. (sketch_persist.rs, named_parameters_persist.rs) -
Fix: none of the 17 sketch-constraint commands (
HCONSTRAINT,VCONSTRAINT,PCONSTRAINT,QCONSTRAINT,ECONSTRAINT,TCONSTRAINT,NCONSTRAINT,NRCONSTRAINT,LCONSTRAINT,FXCONSTRAINT,SYCONSTRAINT,CCONSTRAINT,EDCONSTRAINT,CPCONSTRAINT,MPCONSTRAINT,OCCONSTRAINT,DCONSTRAINT,ACONSTRAINT) carried aninventory::submit!registration — a pre-existing gap thedocs/command_reference.mdgenerator had already flagged, which meant every constraint command (including this session's newNRCONSTRAINT) was invisible to command-line autocomplete and the MCP server'scommandslisting, despite working fine when typed exactly. Each constraint module now registers itself, with a regression test pinning it so the gap can't silently reappear.- The same missing registration also broke the keyboard-shortcut
editor (
ALIASEDIT): it validates a custom shortcut's target against this same registry and silently rejected anything not in it, so a user could not assign a custom shortcut to any constraint command — not just the new ones, the originalHCONSTRAINT/CCONSTRAINT/etc. family too. Fixed by the same change. (tools.rs, coincident.rs, equal_distance.rs, point_on_entity.rs, value.rs, command.rs)
- The same missing registration also broke the keyboard-shortcut
editor (
Pushed 2026-09-10 (eb96e8b6 → 3d0a41b6)
- Fix: a dimensional constraint's value prompt (e.g.
DCONSTRAINT's "Specify distance:") rejected a named parameter typed in its own lowercase name — the command line uppercases typed text before it reaches the parser, sorbecameRand no longer matched the parameter table's case-sensitive lookup.parse_driving_valuenow matches parameter names case-insensitively and resolves to the parameter's canonical name. (value.rs) - Feature: Named Parameters panel gains a "Used by" column showing
which constraints (kind + entity handles) currently reference each
parameter, with a hover tooltip listing the full per-constraint entity
breakdown when more than a couple of constraints use it. Backed by a new
Scene::parameter_usage(name)query that searches every sketch scope (model space and blocks) and deduplicates an entity referenced by more than one of a constraint's point markers. (named_parameters.rs, sketch_constraints.rs) - Named Parameters modal widened (620 → 820) to fit the new column. (modal.rs)
- Feature: constraint-solver support extended well beyond Line/Circle,
closing most of the gap with FreeCAD's Sketcher (grounded against real
ObjectARX headers so DWG-native persistence stays honest about what
AutoCAD itself can represent):
- Arcs are now full constraint participants: center/radius (Concentric,
Tangent, Equal, CenterPoint, Radius, Diameter, Fixed, Normal) via the
same solver representation a Circle uses, and actual endpoints
(Coincident/PointOnCurve/Midpoint/EqualDistance/Symmetric on an arc's
real start/end point, marker 0/1) — kept numerically consistent with
center/radius/angle by "arc rules" constraints added for every
registered arc, reusing an already-ported-but-unused
ocs_gcsprimitive (CurveValue) rather than new low-level math. - New dimensional kinds:
Diameter,DistanceX,DistanceY,ArcLength— reusing existing DWG classes (Diameter/DistanceX/Y ride the sameACRADIUSDIAMETERCONSTRAINT/ACDISTANCECONSTRAINTobjects Radius/Distance already use, with a different mode/direction byte, matching how AutoCAD itself represents them).ArcLengthhas no DWG equivalent at all (confirmed against ObjectARX's own headers) and is XRecord-only by design, not omission. - New geometric kind:
Normal(a line perpendicular to a circle/arc's tangent), matching AutoCAD's realkNormalconstraint type. - New entity:
Ellipse(center/Concentric/CenterPoint/Fixed only — major/minor axis dimensional constraints andPointOnEllipse-based Coincident/Tangent remain a follow-up). DWG-native persistence for ellipse-referencing constraints is deliberately not implemented yet —acadrust'sEllipse/BoundedEllipsenode variants have a different field shape than the geometry-dependency role Circle/Arc play, and guessing the semantics risked writing a plausible-but-wrong object graph, so it degrades to XRecord-only instead. (sketch_solve.rs, sketch_constraints.rs, dwg_native_constraints.rs, value.rs)
- Arcs are now full constraint participants: center/radius (Concentric,
Tangent, Equal, CenterPoint, Radius, Diameter, Fixed, Normal) via the
same solver representation a Circle uses, and actual endpoints
(Coincident/PointOnCurve/Midpoint/EqualDistance/Symmetric on an arc's
real start/end point, marker 0/1) — kept numerically consistent with
center/radius/angle by "arc rules" constraints added for every
registered arc, reusing an already-ported-but-unused