All in all, I'll probably add a bunch of shared hardcoded functions (like `max()` to get the largest value) to Autodoc, to allow folks to implement better custom functions without running arbitrary code. I can already see how those can be useful in my own mods.

More importantly: it works! I'm already using functions in Armory to calculate pocket capacity from a set of dimensions, and I'm going to implement a way to calculate clothing coverage per body part the same way.

I still had to hardcode a bunch of stuff because the *DDA* architecture can collide with my own code (both the toolkit and EOCs use `math`, but in different ways) or just be messy in places (e.g. `talk_topic`'s implicit append behavior). Much less than with any previous designs, though.

Been thinking about this for months, but the architecture wasn't there: I would've had to deeply link multiple transformers together, and that's just too much coupling. With the new architecture, which executes transformers on per-value basis, this is much easier to do.

They don't allow executing arbitrary code for security reasons: only what the toolkit already allows (`ref`, `math` etc.). The point it slimming down and allowing to reuse common calculations throughout the code in an easy way:

`{ fn: "dimensions/rectangle", args: ["2 in", "3 in", "5 in"] }`

For context: these are the complete, full logs from the entire build process of a single mod, top to bottom. It includes multiline JSON object representations, but not many compared to regular old basic string logs. The mod is ~110 files, ~450 objects total.

* my quantity string formatter changes "9mm" (ID of an ammo round) to "9 mm" (because that makes a proper quantity string)
* "ARTIFACT" item subtype now required to make artifacts (overall, big fan of the new "ITEM" type system, but that was undocumented)
* inheritance is weird (growing pains)

etc.

It didn't show up on my initial search because it's labeled as deprecated, which must be hiding results from general search. I wasn't aware of that.

Shame you cannot request package name inheritance, but I understand why: you don't want to break even a single workflow of anyone using NPM for anything. It's made to reliable for a reason. This is a good attitude to have, even if it ends up a thorn in the side of an enterprising dev like me.

anyway here i go inventing things again

Multi-pair design would be more complex because instead of properly parsing (and thus understanding) one string, you may end up having to parse a dozen, and each may be quirky enough to expose an edge case with some outstanding mix of units or, hell, even an issue with text encoding or two!

My concern with these things is usually "What makes the most sense?", and that's never a clear-cut question because sense is relative to one's environment. If I'm going to do my own thing, how important is it that my changes are breaking as long as they make sense to a different set of needs?

It's not a big deal, since I'm not updating `js-quantities`: I'm clearly doing my own things, and people can opt in if they wish. That said, I want to maintain a lot of the upstream's practices, since it's a very well-designed library to begin with, and so compatibility feels like a good goal here.

Rewiring that would be a breaking change, and how to approach it is important if I'm ever to be trusted with supporting the fork. I'm not going to go into detail about what my thought process is here, because time tends to reflect poorly on incomplete thoughts, but just string→array is a challenge.

`js-quantities`, the upstream library from which `quantities` was forked, had only ever had support for single-pair inputs (e.g. "5 m^2"). Everything about the library is geared towards only ever having one pair (scalar + unit): `Qty` objects end up with a single `scalar` and `signature` prop each.

This, by the way, is why I started adding sources to everything in the comments: if I had to retrace my steps again, at least I would have a map. This made error-checking much easier, and would enable anyone to correct me if my sourcing was poor.

My very first mods had no workings-out documented, so when I made mistake, sometimes I wouldn't remember how I'd done the calculations initially – including which values I'd used – so I'd have to retrace my steps. I didn't realize the importance of traceability until it bit me on the cheek.

I used to make all of these calculations by hand, by the way – and if I made an error somewhere down the line, or if I'd come up with a better way to calculate it and my initial values were now different, I'd had to redo the entire thing. This kept me from correcting my work sometimes.

For this new iteration of the codebase, I'm not sure how I'm going to solve this, but I want to make sure my approach is reliable in all cases. It's a fun little challenge I make for myself, to keep code interesting. (It's why I like Zach-likes.)