Done on the Vectornaut:demo-summer-2025
branch, as of commit [6928ac8
](https://code.studioinfinity.org/Vectornaut…
I'm removing the dependency on #66 because we decided that loading an assembly from a file would amount to calling a sequence of element and regulator creation commands—which is what the test…
Did we intentionally remove this indicator, which flags an element with an invalidly specified regulator when the regulator list is closed? The removal looks like a regression—especially because we didn't remove the associated CSS—but I wanted to check in case we decided on it in a meeting and I forgot to write it down.
I didn't intend for this comment to require a review. I'm hoping that submitting this review will make the comment visible to other users, as intended.
don't forget to file that issue
Whoops, thanks for the reminder! This is now issue #90.
assembly
module
During our meeting, we decided that cleaning up the forwarded project_to_normalized
implementations will best be done in a dedicated pull request that encapsulates element representation data…
My first attempt to avoid forwarding the project_to_normalized
implementations was:
- Make
project_to_normalized
a method of a newengine::EngineElement
trait. - Make `engine::EngineEleme…
I am happy with the names but it seems cumbersome that there are methods project_XXX_to_normalized and then two boilerplate implementations of project_to_normalized that just forward to the…